Product Thinking · Articles · 2026

IA & Produto

Como o vibecoding mudou a forma como faço Product Management

Como construí uma plataforma de jogos sozinho em vibecoding, e o que esse processo revelou sobre decisão de produto, arquitetura e aprendizado rápido.

Afrânio Cavalcante

Afrânio Cavalcante

Product Manager

Junho de 2026

8 min de leitura

Existe uma frase que ouvi muitas vezes ao longo da carreira: "eu testaria essa ideia se tivesse um desenvolvedor disponível". Durante muito tempo ela fez sentido para mim. A velocidade de aprendizado de um PM dependia da velocidade de um time de engenharia. Antes de validar uma hipótese, era preciso convencer pessoas, disputar prioridade, escrever especificação e esperar um ciclo inteiro de desenvolvimento para só então descobrir se a ideia valia alguma coisa.

Construir o Palavria mudou essa percepção. O Palavria é uma plataforma de jogos de palavras que desenvolvi praticamente sozinho, em vibecoding: descrevendo o que eu queria construir e iterando com a IA até o produto existir, sem escrever a maior parte do código na mão. Não sou engenheiro de software, sou Product Manager. O que a IA me deu não foi a capacidade de virar desenvolvedor da noite para o dia, e sim autonomia para transformar hipóteses em produto funcionando.

Eu achava que o grande aprendizado seria sobre desenvolvimento.

Descobri que desenvolvimento deixou de ser a parte difícil.

Construir já não é o gargalo

Em poucos dias existia um caça-palavras funcionando. Pouco tempo depois havia um modo de campanha passando por todas as capitais brasileiras, um desafio diário, rankings, sistema de moedas, sequência de dias jogados, autenticação, sincronização entre dispositivos e multiplayer. A implementação andou numa velocidade que eu nunca tinha visto de perto.

Tela de modos de jogo do Palavria: Sprint, Contra o Tempo, Infinito, Viagens e multiplayer
Os modos de jogo do Palavria: quatro mecânicas solo e o multiplayer em tempo real.

Só que nenhuma dessas funcionalidades respondeu as perguntas que realmente importavam. O usuário deveria criar uma conta antes de jogar? Como um caça-palavras se diferencia no meio de centenas de outros? Quando vale a pena adicionar uma mecânica nova e quando ela só aumenta a complexidade? Como impedir que algo criado rápido vire dívida técnica permanente?

Essas perguntas continuaram sendo de produto, e a IA não respondeu nenhuma delas.

A melhor decisão do produto teve poucas linhas de código

Uma das escolhas mais importantes foi deixar qualquer pessoa jogar sem criar conta. Seria fácil exigir cadastro logo na primeira tela, afinal todo produto quer usuários cadastrados. Mas a pergunta que eu precisava responder não era quando eu conseguiria capturar o usuário. Era quando ele teria percebido valor suficiente para aceitar essa fricção.

A resposta acabou sendo depois da primeira vitória. O convite para criar conta aparece só quando o jogador já experimentou o produto e terminou uma partida. Na prática, o cadastro deixou de ser uma barreira de entrada e virou uma ferramenta de retenção.

Tela de desafio concluído do Palavria com convite para criar conta após a vitória
A decisão na tela: o convite para criar conta só aparece depois da vitória.

A implementação ocupou poucas linhas. A decisão levou muito mais tempo do que ela, e esse padrão se repetiu durante o projeto inteiro.

A IA escreve código, mas não faz trade-offs

Outro exemplo apareceu quando comecei a revisar a segurança do backend, construído em Supabase. Na fase inicial, algumas decisões que deveriam estar no servidor ficaram no cliente simplesmente porque era mais rápido iterar assim. O saldo de moedas era uma delas. Tecnicamente funcionava, mas bastava abrir o DevTools do navegador para alterar o valor.

A solução não foi escrever mais código. Foi redefinir quem tinha autoridade sobre aquele dado. Em vez de o cliente informar "meu saldo agora é 500 moedas", ele passou a informar apenas "ganhei 20 moedas". A validação migrou para uma função no próprio banco, uma RPC protegida por regras de RLS, que calcula o saldo verdadeiro e rejeita qualquer valor fora do esperado.

A IA ajudou a implementar a mudança, mas ela não decidiu que aquele era o modelo correto. Essa decisão exigiu entender risco, fraude, experiência do usuário e custo de manutenção. Ou seja, exigiu produto.

O código ficou pronto antes da arquitetura

Um aprendizado curioso foi perceber que a velocidade da IA cria um problema novo. Antes a implementação era lenta. Agora ela acontece tão rápido que a arquitetura precisa correr atrás.

O Palavria começou simples demais. Conforme as funcionalidades foram surgindo, precisei criar um pipeline de build que ofusca o JavaScript com Terser antes de publicar, configurar políticas de segurança, revisar permissões no banco, documentar dívidas técnicas e repensar a sincronização de dados entre dispositivos. Nada disso existia porque eu queria uma arquitetura sofisticada. Existia porque um produto que começa a ser usado inevitavelmente encontra problemas que não aparecem no primeiro protótipo.

A IA acelerou o caminho até esses problemas. Ela não os eliminou.

Aprender sem pedir permissão

Talvez essa tenha sido a maior mudança de todas. Antes, validar uma ideia dependia de convencer outras pessoas de que ela merecia ser construída. Hoje consigo construir primeiro e aprender depois. Se quero testar um novo onboarding, eu testo. Se quero experimentar uma mecânica de retenção diferente, eu implemento. Se quero descobrir se uma funcionalidade gera valor de verdade, ela pode estar em produção muito antes do que seria possível num fluxo tradicional.

Isso mudou a forma como penso discovery. Entrevistas, pesquisa e análise de dados continuam importando tanto quanto antes. A diferença é que agora consigo colocar hipóteses diante de usuários reais com uma velocidade que simplesmente não existia alguns anos atrás.

O Palavria nunca foi só um caça-palavras

Olhando para trás, o produto acabou virando um laboratório. Nele experimentei onboarding, retenção, economia virtual, sincronização entre dispositivos, autenticação, rankings, multiplayer, segurança, deploy e iteração contínua. A IA escreveu boa parte do código, mas cada decisão sobre o que construir, quando construir, por que construir e quais compromissos aceitar continuou sendo minha.

E talvez seja essa a habilidade que ferramentas de IA realmente amplificam. Não a capacidade de escrever software, mas a capacidade de aprender mais rápido. Para mim, esse é o maior impacto do vibecoding sobre Product Management: ele não substituiu o trabalho de produto, ele eliminou a maior desculpa que existia para não testar uma hipótese.

O Palavria está no ar em palavria.online — e continua sendo meu laboratório.

Vibecoding IA & Produto Aprendizado Product Management