Fábricas de software, luz y sombra

Una fábrica de software es bucles aprovechados a escala. Puedes ejecutar el bucle con humanos en él (fábrica iluminada): intercambiando juicio y concentración por velocidad y riesgo de rotura. O puedes ignorar a los humanos (fábrica oscura) y dejar que esos agentes definan el alcance, construyan y envíen código, sin que nadie lea realmente los detalles. Pero si la gente deja de leer, dejará de entender tu software. Tu trabajo más difícil ahora es saber qué controles construir y cuánta autonomía delegar.

Esta idea de la fábrica de software es un término que se remonta al artículo de Bob Bemer, "La economía de la producción de programas" presentado en 1968. Durante medio siglo, muchos han soñado con un mundo en el que el software sea un proceso de producción repetible e instrumentable (análogo a estampar piezas de automóviles en una fábrica) en lugar de la artesanía aislada de individuos. Históricamente, este sueño generalmente (aunque no universalmente) ha fracasado, en parte debido a la dificultad de estampar ideas.

Pero en los últimos dos años, las cosas han cambiado lo suficientemente drásticamente como para que ahora tenga sentido echar un nuevo vistazo al viejo sueño. Y dado que algunos matices pueden pasarse por alto fácilmente, vale la pena ser algo precisos sobre qué es realmente nuevo y diferente, y qué pueden ser trampas recurrentes, disfrazadas de nuevas oportunidades.

@dexhorthy, cofundador de HumanLayer, dio recientemente una excelente charla en AI Engineer World's Fair llamada "La ingeniería de aprovechamiento no es suficiente: Por qué fracasan las fábricas de software." que vale la pena ver sobre este tema.

El bucle es el átomo. La fábrica es el bucle a escala.

La estructura lo es todo, y todo comienza con unidades pequeñas. Toda la pila son realmente tres conceptos superpuestos: el bucle, el aprovechamiento y la fábrica.

Un bucle es un agente que realiza un solo trabajo en repetición: recopilar contexto, tomar una acción, verificar el resultado y repetir hasta que se cumpla alguna condición. Es la unidad más pequeña de trabajo agéntico, y todo lo que está por encima son solo bucles apilados sobre bucles.

El objetivo de la ingeniería de bucles es que dejes de incitar al agente turno por turno y, en su lugar, diseñes el pequeño sistema que lo incita por ti.

Un aprovechamiento son los muros alrededor de un bucle: el entorno aislado en el que se ejecuta, las herramientas a las que puede acceder, la memoria que sobrevive entre ejecuciones y las puertas que deciden qué significa "listo". El bucle es el comportamiento; el aprovechamiento es el entorno en el que se ejecuta ese comportamiento.

Entrega un modelo en bruto sin aprovechamiento y felizmente girará para siempre. El aprovechamiento es todo lo que lo rodea que lo hace útil y seguro de ejecutar.

Una fábrica de software son muchos bucles aprovechados ejecutándose a la vez, alimentados por una cola de trabajo y drenados a través de una puerta de revisión hacia producción, con los humanos siendo dueños de todo desde arriba. No es un agente más grande; es un organigrama hecho de bucles.

El cambio de paradigma final es pasar de escribir código a construir y ejecutar la fábrica que lo escribe. La unidad de trabajo se desplaza un nivel hacia arriba, al bucle, al aprovechamiento y al flujo entre ellos, en lugar del diff de código individual.

Bucle → aprovechamiento → fábrica. Una fábrica no es un agente más inteligente; son muchos bucles aprovechados alimentando una puerta de revisión, con un humano siendo dueño del bucle exterior. La fábrica, dibujada.

La diapositiva central en la que Dex pasó más tiempo fue brillante porque es un diagrama de cableado esclarecedor que visualiza lo que de otro modo es un bucle obvio. Aquí está mi interpretación:

La fábrica es un bucle cerrado: la intención y las señales de producción alimentan una cola, el aprovechamiento construye, las comprobaciones automatizadas y la puerta de revisión lo filtran, el despliegue lo envía, el monitoreo convierte la producción nuevamente en señales. La intención fluye desde la visión del liderazgo de ingeniería, y directamente de los ingenieros, hacia una cola de cosas por hacer. Las señales impulsadas por incidentes y solicitudes de usuarios alimentan la misma cola.

