Deep Work Plan: Los modelos importan. El contexto importa más. Dale un plan a tu coding agent.

Cuando migramos nuestra superficie pública y publicamos Dailybot 3, el artículo terminó con una pregunta: dentro de un año, ¿quién moverá el producto y todo el trabajo técnico que lo sostiene? Nuestra respuesta fue que todo el equipo, porque un agente se sitúa entre las personas y el repositorio y hace la traducción. Esa respuesta nos dejó otra más difícil, una que teníamos que resolver antes de que la velocidad fuera real: cuando todo el mundo está publicando, y cada persona que publica es parte humana y parte agente, ¿cómo evitas que el trabajo se desvíe?

El desvío es concreto, y si alguna vez corriste una tarea larga con un agente lo has visto. El agente arranca con fuerza. La primera hora es precisa: lee los archivos correctos, hace los cambios correctos, corre las pruebas. Pasado cierto punto, el hilo ya es más largo que la atención útil del modelo, el objetivo original quedó fuera de vista, y el agente empieza a resolver un problema un poco distinto al que pediste. Todo sigue funcionando. Solo que no es lo que querías. Para cuando te das cuenta, estás revisando trabajo que se fue por las ramas, y no hay forma limpia de retomar desde el último buen estado, porque ese estado solo existió en una conversación que ahora es demasiado larga como para confiar en ella.

Nos topamos con esto trabajando en tantos proyectos que dejamos de tratarlo como un problema de prompts y empezamos a tratarlo como un problema estructural. El método al que llegamos es Deep Work Plan, una metodología que hoy practicamos en nuestros repositorios y que abrimos como código libre con licencia MIT. Este artículo cuenta cómo la usamos y por qué nos funciona. No es un producto que vendemos. Es una forma de trabajar que adoptamos, escribimos y liberamos.

Empezamos a trabajar en esto antes de que el Spec Driven Development (desarrollo guiado por especificación) y el harness engineering (el repositorio como entorno de ejecución) se volvieran ideas populares. No llegamos desde la teoría, sino desde el trabajo: resolviendo el mismo problema una y otra vez hasta que el patrón se hizo evidente. No fuimos los únicos, ni pretendemos serlo; muchos equipos llegaron a la misma conclusión desde puntos de partida distintos, y esa convergencia nos dice que no es una moda, sino un cambio real en cómo se construye con agentes. Hoy varios equipos ya lo tienen resuelto a su manera. Esta es la nuestra: la probamos y la verificamos en nuestros propios repositorios, y la dejamos como una metodología estandarizada para que cualquier agente pueda tomarla y trabajar sin desviarse, contra un plan estructurado.

Dos ideas que corrigieron el desvío

La primera idea es hacer que el plan sea la fuente de verdad, no la conversación. Antes de que un agente toque el código, escribimos un plan: el objetivo, el trabajo dividido en tareas atómicas, y para cada tarea un conjunto explícito de criterios de aceptación y un control de validación que debe pasar. El agente no decide que terminó. Lo decide el control. Una tarea está completa cuando sus pruebas pasan, su build está en verde y sus criterios de aceptación están marcados, no cuando el modelo siente que acabó. Esto es desarrollo guiado por especificación, y la parte importante es la palabra duradera. El plan vive en disco como archivos dentro del repositorio, así que sobrevive a un reinicio de contexto, a una sesión nueva o a un relevo con otro agente mañana. Cuando la conversación se vuelve demasiado larga como para confiar en ella, el plan sigue ahí, y también las casillas que dicen qué tareas ya pasaron sus controles.

La segunda idea nos costó más nombrarla. Durante un tiempo seguimos construyendo andamiaje para los agentes: el contexto que necesitan, las herramientas que pueden invocar, el bucle de control que los mantiene en la tarea, las barreras de seguridad, la manera en que el estado persiste para que una ejecución pueda detenerse y retomarse. Cada herramienta que probábamos quería que reconstruyéramos ese andamiaje dentro de su propio framework. Así que lo pusimos donde correspondía. Lo pusimos en el repositorio. El contexto son los archivos. Las herramientas son los scripts y la suite de pruebas que el repositorio ya tiene. El bucle de control y las barreras son el plan y sus controles, escritos como archivos planos que cualquier agente puede leer. El estado vive en disco. Dicho sin rodeos, el repositorio mismo se convierte en el harness, su entorno de ejecución, y como ese harness son solo archivos del repositorio y no el framework de un proveedor, cualquier agente puede tomar el repositorio y ejecutarlo. Es lo que otros equipos ya venían nombrando, y que hoy la industria llama harness engineering.

