Cómo auditar código generado por IA sin caer en la trampa del auditor cómplice. Una lección de Spec-Driven Development.
TL;DR — Cuando un agente de IA escribe el código Y otro agente escribe los tests, el sistema tiene un auditor cómplice: aprueba porque conoce las respuestas. Usé Spec-Driven Development (SDD) con el Spec Kit de GitHub para construir el sistema financiero de una fundación, y aún así encontré cinco huecos — tres que movían plata. La lección: el que construye no puede ser el que aprueba, y el que aprueba no puede conocer las respuestas de antemano.
La sorpresa que me hizo desconfiar
Un agente de IA auditó mi código y lo aprobó con 10 sobre 10. Cinco veces seguidas. En vez de celebrar, desconfié — y por eso encontré cinco huecos, tres que movían plata.
Estoy construyendo el sistema que maneja el dinero de una fundación de rescate animal, bajo Spec-Driven Development (el Spec Kit de GitHub): primero el spec con restricciones duras, después el código.
La postura de Uncle Bob y por qué le doy media razón
Viene al pelo un debate de estas semanas: Robert C. Martin — Uncle Bob, el del Clean Code — dijo que ya no lee el código que escriben sus agentes. Su tesis: los humanos somos lentos con el código, y para ser productivos hay que soltarlo y gestionar desde un nivel más alto. En vez de revisar, rodea a la IA de restricciones extremas: tests, métricas, cobertura.
Estoy de acuerdo con la mitad. Las restricciones son necesarias. Pero hay una trampa: ¿quién escribe esos tests? Si los escribe el mismo agente que escribió el código, es un auditor calificando un examen cuyas respuestas él entregó.
El auditor cómplice
Eso me pasó. Mi sistema tiene una regla — nada se borra; si te equivocas, anulas y reescribes —. Levanté cada bloque con un agente y otro lo revisaba con la lista que yo mismo le di. Aprobado, aprobado, aprobado. Cinco bloques perfectos. Un auditor que aprueba todo no es bueno, es ciego.
Traje un segundo agente que no había leído ni el spec ni el código. En una pasada encontró cinco huecos. Tres movían plata: uno dejaba pagar la cuenta de un rescate con la de otro, sin dejar rastro. Ninguno violaba el spec — eran vacíos que el spec nunca decidió.
El límite del spec
Y acá va lo incómodo: quizás yo no sea tan experto como para escribir un spec que no falle. Le dediqué más de mil horas al proyecto y aun así no lo conozco entero — siempre se escapan huecos. Por eso el spec necesita un SSoT que lo sostenga y entender el movimiento completo, no por partes.
El punto: el spec te protege de construir lo equivocado, no de construirlo mal. Y si dejas que el mismo agente escriba las pruebas, no te protege de nada.
Las tres reglas que sostienen el SDD
Mi forma de controlar la etapa que el SDD deja abierta — la implementación:
1. El que construye no puede ser el que aprueba
Separación estricta de roles agente-por-agente.
2. El que aprueba no puede conocer las respuestas de antemano
Un verificador independiente y ciego, no uno con tu misma lista.
3. “Está hecho” no es evidencia
La evidencia es repetir el ataque que rompió el sistema y ver que ya no entra.
La pregunta que te dejo
¿Y vos? Cuando aplicas SDD y la IA genera decenas de diffs en cada bloque, ¿cómo revisas que cada uno cumple de verdad? ¿Cómo controlas esa etapa?