El aprovechamiento es simplemente la cosa que toma un elemento de la cola y construye un cambio para él. Más allá del aprovechamiento, podemos ver todas las comprobaciones automatizadas necesarias para que los cambios sean lo suficientemente seguros como para permitir su entrada en producción. Estas comprobaciones automatizadas se ejecutan a la vez, sin esfuerzo, sin la participación consciente de los ingenieros, gracias a CI, pruebas, análisis estático y escaneo de todo tipo. El único punto de decisión aquí es la puerta de revisión. Después de la aprobación, los cambios se despliegan y monitorean en producción, y los datos de monitoreo retroalimentan las señales que pusieron el bucle en movimiento desde el principio.

En general, cada cuadro en este diagrama tiene un costo casi nulo: generación, pruebas, escaneo. Todos se ejecutan a escala por un costo insignificante. Solo hay un cuadro costoso que demuestra ser obstinadamente resistente a la escala, y esa es la puerta de revisión. Ese brillante cuadro ámbar es "juicio", y ahí reside el quid de la discusión sobre si podemos hacer que el desarrollo sea más rápido y más frecuente.

Por qué lo llamamos "oscuro"

Una fábrica oscura funciona con las luces físicamente apagadas, porque las únicas cosas en el piso son máquinas y las máquinas no necesitan luz para ver. Una fábrica de software oscura hace lo mismo: el código se envía sin que ningún humano lo haya leído, verificado solo por otras máquinas.

La imagen está tomada de la fabricación. Sus orígenes son físicos más que digitales, arraigados en instalaciones donde las luces están apagadas y el trabajo lo realizan robots. FANUC en Japón ha estado operando fábricas sin luces de este tipo desde 2001; Xiaomi, en 2024, abrió su propia fábrica oscura altamente automatizada. Lo que estas tienen en común es un producto ensamblado y enviado sin que un solo humano haya leído nada de él. Lo "oscuro" aparece cuando ese acto de lectura se elimina del proceso.

No estoy tomando prestado el concepto por su ambiente o como un insulto. Por todo su zumbido inquietante, "oscuro" aquí es una simple afirmación física: el piso de la fábrica original, pero sin luz. En el software, el piso es el diff. Quienquiera que haya escrito el diff, quienquiera que lo haya revisado, quienquiera que lo haya enviado, esos humanos se han ido, y lo que queda es un diff verificado solo por las máquinas que lo construyeron.

Esto es sorprendentemente fácil de hacer, al menos al principio. Es fácil porque ese paso de revisión faltante se interpone en todo. Su ausencia hace que tu percepción del rendimiento vertical de tu equipo parezca repentina y radicalmente más alta. Se siente como si hubieras roto la barrera del sonido. Por toda su aparente facilidad, es más difícil de lo que parece sobrevivir a esos flujos de trabajo oscuros, con todos sus costos ocultos.

La ingeniería de aprovechamiento no es suficiente

El aprovechamiento de la orquestación, la creación de prototipos en entornos aislados y la llamada a herramientas a medida que los modelos interactúan con el mundo y entre sí se volverán cada vez más potentes y efectivos. Sin embargo, hay un fallo inherente dentro del modelo al tratar de mantener la calidad del código base a largo plazo y a través de cambios aditivos, y creo que hay buenas razones para creer que los modelos solos perderán esa batalla contra la deuda de comprensión.

La deuda de comprensión es la brecha cada vez mayor entre cuánto código existe y cuánto entiende todavía cualquier humano. Una fábrica oscura no la paga; la asume tan rápido como puede, con las pruebas en verde durante todo el camino.

Esta es una distinción importante porque los modelos se desempeñan bien en algunas tareas. Pero para cualquier cosa que no sea un cambio inmediato en una pequeña parte de un código base, especialmente en un sistema complejo ya existente, la codificación automatizada solo con modelos se enfrenta a un obstáculo insuperable. Las aplicaciones desde cero, los juguetes de fin de semana y los proyectos paralelos son similares en que unos pocos meses de ciclos de desarrollo suelen ser suficientes para que las cosas funcionen, o al menos casi.

Pero un sistema empresarial que ha estado en desarrollo durante una década o más es una bestia diferente; debe mantenerse, en un entorno profesional a un ritmo profesional. De tres a seis meses en un proyecto, ya estás ahogado en código no leído. Ese tipo de entorno, y especialmente las restricciones impuestas por el código de producción, harían que incluso un agente potente se desempeñara mal, todo en contraste con el "vibe-coding" que disfrutan los desarrolladores que trabajan en juguetes de fin de semana.

