Vibe coding para organizar vários documentos de plano sem apagar histórico

O jeito óbvio de arrumar um acervo de planos é juntar tudo num documento só e apagar os antigos. Thiago propôs exatamente isso ao agente, numa das sessões da série em que constrói uma agência de marketing ao vivo, e ouviu que as 2 pontas da proposta estavam erradas.

"Eu não tô gostando desse monte de plano solto. Você não consegue juntar todos esses planos e colocar as [tarefas] que já foram feitas e o que ainda falta ser feito em ordem [...] Daria até para deletar esses outros planos separados. Ou não, deixa assim mesmo que é melhor. Seja brutalmente honesto com isso."

A última frase é o que compra o não. Ele descreveu a arrumação que queria e, na mesma respiração, disse que talvez fosse melhor não mexer em nada. Sem essa abertura, o agente teria executado a fusão e a limpeza sem discutir.

O agente contou antes de opinar

A primeira coisa que o agente fez foi medir o tamanho do problema: "[Vasculhei] 18 planos." Depois cruzou os itens pendentes de cada um com o código que já estava escrito, para separar o que ainda era trabalho de verdade do que tinha sido feito em outro lugar ou abandonado no caminho. O veredito:

"Metade é status podre ou ideia engolida por outro plano."

Metade daqueles documentos continuava afirmando que havia trabalho pendente quando não havia mais. Isso explica a cena anterior ao pedido: o Thiago ia abrindo pasta, achando mais um plano que não lembrava, até dizer que estava ficando confuso de tanto plano.

Um documento com 18 planos dentro não é mais legível que 18

Fundir tudo não resolve porque o problema nunca foi o número de arquivos. Um documento que carrega 18 planos inteiros fica longo o bastante para ninguém ler até o fim, e um documento que ninguém lê até o fim informa tão pouco quanto os planos podres espalhados pelo repositório, com o agravante de ter cara de fonte oficial.

Tem também uma questão de natureza dos documentos, e o agente foi direto nisso. O plano que sai de uma sessão de trabalho é artefato daquela sessão: registra o que foi combinado ali, no contexto daquele dia. O roteiro do produto é outro tipo de documento, que precisa estar sempre certo porque é ele que orienta a próxima decisão. Fundir os 2 estraga os 2. O artefato de sessão perde a data e vira promessa permanente, e o roteiro ganha um passado que ele não deveria carregar.

Apagar o plano morto apaga a decisão junto

Deletar é a parte cara, e o agente explicou por quê:

"Deletar planos perd[e] histórico útil[:] [por]que decidimos X"

Algum tempo depois, alguém pergunta por que o produto funciona daquele jeito estranho. A resposta está escrita no plano que você ia deletar, junto com a alternativa descartada e o motivo. Ninguém guarda isso na cabeça, e o histórico do repositório não cobre o buraco, porque ele registra o que mudou e não o que foi considerado e recusado.

O que incomoda no plano morto é ele parecer atual. Um documento antigo que se anuncia como antigo vira acervo, e o mesmo documento sem esse aviso custa uma tarde de conferência toda vez que alguém tropeça nele.

O caminho do meio é um índice vivo e um carimbo de obsoleto

A recomendação do agente foi curta:

"melhor [...] marcar obsoleta [...] um índice curto e vivo"

O índice é um documento novo, magro, que aponta para os planos que ainda valem e diz o que vem primeiro. Ele é o único do acervo que precisa estar sempre correto, e por ser curto isso é viável. Os outros 18 podem envelhecer em paz, desde que envelheçam identificados.

O carimbo de obsoleto faz o resto do trabalho e custa 1 linha no topo do arquivo. Ele não tira nada de dentro do documento; muda o que o documento afirma sobre si mesmo. O texto continua lá para quem for procurar a decisão, e sai da sua fila de trabalho porque parou de se apresentar como pendente. O agente fechou oferecendo exatamente isso:

"eu crio o [índice] ativo e marco os planos mortos sem deletar nada"

Por que o acervo cresce assim no vibe coding

Escrever um plano à mão dói, então você escreve poucos. Pedir um plano ao agente é barato, e ele sempre entrega. Toda sessão que começa com "faz um plano pra isso" termina com mais um documento no repositório.

O acervo passa a crescer na velocidade das sessões, não na velocidade das decisões. Em pouco tempo você tem mais planos do que memória para saber quais valem, e nenhum deles avisa que morreu. É uma dívida nova, que quem programava sem agente não tinha, e ela aparece cedo em qualquer projeto tocado por vibe coding. Foi o mesmo caminho de vibe coding para monitorar memoria ao rodar varios workers em paralelo.

O outro extremo do mesmo problema está no checklist de retomada no vibe coding, onde outro builder fecha a sessão escrevendo o passo a passo para retomar no dia seguinte, um artefato feito para ser lido de novo, enquanto aqui o acervo é feito de artefatos que ninguém relê e ninguém sabe se ainda valem. A conversa completa, com o agente dando o veredito plano por plano, está na live inteira.

O que fazer com o seu acervo hoje

Abra a pasta onde seus planos moram e conte quantos são. Peça ao agente para cruzar os itens pendentes de cada um com o código que já existe e responder, plano por plano, se aquilo ainda é trabalho real. Com essa lista na mão, escreva um índice de uma página com o que ficou vivo e a ordem em que atacar, e ponha uma linha de obsoleto no topo de cada plano que morreu. Nada é deletado, e a partir de amanhã existe um documento só que você precisa manter em dia.