Fábricas de software: luces y sombras

Una fábrica de software es bucles orquestados a escala. Puedes ejecutar el bucle con humanos dentro (fábrica iluminada): intercambiando juicio y concentración por velocidad y roturas. O puedes ignorar a los humanos (fábrica oscura) y dejar que esos agentes definan, construyan y desplieguen 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 implementar 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, "The economics of program production", 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óvil en una fábrica), en lugar del oficio aislado de individuos. Históricamente, este sueño generalmente ha fracasado (aunque no universalmente), en parte por la dificultad de estampar ideas.

Pero en los últimos dos años, las cosas han cambiado lo suficientemente drástico como para que ahora tenga sentido revisitar ese 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 gran charla en la Feria Mundial de Ingenieros de IA llamada "Harness Engineering is not Enough: Why Software Factories Fail." 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. Todo el stack son realmente tres conceptos apilados uno sobre otro: el bucle, el arnés y la fábrica.

Un bucle es un agente haciendo un solo trabajo de forma repetitiva: 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 agentivo, y todo lo que está encima son solo bucles apilados sobre bucles.

El objetivo de la ingeniería de bucles es que dejes de dar instrucciones al agente turno por turno y, en su lugar, diseñes el pequeño sistema que se las da por ti.

Un arnés son las paredes alrededor de un bucle: el sandbox en el que se ejecuta, las herramientas a las que puede acceder, la memoria que perdura entre ejecuciones, y las compuertas que deciden qué significa "terminado". El bucle es el comportamiento; el arnés es el entorno en el que ese comportamiento se ejecuta.

Dale a un modelo en bruto ningún arnés y se ejecutará felizmente para siempre. El arnés es todo lo que lo rodea y lo hace útil y seguro de ejecutar.

Una fábrica de software son muchos bucles con arnés ejecutándose a la vez, alimentados por una cola de trabajo y drenados a través de una compuerta de revisión hacia producción, con humanos supervisando 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 operar la fábrica que lo escribe. La unidad de trabajo sube un nivel, al bucle, al arnés y al flujo entre ellos, en lugar del diff de código individual.

Bucle → arnés → fábrica. Una fábrica no es un agente más inteligente; son muchos bucles con arnés alimentando una compuerta de revisión, con un humano supervisando el bucle exterior. La fábrica, dibujada.

La diapositiva central en la que Dex se detuvo más tiempo fue brillante porque es un diagrama de cableado aclaratorio que visualiza lo que de otro modo sería 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 arnés construye, las comprobaciones automatizadas y la compuerta de revisión lo evalúan, el despliegue lo envía, el monitoreo convierte producción de nuevo 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 arnés es simplemente lo que toma un elemento de la cola y construye un cambio para él. Más allá del arnés, podemos ver todas las comprobaciones automatizadas necesarias para que los cambios sean lo suficientemente seguros como para dejarlos entrar 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 compuerta 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 en primer lugar.

En general, cada caja en este diagrama tiene un costo casi nulo: generación, pruebas, escaneo. Todos se ejecutan a escala por un costo insignificante. Solo hay una caja costosa que se muestra obstinadamente resistente a escalar, y esa es la compuerta de revisión. Esa brillante caja ámbar es el "juicio", y ahí reside el meollo del argumento 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 lo único que hay en el piso son máquinas y las máquinas no necesitan luz para ver. Una fábrica de software oscura es el mismo movimiento: se envía código que ningún humano ha leído, verificado solo por otras máquinas.

La imagen está tomada de la manufactura. Sus orígenes son físicos más que digitales, arraigados en instalaciones donde las luces se apagan 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 fuertemente automatizada. Lo que 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 tomo 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 software, el piso es el diff. Quien haya escrito el diff, quien lo haya revisado, quien 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 que falta se interpone en todo. Su ausencia hace que tu percepción del rendimiento vertical de tu equipo parezca repentina y radicalmente mayor. 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 arneses no es suficiente

El arnés de orquestación, creación de prototipos en sandbox y llamadas a herramientas a medida que los modelos interactúan con el mundo y entre sí, se volverá cada vez más poderoso y efectivo. Sin embargo, hay un fallo inherente al modelo al intentar 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 reduce; la acumula tan rápido como puede, con las pruebas en verde durante todo el proceso.

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 brownfield complejo, la codificación automatizada solo con modelos se enfrenta a un obstáculo insuperable. Las aplicaciones greenfield, los juguetes de fin de semana y los proyectos secundarios son similares en que unos pocos meses de ciclos de desarrollo suelen ser suficientes para poner las cosas en orden, o al menos lo suficientemente cerca.

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 después de iniciar 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 poderoso se desempeñara mal, todo en contraste con el "vibe-coding" que disfrutan los desarrolladores que trabajan en juguetes de fin de semana.