Esas dos ideas son todo el método. Un plan duradero contra el cual se ejecuta el trabajo, y un repositorio que carga su propio entorno para que el plan lo pueda correr cualquier agente que aparezca. La primera evita que el agente se aleje del objetivo. La segunda evita que el método quede atrapado dentro de una sola herramienta.

La prueba es que lo corremos sobre nosotros mismos

Lo más fuerte que podemos decir es que no estamos describiendo algo que esperamos que funcione. Lo venimos usando internamente desde finales de 2025, en decenas de proyectos, y ya es parte de cómo trabajan nuestros ingenieros. Incluso esta página corre sobre el método: tanto el sitio que estás leyendo como el sitio que documenta la metodología se mantienen así, de modo que la metodología se documenta a sí misma desde un repositorio que la usa. Cuando decimos que un plan puede correr durante horas atravesando reinicios de contexto y seguir en rumbo, es porque lo vimos hacerlo en el repositorio que sirve estas palabras.

También se puede instalar hoy, lo cual importa más de lo que parece. Mucha buena metodología nunca sale del equipo que la inventó porque no hay forma limpia de entregarla. Esta tiene un sitio público, un punto de adopción canónico en deepworkplan.com/init, y una skill instalable en DailybotHQ/deepworkplan-skill. El camino desde leer sobre el método hasta correrlo en tu propio repositorio es un solo paso: instala la skill, deja que prepare a tu agente y luego genera y ejecuta un plan. Quisimos que la distancia entre interesarse y ejecutar fuera corta, porque esa distancia es donde mueren la mayoría de las metodologías.

La parte que creemos que de verdad importa dentro de un año es que es independiente de la herramienta. Hay buenas herramientas en este espacio que empaquetan flujos guiados por especificación, y GitHub Spec Kit es un ejemplo justo de la categoría. La diferencia está en dónde vive el método. Esas herramientas guardan el flujo dentro de la herramienta, así que adoptar el método significa apostar a que la herramienta sobreviva y a que cada agente que uses hable su formato. Deep Work Plan vive en el repositorio como archivos que cualquier agente puede leer, así que no es una apuesta a un solo proveedor. Cuando el panorama de herramientas vuelva a cambiar, y va a cambiar, los planes, los controles y el estado siguen ahí, en el repositorio, donde el siguiente agente los puede retomar.

Dónde no ayuda

Conviene ser claros sobre lo que el método no resuelve: no vuelve bueno un objetivo malo. Si el plan es vago, el agente ejecuta vaguedad con toda fidelidad y los controles pasan sobre un trabajo que nadie quería. Cuando la ejecución es así de rápida, la ambigüedad se vuelve cara: la disciplina pasó de vigilar al agente a escribir el plan, y un plan flojo sigue siendo la forma de fallar. Ahora le dedicamos tiempo de verdad al plan, porque un plan preciso es la parte de la que depende toda la ejecución. Escribir uno bien es definir el problema real y no los síntomas, fijar las restricciones y los criterios con los que se va a validar, y anticipar dónde el agente va a adivinar para cerrarle esos huecos antes de que arranque. Esa claridad es la parte que sigue siendo nuestra, y la que más cuesta: el método no la reemplaza, la vuelve indispensable. Por eso se gana su lugar en el trabajo largo, no en el cambio de una línea: cuanto más larga es la ejecución, más vale haber pensado bien antes de delegar.

Lo que de verdad cambió

Lo que cambió no es que nuestros agentes se volvieron más inteligentes. Los modelos son los modelos, y van a seguir mejorando a su propio ritmo. Lo que cambió es que el trabajo ya no vive en una conversación que deja de ser confiable a medida que crece. Vive en el repositorio como un plan con controles, y esa es la parte que hace que una ejecución larga sea verificable cuando termina y retomable cuando se detiene.

Ese cambio es lo que permitió que la velocidad de nuestra migración se sostuviera una vez que todos estaban contribuyendo. Un equipo que se mueve rápido sobre el producto y todo lo que lo sostiene necesita más que agentes capaces. Necesita una forma de apuntar a los agentes hacia trabajo largo y confiar en que lo que vuelve coincide con lo que se pidió, ejecución tras ejecución, agente tras agente. El repositorio como entorno de ejecución es cómo lo logramos, y el plan es aquello de lo que el agente no se puede desviar. Si en el trabajo largo tus agentes terminan resolviendo algo distinto de lo que pediste, el arreglo probablemente no sea un mejor prompt: es un plan contra el cual ejecutan y un harness capaz de cargarlo. Los modelos van a seguir mejorando solos; lo que pone esa capacidad a trabajar a tu favor es el plan que pones delante. Empieza el tuyo en deepworkplan.com.