"Usamos IA para programar" puede significar aceptar la siguiente línea que sugiere el editor, o dejar que entreguen cambios que ninguna persona lee. La distancia entre ambas cosas es como la que hay entre el control de crucero y un auto sin nadie al volante. Las dos son útiles; necesitan resguardos muy distintos.

Así que la pregunta real es cuánta autonomía darle a la IA en cada tipo de trabajo, y qué reemplaza la atención de una persona a medida que esa autonomía crece. Esta lección cubre cuatro ideas: el espectro de autonomía, el y dónde tiene sentido, las specs y los tests como contrato con el que trabaja un agente, y la "" en el extremo. Cierra con dónde se ubican Tack y docket, incluido lo que no hacen.

El espectro de autonomía

Dos preguntas ubican cualquier práctica de programación con IA: quién escribe el código y quién lo revisa antes de que cuente.

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, en fragmentos	la persona, al copiar	criterio
3. Vibe coding	el modelo, todo	nadie	un entorno descartable
4. Agente con revisión	un agente, en el código	la persona, cada cambio	tests automáticos
5. Spec-driven	un agente, desde una spec escrita	la persona, spec y cambio	specs versionadas
6. Agentes en segundo plano	un agente, sin supervisión	la persona, al final	aislamiento, presupuestos, un registro
7. Fábrica lights-out	agentes	otros agentes y escenarios	todo lo anterior, medido

Sigue la columna "quién revisa". En el nivel 3 nadie lee el código. Del 4 al 6 una persona vuelve a leerlo. En el 7, controles automáticos ocupan el lugar de la persona. Cada escalón agrega sus propios controles, como aislamiento, de costo, aprobaciones y un registro de cada acción; Sandboxing y seguridad de agentes y Gobernanza y human-in-the-loop los tratan a fondo.

Vibe coding

Andrej Karpathy acuñó el término en febrero de 2025 para una forma de programar en la que aceptas lo que produce el modelo sin leer los cambios y, en sus palabras, "forget that the code even exists" ("olvidas que el código siquiera existe") (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 vibe coding sino desarrollo asistido por IA.

Specs y tests como contrato

Nadie construye una casa a partir de una charla de café: hay planos, y un inspector verifica el resultado contra ellos. El desarrollo guiado por especificaciones () aplica esa idea. La fuente de verdad es un documento escrito y versionado, la spec, que dice qué construir, por qué y cómo se aceptará el resultado. El agente construye a partir de ella, y la persona revisa la spec antes que el código.

Una spec solo ayuda si alguien puede verificar que se cumplió. Por eso, en este nivel, los tests son el contrato: cada criterio de aceptación debería corresponder a un test automático que el agente no puede editar para hacerlo pasar. Ver Testing y evals para agentes.

Specqué construir, por qué, cómo se acepta
La persona revisala spec, antes de que exista código
El agente construyea partir de la spec
Testsel contrato, fuera del alcance del agente
La persona revisael cambio en sí

En el desarrollo guiado por specs la persona revisa dos veces: el plan antes del trabajo, y el resultado contra tests que el agente no pudo reescribir.

Agentes en segundo plano y la fábrica lights-out

Un agente en segundo plano () recibe una tarea, como un issue o un ítem del tablero, trabaja sin que nadie mire y entrega algo revisable, normalmente un pull request (un cambio propuesto que espera aprobación). El de Copilot funciona así (Agentes de código: harness y skills).

La fábrica lights-out lleva la idea al extremo. En manufactura, el término designa plantas que operan sin nadie en el piso, con las luces apagadas. El ejemplo más citado es FANUC en Japón, donde robots fabrican robots y, según reportes publicados, pueden operar sin supervisión durante semanas.

En software, Dan Shapiro propuso en enero de 2026 una escala de cinco niveles, inspirada en los niveles de los autos autónomos, y llamó a su último escalón 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, cuya regla es que los humanos no escriben ni revisan código. En lugar de la revisión, usan escenarios de extremo a extremo guardados fuera del repositorio, para que los agentes no puedan ajustarlos a su favor, y prueban en volumen contra imitaciones de los servicios externos de los que dependen.

Tack y docket en el espectro

En docket

Líderplanifica, nunca edita código
Implementadorescribe el código
- Verificación automáticaun comando opcional que debe pasar
Revisoropcional, aprueba o lo devuelve
Testeropcional, pasa o falla
Túrevisas el cambio y haces el commit

El pipeline incorporado de docket. Antes de cada paso se revisa el presupuesto, y la tarea se detiene al alcanzar el tope; el commit final queda en manos de una persona. Fuente: Agent Teams (Pods) · Complete Workflow Guide

Ninguno promete el nivel 7. Ambos aportan controles que ese nivel requeriría.

Errores frecuentes

En la práctica

Elige el nivel por tipo de trabajo, no por equipo:

Prototipos y exploración: nivel 3, en entornos descartables y sin datos reales.
Productos con usuarios: nivel 4 o 5, para que alguien entienda cada línea que llega a producción.
Mantenimiento acotado y repetible, como actualizar dependencias o agregar tests faltantes: nivel 6, con aislamiento, presupuesto y un pull request revisado.
Nivel 7: solo con escenarios y que ya detectaron regresiones reales, fallas que se pueden deshacer y costo medido desde el primer día.

Fuentes

Para profundizar

La documentación de Tack y de docket muestra estos controles con más detalle (en inglés):

Agent Runners & Fleet Execution cubre cómo un ítem del tablero de Tack se convierte en una ejecución registrada, la política que limita al agente y lo que un runner puede y no puede prometer.
Agent Teams (Pods) explica los roles de docket, cómo el pipeline pasa una tarea de un rol al siguiente y las verificaciones entre ellos.
Complete Workflow Guide sigue una tarea desde la cola hasta el commit, incluidos el freno por presupuesto y los pipelines personalizados que terminan con una aprobación humana.

Para llevar

La autonomía va del autocompletado a la fábrica lights-out, y cada nivel necesita sus propios controles.
El vibe coding sirve para prototipos; llevar uno a producción exige pasar a un nivel con revisión y tests.
En el desarrollo guiado por especificaciones, 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 puntos de control medidos la reemplazan.
Tack y docket aportan ejecución registrada y pipelines gobernados, no una fábrica sin personas.

Comprueba lo aprendido

¿Qué convierte el vibe coding en desarrollo asistido por IA?

Que alguien revise, pruebe y entienda el código generado. Si puedes explicarlo y lo probaste, ya no es vibe coding.

¿Por qué un agente no debería poder editar los tests que evalúan su trabajo?

Porque podría cambiar los tests hasta que pasen en lugar de cumplir el requisito. Por eso también StrongDM guarda sus escenarios fuera del repositorio.

Un equipo quiere dejar de revisar a mano el código de sus agentes. ¿Qué debe existir antes?

Reemplazos medidos para esa revisión: escenarios y evals que ya detectaron regresiones reales, puntos de control antes de que los cambios entren, fallas reversibles y seguimiento del costo. Sin ellos, es vibe coding a escala.