Prompt para gerar código: 8 padrões que tiram o ar de tutorial genérico da IA

A IA gera código que funciona, mas parece copiado de um tutorial de 2021. Variável data, função de 80 linhas, um try/catch genérico engolindo qualquer erro e zero relação com o resto do seu projeto. O problema não é o modelo. É o seu prompt.

Quando você escreve um prompt para gerar código tipo "cria uma função que valida e-mail", o modelo não tem como saber qual é o seu padrão. Ele cai no que a documentação oficial da Anthropic chama de output "on distribution": a média de tudo que ele viu treinando. No frontend isso virou um apelido, "AI slop". No backend ninguém deu nome, mas é a mesma coisa — código correto, genérico, que não conversa com a sua base.

Neste post tem oito padrões de prompt para gerar código que segue o padrão do seu projeto, não o exemplo de tutorial. Todos saem direto das docs oficiais de prompt engineering da Anthropic e de boas práticas do Claude Code. Cada um vem com o prompt fraco, o prompt forte e o porquê da diferença. Se você quer o panorama antes dos padrões, vale ler o guia honesto de engenharia de prompt primeiro.

TL;DR

• O que é: oito padrões de prompt para a IA gerar código no seu estilo, não no estilo médio da internet.
• Pra quem: dev que usa Claude, Cursor, Copilot ou qualquer assistente e cansou de reescrever o que a IA entrega.
• Custo: zero. É só mudar como você escreve o prompt.
• Base: docs de prompt engineering da Anthropic + best practices do Claude Code.

Por que a IA entrega código genérico

A IA não lê a sua mente. As docs do Claude Code são diretas nesse ponto: "Claude consegue inferir intenção, mas não consegue ler sua mente." E a analogia que a Anthropic usa pra prompt é boa: trate o modelo como um funcionário brilhante, mas novo, que não conhece suas convenções nem seu fluxo. Um sênior recém-contratado, sem onboarding, escreve exatamente o código genérico que você está vendo.

O modelo genérico não vem de burrice do modelo. Vem de ausência de contexto. Você sabe que o projeto usa Repository, que erro vira exception tipada, que nada de lib nova sem aprovação. O modelo não sabe nada disso até você falar. Os oito padrões abaixo são oito formas de falar.

Os 8 padrões de prompt para gerar código que segue o seu projeto

1. Dê um papel e trate a IA como o novo contratado

A coisa mais barata que existe. Uma frase de papel no início já foca o comportamento do modelo. "Você é um engenheiro Laravel sênior que segue PSR-12 e prefere código explícito a mágica." Não é firula — a própria doc mostra que um system prompt de uma linha já muda a saída.

# Fraco
Escreve uma função que importa usuários de um CSV.

# Forte
Você é um dev sênior Laravel 11, PSR-12, que prefere actions
invocáveis a controllers gordos. Escreve uma action que importa
usuários de um CSV.

O papel não é decoração. Ele estreita o espaço de respostas possíveis antes mesmo do modelo começar a escrever.

2. Aponte um arquivo de referência: "siga o padrão de X"

Esse é o padrão que mais muda o jogo, e o mais ignorado. Em vez de descrever seu estilo, aponte para o código que já tem ele. As docs do Claude Code trazem o exemplo quase literal: em vez de "adiciona um widget de calendário", diga "olha como os widgets existentes são implementados na home. HotDogWidget.php é um bom exemplo. Segue o padrão pra implementar um widget de calendário, sem libs além das que já estão no projeto."

# Fraco
Cria um endpoint pra listar pedidos.

# Forte
Olha o app/Http/Controllers/InvoiceController.php — ele é o padrão
de controller REST aqui (resource, form request, resource collection).
Segue exatamente esse padrão pra criar o endpoint de pedidos.