Dex informa por experiencia que este es un fallo importante, tanto que requirió una depuración manual minuciosa para localizarlo. Esto provino de ejecutar una fábrica de código completamente automatizada durante unos cuatro meses, durante los cuales ningún humano miró el código que se escribió. Subyacente a la experiencia hay una compensación entre dos métricas conflictivas. Una es maximizar la utilización de tokens, el número que actualmente tratamos como progreso. La otra, que minimiza silenciosamente, es la cantidad del sistema que cualquier participante humano aún entiende en un momento dado.

Donde realmente brilla la fábrica oscura es en su capacidad para quemar código prístino mientras las pruebas permanecen en verde. El ajuste de cuentas final, cuando llegue, no será un momento dramático de "todo se va al traste". Será silencioso y tardío.

Oscura e iluminada son el mismo pipeline con las luces en diferentes lugares. La versión iluminada no solo vuelve a agregar revisión al final: también mueve el juicio humano upstream, al diseño y la arquitectura. El cuello de botella nunca fue la generación.

La restricción fundamental en una fábrica de software no es cuánto código podemos producir: es qué tan rápido podemos verificarlo.

La contrapresión es la regla de que solo puedes darle a un bucle tanta autonomía como puedas verificar de manera económica y confiable, ni un ápice más. La verificación, no la generación, es la verdadera restricción en una fábrica.

Debido a que la capacidad de generación ilimitada está en tensión perpetua con el recurso finito y no escalable de la atención humana, el problema central es la brecha entre la generación barata y la revisión limitada. Mira el embudo: mientras el cuello que representa la verificación no se ensanche, se va a acumular. Como señala Dex, el volumen por sí solo no es el problema: lo que realmente sufrimos es un excedente de PRs malos. Cuando tienes un alto volumen sin puertas confiables, los defectos fabricados son inevitables. Esto es nuevamente contrapresión: la autonomía no puede expandirse más allá de lo que se puede verificar de manera económica y confiable.

El problema de segundo orden es por qué mejorar el modelo no debería cerrar automáticamente la brecha entre lo que puede generar y lo que se puede verificar. Entrenar en sistemas bien arquitectados es una propuesta posiblemente más difícil que pasar pruebas simples: recuerda, las funciones de costo que miden la excelencia arquitectónica no se miden en segundos ni siquiera en minutos, sino en meses y años. Los gradientes ordenados son funcionalmente imposibles de calcular, por lo que un sistema que espera una evaluación nítida e instantánea de decisiones de diseño complejas no va a ser entrenado con buenos ejemplos.

La generación es una boca ancha; la verificación es el cuello estrecho. Acelerar la boca solo profundiza el montón en el cuello.

Encendiendo las luces de nuevo

Una fábrica iluminada es el mismo pipeline con las luces encendidas donde reside el juicio. Los agentes todavía hacen la mayor parte de la construcción, pero un humano lee lo que sale antes de que se envíe, y las luces permanecen encendidas donde sea que una decisión incorrecta sea costosa.

La versión iluminada no añade revisión al final, sino que mueve el punto de juicio humano upstream, al producto, al diseño y a la arquitectura antes de que un agente inicie un bucle.

Una gran cosa de esa hora inicial es que conduce a menos horas de implementación. Convierte una larga y frustrante revisión de código en una lectura rápida de un plan de doscientas líneas. Puedes revisar una decisión antes de que se construya, así que más tarde no estás persiguiendo dos mil líneas de código generado para descubrir cuál fue la decisión siquiera. Algunas decisiones son lo suficientemente costosas y duraderas como para que quieras que una persona participe desde el principio, antes de que el costo se acumule. Por supuesto, todavía hay momentos en los que miras diffs, incluso cuando has dedicado tiempo al principio.

Podrías estar pensando que todo suena poco glamoroso. Tienes razón. La red de seguridad está compuesta de prácticas arquitectónicas perfectamente ordinarias que siempre hemos conocido y en su mayoría ignorado: buenos tipos y firmas de métodos para que los errores sean detectados por el compilador en lugar de en producción; puntos de integración para pruebas donde podemos fijar el comportamiento y hacer que el cambio sea observable; diseñar el código para que el próximo lector, humano o modelo, sepa dónde encontrar lo que le importa; mantener las pilas de llamadas cortas y legibles; mantener los límites de los componentes bien definidos para que un cambio no tenga un radio de explosión enorme; e inyección de dependencias para que podamos intercambiar una pieza por otra. Nada de esto es nuevo. Siempre hemos dicho que nos importa una buena arquitectura. Pero ahora que estamos usando agentes de codificación automatizados, esa arquitectura finalmente está haciendo un segundo trabajo como una red de seguridad barata y difícil de falsear contra los errores que el agente cometerá.

