As 12 paredes onde todo não-dev trava depois que a IA gera o código

Tem uma cena que se repete tanto que já dá pra prever o roteiro.

A pessoa abre o Lovable, o Bolt, o Replit. Descreve o que quer. Em quarenta segundos tem uma tela na frente: bonita, com botão, com o nome do projeto no topo. Mexe mais uma hora, ajusta a cor, troca o título. Fecha o notebook satisfeito.

Duas semanas depois aquela pasta está exatamente no mesmo lugar.

Não é falta de esforço, e definitivamente não é falta de inteligência. É que entre "a IA gerou o código" e "eu tenho um produto funcionando na mão de clientes" existe um trecho de caminho que ninguém documentou direito — e não foi por acaso. Quem sabe fazer aquilo aprendeu ao longo de anos, no emprego, com colega do lado, e passou a considerar cada etapa óbvia demais pra escrever.

Eu programo há quinze anos. Vou te dizer uma coisa que a minha categoria não gosta de admitir: a maior parte dessas paredes não é complexidade técnica. É documentação que ninguém se deu ao trabalho de escrever para quem não já sabia.

Então vamos escrever.

As paredes, uma por uma

Cada uma delas eu ouvi de gente real, em fórum brasileiro, em comunidade de vibe coding, em conversa de WhatsApp. As falas entre aspas são literais.

1. "A IA gerou, mas cadê meu app?"

A tela aparece no preview da plataforma. Fora dali, nada existe. Pra rodar na sua máquina você precisa de coisas que ninguém te avisou que precisaria — instalar um programa, rodar comando em terminal, entender o que é localhost.

"Você baixa o Cursor, abre, e vê uma tela com arquivos e pastas. Parece o Word se o Word fosse projetado para alienígenas."

Essa frase é de um dev, sobre o que o não-dev enfrenta. Ele tem razão. E a resposta padrão da internet pra isso é "é só rodar npm install" — que não é resposta, é senha de clube.

2. Conserta uma coisa, quebra outra

Você pede a funcionalidade B. Ela funciona. E a A, que estava de pé, para. Você pede pra consertar a A, e aí o que quebra é a C.

"Fix one thing, break another."

Isso tem nome em engenharia: regressão — quando uma mudança quebra algo que já funcionava. O efeito colateral mais cruel não é o bug: é que você começa a ter medo de pedir a próxima funcionalidade. E software que ninguém tem coragem de mudar já está morto, só não caiu ainda.

3. O loop

"You're just going in circles."

A IA erra, você aponta, ela "conserta", o mesmo erro volta. Terceira, quarta, quinta tentativa. Cada uma consumindo crédito.

Não é você fazendo pergunta errada. É uma característica conhecida dessas ferramentas: quando o contexto da conversa se contamina com as próprias tentativas falhas, o modelo passa a repetir a linha de raciocínio que já não funcionou.

4. O crédito evaporando

"Foram mais de 5000 créditos gastos para que no fim eu só me frustrasse."

"$25 in less than 15 minutes."

E o que dói de verdade não é o valor. É a assimetria: você paga pra IA consertar o que a própria IA quebrou. Um usuário do Replit escreveu que a maior parte dos cerca de US$700 que gastou num mês foi exatamente nisso.

Some o câmbio e o IOF, e o "plano de US$25" chega no seu cartão com outra cara.

5. "Ela disse que consertou" — e não consertou

"Lovable says that it has fixed it but it doesn't."

Essa é sutil e é a mais perigosa da lista, porque não parece um problema técnico. É um problema de prova. Existem quatro estados diferentes que, pra quem está começando, parecem o mesmo: a IA fez, a IA acha que fez, a IA disse que fez, e alguém verificou que está feito.

Só o quarto vale.

6. Cobrar dinheiro no Brasil

Pix, cartão, nota fiscal. A IA gera o código da integração — e gera errado com frequência incômoda, porque a documentação brasileira desses serviços é escassa, espalhada e desatualizada.

E o caminho feliz engana: "pagamento aprovado 🎉" é a parte fácil. O difícil é cartão recusado, cobrança duplicada, assinatura cancelada, estorno, e o aviso do banco que chega atrasado e você processa duas vezes.

7. A segurança que não dá sintoma

Essa é a parede que eu mais quero que você leia.

"Quem nunca estudou isso não sabe o que não sabe."

Um bug visível você percebe: o botão não funciona, alguém reclama. Uma falha de isolamento de dados — o cliente A conseguindo ver o dado do cliente B — não produz sintoma nenhum. A tela funciona. Ninguém reclama. Do seu lado, o app parece mais saudável do que um que tem um botão quebrado.

