"Usamos IA para programar" puede significar aceptar sugerencias de autocompletado o dejar que entreguen cambios que nadie lee. Son niveles de autonomía distintos, y cada uno necesita controles distintos.
Veamos ese espectro, qué exige cada nivel y dónde se ubican Tack y docket, incluido lo que no hacen.
El espectro de autonomía
| Nivel | Quién escribe | Quién revisa | Qué hace falta como mínimo |
|---|---|---|---|
| 1. Autocompletado | la persona, con sugerencias | la persona, al teclear | nada nuevo |
| 2. Chat | el modelo, fragmentos | la persona, al copiar | criterio |
| 3. Vibe coding | el modelo, todo | nadie | un entorno descartable |
| 4. Agente con revisión | el agente, en el repo | la persona, cada diff | tests y CI |
| 5. Spec-driven | el agente, desde una spec | la persona, spec y diff | specs versionadas |
| 6. Agentes en segundo plano | el agente, sin supervisión directa | la persona, en el PR | sandbox, presupuestos, auditoría |
| 7. Fábrica lights-out | agentes | otros agentes y escenarios | todo lo anterior, medido |
Mira la columna de revisión: en el nivel 3 nadie lee el código; del 4 al 6 la lectura humana vuelve; el 7 la reemplaza por controles automáticos.
Vibe coding
Andrej Karpathy acuñó el término en febrero de 2025 para describir una forma de programar en la que aceptas lo que genera el modelo sin leer los diffs y, en sus palabras, "forget that the code even exists" (contexto y cita en Simon Willison). Él lo presentó como algo aceptable para proyectos descartables de fin de semana.
Para eso sirve: prototipos, demos y herramientas de un solo uso. Willison propone una frontera útil: si revisaste el código, lo probaste y puedes explicar qué hace, ya no es , es desarrollo asistido.
Spec-driven development
En el desarrollo guiado por especificaciones, la fuente de verdad es un documento versionado (qué construir, por qué y cómo se acepta), no la conversación. El agente implementa contra él y la persona revisa la spec antes que el código.
La spec solo es útil si se puede verificar. Por eso en este nivel los tests son el contrato: cada criterio de aceptación debería corresponder a un test que el agente no puede editar para hacerlo pasar. Ver Testing y evals para agentes.
Agentes en segundo plano y la fábrica lights-out
Un recibe una tarea (un issue, un ítem del tablero), trabaja sin que nadie mire y entrega un resultado revisable, típicamente un pull request. El de Copilot funciona así, sobre GitHub Actions (Agentes de código: harness y skills).
La lleva la idea al extremo. El término viene de la manufactura: plantas que producen sin personas en el piso, con las luces apagadas. El ejemplo citado con más frecuencia es FANUC en Japón, donde robots fabrican robots y, según reportes, pueden operar sin supervisión durante semanas.
En software, Dan Shapiro propuso en enero de 2026 una escala de cinco niveles, inspirada en la de conducción autónoma, cuyo último escalón llamó dark factory: nadie revisa el código que producen los agentes. El caso público más documentado es el equipo de IA de StrongDM, que describe reglas explícitas: los humanos no escriben código ni lo revisan. Para reemplazar la revisión, usan escenarios de extremo a extremo guardados fuera del repositorio (para que los agentes no puedan ajustarlos a su favor) y réplicas de comportamiento de servicios externos contra las cuales probar en volumen.
Qué exige cada nivel
| Control | Qué resuelve | Necesario desde |
|---|---|---|
| Specs versionadas | ambigüedad sobre qué construir | nivel 5 |
| Tests como contrato | "funciona" sin evidencia | nivel 4 |
| Evals y escenarios ocultos | calidad sin revisión línea a línea | nivel 7 |
| Gates de CI | cambios que rompen el build | nivel 4 |
| Sandbox | daño fuera del workspace | nivel 6 |
| Auditoría | no saber qué pasó ni quién lo decidió | nivel 6 |
| Aprobaciones humanas | acciones irreversibles | nivel 6, en puntos elegidos |
| Presupuestos de costo | bucles que gastan sin límite | nivel 6 |
El detalle está en Sandboxing y seguridad de agentes y Gobernanza y human-in-the-loop.
Tack y docket en el espectro
Ninguno promete el nivel 7; ambos aportan controles que ese nivel requeriría.
Errores frecuentes
Para CTOs
Elige el nivel por tipo de trabajo, no por equipo:
- Prototipos y exploración: nivel 3, en entornos descartables y sin datos reales.
- Producto con usuarios: nivel 4 o 5; toda línea que llega a producción la entiende alguien.
- Mantenimiento acotado y repetible (dependencias, migraciones mecánicas, tests faltantes): nivel 6, con , presupuesto y PR revisado.
- Nivel 7: solo con escenarios y evals que ya detectaron regresiones reales, errores reversibles y costo medido desde el primer día.
Fuentes
- Simon Willison: el término vibe coding y la cita de Karpathy
- GitHub Blog: Spec Kit y el desarrollo guiado por especificaciones
- Kiro: presentación
- Wikipedia: lights-out manufacturing
- Dan Shapiro: The Five Levels
- StrongDM AI: Software Factories and the Agentic Moment y el análisis de Simon Willison
- GitHub Blog: agente de código de Copilot
Para llevar
- La autonomía va del autocompletado a la fábrica lights-out; cada nivel necesita controles propios.
- El vibe coding sirve para prototipos; promoverlo a producción exige cambiar de nivel.
- En , la spec es la fuente de verdad y los tests son su contrato.
- Quitar la revisión humana solo es defendible si escenarios, evals y gates medibles la reemplazan.
- Tack y docket aportan ejecución registrada y pipelines gobernados, no una fábrica sin personas.
Comprueba lo aprendido
¿Qué distingue al vibe coding del desarrollo asistido por IA?
Que en el vibe coding nadie revisa ni entiende el código generado. Si lo revisaste, lo probaste y puedes explicarlo, es desarrollo asistido.
¿Por qué StrongDM guarda sus escenarios fuera del repositorio?
Para que los agentes que escriben el código no puedan verlos ni ajustarlos a su favor; funcionan como un conjunto de validación oculto que reemplaza a la revisión humana.
¿Qué hace docket cuando un pod alcanza su presupuesto?
Pone en pausa al Lead, que deja de tomar tareas hasta que un operador lo reanude. El presupuesto se compara contra una estimación de costo basada en , no contra una factura.