Ya no revisamos código

Este mes compartí una nota interna con todo el equipo de Plain Concepts. Elegí el titular «ya no revisamos código» a propósito para llamar la atención. Pero el titular es lo menos importante. Lo que importa son las conversaciones que abre una afirmación así, y que por fin hayamos dicho en voz alta algo que todos llevábamos un año viendo venir, aunque nadie tuviera del todo claro cómo iba a llegar.

Quizá lo único que hizo el titular fue hacer visible algo que ya estaba repartido entre todos nosotros, esperando a que alguien lo dijera: ha llegado una nueva forma de construir software, y no se parece exactamente a lo que imaginábamos.

Hasta hace poco, revisar una PR significaba lo de siempre: alguien leía los cambios, dejaba comentarios, la aprobaba y solo entonces el código llegaba a producción. Hoy, en ocho aplicaciones internas que compartimos en toda la empresa, ese paso está desapareciendo. No porque hayamos bajado el listón, sino porque lo hemos subido en otro sitio.

En esas aplicaciones, una gran parte del ciclo (leer la incidencia, escribir el código, ejecutar las pruebas, abrir la PR) ya no la hace una persona, sino un agente de IA con sus propias herramientas y permisos, dentro de los límites que establecemos. Los pasos son los mismos; lo que ha cambiado es quién los da. Y eso nos obliga a replantearnos dónde ponemos la atención humana.

La decisión que tomamos fue esta: la revisión humana deja de ser un control previo a la integración y pasa a ser una capa posterior. Una PR solo se integra si todos sus controles (pruebas, especificación, auditoría, contratos) están en verde. La persona revisa el resultado, no cada línea que lo ha producido.

El motivo no es ir más rápido. El motivo es que, cuando una persona lee los cambios generados por agentes al ritmo al que los agentes los generan, esa lectura deja de ser una señal de calidad. Se convierte en teatro.

Robert C. Martin, Uncle Bob, el autor de Clean Code, el que se pasó veinte años enseñándonos a leer código con lupa, respondió hace poco a un desarrollador que decía que no podía dejar que un agente tocara código que él no entendiera. Su respuesta se hizo viral:

«Empecé a programar a finales de los sesenta. Mi estrategia actual es no leer nada del código que escriben mis agentes. Es la única forma de aprovechar su productividad. Lo que hago, en cambio, es rodear a los agentes de restricciones extremas. Pruebas unitarias, pruebas en Gherkin, procedimientos de control de calidad, métricas de calidad, pruebas de mutación, cobertura de pruebas y mucho más. Al final, tengo mucha confianza en el código que producen porque han tenido que superar todas mis restricciones y pruebas».
— Robert C. Martin, 23 de julio de 2026

Ya lo había dicho en abril, en una respuesta que recibió mucha menos atención: no revisa el código de los agentes; mide la cobertura, la estructura de dependencias, la complejidad ciclomática y la puntuación de mutación, porque «los humanos somos lentos con el código». La de julio, en cambio, generó mucho debate.

Viniendo de él, resulta incómodo. Pero apunta exactamente a lo que ya estábamos construyendo: en lugar de leer el código, diseñar la jaula de pruebas que ese código tiene que superar y dejar que el agente escriba dentro de ella. Si el conjunto de restricciones está bien construido, la calidad deja de depender de que alguien mire cada línea.

Esta es una distinción que tardé un tiempo en ver.

Hay dos cosas a las que llamamos «jaula» y no son lo mismo. La primera es el conjunto de comprobaciones que un cambio tiene que superar antes de entregarse: las pruebas, la puntuación de mutación, los análisis de seguridad, la especificación a partir de la que se ha construido. Eso comprueba el resultado. Le da igual lo bueno que sea el modelo, porque tendría que existir aunque el código lo hubiera escrito una persona.

La segunda es el proceso por el que obligamos al agente a pasar para llegar hasta ahí: qué paso va primero, qué artefacto tiene que producir antes de que le dejemos avanzar al siguiente, qué parte del trabajo es andamiaje para que un modelo poco capaz no se salga del carril. Eso comprueba el camino. Es lo que en inglés se llama el harness del agente: el conjunto de herramientas, permisos, pasos y plantillas que rodea al modelo y le indica por dónde puede moverse. Y, con cada nueva versión del modelo, una parte deja de tener sentido.

