Vibe coding para dar exemplo de referência pra IA: aponte o arquivo

Quando o formato que você quer já existe num arquivo seu, pare de descrever esse formato. Aponte o arquivo, nomeie as dimensões dele que devem ser copiadas e diga qual delas muda no caso novo. Martin Blume montou um pedido assim, ao vivo, na hora de gerar uma tabela a partir de uma nova fonte de dados.

Ele tinha acabado de conectar o assistente a essa fonte e ia mandar puxar a lista. Antes disso, freou:

Só antes que você faça isso, dá uma olhada no HTML que nós criamos

O arquivo era um HTML que ele tinha gerado antes, num pedido anterior, com dados de outra origem. Em vez de escrever de novo como a tabela deveria sair, mandou o assistente ler o que já estava no disco.

Descrever um formato em palavras custa caro e ainda sai ambíguo

Descrever em texto o formato de uma tabela que você já tem na cabeça consome um parágrafo inteiro: visual limpo, cabeçalho legível, filtro em cima, uma coluna de resumo curta. Quando o parágrafo acaba, arquivos muito diferentes entre si atendem a ele por completo, e nenhum é necessariamente o que você imaginou. Escrever mais não tira a ambiguidade, só a empurra para outro lugar.

Um arquivo que já existe é a especificação completa, e você não precisou escrever nenhuma linha dela. As decisões estão todas tomadas ali, inclusive as que você jamais lembraria de citar num prompt, e o assistente lê o conjunto de uma vez. Foi o que Martin fez ao mandar abrir o HTML antes de qualquer outra coisa, trocando a descrição pelo caminho de um arquivo.

O que separa uma referência útil de um pedido de fazer igual

Apontar o arquivo sozinho não resolve. Um pedido de fazer parecido com esse deixa o assistente escolher o que conta como parecido, e ele pode ficar com a aparência e refazer o conteúdo, ou manter o conteúdo e inventar outra apresentação. Você estreitou o intervalo de resultados possíveis sem fechá-lo.

Martin nomeia as dimensões na mesma frase do pedido:

eu quero que você gere um HTML parecido com esse que eu tô mencionando em termos de, pô, eh, o estilo de tabela, as informações

O trecho que carrega o peso é o "em termos de". Ele delimita a semelhança a 2 coisas nomeadas: o estilo da tabela e as informações que aparecem. O que ficou fora dessa lista fica livre, e fica livre de propósito.

Fechado o pedido, ele manda o assistente ler o arquivo e dizer o que entendeu:

Tu consegue dar uma olhada nesse HTML para eu ver se você entendeu a tarefa

A checagem vem antes de existir arquivo novo.

O critério da última coluna mudou porque o caso mudou

No arquivo de referência, a última coluna classificava os itens por dificuldade de replicação. O pedido novo mantém a coluna e troca o critério: ele manda classificar por complexidade de "reproduzir isso no Brasil". A lista nova serve a outra pergunta, e a régua da última coluna mudou junto.

Essa é a parte mais fácil de esquecer, justamente porque a referência é aquilo que você aprovou antes. Sem essa frase, o resultado provável é o arquivo velho com dados novos dentro, incluindo as partes que já não faziam sentido no caso novo, e você só descobre lendo a tabela pronta com atenção. A régua antiga parou de valer, e essa informação está só com você.

A live não mostra o resultado desse pedido: logo depois, a coleta na nova fonte travou e ele mudou de método.

No vibe coding, apontar só funciona a partir do segundo arquivo

O método inteiro depende de um artefato anterior existir. Quem está no primeiro entregável de um tipo não tem para onde apontar e vai gastar o parágrafo descrevendo, aceitando o resultado aproximado e corrigindo depois. A partir do segundo, o pedido encolhe para um caminho de arquivo, 2 dimensões nomeadas e uma diferença.

Isso muda o que vale a pena guardar. O primeiro HTML de tabela, o primeiro relatório que saiu do jeito que você queria, cada um vira o molde dos próximos da mesma família. Guarde num lugar que você ache sem procurar, com nome que você reconheça daqui a 3 semanas. Quem faz vibe coding produz muito arquivo descartável, e deixar o bom se perder no meio cobra o preço de descrever tudo de novo na próxima. O mesmo vale para as avaliações negativas que você coleta, que viram referência do que evitar, como em avaliar reclamações de app. A mesma lógica de guardar o que funciona vale quando você tem uma régua de preço anterior, como em precificar usando referência de hábito. O mesmo problema apareceu em yolo mode.

Como escrever o pedido da próxima vez

Comece pelo arquivo: o caminho dele, e uma ordem de olhar antes de fazer qualquer coisa. Depois nomeie as dimensões que devem vir iguais, usando substantivos que apontem partes visíveis do arquivo, como estilo de tabela e informações. E escreva a diferença, o que muda porque o caso é outro, mesmo que pareça óbvio para você. Vale também acompanhar a evolução dessa técnica quando ela aparece em resposta ruim da IA no vibe coding. Vale ver como isso terminou em alucinação de número no vibe coding. O mesmo problema apareceu em seo para ia.

Vale assistir à live e comparar o tamanho desse pedido com a quantidade de coisa que ele especifica. É um dos momentos em que o vibe coding se apoia mais no que você já produziu do que no que você consegue descrever.