Cinco decisões no prompt. Aqui está como tomar cada uma.

TL;DR

A qualidade de um prompt para IA generativa raramente é o resultado de talento. É o resultado das cinco decisões no prompt — decisões deliberadas, tomadas antes do primeiro token ser enviado. As cinco decisões no prompt que separam código preciso de tentativa e erro são especificidade, tamanho, exemplos, tom e iteração. Quem toma as cinco recebe código preciso. Quem ignora qualquer uma recebe código que parece responder, mas que raramente resolve.

• Decisão 1: Especificidade vs Flexibilidade — restrição explícita no que precisa acontecer, abertura no como. “Resultado precisa ser X. Precisamos evitar Y. Sua abordagem fica a seu critério” vence tanto “faça assim” quanto “seja criativo”.
• Decisão 2: Tamanho do prompt — sweet spot de 200 a 500 palavras para a maioria das tarefas. Abaixo de 100 produz ambiguidade por omissão; acima de 1000 dilui o foco. Prompt que passa de 1000 palavras é candidato a ser dividido em dois ou três.
• Decisão 3: Nível de detalhe em exemplos — dois a três exemplos cobrem caso normal, caso extremo e erro a evitar. Zero exemplo deixa a IA improvisar; um exemplo deixa margem para interpretação errada; quatro ou mais exemplos é overhead.
• Decisão 4: Tom e relação com a IA — tom de colega (“considere…”, “sua leitura é…”) abre espaço para criatividade; tom de máquina (“execute…”, “produza…”) fecha espaço para ambiguidade. A escolha depende do que se quer.
• Decisão 5: Iteração esperada — declarar a expectativa muda o prompt. “Quero uma rodada, código de produção” exige especificação máxima. “Quero explorar, código de protótipo” abre espaço para variação. Honestidade aqui evita iterações desnecessárias.

Decisão 1: Especificidade vs Flexibilidade no prompt

A primeira das cinco decisões no prompt é o equilíbrio entre restrição e abertura. O erro comum é tratar especificidade e flexibilidade como opostos binários: ou se dá instrução rígida (“use esta biblioteca, este padrão, este formato”) ou se abre para a IA decidir tudo (“seja criativo, faça o melhor que puder”). Os dois extremos produzem resultado ruim. O sweet spot é específico em restrição, flexível em implementação.

Restrição é o que precisa acontecer. Implementação é como isso vai ser feito. O prompt bem escrito define restrição de forma explícita e deixa a abordagem livre.

Ruim: “Faça um sistema de autenticação com JWT usando RS256 e refresh token com rotação, biblioteca X, framework Y, e cobertura de testes acima de 80%”. A IA não tem espaço para propor alternativa; se a abordagem canônica não funcionar, ela não tem como adaptar.

Pior: “Faça um sistema de autenticação”. A IA tem 20 decisões de escopo a tomar, e cada uma pode divergir da expectativa do desenvolvedor. O resultado é alucinação de requisitos: a IA entrega algo, mas algo que ninguém pediu.

Bom: “Resultado precisa ser: sistema de autenticação stateless com refresh token rotativo. Precisamos evitar: dependência de banco de dados para validação de sessão, vendor lock-in de fornecedor específico. Sua abordagem fica a seu critério”. A IA tem restrição clara (stateless, refresh rotativo) e abertura de implementação (biblioteca, algoritmo, estrutura).

A frase “sua abordagem fica a seu critério” não é redundância: é a sinalização explícita de que o controle de qualidade é por restrição, não por instrução de método. Em sessões de code review observadas em produção, prompts com restrição explícita e abertura de método — primeira das cinco decisões no prompt bem aplicada — produzem três vezes mais propostas de abordagem do que prompts com instrução rígida. Tomar a primeira das cinco decisões no prompt antes de escrever a próxima linha do prompt evita reformulação posterior. O ganho não é cosmético: a IA tem mais espaço para surpreender positivamente em domínio técnico onde o modelo é mais forte que o desenvolvedor.

Decisão 2: Tamanho do prompt de IA

A segunda das cinco decisões no prompt é o tamanho do prompt em si. A intuição de que “mais detalhe é melhor” cai em dois modos de falha opostos: prompt curto demais produz ambiguidade por omissão; prompt longo demais dilui o foco do que importa.

A faixa operacional de sweet spot, observada em uso de IA generativa para tarefas de desenvolvimento, é de 200 a 500 palavras para a maioria dos prompts. Abaixo de 100 palavras, a chance de a IA interpretar errado a restrição central sobe. Acima de 1000 palavras, a chance de a IA ignorar ou subvalorizar uma das restrições sobe. A curva de utilidade por comprimento não é monotônica: cresce até certo ponto, depois decresce.

Ruim: prompt de 30 palavras. “Refatore esta função para melhor performance. Mantenha o comportamento. Use TypeScript.” Três restrições curtas, sem contexto de critério, sem exemplo de performance-alvo. A IA escolhe o que “performance” significa, e a escolha frequentemente diverge do esperado.

