Vibecoding
O erro de arquitetura que todo vibecoder comete
Colocar lógica sensível no navegador. É o erro que parece funcionar e abre seu app de par em par.
Existe um erro de arquitetura que quase todo vibecoder comete. Inclusive eu, no começo.
Confiar no navegador.
Colocar no front-end aquilo que devia morar no servidor. Funciona na tela. E deixa seu app aberto de par em par.
O erro, em uma frase
O navegador é do usuário, não seu.
Tudo que roda no navegador, o usuário pode ver, copiar e mudar. A validação que você fez ali? Ele desativa. A regra que você escondeu no código? Ele lê. O preço que você travou no front? Ele altera.
Se a decisão importa, ela não pode morar onde o usuário manda.
Por que ele engana tanto
O erro é traiçoeiro porque funciona. Você testa, valida, mostra a mensagem de erro certinha. Parece blindado.
Mas você testou como usuário bonzinho. O invasor não é bonzinho. Ele abre as ferramentas do navegador e pula a sua validação em dois cliques.
Funcionar na tela e estar seguro são duas coisas diferentes. O erro é achar que a primeira garante a segunda.
Três exemplos que eu já vi
Validação só no navegador: o campo checa o e-mail na tela, mas a API aceita qualquer coisa. Basta chamar a API direto.
Preço no front-end: a loja calcula o total no navegador e envia pro pagamento. O usuário muda o total pra um real.
Regra de acesso no botão: o botão de admin fica escondido pro usuário comum, mas a rota de admin responde pra qualquer um. Esconder não é proteger.
Os três funcionam na demo. Os três são buraco.
A linha de pensamento certa
A correção não é uma técnica. É uma forma de pensar. Divida cada coisa em dois lugares:
O navegador mostra, facilita e dá feedback rápido
O servidor decide, valida de verdade e protege
Validação no navegador é conforto pro usuário. Validação no servidor é segurança. Você faz as duas. Mas nunca confia só na primeira.
Preço, permissão, regra de negócio, dado sensível: tudo isso é decisão. Decisão vive no servidor.
Como saber se você comete o erro
Faça a pergunta a cada feature:
Se o usuário abrir as ferramentas do navegador e mexer, ele quebra alguma regra minha?
Se a resposta é sim, aquela regra está no lugar errado. Mova pro servidor.
Essa pergunta única pega a maioria dos furos de arquitetura antes de virarem incidente.
O resumo
O erro que todo vibecoder comete é confiar no navegador. Ele funciona, engana e abre o app.
A correção é uma linha: o navegador facilita, o servidor decide. Vibecoding às cegas confia no que vê na tela. Vibecoding com engenharia sabe que a tela é território do usuário.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Qual é o erro de arquitetura mais comum?
Confiar no navegador. Colocar validação, regra de negócio e segredo no front-end, onde qualquer um vê e burla.
+Se funciona na tela, por que está errado?
Porque funcionar não é o mesmo que estar seguro. O navegador é território do usuário. Tudo lá pode ser alterado.
+Como corrijo isso?
Regra que importa vive no servidor. O navegador mostra e facilita. O servidor decide e protege. Essa é a linha.
Continue lendo
Como documentar um sistema que a IA escreveu
Documentação longa ninguém escreve e ninguém lê. Existe uma versão curta que cabe em uma página e resolve 90% do problema, principalmente quando quem escreveu o código foi a IA.
VibecodingComo subir pra produção numa sexta sem medo
A regra de não subir na sexta existe porque o processo é ruim, não porque sexta é perigosa. Com quatro coisas no lugar, o dia da semana para de importar.
VibecodingO agente de código entrou no canal do time. Ver não é revisar
O Slack lançou canais onde agentes de IA programam na frente de todo mundo, com Claude, Copilot, Devin, ChatGPT e Vercel. É a melhor notícia de governança do ano e a maior armadilha de teatro de revisão.