Puedes dejar a un agente de IA programando de madrugada. Eso es cierto, y es genuinamente útil. Lo que no es cierto es la versión que ves en las demos, donde el agente trabaja mientras duermes y amaneces con funcionalidades ya publicadas. La versión honesta tiene un límite tajante: el agente trabaja solo durante horas, pero todo lo que produce aterriza como un borrador para revisar o una corrección mecánica detrás de un pull request — nunca como un merge automático a producción. Esa única restricción es la que convierte el desarrollo nocturno con IA en apalancamiento real y no en un problema.
Llevo tiempo corriendo este ciclo contra mis propios sitios. Esto no es la promoción de un producto; es el montaje, el razonamiento detrás de cada barrera y el problema que rompía todo en silencio hasta que lo arreglé. Cualquier desarrollador puede aplicar el patrón — la herramienta concreta casi da igual.
La barrera de seguridad: el agente abre PRs, un humano hace el merge
La regla que sostiene todo lo demás es la más simple. El agente jamás hace merge de su propio trabajo a producción. Puede crear una rama, escribir código, correr las verificaciones, hacer push y abrir un pull request. Lo que no puede es apretar el botón de merge. Eso lo hace un humano, despierto, por la mañana.
Es una decisión de gobernanza deliberada, no una limitación por la que me esté disculpando. Un agente de IA es muy bueno produciendo trabajo verosímil y genuinamente malo para saber cuándo lo verosímil no es correcto. El merge es el único paso más o menos irreversible de todo el ciclo — es lo que pone el código frente a usuarios reales — así que es justo el paso en el que dejas a una persona. Todo lo que ocurre antes del merge es reversible: una rama que borras, un PR que cierras, un commit que revierte. Todo lo que ocurre después del merge ya es problema de tus usuarios. Por eso la barrera va exactamente ahí.
El efecto secundario agradable es que un PR cerrado no cuesta nada. Si el agente pasó tres horas en algo que resulta estar mal, leo el diff, lo cierro, y no perdí nada más que algo de cómputo. El radio de daño de una mala noche es un PR que no fusioné.
Qué trabajo sí es seguro dejar corriendo de madrugada, sin supervisión
Aquí no todo el trabajo pesa igual, y la distinción útil no es “fácil contra difícil”. Es si la tarea está terminada cuando una verificación se pone en verde.
Hay trabajo verificable. Un linter pasa o no pasa. Una auditoría de accesibilidad encuentra cero fallos de contraste o encuentra cinco. Un barrido de enlaces rotos saca un 404 o vuelve limpio. Una auditoría de etiquetas canónicas cuadra cada página consigo misma o marca el desajuste. Para esta clase de trabajo, “terminado” es un hecho comprobable por una máquina, y el ciclo de retroalimentación se cierra sin mí. Eso es lo que de verdad es seguro dejar corriendo de noche: correcciones de lint, arreglos de accesibilidad, pases de enlazado interno, barridos de enlaces rotos y canónicos. El agente itera hasta que la verificación está en verde, y verde significa verde.
La otra clase es el trabajo de retroalimentación diferida. Escribir un artículo, tomar una decisión de diseño, elegir el posicionamiento de un producto — ninguna tiene un check en verde. No existe una prueba que te diga que el texto es bueno o que la maqueta está bien. Y algo importante: esto es retroalimentación diferida, no ausencia de retroalimentación. El agente igual puede hacer el trabajo de madrugada; solo que produce un borrador que reviso por la mañana en lugar de algo “terminado”. El error es tratar el trabajo de retroalimentación diferida como si fuera verificable — dejar que el agente decida que ya acabó y que actúe en consecuencia. No ha acabado. Está esperando criterio, y el criterio es justo lo que no puedes automatizar.
Así que la regla con la que trabajo: si puedes nombrar la verificación que prueba que está listo, el agente puede terminarlo sin supervisión. Si el único juez es el gusto de una persona, el agente produce un borrador y se detiene.
La estructura que hace que funcione
Tres restricciones, y son aburridas a propósito.
Una rama, un PR, por unidad de trabajo. Cada cosa independiente que hace el agente lleva su propia rama y su propio pull request. No por orden, sino porque hace cada unidad reversible de forma independiente. Si de noche corrieron cuatro cosas y una está mal, fusiono las tres buenas y cierro la cuarta. Si las juntas en un solo PR, un cambio malo tiene de rehén a tres buenos — o peor, se fusiona junto con ellos.
Pon una barrera de build, lint y formato antes de cada push. El agente no puede hacer push de una rama hasta haber corrido de verdad el build sin errores, el linter sin errores y el formateador sin diferencias residuales. Esto es el agente demostrando que su propio trabajo pasa el listón mecánico antes de pedir mi atención. Un PR que no compila es peor que ningún PR — es una petición para revisar código roto.
Nunca inventes datos. Esta es una regla de contenido, pero también es una regla de seguridad. Un agente sin supervisión escribiendo texto va a inventar, si lo dejas, un benchmark o una métrica para que la frase quede mejor. La instrucción permanente es: si una afirmación necesita un número que no puedes sostener, elimina la afirmación. Una estadística inventada con seguridad sale mucho más cara que una omisión honesta, y por definición no hay nadie mirando en tiempo real para atraparla.
El problema: un escritor concurrente te va a borrar la rama
Este es el que de verdad me mordió, y merece su sección porque no es obvio hasta que te pasa.
Imagina que el agente trabaja en un repositorio que tiene un escritor concurrente — otro proceso, otra sesión, o tú mismo, haciendo commits sobre el mismo árbol de trabajo al mismo tiempo. Git tiene un solo HEAD por árbol de trabajo. Si dos actores están cambiando de rama, preparando archivos y haciendo commits en ese único árbol, se pisan el HEAD mutuamente. El agente crea su rama y empieza a trabajar; el otro escritor cambia a otra cosa; ahora el siguiente commit del agente aterriza donde no esperaba, o su rama queda abandonada, o el árbol de trabajo queda sucio con archivos que él nunca tocó. Sin supervisión, no hay ningún humano que note que el árbol se torció.
El arreglo es limpio: dale a cada unidad de trabajo su propio worktree de git. Un worktree es un segundo directorio de trabajo conectado al mismo repositorio, con su propio HEAD independiente y su propia rama en checkout. git worktree add le da al agente nocturno una copia aislada del repo donde trabajar — puede hacer checkout de su rama, compilar, commitear y hacer push sin tocar jamás el HEAD que usa el otro escritor. Mismo repositorio e historia, directorios de trabajo separados, cero colisiones. En cuanto moví cada unidad sin supervisión a su propio worktree, el borrado de ramas desapareció por completo.
La lección general: el git sin supervisión asume que es el único escritor. Si esa suposición es falsa, aísla al escritor. Los worktrees son la herramienta nativa para justo esto, y son baratos.
La conclusión
El desarrollo con IA de madrugada es apalancamiento real, pero solo si eres honesto sobre su forma. Separa el trabajo que está listo cuando una verificación se pone en verde del trabajo que necesita el criterio de una persona — corre el primero hasta terminarlo sin supervisión, y deja que el segundo produzca borradores que revisas despierto. Mantén siempre a un humano en el botón de merge. Dale a cada unidad su propia rama, su propio PR y su propio worktree si algo más está escribiendo en el repositorio.
Haz eso y amaneces con una pila corta de pull requests: unas cuantas correcciones listas-en-verde para fusionar, y un par de borradores que necesitan tu ojo. Eso no es “la IA publicó funcionalidades mientras dormía”. Es mejor, porque es verdad — y porque puedes confiar en ello cada mañana.
Si quieres el mapa completo de las piezas que hacen que Claude Code trabaje así, escribí sobre el stack de IA que uso para programar con Claude Code. Y si vienes desde la enseñanza más que desde el código, usar la IA como asistente en el aula parte del mismo principio: la IA hace el borrador, tú pones el criterio — que es exactamente la línea que separa lo que se puede dejar solo de lo que no.
