Interação de prompt é skill. Nunca aceite a primeira versão.

TL;DR

• Interação de prompt é método, não tentativa e erro — aceitar a primeira entrega é decidir sobre probabilidade; iterar com critério é decidir sobre comparação; a distinção aparece inteira no código que vai para produção.
• Rejeição é feedback estruturado, não impressão — cancelar uma entrega sem refinar é desperdiçar o ciclo; rejeitar com critério é alimentar a próxima interação de prompt com sinal de alta qualidade.
• Interação de prompt reduz escopo até caber no problema — afunilar progressivamente (autenticação → JWT → RS256 → refresh token com rotação) produz especificação executável, não generalização abstrata.
• Pedir alternativas antes de aceitar é regra — duas ou três variações com critérios diferentes separam decisão técnica de aceitação preguiçosa na interação de prompt.
• Metrificar a interação de prompt torna o ciclo visível — listar critério (10 pontos) e contar os atendidos por interação mostra se a interação converge ou gira em falso.

Rejeição é feedback estruturado, não impressão

A frase “isso tá errado, faz de novo” não é rejeição. É desistência disfarçada de interação de prompt. Rejeição com critério é sinal de alta qualidade que alimenta a próxima interação do ciclo prompt → entrega → revisão → refinamento. Rejeição sem critério é ruído.

A forma fixa da rejeição tem quatro partes: diagnóstico, defasagem, direção, abordagem. Em ordem.

• Diagnóstico — o que foi entregue (“a resposta tem 400 linhas”).
• Defasagem — o que está em falta (“precisa ter no máximo 50”).
• Direção — onde precisa chegar (“usar `map`/`filter` em vez de loops”).
• Abordagem — eixo que precisa mudar (“refatorar, não reescrever do zero”).

Exemplo ruim: “isso tá errado, faz de novo”.

Exemplo bom: “O código tem 400 linhas, precisa ter no máximo 50. Refatore para usar `map`/`filter` em vez de loops.”

A entrega ruim mostra o problema. A entrega boa treina a IA sobre o que o revisor entende por qualidade. Em sessões de code review assistido por LLM observadas em campo, prompts com rejeição estruturada produzem segunda interação com ganho de qualidade mensurável em uma ordem de grandeza superior a prompts com rejeição genérica. A rejeição é a alavanca. Sem alavanca, não há ciclo — há tentativa e erro.

Interação de prompt reduz escopo até caber no problema

Prompts genéricos produzem respostas genéricas. A forma mais direta de reverter é afunilar progressivamente: começar amplo, restringir a cada interação com base no que apareceu na revisão. A sequência abaixo, observada em projeto real, ilustra o padrão.

Interação	Prompt	Resultado
1	“Crie sistema de autenticação”	Solução ampla cobrindo OAuth, JWT, sessões, MFA
2	“Focado em apenas JWT, sem OAuth”	Implementação JWT isolada, ainda com HS256
3	“Só RS256, sem HS256”	JWT com chave assimétrica, sem rotação
4	“Incluir refresh token com rotação”	Solução completa, 80 linhas, testada

Cada interação restringiu o escopo com base na revisão da interação anterior. O resultado ao fim do ciclo não é a primeira tentativa mais ajustes. É uma solução calibrada em quatro voltas — cada volta descendente transforma generalização em especificidade. Quem tenta resolver o problema inteiro no primeiro prompt não está sendo ambicioso. Está adiando a decisão sobre o que importa.

A interação de prompt assim conduzida economiza refactor depois: a especificação afunilada chega no merge com o escopo certo, não com o escopo hipotético. O tempo gasto em interação de prompt com critério é menor que o tempo gasto depois desfeito em correção. Métrica empírica em projeto recente: 25% mais iterações de prompt no início, 60% menos correções pós-merge. Soma líquida: ciclo mais curto.

A regra operacional: a cada interação, acrescentar uma restrição, não uma abstração. Restrição é teste (“só RS256”). Abstração é fuga (“considere todos os casos”). Restrição converge. Abstração diverge.

Pedir alternativas antes de aceitar é regra, não exceção

Aceitar a primeira solução entregue por interação de prompt é decidir sobre probabilidade, não sobre comparação. Decisão técnica exige variação visível antes do critério de seleção. A prática: pedir duas ou três abordagens alternativas no mesmo prompt, cada uma com direção distinta.

Prompt com variação forçada: “Crie função que ordena array de inteiros em ordem decrescente. Abordagem A: quick-sort. Abordagem B: merge-sort. Abordagem C: heap-sort. Mostre as três com complexidade e trade-offs de memória em cada uma.”

A primeira resposta da IA, mesmo quando correta, raramente é a melhor entre as viáveis. Pedir alternativas força o modelo a ocupar o espaço de variação que seria ignorado em uma única entrega. O revisor compara as três, escolhe com critério, ou pede quarta com base no que apareceu nas três. Esse é o trabalho de interação — não “pedir de novo”, mas “comparar antes de aceitar”.

Aplicação prática em code review assistido por IA: pedir duas abordagens diferentes para refatoração de função crítica (uma estrutural, uma comportamental). A saída do revisor não é escolher a melhor; é dizer qual trade-off faz sentido no contexto. Quando o trade-off é explícito, o código escolhido carrega justificativa. Sem alternativas, não há justificativa; só há aceitação.

