🔥 Polémica
La verdad sobre las fábricas de software con IA que los gurús no quieren que sepas
OpenAI tiene una "fábrica de software" llamada Symphony. StrongDM promete una donde ningún humano lee código. Ramp, Stripe y WorkOS presumen que el 75% de su código ya lo escriben agentes de IA.
Suena increíble, ¿verdad? Código gratis, 10x más rápido, sin code review. El problema es que la realidad es exactamente la opuesta.
Los números que nadie quiere mostrar
Faros AI publicó un análisis de cientos de equipos que adoptaron herramientas de AI coding desde enero. Los resultados son alarmantes:
- Incidentes por Pull Request: +242.7% — sí, leíste bien, más del doble
- Incidentes mensuales totales: +57.9%
- Bugs por desarrollador: +54%
- PRs que se fusionan sin revisión: 31.3% — casi uno de cada tres
Más comentarios en los PRs, comentarios más largos, y montones de PRs aprobándose sin que nadie los haya leído. La calidad del código no solo no mejoró: se derrumbó.
La gran mentira del "código gratis"
La narrativa dominante en 2026 es simple: "tú eres el cuello de botella, los modelos son suficientemente buenos, el código es gratis, solo envía más cosas". Ryan Lopopolo de OpenAI lo llamó "harness engineering" y su equipo construyó Symphony para demostrarlo.
Pero Dex, fundador de HumanLayer y autor del artículo original que inspiró esto, lo probó en serio. Su equipo implementó una fábrica completamente automatizada en julio 2025. Tres meses después, su sitio se cayó. Los usuarios estaban furiosos. Y él pasó dos semanas excavando en un codebase lleno de "espagueti de Claude".
"La tercera vez que pasó, decidimos que era más fácil reescribir todo desde cero", cuenta. Su cofundador pasó dos semanas escribiendo código a mano en VS Code, ni siquiera Cursor.
¿Por qué los modelos generan código basura?
Aquí está el meollo del asunto: los benchmarks con los que se entrena a los modelos de coding no penalizan el mal diseño.
SWE-bench Multilingual, el estándar de la industria, asigna 1 o 0: ¿pasaron los tests? Sí → 1. No → 0. No importa si el código es mantenible, si tiene try-catches alrededor de cada línea, si las abstracciones son un desastre.
Como dice el artículo original: "no hay penalización por erosionar la mantenibilidad del código".
Un test te da feedback en segundos. Pero el costo de una mala arquitectura se mide en semanas, meses o años. Aparece la primera vez que alguien abre un archivo para un cambio de una línea y descubre que no puede hacerlo en una línea — porque el código está tan acoplado que hay que modificar once archivos y esperar que nada explote.
Claude Code: el elefante en la habitación
Claude Code pasó de cero a ~$9,000 millones en ingresos anuales en menos de un año. Es el producto de AI coding más exitoso de la historia. ¿Su secreto? Anthropic entrenó al modelo con RL dentro del propio harness: la primera vez que un laboratorio entrena un modelo contra las herramientas exactas con las que se va a enviar.
Pero incluso Claude Code tiene el mismo problema fundamental: los modelos son buenos resolviendo problemas puntuales, pero no mejorando la calidad del código base con el tiempo. La brecha entre "resolver un issue" y "mantener un codebase saludable por 12 meses" es enorme.
El mito del "skills issue"
¿Te ha pasado que usas un AI coding agent y los resultados son mediocres? Los gurús te dirán que es un "skills issue" — que necesitas gastar más tokens, mejores prompts, "context engineering" avanzado.
Pero no es un skills issue. Es un problema fundamental del modelo.
No importa cuántos linters configures ni cuántos "adversarial reviewers" agregues a tu pipeline: si el modelo no fue entrenado para producir código mantenible, no lo va a producir. Punto.
Dex lo dice claro: "ninguna cantidad de harness engineering o loopsmaxxing puede resolver lo que es fundamentalmente un problema de entrenamiento del modelo".
¿Qué funciona entonces?
El autor del artículo original no es un detractor de la IA. Al contrario: cree que se puede ir 2-3x más rápido sin quemar el codebase. La clave:
- Planificación previa: 30 minutos de diseño ahorran horas de code review. Documento de producto, arquitectura, diseño de programa, slices verticales.
- Code review humano: sí, todavía hay que leer el código. No hay atajo.
- Slices verticales: en vez de "migraciones → servicios → API → frontend" (horizontal), construir una funcionalidad completa de principio a fin e iterar.
- El 80/20: ~40% de las tareas se pueden mandar al agente en one-shot. El resto necesita supervisión humana.
No tienes demasiados PRs. Tienes demasiados PRs malos.
El futuro: ¿habrá solución?
Hay esfuerzos interesantes: SWE-Marathon con tareas de ~400 horas, Frontier Code de Cognition que penaliza a los modelos por escribir tests que no fallan, DeepSWE que evita contaminación de datos de entrenamiento.
Pero mientras el RL no tenga una forma rápida y confiable de medir mantenibilidad, los modelos seguirán generando slop a escala industrial.
La próxima vez que alguien te diga que su "software factory" te hará 10x más rápido sin sacrificar calidad, recuerda: el que no lee el código, termina leyendo incidentes.
🔥 Dato final: El primer concepto de "software factory" nació en una conferencia de la OTAN en 1968. 58 años después, seguimos intentando automatizar lo que no se puede automatizar: el buen juicio.
Comparte esto si crees que la calidad del código todavía importa — antes de que tu codebase favorito termine en llamas.