Construí una fábrica de software que realmente funciona. Esto es lo que aprendí.

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 ser realmente simple, algo que funcionara sin requerir mucho cuidado. Idealmente, funcionaría completamente con mi suscripción actual de Claude.

Suena ingenuo, pero esencialmente, a menos que se integre fácilmente en mi flujo de trabajo actual, no será algo que perdure. No quiero construir esto y tener que cambiar todos mis hábitos existentes solo para usar este nuevo sistema. Sé por experiencia que si eso sucede, no funcionará para mí a largo plazo y se desvanecerá en la irrelevancia.

Entonces, en lugar de abordar esto como un gran esfuerzo, lo dividí en dos fases distintas:

1. Pre-triaje - determinar las cosas "por hacer"
2. Implementación - realmente "hacer" las cosas

En el centro está Linear, la fuente de verdad de qué trabajo necesita hacerse.

Toda fábrica de software necesita tener este repositorio centralizado de trabajo por hacer, ya sea 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 para que agentes o humanos lo tomen y completen después.

Linear con un issue generado automáticamente mediante el bucle de System Health Check

El pipeline tiene costuras definidas intencionalmente que hacen que el proceso de construir una fábrica de software sea manejable:

1. Crear trabajo (bucles con MCPs)
2. Almacenar trabajo (Linear)
3. Completar trabajo (agente SDLC)

Al dividirlo, no tienes que construir ambos lados (pre-triaje e implementación) a la vez (y recomiendo no hacerlo para evitar sobreingeniería). Linear hace que la interfaz entre lo "por hacer" y lo que estamos "haciendo" actualmente 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 necesita hacerse. Todas las salidas creadas en este paso de pre-triaje se colocan en nuestro Linear.

Algunos bucles que se ejecutan en un entorno en la nube de Claude

En este paso, tenemos tres bucles principales:

1. Bucle de System Health Check (es decir, un buscador de errores) - este bucle se ejecuta diariamente a las 5 a.m. y está conectado a varios servidores MCP: Posthog para seguimiento de errores; Vercel para diagnósticos del sistema; y Linear para crear issues.
2. Bucle de Mejoras de UX y Comentarios de Clientes - este bucle se ejecuta semanalmente los lunes a las 9 a.m., y escanea cada nuevo comentario, cada chat de soporte 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 frustración o dónde los usuarios tienen dificultades y están confundidos.
3. Bucle de Análisis de Churn - este se ejecuta diariamente a las 6 a.m. e investiga cada cliente que hizo clic en cancelar en las últimas 24 horas. Obtiene datos de pago y 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 experimentó ese momento "wow", o encontró errores. El informe se envía a Slack y el agente crea (o comenta) issues si están relacionados con clientes que se van para aumentar la prioridad.

Para ejecutar estos agentes de manera consistente, lo mantuve simple y usé Claude Code Cloud Routines.

Sin sobreingeniería con un VPS de Hetzner, una mac mini con cafeína, etc. Es, con diferencia, 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 de webhook. Y para todos los que dicen "¿pero qué hay del vendor lock-in?" - es literalmente solo algo de texto. Siéntete libre de copiar el prompt a donde quieras, 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 en la nube 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 en la nube, si es necesario), pero si configuras una conexión MCP a través de los conectores de la aplicación de escritorio, tanto tu Claude CLI local como el Claude remoto pueden usarlos, a diferencia de Codex. Esta fue la característica decisiva para mí y es lo que hace que estos bucles de agente de pre-triaje funcionen tan bien. También facilita ejecutar varias sesiones en paralelo sin preocuparte por la memoria de tu laptop.

Si solo implementas este paso de pre-triaje, aún 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 agrega más. Descubre qué rutinas puedes crear hoy que pongan trabajo nuevo y de alta calidad en tu rastreador 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 es lo que quieres si estás leyendo esto, porque ahora eres el cuello de botella en el bucle, iniciando un agente directamente en una sesión.

En cambio, lo que hice fue construir una forma de activar sesiones remotas de Claude Code directamente desde Linear.

Pasando de un issue de Linear a Claude

Funciona así:

1. Primero, identifica cómo quieres activar una nueva sesión de Claude. Para nosotros, agregamos una etiqueta 'auto' a un issue de Linear que inicia esta nueva tarea.
2. Luego, Linear envía un evento de webhook a nuestro servicio interno de API de webhook (una nueva aplicación Hono interna) que analiza el evento y luego reenvía la información correcta a la Claude Routine.
3. Finalmente, este servicio de API liviano hace una solicitud POST a Anthropic que activa la Claude Routine con un prompt inicial.

Usar una etiqueta 'auto' como activador 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 agregue la etiqueta que activa al agente para comenzar a trabajar (manteniendo al humano en el bucle). Por eso llamamos al paso 1 el paso de pre-triaje, porque algo todavía está determinando en qué trabajar realmente, ya sea mediante la intervención humana o algún agente que recorre y observa nuevos issues que se agregan e inicia nuevas sesiones de implementación.

Sin embargo, debido a que agregar una etiqueta también se puede hacer fácilmente con 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 admite webhooks, todo el "empujar cuando se agrega una etiqueta" funciona. El único inconveniente es que necesitamos tener una API pública que acepte estas rutas de webhooks y formatee los eventos y datos de carga útil para activar Claude Code. Este nuevo servicio también agrega los encabezados de autenticación correctos, por lo que no puedes hacer que Linear active la rutina directamente.

Alternativamente, podrías tener una rutina programada que se inicie cada cierto tiempo e intente implementar cualquier nuevo issue que no esté en progreso con la etiqueta auto.

Para el prompt de la rutina real, recomiendo construir una habilidad reutilizable que recorra todo el SDLC, llamada algo como /implement o /do, que facilite simplemente decir "/do ISSUE-NNN", que documente cómo pasar correctamente por los pasos de 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 rutina 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 habilidad /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>\, enviado 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écelo como "En Progreso" y actualiza el issue con cualquier cosa significativa a medida que avances. Siempre antecede los comentarios de issue de Linear con [Claude].

Entonces, en este punto tienes sesiones paralelas de Claude Remotion activadas a través de API, implementando issues, abriendo PRs (y con suerte verificando su trabajo a través de Playwright o Agent Browser).

Es esencialmente una fábrica de software completa que es totalmente observable, funciona mientras duermes y funciona completamente con tu suscripción de Claude Code.