Uma tarefa não é um projeto.
Parece óbvio.
Ainda assim, é um dos erros mais comuns no trabalho com agentes.
A pessoa começa pedindo uma análise.
Depois pede um plano.
Depois uma implementação.
Depois uma mudança de direção.
Depois uma revisão.
Tudo no mesmo lugar.
No fim, a tarefa virou um depósito de decisões, exceções e pedidos antigos.
O agente perde a referência.
A pessoa também.
O problema não é continuar
Continuar uma tarefa não é sempre errado.
O problema começa quando ela deixa de ter um objetivo claro.
Uma tarefa boa responde a três perguntas:
- o que precisa ser resolvido agora;
- o que pode ser alterado;
- como saberemos que terminou.
Sem isso, qualquer novo pedido pode mudar o sentido de tudo o que veio antes.
“Agora também adiciona autenticação.”
“Antes, troca a arquitetura.”
“Esquece o plano e já faz.”
“Volta para a ideia anterior.”
Cada frase pode ser legítima.
Mas juntas, sem uma nova delimitação, produzem ruído.
Muitas iterações também aumentam o risco de alucinação
Um chat longo não guarda apenas decisões.
Ele acumula rascunhos, hipóteses, erros corrigidos, instruções superadas e informações incompletas.
Depois de muitas iterações, o agente pode tratar uma suposição antiga como fato.
Pode citar uma decisão que nunca foi aprovada.
Pode afirmar que validou algo que apenas foi discutido.
Pode preencher uma lacuna com uma resposta plausível, mas errada.
Isso é uma alucinação.
Não acontece apenas por falta de capacidade.
Acontece também quando o contexto ficou confuso.
Quanto mais uma tarefa mistura objetivos e versões de uma mesma decisão, mais difícil fica distinguir o que é atual, o que foi descartado e o que ainda precisa ser confirmado.
Não use um chat longo como fonte única de verdade.
Decisões importantes precisam sair da conversa e entrar em arquivos, testes, planos ou documentação.
Uma tarefa precisa caber em uma frase
Se você não consegue resumir a tarefa em uma frase, ela provavelmente está grande demais.
Exemplos ruins:
Entenda o projeto, defina a arquitetura, implemente o site,
escreva os textos, revise o design e publique.Exemplos melhores:
Analise a estrutura atual do projeto.
Não altere arquivos.
Liste riscos, lacunas e decisões pendentes.Crie um plano incremental para a internacionalização.
Não implemente.
Indique arquivos prováveis, dependências e validações.Implemente apenas o seletor de idioma definido na etapa 1 do plano aprovado.A diferença não é burocracia.
É direção.
Misturar fases cria falsas certezas
Quando descoberta, planejamento e implementação acontecem dentro da mesma tarefa, é fácil confundir hipótese com decisão.
O agente pode começar a editar antes de entender o problema.
Pode criar uma solução para um requisito que ainda vai mudar.
Pode seguir uma decisão antiga que já foi abandonada no meio da conversa.
O resultado parece avançar.
Mas acumula retrabalho.
Separar fases não torna o processo lento.
Evita velocidade na direção errada.
Divida pelo resultado, não pelo tamanho do pedido
Não basta quebrar um pedido grande em partes aleatórias.
A divisão precisa ter sentido.
Uma tarefa de diagnóstico entrega entendimento.
Uma tarefa de planejamento entrega uma sequência aprovada.
Uma tarefa de implementação entrega uma mudança verificável.
Uma tarefa de revisão entrega problemas, riscos ou ajustes.
Cada uma tem uma saída diferente.
Diagnóstico → entendimento do estado atual
Planejamento → plano pequeno e verificável
Implementação → alteração validada
Revisão → avaliação objetiva do resultadoQuando a saída está clara, fica mais fácil saber quando encerrar.
O contexto deve sobreviver à tarefa
Uma tarefa termina.
O conhecimento útil não pode terminar com ela.
Decisões importantes devem ir para arquivos do projeto:
AGENTS.mdpara regras duradouras;README.mdpara contexto geral;PLANS.mdpara etapas aprovadas;docs/para decisões, arquitetura e riscos;- testes e código para comportamento verificável.
Isso reduz a dependência da memória de uma conversa longa.
A próxima tarefa não precisa adivinhar o que aconteceu.
Ela começa pelos registros certos.
Um fluxo simples
Use uma tarefa para cada momento.
- Entenda o problema.
- Registre o que foi decidido.
- Planeje uma etapa pequena.
- Implemente apenas essa etapa.
- Valide.
- Abra a próxima tarefa com o resultado anterior como contexto.
Não é necessário criar uma tarefa para cada frase.
É necessário criar uma nova tarefa quando o objetivo muda.
Essa é a fronteira.
Encerrar também é trabalho
Muitas tarefas ficam abertas porque ninguém declarou o fim.
Ao concluir, registre:
- o que foi feito;
- os arquivos alterados;
- as validações executadas;
- os riscos restantes;
- o próximo passo recomendado.
Depois encerre.
Uma tarefa encerrada com clareza é mais útil do que uma tarefa interminável com muito histórico.
A regra básica
Não tente conduzir um projeto inteiro em uma única tarefa.
Dê a cada tarefa um objetivo, um limite e uma saída.
Registre as decisões que precisam sobreviver.
Vibe coding não é uma conversa sem fim.
É uma sequência de decisões que podem ser entendidas, revistas e continuadas.