Deep Work Plan: Os modelos importam. O contexto importa mais. Dê um plano ao seu coding agent.

Quando migramos nossa superfície pública e lançamos o Dailybot 3, o artigo terminou com uma pergunta: daqui a um ano, quem vai mover o produto e todo o trabalho técnico que o sustenta? Nossa resposta foi o time inteiro, porque um agente fica entre as pessoas e o repositório e faz a tradução. Essa resposta deixou outra mais difícil, uma que precisávamos resolver antes de a velocidade ser real: quando todo mundo está publicando, e cada pessoa que publica é parte humana e parte agente, como você evita que o trabalho saia do rumo?

O desvio é concreto, e se você já rodou uma tarefa longa com um agente, já viu isso acontecer. O agente começa forte. A primeira hora é afiada: ele lê os arquivos certos, faz as alterações certas, roda os testes. Passado certo ponto, a conversa já está mais longa do que a atenção útil do modelo, o objetivo original saiu de vista, e o agente passa a resolver um problema um pouco diferente do que você pediu. Tudo ainda funciona. Só que não é o que você queria. Quando você percebe, já está revisando um trabalho que se perdeu no caminho, e não há um jeito limpo de retomar a partir do último estado bom, porque esse estado só existiu numa conversa que agora está longa demais para se confiar.

Esbarramos nisso trabalhando em tantos projetos que deixamos de tratar como um problema de prompt e passamos a tratar como um problema estrutural. O método ao qual chegamos é o Deep Work Plan, uma metodologia que hoje praticamos nos nossos repositórios e que abrimos como código livre sob licença MIT. Este artigo conta como a usamos e por que ela funciona para nós. Não é um produto que vendemos. É um jeito de trabalhar que adotamos, escrevemos e liberamos.

Começamos com isso antes de o Spec Driven Development (desenvolvimento guiado por especificação) e o harness engineering (o repositório como ambiente de execução) virarem ideias populares. Não chegamos pela teoria, e sim pelo trabalho: resolvendo o mesmo problema vez após vez até o padrão ficar evidente. Não fomos os únicos, e não pretendemos ser; muitos times chegaram à mesma conclusão a partir de pontos de partida diferentes, e essa convergência nos diz que não é modismo, e sim uma mudança real em como se constrói com agentes. Hoje vários times já têm isso resolvido do seu jeito. Este é o nosso: testamos e verificamos nos nossos próprios repositórios, e o deixamos como uma metodologia padronizada para que qualquer agente consiga pegá-la e trabalhar sem se desviar, contra um plano estruturado.

Duas ideias que corrigiram o desvio

A primeira ideia é fazer com que o plano seja a fonte da verdade, e não a conversa. Antes de um agente tocar no código, escrevemos um plano: o objetivo, o trabalho dividido em tarefas atômicas, e para cada tarefa um conjunto explícito de critérios de aceitação e um controle de validação que ela precisa passar. O agente não decide que terminou. Quem decide é o controle. Uma tarefa está completa quando seus testes passam, seu build está verde e seus critérios de aceitação estão marcados, e não quando o modelo sente que acabou. Isso é desenvolvimento guiado por especificação, e a parte importante é a palavra durável. O plano vive em disco como arquivos dentro do repositório, então sobrevive a um reinício de contexto, a uma nova sessão ou a uma passagem de bastão para outro agente amanhã. Quando a conversa fica longa demais para se confiar, o plano continua lá, e também as caixas que dizem quais tarefas já passaram pelos seus controles.

A segunda ideia demorou mais para nomearmos. Por um tempo continuamos construindo andaime para os agentes: o contexto de que precisam, as ferramentas que podem chamar, o laço de controle que os mantém na tarefa, as proteções, o jeito como o estado persiste para que uma execução possa parar e retomar. Cada ferramenta que testávamos queria que reconstruíssemos esse andaime dentro do próprio framework dela. Então colocamos onde era o lugar. Colocamos no repositório. O contexto são os arquivos. As ferramentas são os scripts e a suíte de testes que o repositório já tem. O laço de controle e as proteções são o plano e seus controles, escritos como arquivos simples que qualquer agente consegue ler. O estado vive em disco. Dito de forma direta, o próprio repositório vira o harness, o seu ambiente de execução, e como esse harness são apenas arquivos do repositório, e não o framework de um fornecedor, qualquer agente consegue pegar o repositório e executá-lo. É o que outros times já vinham nomeando, e que hoje a indústria chama de harness engineering.