Pior: prompt de 1500 palavras. Dezenas de restrições misturadas com contexto histórico, exemplos colaterais, e priorização implícita. A IA precisa decidir quais restrições pesam mais, e essa decisão não é declarada.

Bom: prompt de 350 palavras. Declaração de objetivo (50 palavras), lista de restrições explícitas (100 palavras), critério de aceitação (100 palavras), contexto relevante (100 palavras). Estrutura visível: a IA sabe onde olhar para cada parte do problema.

A prática operacional que emerge: quando o prompt passa de 1000 palavras, dividir em dois ou três prompts. Cada um com escopo delimitado. A divisão é uma das formas mais subestimadas de aumentar a qualidade: o que era um pedido vago se torna três pedidos específicos, e a IA consegue tratar cada um com o nível de detalhe que merece. Aplicar a segunda das cinco decisões no prompt em iteração, não apenas na escrita inicial, é o que permite escalar a produção sem perder qualidade.

A divisão também é o que permite iteração: se o segundo prompt falha, o desenvolvedor sabe que o problema está naquele escopo. Em prompt monolítico de 1500 palavras, falha é difusa, e o ciclo de iteração se arrasta sem diagnóstico.

Decisão 3: Nível de detalhe em exemplos

A terceira das cinco decisões no prompt é quantos e quais exemplos incluir. O exemplo é o dispositivo de transmissão de expectativa que mais alto sinal carrega: a IA infere o critério do que o desenvolvedor considera correto ou errado a partir do que está no exemplo, mais até do que do que está declarado.

O padrão observado em uso de produção: zero exemplo deixa a IA improvisar o critério. Um exemplo ancora a IA em uma direção, mas deixa margem para interpretação divergente. Dois ou três exemplos cobrem os três casos críticos: caso normal, caso extremo, erro a evitar. Quatro ou mais é overhead, e o ganho marginal cai.

Ruim: zero exemplo. “Escreva função que valide CPF”. A IA entrega uma implementação qualquer de validação de CPF, mas o critério de “validação” (dígitos verificadores? máscara? formato? rejeição de CPF conhecido inválido?) fica por conta do modelo.

Médio: um exemplo. “Valide CPF. Exemplo: ‘529.982.247-25’ é válido”. A IA ancora em um caso, mas ignora casos extremos (CPF com máscara, CPF repetido, CPF de dígito zero) e o erro a evitar.

Bom: três exemplos. “Valide CPF. Casos válidos: ‘529.982.247-25’, ‘52998224725’. Casos inválidos: ‘111.111.111-11’ (dígitos repetidos), ‘123.456.789-00’ (dígito verificador errado). A função deve rejeitar inválidos e aceitar válidos com ou sem máscara”. A IA tem o critério completo: o que aceitar, o que rejeitar, e qual a forma esperada de entrada.

A escolha de quais exemplos incluir é a decisão editorial. A regra operacional: o caso normal, o caso extremo, e o erro frequente. Cobrir os três é o que faz o exemplo funcionar como especificação executável. Cobrir só o caso normal é o que faz o exemplo virar apenas confirmação de escopo — útil, mas incompleto. Em revisão de código assistido por IA, a terceira das cinco decisões no prompt — exemplos calibrados — converte resposta tentativa em resposta determinística.

Decisão 4: Tom e relação no prompt de IA

A quarta das cinco decisões no prompt é o tom da relação que o prompt estabelece com a IA. A escolha entre tratar a IA como máquina de execução ou como colega de trabalho afeta diretamente o tipo de resposta que o modelo entrega.

A observação em sessões de uso de produção é direta: prompts que tratam a IA como máquina (“execute”, “produza”, “retorne”) produzem resposta literal e rápida, com pouca inferência. Prompts que tratam a IA como colega (“considere”, “sua leitura é”, “como você avaliaria”) produzem resposta mais elaborada, com mais contexto, e mais espaço para a IA sinalizar incerteza.

Ruim: tom inconsistente. Misturar “execute esta função” com “qual seria sua leitura?”. A IA não sabe qual modo operar, e a resposta fica em zona intermediária: nem literal, nem reflexiva.

Bom: tom consistente com o objetivo. Se o objetivo é criatividade, tom de colega — “considere as três abordagens a seguir e proponha uma quarta”. Se o objetivo é precisão, tom de máquina — “execute a consulta SQL abaixo e retorne o resultado em JSON com schema X”.

A frase “sua abordagem fica a seu critério” da Decisão 1 é parte do tom. A inclusão explícita de espaço para decisão da IA é o que diferencia prompt prescritivo de prompt que abre espaço para surpresa. Para tarefas de código em produção, a abertura de método é geralmente um ganho. Para tarefas de infraestrutura crítica, a abertura pode ser um risco. O tom diz à IA em qual modo ela está operando.