Esa red de seguridad tiene que vivir fuera del modelo, porque el modelo no la proporcionará. Los agentes de codificación que se sienten más capaces, Claude Code y Codex entre ellos, están entrenados por refuerzo contra su propio aprovechamiento y herramientas: fluidos con todas las herramientas y modismos del oficio, pero no con cosas como la mantenibilidad a largo plazo. La arquitectura deliberada de la que siempre hemos hablado es la herramienta que detecta esa deuda, y la inversión que hacemos en ella es que nosotros compramos nuestra autonomía.

Combina eso con una infraestructura segura, y hay algunos bucles ajustados y de bajo riesgo que puedes ejecutar sin supervisión. Horthy describió uno en una publicación reciente: un cron de GitHub Actions nocturno que corrige exactamente un anti-patrón, una violación de lint o un prop innecesariamente opcional, hace commit y abre una pequeña solicitud de extracción, todo por su cuenta, para que el equipo se despierte con un código base ligeramente mejor y un diff lo suficientemente corto para leer. Pero para bucles con apuestas suficientemente altas, no quieres arriesgarte a despertarte con un sistema de autenticación roto, un motor de facturación o un contrato de API público. Mantén las luces encendidas ahí, y confía en que una persona con juicio y un conocimiento práctico real del sistema detectará el error.

Qué gana un bucle el estado oscuro

Esta regla se aplica ya sea que lo llames contrapresión, verificación o el interruptor de la luz.

Un bucle puede ganarse el estado completamente automatizado solo si la verificación es barata, se ejecuta a alta frecuencia y se basa en algo que no se puede falsear fácilmente. Los oráculos de verde-o-rojo, las puertas de tipos, las pruebas de propiedades y un agente de revisión junto con una rúbrica real encajan todos. También necesitas que el oráculo responda de inmediato y no se desvíe con el tiempo. Cuando "listo" puede ser probado no solo por ti sino por una máquina, has alcanzado la automatización.

Los bucles cortos son más fáciles de verificar que los largos. La regla general de Dex: un agente se mantiene firme durante tres a diez pasos, luego comienza a perder el hilo después de veinte. La razón es la acumulación de contexto: cuanto más arrastra el agente, más probable es que se desvíe. Cuando un bucle es corto, verificarlo es barato. Los bucles extensos esconden errores en los rincones, lo que es otra forma de decir que nunca se ganaron el estado de luces apagadas.

Mantener las luces encendidas es el caso opuesto. Un bucle necesita ser revisado si una respuesta incorrecta es costosa y solo una persona puede detectarla. Errores de producción sutiles que no pueden ser detectados por pruebas, grandes radios de explosión y una decisión que va a dar forma al trabajo de un año o más, todos califican. En esos casos, tu atención es el producto real, el costoso y esencial.

El peligro es olvidar cambiar cada interruptor y simplemente ponerlos todos en el mismo modo. Todo oscuro, y estás atascado derribando todo cuatro meses después. Todo iluminado, y nadie puede hacer las revisiones a tiempo y estás atascado en un cuello de botella gigantesco. El trabajo difícil y hábil es decidir dónde colocar cada interruptor.

¿Bucles, gráficos o máquinas de estado?

Deberías leer "Máquinas de estado en 2 minutos" por @DavidKPiano

Cuando le das una tarea a un agente, probablemente vas a construir un gráfico alrededor de ella, ya sea que llames a ese gráfico una máquina de estado finito o un conjunto de llamadas a servicios condicionalmente vinculadas. Es un marco donde el software no solo sigue algunas reglas abstractas sino un flujo de trabajo estructurado: cada nodo es un paso explícito, y cada borde entre nodos es una condición explícita.

Eso suena a mucha estructura, pero la mayor parte ya está presente en cualquier software, ya que cualquier código se puede expresar como un gráfico de flujo de control. Así que la única novedad real es que un agente que insiste en la autonomía realmente está solo caminando alrededor de un gráfico particular, y su libertad está restringida al interior de un nodo. Y aquí está la parte que la gente olvida, que Dex escribió hace un año: el software siempre iba a tener esa estructura. Hay una razón por la que solíamos dibujar programas como diagramas de flujo.

