o: el arnés no es suficiente
Actualización: la versión en charla de esta publicación ya está en YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M
supongo que ahora hacemos bucles
Todos estamos compitiendo por llevar la codificación con IA a producción. Se ha hablado mucho sobre la ingeniería de bucles, y la sabiduría predominante es que probablemente deberíamos escribir más bucles.
StrongDM escribió sobre su fábrica de software "sin luces" 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 son suficientemente buenos.
- El código es gratis.
- Simplemente envía 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 realmente inteligentes y les tengo un enorme respeto. Pero la interpretación más cínica aquí sería llamar a esto otra excusa para inyectar más capital de riesgo en el cañón de basura.
está... uh... está funcionando
Nuestro amigo Mario se levantó en AI Engineer Europe y nos rogó que redujéramos la velocidad -- porque las empresas que no deberían tener interrupciones debido a errores de agentes de codificación, bueno... están teniendo interrupciones debido a 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/hallazgos definitivos de StrongDM sobre cómo funcionó esa fábrica oscura. El informe meteorológico tiene algunas actualizaciones dispersas entre febrero y junio de este año. edición - 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!
Los chicos de Faros AI publicaron 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 disminuido drásticamente.
- Más comentarios, comentarios más largos y toneladas de PRs fusionadas 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 hagas empezar con la prosa de Claude), y el objetivo de esta publicación es ser cauteloso con los datos basura, pero se siente direccionalmente válido según lo que he visto.
"Lo estás sosteniendo mal" (no es así)
Mucha gente te dirá que esto es un problema de habilidad: que si no obtienes buenos resultados, es culpa tuya.
Pero sin importar cómo elijas... eh... sostenerlo, te garantizo que te están diciendo que si el token-maxxing no funciona para ti, 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 de la progresión. Yo también pensaba así el verano pasado.
Desafortunadamente para mi ego, algunas cosas tontas que decidí decir sobre "cómo sostenerlo mejor" quedaron grabadas y ahora tienen alrededor de un millón de visitas acumuladas en YouTube. No estoy tratando de 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.
- Ingeniería de Contexto Avanzada para Agentes de Codificación
- Sin Vibraciones Permitidas: Resolviendo Problemas Difíciles en Bases de Código Complejas
- Todo lo que Entendimos Mal sobre RPI
De todos modos, La promesa de todo este parloteo en línea de "simplemente 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 espolvorear 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 de modelos.
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 esta publicación, 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 obtener excelentes resultados 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 superar el hype de cada plugin de habilidades que surge a diario y la pandemia de consejos de ai-psicosis-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: esta publicación se basa (y amplía) mi discurso principal en AI Engineer World's Fair 2026.
Gracias a @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, y @jeffreyhuber por sus comentarios sobre esta publicación.
Un inciso: esto no tiene nada que ver con el vibe coding
Addy Osmani desenredó esto que vale la pena destacar:
Un desarrollador que hace vibe coding en un proyecto paralelo que una docena de personas usarán, y un equipo que mantiene un sistema empresarial de diez años durante otro trimestre, no comparten casi ninguna restricción que valga la pena mencionar, y la mayoría de los consejos que circulan son realmente uno de esos dos diciéndole al otro cómo vivir.
Si te encanta el vibe coding, por favor, sigue vibrando. Yo todavía hago vibe coding en muchas cosas, solo que 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 mucho la palabra brownfield para hablar de esta división. Históricamente significaba 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 quizás tres a seis meses -- empiezas a reducir la velocidad 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 la "ingeniería de software".
El único otro dato que encuentro realmente 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 comenzar a usar Jenkins mejor o algo así.
La fábrica de software de 2022
Vamos a definir nuestra "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 debe suceder
- 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, tal vez alguien lo descarga para probarlo
- ¿Algo mal? Vuelve a "alguien construye la cosa"
- Envío 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 → de vuelta al equipo para agregar al rastreador
Y así sucesivamente. Ni siquiera hemos llegado a la IA, y ya hay varios bucles 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 la revisión también.
Por lo tanto, adelantamos el trabajo -- planificación, propuestas de arquitectura, planificación de sprints -- 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 agentiva en la imagen.
La fábrica de software agentiva
Ahora, todas las empresas y sus madres --
han 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 agentiva se parece principalmente a reemplazar "alguien construye la cosa" → "un agente construye la cosa" -- hay algunas cosas aquí como orquestación, un arnés, un sandbox, un modelo, uso de computadora, etc. No profundizaré en esos detalles porque, francamente, estoy harto de leer sobre ello 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 lleva horas o días. Un humano todavía tiene que leer el código y probar el cambio. Así que la revisión ahora es el cuello de botella.
Así que también aceleras la revisión:
- Revisión de código agentiva, para detectar estilo, errores, seguridad.
- Pruebas de regresión agentivas, para probarlo desde el exterior con navegadores y uso de computadora y tal vez enviarte un pequeño video bonito cuando termine
La revisión es más rápida ahora, pero probablemente sigue siendo el cuello de botella. Pero podemos hacer más bucles.
A continuación, podrías enrutar los incidentes a la fábrica. En lugar de despertar a alguien a las 3 a.m., se despiertan con un PR que tal vez ya lo soluciona.
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 luces.
La fábrica de software sin luces
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 salir genial (no es así)
Voy a plantear algo potencialmente controvertido: la fábrica sin luces no funciona.
Analicemos por qué fallan las fábricas de software.
Lo intentamos
En julio de 2025, nos volvimos completamente sin luces. Solo lee las especificaciones y los tickets, agentes en segundo plano para todas las cosas pequeñas/medianas, todo el asunto.
Si lo has intentado seriamente durante unos meses, ya sabes cómo termina. Encuentras al menos un problema lo suficientemente complicado como para que el agente no pueda resolverlo, incluso con tus indicaciones y flujos de trabajo más avanzados.
- Haces una investigación profunda consciente del 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 tragarte el orgullo y sumergirte 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 como yo, eras miserable, leyendo todo el código basura que dejaste entrar en tu sistema.
La primera vez que nos pasó esto, lo dejé pasar. A pesar de que acababa de pasar la mayor parte de dos semanas rebuscando en espaguetis de Claude, "el riesgo de desventaja 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) diseñando 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 a esto: los modelos tienen una deficiencia. 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 la cosa específica en la que 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:
- Una filosofía del diseño de software de John Ousterhout
- Código limpio de Robert C. Martin
- Refactorización de Martin Fowler
Entonces, ¿por qué no pueden los modelos hacer mantenibilidad de software?
"Pero seguramente los modelos han mejorado desde entonces"
En este punto, podrías estar muriendo por decir: pero Dex, seguramente los modelos han mejorado mucho desde julio
Lo han hecho, en algunos aspectos. En otros, siguen igual.
- ¿Resolver problemas aislados 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 se dirige eso más adelante).
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 durante un tiempo, y mucha gente está publicando exactamente sobre esto, probablemente ya tengas 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 descubrir por qué sucede esto, quiero alejarme al primer gran agente de codificación.
Claude Code ganó debido 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 anteriores a Claude Code, todos con una 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 simplemente... fallaba a veces, lo veías forcejear con la misma edición tres veces y volvías a abrir tu editor para hacerlo tú mismo.
El artículo de SWE-Agent de 2024 describe cómo pequeños cambios en la forma de las herramientas 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 creció verticalmente bastante rápido. Puedes atribuir esto a la distribución, pero la explicación canónicamente aceptada es que Claude Code ganó porque era mejor, y que era mejor porque Anthropic entrenó con RL el modelo dentro del arnés -- la primera vez que un laboratorio entrenó un modelo contra las herramientas exactas con las que iban a enviarlo. Y se volvió realmente, realmente bueno llamando a esas herramientas en un bucle agentivo.
Una cosa es jugar con las definiciones de herramientas y las evaluaciones hasta encontrar la forma que más le gusta al modelo; he pasado semanas haciendo esto para varios casos de uso. Es un juego diferente cuando posees los pesos y puedes modificar el modelo en sí para que sea mejor con un conjunto particular de herramientas.
El equipo de OpenAI dio una charla en noviembre que lo expresó bastante bien: si construyes un arnés pero no posees los pesos y no puedes entrenar con RL el modelo dentro de él, siempre estarás en desventaja frente a un equipo que posee ambos.
RL de Agente de Codificación en 60 segundos
Investigué mucho sobre este tema y preparé un montón de visualizaciones para tratar de explicar las partes importantes, 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 dejar caer esta animación aquí inspirada en sus diapositivas:
Para hacer que un modelo sea mejor en codificación, vas a:
- generar algunos rastros de agente de codificación para resolver un problema (por ejemplo, arreglar mis pruebas)
- puntuar los rastros en función de algunos criterios (verificador)
- actualizar los pesos del modelo para hacer que los rastros buenos sean más probables y los malos menos probables
Y luego haces esto millones de veces durante semanas o meses.
La parte de "puntuación" de estas cosas puede tender a ser caprichosamente unidimensional, sin embargo.
No hay penalización por mal diseño
Toma SWE-bench Multilingual. Las tareas son pequeñas, alrededor de 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 basado en:
- FAIL_TO_PASS - ¿arreglaste lo que se te pidió arreglar?
- 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, por lo que en el momento en que omites include y exclude, se cae:
La solución humana que cerró este problema en particular es de dos líneas (valores nulos por defecto a arrays vacíos):
Durante la evaluación, el modelo
- comienza desde un commit base -- el repositorio verificado en el momento justo antes de que se aplicara esa solución
- 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 problema. No ve el parche dorado ni el parche de prueba que sirve como calificador:
Luego:
- Conservamos cualquier parche que haya producido, luego
- Descartamos cualquier edición que haya hecho a los archivos de prueba (hemos atrapado a un modelo que silenciosamente comenta la prueba fallida o inserta un mock que hace que la prueba sea inútil)
- Aplicamos el parche de prueba del benchmark encima, y
- Ejecutamos todo el conjunto: las pruebas zip existentes (PASS_TO_PASS) más la nueva (FAIL_TO_PASS) para ver si ambas pasan
Inciso - Los benchmarks no son verificadores; de hecho, deben mantenerse separados entre sí (no entrenar con pruebas, etc.) - principalmente quiero transmitir la forma de "juzgar la calidad de un rastro de agente de codificación" y sus limitaciones.
No importa cómo llegó el modelo a una respuesta correcta. 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 terminas con try catch alrededor de todo:
Verificar la calidad es órdenes de magnitud más difícil que "si las pruebas pasaron"
Ejecutar las pruebas te da un resultado claro de aprobado o fallido en ~segundos. Es por eso que RL puede ejecutar millones de bucles para optimizar cada generación de modelo.
Pero la función de costo de una mala arquitectura se mide en semanas, meses, tal vez incluso años. Sucede 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: alguien vibreó esto un poco 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, tal vez incluso años
El mal diseño es lo único que los benchmarks actuales no pueden evaluar. Y lo sé, lo sé, RL != Benchmarks, pero si esto se resolviera en RL, estoy bastante seguro de que comenzaría a notarse 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 un 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/fallido
- DeepSWE (Datacurve): tareas grandes en repositorios OSS 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 manera determinista: penaliza al modelo por escribir pruebas que no fallan en el código anterior al parche (si nunca has oído hablar de pruebas de mutación, 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 la calidad solo puede llegar hasta cierto punto.
De hecho, no es difícil imaginar que si un modelo pudiera distinguir de forma fiable el código bueno del malo, probablemente ya habría escrito la versión buena desde el principio. RL necesita un oráculo rápido y fiable, y todavía no tenemos uno para la mantenibilidad.
Si un modelo pudiera distinguir de forma fiable el código bueno del malo, probablemente ya habría escrito la versión buena desde el principio, pero la mantenibilidad no tiene un oráculo rápido, por lo que no podemos recompensarlo durante el RL.
Por supuesto, más agentes de revisión y más tokens ayudan: elevan el piso, atrapando las tonterías.
Pero no mueven el techo, porque el techo es lo que logramos enseñarle al modelo en RL, y el buen diseño es lo que todavía no sabemos cómo enseñarle.
Así que todavía no apostaría mi base de código por ninguno de estos. Pero son los primeros evals que he visto que intentan puntuar la mantenibilidad en lugar de limitarse a aprobar/reprobar.
Aparte Quizá un modelo futuro simplemente entienda esto y podamos parar. Si quieres mandar prompts a lo loco hasta que salga GPT-7 y averiguarlo, adelante, pero que la amarga lección se vaya al diablo, tenemos problemas que resolver ahora, y voy a explicar cómo lo hacemos.
Volviendo a encender las luces
Hoy aprendí que los Twitter Articles tienen un «límite de medios», lo que significa que el resto de esto irá en un post de la parte II: estén atentos.