Essas duas ideias são o método inteiro. Um plano durável contra o qual o trabalho é executado, e um repositório que carrega o próprio ambiente para que o plano possa ser rodado por qualquer agente que apareça. A primeira evita que o agente se afaste do objetivo. A segunda evita que o método fique preso dentro de uma única ferramenta.

A prova é que rodamos isso em nós mesmos

A coisa mais forte que podemos dizer é que não estamos descrevendo algo que esperamos que funcione. Já o usamos internamente desde o fim de 2025, em dezenas de projetos, e ele faz parte de como nossos engenheiros trabalham. Até esta página roda sobre o método: tanto o site que você está lendo quanto o site que documenta a metodologia são mantidos assim, de modo que a metodologia se documenta a si mesma a partir de um repositório que a usa. Quando dizemos que um plano consegue rodar por horas atravessando reinícios de contexto e continuar no rumo, é porque vimos isso acontecer no repositório que serve estas palavras.

Ele também pode ser instalado hoje, o que importa mais do que parece. Muita metodologia boa nunca sai do time que a inventou porque não há um jeito limpo de entregá-la. Esta tem um site público, um ponto de adoção canônico em deepworkplan.com/init, e uma skill instalável em DailybotHQ/deepworkplan-skill. O caminho entre ler sobre o método e rodá-lo no seu próprio repositório é um passo só: instale a skill, deixe que ela prepare o seu agente e então gere e execute um plano. Quisemos que a distância entre se interessar e executar fosse curta, porque é nessa distância que a maioria das metodologias morre.

A parte que achamos que realmente importa daqui a um ano é que ele independe da ferramenta. Há boas ferramentas nesse espaço que empacotam fluxos guiados por especificação, e o GitHub Spec Kit é um exemplo justo da categoria. A diferença está em onde o método vive. Essas ferramentas guardam o fluxo dentro da ferramenta, então adotar o método significa apostar que a ferramenta sobreviva e que cada agente que você usar fale o formato dela. O Deep Work Plan vive no repositório como arquivos que qualquer agente consegue ler, então não é uma aposta em um único fornecedor. Quando o cenário de ferramentas mudar de novo, e vai mudar, os planos, os controles e o estado continuam lá, no repositório, onde o próximo agente consegue retomá-los.

Onde ele não ajuda

Vale ser claro sobre o que o método não resolve: ele não transforma um objetivo ruim em bom. Se o plano é vago, o agente executa a vagueza com toda a fidelidade e os controles passam sobre um trabalho que ninguém queria. Quando a execução é assim tão rápida, a ambiguidade fica cara: a disciplina passou de vigiar o agente para escrever o plano, e um plano fraco continua sendo a forma de falhar. Agora dedicamos tempo de verdade ao plano, porque um plano preciso é a parte da qual toda a execução depende. Escrever um bom plano é definir o problema real e não os sintomas, fixar as restrições e os critérios pelos quais ele será validado, e antecipar onde o agente vai adivinhar para fechar essas lacunas antes de ele começar. Essa clareza é a parte que continua sendo nossa, e a mais difícil: o método não a substitui, ele a torna indispensável. É por isso que ele ganha o seu lugar no trabalho longo, e não numa mudança de uma linha: quanto mais longa a execução, mais vale ter pensado bem antes de delegar.

O que de fato mudou

O que mudou não é que nossos agentes ficaram mais inteligentes. Os modelos são os modelos, e vão continuar melhorando no próprio ritmo. O que mudou é que o trabalho não vive mais numa conversa que deixa de ser confiável à medida que cresce. Ele vive no repositório como um plano com controles, e essa é a parte que torna uma execução longa verificável quando termina e retomável quando para.

Essa mudança é o que permitiu que a velocidade da nossa migração se sustentasse quando todo mundo passou a contribuir. Um time que se move rápido sobre o produto e tudo o que o sustenta precisa de mais do que agentes capazes. Precisa de um jeito de apontar os agentes para um trabalho longo e confiar que o que volta corresponde ao que foi pedido, execução após execução, agente após agente. O repositório como ambiente de execução é como conseguimos isso, e o plano é aquilo de que o agente não consegue se desviar. Se no trabalho longo os seus agentes acabam resolvendo algo diferente do que você pediu, o conserto provavelmente não é um prompt melhor: é um plano contra o qual eles executam e um harness capaz de carregá-lo. Os modelos vão continuar melhorando sozinhos; o que põe essa capacidade para trabalhar a seu favor é o plano que você coloca na frente. Comece o seu em deepworkplan.com.