Dex reporta 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 escribía. Subyacente a la experiencia hay una compensación entre dos métricas en conflicto. 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 cualquier momento.

Donde la fábrica oscura realmente brilla es en su capacidad para quemar código impecable 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.

Oscuro e iluminado son el mismo pipeline con las luces en diferentes lugares. La versión iluminada no solo agrega revisión al final: también mueve el juicio humano upstream hacia el 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 otorgar a un bucle tanta autonomía como puedas verificar de manera barata 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 solo no es el problema: lo que realmente sufrimos es un excedente de PRs malos. Cuando tienes un volumen alto sin compuertas 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 barata 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 precisa 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 equivocada sea costosa.

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

Una cosa excelente 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. Algunas decisiones son costosas y de larga duración 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 glamuroso. Tienes razón. La red de seguridad está compuesta por 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 enganche 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 gran radio de explosión; e inyección de dependencias para que podamos intercambiar una pieza por otra. Nada de esto es nuevo. Siempre hemos dicho que nos importa la 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, entre ellos Claude Code y Codex, están entrenados por refuerzo contra su propio arnés 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 nuestra forma de recuperar 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 antipatrón, una violación de lint o una prop innecesariamente opcional, hace commit y abre un pequeño pull request, todo por sí solo, 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 lo 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ública. 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é le gana a un bucle el modo oscuro

Esta regla se aplica tanto si lo llamas contrapresión, verificación o el interruptor de la luz.

Un bucle puede ganarse el estatus de completamente automatizado solo si la comprobación es barata, se ejecuta con alta frecuencia y se basa en algo que no se pueda falsear fácilmente. Los oráculos de verde-o-rojo, las compuertas de tipos, las pruebas de propiedades y un agente de revisión junto con una rúbrica real encajan. También necesitas que el oráculo responda de inmediato y no se desvíe con el tiempo. Cuando se puede demostrar que está terminado 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 de 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 terminas desmantelando todo cuatro meses después. Todo iluminado, y nadie puede terminar las revisiones a tiempo y te quedas atascado en un gigantesco cuello de botella. El trabajo difícil y especializado es decidir dónde colocar cada interruptor.

¿Bucles, grafos o máquinas de estado?

Deberías leer "State machines in 2 minutes" de @DavidKPiano

Cuando le asignas una tarea a un agente, probablemente vas a construir un grafo a su alrededor, ya sea que llames a ese grafo 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 arista 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 puede expresarse como un grafo de flujo de control. Así que la única novedad real es que un agente que insiste en la autonomía en realidad solo está recorriendo un grafo 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 los programas como diagramas de flujo.

El movimiento verdaderamente nuevo fue intentar 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 terminado. 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 volver a recorrer el grafo alrededor del bucle. Así que la pregunta de si deberíamos pasar de bucles a grafos es casi una admisión de que necesitábamos el diagrama de flujo desde el principio.

Así es como se ve en la práctica. Toma un error que corregir. Como un bucle puro, te sientas y piensas: averiguar qué está mal, cambiar algo de código, ejecutar las pruebas, ver 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 grafo, 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, intenta una corrección, ejecuta las pruebas, y deja que una ejecución fallida regrese a la corrección mientras que una exitosa continúe hacia la revisión, donde solo una aprobación llega a "terminado". El agente sigue siendo inteligente dentro de cada caja; simplemente no puede alejarse de los caminos que autorizaste. Santi explicó esto con un diagrama que hace obvia la diferencia.

El atractivo real de ese grafo, por supuesto, es que es contrapresión dibujada como un diagrama. Renuncias a algo de la libertad del agente y obtienes a cambio comprobaciones obligatorias y puntos de fallo legibles, 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 agentivos en absoluto, "código mayormente determinista, con pasos de LLM intercalados en los puntos justos". Y esto no es solo un artefacto de cómo la gente está construyendo cosas ahora: puedes ver el patrón en LangGraph y LlamaIndex Workflows, en el flujo de trabajo híbrido sobre agentes de Jerry Liu con un bucle exterior que crea partes del grafo 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á muy sobrecargado: cuando sigo llamando a esto un grafo, no me refiero a un grafo de conocimiento. Me refiero a un grafo dirigido predefinido de cómo debería fluir el trabajo, con aristas condicionales y todo, dándole al bucle una forma en la que realmente puedas confiar.

Dónde va realmente el humano

Observa 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 que te pertenecen 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 equivocarte. El límite entre los dos bucles es la evidencia, los diffs, las pruebas, los registros y una breve explicación que los conecta. Los tipos, los puntos de enganche y las rúbricas hacen posible supervisar todo esto sin hacer mucho trabajo por cada cambio.

Es útil decirlo así: 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 protegiendo la compuerta. Hay mucho que puedes hacer para mejorar el modelo y hacer el arnés más capaz, 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 computación.

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 puntuó este artículo como 100% escrito por humanos.