Os prompts que uso pra IA destruir minha ideia antes de eu codar

A maioria dos devs usa IA pra acelerar código. Pede componente. Pede função. Pede correção de bug. Pede refactor.

Ajuda, mas é o uso mais básico.

O maior ganho que eu tive com IA não foi escrever mais código. Foi evitar escrever código desnecessário.

Antes de construir uma feature, eu mando a IA atacar a minha ideia. Não escrever código. Atacar. Buscar furo. Apontar onde tô sendo otimista.

IA boa não é autocomplete. É segundo cérebro que revisa decisão antes dela virar código.

Os 5 ângulos de ataque

Antes de toda feature nova, mando 5 prompts. Cada um ataca um ângulo diferente:

1. A solução resolve mesmo? — ou só parece que resolve?
2. Existe forma 10x mais simples? — talvez nem precise codar.
3. Qual risco técnico eu ignoro? — o que vai me morder em 3 meses?
4. A regra faz sentido pro cliente? — ou é otimização de developer?
5. O fluxo confunde? — quem nunca viu vai entender?

Cada um é um prompt curto, com [COLCHETES] pra substituir pelo seu contexto.

Prompt 1: a solução resolve mesmo o problema?

O ataque mais importante. Antes de qualquer coisa.

Quero construir [FEATURE] pra resolver [PROBLEMA] do [PERSONA].

Pergunta direta: isso resolve o problema de verdade, ou só parece que resolve?

Liste 3 cenários em que a feature falha em entregar a solução real. Pra cada cenário, mostre o que o usuário ainda vai precisar fazer manualmente DEPOIS dessa feature.

Tom: direto, sem suavizar. Vá além do básico.

Se a IA listar 3 cenários onde o usuário ainda faz tudo manual depois — você não tá resolvendo o problema. Tá só movendo o problema.

Prompt 2: existe uma forma 10x mais simples?

Talvez você não precise codar nada. Talvez Tally, Notion ou planilha resolva.

Vou construir [FEATURE] usando [STACK/ABORDAGEM].

Existe uma forma 10x mais simples de resolver o mesmo problema?

Compare a minha abordagem com 3 alternativas mais simples. Aceita comparar com no-code (Tally, Airtable, Notion, Zapier) se fizer sentido.

Pra cada alternativa, mostre:
- Tempo estimado de implementação
- Custo mensal (se tiver)
- Qual ponto fraco eu aceito ao escolher essa rota

Vá além do óbvio "use planilha".

50% das vezes a resposta dispensa metade do código que eu ia escrever.

Prompt 3: qual risco técnico eu tô ignorando?

O que parece OK agora e vai virar problema em 3-6 meses.

Plano técnico: [FEATURE DESCRITA EM 3-5 LINHAS] usando [STACK].

Qual risco técnico eu tô ignorando agora que vai me morder em 3 meses?

Liste em ordem de gravidade:
1) Decisões de dados/schema difíceis de reverter depois
2) Acoplamentos que vão travar refatoração futura
3) Coisas que parecem OK em dev e quebram em produção (concorrência, scale, edge cases reais, falhas de rede)

Pra cada item: o que muda agora pra evitar o risco. Sem teoria — me dê a ação concreta.

Esse aqui salva projeto. A IA vê os "happy paths" que eu romantizei.

Prompt 4: a regra faz sentido pro cliente real?

Toda feature tem uma regra de negócio. Ela tá ali pra ajudar — ou pra te dar trabalho?

Regra de negócio que vou implementar: [REGRA EM TEXTO CORRIDO, INCLUINDO EXCEÇÕES].

Contexto: [QUEM USA, QUE PROBLEMA RESOLVE, FREQUÊNCIA DE USO].

Pergunta: essa regra faz sentido pro cliente real, ou é otimização de developer/medo de bug?

Liste 3 situações reais em que a regra TRAVA o cliente em vez de ajudar. Sugira a versão mais flexível da regra que ainda protege o que precisa.

Foco no caso real, não no edge case raro.

A regra existe pra proteger ou pra impedir? Diferença que define se vira UX boa ou UX péssima.

Prompt 5: o fluxo vai confundir quem nunca viu o produto?

A maldição do dev: tudo faz sentido pra você porque você construiu. Cliente novo não tem esse contexto.

Fluxo que vou implementar pra [TAREFA]:

Passo 1: [DESCRIÇÃO]
Passo 2: [DESCRIÇÃO]
Passo 3: [DESCRIÇÃO]
(adicione todos)

Persona: [QUEM USA E COM QUAL FAMILIARIDADE].

Pergunta: quem nunca usou o produto vai entender esse fluxo na primeira tentativa?

Pra cada passo, identifique:
1) A pergunta que o usuário VAI ter naquele momento
2) Se a resposta dessa pergunta tá visível na tela
3) Se não estiver, o que falta colocar

Não suavize. Aponte cada confusão potencial.

A IA não conhece o produto. Por isso ela vê o que o dev não vê mais.

Como uso na prática

Não rodo os 5 toda vez. Critério:

• Sempre rodo 1 e 2 — solução resolve mesmo + tem jeito mais simples. Custa 5 minutos e poupa semanas.
• 3 entra quando a feature mexe em dado importante — migração, integração de pagamento, autenticação, anything que envolve "se quebrar, ferra".
• 4 entra quando vou impor restrição — limite de uso, regra de quem pode ou não, validação de entrada.
• 5 entra em fluxo novo de UX — onboarding, wizard, qualquer coisa com mais de 2 passos.

Fechamento

IA acelera quem sabe usar IA. E saber usar IA não é só pedir código — é usar como sparring antes de gastar o tempo certo no que importa.

Se quer o pack completo com mais 7 prompts que uso (revisão pós-implementação, planejamento de migração, escrita de testes, redação de release notes, escolha de stack, decisão build-vs-buy, análise de bug em produção), comenta DESTRUIR no meu Instagram que eu te mando no direct.