Em 2026, um estudo acadêmico montou um corpus de 10.517 aplicações feitas com IA, analisou 200 delas já publicadas na internet e encontrou 1.471 vulnerabilidades. Antes disso, em 2025, a empresa Escape varreu mais de 5.600 apps públicos e achou mais de 2.000 vulnerabilidades e mais de 400 chaves de acesso expostas.

Isso não quer dizer que o seu app está vazando. Quer dizer que funcionar não é evidência de que está protegido, e que o número de gente descobrindo isso da pior forma possível não é pequeno.

8. Você virou testador do seu próprio app

"All I was doing was being a tester."

A promessa era "você não precisa saber programar". O trabalho novo virou: testar software. A cada mudança, refazer cadastro, login, recuperação de senha, pagamento, tudo de novo. Meia hora, uma hora, por mudança.

9. Você não sabe o que deveria testar

Pior que a anterior. Você testa:

Cadastrei? Sim.
Entrei? Sim.
Paguei? Sim.

E publica. O teste que realmente importava era outro: abrir duas contas diferentes e tentar, da segunda, acessar o dado da primeira. Visualmente, os dois apps são idênticos.

10. Depois do MVP: manter aquilo vivo

"Parece que fica algo remendado, como se fosse uma pintura com 3 estilos diferentes."

O primeiro mês é o mais fácil da vida do app. Depois vem mudar o banco de dados sem perder o que já tem, atualizar dependência, lidar com serviço externo que mudou, com usuário que já existe, com dado velho.

11. Você tem o código, mas não tem a produção

Quase todas as plataformas hoje deixam você exportar o código ou conectar no GitHub. Então "lock-in de código" já é uma reclamação meio velha.

O problema é outro, e é maior: você pode ter todos os arquivos do mundo e ainda não conseguir reconstruir seu app amanhã. Porque produção não é só código — é banco de dados, contas de usuário, login, chaves secretas, variáveis de ambiente, domínio, e-mail, tarefas agendadas, backup. Nada disso vem no botão de exportar.

12. Fez, publicou, ninguém usou

"Apesar de muita gente dizer que a ideia é boa, nem a própria pessoa que chegou com a ideia está usando."

A última parede é a única que não é técnica, e é a que mata mais projeto. Um leitor de fórum brasileiro estimou que todo mês são liberados na casa de 150 mil domínios .br comprados e abandonados. Não dá pra auditar o número, mas o cemitério existe e qualquer um consegue enxergar.

O que essas doze têm em comum

Olhe a lista de novo. Quantas delas são sobre escrever código?

Nenhuma.

Todas são sobre o que vem depois de escrever: publicar, cobrar, proteger, verificar, manter, saber quando está pronto. E é exatamente esse pedaço que a indústria de conteúdo técnico decidiu não documentar para quem não é da tribo.

Isso mudou de lugar entre 2025 e 2026. A geração de código melhorou muito — em março de 2026 a Veracode media mais de 95% de acerto sintático no código gerado, ou seja, o código roda. Mas a taxa de tarefas que introduziam uma falha de segurança conhecida continuava perto de 45%, praticamente a mesma de 2025. Um benchmark acadêmico de dezembro de 2025 mediu a mesma coisa por outro ângulo: 61% das soluções funcionavam, 10,5% eram seguras.

Traduzindo o que esses números dizem juntos:

A IA ficou ótima em fazer parecer pronto. Não ficou boa na mesma velocidade em fazer estar pronto.

O que faltou não foi capacidade de construir. Foi capacidade de conferir.

Uma palavra sobre quem ri de você

Vou ser direto, porque isso atrapalha mais gente do que qualquer bug.

Existe um tipo de programador que trata quem construiu alguma coisa sem ele como intruso. Que chama de "energúmeno" quem pagou uma assinatura e conseguiu resolver o próprio problema. Que responde "é só ligar o RLS" e vai embora, sabendo perfeitamente que a frase não ajuda ninguém que não já saiba.

Eu sou dessa categoria há quinze anos e vou te dizer o que penso: isso não é rigor técnico, é medo. Medo de descobrir que boa parte do valor que ele cobrava vinha de guardar informação, e não de resolver problema.

Rigor técnico de verdade é outra coisa. É saber que isolamento de dados importa, e é conseguir explicar por quê para alguém que nunca ouviu a sigla. Quem sabe de verdade consegue explicar. Quem só quer manter o portão fechado precisa que continue difícil.

Você não precisa virar programador. Precisa virar dono: quem manda, quem define e — principalmente — quem confere.

Cada uma dessas doze paredes vai virar um post aqui, com o passo a passo que os tutoriais pulam. Começando pela mais perigosa: a que não dá sintoma.