A IA consegue gerar um MVP funcional em uma tarde. Isso costumava ser a parte difícil; não é mais, e continuar agindo como se fosse arruína seu roadmap sem você perceber.
O difícil agora é o critério: de tudo o que você poderia construir em uma tarde, o que de fato merece o tempo de engenharia de um sprint? Aprendi do jeito caro: joguei uma leva de protótipos gerados com IA direto nos sprints e metade empacou. Funcionavam. Só não importavam.
Então, antes de dar tempo de sprint a algo, passo três perguntas:
1. Alguém de fora do contexto consegue dizer o que aquilo resolve em uma frase?
Mostre a demo para um colega que não estava na sala. Se ele não conseguir enunciar o problema sem a sua narração, o escopo ainda não é real: é uma superfície convincente sobre um núcleo indefinido.
2. Existe uma métrica falseável escrita antes do sprint?
"As pessoas vão amar" é vibe, não métrica. "40% dos usuários de teste chegam à ação principal sem ajuda" é algo em que você pode errar — e é exatamente isso que a torna útil.
3. Qual é a suposição que, se for falsa, torna tudo inútil?
Nomeie-a e teste primeiro. A maioria dos MVPs com IA não morre pela engenharia difícil; morre por uma premissa que ninguém se deu ao trabalho de escrever.
Passou nas três, ganha tempo de sprint. Falhou em uma, volta pro prompt para outra rodada — e agora que gerar uma versão nova custa uma tarde em vez de um mês, isso é genuinamente barato.
Acabei encadeando isso num fluxo repetível (prompt → MVP → portão de validação) para não rediscutir a cada planejamento. Se quiser ver como está montado, documento em https://nxcode.io.
As ferramentas baratearam o construir. O escasso agora é decidir o que vale a pena construir — é aí que prefiro gastar o critério.
Que filtros vocês usam antes de um protótipo com IA ganhar horas reais de engenharia?
Top comments (0)