Adoptar el modelo de fábrica de software: gatear, caminar, correr

El enfoque de fábrica de software (un bucle agéntico cerrado que se ejecuta en la nube) está ganando popularidad, pero su adopción puede resultar abrumadora. En este artículo, detallaré los pasos de "gatear, caminar y correr" para realizar la transición desde agentes locales e interactivos hacia el desarrollo automatizado en la nube.

Gatear

Muchos líderes de ingeniería y equipos de plataforma con los que hablo ya han comenzado la fase de "gateo" en la construcción de una fábrica de software mediante la creación de automatizaciones simples usando agentes en la nube.

Piensa en estas automatizaciones como Disparador → Actividad del Agente.

Por ejemplo:

• Reproducción y triaje de incidencias: tener un agente que revise todas las nuevas incidencias reportadas, las reproduzca y las etiquete.
• Revisión de código: Revisar automáticamente los PRs a medida que se abren y dejar comentarios.
• Monitoreo: tener un agente que responda a una alerta de Sentry, depure y solucione un problema.
• Auto-reparación de CI: arreglar CI rotas identificando PRs para revertir o conflictos de fusión para resolver.
• Actualización automática de documentación: actualizar la documentación dirigida al usuario y generar registros de cambios (changelogs).
• Verificación: Los agentes de uso del navegador y uso de la computadora realizan QA visual y verifican los cambios.
• Correcciones simples de bugs: los agentes identifican y corrigen problemas simples reportados por usuarios.

Lo común en todos estos enfoques es que automatizan una parte discreta del ciclo de vida del software. Comenzar con automatizaciones simples es un enfoque de bajo riesgo y bajo costo, y ayuda a desarrollar la intuición sobre cómo usar eficazmente los agentes en tareas más complejas y de múltiples etapas.

Ejemplo de automatización para monitoreo de alertas

Estas automatizaciones podrían estar construidas utilizando infraestructura propia (por ejemplo, colocando el SDK de Claude Code en un contenedor Docker y conectando un servidor para activarlo), o podrían usar una plataforma genérica de automatización de agentes en la nube diseñada para ejecutar agentes basándose en disparadores. También podrían utilizar una plataforma dedicada exclusivamente a una etapa del ciclo (por ejemplo, un revisor de código agéntico dedicado o un SRE de IA).

Comenzar con un parcheado de automatizaciones puntuales está bien, pero la mayoría de los equipos eventualmente encuentran límites con este enfoque.

Específicamente:

• Dependiendo de cómo estén configuradas, estas automatizaciones podrían no compartir contexto. Esto significa que, al mejorar un aspecto (digamos, la revisión de código), esas mejoras no se trasladan a otras etapas, como el triaje y el QA.
• No hay una visión global de si todas estas automatizaciones únicas realmente mejoran la productividad general, ni una forma sistemática de probar y mejorar las métricas de alto nivel que te importan, como costo por PR, tiempo de ciclo, porcentaje de automatización, etc. Para rastrear esto, necesitas un sistema que funcione a través de todas las etapas de desarrollo.
• Las soluciones puntuales crean cada una su propia carga de configuración y mantenimiento. Crean una superficie de seguridad más grande para gestionar. No tienen una interfaz unificada para la observabilidad. Los equipos eventualmente desean configuración centralizada, auditoría y gobernanza.

Caminar

Todos estos problemas apuntan a la necesidad de un enfoque más holístico. Las organizaciones que han pasado por la fase de "gateo" se preguntan: "¿cuál es el sistema que queremos para escalar verdaderamente el desarrollo agéntico?"

Más específicamente, se preguntan:

• ¿Dónde debería ocurrir el desarrollo? ¿Localmente o en la nube? ¿A través de qué interfaces?
• ¿Cómo se ve un proceso de desarrollo automatizado exitoso? ¿Cuáles son las métricas clave?
• ¿Cuál es nuestra postura de soberanía de IA? ¿Qué tan importante es poseer nuestros datos de agentes de codificación? ¿Qué tan dependientes deberíamos ser de los proveedores de modelos?
• ¿Cómo planeamos mejorar nuestro proceso de desarrollo con el tiempo? ¿Cómo controlamos los costos mientras aceleramos la velocidad de entrega? ¿Cómo sabemos que estamos mejorando?
• ¿Cómo nos preparamos para el futuro a medida que los modelos y agentes mejoran? ¿Estamos considerando el riesgo regulatorio que podría impactar el acceso a los modelos?
• ¿Cómo deberían participar exactamente los ingenieros en el proceso de desarrollo? ¿Y los diseñadores, PMs y otros creadores?
• ¿Cómo aseguramos el desarrollo? ¿Cuál es nuestro plan si nuestro proceso de producción de software se ve comprometido?

