Uncle Bob dice que ya no lee el código que escriben sus agentes (y todos entendieron mal)
Si escribes código con agentes, seguro has escuchado mil veces la misma recomendación: revisa el código que te genera la IA, no confíes ciegamente en lo que produce. Es prácticamente el consejo estándar de la era de los agentes. Pero esta semana alguien muy conocido en el mundo del desarrollo dijo exactamente lo contrario, y el internet explotó.
Ese alguien es Robert C. Martin, mejor conocido como Uncle Bob: autor de Clean Code, coautor del Manifiesto Ágil y la persona detrás de los principios SOLID. Es decir, no es un influencer de vibe coding cualquiera; es alguien que lleva programando desde antes de que existiera el desarrollo web, y mucho antes de que existieran los agentes.
La frase que todos compartieron
Todo empezó como una respuesta a otro programador de la vieja escuela que comentaba que no se sentía cómodo confiando en el código que genera la IA, y que psicológicamente necesitaba revisar todo lo que producía. Uncle Bob le respondió con un post que incluía esta frase:
"Mi estrategia actual es no leer nada del código escrito por mis agentes. Es la única forma de aprovechar su productividad."
Y claro, eso fue lo único que se compartió. En cuestión de horas, medio Twitter estaba repitiendo la idea de "Uncle Bob ya no revisa el código de la IA, ¿por qué tú deberías hacerlo?". El problema es que casi nadie leyó lo que venía después de esa frase, y ahí está todo el contexto.
Lo que realmente está diciendo: TDD
El post no termina en "no leo el código". Continúa explicando que, en lugar de leerlo, rodea a los agentes de restricciones extremas: tests unitarios, tests Gherkin, procedimientos de QA, métricas de calidad, mutation testing, cobertura de tests y más. Su confianza en el código no viene de leerlo, sino de que ese código tuvo que sobrevivir a toda esa batería de verificaciones.
En otras palabras, Uncle Bob no está diciendo "confía al 100% en lo que genera el agente". Está aplicando una metodología que existe desde mucho antes de la IA: Test-Driven Development (TDD).
Para quienes llegaron al desarrollo en la época del vibe coding, esto puede sonar nuevo, pero el TDD se usa desde antes del desarrollo web. La idea es simple:
- Primero escribes los tests. Como todavía no hay código, al ejecutarlos van a fallar.
- Luego escribes el código necesario para que esos tests pasen.
- Refactorizas, vuelves a ejecutar, y si algo falla, iteras: más tests, más código, más refactorización.
Lo que cambia ahora es quién ejecuta el ciclo. Como los agentes escriben código mucho más rápido que los humanos, el tiempo del programador se invierte en definir esas restricciones: escribir tests unitarios, tests de aceptación, criterios de calidad. Cuando Uncle Bob dice que ya no "pierde tiempo" revisando código manualmente, se refiere a que delega la verificación a esa infraestructura de testing, no a que acepta cualquier cosa que salga del agente. De hecho, publicó una lista de repositorios donde está aplicando esta estrategia, y si los revisas, lo que vas a encontrar son justamente los tests.
La reacción: de Hacker News a las paráfrasis
Como era de esperarse, no a todos les cayó bien. En Hacker News aparecieron posts acusándolo de estar promoviendo consultorías de desarrollo automatizado o de estar vendiendo su nuevo material sobre disciplina con agentes. En el fondo, es el disgusto de un grupo de personas que todavía no está conforme con toda esta ola de IA, sumado a que mucha gente aún no entiende bien cómo funcionan los agentes.
Y ese es justamente el problema de este tipo de titulares: cuando una frase se comparte suelta en redes sociales, se entiende mucho peor de lo que realmente es. "Ya no reviso mi código porque mata mi productividad" suena a rendición total; leído en contexto, es la defensa de una metodología con décadas de historia.
Mi experiencia: TDD con IA no es tan bonito como suena
Ahora, opinión personal: a mí el TDD con agentes no me terminó de funcionar. Hace como un año intenté algo similar y, aunque en papel suena muy bien, en la práctica hay un problema evidente: la IA también puede modificar los tests que escribe. Puedes aplicar reglas para evitarlo, pero aun así no es un flujo cómodo.
También vale recordar que hace unos meses se hablaba mucho de otro enfoque: el spec-driven development, que va en la dirección contraria. En lugar de partir de los tests, primero defines las especificaciones o requerimientos del proyecto, y la IA va tomando cada spec y avanzando una por una. Hay proyectos dedicados a esto, como Spec Kit de GitHub, que te da una serie de comandos y skills para implementar cada especificación.
Es decir, hoy tenemos varias formas de escribir código con agentes, y ninguna es realmente nueva. Estas metodologías existían desde antes de la IA; la diferencia es que antes se implementaban con equipos de personas. Había un project manager que elegía la metodología, gente dedicada solo al frontend, otra solo al backend, y para que el código de todos fuera consistente se usaban estas formas de trabajo. En TDD, una persona entraba al proyecto, veía los tests escritos, los ejecutaba, fallaban, y su trabajo era escribir el código que los hiciera pasar. Hoy esa persona es un agente.
El punto que muchos no entienden
Aquí está el detalle de fondo: mucha gente cree que la IA es una especie de software que genera código perfecto. No lo es. Es una máquina que genera texto tras texto, y alguien tiene que ponerle orden a todo lo que produce. Parte de ese orden es, en algún momento, revisar el resultado final.
En mi caso, prefiero un flujo intermedio: dejo que el agente genere el código y lo pruebe por sí mismo. Le doy herramientas de automatización para que abra el navegador y testee su propio trabajo, y cuando pasa sus tests de aceptación, recién ahí hago una segunda revisión manual del código. Y aun así, muchas veces toca volver a iterar.
De esto también viene lo que hace unos meses se popularizó como loop engineering: la idea de que la IA escriba el plan, lo ejecute, verifique, aprenda de los errores y vuelva a iterar por sí misma. No es una técnica nueva de desarrollo; es la búsqueda de que la IA pueda revisar su propio trabajo.
El problema es que, aunque los modelos actuales son mucho mejores que los de hace un par de años, todavía están lejos de darte código 100% confiable. Y ahí hay que distinguir tipos de desarrollo:
- Para frontend, interfaces o aplicaciones comunes (un e-commerce, una landing), los modelos ya están bastante bien y puedes delegar mucho.
- Para software serio —una aplicación de escritorio, un backend complejo con múltiples subsistemas— eventualmente vas a tener que revisar, o al menos entender el mapa general de lo que se ha creado. Una modificación pequeña en estos sistemas no es algo que puedas simplemente "vibecodear": cambiar un flag puede alterar el sistema o borrar una enorme cantidad de datos. Ya hay casos reales de fallas de seguridad descubiertas por cambios así.
El vibe coding sirve para aplicaciones rápidas y pequeñas, que en su mayoría no están pensadas para escalar (principalmente porque quien las crea no sabe cómo escalarlas). La estrategia de Uncle Bob, en cambio, está pensada para proyectos grandes, donde la confianza no viene de leer cada línea sino de la infraestructura de verificación que rodea al agente. Y ese es un matiz importante: su "derecho a no leer el código" se lo ganó construyendo esa infraestructura durante décadas. Copiar el titular sin construir el resto es simplemente vibe coding con exceso de confianza.
En resumen
Lo que pasó esta semana es que mucha gente está descubriendo el test-driven development gracias a que Uncle Bob lo hizo viral con una frase polémica, y las redes sociales hicieron lo suyo: tomar la frase, quitarle el contexto y convertirla en "revisar código ya murió".
Mi recomendación es simple: lean los posts completos antes de replicar el titular. Y si quieren profundizar en TDD con agentes, es un tema que da para un video práctico completo —aunque ya les adelanté que, en mi experiencia personal, no es tan mágico como suena.