La edición abierta · miércoles 23 de septiembre 2026
No leer el código que escribe tu agente de IA puede costarte cinco meses de producto
Un equipo de agentes de código dejó de leer lo que su IA producía y confió solo en los planes durante 4 a 5 meses, hasta que el producto quedó tan roto que lo reescribieron entero a mano. Un benchmark nuevo, SlopCodeBench, muestra por qué: los modelos apenas mejoraron de 14,8% a 16,3% en mantener sano un código base con el tiempo, muy por debajo de lo que sacan en pruebas de codificación sueltas. La lectura para quien construye con IA: el plan no reemplaza la revisión, sobre todo en las decisiones de arquitectura tempranas.
Dex Horthy, CEO y cofundador de HumanLayer, contó esta semana en el podcast AI Native Dev que su equipo corrió un experimento de desarrollo casi a ciegas: en vez de leer el código que escribía su agente, leían solo el plan -un archivo de pocas centenas de líneas en markdown- y confiaban en que la implementación seguía esa intención. Lo sostuvieron entre 4 y 5 meses. Cada cambio nuevo generaba una regresión en otro lado, el producto se volvió cada vez más lento de tocar, y terminaron reescribiéndolo desde cero: las primeras dos semanas las hizo a mano uno de los cofundadores, tipeando carácter por carácter la arquitectura de datos.
Estamos viendo la misma señal en varios lugares esta semana: la conversación sobre agentes de código dejó de ser cuánta autonomía darles y pasó a ser qué parte conviene revisar siempre. Nos llamó la atención que ya existe un benchmark específico para medir justamente esto -no si un modelo escribe código correcto una vez, sino si puede mantener sano un código base a través de pedidos sucesivos- y los números todavía son bajos. Leemos esto como el cierre de una fase: la promesa de programar con las luces apagadas no murió, pero se achicó mucho frente a lo que se vendía hace un año.
Señal 01 · El caso
Por qué confiar solo en el plan le rompió el código a un equipo de agentes
Cuando salió Claude Opus 4 con el Claude Agent SDK, a mediados de 2025, HumanLayer -entonces una startup de tres personas- adoptó el desarrollo guiado por especificaciones que impulsaba Sean Grove, investigador de OpenAI: la idea de que el plan es el nuevo código fuente, igual que hoy compilamos Java a un .jar y no versionamos el binario. En la práctica, el equipo escribía planes con los diffs completos, dejaba que el agente ejecutara y evitaba leer el resultado.
El problema no fue solo de calidad de código: fue arquitectónico. Al dejar que el modelo también decidiera el diseño del sistema, terminaron con seis servicios separados -una app de escritorio en Rust que hablaba por socket Unix con un demonio en Go, que lanzaba sesiones de agente, que llamaban a servidores MCP para las aprobaciones, que escribían en SQLite por el mismo socket- un diseño que nadie en el equipo podía depurar con confianza.
La falla no fue que la IA escribiera mal código puntual. Fue que revisar el plan en lugar del código deja pasar el desvío entre lo planeado y lo implementado, hasta que el sistema queda ilegible incluso para quien lo pidió.
El benchmark que mide si la IA mantiene sano un código, no si lo escribe bien una vez
Se llama SlopCodeBench y lo arma un laboratorio de la Universidad de Wisconsin. En vez de una tarea de código aislada, le entrega al modelo una base real, le pide una funcionalidad, después otra, y otra más, evaluando si el código se mantiene ordenado a medida que se acumulan los pedidos. Horthy citó que GPT-5.5 sacó 14,8% en mayo, y que en la primera corrida de un modelo más nuevo el resultado subió a 16,3%.
Son números bajos frente a lo que esos mismos modelos sacan en benchmarks de codificación tradicionales, donde ya superan el 70-80%. La razón que da Horthy: no existe un chequeo rápido para la mantenibilidad. No te enterás de que un código quedó difícil de tocar hasta dos meses después, así que no hay forma fácil de entrenar a un modelo para que la priorice.
Mientras la escritura de código mejora rápido, la propiedad que más le importa a un negocio real -que el código siga siendo modificable dentro de seis meses- mejora mucho más lento. Es la brecha que paga más caro quien construye solo, sin nadie más revisando por detrás.
La mitad de los que ya usan IA para todo su código la sigue leyendo línea por línea
Horthy contó que en una cena en San Francisco, unas seis semanas antes de esta entrevista, alguien preguntó cuántos tenían IA escribiendo el 100% de su código: todas las manos arriba. Después preguntó cuántos todavía leían ese código: la mitad se mantuvo arriba. En HumanLayer, hoy con unas 20 personas en ingeniería, volvieron a revisar código, pero cambiaron qué revisan: lo que se propaga hacia adelante -esquema de datos, arquitectura inicial- se lee siempre; lo chico y reversible -el color de un botón- se suelta sin revisión.
En paralelo corren cada noche, por cron y por integración continua, cinco agentes de mantenimiento -el mismo motor con un prompt distinto cada uno- que buscan patrones que el equipo no quiere ver repetirse en el código. Cada mañana ya dejan entre 4 y 5 pull requests que mejoran el código base en una dimensión específica.
El patrón que se está asentando no es revisar todo ni no revisar nada: es separar lo irreversible, que se lee siempre a mano, de lo reversible, que se automatiza con chequeos deterministas corriendo solos. Es una regla operativa, no una postura sobre cuánto confiar en la IA.
Venimos registrando esta tensión hace más de una semana: el 14 de septiembre marcamos que explicarle bien la tarea a la IA no alcanzaba para que el código resultante fuera sólido, y el 21 de septiembre notamos que armar un agente propio se volvió prácticamente gratis, lo que vuelve más urgente la pregunta de quién revisa lo que ese agente termina produciendo. El caso HumanLayer es la primera vez que vemos ese costo puesto en meses concretos, no en líneas de código sueltas.
Si estás construyendo tu producto con un agente de código, separá desde ahora qué decisiones son irreversibles y cuáles no. El esquema de tu base de datos, qué librería de autenticación usás, cómo se comunican tus servicios entre sí: esas las leés vos, línea por línea, la primera vez que el agente las propone, no en el resumen del plan sino en el código final. El color de un botón, el copy de un error, el orden de los campos de un formulario: eso se puede soltar sin revisión y corregir después con un prompt más.
El lunes, además de leer, sumale a tu proyecto un chequeo que corra solo: pedile a tu agente una regla simple que detecte el patrón que más veces tuviste que corregirle a mano en las últimas semanas -código duplicado, un servicio llamando a otro que no debería, una función que ya creció demasiado- y que la corra cada vez que termina una tarea, no una vez por mes. Sale más barato prevenir mil veces el mismo error que reescribir el producto dentro de cinco meses.
La movida del día
Elegí hoy las 2 o 3 decisiones de arquitectura de tu proyecto que no vas a delegar sin leer el código resultante. Armá un chequeo automático, aunque sea casero, para el patrón de error que más se repite en tu código. Y la próxima vez que aceptes un plan completo sin mirar lo que produjo, anotá la fecha: es el dato que después te va a decir cuánto tardaste en confiar de más.
¿Qué es SlopCodeBench?
Es un benchmark de un laboratorio de la Universidad de Wisconsin que no mide si un modelo escribe una función correcta una sola vez, sino si puede mantener sana una base de código real a través de una serie de pedidos de funcionalidades sucesivos. Según los datos citados por Dex Horthy (HumanLayer), la mejora es lenta: de 14,8% con GPT-5.5 en mayo de 2026 a 16,3% en una corrida posterior con un modelo más nuevo.
La edición abierta lee el mundo. La tuya lee TU mundo — tu industria, tus proyectos, tus objetivos — y llega a tu casilla cada mañana. Nadie más recibe tu edición.
