📰 Uncle Bob ya no revisa el código que escriben sus agentes

Si hay alguien a quien no le pegaba decir “ya no miro el código antes de que se suba a producción”, ese es Robert C. Martin, más conocido en el mundo del desarrollo como Uncle Bob y autor de Clean Code, el libro que durante casi veinte años ha sido la referencia obligada sobre cómo escribir software mantenible. Pues bien, acaba de decir exactamente eso. En una publicación que se hizo viral entre programadores, confirmó que ya no revisa manualmente el código que escriben sus agentes de Inteligencia Artificial. En su lugar, confía en un puñado de métricas automáticas para decidir si ese código vale o no.

Qué ha dicho exactamente Uncle Bob

La cita, publicada en su cuenta de X el pasado 14 de abril, dice así:

“I don’t review code written by agents. I measure things like test coverage, dependency structure, cyclomatic complexity, module sizes, mutation testing, etc. Much can be inferred about the quality of the code from those metrics. The code itself I leave to the AI. Humans are slow at code. To get productivity we humans need to disengage from code and manage from a higher level.”

Traducido: no revisa el código escrito por agentes. Mide cobertura de tests, estructura de dependencias, complejidad ciclomática, tamaño de los módulos, mutation testing… y de esas métricas infiere si el código es bueno. El código en sí se lo deja a la Inteligencia Artificial. Su argumento de fondo es que los humanos somos lentos escribiendo código y que, para ganar productividad de verdad, tenemos que desengancharnos de él y gestionar desde un nivel más alto.

Para el autor de un libro cuya premisa entera es que el código lo tienen que leer personas, esto no es un matiz menor. Es, básicamente, dar la vuelta a la tesis central de su propia obra.

El “gauntlet”: el filtro que sustituye a sus ojos

Martin no ha dicho que el código de sus agentes circule sin control. Lo que ha cambiado es quién lo controla y cómo. Su sistema, que algunos medios han bautizado como un “gauntlet” (una especie de carrera de obstáculos), reparte el trabajo así:

Código de implementación: lo escribe el agente. Nadie lo revisa línea a línea, por diseño.
Tests unitarios: también los escribe el agente, y tampoco se revisan manualmente.
Tests de aceptación en Gherkin: los escribe el agente, pero Martin los revisa, con un rigor variable según el proyecto.
Procedimientos de QA: igual, escritos por el agente y revisados por él mismo cuando lo considera necesario.
Pruebas manuales finales: las hace Martin en persona, de forma puntual, a modo de comprobación de humo.

Encima de todo eso coloca lo que él mismo llama “restricciones extremas”: límites de tamaño en las funciones, umbrales de complejidad, exigencias mínimas de cobertura de tests, todo verificado automáticamente en cada integración. Su razonamiento es casi de sentido común para cualquiera que haya trabajado con estas herramientas: “el código desordenado ralentiza a mis agentes. Los he visto enredarse en sus propios líos sin resolución”. Si el código de partida es limpio y las restricciones son estrictas, el agente tiene menos margen para meter la pata, y menos margen todavía para acumular deuda técnica que luego ni él mismo sepa desenredar.

Por qué lo defiende: productividad, no pereza

La lectura fácil de todo esto es “Uncle Bob ha dejado de currar”. La lectura que él defiende es la contraria: dice que revisar código a mano es precisamente lo que frena la productividad que promete la Inteligencia Artificial. Si un desarrollador tiene que leer cada línea que genera un agente, el cuello de botella sigue siendo humano, y entonces da igual lo rápido que escriba el agente. Su apuesta es que, si las métricas de calidad están bien elegidas y las restricciones son lo bastante duras, se puede inferir la salud del código sin necesidad de leerlo entero.

Es una apuesta con sentido en un contexto muy concreto: proyectos con una cobertura de tests altísima, una arquitectura ya madura y restricciones automatizadas desde el primer commit. Extrapolarlo a cualquier proyecto con una base de código mediocre y tests flojos es harina de otro costal, y ahí es exactamente donde entran sus críticos.

Grady Booch responde: “ningún agente tiene el contexto para saber eso”

No todo el mundo se lo ha tomado bien. Grady Booch, uno de los creadores del UML y una de las figuras con más autoridad histórica en ingeniería del software, respondió públicamente con un enfoque radicalmente distinto:

“Unlike Bob, I review all code generated by agents. Test coverage and similar metrics will give me confidence of functionality, but they offer me no confidence whatsoever that those agents have not introduced vulnerabilities…”

Y añadió:

“Trust but verify. As an experienced developer, I know the smell of what is good and what is not. And no agent has either the experience or the context to know those things.”

