Esta es la segunda publicación de una serie de dos partes sobre la ejecución de agentes de IA en equipos de ingeniería de producción en Strike. En Cómo crear la fábrica de software de Strike, analizamos el cambio inicial hacia la alineación previa, las entregas verticales y la gestión de los cuellos de botella en las revisiones. La segunda parte explora la economía y la arquitectura de la propia fábrica: contrasta las barreras de compilación deterministas con las directrices no deterministas, mide las habilidades mediante evaluaciones y mantiene el entorno del repositorio como capital institucional duradero.
Un agente consta de un modelo equipado con un armazón que opera dentro de un entorno. El armazón es la estructura que proporciona un proveedor —Claude Code, por ejemplo— y que transforma un modelo sin procesar en un agente capaz de llevar a cabo acciones. Heredamos el armazón y alquilamos el modelo, pero construimos el entorno. En concreto, damos forma a ese entorno para convertirlo en una fábrica de software: un espacio de trabajo optimizado específicamente para producir software fiable.
La economía de la fábrica
Toda fábrica de software depende de dos mecanismos distintos para garantizar la calidad: barreras deterministas y directrices no deterministas.
- Las barreras deterministas son restricciones programáticas basadas en reglas —como compiladores, linters, analizadores estáticos y conjuntos de pruebas automatizadas— en las que el código pasa o falla de forma rotunda, sin razonamiento probabilístico.
- Las directrices no deterministas consisten en instrucciones en lenguaje natural, habilidades de los agentes y barreras de seguridad para prompts que orientan al modelo hacia las decisiones de ingeniería preferidas.
Estos mecanismos crean dos estructuras de costes completamente distintas:
Una barrera determinista representa un coste fijo: inviertes una vez en crear el analizador o establecer la regla, y esta se ejecuta indefinidamente de forma gratuita, sin que intervenga ningún modelo. Una comprobación no determinista representa un coste marginal: cada ejecución consume tokens, y el consumo de tokens escala directamente con la capacidad del modelo y la frecuencia de ejecución.
Esta distinción replantea las decisiones de ingeniería. Convertir costes marginales recurrentes en inversiones puntuales de coste fijo genera un apalancamiento operativo inmediato. Cuando la evaluación humana o del modelo sigue siendo necesaria, dirigir las evaluaciones más sencillas al modelo viable más barato mantiene el gasto en tokens proporcional a la complejidad de la tarea.
El tiempo de revisión humana es la partida más cara de todas. No escala, no se puede paralelizar de forma económica y la atención humana sigue siendo estrictamente finita.
Invertir en puertas deterministas de coste fijo mantiene predecible el gasto en tokens, pero, lo que es más importante, garantiza que las solicitudes de cambios lleguen limpias, para que la revisión humana se centre en la intención arquitectónica y no en la validación mecánica.
Coacción frente a imposición
Esta distinción económica conduce directamente a una realidad operativa: las directrices no deterministas son coacción, mientras que las herramientas deterministas son imposición.
Los agentes llegan con comportamientos predeterminados distintos: hábitos aprendidos de los datos de entrenamiento y reforzados por los patrones existentes del repositorio. Por ejemplo, los agentes tienden naturalmente a generar comentarios explicativos porque la documentación está ampliamente representada en los corpus de entrenamiento. Dar a una skill la instrucción «no escribas comentarios» es coacción: estás luchando contra un comportamiento predeterminado inherente que tiende a reaparecer. La imposición determinista elimina por completo el hábito al suprimir la opción, de modo que cumplirla es la única vía para obtener una compilación correcta.
Caso práctico: comentarios y el juego de golpear topos
Gestionar los comentarios ilustra los límites de la coacción. Cuando dependíamos de reglas en los prompts para restringir los comentarios, se convirtió en un juego interminable de golpear topos: el agente seguía intentando explicar la lógica y cambiaba a comentarios insertados que imitaban las cadenas de documentación sin infringir técnicamente el prompt.
Una barrera determinista resuelve el ciclo de forma permanente. Imponer una regla que bloquee la compilación cuando falta documentación convierte el cumplimiento en un requisito estricto: las interfaces públicas deben estar documentadas o hacerse privadas para obtener una compilación correcta. La falta de documentación provoca un fallo local mediante hooks de precommit y un fallo rotundo en CI, lo que garantiza estándares coherentes en el código base, un mejor autocompletado del editor y solicitudes de incorporación de cambios limpias desde el principio.
La coherencia prima sobre acertar con la elección. Que un equipo exija documentación en todas partes o la prohíba por completo importa mucho menos que elegir un estándar e imponerlo de forma determinista. Una vez que el equipo acuerda la convención, codificarla de forma permanente en la compilación elimina por completo los debates posteriores.
Construir la cadena de montaje
El cambio de la coacción mediante prompts a la imposición determinista va mucho más allá de los comentarios del código y llega hasta la arquitectura fundamental del sistema. Tomemos como ejemplo la mensajería entre servicios a través de un bus de eventos: ciertos patrones de mensajes no son válidos objetivamente y provocan fallos en producción. Detectarlos en la revisión del código y crear habilidades de orientación ayudó al principio, pero el modo de fallo persistió hasta que creamos reglas de análisis estático personalizadas para imponer los patrones correctos en tiempo de compilación.
Otros patrones no requieren ninguna interpretación subjetiva, como las reglas de herencia de clases. Establecer un estándar por el que las clases permanezcan selladas o finales de forma predeterminada permite imponerlo en tiempo de compilación mediante reglas del linter. Revisar todo el repositorio una vez alinea el código base y elimina permanentemente la necesidad de que ingenieros o agentes deliberen sobre la herencia de clases.
Los límites del determinismo
El determinismo tiene límites claros. Un compilador puede imponer que exista un docstring, pero no puede verificar si la explicación es útil o si simplemente repite la firma de la función. Los comentarios triviales añaden ruido sin aportar valor.
La solución es sencilla: un control determinista garantiza que existan comentarios, mientras que un agente de revisión ligero evalúa si realmente aportan valor. Como esta comprobación se limita estrictamente a la claridad y la utilidad, se ejecuta de forma rentable en niveles de modelos más económicos sin necesidad de recurrir a modelos de vanguardia.
Anatomía de la fábrica
Mantener la fábrica de software implica realizar actualizaciones continuas en las habilidades, la documentación, las barreras de seguridad y la orquestación. En lugar de ser una colección improvisada de ajustes, estas mejoras se agrupan en seis capas diferenciadas:
- La columna vertebral del proceso: habilidades operativas que definen cómo se ejecuta el trabajo (como un flujo de trabajo
/implemento/submit-for-review), comprobaciones de definición de preparación y controles de revisión. - Orientación del dominio: contexto específico de cada servicio, adquirido con esfuerzo y actualmente recogido en instrucciones, cuya aplicación determinista está prevista para el futuro.
- Controles deterministas: analizadores estáticos, linters, hooks de Git y comprobaciones de CI que eliminan clases de errores sin requerir inferencia del modelo.
- Orquestación: prompts de objetivos, condiciones de parada y estrategias para coordinar la ejecución paralela de agentes.
- Higiene del corpus: deduplicación y perfeccionamiento de habilidades y documentos para garantizar que los agentes razonen a partir de instrucciones inequívocas y no contradictorias.
- Reintegración: incorporación de los aprendizajes y de la desviación respecto a las especificaciones de las ejecuciones completadas a la base fundacional.
Proximidad a la pulsación de tecla
El principio organizador para decidir dónde ubicar un control es la proximidad: cuanto más cerca se sitúe la corrección del momento en que se comete el error, menor será su coste.
Corregir los errores lo más cerca posible de la pulsación de tecla minimiza las interrupciones y los costes:
- Mientras escribes: los analizadores señalan los problemas directamente en el editor, evitando que el error se arraigue.
- Al guardar: los formateadores automáticos estandarizan el formato en segundo plano.
- Antes del commit: los hooks de Git validan los archivos preparados antes de que los cambios se confirmen localmente.
- Antes del push: las comprobaciones locales verifican las suites de pruebas antes de que el código salga de la máquina.
- Aviso del hook del agente: los hooks devuelven los errores al agente para que los corrija de forma específica durante la ejecución.
- Control estricto de CI: la última barrera que garantiza que ningún código que no cumpla los requisitos se fusione en las ramas principales.
Guía de pruebas con evaluaciones
Como la revisión humana sigue siendo nuestro recurso más limitado, automatizar la revisión por pares es esencial; sin embargo, los agentes de revisión no deterministas requieren una medición rigurosa para garantizar que realmente detecten las regresiones.
Los controles de revisión actúan como cuellos de botella necesarios. En el software financiero, los cambios requieren una revisión independiente antes de fusionarse. Este estándar se aplica por igual a la documentación y a las habilidades de los agentes, lo que garantiza que unas credenciales comprometidas o unas actualizaciones erróneas no puedan introducir modificaciones no revisadas en la base de código.
Sin embargo, la carga de la revisión debe corresponderse con el riesgo operativo. Aunque las actualizaciones de la documentación y de las habilidades requieren validación, no tienen el mismo radio de impacto que la lógica de las transacciones financieras. La iteración rápida en el entorno de la fábrica requiere revisar y fusionar con prontitud los PR de herramientas de bajo riesgo para que las ejecuciones posteriores de los agentes se beneficien inmediatamente de las mejoras.
La revisión automatizada por pares reduce la carga de trabajo humana. Por ejemplo, en un flujo de trabajo /implement, un consejo de agentes puede ejecutar en paralelo varios subagentes de revisión especializados antes de abrir un PR. Cada subagente evalúa el código según criterios diferenciados y los estándares del repositorio, y resuelve los problemas antes de involucrar a una persona. La revisión humana actúa como última barrera, garantizando que la atención de las personas se dedique a los aspectos arquitectónicos sustanciales y no a la comprobación básica con linters.
Como los agentes de revisión y las habilidades pertenecen a la capa no determinista, necesitamos evaluaciones que demuestren que realmente funcionan. Las actualizaciones de habilidades representan hipótesis comprobables: que un agente ejecutará una tarea con mayor fiabilidad. Las evaluaciones comparan las modificaciones con líneas base establecidas en tareas idénticas, convirtiendo los ajustes subjetivos de los prompts en mejoras medibles. Una vez validada, la nueva puntuación se convierte en la línea base para futuras iteraciones.
Las evaluaciones ofrecen a los prompts la misma protección contra regresiones que las suites de pruebas automatizadas ofrecen al código: sin ellas, el comportamiento se desvía; con ellas, la calidad mejora.
La visión a largo plazo
Higiene y conciliación
El crecimiento sin control convierte un corpus de instrucciones en un laberinto difícil de manejar. A medida que se acumulan habilidades, reglas y documentos, mantener la claridad requiere una eliminación activa: podar prompts redundantes, deduplicar instrucciones superpuestas y mantener una frontera estricta entre las habilidades operativas y la documentación duradera. La higiene del corpus es una tarea fundamental de mantenimiento de la fábrica; sin ella, las mejoras de ayer se convierten en la entropía de mañana.
Una redacción ambigua funciona como una API con errores. Una vez que un orquestador la interpreta y distribuye las tareas entre docenas de agentes, las ambigüedades se convierten en errores ejecutables cuyos costes se acumulan. Las modificaciones de la fábrica requieren los mismos ciclos rigurosos de retroalimentación que el software en producción: observar el comportamiento real de los agentes en tareas variadas y, después, hacer los ajustes necesarios y recalibrar.
La conciliación evita el deterioro de los cimientos. Después de la implementación y la fusión, realinear la especificación original con el código entregado garantiza que la documentación refleje la realidad. Conciliar las discrepancias con prontitud evita que las sesiones posteriores de los agentes descubran patrones contradictorios y produzcan soluciones desalineadas.
Cada ejecución se basa en la base de la ejecución anterior: una base obsoleta agrava el problema.
Dos flujos de cambios complementarios se ejecutan continuamente:
- Mejoras de la fábrica: actualizaciones de las skills, los analizadores estáticos y la orquestación que determinan cómo los agentes crean software.
- Perfeccionamiento de las especificaciones de la plataforma: actualizaciones de los registros de decisiones de arquitectura (ADR) y de los glosarios de lenguaje ubicuo que definen a partir de qué construyen los agentes.
Mantener ambas corrientes sincronizadas preserva la integridad de la base de código.
La curva de rendimientos decrecientes
Perfeccionar el entorno de los agentes sigue una curva previsible de rendimientos decrecientes. Las primeras inversiones en habilidades fundamentales y reglas en tiempo de compilación producen mejoras sustanciales en la fiabilidad. Con el tiempo, las mejoras pasan a centrarse en ganancias incrementales y en mantener unos estándares base elevados.
La madurez varía según los servicios y los repositorios. Los repositorios maduros, con conocimiento del dominio codificado y controles estrictos, operan en el extremo más plano de la curva. Los servicios menos maduros ofrecen un margen considerable para obtener mejoras rápidas de calidad mediante inversiones en el entorno de referencia.
La fábrica busca maximizar la entrega de software correcto y revisable dentro de las limitaciones de calidad y seguridad del software financiero.
Un agente más rápido que genera el doble de trabajo de revisión no es una optimización.
Aunque el consumo de tokens y los tiempos de ciclo son importantes, la métrica definitiva de la fábrica es la eficacia con la que el entorno minimiza la carga de revisión.
La ventana dorada
Trabajar como un equipo distribuido globalmente crea de forma natural periodos tranquilos fuera del horario central de colaboración: una ventana ideal para ejecutar enjambres de agentes autónomos de larga duración que se encarguen del mantenimiento más profundo del entorno, fuera de los ciclos de entrega en tiempo real.
Las actualizaciones estructurales a gran escala —como las refactorizaciones de todo el repositorio previas a la incorporación de nuevas reglas de análisis— son muy adecuadas para enjambres autónomos de varios agentes. Especificar objetivos y ejecutar barridos coordinados fuera del horario laboral produce PR apiladas listas para la revisión estructurada del equipo y traslada la generación mecánica de código fuera del horario central.
Optimizar la fábrica
El enfoque de ingeniería cambia naturalmente de escribir código repetitivo rutinario a optimizar la fábrica: crear habilidades, establecer controles deterministas, configurar enjambres de revisión y mantener la higiene del corpus.
Este enfoque a nivel de sistemas se acumula con cada ingeniero y cada ejecución de agente. Aunque los modelos fundacionales evolucionan y los arneses de los proveedores cambian, los recursos a nivel de repositorio —conjuntos de pruebas, analizadores estáticos, linters, hooks de pre-commit, controles de CI y decisiones de arquitectura codificadas— conservan su valor entre generaciones de modelos.
Alquilamos modelos externos y heredamos los arneses de los proveedores, pero somos los propietarios del entorno y lo construimos. Automatizar las restricciones mecánicas de forma determinista reserva la atención humana para la arquitectura central, la seguridad y el diseño de producto.
