Dejemos la careta educada: el juicio nunca fue un cuello de botella nuevo en la ingeniería de software. Es el más viejo que existe. Lo que cambió es que los agentes de codificación con IA nos quitaron la excusa de que escribir el código era la parte difícil, así que ahora la parte en la que siempre hemos sido mediocres — decidir si un trozo de código realmente merece existir en producción — está ahí, desnuda, sin dónde esconderse.

Fíjate en la historia de Grok Build de este mes. xAI liberó como open source el harness y la interfaz de terminal detrás de la herramienta, dejando que cualquiera inspeccione cómo arma el contexto y despacha las llamadas a herramientas, lo cual es una transparencia genuinamente útil. Pero ese lanzamiento llegó después de reportes de que el asistente había estado subiendo más datos del repositorio de los que cualquier tarea concreta requería, con la empresa prometiendo borrar datos de clientes que un investigador encontró guardados en su almacenamiento en la nube. Tradúcelo a términos de un equipo PHP: tu composer.lock, tu .env.example que alguien olvidó que en realidad no está en el gitignore, tus seeders de base de datos llenos de datos de prueba con pinta realista, las credenciales de tu espejo privado de Satis o Packagist. El open source te dice que el código se puede leer. No te dice nada sobre qué hace una versión alojada de ese código con tu árbol de archivos en cuanto la apuntas hacia tu repositorio.

Aquí va el contraargumento honesto, y no creo que sea un hombre de paja: muchos equipos PHP dirán "bueno, simplemente limita lo que el agente puede leer y escribir". Suena simple hasta que recuerdas cómo es en realidad un monorepo Laravel o Symfony heredado de verdad: migraciones al lado de fixtures sembradas al lado de un directorio de config que carga secretos calladamente desde tres sitios distintos según el entorno. Trazar un límite limpio de lectura/escritura alrededor de ese desorden es, en sí mismo, una tarea de ingeniería genuina, no una casilla que marcas en el panel de configuración de tu agente.

Ahora la parte que debería preocuparte de verdad más que cualquier escándalo de manejo de datos. Un preprint de julio hizo que 86 programadores de Python juzgaran afirmaciones de test generadas por IA: identificaron correctamente las correctas el 74% de las veces, pero solo detectaron las incorrectas el 49% de las veces — cara o cruz — mientras reportaban la misma confianza en ambos casos. Es un preprint, trata los números como preliminares, pero la forma del hallazgo suena verdadera para cualquiera que haya revisado un PR generado por un agente lleno de formato PSR-12 impecable, relaciones Eloquent plausibles y un mensaje de commit confiado que explica exactamente qué "arregló". El código fluido se lee como código correcto. Esa es la trampa, y no le importa en qué lenguaje escribas.

Entonces, ¿qué haces realmente con eso? El artículo original propone cuatro límites antes de elegir una herramienta — contexto, autoridad, evidencia, aprobación — y creo que ese instinto es correcto pero necesita dientes más afilados para nosotros específicamente. La evidencia no puede significar solo un PHPUnit en verde. Una suite de tests que pasa no va a detectar un cálculo de IVA sutilmente equivocado, y desde luego no va a detectar la consulta N+1 que un agente metió, que se ve bien en una base de datos de desarrollo sembrada con doce filas y que tres semanas después derrite tus workers de cola al 90% de CPU contra datos de producción reales. Si tu barra de evidencia es "los tests pasan", no tienes ninguna barra.

También empujaría un poco contra la idea de que esto es principalmente un problema de elegir herramienta — Claude Code contra Cursor contra Codex contra Grok Build. Un mejor harness montado sobre un equipo sin una cultura real de revisión es solo una capa de pintura más bonita sobre la misma fuga. Los equipos que van a sacar ventaja real de estos agentes no son los que tienen la interfaz de permisos más elegante, son los que ya sabían cómo llevar una revisión de código rigurosa antes de que nada de esto existiera, y ahora están aplicando esa misma disciplina a una manguera mucho más rápida de diffs.

En la práctica, eso significa clasificar tu propio flujo de trabajo por nivel de riesgo en lugar de tratar cada PR generado igual. Un agente rediseñando un componente de landing page de marketing puede pasar por una revisión ligera. Un agente que toca tu lógica de facturación, tu middleware de autenticación, o cualquier cosa que escriba en una tabla de libro mayor necesita tests de contrato, un segundo humano, y honestamente una buena dosis de sospecha sin importar cuán segura suene su explicación — porque la confianza, según ese preprint, es exactamente la señal en la que no puedes confiar.

Así que aquí va mi pregunta real para ti, no una retórica: ¿tu equipo ha trazado límites reales sobre qué puede tocar un agente de codificación en tu repositorio, o ahora mismo estás confiando en un pipeline de CI en verde como toda tu red de seguridad? Me gustaría saber de verdad cómo es tu puerta de revisión cuando el volumen de PRs del agente se multiplica por diez, porque la mía todavía es un trabajo en progreso.