AI software factory: qué es y por qué falla sin contrato
DominicodeEl 6 de febrero de 2026 un equipo de tres personas de StrongDM publicó un manifiesto con dos reglas. La primera: el código no lo escriben humanos. La segunda: el código no lo revisan humanos.
Al día siguiente el texto llegó a portada de Hacker News. Un comentario resumía la reacción de media sala: "I feel like I'm taking crazy pills". La otra media lo leía como el primer plano de una AI software factory de verdad.
Casi nadie discutía qué modelo usaban. Discutían cómo sabes que funciona un software que ningún humano ha escrito ni leído.
En corto: una AI software factory es un pipeline donde agentes de IA convierten especificaciones en software desplegado, y los humanos solo escriben specs y juzgan resultados. Lo que decide si funciona no es el modelo, sino el harness de verificación: tests, tipos, escenarios y gates de CI que el agente no puede manipular.
¿Qué es una AI software factory?
Una AI software factory (fábrica de software con IA) es un sistema en el que agentes de IA escriben, prueban e integran código a partir de especificaciones, y donde la calidad la garantiza un sistema de verificación automatizado en lugar de la revisión humana línea a línea.
StrongDM lo define en su propio manifiesto como "non-interactive development where specs + scenarios drive agents that write code": desarrollo no interactivo donde specs y escenarios dirigen a agentes que escriben código.
Fíjate en lo que falta: el prompt. Nadie chatea con el agente. Hay una entrada (la spec), una salida (el software) y un control de calidad entre medias.
Quién usa el término y qué hay detrás de cada uso
Hoy el término lo usan cuatro actores: StrongDM y OpenAI para describir cómo producen software sin escribir código a mano, Dan Shapiro para su escala de autonomía, y Factory como marca comercial. Solo los dos primeros publican cómo verifican.
| Quién | Qué afirma | Evidencia | Limitación o riesgo |
|---|---|---|---|
| StrongDM (feb. 2026) | Equipo de 3 personas desde julio de 2025; "code must not be written by humans" ni revisado por humanos | Manifiesto propio, técnicas publicadas y análisis de Simon Willison | Su regla práctica: si no gastas 1.000 USD en tokens al día por ingeniero, a tu fábrica le queda margen; no publican métricas de producto entregado |
| Dan Shapiro (ene. 2026) | Seis niveles de autonomía (0 a 5); el 5 es la "dark factory" | Lo que ha visto en decenas de empresas | No es una encuesta; los porcentajes son estimaciones del autor |
| OpenAI, harness engineering (feb. 2026) | Un producto interno en beta de alrededor de un millón de líneas en cinco meses, con cero código escrito a mano (InfoQ, The Neuron) | Cifras autodeclaradas, repetidas por dos medios | Lo hace el fabricante del modelo, con acceso y presupuesto que tu equipo no tiene |
| Factory (antes Factory.ai) | "Build Your Software Factory": agentes llamados Droids que trabajan desde terminal, Slack, Jira, Linear y CI | Página comercial | Es un producto; el término es su posicionamiento de marca |
Mi lectura: StrongDM y OpenAI describen cómo verifican, y eso es lo valioso. Factory describe dónde se ejecutan los agentes, que es lo fácil.
Las piezas de una fábrica de software con IA
Una fábrica de software con IA tiene cinco piezas, y solo una de ellas es el modelo.
1. Specs. La entrada de la línea. Si es ambigua, el agente rellena huecos con lo más frecuente en su entrenamiento, no con lo que pide tu negocio. Es Spec-Driven Development sin humanos en medio; lo desarrollo en el libro de Spec-Driven Development.
2. Agentes. Claude Code, Codex, Droids. La pieza más intercambiable.
3. Harness de verificación. Tests, tipos estrictos, linters, tests estructurales de arquitectura y escenarios end-to-end. Según InfoQ, OpenAI impone los límites de arquitectura "through mechanical rules and structural tests". No los pide en el prompt.
4. CI como gate. Nada llega a main sin pasar el harness.
5. Revisión. En StrongDM la revisión humana desaparece y la sustituye una métrica que llaman satisfaction: de todas las trayectorias observadas en todos los escenarios, qué fracción probablemente satisface al usuario. En el resto del mundo, la revisión sigue siendo humana pero cambia de objeto: revisas el contrato, no cada diff.
Por qué la verificación decide si una AI software factory funciona
El cuello de botella de una AI software factory es la verificación, no la generación de código. Generar código ya es barato. Saber si es correcto sigue siendo caro.
Si el mismo agente escribe el código y los tests, optimiza para que los tests pasen, no para que el software funcione. En el hilo de Hacker News sobre StrongDM, el usuario Zakodiac lo dijo sin rodeos: "agents will absolutely game your test suite".
La respuesta de StrongDM es la idea más útil de todo su manifiesto: guardar los escenarios fuera del repositorio, como el holdout set de un modelo de machine learning. El agente nunca los ve, así que no puede adaptarse a ellos.
En la práctica se parece a esto:
# .github/workflows/factory-gate.yml
name: factory-gate
on: pull_request
jobs:
holdout:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
# Los escenarios viven en otro repo, sin acceso de escritura para el agente
- uses: actions/checkout@v7
with:
repository: acme/checkout-scenarios
path: scenarios
token: ${{ secrets.SCENARIOS_READ_TOKEN }}
- run: npm ci && npm run typecheck && npm test
- run: npx playwright install --with-deps
- run: npx playwright test --config scenarios/playwright.config.ts
Tipos y tests en el repo, y escenarios que el agente no puede leer ni editar. Si una capa falla, el PR no entra. Protege también el workflow con CODEOWNERS y protección de rama; si no, el agente puede editar el propio gate.
Otro comentario del mismo hilo, de CuriouslyC, pone el límite donde toca: "Until we solve the validation problem, none of this stuff is going to be more than flexes."
Por eso defiendo que la pieza central es un contrato: reglas de negocio expresadas como tipos, tests y escenarios, no como frases en un prompt. Lo explico paso a paso en el tutorial de harness engineering y en el método de revisión por contrato.
En qué nivel de autonomía está la mayoría de equipos hoy
Según Dan Shapiro, el 90 % de los developers que se llaman "AI-native" está en el nivel 2 de su escala de seis niveles, y casi todos tocan techo en el 3. Él mismo lo presenta como una impresión, no como un estudio. La escala, de enero de 2026, se inspira en la conducción autónoma:
| Nivel | Analogía de Shapiro | Qué hace el developer |
|---|---|---|
| 0 | El Volvo de tus padres | Escribe todo el código |
| 1 | Control de carril | Delega tareas pequeñas y aisladas |
| 2 | Autopilot en autopista | Programa en pareja con la IA, en flujo |
| 3 | Waymo con conductor de seguridad | La IA escribe; él revisa diffs ("your life is diffs") |
| 4 | Robotaxi | Escribe specs y planes; vuelve horas después a ver si pasan los tests |
| 5 | Dark factory | Una caja negra que convierte specs en software |
Mi opinión: el salto que paga es del 2 al 4, no del 4 al 5. En el nivel 4 sigues escribiendo la spec y juzgando el resultado, pero dejas de leer cada línea porque el harness lo hace por ti. Eso ya es una fábrica. La dark factory completa es un caso extremo, no la meta por defecto. Si quieres ver el ciclo completo de contexto entre esos niveles, está en el post de SDLC context engineering.
Cuándo NO montar una AI software factory
Una AI software factory no es gratis ni universal. No la montaría en estos casos.
Cuando no tienes tests ni tipos fiables. Si tu suite actual no detecta regresiones con humanos escribiendo el código, tampoco las detectará con agentes. Multiplicarás la velocidad de los errores. Primero el harness, después la fábrica.
Cuando el trabajo consiste en descubrir qué hay que construir. Para validar su fábrica, StrongDM construyó réplicas de servicios con API pública documentada (Okta, Jira, Slack): ahí la spec ya existe. En el hilo de HN, softwaredoug lo señaló: "most development work involves discovering correctness, not writing to a fullproof spec (like cloning slack)". Si la spec no existe todavía, no hay nada que fabricar.
Cuando el coste no cuadra. La guía de StrongDM habla de al menos 1.000 USD en tokens al día por ingeniero. Simon Willison lo traduce a unos 20.000 USD al mes por persona y admite que eso le hace el enfoque "far less interesting" salvo que el negocio lo sostenga.
Cuando un fallo es inaceptable y nadie lo revisa. Software de seguridad, pagos o salud. Un antiguo cliente de StrongDM escribió en el hilo que para un producto de seguridad central eso no era el "flex" que creían.
Por dónde empezar con una fábrica de software con IA
No montes la fábrica. Monta el contrato.
Elige un módulo de tu proyecto con reglas de negocio claras. Escribe su spec, convierte esas reglas en tipos y tests, y mueve tres escenarios end-to-end a un sitio que el agente no pueda tocar. Después deja que el agente implemente una feature entera sin que leas el diff, y mira solo si el gate pasa.
Si pasa y el comportamiento es correcto, has subido un nivel. Si pasa y es incorrecto, has encontrado el agujero de tu contrato: la información más valiosa de tu semana.
Si quieres empezar sin pagar nada, el ebook gratuito El Developer Agéntico cubre cómo construir agentes de IA, de la arquitectura a la seguridad y la evaluación.
Ese recorrido, de la spec al harness y a la revisión por contrato, es lo que trabajamos en el workshop SDD + Agentic Engineering. Y si prefieres construir un producto completo con Claude Code aplicando estas ideas, está el curso Construye con IA: de la idea al producto.
Preguntas frecuentes
¿Qué diferencia hay entre una AI software factory y usar Claude Code o Copilot?
Usar un asistente es trabajo interactivo: tú pides, revisas y corriges en cada paso. Una AI software factory es no interactiva: los agentes trabajan a partir de una spec y un sistema automatizado decide si el resultado es aceptable, sin que nadie siga la sesión.
¿Qué es una dark factory en desarrollo de software?
Es el nivel 5 de la escala de Dan Shapiro: un proceso donde las specs entran y el software sale sin desarrollo ni revisión humana en medio. El término viene de las fábricas industriales que funcionan con las luces apagadas porque no hay personas dentro.
¿Qué relación tiene una fábrica de software con IA con SDD?
Spec-Driven Development aporta la entrada de la fábrica: specs precisas que el agente puede ejecutar sin interpretar. Sin SDD, el agente rellena los huecos de la spec con lo más frecuente en su entrenamiento. Con SDD, esas reglas se convierten en tipos, tests y escenarios que el harness comprueba.
¿Los agentes pueden escribir sus propios tests en una AI software factory?
Pueden escribir tests unitarios, pero no deberían controlar la verificación final. Si el mismo agente escribe el código y todos los tests, tenderá a ajustar los tests al código. Los escenarios de aceptación deben vivir fuera de su alcance.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.