La escena del aprendiz de brujo en Fantasía sigue siendo una de las mejores metáforas sobre automatización.
Mickey no falla porque la escoba no funcione. Falla porque funciona demasiado bien. Le delega una tarea, la escoba obedece, el trabajo se multiplica y el problema deja de ser cargar agua. El problema pasa a ser cómo detener lo que ya fue acelerado.
Con los agentes de código empieza a pasar algo parecido.
Durante años, una parte importante del costo de desarrollo estuvo en escribir código. Traducir una decisión técnica en implementación tomaba tiempo: entender el dominio, navegar el repositorio, escribir, probar, romper cosas, corregir y revisar.
Los agentes de IA reducen esa fricción de forma importante. Pueden generar tests, refactors, endpoints, migraciones, scripts, documentación, componentes y explicaciones en una fracción del tiempo.
Eso es útil. Muy útil.
Pero también mueve el cuello de botella.
Si antes el límite estaba en producir código, ahora empieza a estar en revisar, validar, entender y asumir responsabilidad por ese output.
Y esa parte no escala igual.
Revisar código ya era difícil
Un buen review nunca ha sido solamente mirar si el código “se ve bien”.
Revisar bien exige contexto. Hay que entender qué problema se está resolviendo, qué tradeoffs se hicieron, qué deuda se está aceptando y qué impacto puede tener el cambio en seguridad, performance, mantenibilidad y operación.
También exige criterio. A veces la pregunta importante no es si el cambio funciona, sino si debería existir de esa forma.
Eso ya era difícil cuando el output humano venía limitado por tiempo, energía y coordinación. Un equipo podía escribir más o menos a la velocidad a la que también podía discutir, revisar y corregir.
Los agentes de código rompen parte de ese equilibrio.
Un equipo puede recibir más PRs, más rápido, con explicaciones razonables, tests generados y diffs que parecen ordenados a primera vista. El cambio compila. El modelo justifica sus decisiones. La descripción suena profesional.
Y se vuelve tentador aprobar.
Ahí aparece el AI brain fry.
Qué es el AI brain fry
AI brain fry no es un término académico. Es una forma práctica de nombrar la fatiga cognitiva que aparece cuando un equipo tiene que auditar demasiado output plausible generado a velocidad industrial.
No es simplemente cansancio.
Es el desgaste de revisar una secuencia de cambios que parecen razonables, vienen bien explicados y requieren atención real para detectar dónde está el problema. Cada PR puede parecer manejable por separado. El daño aparece en acumulación.
Un cambio toca un borde del dominio.
Otro introduce una abstracción que parece limpia, pero no encaja del todo.
Otro genera tests que validan el comportamiento esperado, pero no el riesgo real.
Otro refactor deja el código más ordenado localmente, pero más difícil de operar globalmente.
Nada de eso necesariamente se ve como un incendio en el momento. Muchas veces se ve como progreso.
Ese es el punto incómodo: el brain fry no aparece porque el output sea obviamente malo. Aparece porque el output es suficientemente coherente como para exigir revisión seria.
La mente técnica queda atrapada entre dos costos:
- revisar con profundidad todo lo que produce el sistema;
- aceptar que parte de lo generado entrará con una revisión superficial.
El primero no escala. El segundo acumula riesgo.
La aprobación por fatiga
Cuando el volumen sube, el review empieza a cambiar de naturaleza.
Al principio el equipo revisa con intención. Lee el diff, entiende el contexto, cuestiona decisiones, pide cambios y valida supuestos.
Después, si la presión se mantiene, aparece una dinámica más peligrosa: aprobación por fatiga.
No porque el equipo sea irresponsable. No porque no le importe la calidad. Sino porque la atención es finita.
Después de revisar suficientes cambios plausibles, el criterio empieza a buscar atajos. Se confía más en que los tests pasaron. Se lee más rápido la explicación del agente. Se asume que si el cambio es pequeño, probablemente está bien. Se aprueba porque no hay una señal clara para detenerlo.
Y en sistemas reales, muchas decisiones malas no vienen con una señal clara.
Vienen disfrazadas de decisiones razonables.
Una función nueva que duplica una regla de negocio en vez de reutilizarla.
Una migración que funciona, pero deja un camino difícil para rollback.
Un test que cubre el caso feliz y aumenta la sensación de seguridad.
Un refactor que mejora nombres, pero cambia el ownership implícito de una parte del sistema.
Una dependencia que resuelve el problema inmediato, pero abre un riesgo operativo que nadie pidió revisar.
La aprobación por fatiga es peligrosa porque no se siente como negligencia. Se siente como velocidad.
El equipo sigue avanzando. Los PRs se cierran. El tablero se mueve. El output crece.
Hasta que el sistema empieza a cobrar las decisiones que nadie revisó con suficiente calma.
Output no es avance
Una de las trampas de los agentes de código es que hacen más visible una confusión clásica en tecnología: actividad no es progreso.
Más commits no significan mejor producto.
Más líneas no significan mejor arquitectura.
Más PRs no significan más avance.
A veces solo significan más superficie que revisar, más decisiones implícitas que descubrir y más deuda potencial entrando al sistema con una presentación más elegante.
El riesgo tampoco es que la IA escriba código malo todo el tiempo. Eso sería relativamente fácil de detectar.
El riesgo más incómodo es que escriba código suficientemente bueno como para pasar una revisión superficial, pero no suficientemente bueno como para sostener el sistema seis meses después.
Ese tipo de problema no siempre explota en el demo. Explota cuando el equipo ya construyó encima.
Y por eso el AI brain fry no debería tratarse como un problema individual de concentración. No se resuelve solo pidiéndole al equipo que “revise mejor”.
Si el sistema produce más decisiones técnicas de las que el equipo puede absorber, el problema es de diseño operativo.
El cuello de botella se mueve a la validación
La respuesta obvia sería revisar más.
Pero revisar más no escala si el sistema está diseñado para producir mucho más de lo que el equipo puede validar con criterio.
Cuando la generación se vuelve barata, el trabajo técnico cambia. La pregunta deja de ser solamente “¿cómo producimos más rápido?” y empieza a ser “¿cómo evitamos aceptar cambios que no entendemos completamente?”.
Esto requiere diseñar límites operativos para los agentes.
Límites como:
- qué partes del repositorio puede tocar un agente;
- qué tipos de cambio requieren revisión humana obligatoria;
- qué refactors necesitan diseño previo;
- qué pruebas deben existir antes de abrir o aprobar un PR;
- qué métricas operativas importan después del merge;
- quién mantiene ownership real del cambio;
- qué deuda técnica no entra, aunque el PR se vea correcto.
También requiere separar tipos de trabajo.
No es lo mismo pedirle a un agente que genere un test faltante que pedirle que reestructure un módulo central.
No es lo mismo producir documentación que cambiar reglas de negocio.
No es lo mismo corregir un bug acotado que tocar una migración irreversible.
La utilidad de los agentes aumenta cuando el entorno les pone bordes claros. Sin esos bordes, la productividad aparente puede convertirse en una fábrica de decisiones sin dueño.
La pregunta importante no es solo “¿qué tan rápido podemos generar código?”.
La pregunta importante es “¿qué mecanismos tenemos para detenernos a tiempo?”.
Diseñar límites es arquitectura
En muchos equipos, la gobernanza de IA suena a burocracia: permisos, políticas, checklists, compliance.
Pero en desarrollo de software, diseñar límites no es papeleo. Es arquitectura.
Un buen límite puede ser tan concreto como restringir a un agente a ciertos directorios. O separar tareas de generación de tareas de decisión. O impedir que un agente mezcle refactor con feature. O exigir ADRs para cambios estructurales. O hacer que los tests no sean opcionales, sino parte del contrato de trabajo.
También puede significar cambiar el flujo de review.
Por ejemplo: no todos los cambios generados por IA deberían llegar al mismo carril. Algunos pueden validarse con pruebas automáticas y revisión ligera. Otros deberían requerir explicación de diseño, ownership explícito y validación posterior en producción.
Un buen sistema no trata todo output como igual.
Clasifica riesgo.
Define umbrales.
Reduce superficie.
Hace que ciertas decisiones sean difíciles de tomar por accidente.
Y, sobre todo, evita que la revisión humana se convierta en una cinta transportadora infinita.
También hay un componente cultural: que el equipo entienda que “lo hizo la IA” no es una explicación técnica ni una transferencia de responsabilidad.
El agente puede proponer. Puede acelerar. Puede explorar. Puede reducir fricción.
Pero no vive con las consecuencias del sistema.
El equipo sí.
Antes de inundar la torre
Los agentes de código van a quedarse. Usarlos tiene sentido. Ignorarlos por purismo no es una estrategia especialmente útil.
Pero usarlos bien requiere dejar de pensar solo en generación y empezar a pensar en control.
No control como miedo.
Control como criterio.
La escena de Fantasía funciona porque no habla realmente de escobas. Habla de una tentación muy humana: automatizar algo antes de entender cómo gobernarlo.
Ese es el punto con los agentes de código.
El problema no es cargar agua.
El problema es no inundar la torre.