A diferença é brutal. O modelo para de inventar uma arquitetura e passa a copiar a sua. Convenção de nome, tratamento de erro, formato de resposta — tudo vem do arquivo que você apontou. Se você usa Claude Code, referencia o arquivo com @ e ele lê antes de responder.

3. Mostre exemplos do seu estilo (few-shot)

Quando não dá pra apontar um arquivo inteiro, mostre um par de exemplos. Few-shot (ou multishot) é, segundo a Anthropic, "uma das formas mais confiáveis de guiar formato, tom e estrutura" da saída. A recomendação concreta: 3 a 5 exemplos, relevantes, diversos e dentro de tags <example> pra ele não confundir exemplo com instrução.

Segue esse estilo de teste. Exemplos:

<example>
it('rejeita e-mail sem arroba', function () {
    expect(fn () => Email::from('invalido'))
        ->toThrow(InvalidEmail::class);
});
</example>

Agora escreve os testes pra classe Cpf seguindo o mesmo estilo:
Pest, expectativa funcional, exception tipada.

Dois ou três exemplos do seu jeito de testar valem mais que um parágrafo descrevendo o seu jeito de testar.

4. Diga o que fazer, não o que evitar

Parece detalhe, mas a doc é explícita: para controlar a saída, diga o que fazer em vez do que não fazer. O exemplo oficial é de prosa, mas vale igual pra código. "Não usa abstração desnecessária" é fraco — o modelo fica adivinhando o que você considera desnecessário. "Resolve com uma função pura, sem classe nem injeção de dependência" é forte.

# Fraco
Não deixa o código verboso.

# Forte
Resolve em no máximo 15 linhas, com early return em vez de
if aninhado, e sem comentário explicando o óbvio.

Instrução negativa deixa o alvo em aberto. Instrução positiva fecha o alvo.

5. Explique o porquê de cada regra

Esse é sutil e poderoso. Quando você dá o motivo por trás de uma regra, o modelo generaliza pra casos que você nem listou. A doc tem o exemplo perfeito: "NUNCA use reticências" funciona pior que "sua resposta vai ser lida por um TTS, então nunca use reticências porque o motor não sabe pronunciar". O modelo é esperto o bastante pra generalizar a partir da explicação.

# Fraco
Não usa facade Cache direto no domínio.

# Forte
Não usa a facade Cache dentro de classes de domínio — elas têm que
ser testáveis sem o framework Laravel carregado. Injeta uma interface
de cache no construtor.

Com o porquê, o modelo passa a aplicar a regra em situações análogas — não usa Auth, não usa Request global, e por aí vai. Sem o porquê, ele obedece literal e erra no caso seguinte. (É o mesmo princípio do prompt mestre em XML que a gente usou pra gerar ADRs com Claude: contexto explícito antes da tarefa.)

6. Trave a stack, a versão e as libs permitidas

Metade do código genérico vem de o modelo escolher uma lib que você não usa. Ele importa axios num projeto que usa fetch, sugere moment em 2026, instala um pacote pra fazer o que o framework já faz. A correção é uma linha: declare a stack, a versão e a fronteira de dependências.

# Fraco
Faz a chamada HTTP pra API de pagamento.

# Forte
PHP 8.3, Laravel 11. Usa o Http client nativo do Laravel
(Illuminate\Support\Facades\Http), não Guzzle direto. Não adiciona
nenhuma dependência nova ao composer.json.

"Sem dependência nova" é a frase que mais economiza review. Ela força o modelo a resolver com o que você já tem.

7. Peça solução geral, não decoreba de teste

Um vício conhecido: o modelo às vezes foca tanto em fazer o teste passar que hard-coda o resultado em vez de implementar a lógica. A própria Anthropic publica um trecho de prompt pra evitar isso — vale guardar:

Escreve uma solução geral e de alta qualidade. Não faz hard-code de
valores nem soluções que só funcionam pros casos de teste. Implementa
a lógica real que resolve o problema pra qualquer entrada válida.
Testes servem pra verificar correção, não pra definir a solução.