A forma prática de calibrar: revisar os prompts que produziram os melhores resultados no último mês, e identificar o tom comum. Em uso de produção observado, a maioria dos prompts de alta qualidade tem tom de colega, porque a IA moderna performa melhor quando tem espaço para contribuir. Mas a escolha depende da criticidade da tarefa: deploy em produção pede precisão, prototipação pede criatividade.

Decisão 5: Iteração esperada no prompt

A quinta das cinco decisões no prompt é a expectativa de iteração. Declarar, no próprio prompt, quantas rodadas se espera — uma rodada para entrega final, ou três a cinco rodadas para refinamento — muda o que se pede na primeira iteração.

O efeito prático é direto: se a expectativa é uma rodada só, o desenvolvedor precisa especificar muito, porque a primeira entrega tem que estar próxima do aceitável. Se a expectativa é três a cinco rodadas, o prompt pode começar mais aberto, com critério de aceite, e a IA pode errar parcialmente na primeira iteração, com a iteração refinando.

Ruim: expectativa não declarada. O desenvolvedor escreve prompt, recebe primeira entrega, e decide se aceita ou itera com base no feeling do momento. Sem declaração prévia, o critério de aceite muda entre iterações, e a IA não consegue convergir.

Pior: expectativa falsa. “Quero a melhor versão possível” sugere iteração longa, mas o prompt é curto. A IA entrega a primeira versão rápida, que não é “a melhor possível”, e o desenvolvedor itera com critério que não estava declarado.

Bom: expectativa explícita. “Quero uma rodada, código de produção. Especificação: X, Y, Z. Se algum desses não puder ser atendido, sinalize na resposta.” Ou: “Quero iterar. Primeira rodada: traga três abordagens alternativas, sem implementação. Segunda rodada: implemente a escolhida. Terceira rodada: refine até cobertura de testes acima de 80%.”

A declaração de iteração esperada é o que evita a armadilha mais comum: prompt curto pedindo tudo na primeira iteração, e a IA entregando um rascunho que precisa de três voltas para chegar ao aceitável. Em uso de produção, a primeira iteração tem rendimento médio de 30 a 50% do critério de aceite declarado. Planejar para isso muda o prompt. As cinco decisões no prompt se aplicam em cada iteração: cada nova rodada é um novo prompt, e cada nova rodada merece as cinco decisões no prompt declaradas de novo.

A regra operacional: se a expectativa é uma rodada, declarar a especificação com 5 a 10 critérios verificáveis. Se a expectativa é iteração, declarar o critério de aceite e o número de voltas, e abrir espaço para que a primeira iteração seja exploratória. As duas abordagens funcionam; misturá-las é o que produz ciclo sem convergência. A quinta das cinco decisões no prompt é o que separa ciclo convergente de tentativa e erro disfarçado.

Cinco decisões no prompt: o framework operacional

As cinco decisões no prompt — especificidade, tamanho, exemplos, tom, iteração — formam o framework operacional para escrever prompt de IA com critério. Cada uma das cinco decisões no prompt é independente, mas a soma é o que produz resultado superior: especificidade sem tamanho certo é prompt longo e vago; tamanho sem exemplos é prompt longo e abstrato; exemplos sem tom é prompt correto e frio; tom sem iteração é prompt amigável e único; iteração sem as outras quatro é ciclo sem convergência. Aplicar as cinco decisões no prompt de forma integrada é o que transforma tentativa e erro em método reproduzível.

A próxima sessão de desenvolvimento assistido por IA começa com as cinco decisões no prompt declaradas antes do primeiro envio. Sem declaração, o prompt é tentativa e erro: a IA entrega algo, o desenvolvedor reformula, e a iteração consome tempo que poderia ter sido economizado com cinco minutos de especificação. Cinco decisões no prompt custam cinco minutos. Cinco decisões evitadas custam cinco horas de iteração. A escolha é operacional, não filosófica.

A frase final vale repetir: prompt matador é resultado das cinco decisões no prompt — especificidade, tamanho, exemplos, tom e iteração. Quem toma as cinco recebe código preciso. Quem ignora qualquer uma recebe código que parece responder, mas que raramente resolve. As cinco decisões no prompt se aplicam do CRUD diário ao refactor crítico.

Leitura relacionada

• Seu prompt é vago porque você não sabe o que quer. Aqui está como saber. — diagnóstico do problema que a Decisão 1 (especificidade) resolve: prompt vago não é falha de IA, é falha de especificação do que se quer.
• Estrutura de prompt é diferença entre alucinar e acertar — aprofunda a Decisão 2 (tamanho) e a Decisão 3 (exemplos) com a anatomia completa de um prompt bem estruturado.
• Iteração de prompt é skill. Nunca aceite a primeira versão. — aprofunda a Decisão 5 (iteração) com as cinco práticas de ciclo de qualidade que transformam aceitação preguiçosa em decisão técnica.