Vibe coding para documentar projeto antes de codar sem reinstruir a cada sessão

Perto das 3 horas de live, danilixz estava de papo com a audiência enquanto o agente seguia trabalhando na tela. Em vez de pedir desculpa pela pausa, ele apontou para lá e usou aquilo como prova do que vinha defendendo:

"Então, tipo, estou aqui com vocês aqui, mano. Ele está aqui, ó, ligado? Por quê? Porque ele tem um passo a passo do que é que ele tem de fazer."

Esse passo a passo não nasceu no pedido daquela hora. Ele foi escrito antes de o projeto começar, num documento, e é isso que danilixz chama de método: "é você instruir a inteligência com a documentação do que pretende fazer". Documentar o projeto antes de codar é o que compra as horas em que ninguém precisa ficar em cima do agente.

O que o documento economiza é reinstrução

Logo em seguida ele imita as ordens que estaria repetindo se o documento não existisse: "Aí eu não preciso de estar toda hora." e emenda com "faz isso daqui desse lado. Faz isso aqui funcionar. Faz aplicar esse motor." O que ficou para trás ali foi a instrução repetida.

Sem documento, você vira a memória do projeto. A cada sessão nova o agente chega zerado, e alguém precisa contar de novo como as partes se ligam e o que já foi decidido. O custo maior nem é o tempo gasto nisso. É que instrução dita de cabeça sai diferente a cada vez, e o projeto vai andando conforme a versão que você lembrou naquele dia.

Isso não se confunde com pedir ao agente o plano antes de ele executar uma tarefa. Aquele plano nasce e morre dentro do pedido. O documento do projeto tem outra duração: escrito antes da primeira linha de código, ele continua valendo na sessão seguinte, com outro pedido e outra conversa.

A parte pesada é o que vai escrito lá dentro

Ele descreve o conteúdo do documento assim:

"Você vai pegar no documento que você planeou tudinho dentro de uma lógica, dentro de uma ontologia, utilizando regras determinísticas para cada função do seu sistema, tá ligado? amarrando cada paragem, cada bagulho que tem ali"

Aí está o trabalho de verdade, e a live não mostra como esse arquivo fica pronto. danilixz chega a dizer que vai mostrar "só um bocadinho" do documento, a conversa segue e o arquivo não é aberto. Fica registrado o que ele afirma sobre o próprio método, sem que eu possa descrever o que está escrito ali dentro.

O que dá para copiar é a recomendação prática dele: "faça a documentação do seu projeto, fazer um PRD, fazer um BRD, tá ligado? Façam roadmap." Ele mesmo explica por que precisa dizer isso em voz alta no meio de uma live: "as pessoas não ligam muito a documentação".

Por que isso pesa mais no vibe coding

Num projeto escrito à mão, boa parte do combinado sobrevive na cabeça de quem escreve o código, e a documentação atrasada só cobra caro quando entra gente nova no time. No vibe coding quem escreve é o agente, e ele não acumula nada de uma sessão para a outra. O que ficou entendido ontem na conversa não existe hoje. Sobrevive o que está em arquivo. O mesmo problema apareceu em como planejar um projeto de software.

O arquivo sobre você e o documento do projeto

O arquivo de contexto no vibe coding cobre a outra metade do problema: ele descreve você, de onde veio e o que sabe fazer, e deixa o projeto de fora de propósito. O documento de que danilixz fala é o outro lado, o do projeto. Os 2 vivem separados porque as durações não batem: o arquivo sobre você atravessa projetos e continua servindo no próximo; o documento do projeto morre junto com o projeto.

2 ressalvas minhas, que a live não cobre

A primeira é sobre leitura. Documento que o agente não abre sozinho é decoração. Ele só vale se a sua configuração carrega aquele arquivo em toda sessão, ou se você aponta para ele dentro do pedido. Fora isso você escreveu um arquivo bonito que ninguém abre, continua reinstruindo tudo de cabeça e ainda ganha a sensação falsa de estar coberto.

A segunda é sobre validade. Documento desatualizado sai mais caro que documento nenhum, porque o agente segue com confiança o que está escrito e você gasta a sessão descobrindo por que ele insiste numa decisão que você abandonou faz 2 semanas. danilixz encosta nisso quando diz que a documentação não se escreve uma vez só: "se analisar a paragem de tempos a tempos redesenha o seu projeto".

O que fazer antes do próximo projeto

Escreva o documento antes da primeira linha de código, com PRD, BRD e roadmap se for o seu caso, e trate a parte das regras por função como o trabalho principal, não como anexo do plano. Depois, no primeiro pedido da próxima sessão, peça ao agente que diga o que leu do arquivo antes de mexer em qualquer coisa. Se ele não citar nada de lá, o documento não chegou até ele e você está de volta a repetir instrução na mão. Enquanto documenta, inclua também a estratégia de segurança: rls supabase mostra por que a proteção de dados tem que vir escrita no documento, não como uma conferência de última hora. E quando a segurança entra na equação, desde documentar falhas antes de corrigir até checar se o painel está exposto, o documento é o que permite sair do tapa-buracos e chegar na análise estruturada. A cena que abre este post está gravada, e dá para assistir à live inteira e ver o agente seguindo sozinho enquanto danilixz conversa com a audiência.