Contexto limpo no vibe coding: o que tirar antes de mover o arquivo

Um arquivo de contexto tem que se bastar no lugar onde vai ser lido, não no lugar onde foi escrito. Martin percebeu isso na primeira leitura do arquivo que tinha acabado de pedir, antes de qualquer coisa quebrar.

Ele tinha batido o martelo sobre qual produto ia construir, depois de comparar as ideias finalistas, e pediu ao assistente um arquivo de contexto do projeto para não precisar reexplicar tudo a cada sessão nova. O assistente criou o arquivo e explicou o mecanismo: ao abrir uma sessão nova dentro daquela pasta, "esse arquivo já vai carregar automaticamente como contexto do projeto". É esse arquivo que faz o vibe coding para retomar onboarding de onde parou funcionar: o estado da sessão anterior fica escrito no documento, não na sua memória. Martin foi ler o que tinha sido escrito e parou nas primeiras linhas. Isso aparece também em vibe coding para o subagente nao compactar o contexto do pai.

eu já vi aqui que tem cagada

O documento contava a própria história em vez de contar o produto

O arquivo abria se apresentando: "Escrito depois de uma pesquisa extensa comparada a quatro ideias de produto." Em seguida mandava consultar o histórico da decisão em arquivos HTML que estavam na pasta atual.

Nada daquilo era mentira. O assistente tinha passado a conversa inteira comparando 4 ideias de produto, e escreveu a proveniência porque era exatamente disso que a conversa tratava. Ele documenta o próprio processo por padrão, com os ponteiros de onde veio. O problema é que a sessão seguinte não precisa da deliberação, precisa da decisão.

A regra do contexto limpo no vibe coding: o arquivo se basta onde vai ser lido

A razão que Martin deu para o conserto é a regra inteira, dita em voz alta:

como eu vou abrir em outra pasta, tu não pode mencionar as outras quatro ideias e dizer para ver histórico em HTMLs que estão dentro dessa pasta aqui

E o motivo, completado na frase seguinte: "porque ele não vai ter acesso a esses documentos".

Um arquivo de contexto quase nunca é lido onde foi escrito. Ele nasce numa pasta e é aberto em outra, ou na mesma pasta muito depois, quando metade dos arquivos citados já mudou de nome. Toda referência que manda ver o comparativo ali na pasta é um ponteiro que só vale no endereço onde foi escrito. Assim que o documento muda de casa, o ponteiro morre, e continua lá com cara de instrução válida.

A instrução de Martin foi curta: tirar a menção aos comparativos e descrever só a ideia escolhida.

Não quero que fale sobre comparativo com outras.

O assistente voltou com o que tinha feito: "removi todas as referências as outras três ideias, ao processo de comparação e os arquivos HTMLs". As 3 ideias descartadas saíram junto com o caminho que apontava para elas, e o documento passou a se bastar sozinho, falando só do produto escolhido.

O custo desse erro é silencioso

Não existe aviso para esse tipo de erro. Se Martin tivesse movido o arquivo com a proveniência dentro, o build seguiria normalmente: a sessão nova abriria a pasta, carregaria o contexto, leria a instrução de consultar o histórico nos HTMLs daquela pasta, não acharia nada e seguiria em frente. Nenhum erro, nenhum log.

No cenário pior, a sessão nova leva a sério a parte que ficou escrita ali: que houve 4 ideias em disputa e que o produto foi escolhido comparando com elas. Aí o assistente começa a pesar alternativas que o projeto já abandonou, ou pede seu parecer sobre um caminho que você matou na semana passada. Você não vai desconfiar do arquivo de contexto, porque ele foi feito justamente para você não ter que lembrar do que tem lá dentro. Esse erro aparece na leitura ou não aparece nunca, e foi por ler que Martin pegou.

A checagem que custa uma leitura antes de mover

Não tem ferramenta para isso. É reler o arquivo de contexto uma vez, pensando na pasta onde ele vai ser aberto, procurando por:

- caminho: qualquer nesta pasta, no arquivo ao lado, veja o anexo, nome de arquivo solto - decisão descartada: a opção que perdeu, a alternativa considerada, o processo que levou à escolha - pressuposto de sessão: como conversamos, conforme decidimos acima, qualquer coisa que dependa da conversa em que o arquivo nasceu

O que sobra depois do corte é o que um leitor novo, sem histórico e sem acesso a nada, consegue usar sozinho. A régua é a mesma para tudo o que você escreve para ser lido depois no vibe coding: se o texto precisa do lugar onde nasceu para fazer sentido, ele ainda não está pronto para sair de lá.

Sobre o que deve entrar no documento, escrevemos em o que escrever dentro do arquivo de contexto; aqui a pergunta é só o que precisa sair quando ele muda de pasta.

Ele levou o arquivo para a pasta nova ainda na live

O que dá peso à cena é que Martin não parou na hipótese. Ele achou a pasta antiga, criou uma pasta nova, levou o arquivo corrigido para lá, abriu aquela pasta como projeto e pediu ao assistente que lesse o arquivo e dissesse o que tinha entendido do que estavam construindo. O documento chegou na pasta nova sem nenhum ponteiro morto dentro, e essa é a prova que a checagem existe para produzir.

Faça isso com o seu arquivo de contexto hoje: abra ele numa pasta onde nada mais existe e leia como se fosse a primeira vez. Toda frase que só funciona porque você sabe o que tem na pasta de origem é uma frase para reescrever. O resto do caso está em assistir à live, com o arquivo sendo escrito, corrigido e movido de pasta na mesma sessão.