- Una fábrica de software opera a gran escala envolviendo en un arnés bucles que repiten la recopilación de contexto, la acción y la verificación, y se divide en fábricas iluminadas, donde los humanos toman decisiones, y fábricas oscuras, donde incluso la revisión de código queda en manos de las máquinas
- La generación de código, las pruebas y los escaneos escalan casi sin costo, pero la revisión y el juicio humanos son difíciles de escalar; por eso, el cuello de botella no es la cantidad generada, sino la velocidad para validar los resultados de forma barata y confiable
- Si las personas no leen el código, se acumula una deuda de comprensión (comprehension debt) entre el tamaño del código y lo que los humanos entienden; incluso si las pruebas siguen pasando, en sistemas complejos operados durante mucho tiempo los problemas de mantenimiento pueden aparecer tarde
- La automatización completa debe permitirse solo en bucles cortos con criterios de decisión inmediatos, que no deriven con el tiempo y sean difíciles de manipular; en tareas donde una mala decisión tiene alto costo y amplio impacto, como autenticación, pagos o API públicas, debe mantenerse la revisión humana
- El rol del ingeniero pasa de escribir directamente cambios individuales a diseñar y proteger el bucle externo, verificando la evidencia del diagnóstico, la implementación y las pruebas realizadas por los agentes, y asumiendo la responsabilidad por la aprobación y los resultados
De los bucles a las fábricas de software
- La idea de convertir el software en un proceso de producción repetible y medible se remonta a “The economics of program production”, publicado por Bob Bemer en 1968
- Como era difícil producir ideas en serie como piezas de automóvil, durante el último medio siglo estos intentos en general no estuvieron a la altura de las expectativas
- Los cambios de los últimos dos años han sido lo bastante grandes como para volver a examinar la vieja idea de la fábrica de software, pero las trampas del pasado pueden presentarse como nuevas oportunidades
- Todo el sistema se compone de tres capas: bucle, arnés y fábrica
- Un bucle es la unidad mínima de trabajo en la que un agente reúne contexto, actúa y luego verifica el resultado, repitiendo hasta cumplir una condición de finalización
- La ingeniería de bucles consiste en diseñar pequeños sistemas que le proporcionan prompts al agente, en lugar de que una persona escriba un prompt cada vez
- El arnés incluye el sandbox donde se ejecuta el bucle, las herramientas disponibles, la memoria que se conserva entre ejecuciones y las compuertas que determinan si algo está terminado
- Un modelo sin arnés puede repetirse indefinidamente, así que el arnés vuelve al bucle útil y seguro
- Una fábrica de software es una estructura que toma elementos de una cola de trabajo, ejecuta al mismo tiempo múltiples bucles basados en arneses y, tras pasar por compuertas de revisión, los envía a producción
- Se parece más a un organigrama compuesto por bucles que a un único agente más grande
- La unidad de trabajo del ingeniero también se desplaza de cambios de código individuales a bucles, arneses y flujos entre bucles
Flujo de trabajo y cuellos de botella de la fábrica
- La visión del liderazgo de ingeniería, la intención de los ingenieros y las señales provenientes de incidentes y solicitudes de usuarios entran en una única cola de trabajo
- Un arnés selecciona elementos y crea cambios, mientras CI, pruebas, análisis estático y distintos escaneos los inspeccionan en paralelo
- Si la compuerta de revisión los aprueba, los cambios se despliegan, y los datos de monitoreo de producción vuelven como señales que disparan nuevo trabajo
- La generación, las pruebas y los escaneos pueden escalar con un costo despreciable, pero el juicio humano en la compuerta de revisión es difícil de escalar
- Poder aumentar la velocidad de desarrollo y la frecuencia de despliegue depende de cómo se maneje este cuello de botella de juicio
Fábricas oscuras y deuda de comprensión
- En manufactura, una fábrica oscura es una instalación que opera con las luces apagadas porque las máquinas no necesitan iluminación
- FANUC opera fábricas de este tipo desde 2001, y Xiaomi también abrió en 2024 una fábrica oscura altamente automatizada
- En una fábrica de software oscura, las personas no leen el código y los cambios se despliegan solo con la verificación realizada por las máquinas que lo crearon
- Aquí la oscuridad no implica algo negativo, sino que las personas desaparecen del proceso de escribir, revisar y desplegar diffs
- Al eliminar la revisión humana, desaparece la fricción y parece que el throughput vertical del equipo aumenta drásticamente
- Sin embargo, por sus costos ocultos, este flujo de trabajo es más difícil de sostener a largo plazo de lo que parece
- La orquestación, el prototipado basado en sandboxes y las llamadas a herramientas seguirán volviéndose más potentes, pero los arneses por sí solos no bastan para mantener la calidad de una base de código a largo plazo
- La deuda de comprensión es la brecha entre la cantidad de código existente y la cantidad de código que los humanos realmente entienden
- Las fábricas oscuras acumulan deuda de comprensión rápidamente, incluso mientras las pruebas pasan
- A diferencia de los cambios inmediatos en áreas pequeñas del código o los proyectos de fin de semana, los sistemas existentes y complejos desarrollados durante más de 10 años deben seguir manteniéndose a un ritmo profesional
- Después de operar un proyecto de automatización durante 3 a 6 meses, el código no leído puede volverse abrumador
- Cuando Dex Horthy operó durante unos 4 meses una fábrica totalmente automatizada en la que los humanos no veían el código generado, encontrar la causa de los problemas requirió una ardua depuración manual
- Cuanto más se maximiza el uso de tokens, más disminuye silenciosamente la comprensión humana del sistema
- El fracaso puede llegar tarde y en silencio, en lugar de que todo un sistema cuyas pruebas pasaban colapse de golpe
Por qué la verificación se vuelve la restricción, no la generación
- La contrapresión (back pressure) es el principio de otorgar autonomía a los bucles solo hasta donde se pueda verificar de forma barata y confiable
- El problema central es la brecha entre una capacidad de generación casi ilimitada y la atención humana finita
- Si la etapa de verificación no se amplía, los cambios se acumulan; y si solo se aumenta el volumen sin compuertas confiables, aparecen PR de baja calidad y defectos fabricados
- Las mejoras en el rendimiento de los modelos no reducen automáticamente la distancia entre generación y verificación
- El valor de una buena arquitectura se revela a lo largo de meses y años, no en segundos o minutos
- Es difícil calcular una función de costo limpia o una señal de evaluación inmediata para la excelencia arquitectónica, y por eso también es difícil entrenar decisiones de diseño complejas como buenos ejemplos
Cómo volver a encender las luces
- Incluso en una fábrica iluminada, los agentes se encargan de la mayor parte de la implementación, pero en los puntos donde el costo de un mal juicio es alto se encienden las luces y las personas leen los resultados antes de desplegarlos
- El juicio humano no debe agregarse solo al code review final, sino moverse a las etapas de producto, diseño y arquitectura antes de que el agente inicie el bucle
- Revisar con anticipación durante una hora un plan de 200 líneas puede reducir una larga revisión posterior en la que haya que escarbar entre 2,000 líneas de código generado para encontrar decisiones de diseño
- Cuanto más costosa y duradera sea una decisión, más deben participar las personas antes de la implementación; e incluso si hubo revisión previa, deben revisar directamente el diff cuando sea necesario
- Las redes de seguridad no están formadas por técnicas nuevas, sino por prácticas de arquitectura conocidas
- Usar buenos tipos y firmas de métodos para detectar errores en el compilador en lugar de en producción
- Crear puntos de prueba (seams) para fijar el comportamiento y poder observar los cambios
- Organizar el código para que tanto personas como modelos encuentren fácilmente lo que necesitan
- Mantener la pila de llamadas corta y fácil de leer
- Definir límites claros entre componentes para limitar el alcance del impacto de los cambios
- Usar inyección de dependencias para poder reemplazar componentes
- Esta arquitectura cumple un segundo rol: bloquear los errores de los agentes de codificación automática de una manera barata y difícil de engañar
- Agentes como Claude Code y Codex están entrenados con aprendizaje por refuerzo en el uso de sus propios arneses y herramientas, pero no ofrecen mantenibilidad a largo plazo
- Las redes de seguridad deben existir fuera del modelo, y la inversión en arquitectura se convierte en una forma de obtener más autonomía de manera segura
- Combinados con infraestructura segura, algunos bucles cortos y de bajo riesgo pueden ejecutarse sin supervisión
- Por ejemplo, cada noche un cron de GitHub Actions podría corregir exactamente un antipatrón, una infracción de lint o una prop innecesariamente opcional, hacer commit y abrir un PR pequeño
- Los objetivos con alto costo de falla, como sistemas de autenticación, motores de pago o contratos de API públicas, deben ser revisados por personas con conocimiento del sistema y criterio
Bucles que califican para automatización
- Para que un bucle se automatice por completo, la verificación debe ejecutarse de forma barata y frecuente y depender de criterios difíciles de engañar
- Esto incluye jueces que devuelven claramente verdadero o falso, compuertas de tipos, pruebas basadas en propiedades y agentes de revisión combinados con rúbricas de evaluación reales
- El juicio debe ser inmediato y no debe derivar con el tiempo
- Se puede automatizar cuando el estado de finalización puede ser demostrado también por una máquina, no solo por una persona
- Los bucles cortos son más fáciles de verificar que los largos
- Según la regla práctica de Dex, los agentes funcionan bien en 3 a 10 pasos, pero empiezan a perder el hilo cuando superan los 20 pasos
- Cuanto más se acumula el contexto, mayor es la probabilidad de que el agente se desvíe; los bucles largos esconden errores en rincones
- Si el costo de una respuesta incorrecta es alto y solo una persona puede detectarla, hay que encender las luces
- Esto incluye bugs sutiles en producción que no capturan las pruebas, alcances de impacto amplios y decisiones que determinan un año o más de trabajo
- En estos casos, la atención humana es el producto real y un recurso caro pero indispensable
- Configurar todos los bucles en el mismo modo falla en ambos extremos
- Si todo opera en la oscuridad, quizá haya que desmontar el sistema unos meses después
- Si todo opera con luces, la revisión se convierte en un cuello de botella enorme
- La habilidad clave es decidir en qué punto de cada bucle encender las luces
Grafos y máquinas de estado que envuelven los bucles
- Aunque se lo llame máquina de estados finitos o llamadas condicionales a servicios, el trabajo de los agentes probablemente termine organizado como un grafo dirigido
- Cada nodo es un paso explícito y las aristas entre nodos son condiciones explícitas
- Como todo código puede representarse como un grafo de flujo de control, la estructura en sí no es nueva
- La autonomía del agente queda limitada al interior de cada nodo, no a todo el grafo
- El intento nuevo fue eliminar los diagramas de flujo y hacer que el modelo eligiera su camino en cada llamada a herramientas hasta declarar por sí mismo que había terminado
- Después de chocar con bases de código antiguas, el movimiento para recuperar el control del flujo equivale a restaurar grafos tradicionales alrededor de los bucles
- La corrección de bugs avanza de forma distinta en un bucle puro y en un grafo
- En un bucle puro, la investigación del problema, el cambio de código, la selección y el orden de ejecución de pruebas, los reintentos y el juicio de finalización se deciden sobre la marcha
- En un grafo, la reproducción del bug o la solicitud de información adicional, el análisis de la causa, la corrección, las pruebas y la revisión se definen de antemano como rutas
- Una falla en las pruebas vuelve a la etapa de corrección; un éxito pasa a revisión, y solo se completa si fue aprobado
- El agente actúa inteligentemente dentro de cada nodo, pero no puede desviarse por rutas no permitidas
- El grafo es una forma de visualizar la contrapresión
- A cambio de renunciar a parte de la libertad del agente, se obtienen verificaciones obligatorias y puntos de falla legibles
- Si una ejecución falla, se puede identificar qué nodo la detuvo
- Como en el enfoque de 12-factor agents, muchos sistemas de agentes se parecen más a “código mayormente determinista con pasos de LLM mezclados en los lugares adecuados”
- El mismo patrón aparece en LangGraph y LlamaIndex Workflows, en los grafos híbridos de flujos de trabajo sobre agentes de Jerry Liu y en las máquinas de estado y el modelo de actores conectados por David Khourshid
- Aquí, grafo no se refiere a un grafo de conocimiento, sino a un grafo dirigido que define de antemano el flujo de trabajo y las aristas condicionales
Los humanos son dueños del bucle externo
- Los humanos no desaparecen de la fábrica, sino que se desplazan de la línea de ejecución al bucle externo
- El agente realiza el bucle interno: investigar bugs, redactar diagnósticos, implementar correcciones, ejecutar pruebas y reportar resultados
- El ingeniero decide si el problema se está resolviendo de la manera correcta, verifica el diagnóstico y la implementación, aprueba el cambio y asume la responsabilidad por resultados incorrectos
- En el límite entre el bucle interno y el externo se encuentra la evidencia: diffs, pruebas, logs y explicaciones breves que los conectan
- Con tipos, puntos de prueba y rúbricas de evaluación, se puede supervisar la ejecución de agentes sin hacer mucho trabajo manual en cada cambio
- La posición del ingeniero pasa de escribir cambios directamente en la línea de producción a diseñar la línea y proteger sus compuertas
- Los modelos y arneses pueden mejorar, pero será difícil automatizar el juicio humano que identifica problemas caros a largo plazo
- Lo más peligroso es convertir todo el espacio de trabajo en oscuridad, hasta que las personas no puedan ver qué está ocurriendo ni siquiera encontrar el interruptor de la luz
Aún no hay comentarios.