Las fábricas de software han estado de moda estas últimas semanas. Así que construí una.
Esto es lo que aprendí, cómo funciona y cómo puedes construir una en una tarde.
Mis Objetivos
Necesitaba que fuera realmente simple, algo que funcionara y no requiriera un montón de supervisión. Idealmente, funcionaría por completo con mi suscripción actual de Claude.
Suena ingenuo, pero esencialmente, a menos que se integre fácilmente en mi flujo de trabajo existente, no va a ser algo que perdure. No quiero construir esto y tener que cambiar todos mis hábitos actuales solo para usar este nuevo sistema. Sé por experiencia que si eso pasa, no funcionará a largo plazo y se desvanecerá en la irrelevancia.
Así que, en lugar de abordar esto como un gran esfuerzo, lo dividí en dos fases distintas:
- Pre-triaje: averiguar las cosas "por hacer"
- Implementación: realmente "hacer" las cosas
En el centro está Linear, la fuente de verdad de qué trabajo hay que hacer.
Toda fábrica de software necesita tener este repositorio centralizado de trabajo por hacer, ya sean issues de GitHub, Linear o algo más. Debería ser lo que ya usas para que sea fácilmente extensible para que cualquier sistema agregue trabajo que luego los agentes o humanos puedan recoger y completar.
Linear con un issue generado automáticamente mediante el bucle de verificación de salud del sistema
El pipeline tiene costuras definidas intencionalmente que hacen que el proceso de construir una fábrica de software sea realmente manejable:
- Crear trabajo (bucles con MCPs)
- Almacenar trabajo (Linear)
- Completar trabajo (agente SDLC)
Al dividirlo, no tienes que construir ambos lados (pre-triaje e implementación) a la vez (y de hecho recomiendo no hacerlo para evitar sobreingeniería). Linear hace que la interfaz entre lo "por hacer" y lo que estamos "haciendo" esté bien definida y sea fácil de extender.
Paso de Pre-Triaje
En el diagrama anterior, el trabajo progresa de izquierda a derecha. El lado izquierdo es donde se crea el trabajo y contiene cualquier número de sistemas (ya sean humanos, agentes o APIs) que agregan a lo que hay que hacer. Todos los resultados creados en este paso de pre-triaje se colocan en nuestro Linear.
Algunos bucles que se ejecutan en un entorno cloud de Claude
En este paso, tenemos tres bucles principales:
- Bucle de verificación de salud del sistema (es decir, un buscador de errores): este bucle se ejecuta diariamente a las 5 a. m. y está conectado a algunos servidores MCP: Posthog para el seguimiento de errores; Vercel para diagnósticos del sistema; y Linear para crear issues.
- Bucle de mejoras de UX y comentarios de clientes: este bucle se ejecuta semanalmente los lunes a las 9 a. m. y escanea cada nueva sugerencia, cada chat de atención al cliente de Intercom/Fin y todas las repeticiones de sesiones de Posthog. Las repeticiones de sesiones son una mina de oro. Puedes ver dónde ocurren los clics de ira o dónde los usuarios tienen dificultades y están confundidos.
- Bucle de análisis de cancelaciones: este se ejecuta diariamente a las 6 a. m. e investiga a cada cliente que hizo clic en cancelar en las últimas 24 horas. Extrae datos de pago y de usuario de Stripe (incluyendo su correo electrónico/ubicación), y luego revisa la repetición de sesión de este cliente en Posthog para ver qué estaban haciendo antes de cancelar. Extraemos su uso de Supabase para ver si era un ICP incorrecto, nunca experimentaron ese momento "wow", o encontraron errores. El informe se envía a Slack y el agente crea (o comenta) issues si están relacionados con clientes que se cancelan para aumentar la prioridad.
Para ejecutar estos agentes de manera consistente, lo mantuve simple y usé Claude Code Cloud Routines.
Nada de sobreingeniería con un VPS de Hetzner, un Mac mini con cafeína, etc. Es, por mucho, la forma más fácil que he encontrado de aprovechar tu suscripción existente de Claude Code y crear agentes siempre activos que se puedan activar según un horario o mediante un evento webhook. Y para todos los que dicen "¡¿pero qué pasa con el vendor lock-in?!" — es literalmente solo texto. Siéntete libre de copiar el prompt a donde quieras, yo solo quería la forma más fácil y barata de configurar algo que funcione de manera confiable.
Y otra razón para usar Claude Code Cloud Routines es que los entornos cloud de Anthropic tienen una paridad cercana con Claude ejecutándose localmente.
Claude Routines en la nube
Obviamente no tienen tus variables de entorno (que se pueden agregar a la configuración del entorno cloud, si es necesario), pero si configuras una conexión MCP a través de los conectores de la aplicación de escritorio, tanto tu CLI local de Claude como el Claude remoto pueden usarlos, a diferencia de Codex. Esta fue la característica clave para mí y es lo que hace que estos bucles de agentes de pre-triaje funcionen tan bien. También facilita ejecutar varias sesiones en paralelo sin preocuparte por la memoria de tu portátil.
Si solo implementas este paso de pre-triaje, aun así obtendrás mucho apalancamiento, incluso si no construyes el siguiente paso donde se completa el trabajo.
Empieza pequeño con un solo bucle, pruébalo, refínalo, luego añade más. Averigua qué rutinas puedes crear hoy que pongan trabajo nuevo y de alta calidad en tu gestor de issues existente y luego haz lo que ya haces hoy para la implementación.
Paso de Implementación
La versión más básica del paso dos es darle a tu agente un ID de issue y decirle que lo complete. Esto es lo que la mayoría de la gente ya hace hoy cuando trabaja con agentes. Sin embargo, probablemente no sea lo que quieres si estás leyendo esto, porque ahora eres tú el cuello de botella en el bucle, iniciando un agente directamente en una sesión.
En su lugar, lo que hice fue construir una forma de activar sesiones remotas de Claude Code directamente desde Linear.
Desde un issue de Linear hasta Claude
Funciona así:
- Primero, identifica cómo quieres activar una nueva sesión de Claude. Para nosotros, añadimos una etiqueta 'auto' a un issue de Linear que inicia esta nueva tarea.
- Luego, Linear envía un evento webhook a nuestro servicio de API webhook interno (una nueva aplicación Hono interna) que analiza el evento y luego reenvía la información correcta a la Routine de Claude.
- Finalmente, este servicio API liviano realiza una solicitud POST a Anthropic que activa la Routine de Claude con un prompt inicial.
Usar una etiqueta 'auto' como desencadenante nos permite controlar la ejecución automática de nuevas sesiones de Claude.
Por defecto, no hacemos que los pasos de pre-triaje incluyan estas etiquetas 'auto' y requerimos que un humano añada la etiqueta que activa al agente para comenzar el trabajo (manteniendo al humano en el bucle). Por eso llamamos al paso 1 el paso de pre-triaje, porque algo todavía está averiguando qué trabajar realmente, ya sea mediante intervención humana o algún agente que haga bucles y observe la adición de nuevos issues e inicie nuevas sesiones de implementación.
Sin embargo, debido a que añadir una etiqueta también es fácilmente realizable por un agente, podríamos hacer que los bucles de pre-triaje creen nuevos issues con la etiqueta 'auto' por defecto, lo que inicia una nueva sesión de Claude. Usar una etiqueta se convierte en una forma muy flexible de iniciar nuevo trabajo de implementación, ya sea automáticamente por un agente o por nosotros los humanos.
Un servicio de enrutamiento liviano para iniciar sesiones de Claude
Debido a que Linear soporta webhooks, todo el "empujar cuando se añade una etiqueta" funciona. La única desventaja es que necesitamos tener una API pública que acepte estos webhooks y formatee los eventos y datos del payload para activar Claude Code. Este nuevo servicio también añade los encabezados de autenticación correctos, por lo que no puedes hacer que Linear active la Routine directamente.
Alternativamente, podrías tener una rutina programada que se inicie cada cierto tiempo e intente implementar cualquier issue nuevo que no esté en progreso con la etiqueta auto.
Para el prompt real de la rutina, recomiendo construir una skill reutilizable que recorra todo el SDLC, con un nombre como /implement o /do, que facilite simplemente decir "do ISSUE-NNN", que documente cómo seguir correctamente los pasos para obtener el contexto del issue, implementar el trabajo, verificar en el navegador, crear el PR y estar atento a los comentarios.
Luego, el prompt de la Routine de Claude, activado por el evento de Linear, puede tener un prompt muy simple. Aquí está el mío:
Recupera el issue proporcionado y usa la skill /do para implementar el cambio solicitado y crear un pull request. Solo obtén el issue exacto proporcionado. Si ya está completo o en progreso, detente.
La referencia del issue no aparece en este mensaje; llega como un mensaje de seguimiento separado envuelto en una etiqueta
<routine-fire-payload>, enviada inmediatamente después de este, en la misma sesión. Espera ese mensaje antes de decidir si se proporcionó un issue. Solo concluye que el issue no existe, o que no se dio ninguno, después de verificarlo en el mensaje<routine-fire-payload>y confirmar que el issue referenciado realmente no existe.Cuando comiences a trabajar, comenta en el issue, establécela como "En Progreso" y actualiza el issue con cualquier cosa significativa a medida que avances. Siempre prefija los comentarios de los issues de Linear con [Claude].
Así que en este punto tienes sesiones paralelas de Claude Remotion activadas por API, implementando issues, abriendo PRs (y con suerte verificando su trabajo mediante Playwright o Agent Browser).
Es esencialmente una fábrica de software completa que es totalmente observable, se ejecuta mientras duermes y funciona completamente con tu suscripción de Claude Code.
