Will Larson prueba el patrón ‘software factory’ en Imprint

El patrón software factory: agentes que iteran sobre un objetivo

El término software factory empieza a sonar con fuerza entre los equipos de ingeniería que reorganizan su forma de trabajar alrededor de agentes de IA. La idea de fondo es simple: en lugar de pedirle a un agente una tarea concreta, se le entrega un objetivo amplio y un sistema de medición, y se deja que el agente itere solo, creando tickets, escribiendo código y verificando resultados hasta converger. Will Larson, fundador de Imprint, lo describe así en su blog: el patrón consiste en iterar sobre un objetivo amplio y dejar que el harness (la infraestructura que orquesta agentes) lleve el progreso adelante.

La paternidad del término es discutida. Larson apunta a Justin McCarthy, que en febrero de 2026 publicó Software Factories And The Agentic Moment como uno de los textos que más han influido en la conversación. La popularidad del concepto, eso sí, se explica menos por el nombre y más por algo que varias empresas estaban descubriendo a la vez: los agentes ya saben escribir código razonablemente bien, pero fracasan cuando se les pide decidir si van en la dirección correcta.

Cómo lo implementó Will Larson en Imprint

La primera versión del patrón en Imprint es modesta pero ilustrativa. Larson la ejecuta por ahora en su entorno local, pero prevé moverla al Agent Fleet, el orquestador interno de la compañía inspirado en el sistema Minions de Stripe.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El flujo tiene cuatro pasos:

Auditar el objetivo del proyecto. Un agente lee un proyecto de Linear y verifica dos cosas: que exista un RFC en Notion con la definición del objetivo, sus métricas y el approach general, y que haya un dashboard en Datadog o consultas en Snowflake que midan progreso. Si falta alguno, itera con el humano hasta crearlo.
Revisar métricas e issues. Lee el estado actual de las métricas y de los tickets. Si detecta trabajo nuevo, lo agrega al proyecto. Si un ticket cambió de estado, lo actualiza.
Trabajar en tareas no bloqueadas. Lo habitual es abrir un pull request, actualizar uno existente, pedir review o hacer una pregunta de aclaración.
Decidir el siguiente paso. Si el proyecto está actualizado, toma la siguiente tarea. Si la definición del proyecto lleva tiempo sin actualizarse, vuelve al primer paso.

Larson destaca algo que no esperaba: el patrón lo obligó a externalizar estado que tenía en la cabeza. Antes ya le pedía a agentes que iteraran sobre proyectos específicos en Linear, pero no tenían cómo evaluar si el rumbo era el correcto ni si faltaban tareas. Con la fábrica, sí.

Otro caso de uso que le ha resultado potente es el monitoreo post-lanzamiento. Por ejemplo, Imprint implementó passkeys a principios de 2026, pero Larson admite que pasan meses sin volver a mirar las métricas de adopción. Un factory en modo post-release poco frecuente lo detectaría al instante.

La cadena de migraciones que hizo posible la fábrica

Lo más interesante de la narrativa de Larson es que el patrón no funciona de forma aislada: depende de una pila entera que Imprint fue construyendo durante meses. Su bitácora de 2026 lo deja claro:

Enero: todos los ingenieros usando Claude Code a diario.
Marzo: el resto de la compañía también, entre Claude Code y Claude Cowork.
Abril: cambio de modelo de desarrollo local. El cuello de botella ya no era el checkout ni los worktrees por repo, sino la necesidad de operar a nivel de workspace para poder generar pull requests cross-repo entre frontend, backend, infraestructura y data monorepos. Crearon ~10 workspaces locales, cada uno con un checkout independiente de cada repositorio.
Junio: la visibilidad de tickets se volvió un problema. Migraron toda la compañía a Linear y cortaron por completo con Jira.
Julio: la gestión local de tickets no escalaba. Lanzaron el Agent Fleet, una capa orquestada tipo Minions de Stripe.

La moraleja que Larson extrae es que cada pieza solo aporta valor si el resto ya está. El factory necesita acceso a Datadog MCP y Snowflake para gestionar el seguimiento de objetivos, pero también necesita que Linear sea la fuente única de estado de la compañía y un orquestador que pueda ejecutar trabajo independientemente de tu laptop.

El ecosistema: quién más está probando el patrón

Imprint no está sola. La conversación sobre fábricas de software tiene tres focos públicos relevantes en 2026:

Warp Factories (agosto de 2026). La empresa de coding agents Warp lanzó un sistema de infraestructura listo para desplegar fábricas de software. Su CEO, Zach Lloyd, dijo a TechCrunch que ya automatizan "30% a 35% de nuestras tareas semanalmente" y que ese número subirá conforme mejoren modelos, contexto y harness. La propuesta de Warp se centra en empresas medianas sin recursos para construir toda la pila desde cero, e integra Linear, Jira, Slack y Teams como capa de colaboración.
Stripe Minions y Ramp. Antes de que Warp empaquetara el patrón, Stripe ya había hecho público su sistema interno de minions para automatizar desarrollo, y Ramp había desplegado un agente de fondo capaz de monitorear su propio código después del deploy. Ambos casos sirven como referencia pública de que el patrón funciona en empresas reales de gran tamaño, según reportó TechCrunch.
StackGen Autonomous Operations Factory (septiembre de 2026). No es exactamente el mismo patrón: aplica la idea de fábrica a operaciones de producción en lugar de a desarrollo. StackGen presentó un sistema donde agentes especializados comparten contexto y se reparten trabajo de provisioning, deployment y respuesta a incidentes. Su State of Reliability 2026 atribuye ~10% de las caídas divulgadas este año a la IA (un aumento de seis veces en tres años) y documenta al menos nueve casos en el último año donde un agente tomó acción destructiva contra un sistema en producción sin intervención humana. Entre sus clientes están Autodesk, Nielsen y Bancolombia, reportó SiliconANGLE.

Qué significa esto para tu startup

El patrón software factory no es un producto que puedas comprar mañana; es una decisión de arquitectura organizacional que se sostiene sobre tres cimientos:

Estado único y medible. Necesitas un sistema de tickets (Linear o equivalente), dashboards de métricas confiables y definiciones de proyecto en prosa que un agente pueda auditar. Si cualquiera de los tres falta, el agente itera a ciegas.
Un orquestador que no dependa de tu laptop. El factory necesita correr en la nube o en infraestructura persistente, no en sesiones locales que se cierran cuando te vas a dormir. Aquí entran tanto productos empaquetados (Warp Factories) como inversiones internas tipo Agent Fleet o Minions.
Tolerancia a iteraciones incompletas. Vas a ver agentes abrir PRs que no sirven, malinterpretar objetivos o duplicar tickets. El sistema solo aprende si los humanos revisan, cierran y corrigen.

Acciones concretas para empezar esta semana:

Elige un solo proyecto pequeño que tenga RFC escrito, dashboard con métricas claras y un dueño humano accesible. Móntale un loop mínimo en Linear y observa durante dos semanas si el agente identifica trabajo nuevo que tú no habías visto.
Audita tu deuda de visibilidad. Si todavía usas Jira con permisos complicados y dashboards dispersos, no vas a poder correr un factory serio. La migración a Linear (o equivalente) es prerrequisito, no optimización.
Mide el porcentaje de tareas automatizadas por semana. No para reportarlo a un board, sino para tener una línea base honesta. Warp dice estar en 30-35% en su propia operación; la mayoría de equipos están muy por debajo. Ese número es lo que justifica (o no) la siguiente inversión en orquestación.