O que é vibe coding? A explicação simples — e o capítulo que os guias pulam

Toda ferramenta de vibe coding, seja qual for o marketing, roda alguma versão de um único ciclo: descrever → gerar → rodar → reagir. Você escreve "uma lista de tarefas em que os itens se ordenam pelo prazo"; o agente planeja a mudança, escreve o código em quantos arquivos forem necessários, compila o projeto, vê os mesmos erros que um programador veria, corrige e mostra o resultado rodando. A sua próxima frase — "as atrasadas ficam em vermelho" — repete o ciclo em cima de tudo que já foi construído.

Três coisas por baixo do capô decidem se esse ciclo produz algo bom, e vale conhecê-las porque explicam toda diferença de qualidade entre ferramentas:

Contexto. O agente só respeita o que consegue ver — as suas decisões anteriores, o código que já existe, o sistema de design. As ferramentas variam enormemente em quanto lembram e em como escolhem o que olhar.

Estrutura. Peça funcionalidades uma por uma, sem plano, e o agente improvisa uma arquitetura por prompt — ótimo para uma demo, ruim de um jeito que se acumula até a funcionalidade vinte. Ferramentas que decidem a estrutura antes (ou deixam você decidir) produzem código que continua utilizável.

Verificação. As melhores ferramentas não entregam código que deveria funcionar; elas compilam, rodam, testam e corrigem os próprios erros antes de você ver qualquer coisa. A diferença entre "gera código" e "entrega software" mora quase toda aqui.

Repare no que está ausente dessa lista: a sua capacidade de programar. O que o ciclo consome de verdade é a sua capacidade de descrever com precisão e reagir com honestidade — e é por isso que gente de produto pegou o jeito mais rápido que qualquer outro perfil. Escrever o que deve existir, cenário por cenário, já era o trabalho.

Bom, hoje: ir da ideia ao software funcionando numa sentada; iterar barato (a tentativa de novo que custava a tarde de um engenheiro agora custa uma frase); as superfícies padrão de produto — telas, formulários, listas, contas, pagamentos com backends gerenciados; e deixar a pessoa com o julgamento de produto construir diretamente, em vez de passar o recado por camadas.

Ainda falha, honestamente: trabalho sem especificação descritível (se você não consegue dizer como é o "certo", o agente também não); algoritmos realmente novos e programação de sistemas incomum; resgatar uma base de código grande que ele não construiu; e compensar a ausência de pensamento de produto — um agente amplifica a qualidade das decisões nos dois sentidos.

E um modo de falha pertence ao usuário, não às ferramentas: confundir demo com produto. Qualquer ferramenta desta página entrega uma demo impressionante numa tarde. Produtos precisam, além disso, de estrutura que sobreviva à funcionalidade vinte, contas que funcionem, dados que persistam, atualizações que saiam e código que seja seu. As ferramentas diferem muito mais nessa segunda metade do que na velocidade da demo — o que nos leva ao mapa.

A maioria das listas ordena por velocidade e acabamento. Ordene pelo resultado — o que aquilo que você descreve realmente vira — e o mercado inteiro cai em cinco grupos. (Sem preços aqui: eles mudam, e cada ferramenta publica os seus. A pergunta a fazer é sempre a mesma: em qual plano eu consigo publicar e levar o código embora?)

Construtores web — resultado: aplicativos web. Lovable é a referência: apps em React, sincronização com GitHub, backend no Supabase. v0, da Vercel, e Bolt jogam o mesmo jogo. Para produtos web, são publicáveis de verdade; para protótipos de qualquer coisa, são excelentes.

Ferramentas de protótipo — resultado: demos interativas descartáveis. Figma Make vive dentro do ecossistema de design e é honesto sobre o que é: feito para explorar, não para publicar.

Agentes de código, traga a sua IA — resultado: o que você conseguir dirigir. Claude Code, Cline, Aider: agentes que trabalham numa base de código real usando a sua própria assinatura ou chave de API. Liberdade máxima, sem trilhos — ótimo para desenvolvedores, e o caminho em que gente de produto mais precisa da estrutura que o grupo seguinte embute.

