--- title: "O que entendi em um ano de vibe coding — e do que tenho um pouco de vergonha" url: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions" locale: "pt" author: "Mike Fluff" updated: "2026-06-20" description: "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." tags: - "vibe-coding" - "ai" - "developer" alternates: - locale: "en" url: "https://www.mikefluff.com/en/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/en/blog/vibe-coding-without-illusions.md" - locale: "ru" url: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/ru/blog/vibe-coding-without-illusions.md" - locale: "pt" url: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/pt/blog/vibe-coding-without-illusions.md" - locale: "es" url: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions" markdown: "https://www.mikefluff.com/es/blog/vibe-coding-without-illusions.md" --- # O que entendi em um ano de vibe coding — e do que tenho um pouco de vergonha > **Em resumo:** Vibe coding tira a parte mecânica da programação e deixa com você as decisões. De umas doze coisas feitas em um ano, quatro protótipos, três integrações e duas refatorações funcionaram, e falharam um backend com locks distribuídos e um SDK sem análogos. O que ajuda é formular o resultado, testar cada iteração e ler o código antes de aceitar. 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. **[Curso de vibe coding](https://www.mikefluff.com/pt/vibe-coding-course)** — Seis módulos, $19. Ferramentas, prompts, processo. Sem entusiasmo nem decepção — sobre como realmente funciona.