La jaula que comprueba el resultado no envejece con los modelos. La que comprueba el camino, sí.

La nuestra es, sobre todo, del primer tipo, aunque no del todo: exigir que cada cambio modifique una especificación es una restricción del camino, y la mantenemos porque la especificación es aquello con lo que se contrasta el resultado. Separar con honestidad nuestros controles es un trabajo que todavía no hemos terminado.

Es tentador leer todo esto como «menos ingeniería, más automatización». Es exactamente lo contrario.

Alguien tiene que delimitar los contextos acotados, decidir las invariantes (lo que nunca puede dejar de cumplirse), escribir la especificación a partir de la que construye el agente y diseñar el conjunto de pruebas que tiene que detectar la regresión antes de que nadie mire el código. Eso es bastante más difícil que escribir el código a mano. Es, de hecho, la ingeniería que antes nos saltábamos, porque siempre había un revisor detrás haciendo de red de seguridad.

Ahora la red de seguridad es el sistema. Y eso significa que el sistema tiene que estar bien construido, o nadie detectará el error. Precisamente ahora, cuando tenemos más capacidad de ingeniería que nunca, es cuando más necesitamos disciplina de ingeniería.

Todo esto suena abstracto hasta que abres una jaula. Así que, en la aplicación en la que tomamos la decisión, la jaula es, a grandes rasgos, así.

Cada cambio empieza con una especificación escrita. Antes de generar una sola línea, hay que describir el cambio: qué hace, qué no puede romper, cómo sabremos que funciona. Si falta o está mal planteada, la compilación falla. Una especificación vaga no produce código malo; produce código bueno para el problema equivocado.

Miles de pruebas en cada cambio. Unas cuatro mil entre la API y la web, y las que acceden a la base de datos se ejecutan contra una base de datos real. Esto es lo que sustituye al ojo del revisor, y necesita ese volumen porque tiene que detectar lo que antes detectaba una persona leyendo.

Rompemos nuestro propio código a propósito para ver si las pruebas se dan cuenta. Se llama pruebas de mutación. No basta con que una línea esté cubierta por una prueba: introducimos pequeños errores deliberados y comprobamos que al menos una prueba falle. Una prueba que se ejecuta pero nunca falla es decoración. Así sabemos que la red funciona de verdad, que es lo único que importa cuando nadie lee el código.

Seguridad en cada compilación, sin tener que pedirla. TruffleHog para detectar secretos filtrados, Trivy para las vulnerabilidades conocidas en dependencias e infraestructura, y Semgrep para los patrones inseguros en el código. Los tres bloquean el proceso. Nada de esto depende de que alguien se dé cuenta, ni debería depender de ello.

Cada compilación sabe lo que contiene. Cada compilación genera con Syft una lista de materiales de software, una SBOM: un inventario completo y legible por máquinas de cada paquete y componente que contiene la aplicación, con su licencia. Un paquete con una licencia que no podemos distribuir se detecta antes de que llegue a un entregable. Además, es lo primero que pide un equipo de seguridad o un auditor, y por eso antes se hacía a mano, una vez, la semana anterior a la auditoría.

Lo que se despliega se vuelve a probar con el sistema en funcionamiento. Tras la integración, el código pasa a un entorno de preproducción y ZAP lo sondea automáticamente como lo haría un atacante, antes de que una persona confirme el paso a producción. La jaula no termina en la integración.

La ingeniería que siempre se posponía ahora se hace. Todos los equipos conocen la lista: restaurar una copia de seguridad para demostrar que funciona, rotar secretos, revisar quién sigue teniendo acceso, comprobar que lo que está en ejecución coincide con lo que está documentado, mantener actualizado el manual de operaciones. Siempre importante, siempre lo primero que pide el auditor, siempre para el próximo trimestre. Una copia de seguridad que nadie ha restaurado es una hipótesis, y una lista de accesos que nadie revisa es un riesgo. Las evidencias de auditoría, que antes eran una carrera de última hora, pasan a generarse como resultado del propio proceso de compilación.

La misma jaula, en forma de lista que puedes copiar y adaptar. Cada elemento bloquea la integración.

