Fer el projecte més automatitzable
Aquest capítol descriu la infraestructura que fa més segura la delegació: decisions explícites, contractes, tests i una verificació automàtica prou fiable per sostenir més autonomia.
Que la delegació autònoma sigui segura per defecte no és qüestió d’encertar el prompt — és qüestió de com està dissenyat el projecte. Tres palanques són especialment rendibles: decisions de disseny explícites, contractes formals i tests automatitzats. I totes tres només serveixen de xarxa de seguretat real si s’executen automàticament a cada canvi.
Decisions de disseny explícites
Un projecte on les decisions estructurals estan documentades — patrons, convencions, fronteres entre mòduls — satisfà la primera condició del mode autònom sense haver de repetir-les a cada prompt. ADRs, fitxers d’instruccions de projecte i exemples canònics al codi serveixen el doble propòsit: orienten nous desenvolupadors i donen context a la IA per mantenir la coherència. Les decisions ja estan preses i són accessibles — ni el desenvolupador ni l’agent han d’inferir-les de nou.
Contractes i tipus
Definir contractes formals — interfícies, tipus, esquemes d’API, fronteres entre mòduls — fa que la segona condició es compleixi estructuralment: el resultat esperat està descrit amb precisió al codi, no al cap del desenvolupador. Un tipus és una especificació executable; un esquema d’API es pot validar automàticament. Quan l’agent ha de generar codi que encaixi amb aquests contractes, els buits d’especificació queden reduïts mecànicament — no és qüestió de redactar prompts millors, sinó d’haver escrit els contractes al codi.
Tests i CI/CD
La tercera condició del mode autònom és que la verificació sigui simple i fiable. Això depèn de dues peces que es reforcen mútuament: una suite de tests sòlida i una CI/CD que l’executi automàticament a cada canvi.
Però aquestes inversions — documentació, contractes, tests — només es converteixen en una xarxa de seguretat real si s’executen automàticament a cada canvi. Un test que cal recordar de llançar manualment no protegeix res; un contracte que no es verifica a cada commit acaba desincronitzat. El mecanisme que tanca el cicle és la integració contínua (vegeu CI/CD): cada push dispara linters, type checkers, tests i escàners de seguretat, i cap canvi avança si alguna porta falla. Sense CI/CD, l’arnès existeix al repositori però no s’aplica; amb CI/CD, passa a ser la condició per defecte de tot el que es fusiona.
Com més d’aquesta estructura existeixi, més tasques passen de requerir mode Plan o Chat a ser segures en mode Autònom. Invertir en disseny clar, contractes explícits i tests no és només bona enginyeria — és el que converteix la IA d’una eina que cal supervisar constantment en un executor fiable.
Harness engineering
La idea d’envoltar l’agent amb un arnès automatitzat de verificació s’està consolidant com a disciplina amb nom propi: harness engineering. Linters estrictes, type checking, tests de contracte, escàners de seguretat — tot plegat forma un arnès que atrapa les classes d’error que la revisió humana detecta però que no necessita jutjar.
L’arnès no substitueix la revisió — l’allibera. Quan les portes automatitzades ja garanteixen que el codi compila, segueix els tipus, passa els tests i no conté vulnerabilitats conegudes, el revisor humà pot centrar tota l’atenció en el que les portes no poden avaluar: si la solució és la correcta, si l’abstracció aguantarà, si la decisió de disseny encaixa al sistema.
Això també és cert a escala d’equip. La recerca més rigorosa sobre el tema (el report DORA 2025) arriba a una conclusió clara: la IA amplifica el que l’equip ja és. Equips amb CI/CD sòlid, cultura de revisió i bona cobertura de tests canalitzen la velocitat de la IA en guanys reals. Equips sense aquestes bases simplement produeixen bugs més ràpid. L’arnès no és només una pràctica individual — és una inversió organitzativa que determina si la IA accelera el projecte o n’accelera la degradació.