O mesmo vale na direção oposta: Opus e os modelos recentes têm tendência a over-engineer — criar arquivo extra, abstração que ninguém pediu, flexibilidade pra um futuro hipotético. Se é isso que te incomoda, a doc tem o contraveneno: "Evite over-engineering. Só faz mudanças diretamente pedidas ou claramente necessárias. Um bugfix não precisa limpar o código ao redor."

8. Feche o loop com um critério de verificação

O modelo para quando o código parece pronto. Sem um teste que ele possa rodar, "parece pronto" é o único sinal que ele tem — e você vira o loop de verificação. As docs do Claude Code são categóricas: dê ao modelo um check que ele mesmo rode.

# Fraco
Escreve uma função validateEmail.

# Forte
Escreve uma função validateEmail. Casos de teste: user@example.com
é true, "invalido" é false, user@.com é false. Roda os testes depois
de implementar e corrige até passar.

Com critério de verificação no prompt, o modelo implementa, roda, lê o resultado e itera sozinho. Sem ele, você é quem descobre o bug — em produção, no pior caso.

Onde isso ainda falha

Padrão de prompt não conserta tudo. Três limites honestos:

• Contexto tem teto. Se você joga o projeto inteiro no prompt, a performance cai e o modelo começa a "esquecer" instrução. Aponte arquivos específicos em vez de despejar a base toda. Em projeto grande, o melhor "prompt" nem fica no chat — fica num CLAUDE.md enxuto com as convenções, carregado em toda sessão.
• Regra demais vira ruído. Um arquivo de regras inchado faz o modelo ignorar metade. A própria doc avisa: pra cada linha, pergunte "remover isso faria o modelo errar?". Se não, corta.
• Verificação você não delega. O modelo gera uma implementação plausível que não cobre o edge case. Se você não tem teste, não tem como confiar. Não dá pra verificar, não sobe.

FAQ rápido

Preciso decorar os oito? Não. Comece por dois: apontar um arquivo de referência (padrão 2) e travar a stack (padrão 6). Sozinhos já eliminam a maior parte do código genérico.

Isso vale só pro Claude? Os exemplos são das docs da Anthropic, mas os princípios — papel, exemplo, contexto, verificação — valem pra qualquer LLM de código. Os melhores prompts para código não dependem do modelo — dependem de contexto. Cursor, Copilot, Gemini: muda a sintaxe de referenciar arquivo, não muda o conceito.

E se eu repetir as mesmas regras todo dia? Tira do chat e põe num arquivo de convenções (CLAUDE.md, .cursorrules, regra de projeto). Carrega sozinho, todo prompt, sem você recolar. É a forma definitiva do padrão 2.

Few-shot não enche o contexto? Três a cinco exemplos curtos cabem fácil. O ganho de consistência paga o custo de tokens com folga — especialmente em geração repetitiva, como uma leva de testes ou migrations.

Conclusão

Código genérico da IA não é limite do modelo. É falta de contexto no prompt. Os oito padrões são oito formas de dar esse contexto: papel, arquivo de referência, exemplo, instrução positiva, o porquê, a stack travada, a exigência de solução geral e o critério de verificação. Junta dois ou três e a saída deixa de parecer tutorial e passa a parecer parte do seu projeto.

O próximo salto é parar de pensar em prompt isolado e começar a pensar em arquitetura — como o contexto, as ferramentas e a verificação se encaixam num sistema que produz código bom de forma consistente, não por sorte. É exatamente isso que a gente coloca na mesa no Workshop Arquitetando Soluções de IA: como desenhar soluções de software com agents de IA, do prompt à arquitetura, com código rodando. Se você quer ver o assunto deste post no nível de sistema, é por ali.

E se a ideia de IA-para-código no centro do projeto te interessa, o passo seguinte é entender como ela deixa de ser assistente e vira motor de negócio.