Por muito tempo, uma ideia simples de software virava uma lista enorme antes de poder ser testada: aprender a programar, configurar o ambiente, criar banco de dados, backend, frontend, deploy, autenticação, APIs. Muita gente desistia antes de mostrar qualquer coisa para um usuário.

Isso mudou. Hoje dá para explicar uma ideia a uma IA e, em poucas horas, ter uma tela, um formulário, um banco de dados e alguma integração funcionando. Às vezes, até um produto inteiro.

Eu acho isso incrível. Mas vale separar duas coisas que costumam aparecer misturadas na conversa sobre vibe coding:

Ficou mais fácil construir software. Não ficou mais fácil construir um bom produto.

Você não precisa ser um grande programador para fazer algo útil. Precisa, porém, aprender a pensar como alguém que constrói produto. Essa diferença separa um negócio de uma coleção de projetos bonitos que ninguém abre depois da demonstração.

O código deixou de ser a maior barreira

Passei boa parte da carreira trabalhando com tecnologia. Antes, uma ideia pequena podia levar dias ou semanas até ficar pronta para um teste real.

Hoje posso pedir algo como:

Preciso de uma aplicação que receba leads, guarde contatos, permita mudar o estágio de uma oportunidade e mostre as conversões em um dashboard.

A IA ajuda a definir uma arquitetura, criar tabelas, montar a interface, escrever APIs, gerar migrations, investigar erros e preparar o deploy. É muita coisa.

Mas ela não responde à pergunta que vem antes de todas as outras:

Por que alguém usaria isso?

Ela constrói aquilo que você pediu, inclusive quando ninguém precisa daquilo. A velocidade só torna esse erro mais barato de cometer.

Vibe coding não é apertar um botão e ganhar um SaaS

Às vezes a promessa implícita parece ser esta:

tenha uma ideia
↓
escreva um prompt
↓
a IA cria o sistema
↓
publique
↓
ganhe dinheiro

Seria ótimo. Só que a IA reduziu o custo de execução; ela não escolhe o problema, não entende o cliente por osmose nem cria distribuição para você. Ainda existe posicionamento, experiência de uso, modelo de negócio, suporte e validação.

E existe uma parte bem menos glamourosa: demanda não aparece porque o software ficou pronto.

O erro de começar pela ideia

Alguém pensa: “seria legal criar um sistema para academias”. Abre a IA e começa a pedir cadastro de alunos, planos, financeiro, relatórios e integrações. Três semanas depois surge a pergunta que deveria ter vindo no início: como eu vendo isso?

Academias já usam software. Algumas usam vários. Então vale perguntar: qual problema específico elas têm? O que ainda é feito na mão? Onde se perde dinheiro? Quem vai decidir a compra? Quanto custa continuar como está?

Nenhuma dessas perguntas é sobre React, Supabase ou Python. São perguntas de produto.

Pense no problema antes do software

Antes de abrir o editor, eu gosto de perguntar:

O que essa pessoa faz hoje sem o meu software?

Imagine uma clínica que recebe dezenas de contatos pelo WhatsApp. A recepcionista conversa com eles; alguns agendam, outros somem. Depois da primeira conversa, ninguém acompanha uma parte desses leads.

“A clínica precisa de um CRM” já é uma solução. O problema pode ser mais simples: pessoas interessadas estão sendo esquecidas.

Talvez a resposta seja um CRM. Talvez seja uma automação, uma planilha bem feita ou um fluxo dentro da ferramenta que a clínica já usa. Talvez não haja motivo para criar software novo.

Pensar como produto é segurar a vontade de construir até entender o que está acontecendo.

Uma transformação clara

Software útil muda alguma situação concreta.

ANTES
↓
PROBLEMA
↓
SOLUÇÃO
↓
DEPOIS

“Vou criar um dashboard com IA” não diz muita coisa. Já “o gestor abre quatro ferramentas para saber quantos leads viraram vendas; quero reunir isso em uma tela” dá uma direção.

O mesmo vale para agentes. Em vez de “quero criar um agente de IA”, tente: “depois das 18h, a empresa deixa mensagens sem resposta; quero que todo contato novo receba um atendimento inicial”. O software deixa de ser a ideia e vira uma possível resposta.

Comece pequeno o suficiente para terminar

Com IA, pedir mais uma funcionalidade ficou fácil demais. Você começa com uma agenda e logo entram pagamentos, WhatsApp, dashboard, aplicativo, IA, afiliados e multiempresa. Em três dias nasceu um Salesforce que não tem usuário nenhum.

Uma pergunta mais útil é:

Qual é a menor versão que resolve o problema principal?

Não a menor versão tecnicamente possível. A menor versão útil.

Para acompanhar oportunidades esquecidas no WhatsApp, um MVP pode ter só quatro coisas:

cadastrar o contato;
definir o estágio;
registrar a próxima ação;
avisar quando o follow-up venceu.

Se isso funcionar com pessoas reais, você aprende o que falta. Aí sim vale ampliar.

