Human-in-the-Loop: desenvolupar amb IA sense perdre el control
Vaig acabar l'article anterior d'aquesta sèrie amb una pregunta: algun agent de la vostra configuració encara sap coses que no hauria de saber? Aquest tracta d'una fallada relacionada, però diferent: no de què sap un agent, sinó de quan l'atureu per revisar la seva feina.
L'automatització no ha d'implicar perdre el control. Però la manera com la majoria configura els seus punts d'aprovació acaba donant una sensació de control sense que aquest control sigui realment efectiu.
El punt de control al qual vaig deixar de prestar atenció
Després d'afegir passos d'aprovació entre cada etapa d'un pipeline, vaig notar una cosa incòmoda: feia clic a «tot bé» més ràpid del que hauria pogut llegir el diff.
Hi havia punts de control pertot arreu: després de l'especificació, després de la implementació, després de la verificació i, de vegades, després de modificar un sol arxiu. Revisar-los tots com cal hauria estat una feina a temps complet, així que, sense decidir-ho conscientment, vaig començar a mirar-me'ls per sobre. Després, ni això. Simplement aprovava, perquè el pipeline estava esperant i jo tenia altres coses a fer.
Sobre el paper, aquella configuració no tenia res d'insegur. En cada pas hi intervenia una persona. Però un punt de control que ningú revisa de debò no és supervisió: és un tràmit disfressat de revisió. En certa manera, és pitjor que no tenir cap punt de control, perquè genera una falsa sensació de seguretat: jo creia tenir control sobre el que arribava a producció, però no era així.
Quan deixar que l'agent avanci sol
No tots els passos mereixen un punt de control que obligui a aturar-se i esperar. L'autonomia té sentit quan un error és poc costós, reversible i fàcil de detectar a posteriori: executar una bateria de proves, aplicar un formatador, fer una refactorització que ja segueix una especificació i un patró aprovats o fer qualsevol canvi que una comprovació de CI detectaria igualment si s'escapés.
Posar un punt de control en aquests passos no afegeix seguretat. Afegeix una fricció que us acostuma a deixar de prestar atenció, que és exactament el que em va passar a mi.
Quan insistir a aturar-lo
Els passos que mereixen un punt de control real són aquells en què equivocar-se surt car, és difícil de revertir o costa de detectar més endavant. Aprovar una especificació abans d'implementar-la deixa fixats els seus supòsits. També mereixen una pausa els canvis que afecten dades de producció, qualsevol feina que estigueu a punt de presentar com a acabada a una altra persona i les decisions d'arquitectura en què es basarà la feina posterior.
La regla que aplico és senzilla: multipliqueu el cost d'equivocar-vos per com de tard descobriríeu l'error. Si qualsevol dels dos factors és alt, mereix un punt de control real. Si tots dos són baixos, el punt de control és totalment inútil.
Què vol dir «revisar de debò»
Aquesta és la prova que faig ara abans d'aprovar res: puc explicar en una frase per què aquest resultat concret és correcte? No n'hi ha prou amb dir «sembla que està bé»; he de saber per què compleix el que es demanava.
Si no puc formular aquesta frase, no estic revisant, sinó limitant-me a donar el vistiplau. Normalment, això indica que el punt de control és al lloc equivocat, no que jo m'hagi d'esforçar més: o bé el pas no mereix cap punt de control o bé agrupa massa coses per revisar-les de debò d'una sola passada.
Pocs punts de control presos seriosament són millors que molts d'ignorats
Quan alguna cosa surt malament, el primer impuls sol ser afegir un altre pas d'aprovació. Normalment, aquesta no és la solució. Com més punts de control hi ha, més es dispersa la vostra atenció, i aquesta falta d'atenció és precisament el que fa que un punt de control sigui prescindible.
La millor solució és tenir menys punts de control i col·locar-los bé: allà on equivocar-se té un cost real. I cal dedicar a cadascun l'atenció que mereix, en lloc de fer clic sense pensar. Agrupeu les aprovacions trivials o ometeu-les del tot. Reserveu la revisió minuciosa per als moments en què realment pot canviar el resultat.
Conclusió
L'objectiu mai no va ser que l'agent decidís en lloc meu. L'objectiu és que treballi dins d'un sistema en què jo continuï controlant les decisions que importen de debò i els punts de control del qual reflecteixin amb honestedat quines són aquestes decisions.
Un pipeline en què intervé una persona a cada pas no és necessàriament més segur que un altre amb menys punts de control, però més ben definits. Només ho és si aquesta persona hi presta atenció de debò.
En el pròxim article d'aquesta sèrie parlaré del que passa quan aquesta disciplina es relaxa: Code Slop and AI-Generated Technical Debt — com reconèixer un resultat que va superar tots els punts de control i que, tot i així, no era realment bo.
Fins llavors, la pregunta que val la pena fer-se sobre la vostra pròpia configuració no és:
Tinc una persona al bucle?
És:
L'última vegada que vaig aprovar alguna cosa, hauria pogut explicar per què estava bé?
Si heu trobat una manera de col·locar els punts de control que de debò us funciona, m'agradaria saber on els poseu. No dubteu a escriure'm.