El argumento de Booch es concreto, no una simple defensa de la tradición por la tradición: la cobertura de tests y la complejidad ciclomática te dicen que el código funciona para los casos que has probado. No te dicen si un agente ha colado una vulnerabilidad de seguridad, si ha dejado código muerto que va a degradar silenciosamente el mantenimiento futuro, o si se ha saltado una refactorización que importaba de cara al rendimiento. Ese es, según recoge la cobertura del tema, el núcleo del debate que ha corrido por foros y redes de desarrolladores durante los últimos meses: las métricas cuantifican lo que ya sabes medir, pero no sustituyen el “olfato” de alguien que ha visto suficiente código bueno y código malo como para reconocer la diferencia a simple vista.

La comunidad, partida en dos

La reacción del resto de programadores ha sido tan polarizada como cabía esperar. Un sector defiende que Martin simplemente ha evolucionado su flujo de trabajo como haría cualquier desarrollador senior con tres décadas de experiencia: automatiza lo que se puede automatizar y dedica su atención a lo que de verdad importa. El otro sector es bastante más duro, y llega a describir el resultado como “slop” (código basura generado sin criterio), acusando a Martin de haber quedado desfasado respecto a lo que realmente hace falta para mantener software seguro a largo plazo.

Algunos críticos han ido más allá y cuestionan directamente la utilidad de las métricas que Martin dice usar: sostienen que la cobertura de tests o la complejidad ciclomática, tomadas de forma aislada, dicen tan poco sobre la calidad real de un sistema como contar cuántas veces aparece la letra “e” en el código fuente. Es una exageración deliberada, pero apunta al mismo sitio que la crítica de Booch: una métrica no es un sustituto de comprender lo que hace el código.

El propio Uncle Bob ha matizado su postura

Lo interesante es que ni siquiera Martin se ha quedado en la versión más extrema de su propio mensaje. En intervenciones posteriores reconoció que aplicar todo el arsenal de pruebas (unitarias, de aceptación, mutation testing, QA completo) a cualquier tarea es excesivo:

“Just because we can do them doesn’t mean we actually should. Lots of times I just use unit tests and crap.”

Dicho de otra forma: el “gauntlet” completo lo reserva para lo que de verdad lo necesita, y para el resto del trabajo del día a día tira de lo básico. Ese matiz suele perderse en los titulares más llamativos, pero es importante para entender que su postura no es “no reviso nunca nada”, sino “elijo dónde merece la pena mirar y dónde no”.

Qué significa esto si trabajas con agentes de Inteligencia Artificial en tu equipo

Más allá de la polémica entre dos figuras conocidas del sector, el debate señala una pregunta muy práctica para cualquier equipo que ya esté metiendo agentes de Inteligencia Artificial en su flujo de desarrollo: ¿dónde pones el límite entre lo que automatizas y lo que sigue necesitando ojos humanos? La respuesta de Martin funciona en un contexto muy concreto, con tests exhaustivos y restricciones automáticas ya maduras. Sin esa base, aplicar el mismo criterio a ciegas es exactamente la receta que Booch señala como peligrosa: vulnerabilidades que ninguna métrica de cobertura va a detectar.

Si tu empresa está evaluando cómo meter agentes de Inteligencia Artificial en el proceso de desarrollo sin perder el control de la calidad, puedo ayudarte a definir dónde automatizar y dónde no.

Preguntas frecuentes

¿Quién es Uncle Bob y por qué es relevante lo que dice?

Uncle Bob es el apodo de Robert C. Martin, autor del libro Clean Code (2008), una de las obras más influyentes sobre buenas prácticas de programación. Que sea precisamente él quien afirme que ya no revisa el código manualmente contradice la premisa central de su propio libro, y por eso la afirmación ha generado tanto debate.

¿Qué métricas usa Uncle Bob en lugar de revisar el código a mano?

Cobertura de tests, estructura de dependencias, complejidad ciclomática, tamaño de los módulos y mutation testing, todo verificado automáticamente en cada integración. Además impone restricciones estrictas de tamaño y complejidad para que el código de partida sea limpio.

¿Qué opina Grady Booch sobre este enfoque?

Grady Booch, cocreador del UML, discrepa abiertamente: revisa todo el código que generan sus agentes porque considera que las métricas dan confianza sobre si el código funciona, pero no dicen nada sobre si un agente ha introducido una vulnerabilidad, código muerto o un problema de rendimiento.

¿Uncle Bob ha dejado de revisar código en todos los casos?

No exactamente. En intervenciones posteriores matizó que el conjunto completo de pruebas y restricciones lo reserva para el código que de verdad lo necesita, y que para el trabajo del día a día suele bastar con tests unitarios básicos.

Fuentes

Compártelo si te ha resultado útil, sobre todo si en tu equipo ya estáis discutiendo dónde poner el límite con los agentes de Inteligencia Artificial.

¿Tú revisas el código que genera la Inteligencia Artificial línea a línea, o confías en los tests como Uncle Bob? Cuéntame.

Y… el debate seguirá dando guerra un buen tiempo.