Rejeição pontual vence rejeição genérica

A rejeição genérica (“não gostei”, “tem algo estranho”, “quase”) gasta interação de prompt sem produzir sinal. A rejeição pontual produz refactor de alta qualidade porque aponta onde a entrega atual diverge da especificação e onde precisa chegar.

Formato canônico de rejeição pontual: “Seu código não atende porque: [1] performance é ruim, [2] usa biblioteca proibida, [3] não trata exception. Tente abordagem que use async/await, biblioteca X, e exception explícita por caminho.”

Cada item da rejeição é critério verificável. Critério verificável permite que a próxima interação de prompt seja convergente — o sinal vai para o mesmo lugar que falhou na entrega anterior. Critério genérico produz interação divergente: a próxima tentativa pode atacar qualquer ponto, todos, ou nenhum. Resultado: o ciclo gira em falso até que o dev reformula a rejeição em critério verificável, ou até aceitar por cansaço. Interação de prompt sem rejeição pontual é círculo, não ciclo.

Em revisão de prompt, rejeição pontual deve cobrir três eixos:

• Restrição — o que foi entregue viola restrição explícita da especificação (biblioteca, protocolo, versão).
• Qualidade — funciona, mas com custo operacional inaceitável (latência, memória, throughput).
• Comportamento — funciona em caso feliz, falha em edge cases (exceção não tratada, entrada inválida silenciada).

Sem os três eixos na rejeição, a próxima interação vai redescobrir o problema que a anterior já tinha resolvido parcialmente. É trabalho perdido que aparece como “parece que está voltando”.

Metrificar a interação torna o ciclo visível

A diferença entre aceitar por sorte e iterar com método aparece no que se consegue medir. Listar critério antes da primeira interação de prompt e contar quantos foram atendidos a cada volta torna o progresso visível — e torna circularidade visível também.

Exemplo operacional, observado em code review assistido por IA em ambiente de produção:

• Interação 1 — 10 pontos de critério definidos, 3 atendidos pela entrega inicial.
• Interação 2 — mesmos 10 pontos, 7 atendidos após rejeição pontual.
• Interação 3 — mesmos 10 pontos, 10 atendidos. Aprovação.

O que a métrica revela: o ganho marginal de cada interação cai conforme o número de atendidos sobe. Interação 1 → 2 rendeu 4 pontos. Interação 2 → 3 rendeu 3. Curva decrescente é sinal de convergência. Curva plana (0 pontos atendidos a mais) é sinal de vagueza na rejeição — o ciclo está girando, não convergindo.

Métrica que se aplica sem alteração entre times: 10 critérios mensuráveis, contagem binária por interação de prompt. Sem essa lista, o critério de “aceitação” vira opinião, e opinião muda entre iterações sem que se perceba. Com a lista, o critério é o mesmo na primeira e na quinta interação. É o que dá estabilidade ao ciclo.

Os números de um projeto recente, observado em code review assistido por IA, ajudam a calibrar expectativa: interação 1 entregou 3 de 10 pontos; interação 2 subiu para 7; interação 3 fechou em 10. Cada interação de prompt rendeu ganho marginal menor (4 e depois 3 pontos), o que é curva decrescente esperada em ciclo convergente. Se a próxima interação rendesse 0 pontos adicionais, o sinal seria que a rejeição virou vaga, e o próximo passo do dev seria reformulá-la em vez de pedir nova entrega.

Prompt matador é iterado, não encontrado

Prompt matador é iterado, não encontrado na primeira tentativa. A primeira resposta da IA carrega o escopo que o prompt pediu — o que aparece nessa resposta é o que o modelo entendeu do problema. O que não aparece é o que faltou. Interação de prompt é descobrir o que faltou no primeiro prompt, e ajustar o prompt para que a próxima entrega feche o que a anterior abriu.

A frase de fechamento vale repetir em voz alta: nunca aceitar primeira entrega de IA. Iterar pelo menos duas vezes com feedback estruturado. Qualidade melhora exponencialmente — não linear, exponencialmente — porque a segunda interação não é refinamento da primeira; é aplicação de critério sobre o que a primeira revelou. E o critério é o que transforma aceitação preguiçosa em decisão técnica.

A próxima sessão de desenvolvimento assistido por IA começa com a lista de critério, não com o primeiro prompt. Sem lista, não há o que medir. Sem medição, não há interação. Sem interação de prompt, há aceitação — e aceitação sem critério não é decisão; é probabilidade. Cinco práticas descritas, todas operacionais, todas aplicáveis na sessão de amanhã. A escolha entre aceita-e-publica e itera-com-critério não é técnica: é de método, e método se instala em semanas, não em uma tarde.

Leitura relacionada

• Interação com IA não é “até parecer certo”. É ciclo estruturado de refinamento — a versão macro deste post: ciclo de especificação → geração → revisão → refinamento como método, não como tentativa e erro.
• Vibe code com IA é desastre: como o desenvolvimento com IA exige rigor — diagnostica o padrão de aceitação preguiçosa que este post transforma em cinco práticas de interação com critério.
• Estrutura de prompt é diferença entre alucinar e acertar — mostra como a estrutura do primeiro prompt determina o que sobra para a interação refinar; prompt vago força interação a corrigir escopo, não qualidade.