Deixar de revisar codi línia a línia: què el substitueix

La revisió de codi línia a línia és un mecanisme de control que va néixer amb un supòsit implícit: que el codi es produeix a la velocitat a què una persona el pot llegir. Aquest supòsit s’ha trencat.

Quan un agent genera vuit-centes línies en deu minuts i tu en pots revisar amb atenció unes dues-centes per hora, la revisió deixa de ser una porta i passa a ser un teatre. La llegeixes en diagonal, aproves, i el mecanisme que et donava confiança ja no te’n dona. Pitjor: creus que sí.

Aquest article és la part incòmoda del harness engineering: si les tres dimensions funcionen, què queda per fer a l’humà.

Què cobreix cada capa

La confusió habitual és tractar la revisió com una xarxa que ho atrapa tot. No ho és, i mai ho ha estat. Repartim-ho:

Les tres últimes files no s’automatitzen, i les tres primeres no haurien d’ocupar-te el temps. El problema de la revisió tradicional és que barrejava les set en una sola passada, i com que les de dalt són fàcils de detectar, s’emporten l’atenció que necessiten les de baix.

Quan traus les quatre primeres files de la revisió humana, el que en queda no és menys feina: és feina més difícil i més valuosa.

Verificació en capes

L’esquema que descriu en Ben Shoemaker, i que em sembla el més sensat que he vist, és una escala on cada esglaó filtra un tipus d’error diferent:

   sortida de l'agent
          │
     ┌────▼─────────────────────────────────┐
     │ 1. determinista                      │  linter, tipus, format
     │    estructura                        │  → binari
     ├──────────────────────────────────────┤
     │ 2. proves                            │  unitat, integració
     │    comportament                      │  → binari, dins de cobertura
     ├──────────────────────────────────────┤
     │ 3. revisió creuada de model          │  un model diferent llegeix
     │    diversitat                        │  → probabilístic, no correlat
     ├──────────────────────────────────────┤
     │ 4. persona                           │  intenció, disseny, riscos
     │    semàntica                         │  → l'únic que veu el «per què»
     └──────────────────────────────────────┘

L’esglaó 3 és el menys conegut i el que dona més sorpreses: enviar el diff a un model diferent del que l’ha escrit. No és redundància, és diversitat. Un model que no ha generat el codi no arrossega les seves suposicions, i troba coses que el propi autor —humà o no— té cegues. És el mateix motiu pel qual la revisió creuada entre persones funciona i l’autorevisió no.

Un detall pràctic: demana-li que busqui el problema, no que valori el codi. «Digues què falla aquí» dona resultats molt millors que «revisa aquest diff», que acaba en una llista de retocs cosmètics.

Els sis passos, i on és la gent de veritat

L’adopció no és un salt, és una escala. La d’en Mitchell Hashimoto descriu bé el recorregut real:

El pas 5 és on canvia la naturalesa de la feina, i és el que la majoria salta perquè sembla infraestructura i no producte. La formulació d’en Hashimoto és la millor definició operativa que he trobat: «cada cop que trobes que un agent comet un error, dediques el temps a dissenyar una solució perquè no torni a cometre’l mai més».

Fixa’t que el pas 5 no requereix el 6. Pots enginyerar el harness i seguir treballant amb un agent i una sessió. El benefici arriba igual.

El que no delegaràs

Val la pena tenir la llista clara, perquè és la que justifica la teva feina d’aquí a dos anys.

Decidir què es construeix. Cap harness et dirà que la funcionalitat que has demanat no calia. És el mateix criteri que fa que ordenar el procés valgui més que automatitzar-lo: la pregunta prèvia no és tècnica.

El buit semàntic. Aquesta és la limitació que el document remarca i que convé repetir: la convergència estructural no garanteix equivalència de comportament. Dues implementacions estructuralment idèntiques poden contenir errors diferents. El harness et diu que la casa està ben ordenada; no que la instal·lació elèctrica funcioni.

Els compromisos. Que això sigui més ràpid però més fràgil, que aquell disseny sigui més net però demani una dependència més, que valgui la pena o no pagar consistència amb flexibilitat. Els compromisos no tenen resposta correcta i per això no s’imposen amb regles.

El que passa d’aquí a un any. Un agent optimitza la tasca que té davant. Ningú li ha explicat que el mòdul que està escrivint el mantindrà una persona que encara no ha entrat a l’empresa.

Què costa aquest salt

Sense edulcorar, perquè el balanç és el que decideix si t’hi poses.

El harness és feina, i és feina que no es veu. Escriure regles pròpies, mantenir el docs/, arreglar les regles que es contradiuen. No surt a cap demo i no és una funcionalitat. En un equip que mesura per funcionalitats entregades, és la primera cosa que es talla i la que més cara surt de tallar.

Més restriccions, més excepcions. És el compromís central i no té solució, només gestió. Com més complet és el harness, més casos límit demanen excepció explícita, i cada excepció és manteniment permanent. La regla d’OpenAI —fronteres estrictes al centre, autonomia als extrems— és la millor navegació que conec: rigidesa per al que travessa tot el projecte, mà lleugera per als patrons d’un sol domini.

Pots perdre gent pel camí. Un equip acostumat a revisar codi pot viure el canvi com una pèrdua de control. No és una objecció ximple: ho és, de pèrdua de control, i el que hi guanyes a canvi (garanties deterministes en comptes de vigilància) triga a notar-se. Val més dir-ho que dissimular-ho.

No val per a tot. Per a una prova de concepte, un script d’una tarda o codi que llençaràs, tot això és sobrecàrrega pura. El senyal per començar és molt concret, i el repeteixo perquè és el que estalvia diners: quan la mateixa correcció apareix per tercera vegada.

Com aprofitar-ho si ets un equip petit

L’error és mirar el milió de línies d’OpenAI i concloure que això és per a ells. La part que escala cap avall és la que val:

1. Una regla, no un marc. La correcció que més has repetit aquest mes, convertida en porta de CI. Una tarda de feina.
2. Un AGENTS.md de quaranta línies amb els principis innegociables i on és cada cosa. No més.
3. La prova de convergència a CI. Deu línies de bash i saps si les teves regles es barallen.
4. Un registre de correccions. Tres columnes: què vaig corregir, per què va passar, quina regla ho evitaria. Revisar-lo cada quinze dies és el que converteix anècdotes en harness.
5. Revisió creuada de model per als diffs que toquen coses delicades. Zero infraestructura, benefici immediat.

Els cinc punts són d’una tarda cadascun i no requereixen canviar d’eines, de pila ni d’organització.

El que t’has d’endur

La frase amb què tanca el document em sembla la correcta, i no és la que esperaries d’un article sobre automatitzar el control:

El harness no substitueix el criteri humà. L’allibera perquè es dediqui a la semàntica, al disseny i a la intenció.

Aquest és el punt. No es tracta de revisar menys perquè no hi hagi temps: es tracta de deixar de gastar atenció on una màquina dona una resposta binària i millor, per poder-la gastar on cap màquina en dona cap. La variància estructural és un cost. La variància en el criteri, el disseny i la intenció és precisament el que hi aportes.

I si el teu equip encara no té ni linter ni proves a CI, aquest article no va de tu: comença per allà, que el problema no són els agents.