El movimiento verdaderamente nuevo fue tratar de tirar el diagrama a la basura, apoyándose en un bucle donde el modelo elige el camino llamada a herramienta por llamada a herramienta, hasta que se declara listo. Eso se sintió como liberación, justo hasta que se encontró con un código base de diez años, y la disciplina que todos están redescubriendo ahora, ser dueño de tu flujo de control, es realmente solo caminar el gráfico de vuelta alrededor del bucle. Así que la pregunta de si deberíamos cambiar de bucles a gráficos es casi una admisión de que necesitábamos el diagrama de flujo todo el tiempo.

Así es como se ve en la práctica. Toma un error para corregir. Como un bucle puro, te sientas y piensas: descubre qué está mal, cambia algo de código, ejecuta las pruebas, mira qué pasa, y si esa ronda no mata la ejecución, vuelve al bucle y empieza de nuevo. Todo el viaje se decide sobre la marcha, qué problema persigues, el código exacto que cambias, qué pruebas ejecutas y en qué orden, si ejecutas pruebas en absoluto, y si lo intentas de nuevo o declaras victoria.

Como un gráfico, lo primero que haces es mapear lo que debería suceder. Reproduce el error o ve a pedir más información, encuentra la causa, prueba una corrección, ejecuta las pruebas, y deja que una ejecución fallida vuelva a la corrección mientras que una exitosa pasa a revisión, donde solo una aprobación alcanza "listo". El agente sigue siendo inteligente dentro de cada caja; simplemente no puede desviarse de los caminos que autorizaste. Santi explicó esto con un diagrama que hace obvia la diferencia.

El atractivo real de ese gráfico, por supuesto, es que es contrapresión dibujada como un diagrama. Renuncias a algo de la libertad del agente y obtienes verificaciones obligatorias y puntos de falla legibles a cambio, así que cuando una ejecución muere, puedes señalar el nodo que la mató. Es el mismo instinto detrás de la línea contundente de Dex de que la mayoría de los llamados agentes no son muy agénticos en absoluto, "código mayormente determinista, con pasos de LLM espolvoreados en los puntos justos." Y esto no es solo un artefacto de cómo la gente está construyendo cosas ahora mismo: puedes ver el patrón en LangGraph y LlamaIndex Workflows, en el híbrido flujo de trabajo-gráfico-sobre-agentes de Jerry Liu con un bucle exterior que hace crecer partes del gráfico a medida que se ejecuta, y en el recordatorio de David Khourshid de que esto es realmente solo máquinas de estado y el modelo de actor apareciendo con ropa nueva.

Una aclaración, porque el término está terriblemente sobrecargado: cuando sigo llamando a esto un gráfico, no me refiero a un gráfico de conocimiento. Me refiero a un gráfico dirigido predefinido de cómo debería fluir el trabajo, bordes condicionales y todo, dándole al bucle una forma en la que realmente puedas confiar.

Dónde va realmente el humano

Nota que la persona nunca abandonó la fábrica. Se movió.

Creo que los ingenieros necesitan ser cada vez más dueños del bucle exterior. Los agentes pueden investigar un error, redactar el diagnóstico, implementar una corrección, ejecutar las pruebas y redactar un informe. Esa es la ejecución del bucle interior, y pueden hacerlo tan eficientemente como cualquiera. Pero ese nunca fue el trabajo. Las partes de las que eres dueño son lo que yo llamaría el bucle exterior: decidir si es la forma correcta de abordar el problema, verificar que el diagnóstico y la implementación sean sólidos, aprobar el cambio y asumir las consecuencias de estar equivocado. El límite entre los dos bucles es la evidencia, los diffs, las pruebas, los registros y una breve explicación que los conecte. Los tipos, los puntos de integración y las rúbricas hacen posible supervisar todo esto sin hacer mucho trabajo para cada cambio.

Es útil decirlo de esta manera: ya no estás abajo en la línea escribiendo cambios; estás arriba al final de la línea de producción diseñándola y vigilando la puerta. Hay mucho que puedes hacer para mejorar el modelo y hacer más capaz el aprovechamiento, pero he observado que identificar problemas que son costosos a largo plazo no es algo que normalmente puedas automatizar. Lo central que sigue siendo el trabajo es ejercer el juicio humano mejor que cualquier flujo de papel y poder de cómputo.

Los robots están bien operando en la oscuridad, pero los humanos necesitan ver lo que están haciendo. Si todo en el piso de la fábrica está oscuro, y no puedes ver nada, y ni siquiera puedes encontrar el interruptor de la luz, ahí es donde está el peligro.

Pangram calificó este artículo como 100% escrito por humanos.