O que é PRD no vibe coding: planejar forte, executar barato

O que é PRD, na mesa do ia.de.gabinete, é o documento de requisitos do produto escrito no chat antes de qualquer código: problema, objetivo, métrica de sucesso, requisitos funcionais, escopo negativo, restrições e premissas. No dia 15 ele fez grilling (a IA o interrogou sobre o que queria), rodou 156 testes com Gemini, DeepSeek e Sonnet, e só então pôs o Sonnet para executar. Planejamento forte deixa a execução barata no vibe coding; sem o trilho, ele compara com trocar pneu com o carro andando.

O projeto classifica 10.769 decisões do Conselho Superior do Ministério Público de Goiás em 7 dimensões, com verificador que exige citação literal, e o PRD vem antes do código.

Os 7 campos, antes de qualquer código

Ele pede à IA para explicar o que é PRD.

o RD é os documentos de requerimentos do produto, requisitos do produto. É a documentação que define o que que é o produto, a funcionalidade deve fazer e por quê, antes de qualquer código ser escrito.

Product Requirements Document, na tradução que ele aceita: documentos de requisitos do produto.

o PRD ele contém o problema, o objetivo, métrica de sucesso, requisitos funcionais, a escopo negativo, restrições e premissas

O escopo negativo está na mesma lista que o requisito funcional: o que o produto não faz. Restrições e premissas entram no documento junto, ainda antes do código.

Depois da definição, ele descreve a skill. Você começa o projeto, fala o que é e o que quer, do seu jeito. Lança o "grill with docs". A skill abre uma sessão de brainstorm, faz uma série de perguntas, e vocês alinham os rumos. Depois do primeiro PRD, você fala: me faz o PRD.

Os 7 campos saem depois da sessão de perguntas.

Grilling no dia 15 e 156 testes

No dia 15 ele fez o design e a IA o interrogou.

como foi no dia 15, eu fiz o design, né, que fez aquele grilling, que é ah, eu eu fui interrogado pela inteligência artificial sobre o que o que o que que eu queria e como eu queria.

Depois do interrogatório, outro modelo deu a versão dele e bateu com o Cloud, para juntar o que fosse de bom e excluir o que fosse de ruim.

os testes foi feito 156 testes de como isso seria feito da melhor forma, porque eu testei com vários modelos. Eu testei com Gemini, eu testei com DeepSeek, eu testei com o Sonnet, testei com tudo que dava para testar para ver o que que seria melhor em cada etapa.

O grilling fecha o que ele quer; os 156 testes, com Gemini, DeepSeek e Sonnet, fecham como cada etapa deve ser feita. O código ainda vai correr nesse trilho.

No vibe coding, o Sonnet só roda no trilho

Quando outro modelo revisa, o critério é o trilho. Se o Sonnet fizer alguma coisa errada, é porque saiu do que foi planejado, e aí é fácil de corrigir.

você faz o planejamento forte, você faz etapas muito muito bem pensadas no começo, a execução fica barata, porque aí você põe o Sonnet para rodar tudo, já que ele tá dentro do trilho que foi planejado

No planejamento, gastar muito tempo tem jeito.

fazer isso depois, né, que já tá alguma coisa feita, que já tá rodando, é pior que aí você vai ter que refaturar todo o teu projeto e aí sim que você vai gastar um token absurdo

Por isso ele gasta o tempo no começo.

Agora você não faz isso no começo, é trocar pneu com carro andando

O mesmo builder já tinha separado o que é MCP como a camada de onde conectar. O PRD é outro papel: o que o produto faz e o que fica de fora, ainda sem código.

No vibe coding do dia 15 a ordem ficou grilling, 156 testes, 7 campos no documento, e o Sonnet no trilho.

Os 7 campos no chat, o código depois

Antes de pedir código, anota os 7 campos no chat e lança o "grill with docs". O Sonnet só entra quando esse documento já existe. A execução fica barata por isso: o modelo roda no trilho que foi planejado.

Quem quer ouvir o grilling do dia 15, os 156 testes e o pneu com o carro andando, assiste à live.