Você pede pra IA “analisa esse código” e recebe uma resposta genérica, meio sem noção do que você realmente queria. Aí você reformula, adiciona duas frases de contexto, e do nada a resposta fica cirúrgica. Não foi sorte. Não foi a IA “acordando melhor” naquele dia. Foi engenharia de prompt, e é sobre isso que eu quero falar aqui de um jeito direto, sem enrolação.
Uma coisa que preciso deixar clara logo de cara: a IA não adivinha o que você quer. Ela responde ao que você escreve. Se você escreve mal, ela responde mal. Parece óbvio, mas é surpreendente quantas pessoas tratam prompt como “só um textinho qualquer” e depois reclamam que a resposta veio ruim.
Prompt não é fórmula mágica
Antes de entrar na prática, um alerta: você vai encontrar curso, vídeo e ebook vendendo “os segredos definitivos da engenharia de prompt”. Desconfie. O que funcionava bem em 2024 pode não funcionar do mesmo jeito hoje, porque os modelos evoluem e mudam de comportamento. Engenharia de prompt não é decorar truque, é entender como pensar junto com a IA. Isso é uma mistura de arte — você testa formas diferentes de pedir a mesma coisa — e ciência, porque você busca repetibilidade. Se um prompt funcionou hoje, ele precisa funcionar amanhã.
E tem outro ponto que muita gente ignora: um prompt que funciona bem no ChatGPT pode não funcionar igual no Gemini ou no Claude. Cada modelo foi treinado com dados e arquiteturas diferentes. Não existe prompt universal. Mudou o modelo, você precisa adaptar.
Os quatro componentes de um prompt bem estruturado
Na prática, todo prompt bem construído tende a ter até quatro elementos. Você não precisa usar os quatro sempre — às vezes uma instrução clara já resolve —, mas quando a tarefa é complexa, combinar esses elementos muda o resultado.
1. Contexto (quem a IA é). Você define o papel que ela deve assumir. Em vez de “analisa esse código”, tente:
“Você é um engenheiro de software sênior especializado em depuração de aplicações C/C++.”
Isso direciona o tipo de raciocínio e o ponto de vista da resposta. Não é papo de personalidade escondida — é você guiando o estilo e a profundidade técnica.
2. Instrução (o que você quer que ela faça). Resumir, classificar, gerar código, explicar passo a passo. Regra prática que eu sigo: uma instrução clara por prompt. Se você tenta pedir cinco coisas de uma vez — “resume isso, traduz aquilo, sugere melhorias, classifica e ainda me dá uma recomendação estratégica” — você está sobrecarregando o modelo. Ele precisa integrar tudo numa resposta só e, nesse processo, erra ou alucina. Quebre em prompts menores.
3. Entrada de conteúdo (a matéria-prima). Sem conteúdo fornecido, a IA só responde de forma genérica. E aqui vai uma prática que faz diferença real: separe a instrução do conteúdo usando delimitadores, tipo três aspas ou três hashtags. Exemplo:
Instrução: resuma as principais etapas de implementação da API a partir do texto abaixo.
"""
[cole aqui a documentação da API]
"""
Sem essa separação, o modelo pode interpretar parte do conteúdo como instrução e ignorar trechos importantes.
4. Formato (como você quer a saída). Muita gente esquece esse item e depois reclama que a resposta veio bagunçada, com comentário no meio do código. Um exemplo direto que costumo usar:
“Crie uma função em Python que receba uma lista de objetos de usuário, cada um com ID e nome, e retorne um objeto JSON mapeando IDs para nomes. Formate a saída apenas como JSON, sem texto explicativo antes ou depois.”
Se você não especifica o formato, o modelo decide por você — e às vezes ele decide escrever um textão explicativo antes do código que você só queria colar direto.
Um exemplo de prompt fraco vs prompt bem construído
Fraco:
“Melhora esse código.”
Bem construído:
“Você é um desenvolvedor sênior focado em performance e legibilidade. Analise a função abaixo e sugira até três melhorias concretas, cada uma com uma frase explicando o motivo. Não reescreva a função inteira, apenas liste os pontos.
“`python
[cole a função aqui]
“`Responda em lista numerada.”
Repare que o segundo prompt tem os quatro componentes: contexto (desenvolvedor sênior), instrução (sugerir até três melhorias, sem reescrever tudo), conteúdo (a função colada com delimitador) e formato (lista numerada). A diferença na qualidade da resposta é enorme, e não é mágica — é estrutura.
Os problemas que a estrutura não resolve sozinha
Mesmo com um prompt bem montado, você ainda enfrenta desafios reais:
- Prolixidade. LLM adora escrever demais. Se você não pedir resposta curta, ela vai te entregar um TCC.
- Sensibilidade ao comprimento. Prompt gigante não é prompt melhor. Se você exagera nos detalhes, o modelo pode ignorar partes importantes ou se perder. Clareza vence volume.
- Ambiguidade. Pedido vago gera resposta vaga — e às vezes gera alucinação, porque o modelo “preenche” a lacuna com algo que parece plausível mas não existe.
Nada disso é motivo para tratar prompt engineering como perda de tempo. É motivo para tratar como o que é: uma habilidade técnica, não um dom místico.
Prompt engineering virou “a profissão do futuro”? Não exatamente
Lá por 2024 rolou bastante hype em cima de “engenheiro de prompt” como cargo separado, com salário alto e tudo mais. Hoje isso parece menos uma profissão isolada e mais uma competência que qualquer dev precisa ter, do mesmo jeito que saber usar o Git ou escrever uma query SQL decente. Não é sobre ter um cargo com esse nome — é sobre saber pedir código, análise ou refatoração pra IA e efetivamente receber o que você precisa, sem depender de sorte.
Se você quer ver esse conteúdo em vídeo, com mais exemplos ao vivo de prompt bom e prompt ruim, tem um episódio inteiro no canal FortShield cobrindo isso, e a continuação entra em chain-of-thought prompting, redução de alucinação e segurança — assunto pra outro artigo aqui do blog.
