Quan el programador opera agents d’IA: el cost d’aprovar per rutina
De les màquines dels anys setanta als agents d’IA: aprovació rutinària, decisions difícils de reconstruir i supervisió humana amb sentit.
L’agent proposa un canvi. L’explicació sembla raonable. Les comprovacions passen. L’aproves. Després aproves el següent.
No passa res espectacular. Precisament per això costa detectar l’hàbit. A poc a poc, aprovar pot deixar de significar «entenc aquesta decisió» i començar a significar «les últimes decisions van funcionar».
Els programadors hi hauríem de parar atenció. Construïm eines que altres persones fan servir. Amb els agents d’IA, cada vegada més fem servir eines que ajuden a construir les eines següents. Estem assumint una funció de supervisió amb dificultats conegudes molt abans de la IA generativa.
Un problema conegut, cinquanta anys després
El System/370 d’IBM va arribar el 1970 per a aplicacions empresarials i computació centralitzada. Programar i operar un ordinador ja eren responsabilitats diferenciables. Història d’IBM
Imagina el processament de nòmines en un mainframe d’aquella època. El programa s’executa, apareix el resultat i un operador comprova que ha acabat. Una execució normal no demostra, per si sola, que les regles salarials o les dades d’entrada fossin correctes. És un exemple il·lustratiu, no un incident documentat.
Hi ha un equivalent físic. Siemens situa el seu control numèric per ordinador SINUMERIK System 7 el 1976. Història de Siemens
Pensa en una màquina programada per tallar una peça. Seguir la trajectòria indicada i fabricar la peça correcta són preguntes diferents: la preparació, el material i les instruccions continuen important. També és una analogia, no la descripció d’una fallada concreta.
El 1983, Lisanne Bainbridge va explicar com l’automatització industrial podia deixar les persones a càrrec de situacions anormals mentre dificultava la seva funció. Ironies of Automation
La lliçó pràctica que n’extrec resulta incòmoda: que l’operació habitual vagi bé ens diu poc sobre la preparació d’algú per resoldre una fallada desconeguda.
Tres maneres de convertir la revisió en un ritual
No hi ha un únic «efecte de normalització» establert que expliqui tot això. Hi ajuden tres conceptes relacionats.
El biaix d’automatització consisteix a acceptar recomanacions automàtiques malgrat proves contràries. La complaença davant l’automatització consisteix a reduir l’atenció a un sistema que se suposa fiable. Recerca de la NASA
La normalització de la desviació descriu com s’accepten incompliments dels estàndards quan es repeteixen sense danys evidents. Explicació de la NASA
En desenvolupament podrien ser tres moments diferents: confiar en un resum tranquil·litzador de l’agent davant d’un diff preocupant; revisar cada cop amb menys atenció; i finalment acceptar que una revisió obligatòria s’ometi habitualment. Són aplicacions possibles dels conceptes, no resultats d’un estudi sobre aquest flux concret.
No tota aprovació ràpida és descurada. La familiaritat pot ajudar a decidir bé. El problema comença quan l’evidència necessària per aprovar un canvi desapareix silenciosament del procés.
- REVISIÓ — Entenc aquest canvi.
- TRANQUIL·LITAT — Els canvis anteriors van funcionar.
- RUTINA — Aprovar sense reconstruir el perquè.
El programador també es converteix en operador
Seria incorrecte dir que és la primera vegada que els programadors supervisen automatització. Els sistemes de compilació, els processos de desplegament i els generadors de codi són exemples coneguts. Qui construeix i qui opera també fa dècades que comparteixen funcions.
El que em sembla distintiu dels agents és quanta implementació poden proposar entre les nostres intervencions. Un agent pot triar un enfocament, editar diversos fitxers, interpretar un error i proposar un altre canvi. El desenvolupador pot dedicar més temps de la sessió a revisar decisions que no va prendre pas a pas.
Em preocupa que una explicació fluida faci fàcil subestimar aquesta distància. Llegir una explicació plausible i entendre’n les conseqüències són assoliments diferents. L’experiència tècnica continua sent valuosa, però necessita accés a la feina real i temps per examinar-la.
Quan falla, tornen les decisions anteriors
Imaginem un agent que reorganitza un servei de processament de comandes. Canvia la gestió d’identificadors, modifica els reintents i actualitza les comprovacions. El desenvolupador aprova la sèrie després de llegir els resums. Més tard apareix un problema intermitent de comandes duplicades.
Trobar la línia defectuosa pot ser només una part de la feina. Per què es va tractar un identificador com a únic? Es conservava quan es reintentava? Les comprovacions actualitzades encara cobrien el comportament original? Quin canvi va introduir la suposició que ho connectava tot?
El desenvolupador ha de reconstruir la implementació i el raonament visible a les propostes. Si l’agent va canviar una comprovació per adaptar-la a un comportament incorrecte, que passi no aporta tranquil·litat independent.
Jo ho veig com una comprensió ajornada. El temps estalviat en implementar pot convertir-se en temps dedicat a reconstruir el context en recuperar el sistema. És una preocupació d’enginyeria, no una afirmació mesurada que els agents sempre costin més temps. Els bons registres, els canvis petits i les comprovacions independents poden facilitar molt la reconstrucció.
- IDENTIFICADOR — Què volia dir «únic»?
- REINTENT — Es va conservar el mateix identificador?
- COMPROVACIÓ — Validava la regla original?
La intervenció humana ha de continuar tenint sentit
Proposo dissenyar la supervisió al voltant de decisions amb conseqüències, en lloc de convertir cada acció en una altra sol·licitud d’aprovació.
- Canvis prou petits per explicar-los. Aprovar un canvi acotat i els seus supòsits, en lloc d’un conjunt creixent de modificacions sense relació.
- Evidència al costat de la proposta. Mostrar el diff, què es va comprovar, què continua sent incert i els canvis a les comprovacions mateixes.
- Una referència independent. El procés que produeix la implementació no hauria de reescriure tots els requisits i comprovacions existents.
- Un registre per recuperar el context. Conservar accions observables, versions, propostes, resultats i aprovacions. L’explicació de l’agent és una afirmació verificable, no una prova del seu raonament intern.
- Poder aturar-se de debò. Establir límits de permisos i punts de recuperació útils. Ajustar l’autonomia i la càrrega a la capacitat de qui revisa per seguir la feina.
Per a tasques reversibles i de baix risc, una execució automàtica acotada pot ser raonable. Les decisions sobre permisos, significat de les dades o recuperació mereixen atenció deliberada. Demanar aprovació constantment també pot convertir el botó en una rutina.
La recerca sobre intervencions que obliguen a considerar activament una decisió indica que poden reduir la dependència excessiva, encara que afegeixen esforç i no l’eliminen. Buçinca i col·laboradors
- PROPOSTA + EVIDÈNCIA — Diff, supòsits, comprovacions independents.
- CRITERI HUMÀ — Acceptar, revisar o aturar.
- EXECUCIÓ ACOTADA — Abast petit, punts de recuperació i registre.
Sistemes més capaços necessiten decisions comprensibles
Un disseny amb humans al circuit no garanteix l’absència de biaixos. Pot oferir una oportunitat realista de detectar un problema i intervenir-hi. Aquesta oportunitat depèn del que les persones veuen, entenen i poden decidir.
En la meva opinió, una bona automatització hauria de conservar la nostra capacitat d’explicar-ne les accions i recuperar-nos-en. Com més capaços siguin els agents, més intencional ha de ser la supervisió.
Abans d’aprovar el canvi següent, podries explicar què estàs acceptant i per on començaries si fallés demà?