O usuário quer o resultado, não o seu software

Ninguém acorda querendo testar um SaaS novo. A clínica quer mais pacientes comparecendo. O corretor quer vender. O barbeiro quer uma agenda menos caótica. O gestor quer entender os números sem caçar planilhas.

Seu software é só o caminho até esse resultado. Quando isso fica claro, funcionalidades deixam de ser troféus e passam a ser escolhas.

Escreva o problema antes do prompt

Antes de pedir para uma IA construir algo, preencha isto:

USUÁRIO:
Quem vai usar?

PROBLEMA:
O que acontece hoje que é ruim?

PROCESSO ATUAL:
Como essa pessoa resolve isso hoje?

IMPACTO:
O que ela perde por causa desse problema?

RESULTADO:
O que deveria acontecer depois?

MVP:
Qual é a menor solução capaz de gerar esse resultado?

Com isso, o pedido muda. Em vez de “crie um sistema de vendas completo”, você pode dizer:

Estou criando uma ferramenta para pequenas clínicas que recebem leads pelo WhatsApp e perdem oportunidades por falta de follow-up. A primeira versão precisa cadastrar uma oportunidade, mover entre cinco etapas e definir a próxima data de contato.

A IA trabalha melhor porque você já fez a parte difícil: organizou o problema.

A habilidade que ganhou valor

Saber sintaxe ainda ajuda. Entender loops, queries e frameworks dá repertório e torna o trabalho com IA bem melhor. Mas uma habilidade ficou ainda mais valiosa: decompor um problema.

“Quero um sistema para imobiliária” precisa virar perguntas concretas: quem usa, qual fluxo existe hoje, quais dados entram, qual regra importa, o que pode dar errado e o que cabe na primeira versão.

É assim que você orienta uma IA. Também é o trabalho que bons desenvolvedores, arquitetos, product managers e empreendedores já faziam antes dela. A execução apenas ficou mais barata.

“Mas eu não sei programar. Posso construir?”

Pode. Para uma ferramenta interna, um protótipo, uma landing page, uma automação ou um micro SaaS simples, a IA leva muita gente bem longe.

O cuidado aumenta quando entram dinheiro, dados médicos, informações sensíveis, segurança, alta escala ou infraestrutura crítica. Vibe coding não é licença para ignorar engenharia. É uma forma de fazer mais engenharia com ajuda da IA.

Também vale aprender a perceber quando ela errou. IA produz código incorreto, complica solução simples, duplica lógica, ignora casos de borda e pode criar vulnerabilidades. Se tudo é aceito no automático, cedo ou tarde aparece aquele sistema que “funciona”, mas ninguém entende por quê. Até deixar de funcionar.

Não é preciso decorar tudo, mas eu aprenderia o básico de frontend e backend, banco de dados, API, autenticação, HTTP, variáveis de ambiente, logs, Git, deploy e segurança. Não para disputar com a IA. Para conseguir conduzi-la.

A oportunidade está em quem conhece o problema

Não acho que o objetivo seja transformar todo mundo em desenvolvedor tradicional. A parte interessante é outra: quem conhece profundamente um setor agora consegue testar soluções sem depender, desde o primeiro dia, de um sócio técnico, uma equipe ou investimento.

Uma pessoa que trabalhou dez anos em uma transportadora conhece dores que alguém de fora talvez leve meses para enxergar. Ela pode prototipar, mostrar para colegas, colocar cinco clientes para usar e só então decidir se aquilo merece crescer. Essa sequência é bem mais saudável do que passar meses construindo no escuro.

O gargalo agora é escolher o que construir

Tecnologia, infraestrutura e programação ficaram mais baratas. Construir ficou mais rápido.

O problema não é só saber construir. É saber o que vale a pena construir.

Você pode criar software sem fim. Pouco dele resolve um problema relevante; menos ainda resolve algo pelo qual alguém paga e chega até essas pessoas. É aí que produto, marketing, vendas e tecnologia se encontram.

Um exercício para o próximo projeto

Quando surgir uma ideia, não abra o Cursor, Codex, Claude ou ChatGPT de imediato. Pegue uma folha e responda:

Quem tem esse problema?
Qual é o problema?
Como ele é resolvido hoje?
Por que a solução atual é ruim?
Quanto custa continuar desse jeito?
Que resultado minha solução entrega?
Qual versão mínima prova isso?
Como vou colocá-la na mão de cinco pessoas reais?

Depois, construa. Você provavelmente vai escrever menos código e aumenta bastante a chance de fazer algo que alguém queira usar.

O que significa saber construir agora

Antes, boa parte do valor estava em transformar uma especificação em código. Agora, uma parcela maior está em transformar um problema confuso em uma solução clara.

A IA pode escrever código, desenhar uma interface, sugerir arquitetura e encontrar bugs. Alguém ainda precisa decidir o que merece ser feito e por quê.

Você não precisa ser um grande programador para construir software útil. Mas precisa entender o problema, o usuário e o negócio. Código nunca foi o produto. O produto é o problema resolvido.