Cuando el programador opera agentes de IA: el coste de aprobar por rutina
De las máquinas de los años setenta a los agentes de IA: aprobación rutinaria, decisiones difíciles de reconstruir y supervisión humana con sentido.
El agente propone un cambio. La explicación parece razonable. Las comprobaciones pasan. Lo apruebas. Después apruebas el siguiente.
No ocurre nada espectacular. Precisamente por eso cuesta detectar el hábito. Poco a poco, aprobar puede dejar de significar «entiendo esta decisión» y empezar a significar «las últimas decisiones funcionaron».
Los programadores deberíamos prestar atención. Construimos herramientas que otras personas manejan. Con los agentes de IA, cada vez más manejamos herramientas que ayudan a construir las siguientes herramientas. Estamos asumiendo una función de supervisión cuyas dificultades eran conocidas mucho antes de la IA generativa.
Un problema conocido, cincuenta años después
El System/370 de IBM llegó en 1970 para aplicaciones empresariales y computación centralizada. Programar y operar un ordenador ya eran responsabilidades diferenciables. Historia de IBM
Imagina el procesamiento de nóminas en un mainframe de aquella época. El programa se ejecuta, aparece el resultado y un operador comprueba que ha terminado. Una ejecución normal no demuestra, por sí sola, que las reglas salariales o los datos de entrada fueran correctos. Es un ejemplo ilustrativo, no un incidente documentado.
Existe un equivalente físico. Siemens sitúa su control numérico por ordenador SINUMERIK System 7 en 1976. Historia de Siemens
Piensa en una máquina programada para cortar una pieza. Seguir la trayectoria indicada y fabricar la pieza correcta son preguntas distintas: la preparación, el material y las instrucciones siguen importando. También es una analogía, no la descripción de un fallo concreto.
En 1983, Lisanne Bainbridge explicó cómo la automatización industrial podía dejar a las personas a cargo de las situaciones anormales mientras dificultaba su función. Ironies of Automation
La lección práctica que extraigo resulta incómoda: que la operación habitual salga bien nos dice poco sobre la preparación de alguien para resolver un fallo desconocido.
Tres formas de convertir la revisión en un ritual
No existe un único «efecto de normalización» establecido que explique todo esto. Ayudan tres conceptos relacionados.
El sesgo de automatización consiste en aceptar recomendaciones automáticas pese a pruebas contrarias. La complacencia ante la automatización consiste en reducir la atención a un sistema que se supone fiable. Investigación de la NASA
La normalización de la desviación describe cómo se aceptan incumplimientos de los estándares al repetirse sin daños evidentes. Explicación de la NASA
En desarrollo podrían ser tres momentos diferentes: confiar en un resumen tranquilizador del agente frente a un diff preocupante; revisar cada vez con menos atención; y finalmente aceptar que una revisión obligatoria se omita de forma habitual. Son aplicaciones posibles de los conceptos, no resultados de un estudio sobre este flujo concreto.
No toda aprobación rápida es descuidada. La familiaridad puede ayudar a decidir bien. El problema empieza cuando la evidencia necesaria para aprobar un cambio desaparece silenciosamente del proceso.
- REVISIÓN — Entiendo este cambio.
- TRANQUILIDAD — Los cambios anteriores funcionaron.
- RUTINA — Aprobar sin reconstruir el porqué.
El programador también se convierte en operador
Sería incorrecto decir que es la primera vez que los programadores supervisan automatización. Los sistemas de compilación, los procesos de despliegue y los generadores de código son ejemplos conocidos. Quienes construyen y quienes operan también llevan décadas compartiendo funciones.
Lo que me parece distintivo de los agentes es cuánta implementación pueden proponer entre nuestras intervenciones. Un agente puede elegir un enfoque, editar varios archivos, interpretar un error y proponer otro cambio. El desarrollador puede dedicar más tiempo de la sesión a revisar decisiones que no tomó paso a paso.
Me preocupa que una explicación fluida haga fácil subestimar esa distancia. Leer una explicación plausible y entender las consecuencias son logros distintos. La experiencia técnica sigue siendo valiosa, pero necesita acceso al trabajo real y tiempo para examinarlo.
Cuando falla, vuelven las decisiones anteriores
Imaginemos un agente que reorganiza un servicio de procesamiento de pedidos. Cambia la gestión de identificadores, modifica los reintentos y actualiza las comprobaciones. El desarrollador aprueba la serie después de leer los resúmenes. Más tarde aparece un problema intermitente de pedidos duplicados.
Encontrar la línea defectuosa puede ser solo una parte del trabajo. ¿Por qué se trató un identificador como único? ¿Se conservaba al reintentar? ¿Las comprobaciones actualizadas seguían cubriendo el comportamiento original? ¿Qué cambio introdujo la suposición que conectaba todo?
El desarrollador tiene que reconstruir la implementación y el razonamiento visible en las propuestas. Si el agente cambió una comprobación para adaptarla a un comportamiento incorrecto, que esa comprobación pase no aporta tranquilidad independiente.
Yo lo veo como comprensión aplazada. El tiempo ahorrado al implementar puede convertirse en tiempo dedicado a reconstruir el contexto al recuperar el sistema. Es una preocupación de ingeniería, no una afirmación medida de que los agentes siempre cuesten más tiempo. Los buenos registros, los cambios pequeños y las comprobaciones independientes pueden facilitar mucho la reconstrucción.
- IDENTIFICADOR — ¿Qué significaba «único»?
- REINTENTO — ¿Se conservó el mismo identificador?
- COMPROBACIÓN — ¿Validaba la regla original?
La intervención humana debe seguir teniendo sentido
Mi propuesta es diseñar la supervisión alrededor de decisiones con consecuencias, en vez de convertir cada acción en otra solicitud de aprobación.
- Cambios suficientemente pequeños para explicarlos. Aprobar un cambio acotado y sus supuestos, en lugar de un conjunto creciente de modificaciones sin relación.
- Evidencia junto a la propuesta. Mostrar el diff, qué se comprobó, qué sigue siendo incierto y los cambios en las propias comprobaciones.
- Una referencia independiente. El proceso que produce la implementación no debería reescribir todos los requisitos y comprobaciones existentes.
- Un registro para recuperar el contexto. Conservar acciones observables, versiones, propuestas, resultados y aprobaciones. La explicación del agente es una afirmación verificable, no una prueba de su razonamiento interno.
- Poder detenerse de verdad. Establecer límites de permisos y puntos de recuperación útiles. Ajustar la autonomía y la carga a la capacidad de quien revisa para seguir el trabajo.
Para tareas reversibles y de bajo riesgo, una ejecución automática acotada puede ser razonable. Las decisiones sobre permisos, significado de los datos o recuperación merecen atención deliberada. Pedir aprobación constantemente también puede convertir el botón en una rutina.
La investigación sobre intervenciones que obligan a considerar activamente una decisión indica que pueden reducir la dependencia excesiva, aunque añaden esfuerzo y no la eliminan. Buçinca y colaboradores
- PROPUESTA + EVIDENCIA — Diff, supuestos, comprobaciones independientes.
- CRITERIO HUMANO — Aceptar, revisar o detener.
- EJECUCIÓN ACOTADA — Alcance pequeño, puntos de recuperación y registro.
Sistemas más capaces necesitan decisiones comprensibles
Un diseño con humanos en el circuito no garantiza la ausencia de sesgos. Puede ofrecer una oportunidad realista de detectar un problema e intervenir. Esa oportunidad depende de lo que las personas ven, entienden y pueden decidir.
En mi opinión, una buena automatización debería conservar nuestra capacidad de explicar sus acciones y recuperarnos de ellas. Cuanto más capaces sean los agentes, más intencional debe ser la supervisión.
Antes de aprobar el siguiente cambio, ¿podrías explicar qué estás aceptando y por dónde empezarías si fallara mañana?
