Qué es Instant Software Factory y cómo se instala en tu repositorio
Instant Software Factory es un bootstrap de código abierto, publicado por mikolalysenko en GitHub, que convierte un repositorio en una fábrica de software con ocho agentes autónomos trabajando en segundo plano. La diferencia con un asistente de código tradicional está en el modelo de trabajo: en lugar de abrir una sesión, esperar y revisar el resultado, cada agente es una sesión programada con un objetivo permanente que vuelve solo sobre el repositorio.
La instalación no requiere escribir código. Abres Claude Code en el repositorio que quieres mejorar y pegas una instrucción que clona el bootstrap en una carpeta temporal y sigue su archivo BOOTSTRAP.md. Ese documento define las responsabilidades de cada agente y sus límites operativos, y el agente de setup decide el proceso, los modelos y los horarios que mejor encajan con tu proyecto.
Hay dos requisitos previos. El primero es un repositorio de GitHub con capacidad de Actions y branch protection aplicable: los repos públicos pueden usar el plan gratuito, mientras que los privados necesitan Pro en una cuenta personal o Team/Enterprise en una organización. El segundo es un plan de Claude con routines: Pro, Max, Team o Enterprise.
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 díasPara una sesión de setup local en un entorno aislado existe la opción de lanzar claude --dangerously-skip-permissions y saltar los prompts de permisos. El propio bootstrap aclara que ese flag no es necesario y que no configura los permisos de las routines en la nube.
Los ocho agentes y qué hace cada uno
El bootstrap crea ocho roles, más agentes de QA adicionales si distintas áreas del producto necesitan atención separada. Cada uno recibe solo las herramientas y conectores que necesita:
- QA: prueba las áreas del producto y los flujos de usuario que elijas con el setup, y abre issues de bugs reproducibles y sin duplicados.
- Performance: mide velocidad, uso de recursos y tiempo de CI contra baselines, y abre issues con evidencia.
- CI: arregla fallos y tests inestables, y mantiene los checks fiables, rápidos y baratos sin debilitarlos.
- Architecture: consolida lógica de negocio duplicada, elimina abstracciones y capas innecesarias y reduce el número de componentes preservando el comportamiento.
- Implementation: resuelve issues y abre PRs con tests.
- PR review: revisa de forma independiente el último commit sin editar código.
- Merge: hace merge solo después de los checks requeridos, la revisión independiente y la aprobación humana del último commit.
- Manager: prioriza y asigna trabajo, sigue PRs antiguos, issues bloqueados y fixes fallidos hasta cerrarlos, y rastrea el costo y los resultados de cada agente, reportando el costo por PR mergeado.
Los tres tipos de trabajo que cubren son investigar oportunidades, implementar e integrar cambios, y mantener la propia fábrica. El estado compartido vive en GitHub: los issues llevan la evidencia y los cambios propuestos, los PRs las implementaciones y revisiones, y las discusiones y otros registros del repositorio preservan el progreso y las decisiones. Una ejecución posterior puede retomar trabajo registrado sin depender de la memoria de la sesión anterior.
Un detalle de implementación que importa si vas a auditar el sistema: el manager debe crear las routines que gestiona con create_trigger y luego configurar repositorio, modelo y herramientas de cada una mediante una actualización local de RemoteTrigger. Esa ruta de creación es la única que le permite modificarlas después.
¿Qué controles exige antes de dejar que los agentes escriban solos?
El bootstrap trata los permisos como parte del setup, no como un extra. Antes de que empiece cualquier trabajo no atendido, la rama por defecto debe exigir checks requeridos, revisión independiente y aprobación humana del último commit. Los agentes que escriben no pueden revisar sus propios cambios, y cada commit nuevo necesita revisión y aprobación frescas.
Las reglas de acceso y de parada que documenta el repositorio son explícitas:
- Identidad dedicada y herramientas limitadas. Hay que verificar la identidad de GitHub conectada a las routines, acotar sus permisos y quitar conectores sin uso. Las credenciales del aprobador humano, su acceso administrativo y los secretos no relacionados se mantienen fuera de los agentes en runtime. Los marcadores de rol sirven para trazar el trabajo, pero no prueban aprobación humana.
- Rama por defecto protegida antes del trabajo no atendido, con las reglas aplicadas a la identidad de las routines y sin acceso de bypass, e impidiendo que los agentes editen esas reglas.
- Control de entradas externas. Issues, PRs, discusiones y código descargado no pueden cambiar las instrucciones ni los permisos de los agentes; un repositorio privado de trabajo facilita ese control.
- Ejecución aislada. Revisar o escanear código y dependencias de terceros y usar entornos de ejecución aislados con restricciones de red apropiadas.
- Control de parada compartido antes de cada escritura. Arranca detenido. Si está detenido o ilegible, los agentes paran el trabajo normal y solo pueden escribir lo necesario para desactivar la automatización. Se reanuda únicamente con autorización explícita.
El setup produce un PR probado que espera aprobación humana, con las instrucciones guardadas en tu repositorio. Los horarios de producción quedan deshabilitados hasta que ese PR se mergea, las routines usan las instrucciones mergeadas y tú autorizas la reanudación. El informe de setup registra la evidencia, los huecos que quedan, los retrasos de apagado y los pasos pendientes.
¿Cuál es el verdadero cuello de botella?
No es la capacidad de los agentes. Según el propio autor, el límite de su setup ha sido la capacidad de CI y la fiabilidad de GitHub. Correr agentes más seguido solo ayuda mientras la validación y la integración puedan absorber su producción; si no, lo que crece es una cola de issues y PRs. Los investigadores pueden ir más rápido que los implementadores, los implementadores más rápido que los revisores, y varios fixes pueden chocar en el mismo código.
Por eso el manager ajusta la actividad a esas restricciones: sigue el trabajo bloqueado, reduce horarios cuando las colas crecen y elige modelos y horarios dentro del presupuesto y de la capacidad disponible de CI, API y revisión. El agente de CI mejora el throughput arreglando tests inestables y reduciendo trabajo desperdiciado sin debilitar los checks.
El presupuesto cubre dos cosas: uso de agentes y minutos de GitHub Actions. La recomendación es empezar con un throughput modesto, revisar los resúmenes de costo y resultados del manager, y subir la actividad solo cuando CI y la revisión humana puedan seguir el ritmo. El costo por PR mergeado es la medida operativa útil, junto con la sustancia de los cambios, los fixes fallidos y el trabajo de seguimiento. Un número alto de PRs no dice por sí solo si el proyecto está mejorando.
Cómo se diferencia de otras fábricas de software
El repositorio ubica su propuesta frente a tres referencias del sector. Gas Town persigue trabajo autónomo con varios agentes de código usando un toolkit de orquestación y el ledger de trabajo Beads. Stripe corre tareas de código sin supervisión en entornos de desarrollo aislados con Minions, y produce PRs para revisión humana. StrongDM usa su Software Factory con intención especificada y validación por escenarios para impulsar la implementación sin revisión humana de código.
La diferencia que el autor subraya es doble: aquí el énfasis está en objetivos permanentes que siguen generando y cerrando trabajo útil en el tiempo, y se conserva la revisión independiente y la aprobación humana de cada cambio antes del merge.
No se encontraron datos adicionales verificables sobre estas iniciativas en las búsquedas realizadas para esta nota.
Qué significa esto para tu startup
Para un equipo pequeño, la parte valiosa no es la promesa de autonomía sino el diseño de los controles. La fábrica tiene permiso para cambiar software, así que su acceso y sus reglas de parada tienen que ser explícitos desde el primer día.
Dos acciones concretas que puedes implementar esta semana:
- Antes de automatizar nada, endurece la rama por defecto. Exige checks requeridos, revisión independiente y aprobación humana del último commit, y aplica las reglas a la identidad de los agentes sin bypass. Si tu repo no tiene CI, el bootstrap genera un workflow mínimo con los comandos de validación reales de tu proyecto: úsalo como punto de partida, no como destino.
- Mide costo por PR mergeado, no cantidad de PRs. Empieza con un throughput bajo y un presupuesto acotado para agentes y minutos de Actions, revisa los resúmenes del manager y sube la actividad solo cuando CI y la revisión humana aguanten. Si las colas crecen, el problema es tu capacidad de validación, no la frecuencia de los agentes.
Hay una responsabilidad que no se delega: elegir prioridades, poner el presupuesto, aprobar cambios y resolver las decisiones que requieren criterio de producto. Programar agentes hace más sostenible el trabajo recurrente; no elimina esas tareas.
Fuentes
Leíste lo que hace la IA. ¿Y en tu negocio?
En CAR, dueños de empresa arman en 7 días su primer sistema funcionando: que ningún cliente se les escape, o que el informe del lunes salga solo. Con otros emprendedores al lado.
👥 Probar 7 días