1. Especificación. El cambio se describe antes de generar código: qué hace, qué no puede romper, cómo sabremos que funciona. Si falta o está mal planteada, la compilación falla.
2. Pruebas. Unas 4.000 entre la API y la web. Las que acceden a la base de datos se ejecutan contra una real.
3. Puntuación de mutación. Stryker introduce pequeños errores y comprueba que alguna prueba falle. Cada módulo tiene que mantener una puntuación mínima.
4. Secretos. TruffleHog busca credenciales filtradas. Bloqueante.
5. Vulnerabilidades. Trivy analiza las dependencias y el código de infraestructura. Bloquea ante vulnerabilidades críticas y de gravedad alta.
6. Patrones inseguros. Semgrep como herramienta de análisis estático. Bloqueante.
7. SBOM y licencias. Syft inventaría cada componente y una política valida cada licencia en función de lo que podemos distribuir.

Tras la integración hay un control más antes de producción: ZAP sondea el despliegue de preproducción como lo haría un atacante, y solo entonces una persona confirma el paso.

Nada de esto llegó de golpe y nada sale gratis. Casi todas las protecciones de esa lista existen porque algo se coló, o porque vimos cómo podía colarse. Ese es el trato, dicho con honestidad: no dejas de leer código y luego construyes la jaula. Primero construyes la jaula, la sigues manteniendo y, el día que deja de detectar cosas, vuelves a leer código. Saltarse la primera mitad y quedarse solo con la segunda no es lo que estoy describiendo. Eso es, sencillamente, no revisar código.

Nada de esto significa soltar el volante. Sigue habiendo un control de entrada no negociable. Ningún cambio nace de una idea suelta o de un prompt improvisado, sino de un problema descrito y analizado, con criterios de aceptación explícitos. Ahí es donde ponemos el criterio humano: en qué construir y por qué, no en la sintaxis de cómo se construye.

Y hay líneas rojas que el agente no cruza solo: antes de emitir o rotar una credencial o una clave, reescribir el historial compartido o tocar producción, se detiene y pide confirmación a una persona.

La responsabilidad tampoco cambia de sitio. Nadie explica una incidencia en producción diciendo que lo escribió el agente. Decidir no leer cada línea es decidir dónde merece la pena poner la atención, no renunciar a la autoría. Quien integró el cambio sigue respondiendo por él.

Sería fácil terminar con «y por eso necesitas una jaula» y dejarlo ahí. También sería un error. Construimos la jaula pensando en los modelos que teníamos entonces, y los modelos mejoran más rápido que las herramientas que los contienen. Parte de lo que pusimos para que un agente no se saliera del carril ya sobra, y sobrará más. Fingir lo contrario sería el mismo teatro del que me quejaba al principio.

Así que no perdamos la cabeza en ninguna de las dos direcciones. La ingeniería no desaparece: alguien tiene que escribir la especificación, decidir las invariantes y construir las comprobaciones que te dicen si lo que ha salido es lo que se pidió. Esa parte gana importancia a medida que mejoran los modelos, porque es lo único que queda entre un modelo muy capaz y producción.

Lo que se abarata es el harness, todo lo que construimos para mantener al modelo en el camino: el andamiaje, la ceremonia, los pasos adicionales porque un modelo anterior se perdía sin ellos. Cada uno es un barrote que tiene sentido retirar el día que deja de detectar algo, y cuanto antes llegue ese día, mejor: cada barrote que quitas es esfuerzo que vuelve a la ingeniería que importa.

Un control se gana su sitio detectando algo. Si lleva meses sin detectar nada, es un coste, no una protección.

La forma de gestionarlo es la misma con la que construimos la jaula: midiendo. Los controles del resultado seguirán ganándose su sitio durante mucho tiempo. Muchos de los del camino no, y está bien que sea así. Es lo que ocurre cuando los modelos son lo bastante buenos como para que el cuello de botella vuelva a la ingeniería que los rodea.

La revisión ha cambiado de sitio; la responsabilidad, no. Puedes dejar de leer cada diff, pero no puedes dejar de responder por lo que llega a producción. Por eso construir la jaula es ingeniería de verdad, y decidir qué barrotes retirar a medida que mejoran los modelos es la parte que menos dispuesto estoy a delegar.

Nota sobre el uso de IA: Este artículo ha sido elaborado principalmente por el autor, con un uso limitado de herramientas de inteligencia artificial para estructurar el contenido. Todas las opiniones, los análisis y las reflexiones son del autor.