La mayoría de los líderes de ingeniería y equipos de plataforma que reflexionan profundamente sobre estas preguntas llegan a algo similar a un enfoque de fábrica de software en la nube. Ellos quieren:

• Desarrollo en la nube por defecto, porque es más seguro dar a los agentes entornos aislados (sandboxes) que dejarlos sueltos localmente.
• Gobernanza centralizada de los agentes de codificación y las herramientas y sistemas a los que acceden.
• Trazas completas de lo que han hecho los agentes, para auditoría y comprensión de la productividad.
• Opcionalidad alrededor de modelos y arneses (harnesses), para minimizar riesgos y optimizar el rendimiento.
• Integración del desarrollo en todas las herramientas que tu equipo ya utiliza (por ejemplo, Slack/Teams, Jira, Github, etc.).
• Vías de escape para que los humanos tomen el control, ya sea dirigiendo agentes en vivo o trayendo el trabajo al bucle interno de desarrollo.
• Una capa de contexto compartido que funcione entre agentes en todas las fases del desarrollo.
• Un enfoque que permita pruebas, evaluaciones y benchmarks para que tu equipo tenga confianza en que el sistema mejora con el tiempo.

Una vez que una empresa decide adoptar un enfoque de fábrica, la pregunta pasa a ser: ¿cómo llegas allí desde tus automatizaciones puntuales existentes? Esto generalmente se reduce a decidir si (1) construyes más infraestructura alrededor de esas automatizaciones o (2) haces la transición a una plataforma como Warp Factories, que proporciona la infraestructura de fábrica.

Ten en cuenta que no encuadraría esto como una decisión tradicional de construir vs. comprar. Sin importar el camino que tomes, debes esperar que tu equipo interno haga algo de construcción, porque para que un enfoque de fábrica funcione, esa fábrica debe estar profundamente integrada en el contexto y los flujos de trabajo de tu equipo. Es más una cuestión de si construyes tu infraestructura de automatización totalmente desde cero, o si colaboras con quienes te proporcionan una ventaja inicial.

Por ejemplo, sin importar el camino que tomes, debes esperar construir habilidades específicas de la organización y ajustarlas para tu base de código. Debes esperar exponer y configurar MCPs específicos de la organización y fuentes de contexto internas. Pero, quizás no quieras construir infraestructura en la nube para ejecutar y gestionar agentes, dirigirlos, pasarles el trabajo, medir su eficacia, realizar uso de la computadora, y así sucesivamente. La regla práctica es enfocarse en construir las piezas que son específicas de tu organización, no las que necesita cualquier organización.

Cualquiera que sea el enfoque que tomes, sugiero que el hito más importante en la fase de caminar es desplegar una primera fábrica de extremo a extremo sobre una superficie de producto simple. Podría ser tu sitio de marketing o una aplicación interna.

Comenzar con un proyecto simple tiene la ventaja de poner en marcha todo un bucle con bajas apuestas y mínima complejidad. Añadir más repositorios, líneas de código, dependencias de servicios, partes interesadas humanas, etc., aumenta la complejidad y puede llevar a la sensación de que no estás listo para la automatización. Es mejor afinar primero un bucle simple.

El objetivo es un sistema multi-agente que vaya desde triaje → especificación → implementación → revisión → verificación → monitoreo. Con más detalle:

1. Una nueva incidencia entra en el sistema, ya sea a través de un humano o un agente de monitoreo.
2. El agente de triaje se ejecuta e intenta entender y reproducir la incidencia. Si determina que la tarea es automatizable → la pasa al agente de Implementación. Si necesita especificaciones debido al alcance → hace que el agente de especificaciones itere con un humano para crear una especificación. Si es ambigua → obtiene entrada humana y vuelve a ejecutar, o simplemente decide aparcar la incidencia por ahora.
3. [Si es necesario] El agente de especificaciones se ejecuta, un humano revisa las especificaciones y luego las pasa al agente de implementación.
4. El agente de implementación escribe código.
5. El agente de revisión de código revisa el código.
6. El agente de verificación realiza uso de la computadora u otra verificación.
7. Un humano revisa el código y la salida de verificación. Si es necesario, vuelve al paso 2, 3, 4 o 5.
8. CI / CD.
9. Entregar (Ship it).
10. El agente de monitoreo se ejecuta y crea incidencias si es necesario, completando el bucle.

