O: el arnés no es suficiente
Actualización: la versión en charla de este artículo ya está en YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M
bueno, parece que ya estamos en loops
Todos estamos compitiendo por poner la codificación con IA en producción. Se ha hablado mucho sobre la ingeniería de loops, y la sabiduría predominante es que probablemente deberíamos escribir más loops.
StrongDM escribió sobre su fábrica de software sin intervención humana donde ningún humano lee código y ningún humano escribe código.
La narrativa va más o menos así:
- Tú eres el cuello de botella.
- Los modelos ya son suficientemente buenos.
- El código es gratis.
- Solo hay que enviar más cosas.
Ryan Lopopolo de OpenAI escribió sobre esto en febrero y dio una charla en abril sobre la fábrica de software de OpenAI, Symphony.
Todas estas personas son increíblemente inteligentes y les tengo un montón de respeto. Pero la interpretación más cínica aquí sería llamar a esto otra excusa para bombear más dinero de capital de riesgo al cañón de basura.
esto está... yendo
Nuestro amigo Mario se levantó en AI Engineer Europe y nos rogó que frenáramos -- porque empresas que no deberían tener interrupciones por errores de agentes de codificación, bueno... están teniendo interrupciones por errores de agentes de codificación.
Como dijo Matt Pocock, las bases de código se están desmoronando más rápido que nunca.
No he podido encontrar datos o conclusiones definitivas de StrongDM sobre cómo resultó esa fábrica oscura. El informe meteorológico tiene algunas actualizaciones dispersas entre febrero y junio de este año. edit - hay algo de conversación con el equipo en Hacker News el 23 de julio - ¡parece que pronto podríamos tener una actualización más formal!
La gente de Faros AI publicó un informe: desde que todos2 adoptamos estas herramientas de codificación con IA en enero y febrero, la calidad de la revisión de pull requests ha bajado mucho.
- Más comentarios, comentarios más largos, y montones de PRs fusionados sin ninguna revisión.
- Los incidentes han aumentado considerablemente.
- Los errores por desarrollador han aumentado considerablemente.
Este informe es más una señal de correlación que una prueba irrefutable (sí, elegí esa palabra a propósito, no me hagan empezar con la prosa de Claude), y todo el punto de este artículo es desconfiar de los datos basura, pero se siente direccionalmente válido según lo que he visto.
"Lo estás sosteniendo mal" (no es cierto)
Mucha gente te dirá que esto es un problema de habilidad: que si no obtienes buenos resultados, es tu culpa.
Pero sin importar cómo elijas... eh... sostenerlo, te garantizo que te están diciendo que si el token-maxxing no te funciona, es un problema de habilidad. Solo necesitas gastar más tokens. Deja de leer el código. Y si apenas estás llegando, te prometo que es parte del progreso. Yo también pensaba así el verano pasado.
Lamentablemente para mi ego, algunas tonterías que decidí decir sobre "cómo sostenerlo mejor" fueron grabadas y ahora tienen alrededor de un millón de vistas acumuladas en YouTube. No intento presumir aquí, comparto esto solo para establecer que he estado profundizando en las mejores formas de usar agentes de codificación durante mucho tiempo y he descubierto algunas cosas que muchos otros han encontrado genuinamente útiles.
- Advanced Context Engineering for Coding Agents
- No Vibes Allowed -- Solving Hard Problems in Complex Codebases
- Everything We Got Wrong About RPI
De todos modos, La promesa de toda esta charla en línea de "solo tokeniza más duro" que hemos tenido que soportar es, en resumen: con suficiente ingeniería de arnés, podemos obtener lo mejor de ambos mundos:
- 10 a 100 veces más rápido,
- alta calidad, y
- nadie tiene que hacer nunca esa cosa que todos odiamos llamada revisión de código
Todo lo que tenemos que hacer es configurar más linters y esparcir algunas palabras mágicas como "revisión adversarial" en suficientes bots de revisión de PR, y nuestro software se construirá felizmente sin incidentes.
Esto no es un problema de habilidad
Lo que voy a intentar convencerte es que ninguna cantidad de ingeniería de arnés o loopsmaxxing puede resolver lo que es fundamentalmente un problema de entrenamiento del modelo.
Para abordar esto, tuve que profundizar en cómo se entrenan y evalúan realmente los modelos de codificación, tanto en el lado de RLVR como en el de los benchmarks.
En este artículo voy a repasar:
- Las fábricas de software se remontan a 1968, ¿cómo han evolucionado y cómo las ha cambiado la IA?
- Por qué los modelos pueden generar montañas de basura a pesar de sobresalir en los benchmarks (incluso los nuevos benchmarks de "frontera")
- A pesar de esto, puedes avanzar bastante rápido sin incendiar tu base de código
Voy a intentar atravesar el hype de cada plugin de habilidades que emerge diariamente y la pandemia de consejos de psicosis de IA y tokenmaxxing, y hablar en términos generales sobre los tipos de cosas que funcionan sin hacer referencia a ninguna habilidad o marco en particular.
Versión en video: este artículo se basa (y expande) mi keynote en AI Engineer World's Fair 2026.
Gracias a @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, y @jeffreyhuber por sus comentarios en este artículo.
Un inciso: esto no tiene nada que ver con vibe coding
Addy Osmani desenredó algo que vale la pena destacar:
Un desarrollador haciendo vibe coding de un proyecto secundario que una docena de personas ejecutarán, y un equipo manteniendo vivo un sistema empresarial de diez años por un trimestre más, no comparten casi ninguna restricción que valga la pena nombrar, y la mayoría de los consejos en circulación son realmente uno de esos dos diciéndole al otro cómo vivir.
Si amas el vibe coding, por favor, sigue vibrando. Yo todavía vibreo muchas cosas, pero también mantengo mucho software de producción (y a través de HumanLayer, ayudo a miles de otros ingenieros a hacer lo mismo), así que el resto de esto está dirigido a personas que resuelven problemas difíciles en bases de código complejas.
Escucho la palabra brownfield mucho para hablar de esta división. Históricamente se refería a algo de Java de hace diez años, pero al ritmo al que podemos enviar ahora, parece que una base de código construida por agentes comienza a tener problemas después de tres a seis meses -- empiezas a ir más lento, y la forma en que abordas agregar cosas nuevas tiene que cambiar.
Una breve historia de la fábrica de software
He estado construyendo y estudiando fábricas de software durante toda mi carrera, pero solo aprendí esto recientemente: el término se remonta a una conferencia de la OTAN en 1968 -- la misma que nos dio "ingeniería de software".
Lo único más que me parece súper interesante desde entonces es que el Departamento de Defensa de EE.UU. escribió un PDF de 31 páginas sobre cómo el DoD necesita empezar a usar Jenkins mejor o algo así.
La fábrica de software de 2022
Aterricemos nuestra definición de "fábrica de software" alrededor de 2022, justo antes de la IA. En una fábrica de software típica:
- Las personas deciden qué construir -- ingenieros, PMs, liderazgo impulsando la visión
- Va a un rastreador -- Linear, Jira, lo que sea: una máquina de estados de lo que hay que hacer
- Alguien toma un ticket y lo construye -- probablemente hace algunas pruebas manuales/automatizadas mientras lo hace
- Pull request -- verificaciones automatizadas, un humano revisa el código, quizás alguien lo descarga para probarlo
- ¿Algo mal? Volver a "alguien construye la cosa"
- Enviar a producción -- y hace contacto con los usuarios
- Agregar monitoreo -- hay toda una industria construida alrededor de despertar a un ingeniero a las 3 a.m. cuando algo se rompe
- Los usuarios se quejan -- piden cosas, encuentran errores, solicitan funciones → vuelven al equipo para agregar al rastreador
Y así sucesivamente. Aún no hemos llegado a la IA, y ya hay varios loops en esta imagen.
alineación previa a la carga
Hay algo que los equipos descubrieron hace décadas: construir lleva horas o días, y lo mismo la revisión.
Por eso precargamos el trabajo -- planificación, propuestas de arquitectura, sprint planning -- juntos, como equipo. Eso significa:
- menos retrabajo, porque nos alineamos antes de que alguien escribiera código
- menos tiempo revisando cada línea, si alguna vez has leído un PR largo pero bien hecho, sabes lo rápido que va la revisión cuando está casi perfecto
Volveremos a esto más tarde; veamos qué sucede cuando introduces la codificación de agentes en la imagen.
La fábrica de software con agentes
Ahora cada empresa y su madre --
ha pasado la mayor parte de este año explicando cómo construyeron una fábrica de agentes que envía alrededor del 75% de su código.
La fábrica de agentes se parece principalmente a intercambiar "alguien construye la cosa" → "un agente construye la cosa" -- hay cosas aquí como orquestación, un arnés, un sandbox, un modelo, uso de computadora, etc. No entraré en detalles sobre esos porque francamente estoy harto de leer sobre eso y estoy seguro de que tú también.
Cuando el agente construye la cosa:
- Construir pasa de horas o días a minutos u horas.
- La revisión aún toma horas o días. Un humano todavía tiene que leer el código y probar el cambio. Así que la revisión es ahora el cuello de botella.
Entonces aceleras la revisión también:
- Revisión de código con agentes, para detectar estilo, errores, seguridad.
- Pruebas de regresión con agentes, para probarlo desde afuera con navegadores y uso de computadora y quizás enviarte un lindo videíto cuando termine.
La revisión es más rápida ahora, pero probablemente sigue siendo el cuello de botella. Pero podemos hacer más loops.
Luego puedes enrutar incidentes a la fábrica. En lugar de despertar a alguien a las 3 a.m., se despiertan con un PR que quizás ya lo corrige.
También podemos enrutar los comentarios de los usuarios a la fábrica. La gente pide cosas, se construyen.
En ese punto, el trabajo son dos preguntas: ¿cuánto puedes meter en la cola, y qué tan rápido puedes revisar y probar lo que sale?
Lo que nos lleva a la fábrica de software sin intervención humana.
La fábrica de software sin intervención humana
Dan Shapiro acuñó este término y Simon Willison escribió sobre la implementación de StrongDM -- donde ya no leemos el código.
Miras tu hermosa fábrica de software. Está arruinada por ese molesto paso de revisión de código y dices: ¿sabes qué? ¿Eso de que un humano lea cada cambio? No, gracias.
Así que lo eliminas y pones el esfuerzo en otro lugar:
- Invertir en pruebas y dejar que el agente pruebe su propio trabajo
- Invertir en sandboxes y orquestación
- Invertir en revisión automatizada
- Invertir en monitoreo
- Invertir en despliegue
- Invertir en recopilar señales de retroalimentación de los usuarios
Y ahora el trabajo realmente es solo una pregunta: ¿cuántas cosas podemos pedirle al agente que construya? ¿Cuánto del océano queremos hervir?
Esto va a ir genial (no, no va)
Voy a plantear algo potencialmente controvertido: la fábrica sin intervención humana no funciona.
Analicemos por qué fallan las fábricas de software.
Lo intentamos
En julio de 2025 nos fuimos completamente sin intervención humana. Solo lee las especificaciones y los tickets, agentes de fondo para todas las cosas pequeñas/medianas, todo el asunto.
Si ya lo has intentado seriamente durante unos meses, ya sabes cómo termina. Encuentras al menos un problema lo suficientemente espinoso que el agente no puede resolver -- incluso con tus indicaciones y flujos de trabajo más avanzados.
- Haces una investigación profunda con contexto, recopilando todas las partes correctas en la zona inteligente para que el modelo las analice
- Haces que el agente intente reproducirlo de 10 maneras diferentes
Eventualmente tienes que armarte de valor y adentrarte en la base de código que dejaste de leer hace tres meses, tratando de descubrir qué está roto.
Y mientras tanto:
- Tu sitio estaba caído.
- Tus usuarios estaban enojados.
- Y tú, si eres algo como yo, estabas miserable -- leyendo todo el código basura que dejaste colar en tu sistema.
La primera vez que nos pasó esto, lo dejé pasar. A pesar de que acababa de pasar casi dos semanas excavando en espaguetis de Claude, "el riesgo negativo valía la velocidad". Para la ~tercera vez en noviembre, decidimos que sería más fácil reescribir desde cero, y mi cofundador pasó dos semanas enteras en VS Code (ni siquiera Cursor) cableando todos los patrones a mano.
los modelos degradan la calidad de la base de código con el tiempo
A lo que quiero llegar es esto: los modelos tienen una limitación. No pueden mantener y mejorar la calidad de la base de código con el tiempo, no sin una cantidad decente de dirección humana.4
Cuando digo mantenibilidad, me refiero a esa cosa específica donde se vuelve realmente, realmente difícil cambiar una parte de la base de código sin romper otra. Esto es la cirugía de escopeta de Martin Fowler.
No voy a decir mucho más sobre mantenibilidad. Hay un montón de libros que puedes leer al respecto:
- John Ousterhout's A Philosophy of Software Design
- Robert C. Martin's Clean Code
- Martin Fowler's Refactoring
Entonces, ¿por qué los modelos no pueden hacer mantenibilidad de software?
"Pero seguro que los modelos han mejorado desde entonces"
Llegado a este punto, quizás te mueres por decir: pero Dex, seguro que los modelos han mejorado mucho desde julio
Lo han hecho -- en algunos aspectos. En otros, siguen más o menos igual.
- ¿Resolver problemas puntuales, o hacer vibe coding de un nuevo sitio de marketing? Sí. Mucho mejor.
- ¿Mejorar la calidad de la base de código con el tiempo? No mucho mejor, hasta donde puedo decir.
No puedo probar esto. Tú tampoco puedes. No hay buenos benchmarks para la capacidad de un modelo de mantener la calidad de la base de código. (Más sobre hacia dónde va eso después.)
NO HAY BUENOS BENCHMARKS para la capacidad de un modelo de mantener la calidad de la base de código
Pero si has trabajado con agentes de codificación por un tiempo -- y mucha gente está publicando exactamente sobre esto -- probablemente ya tienes la sensación: tienden a empeorar las cosas con el tiempo, y hacen que la base de código sea más difícil de trabajar.
Así que para entender por qué sucede esto, quiero alejarme hasta el primer gran agente de codificación.
Claude Code ganó gracias al Aprendizaje por Refuerzo dentro del arnés
Claude Code pasó de nada a ~$4B -- ahora algo así como ~$9B -- en ingresos en menos de un año.
Lo cual es un poco loco, porque ya había excelentes agentes CLI. aider, cline, codebuff -- todos precedieron a Claude Code, todos con ingeniería de contexto genuinamente excelente incorporada, todos con el mismo conjunto de herramientas que podrías atribuir a Claude Code: leer, escribir, editar, grep, bash. Los usé. Eran buenos. Pero también, el uso de herramientas a veces... fallaba -- lo veías forcejear con la misma edición tres veces y abrías tu editor de nuevo para hacerlo tú mismo.
El artículo SWE-Agent de 2024 describe cómo pequeños cambios en la forma de la herramienta hacen diferencias notables, por ejemplo, incluir números de línea en los resultados de ReadFile, o cambiar una herramienta de Editar de buscar/reemplazar a ediciones por rango de líneas.
Luego Claude Code se lanzó y se disparó verticalmente bastante rápido. Puedes descartar esto como distribución, pero la explicación canónicamente aceptada es que Claude Code ganó porque era mejor, y que era mejor porque Anthropic aplicó RL al modelo dentro del arnés -- la primera vez que un laboratorio entrenó un modelo contra las herramientas exactas con las que lo iban a enviar. Y se volvió realmente, realmente bueno en llamar a esas herramientas en un bucle de agente.
Una cosa es jugar con las definiciones de herramientas y evaluaciones hasta encontrar la forma que el modelo prefiere -- he perdido semanas haciendo esto para varios casos de uso. Es un juego diferente cuando posees los pesos y puedes modificar el modelo mismo para que sea mejor en un conjunto particular de herramientas.
El equipo de OpenAI dio una charla en noviembre que lo expuso bastante bien: si construyes un arnés pero no posees los pesos y no puedes aplicar RL al modelo dentro de él, siempre estarás en desventaja frente a un equipo que posea ambos.
RL para agentes de codificación en 60 segundos
Investigué mucho sobre este tema y preparé muchas visualizaciones para intentar explicar las partes que importan, pero descubrí que Calvin French-Owen (MTS en el equipo de codex, fundador de Segment) dio una charla en AI Council que hizo un trabajo mucho mejor y más limpio, así que solo voy a poner aquí esta animación inspirada en sus diapositivas:
Para hacer que un modelo sea mejor en codificación, vas a:
- generar algunos rastros de agentes de codificación para resolver un problema (por ejemplo, arreglar mis pruebas)
- puntuar los rastros según algún criterio (verificador)
- actualizar los pesos del modelo para hacer que los buenos rastros sean más probables, y los malos menos probables
Y luego haces esto millones de veces a lo largo de semanas o meses.
Sin embargo, la parte de "puntuación" de estas cosas tiende a ser caprichosamente unidimensional.
No hay penalización por mal diseño
Toma SWE-bench Multilingual. Las tareas son pequeñas -- unos quince minutos de trabajo cada una -- extraídas de repositorios de código abierto como Redis, jq y Django. La recompensa es uno o cero basada en:
- FAIL_TO_PASS - ¿arreglaste lo que te pidieron que arreglaras?
- PASS_TO_PASS - ¿lo hiciste sin romper nada más?
Aquí hay una real, fastlane__fastlane-19304, de fastlane -- un proyecto de Ruby. Su acción zip toma dos parámetros opcionales y llama a .empty? directamente, así que en el momento en que omites include y exclude, se cae:
La corrección humana que cerró este problema en particular es de dos líneas (nil por defecto a arreglos vacíos):
Durante la evaluación, el modelo
- comienza desde un commit base -- el repositorio revisado justo al momento antes de que esa corrección llegara
- el informe de error - en este caso 'zip_command': método indefinido 'empty?' para nil:NilClass
El agente se va y escribe algo de código basado en el issue. No ve el parche dorado ni el parche de prueba que sirve como calificador:
Luego:
- Mantenemos cualquier parche que haya producido, luego
- Descartamos cualquier edición que haya hecho a los archivos de prueba (hemos atrapado a un modelo comentando silenciosamente la prueba fallida o insertando un mock que hace que la prueba sea inútil)
- Aplicamos el parche de prueba del benchmark encima, y
- Ejecutamos toda la suite: las pruebas zip existentes (PASS_TO_PASS) más la nueva (FAIL_TO_PASS) para ver si ambas pasan
Incidental - Los benchmarks no son verificadores - de hecho, deben mantenerse separados unos de otros (no entrenar en pruebas, etc.) - principalmente quiero transmitir la forma de "juzgar la calidad de un rastro de agente de codificación" y sus limitaciones.
Cómo llegó el modelo a una respuesta correcta no importa. Si las pruebas pasan, ganamos, pero no hay penalización por erosionar la mantenibilidad de la base de código.
no hay penalización por erosionar la mantenibilidad de la base de código
Así es como obtienes try catch alrededor de todo:
Verificar la calidad es órdenes de magnitud más difícil que "¿pasaron las pruebas?"
Ejecutar las pruebas te da un resultado claro de aprobado o reprobado en ~segundos. Por eso RL puede ejecutar millones de loops para optimizar cada generación de modelo.
Pero la función de costo de una mala arquitectura se mide en semanas, meses, quizás incluso años. Ocurre la primera vez que alguien abre ese archivo para un cambio de una línea y se da cuenta de que no puede hacerlo en una línea -- que alguien vibreó esto demasiado fuerte, y ahora tenemos que hacer la misma edición en once lugares y esperar que nada se rompa silenciosamente tres archivos más allá.
Las pruebas te dan retroalimentación en segundos, pero la función de costo de una mala arquitectura se mide en semanas, meses, quizás incluso años
El mal diseño es lo único que los benchmarks de hoy no pueden evaluar. Y lo sé, lo sé, RL no es lo mismo que benchmarks, pero si esto estuviera resuelto en RL, estoy bastante seguro de que empezaría a reflejarse también en cómo están diseñados nuestros benchmarks.
En cualquier caso, personalmente no confío en ninguna mejora en los benchmarks actuales como indicador de que los modelos de repente son buenos para no llenar de basura tu base de código.
La frontera está mejorando, lentamente
Por supuesto, muchas personas inteligentes están trabajando en esto. Mi punto no es que no se pueda hacer, es que el hype está superando a la disciplina.
Algunos esfuerzos que creo que van en la dirección correcta:
- SWE-Marathon (Abundant AI): tareas de ~400 horas como "clonar todo Excel, cada función" -- con un canal de recompensa compuesto en lugar de un solo bit de aprobado/reprobado
- DeepSWE (Datacurve): tareas grandes en repositorios de código abierto que nunca se construyeron realmente en el mundo real, por lo que por construcción no pueden estar ya en el conjunto de entrenamiento (resuelve la contaminación, pero no la calidad)
- Frontier Code (Cognition): tareas de múltiples PR, y un movimiento inteligente que evalúa la calidad de forma determinista -- penaliza al modelo por escribir pruebas que no fallan en el código anterior al parche (si nunca has oído hablar de mutation testing, te espera un viaje divertido5). También ejecuta un modelo juez sobre el diff verificando reglas de calidad de código.
Pero un modelo juzgando calidad solo puede llegar hasta cierto punto.
De hecho, no es difícil imaginar que si un modelo pudiera distinguir de manera confiable entre código bueno y malo, podría haber escrito la versión buena desde el principio. RL necesita un oráculo rápido y confiable, y aún no tenemos uno para la mantenibilidad.
si un modelo pudiera distinguir de manera confiable entre código bueno y malo, podría haber escrito la versión buena desde el principio, pero la mantenibilidad no tiene un oráculo rápido, por lo que no podemos recompensarla durante el RL.
Por supuesto, más agentes de revisión y más tokens ayudan: elevan el piso, atrapando las cosas tontas.
Pero no mueven el techo, porque el techo es lo que hemos logrado enseñarle al modelo en RL, y el buen diseño es lo que aún no sabemos cómo enseñarle.
Así que todavía no apostaría mi base de código por ninguno de estos. Pero son las primeras evaluaciones que he visto que intentan calificar la mantenibilidad en lugar de limitarse a aprobar/reprobar.
Aparte Quizás un modelo futuro simplemente entienda esto y podamos parar. Si quieres mandar prompts a lo loco hasta que llegue GPT-7 y descubrirlo, adelante — pero al diablo la lección amarga, tenemos problemas que resolver ahora, y voy a explicar cómo lo hacemos.
Volviendo a encender las luces
Hoy aprendí que los Artículos de Twitter tienen un "límite de medios", lo que significa que el resto de esto irá en una segunda parte — mantente al tanto.