Construtores mobile — resultado: apps de celular, com uma bifurcação dentro do grupo que a maioria das listas nunca menciona. Rork, Vibecode e RapidNative geram React Native/Expo — JavaScript multiplataforma que roda no celular por meio de uma ponte, geralmente cobrado em créditos. FlutterFlow monta apps em Flutter visualmente. E a Modaal (nossa) gera código nativo de verdade da plataforma — Swift/SwiftUI para iPhone, Kotlin/Jetpack Compose para Android, os dois a partir de um projeto —, com o plano primeiro, o código no seu próprio disco e prompts ilimitados no plano gratuito. Por que essa bifurcação importa é o próximo capítulo, porque é a parte do vibe coding que os guias continuam pulando.

Eis a lacuna estranha em todo guia de vibe coding publicado até agora, em português ou em inglês: eles explicam o ciclo, listam as ferramentas, mostram uma demo web — e param no celular. "Mobile" aparece, quando aparece, como "seu app web também funciona no navegador do celular". Para quem tem um produto que pertence à tela inicial de um celular, essa frase esconde os três fatos que mais importam:

1. Um site no celular não é um aplicativo. Notificações push, uso offline, câmera e sensores, widgets, relógio e os pagamentos das lojas pertencem a apps de verdade. O teste rápido: os seus usuários chegam clicando num link ou abrindo um ícone?

2. Embrulhar o seu app web vibe-codado não atravessa a lacuna. O atalho óbvio — enfiar o app web numa casca em formato de app — esbarra na revisão da Apple, que costuma rejeitar cascas finas em volta de sites, e em todas as limitações acima, porque o app continua sendo um site fantasiado.

3. A lacuna agora é atravessável com a mesma habilidade. Isso é o que mudou e o que os guias ainda não alcançaram: o ciclo de descrever e iterar agora produz código nativo de verdade. Na versão da Modaal, o ciclo é de propósito mais estruturado do que o vibe coding web — um documento de produto quando o projeto começa e, para cada funcionalidade, o agente primeiro escreve um plano que você lê e aprova (cenários, abordagem, riscos, testes), e só depois constrói; o resultado é Swift e Kotlin que um engenheiro da plataforma reconheceria, compilando e testado, no seu disco. Vibe coding com a improvisação trocada por planos — que é exatamente o ajuste que torna possível um resultado de produção. O plano gratuito inclui um projeto ativo, prompts ilimitados e uma plataforma à sua escolha; o Pro custa 9 € por mês na cobrança anual (15 € mensal) e liga as duas plataformas e a distribuição nas lojas — detalhes em /pricing. É preciso um Mac.

A consequência prática: o caminho web e o caminho mobile agora começam do mesmo jeito — com uma descrição — e não precisam mais terminar numa reconstrução. Validou algo no Lovable que se revelou um app? O backend costuma sobreviver à mudança; a frente vira um app nativo de verdade, descrito na mesma língua que você usou no protótipo. Está começando do zero com um produto de celular? O passo a passo de como um agente constrói, o caminho do zero à Play Store e a conta real estão nos artigos ao lado.

A rampa de entrada de uma sentada, na ordem que evita os erros clássicos:

1. Escolha uma coisa real, mas pequena. Não o produto principal da sua empresa — uma ferramenta que você mesmo quer. O aprendizado está no ciclo, e coisas pequenas giram mais rápido.

2. Escreva cinco frases antes de encostar em qualquer ferramenta. O que faz; três cenários "o usuário faz X, vê Y"; o que a primeira versão deixa de fora de propósito. É a diferença entre dirigir e ir à deriva — e é o hábito que depois escala para produção.

3. Escolha a ferramenta pelo resultado, não pela demo. Produto web → construtor web. Produto de celular → ferramenta com resultado mobile (e decida conscientemente entre nativo e multiplataforma). Só explorando → qualquer uma, sem culpa.

4. Reaja com precisão. "Errado" não ensina nada ao agente; "o botão vai embaixo, no alcance do polegar" resolve numa passada. Você briefa o agente como briefaria um engenheiro muito literal e muito rápido — uma habilidade que gente de produto já tem.

5. Itere num celular de verdade cedo, se o produto for mobile — o simulador é educado, os dedos são honestos.

Começar não custa nada que importe: os construtores web têm planos gratuitos, e o plano gratuito da Modaal é um projeto completo com prompts ilimitados. O recurso escasso é o mesmo de sempre — saber o que construir. As ferramentas só pararam de esconder isso.