Internamente en Warp, nuestra fábrica de fase caminar automatiza aproximadamente el 75% de los cambios en warp.dev, nuestro sitio de marketing. A diferencia de Warp Terminal (65k estrellas en GitHub, casi un millón de desarrolladores activos, 1M de líneas de Rust nativo), nuestro sitio de marketing es una aplicación bastante simple. Ten en cuenta que por "automatizar" me refiero a ir desde la entrada humana hasta una función entregada completamente a través de la fábrica, con puntos de contacto humanos mínimos además de describir el cambio que queremos, ya sea en Slack o en nuestro rastreador de tareas.

Correr

Solo cuando tengas el bucle básico establecido en un proyecto simple deberías escalar a proyectos más complejos. Escalar fábricas requiere infraestructura más robusta.

Específicamente, a medida que escalas, surgen ciertos cuellos de botella:

• Hacer funcionar los entornos de desarrollo remotos en proyectos grandes es difícil. Más repositorios, líneas de código y dependencias de servicios hacen que la automatización sea más difícil.
• A medida que tienes más habilidades y código, etc., se vuelve más difícil saber si los cambios que estás haciendo en tus fábricas están teniendo un impacto positivo en el desarrollo o solo causando inestabilidad (churn).
• Naturalmentee incurres en mayores riesgos de costos a medida que los agentes trabajan en bases de código más complejas porque necesitas modelos más potentes y los agentes necesitan ejecutarse durante más tiempo. El enrutamiento de modelos y la elección de arnés (harness) se vuelven más importantes.
• La seguridad y la auditoría se vuelven más importantes cuanto más llevas el enfoque de fábrica a aplicaciones críticas para el usuario.
• Más partes interesadas de la aplicación significa más coordinación humana y aprobaciones. Querrás una solución de fábrica que permita entradas multipersona y registros de auditoría.
• Inevitablemente, los PRs comenzarán a acumularse, por lo que querrás una estrategia definida para qué código se revisa, cómo usas la verificación y el QA agénticos.
• Querrás herramientas más robustas para cerrar el bucle, asegurándote de que los cambios que se envían a producción sean de alta calidad, no fallen, etc.

Hacer funcionar fábricas escaladas será, en mi opinión, uno de los desafíos de ingeniería de software más interesantes en los próximos años; la ingeniería de software se está convirtiendo en ingeniería de fábricas. Las organizaciones que puedan hacer sus fábricas robustas, confiables y auto-mejorables podrán entregar más a mejor costo y tendrán una ventaja competitiva.

Para que las fábricas funcionen realmente a pleno rendimiento se requiere una inversión significativa. En Warp, pensamos en esto como construir completamente tu pila de fábrica:

Cubro cada una de estas capas en detalle en este post:

https://x.com/zachlloydtweets/status/2097739116720910619

Algunas claves para destacar que podrían no ser obvias:

• Fábricas-como-código: una de las decisiones clave que puedes tomar es definir tus fábricas como código. Esto permite probar diferentes configuraciones de fábrica para ver cuáles son más eficientes, de mayor calidad, etc.
• Multi-modelo y multi-arnés: debes asegurarte de que tus fábricas puedan usar los últimos modelos, tanto de frontera como de pesos abiertos, y usar diferentes arneses de agentes de codificación como Claude Code y Codex.
• Propiedad de datos: debes asegurarte de almacenar y poseer todos los datos que salen de tu fábrica; esta es la materia prima para mejorar sus operaciones.

En una fábrica funcionando a pleno rendimiento, la característica clave es que es un sistema de bucle cerrado, medible y mejorable. Este debería ser el objetivo. En tal sistema, todos trabajan desde el mismo contexto, públicamente, de manera totalmente auditada y observada. Los propios agentes observan las habilidades y la configuración que impulsan el sistema y sugieren mejoras. Los ingenieros de plataforma pueden extender el sistema para integrarlo en todos los sistemas internos. Los líderes de ingeniería pueden ver métricas de productividad y entender qué cambios se están haciendo para mejorarlas. Todo funciona empíricamente, no por corazonadas.

En Warp, nos estamos acercando a esta visión. Cada día trabajamos todos públicamente, ajustando nuestra fábrica, reduciendo costos y mejorando el throughput y la calidad.

Nuestra misión es proporcionar a los mejores equipos de ingeniería del mundo las herramientas para construir, medir y optimizar sus propios flujos de trabajo utilizando cualquier modelo subyacente y arnés sobre infraestructura abierta. Estas capacidades ayudarán a los equipos a entregar mejor software más rápida y eficientemente.

Warp Factories está actualmente en acceso temprano. Las empresas calificadas obtienen $10k de uso de fábrica.