Vibe coding para salvar regras positivas e negativas em markdown: o que o chat não guarda

Jhonatan aprovou uma arte, decidiu que aquilo seria o padrão de todas as artes seguintes e, antes de mandar gerar a série, mandou o agente abrir um arquivo markdown no projeto. Dentro dele iam 2 coisas: a forma que a arte tem de ter e a lista do que ela não pode ter.

A metade que chama atenção é a negativa. Guardar a descrição do padrão é a parte fácil; guardar junto o que está proibido é o pedaço que costuma faltar, e é a falta dele que faz um documento de padrão parar de descrever o projeto que você tem hoje.

"Salva tudo isto [música] no ponto MD, a forma que tem de ser, os negativos que não pode ser e a forma que precisa ser para este doping correr de forma autónoma."

Por que a proibição quase nunca chega ao arquivo

Quando você descreve um padrão, você descreve o que quer: a fonte, o enquadramento. O que você não quer ainda não passou pela sua cabeça, porque ninguém errou até ali.

A proibição nasce depois, no instante em que o agente entrega alguma coisa fora do combinado. E nesse instante a correção sai por onde é mais rápido, que é a conversa. Quem faz vibe coding com agente vive nessa rotina: o desvio aparece na tela, você corrige por escrito na hora. Você escreve "tira esse fundo", o agente ajusta, o resultado sai certo e a frase morre no histórico. O documento continua com a metade positiva que você redigiu no começo, e cada correção que não volta para ele deixa o arquivo mais defasado sem que nada no arquivo indique isso.

Validar 3 capas antes de escrever a regra

O padrão que ele estava prestes a congelar era uma arte já aprovada, apontada na tela:

"Esse é o padrão que eu quero em todas as artes. Daqui para a frente, os carrosis vão [música] ser assim."

Mesmo com a arte aprovada na frente, ele pediu uma amostra antes de escalar:

"vamos criar três opções de capas, apenas de capa para eu validar que está tudo certinho"

São 3 capas e nada além da capa, conferidas antes de a regra virar texto no arquivo. Escrever no documento uma regra que você ainda não viu funcionando é gravar um palpite no projeto: se a sua descrição do padrão estiver ambígua, a ambiguidade entra no arquivo e volta em toda geração seguinte com o peso de uma decisão. Uma amostra pequena custa pouco e conserta a redação da regra enquanto ela ainda é barata de mudar.

O arquivo existe para você não repetir

O motivo está dito no próprio pedido: o arquivo é para aquilo "correr de forma autónoma" depois. Ele serve para a próxima geração não depender de alguém redigitar o combinado.

Nesse trecho a legenda embaralha uma palavra ("este doping"), então o sujeito exato da frase fica ilegível na transcrição e eu não vou adivinhar qual era. O que sobrevive legível é o critério, e o critério é rodar sem ele no meio.

A live não mostra a série sendo gerada sozinha depois disso. O que está gravado é o pedido e o objetivo declarado; se o arquivo cumpriu o que ele queria, ficou fora dessa transmissão.

Um dia antes, a mesma proibição vivia no chat

Deste mesmo builder já existe um post sobre uma live do dia anterior: instrução negativa quando o agente foge do padrão. Lá o agente já tinha fugido do padrão, e a proibição foi escrita naquele momento, na conversa, para corrigir o desvio que acabara de acontecer. Aquele post também registra que a correção não resolveu dentro da live.

Aqui a ordem é outra. As regras positivas e as negativas vão para um arquivo do projeto antes de a série ser gerada, com o objetivo declarado de rodar sozinho depois. Uma correção escrita no chat vive na conversa e acaba com ela; uma regra escrita no arquivo continua lá depois que a sessão fecha.

Ligar as 2 lives, dizer que ele passou a escrever em arquivo porque a correção no chat tinha falhado na véspera, é leitura minha. A transcrição não faz essa ligação e ele não comenta a live do dia anterior. O que dá para afirmar é a sequência: um dia, correção na conversa; no dia seguinte, regra no arquivo.

Onde o vibe coding corrige e onde ele ensina

A conversa é o lugar mais fácil de corrigir e o pior lugar de guardar. Você vê o desvio, escreve uma frase, o agente ajusta e o resultado sai, sem custo nenhum no momento. A cobrança vem na sessão seguinte, com o contexto zerado, quando você digita a mesma frase de novo, e na outra depois dessa também.

No vibe coding, a diferença entre corrigir e ensinar está em onde a frase termina: quem deixa a regra no chat volta a escrevê-la amanhã, e quem move a mesma regra para o arquivo do projeto escreveu aquilo uma vez.

O que eu acho disso, e não está na live

Daqui em diante é análise minha, não o que a gravação mostra.

Um arquivo que o agente não lê sozinho não muda nada. Ele só passa a valer se a sua configuração puxa aquele arquivo em toda sessão, ou se você aponta para ele dentro do pedido; salvar sem carregar tem o mesmo efeito de não salvar.

Regra negativa nasce de um caso concreto e tende a sair específica demais. "Não use aquela ferramenta" fecha o desvio que você viu e deixa abertos os vizinhos dele. Por isso vale escrever, ao lado da proibição, por que ela existe: o motivo cobre os casos que você ainda não viu, enquanto a proibição sozinha cobre só o que já aconteceu.

E um documento de padrão compete com o próprio padrão. Quando a arte aprovada muda, o arquivo tem que mudar junto, e se ele não muda o agente passa a seguir com disciplina uma regra que você já abandonou. Isso fica pior do que não ter arquivo nenhum, porque a saída continua consistente e consistência tem cara de acerto.

Escreva as 2 metades no arquivo

Da próxima vez que você corrigir o agente por desvio de padrão, não termine na correção. Abra o arquivo do projeto e escreva as 2 metades, o que tem de ser e o que não pode ser, e ao lado de cada proibição escreva o motivo dela. Assim a sessão seguinte começa com a regra já escrita, em vez de começar com você lembrando dela.

Dá para assistir à live e ver o pedido inteiro, com a arte aprovada na tela.