Codificação Vibe, depois da lua de mel
· 6 min read · Filippo Spinella · AI, Coding, Agents, Developer Tools
Vibe coding é uma daquelas expressões que parecem nascer para serem odiadas e depois, lentamente, tornam-se úteis.
A princípio parece: não penso, pergunto à IA, aceito o que sai, continuo. Uma forma alegre de produzir dívida técnica com fundo musical.
Mas seria muito fácil descartá-lo assim. A verdade é que o vibe coding interceptou algo real: programar com um modelo muda a relação entre ideia e protótipo.
Primeiro você teve um pensamento e depois uma longa subida. Muitas vezes você tem um pensamento e meia hora depois algo se move na tela. É difícil não ser seduzido por isso.
A questão interessante, em 2026, não é se a codificação de vibração é verdadeira. Isso é. A questão é: o que acontece depois da lua de mel?
O protótipo tornou-se econômico
Esta é a parte mais importante.
As ferramentas de IA reduziram o custo emocional de começar. Antes, se você quisesse testar uma ideia, já tinha que colocar a mão na massa: escolher a pilha, criar o projeto, lembrar do clichê, escrever o layout, conectar APIs, discutir detalhes chatos.
Agora você pode dizer: dê-me uma primeira versão.
E chega uma primeira versão.
Nem sempre bonito. Nem sempre correto. Muitas vezes frágil. Mas isso acontece. E quando chega, muda a conversa. Você não está mais discutindo no vácuo. Você está tocando alguma coisa.
Isso é muito poderoso para designers, fundadores, gerentes de produto, desenvolvedores seniores cansados de reescrever andaimes, pessoas curiosas que nunca teriam aberto um editor antes.
A codificação Vibe é um exagero porque dá a mais pessoas a sensação física do software que está sendo criado.
O problema é que o software continua vivo
A parte que o meme menos conta é o dia seguinte.
O protótipo deve ser lido. Correto. Testado. Implantado. Protegido. Recebi de outra pessoa. Conectado a dados reais. Tornado acessível. Mantido quando uma dependência é alterada.
Aqui a codificação de vibração pura atinge a parede.
Um modelo pode gerar muito código rapidamente, mas o código em si não é valor. É uma promessa de comportamento. E uma promessa deve ser verificada.
O risco da codificação vibe não é escrever um código feio. Sempre fizemos isso, mesmo sem IA. O risco é perder o sentido de propriedade: “o modelo fez isso” torna-se uma desculpa para não compreender o suficiente.
Mas o tempo de execução não aceita desculpas. Se o código for executado em produção, ele será seu.
Da codificação de vibração à engenharia de agentes
A versão madura do vibe coding é não parar de usar agentes. É usá-los com um ciclo mais sério.
Não: gera tudo e esperamos.
Mas:
- descreva a intenção;
- vamos gerar um rascunho;
- peça ao agente para explicar o plano;
- faça pequenas diferenças;
- lançar testes;
- faça avaliações;
- correto;
- só então participe.
Essa coisa merece um nome diferente. Gosto de engenharia de agentes, mesmo que pareça um pouco solene. Significa usar agentes não como máquinas caça-níqueis, mas como colaboradores dentro de um processo de engenharia.
A questão não é tirar energia da codificação de vibração. Está dando pistas a ela.
Onde funciona muito bem
A codificação Vibe funciona quando o custo do erro é baixo e o valor da exploração é alto.
Exemplos:
- protótipos de interfaces;
- ferramentas pessoais;
- painéis internos;
- pequenos jogos;
- roteiro único;
- varreduras de API;
- prova de conceito;
- refatoradores mecânicos com bons testes;
- conteúdos técnicos a serem transformados em demonstrações.
Nestes casos a velocidade é o ponto. Você quer ver se a ideia tem pernas. Você quer descobrir o que não entendeu. Você quer chegar a uma conversa concreta.
A codificação Vibe é perfeita para fazer surgir formas.
Onde fica perigoso
Torna-se perigoso quando o sistema tem consequências e ninguém abranda.
Pagamentos, dados pessoais, autenticação, permissões, infraestrutura, migrações de banco de dados, código legado confidencial, conformidade, produção. Aqui a vibração não é suficiente. Precisamos de rigor.
Isso não significa que a IA não possa ajudar. Na verdade, pode ajudar muito. Mas deve funcionar dentro de limites estreitos: branch, sandbox, test, lint, review, feature flag, rollback.
A frase a ser tatuada no monitor é simples: quanto mais rápido o agente, mais legível deve ser o processo.
Se você não consegue explicar o que mudou, você não acelerou. Você apenas mudou a dívida do tempo para o entendimento.
O novo papel do desenvolvedor
O mais interessante é que o trabalho do desenvolvedor não desaparece. Alterar densidade.
Menos tempo no clichê. Mais tempo para intenção, decomposição, revisão, integração, teste, limites.
O desenvolvedor se torna uma espécie de editor técnico. Não no sentido esfarrapado de “revisar”. No sentido forte: decide o que deve existir, o que deve ser cortado, o que é coerente com o sistema, o que merece confiança.
Um bom editor não aceita tudo o que recebe. Ele nem mesmo reescreve tudo por orgulho. Reconhece o bom material, dá forma, protege o leitor.
Com os agentes, o leitor também é o futuro mantenedor. Muitas vezes é você em três semanas.
O padrão que vejo emergindo
O padrão mais saudável é este:
- humano: intenção, restrições, gosto, responsabilidade;
- agente: variantes, andaimes, busca, modificações locais, testes repetitivos;
- infraestrutura: sandbox, CI, trace, permissões, implantação;
- equipe: revisão, propriedade, padrões.
Quando falta uma dessas peças, algo fica deformado.
Apenas humano: lento, muitas vezes atolado em trabalhos repetitivos.
Somente agente: rápido, mas sem julgamento situado.
Apenas infraestrutura: Processo elegante para produzir coisas inúteis.
Somente equipe: reuniões muito organizadas em torno de um protótipo que nunca chega.
O melhor acontece quando as peças conversam entre si.
Uma pequena lista de verificação
Antes de deixar um protótipo codificado por vibração crescer, eu me perguntaria o seguinte:
- eu entendo a estrutura do código?
- existem testes para comportamento crítico?
- eu sei quais arquivos o agente tocou?
- removi o código gerado, mas não usado?
- algum segredo, token ou dado falso acabou no lugar errado?
- a acessibilidade mínima é respeitada?
- a implantação tem rollback?
- alguém além de mim pode ficar com ele?
Se a resposta for não para muitas perguntas, não é um fracasso. É apenas um protótipo que precisa continuar sendo protótipo por mais um pouco.
Minha leitura
Vibe coding é uma palavra forte para algo terno: a alegria de ver uma ideia tomar forma antes que o medo a impeça.
Eu não quero jogar fora. Isso seria esnobe. Muitas coisas boas nascem assim, meio tortas e vivas.
Mas o software restante precisa de mais. Precisa de compreensão, testes, propriedade, infraestrutura, limites. Precisa de alguém para dizer: legal, agora vamos tornar isso real.
Talvez o futuro não seja uma questão de escolher entre a programação “séria” e a programação “vibrante”. Talvez seja aprender a mudar de marcha: explorar levemente e depois consolidar com respeito.
A parte humana está aí. Saiba quando correr e quando sentar e ler as diferenças.