O que entendi em um ano de vibe coding — e do que tenho um pouco de vergonha
Um ano atrás eu achava que programar já não era necessário. Depois passei uma semana debugando um código que o modelo gerou em quinze minutos. Balanço pessoal.
Em junho do ano passado montei meu primeiro produto "sério" em modo vibe. Era uma ferramenta interna para um cliente — um bot que pegava e-mails de uma caixa, resumia e mandava o resumo para uma planilha. Montei num sábado. Dezesseis horas, sem contar comida e um passeio com o cachorro. No domingo olhei, concluí que funcionava, e fui dormir satisfeito.
Na segunda o cliente ligou dizendo que o bot estava "meio estranho". Principalmente — começou a adicionar nos resumos fatos que não estavam nos e-mails. O bot alucinava, como um bom aluno de primeiro ano de filosofia.
Sentei para debugar. Nos cinco dias seguintes entendi quatorze coisas que o modelo não tinha me contado enquanto escrevia o código. A principal: eu, na verdade, não sabia o que estava construindo. Sabia que queria que funcionasse. Não é a mesma coisa, acontece.
Sobre vibe coding escrevem dois tipos de gente. Primeiro — os entusiasmados: "agora num fim de semana entrego o que antes levava um mês!". Segundo — os decepcionados: "é tudo ficção, IA não faz nada, enquanto pagarmos programadores de verdade está tudo bem". Os dois, acho, perdem o ponto principal.
O ponto é que vibe coding não elimina a programação. Elimina a parte mecânica da programação. Digitar loops. Analisar JSON repetitivo. Escrever sua décima paginação da vida. Se você achava que o trabalho do dev é digitar, ganha muito. Se achava que é tomar decisões, o modelo não é ajudante, é interlocutor. E, honestamente, não muito inteligente. Sabe como fazer; não sabe por quê.
Aquele bot do verão é um exemplo clássico. Eu formulava tarefas do tipo "faça uma função que pega e-mails da API do Gmail e devolve um array". O modelo fazia. Funcionava. Depois "resuma cada e-mail". O modelo fazia. Também funcionava.
O problema era que eu não especifiquei nenhum critério de correção para o resumo. Eu assumia que "resumir" = "extrair os pontos-chave sem distorção". O modelo assumia que "resumir" = "reformular mais curto". Coincidem. Não totalmente.
Na sexta entendi que o que precisava ser reescrito não era o código, era o prompt dentro do modelo-resumidor. Reformulei numa linguagem que não pode ser interpretada de duas formas: "Extraia os fatos do e-mail. Fato = afirmação com sujeito, verbo e objeto. Não adicione nada que não esteja no e-mail. Em dúvida, escreva 'não mencionado'.". As alucinações sumiram. O código ficou igual. O prompt resolveu.
E isso é o que entendi em um ano. Vibe coding funciona quando você sabe formular. Não quando sabe programar. Não quando sabe escrever prompt. Mas quando sabe formular a tarefa de um jeito em que não dá para responder errado.
(Embora "não dá" seja exagero. Modelos são inventivos.)
No mesmo ano montei cerca de doze coisas em modo vibe. Delas:
Quatro — protótipos para clientes que foram para produção sem reescrita. Landing pages, pequenos paineis admin, tools internos. Continuam rodando. Vibe coding para esse tipo de tarefa é a ferramenta ideal. Não voltaria a escrever à mão. É um daqueles casos em que "desenvolvimento tradicional" vira tortura doméstica.
Três — integrações. Pega entrada de uma API, faz algo, manda para outra. Em 2026 isso costuma ser um prompt, não um sprint. Para integração o modelo é forte, porque o contexto de APIs públicas é justamente no que ele foi treinado.
Duas — refatorações. Dou ao modelo código alheio, descrevo o que quero, ele propõe, eu aceito. É meu uso favorito, porque aqui o modelo funciona como colega júnior de paciência infinita e ego zero.
Duas — fracassos completos. Tentativas de fazer coisas que eu não entendia totalmente. Uma foi um backend complexo com filas assíncronas e locks distribuídos. O modelo escreveu código que compilava, parecia certo, e tinha uma race condition sutil em cima dos locks do Redis, que eu só descobri em produção, quando dois usuários pediram a mesma coisa simultaneamente. O modelo não pega isso porque não enxerga causalidade em sistemas distribuídos. Vê código. O código parece certo.
Outra — tentativa de fazer um SDK custom com lógica de negócio única, sem análogos na internet. O modelo preencheu a lógica pela média do setor, e o que saiu foi "um SDK típico para uma tarefa típica", não o meu específico. Depois reescrevi à mão. Mais rápido teria sido começar assim.
Três regras que terminei adotando em um ano, se me permitem brevidade.
Primeira. Formule o resultado, não o código. "Adicione um endpoint POST /orders que aceita { id, items[], total }, valida, grava no banco, devolve 201" é pedido. "Faça os pedidos funcionarem" é reza. Entre um e outro: 80% do sucesso.
Segunda. Testa à mão cada iteração. Não depois de cinco prompts. Depois de cada um. Tenho uma regra dura comigo: se não verifiquei que o código funciona, não aceito o próximo prompt. Senão o modelo constrói uma torre de suposições, cada uma em cima da anterior, e quando cai — cai inteira.
Terceira. Leia o código, não só aceite. Se as linhas 40–60 estão opacas — pergunta ao modelo. Se ele não explica de um jeito que você entende — não está pronto para ir para produção. Não é sobre desconfiança. É que seu trabalho agora é revisão. Revisar código alheio, mesmo sendo um modelo de linguagem, exige entendimento.
Quem diz que dev não é mais necessário ou nunca consertou código alheio às 3 da manhã, ou está vendendo um curso de $500. (Já escrevi isso em algum lugar. Gosto da formulação porque é precisa.)
O modelo é uma alavanca. Alavanca sem apoio quebra no primeiro trabalho sério. O apoio é você, quem entende o que está construindo, por quê, e o que acontece quando dá ruim.
Em junho do ano passado eu achava que programar não era mais necessário. Em junho deste ano acho que programar é ainda mais necessário — só que não com as mãos. Com a cabeça.