En pocas palabras: Según Phillip Mortimer en su charla difundida por InfoQ en agosto de 2026, el código generado por IA es write-only: tan denso que nadie puede leerlo ni modificarlo, ni siquiera su autor. La respuesta no es negarlo, sino cambiar el flujo: tests definen el comportamiento, revisión automatizada y auto-reparación.
Phillip Mortimer planteó algo incómodo en su charla “Complexity and Creativity in Software Engineering” (Complejidad y creatividad en ingeniería de software): el código generado por IA es ilegible, y conviene aceptarlo en vez de negarlo. Sus ideas, publicadas por InfoQ en agosto de 2026, giran alrededor de un concepto viejo con nombre nuevo: el código write-only.
El código write-only es software tan denso, complejo o mal estructurado que nadie puede modificarlo ni comprenderlo, ni siquiera su autor. Mortimer argumenta que los agentes de programación empujan todo el código hacia ese estado, y que la respuesta no es pelear contra eso sino cambiar el flujo de trabajo: los tests definen el comportamiento, las revisiones se automatizan con agentes y el software se auto-repara a partir de alertas de observabilidad.
En 30 segundos
- Todo el código generado por IA es write-only: según Mortimer, es demasiado denso para leerlo, y los tests pasan a definir el comportamiento.
- El código es desechable: muchas veces sale más barato regenerarlo desde cero que depurar lo que ya existe.
- La revisión humana no escala: revisar línea por línea convierte al desarrollador en el cuello de botella del pipeline.
- La salida es automatizar: agentes de revisión corriendo en CI y agentes que reparan bugs a partir de alertas de observabilidad.
- El rol del dev cambia: la implementación queda resuelta; lo que queda es creatividad iterativa, con tiempo y espacio para pensar.
¿Por qué el código generado por IA es ilegible?
Porque los modelos optimizan para que el código funcione, no para que se pueda leer. Ponele que le pedís a tu agente un parser de extractos bancarios: te devuelve trescientas líneas de un tirón, los tests pasan en verde, y vos te quedás mirando una función recursiva de siete niveles tratando de descifrar qué hace. Funciona. Entenderlo es otro tema.
Mortimer se apoyó en una definición clásica de Eric S. Raymond: el código write-only es aquel tan arcano, complejo o mal estructurado que ni su autor puede modificarlo ni comprenderlo. APL y las expresiones regulares ya eran write-only por diseño: densidad extrema a cambio de potencia bruta. Si alguna vez tuviste que mantener una regex de doscientos caracteres escrita por otra persona, sabés exactamente de qué hablamos.
La diferencia con antes es de escala. Antes el código ilegible era la excepción (ese módulo que nadie quería tocar); ahora, con agentes generando buena parte de las líneas en muchos equipos, la excepción se volvió la norma. Por eso Mortimer propone abrazar el principio write-only en vez de fingir que alguien va a leer todo eso.
¿Por qué los tests se convierten en la documentación principal?
Porque cuando el código no se puede leer, los pares entrada-salida son la única especificación confiable de su comportamiento. “Cuando escribís código demasiado denso para leer, la única forma de entender qué hace es a través de casos de prueba extensivos. Los tests se vuelven la documentación de tu código”, explicó Mortimer. Leés qué entra y qué sale, y de ahí reconstruís la intención.
Para quien viene del mundo TDD esto suena a reivindicación tardía. Escribir tests primero siempre fue la jugada correcta; lo que cambió es que dejaron de ser red de seguridad y pasaron a ser el contrato. Si el código va a ser regenerado, borrado y escrito de nuevo, lo único estable entre versiones son esos casos de prueba.
Los tests son la documentación. Sin vueltas.
¿Es mejor reescribir que depurar código generado por IA?
En muchos casos, sí: si el código es denso y los tests son sólidos, regenerarlo desde cero cuesta menos esfuerzo que rastrear un bug dentro de una lógica que nadie entiende. Mortimer lo plantea sin anestesia: el código es desechable. Te quedás con los tests, tirás el código, y lo escribís de nuevo.
El escenario típico: abrís el archivo, buscás la función, la función llama a otra que llama a un helper que nadie sabe de dónde salió, ponés un breakpoint, seguís el flujo veinte minutos, y llegás a la conclusión de que pedirle al agente que lo regenere lleva diez y sale más limpio. ¿Y el conocimiento del dominio que estaba metido en ese código? Se pierde, salvo que esté capturado en los tests. Otra razón para cuidarlos. Lo explicamos a fondo en nuestra guía completa de ChatGPT.
Eso sí, tomalo con pinzas: la ecuación de que reescribir gana depende de la cobertura. Con tests flojos, regenerar es tirarte en paracaídas con una bolsa de plástico. Primero asegurá la red, después borrá con confianza.
¿Cómo revisar código generado por agentes IA a escala?
Automatizando la primera pasada: un agente de revisión corre como acción de CI, con un skill que codifica lo que miraría un desarrollador senior, y puede comentar el PR, pedir cambios o aprobarlo. Como detalla la cobertura de InfoQ, la revisión humana línea por línea no escala: el humano se vuelve el cuello de botella del pipeline muy rápidamente.
Lo contraintuitivo es el review adversarial. Que un modelo revise su propio output suena a que el alumno corrija su propio examen, pero Mortimer asegura haber visto comentarios valiosos y bugs atrapados antes del deploy. El truco parece estar en cambiar el prompt, las instrucciones y el contexto: con suficiente distancia, la revisión aporta. De hecho, esta técnica adversarial ya es común en sistemas agénticos más allá del code review.
Hay una tercera pieza: los agentes “de-slopify” que corren seguido contra el codebase buscando código repetido, tests sin parametrizar, feature flags sin usar y demás deuda de bajo riesgo. Limpieza programada, sin esperar a que alguien abra un PR.
| Estrategia | Qué hace | Cuándo conviene |
|---|---|---|
| Review humano línea por línea | Un dev lee cada cambio | Cambios críticos de seguridad o arquitectura; no escala para el volumen diario |
| Agente de revisión en CI | Comenta, pide cambios o aprueba PRs con criterios senior codificados | Todos los PRs, como filtro automático previo |
| Review adversarial | Otro prompt y contexto revisan el output del modelo | Atrapar bugs antes del deploy; técnica común en sistemas agénticos |
| Agente de-slopify | Busca código repetido, tests sin parametrizar, flags sin usar | Limpieza programada del codebase, ítems de bajo riesgo |
¿Cómo funciona el software que se auto-repara con observabilidad?
Con un bucle simple: un agente escucha tu plataforma de observabilidad, agrupa las alertas de una ventana de tiempo y empieza a abrir pull requests para arreglar lo que vio, empezando por los problemas más frecuentes. Mortimer lo describe como una de las partes más potentes del enfoque agéntico: el sistema detecta sus propios síntomas y propone el remedio. Cubrimos ese tema en detalle en cómo razonan los modelos de lenguaje.
Suena a ciencia ficción. Es ingeniería de pipelines con pasos extra.
¿Y quién aprueba esos PRs? Ahí está la decisión que cada equipo tiene que tomar. Mi consejo: que el agente proponga y un humano (u otro agente con criterios más estrictos) apruebe, al menos hasta acumular confianza. Auto-reparación sin supervisión inicial me parece pedirle demasiado a un modelo que ayer alucinó un import.
¿Por qué se desacopla la intención de la implementación?
Porque la interfaz entre vos y el código pasó a ser lenguaje natural. Describís qué querés, la implementación se genera, y el lenguaje de programación deja de ser una identidad: según Mortimer, eso hace a los desarrolladores portables entre tecnologías. Hoy Python, mañana Rust, pasado Go, con la misma intención de base.
La conclusión de Mortimer es que “todos somos full stack developers”, y medio que me la quiero creer, pero con matices. Describir bien una intención exige entender el dominio, sus bordes y sus casos patológicos; eso sigue siendo oficio técnico. Lo que se desacopla es la mecanización, no el criterio.
¿Cuál es el nuevo rol del desarrollador en la era del código IA?
Creatividad iterativa: mejora paso a paso sostenida durante largos períodos, no un flash de genialidad. Para Mortimer, la implementación está resuelta; lo que queda es pensar bien qué construir y refinarlo con constancia. Y eso exige condiciones que la hipervelocidad de la ingeniería actual está erosionando. Más contexto en el enfoque de Google hacia la IA.
- Tiempo protegido para pensar: Mortimer agrupa sus reuniones al inicio o al final del día para dejar bloques largos de foco, donde trabaja sin interrupciones en problemas difíciles.
- Trabajar en solitario rinde más que el brainstorming: según Mortimer, la técnica favorita del mundo corporativo produce menos buenas ideas que la gente trabajando sola (dato que va a doler en más de una oficina).
- Las restricciones ayudan: en Accelex, la startup de inteligencia documental donde trabajó antes, la falta de tiempo y recursos lo obligó a encontrar soluciones innovadoras para leer datos de tablas.
Nada de esto es nuevo para quien lleva años en el oficio. Lo nuevo es que, con la implementación en manos de los agentes, el tiempo de pensar dejó de ser un lujo y pasó a ser el trabajo.
Errores comunes al adoptar código generado por IA
Antes de cerrar, los tropiezos que más veo (y algunos cometí):
- Depender del review humano como único control: con el volumen que generan los agentes, el revisor se convierte en cuello de botella y termina aprobando en automático. Combiná revisión automatizada con puntos humanos en cambios críticos.
- Regenerar código sin proteger los tests: si tu plan es borrar y rehacer, los tests son la red de seguridad y la especificación. Sin ellos, tirás el comportamiento junto con el código.
- Pedirle al mismo prompt que audite su propio trabajo: el review adversarial funciona cambiando prompt, instrucciones y contexto. Repetir el mismo setup produce revisiones complacientes.
- Encender el auto-healing sin guardrails: un agente que abre PRs sin supervisión puede arreglar un bug y crear otro peor. Arrancá con propuestas revisadas y ampliá la autonomía de a poco.
Preguntas Frecuentes
¿Por qué el código generado por IA es tan difícil de leer?
Porque los modelos priorizan que el código funcione sobre que sea legible: generan soluciones densas, con abstracciones apiladas y estilo inconsistente. Phillip Mortimer lo resume con el concepto write-only de Eric S. Raymond: código que ni su autor puede comprender después de escribirlo.
¿Cómo revisar código generado por agentes IA a escala?
Automatizá la primera pasada con un agente de revisión corriendo como acción de CI, con criterios senior codificados en un skill. Complementá con review adversarial (otro prompt y otro contexto) y agentes de limpieza periódica; reservá el review humano para cambios críticos de seguridad o arquitectura.
¿Es mejor reescribir que depurar código generado por IA?
Cuando los tests son sólidos, sí: mantener los tests y regenerar el código suele costar menos que rastrear un bug en lógica densa. Si la cobertura es débil, reescribir te deja sin red de seguridad; en ese caso conviene depurar o escribir primero los tests que capturen el comportamiento esperado.
¿Qué rol tienen los tests en código generado por IA?
Son la documentación y la especificación: como el código es demasiado denso para leerlo, los pares entrada-salida de los tests indican qué se supone que hace. Sin tests buenos, el código write-only resulta inmantenible, porque no queda ninguna descripción confiable de su comportamiento.
¿Quién es Phillip Mortimer y dónde presentó estas ideas?
Es el ingeniero de software que planteó estas tesis en la charla “Complexity and Creativity in Software Engineering”, difundida por InfoQ en agosto de 2026. Antes trabajó en Accelex, una startup de inteligencia documental, donde las restricciones de tiempo y recursos moldearon su enfoque creativo.
Conclusión
Lo que cambió es el contrato implícito del software: el código dejó de ser el artefacto que se mantiene y pasó a ser un producto intermedio, regenerable, con los tests como fuente de verdad. Para los equipos la traducción es concreta: invertir en calidad de tests, automatizar la revisión antes de que el volumen los aplaste, probar el auto-healing con supervisión y defender el tiempo de foco, que es donde aparece la creatividad que Mortimer pone como centro del oficio. Quien siga revisando todo a mano va a terminar siendo el cuello de botella de su propio pipeline, y no por falta de talento sino por aritmética.
