Vibe coding não pode ser desculpa para trabalho de baixa qualidade
(addyo.substack.com)- Vibe coding com IA é inovador, mas o alerta é claro: velocidade sem qualidade é perigosa
> "Mova-se mais rápido e quebre mais coisas"
> "vibe coding, a forma como dois engenheiros conseguem criar dívida técnica para 50" - Essa releitura irônica de um velho slogan do Vale do Silício vem circulando recentemente na comunidade de engenharia como o conceito de “vibe coding”
- O desenvolvimento com IA realmente está revolucionando a forma de criar software, mas isso não dá licença para abandonar rigor, revisão e capricho técnico
- “vibe coding” não pode ser desculpa para justificar trabalho de baixa qualidade
- Reconhecendo os pontos positivos, programação assistida por IA pode ser um verdadeiro game changer
- Reduz a barreira de entrada para novos programadores e não especialistas, permitindo que criem software funcional apenas descrevendo o que precisam
- Isso libera a criatividade e permite que mais pessoas resolvam seus próprios problemas diretamente com software sob medida
- Esse movimento é visto como parte da tendência de desagregação do software pessoal (uso de pequenas ferramentas com IA em vez de apps prontos)
- Engenheiros experientes também podem se beneficiar
- Mas, como qualquer engenheiro experiente dirá, velocidade não significa nada se as rodas caírem no fim do caminho
- E é exatamente aí que começam a surgir as rachaduras — o abismo entre o vibe e a realidade, isto é, a realidade de construir software robusto e de fácil manutenção
A verdade incômoda: qualidade não vem automaticamente
- O hype é grande, mas o ceticismo dos desenvolvedores veteranos em relação ao vibe coding também é forte
- A crítica central é esta: o fato de a IA gerar código rapidamente não significa que esse código seja bom
- Na verdade, confiar e usar código gerado por IA sem questionar pode ser bem perigoso
- A piada de que “dois engenheiros criam dívida técnica equivalente ao trabalho de 50” não é totalmente piada
- Código de IA sem revisão pode ampliar dívida técnica em larga escala
→ Essa dívida torna o código frágil, difícil de manter e gera custos altos no longo prazo
- Projetos feitos com vibe coding muitas vezes parecem ótimos à primeira vista ("está funcionando, vamos publicar!")
- Mas, na prática, escondem riscos como:
- falta de tratamento de erros
- baixo desempenho
- práticas de segurança instáveis
- estrutura lógica fraca e quebradiça
- Esses projetos são como estruturas erguidas sobre areia
- E, na expressão que eu uso, são “casas de cartas (
house of cards code)” —
parecem completas por fora, mas desmoronam facilmente sob pressão real - Se você já viu a primeira grande funcionalidade de um dev júnior quase funcionar, mas quebrar imediatamente com uma entrada inesperada, sabe exatamente a sensação
- A IA pode gerar muito código rapidamente, mas quantidade não significa qualidade
- "A IA é como um desenvolvedor júnior extremamente entusiasmado que entrou no time"
- → Essa ideia é bem ilustrada por Forrest Brazeal
- Esse risco não é só uma hipótese; na manutenção real, o problema também é concreto
- Se um módulo criado por IA for complexo demais ou difícil de entender, quem vai ficar responsável por mantê-lo?
- Mesmo que nem o próprio desenvolvedor que escreveu inicialmente entenda totalmente o código produzido pela IA,
esse código pode virar um pesadelo para futuras correções ou expansões
- Segurança é outro grande problema
- A IA pode produzir código que aparentemente funciona bem, mas esconder vulnerabilidades críticas como SQL injection
- Ou pode haver tratamento de erros deficiente
- Se esses problemas forem para produção sem uma revisão rigorosa, podem causar incidentes reais
- Outro problema é o overfitting ao prompt
→ A IA faz exatamente o que você pediu, mas isso pode ser diferente do que realmente era necessário - Um desenvolvedor humano percebe erros de design ou mal-entendidos durante a implementação e os corrige
- Já a IA não percebe esse tipo de mal-entendido de forma alguma, e o problema permanece se ninguém identificar e corrigir
- Claro, tudo isso não significa que a IA nunca consiga escrever bom código —
- Às vezes, a IA produz código excelente
- Mas, para decidir se esse código realmente pode ser usado, três coisas são indispensáveis:
- contexto
- análise crítica
- experiência e especialização
- Em 2025, a IA que usamos é como uma assistente cheia de entusiasmo, mas sem experiência
- Assim como você não colocaria um desenvolvedor júnior de primeiro ano para projetar todo o sistema sem supervisão,
também não deve aceitar código de IA sem revisão - A expectativa em torno da “mágica da IA” agora precisa entrar em harmonia com a realidade da engenharia de software
- Então, como encontrar equilíbrio?
- O importante é que não é preciso rejeitar totalmente o vibe coding
- Em certos casos, vibe coding pode ser muito útil
- Mas o essencial é integrá-lo de forma disciplinada — isto é, enxergar a IA como uma ferramenta com limites claros
- Isso significa que o ser humano precisa continuar no circuito, usando a IA de um jeito que preserve nossos padrões de qualidade e princípios de engenharia
IA não é substituta, é estagiária (o ser humano precisa continuar no circuito)
- Para usar vibe coding de forma eficaz, é preciso mudar a mentalidade e tratar a IA como ‘uma estagiária de desenvolvimento muito rápida, mas inexperiente’
- Ou seja, você — engenheiro sênior ou líder técnico — continua sendo o responsável final pelo resultado
- A IA pode gerar um rascunho rapidamente, mas você ainda precisa revisá-lo com olhar crítico, corrigi-lo e confirmar que atende aos padrões de qualidade
- Desenvolvedores experientes seguem esse processo de forma intuitiva
- Quando a IA sugere código, eles não simplesmente clicam em “Accept” e seguem em frente; em vez disso, fazem o seguinte:
- Ler e entender primeiro o código escrito pela IA — tratando-o como código de um dev júnior
- Modularizar e refatorar se o código vier em um bloco único ou estiver bagunçado — quebrando em partes menores e mais claras
- Adicionar manualmente tratamento de exceções e edge cases ausentes — null checks, validação de entrada etc. são coisas que a IA frequentemente omite
- Reforçar tipagem frouxa ou abstrações incompletas — transformando suposições implícitas em contratos explícitos
- Avaliar se a arquitetura ou abordagem escolhida pela IA é ineficiente — por exemplo, força bruta ou introdução de estado global
- Escrever testes ou fazer testes manuais — se a IA gerou testes unitários, também é obrigatório revisar se esses testes fazem sentido
-
Em todo esse processo, você injeta sabedoria de engenharia no código produzido pela IA
-
Essa combinação pode ser muito poderosa — a IA oferece velocidade, e o ser humano garante confiabilidade
-
Na prática, pesquisas e experiências do mercado mostram que desenvolvedores sêniores tiram mais valor das ferramentas de programação com IA do que juniores
-
Isso acontece porque o sênior tem o conhecimento e a experiência para orientar corretamente a saída da IA e corrigir seus erros
-
Já o júnior corre maior risco de acreditar erroneamente que a IA é uma autoridade absoluta
- Por isso, surge uma regra importante:
→ todo código escrito por IA deve ser incorporado somente após revisão - Como ao revisar o PR de um desenvolvedor iniciante, é preciso ler linha por linha e só fazer merge depois de entender tudo completamente
- Não parta do pressuposto de que a IA é mais inteligente — na maioria dos casos, não é
- Se houver trechos que você não entende:
- vale a pena refinar o prompt e pedir com mais clareza, ou
- reescrever você mesmo aquele código
- A saída da IA é apenas um “rascunho” e obrigatoriamente precisa passar por revisão
- Em um ambiente de desenvolvimento em equipe:
- se alguém usou IA para criar código,
- essa pessoa deve ser capaz de explicar e defender diretamente esse código durante a revisão
- “simplesmente funciona” não basta — código de verdade é código que seres humanos entendem e conseguem manter
- Outra boa prática: o design fica com humanos, a implementação com a AI
- Em outras palavras, use a AI para implementar rapidamente tarefas já bem definidas, como uma API CRUD
- Já pedidos como “projete uma arquitetura de microsserviços escalável” devem ficar com pessoas
- Design de alto nível e decisões centrais devem continuar sendo responsabilidade humana
- Resumindo: deixe o trabalho repetitivo (grunt work) para a AI e o pensamento e julgamento (brain work) para as pessoas
- Comunicação e documentação também se tornam muito importantes
- Se você pediu à AI um algoritmo complexo ou uma biblioteca pouco familiar,
- é essencial documentar o motivo e a intenção dessa escolha
- futuros mantenedores, ou você mesmo no futuro, precisam conseguir entender por que aquele código foi feito daquele jeito
- Algumas equipes chegam a registrar os próprios prompts usados em gerações importantes de código com AI
→ isso é útil na depuração, porque permite consultar o “histórico de conversa” com a AI
- Em conclusão, intervenção humana não é opcional, é obrigatória
- Usar apenas código de AI sem participação humana é jogar dados com a qualidade do software
- Ainda não chegamos a uma era em que a AI possa substituir a compreensão ampla de um engenheiro sênior
- vibe coding deve ser uma parceria —
→ a AI pode dar velocidade, e os humanos colocam o cinto de segurança nessa velocidade
Regras práticas para um vibe coding de alta qualidade
- Vamos organizar a discussão até aqui em regras acionáveis e boas práticas
- Isso pode ser visto como um novo manual de “mova-se rápido, mas não estrague tudo”
- São regras que funcionam como guarda-corpos para manter a qualidade mesmo fazendo vibe coding
- Regra 1: Always Review AI-Generated Code / Sempre revise código gerado por AI
- Sem exceções. Todo código escrito por AI deve ser revisado como se tivesse sido escrito por um desenvolvedor júnior
- Seja revisão individual ou por pares, ela precisa acontecer
- Vale para Copilot, ChatGPT, Cursor ou qualquer outra AI
- Se você não tem tempo para revisar, então também não tem tempo para usar esse código
- Fazer merge de código de AI sem revisão é o mesmo que assumir o risco por inteiro
- Regra 2: Establish Coding Standards and Follow Them / Defina padrões de código e siga-os
- A AI reflete os estilos de código com que foi treinada, então sem um padrão consistente de equipe, a qualidade fica irregular
- O guia de estilo da equipe, os padrões de arquitetura e as regras de codificação precisam estar claramente definidos
- Ex.: “toda função deve ter JSDoc e testes unitários” → o mesmo se aplica ao código gerado por AI
- Em projetos que usam hierarquia ou arquitetura em camadas,
é essencial refatorar para impedir que a AI coloque chamadas de banco de dados dentro do código de UI - Também é recomendável adotar regras de lint ou análise estática para capturar erros comuns da AI (ex.: funções complexas demais, uso de APIs deprecated etc.)
- Regra 3: Use AI for Acceleration, Not Autopilot / AI é acelerador, não piloto automático
- vibe coding deve ser usado para resolver rapidamente tarefas que você já conhece bem
- Bons usos:
- gerar boilerplate
- criar scaffolding de componentes
- conversão entre linguagens
- escrever o esqueleto de algoritmos simples
- Usos arriscados:
- pedir que ela projete um módulo inteiro com uma descrição vaga
- tentar gerar código em um domínio que você não conhece bem
- Se o código vai permanecer de forma definitiva, é obrigatório migrar do modo vibe para o modo engineering
- Regra 4: Test, Test, Test / Teste, teste, teste
- Só porque a AI gerou o código não significa que ele esteja automaticamente certo
- É obrigatório escrever testes para todos os fluxos principais
- Se a AI também gerou os testes, é preciso verificar se eles são realmente válidos
- Principalmente em funcionalidades de UI ou partes com muita entrada de usuário, é obrigatório clicar manualmente e testar entradas inválidas
- Apps feitos com vibe coding costumam funcionar bem só no happy path e ser frágeis diante de entradas excepcionais
- Regra 5: Iterate and Refine / Itere e refine
- Se o primeiro resultado que a AI entregou não estiver satisfatório, não deixe passar: tente de novo ou refatore
- vibe coding é um processo iterativo baseado em conversa
- Ex.:
- “deixe esse código mais conciso”
- “divida isso em funções menores” e assim por diante, ajustando o prompt
- Ou então refatore você mesmo → identifique os pontos a corrigir → crie um novo prompt → repita
- Usar a AI em ciclos é uma estratégia eficaz
- Regra 6: Know When to Say No / Saiba quando dizer não
- vibe coding nem sempre é a melhor opção
- Em situações que exigem design crítico ou segurança, é melhor escrever diretamente
- Ex.:
- em módulos relacionados à segurança, faça o design você mesmo e use AI só em partes específicas
- se a AI complicar uma questão simples, programar direto pode ser mais rápido
- Quando a AI não estiver resolvendo bem o problema, não insista: mude para o modo manual
- "Foi a AI que fez" não é desculpa para não entender o próprio código
- Regra 7: Document and Share Knowledge / Documente e compartilhe conhecimento
- Código gerado por AI também deve ser documentado tanto quanto código escrito manualmente (às vezes até mais)
- Se houver decisões pouco intuitivas ou implementações incomuns, deixe comentários
- Compartilhe claramente com a equipe quais partes foram geradas por AI
- Algumas equipes salvam os prompts usados no código principal gerado por AI exatamente como foram escritos → isso ajuda na depuração
- Seguindo essas regras, as equipes conseguem aproveitar ao máximo a produtividade do vibe coding e ao mesmo tempo minimizar os riscos
- O ponto central é que a AI não substitui pessoas, e sim as complementa
- A AI acelera o trabalho repetitivo, enquanto os humanos cuidam do pensamento crítico e da criatividade
- Vivemos uma era em que criamos código em conjunto (co-create) com a AI
Quando o vibe coding funciona bem vs. quando desmorona
- Também é importante saber com clareza onde o vibe coding brilha e onde ele não funciona tão bem
- Nem todo projeto ou tarefa é igualmente adequado a um fluxo de trabalho baseado em AI
- A seguir, uma classificação de uso organizada com base em experiências e casos do setor
- 👍 Situações em que funciona bem (Great Use Cases)
- Rapid prototyping (prototipagem rápida)
→ o ponto ideal do vibe coding. Quando há um pequeno app ou uma ideia de funcionalidade
→ é possível usar um assistente de IA para criar rapidamente uma prova de conceito ou protótipo
→ não tem problema se o código ficar um pouco desajeitado — o principal é validar a ideia
→ há muitos casos de projetos de fim de semana em que apps são feitos só com IA para testar um conceito - One-off scripts / Internal tools (scripts pontuais, ferramentas internas)
→ parsing de arquivos de log, automação de trabalho pessoal, dashboards internos etc.
→ em ambientes onde o risco de falha não é grande, o vibe coding é eficaz para economizar tempo
→ em situações que não exigem qualidade de produção, dá para criar rapidamente algo que “funcione agora” - Learning and exploration (aprendizado e experimentação)
→ ao aprender uma nova linguagem ou API, pedir à IA que gere exemplos
→ mesmo que o código não seja perfeito, ele já serve bem como material de aprendizado
→ é como um monitor virtual mostrando várias abordagens, que depois a pessoa ajusta - Boilerplate-heavy tasks (tarefas cheias de boilerplate)
→ ex.: gerar 10 classes de dados parecidas, implementar CRUD
→ se a estrutura estiver clara, a IA consegue seguir padrões repetitivos com precisão
→ dá para passar rapidamente pelas tarefas mecânicas e deixar as pessoas focarem no que importa
- Rapid prototyping (prototipagem rápida)
- 👎 Situações em que surgem problemas (Not-So-Great Use Cases)
- Enterprise software / Complex systems (software de nível enterprise, sistemas complexos)
→ sistemas com lógica de negócio complexa, concorrência, segurança e requisitos de compliance
→ a IA não conhece essas condições se elas não forem explicitadas; e, mesmo conhecendo, pode refletí-las mal
→ ex.: sistemas de pagamento fintech, software de controle aeroespacial etc. nunca devem ser deixados apenas para a IA
→ nesses ambientes, ela só pode ajudar em parte, e a qualidade final exige QA humano e expertise - Long-term maintainability (manutenibilidade de longo prazo)
→ em codebases que vão durar anos, a estrutura importa desde o começo
→ códigos feitos na base do remendo com IA tendem a ter menos consistência e viram um grande peso na manutenção posterior
→ é melhor investir tempo no início para definir um framework e um design claros
→ muitos usuários iniciais compartilham a experiência de que o tempo economizado com vibe coding
depois acaba sendo gasto de volta em refatoração e limpeza - Critical algorithms / Optimizations (algoritmos críticos ou trabalho de otimização)
→ ex.: gerenciamento de memória customizado, algoritmos de ordenação ultrarrápidos etc.
→ a IA pode ir bem com entradas pequenas, mas costuma carecer de atenção à escala
→ pode ficar lenta ou funcionar errado sem aviso
→ nessas partes, ainda é preciso criatividade humana e compreensão profunda - Explainability and clarity (clareza e explicabilidade)
→ situações em que o código precisa ser lido com clareza por outros desenvolvedores ou auditores
→ se a IA abstrair demais ou adotar abordagens complexas, a legibilidade e a manutenibilidade caem seriamente
→ hoje, a IA nem sempre busca “código curto e conciso” → às vezes ela fica verbosa demais ou abstrai sem necessidade
→ nesses casos, é preciso refatoração humana e escrita de código clara
- Enterprise software / Complex systems (software de nível enterprise, sistemas complexos)
- Em resumo, vibe coding é uma poderosa ferramenta de aceleração, mas não uma solução mágica universal
- É muito eficaz quando a velocidade importa e o trabalho pode ser ajustado algumas vezes
- Por outro lado, entregar um software mission-critical de uma vez só para a IA é uma aposta arriscada
- Fazendo uma analogia: é como colocar um ônibus escolar nas mãos de um piloto de corrida — boa ferramenta, uso errado
- Talvez um dia a IA possa virar a ferramenta básica de todo desenvolvimento, mas hoje ainda não
- O que precisamos fazer hoje é usar a IA no problema certo, da forma certa e com a responsabilidade certa
Conclusão: use o vibe com cuidado — aproveite a velocidade, mas sem perder o artesanato
- vibe coding e o desenvolvimento de software baseado em IA representam um salto gigantesco na evolução das ferramentas
- esse movimento não é uma moda passageira, mas uma realidade já estabelecida, e vai ficar mais sofisticado no futuro
- equipes de engenharia com visão de futuro não podem ignorar isso
- assim como ferramentas de automação anteriores e frameworks mais avançados superaram formas antigas de desenvolver,
há uma grande chance de equipes que usam bem a IA superarem as que não usam - a mensagem deste texto não é rejeitar o vibe coding —
→ é abordá-lo de olhos abertos, preservando os fundamentos da engenharia
- A lição mais importante: velocidade sem qualidade não significa nada
- Implantar rápido um código cheio de bugs e impossível de manter é só correr em alta velocidade rumo ao precipício
- Os melhores desenvolvedores são aqueles que aceleram com IA sem derrubar o sistema
- A IA levanta o peso, e os humanos verificam se aquilo está realmente de pé
- Encontrar esse ponto de equilíbrio (sweet spot) é o essencial
- Pontos práticos para líderes técnicos e gestores:
→ é preciso consolidar na equipe a cultura de que a IA é uma ferramenta a ser usada com responsabilidade- incentivar o vibe coding, mas também estabelecer expectativas e regras claras para proteger a codebase
- código gerado por IA também deve sempre passar por code review,
- criando uma cultura em que a pergunta “você entende este código?” seja natural
- investir no fortalecimento da equipe para que todos consigam colaborar com a IA de forma eficaz
- adotando novas habilidades, como escrever bons prompts e avaliar sugestões da IA
- isso é uma mudança de paradigma parecida com a transição para linguagens de alto nível ou a adoção do Git
→ as equipes que se adaptarem rápido vão sair ganhando
- O que realmente devemos continuar valorizando em engenharia de software ainda é o seguinte:
- resolver problemas dos usuários
- construir sistemas confiáveis
- continuar aprendendo
- vibe coding é um meio, não um fim
- Se ele ajuda a entregar valor ao usuário de forma mais rápida e melhor, é uma ótima ferramenta
- Mas, se no processo ele nos leva a sacrificar a qualidade e a segurança em que precisamos confiar, é melhor frear o uso
- A essência continua válida:
→ pensamento claro, entendimento dos requisitos, design preparado para mudanças e testes rigorosos
- Por fim, guardemos este espírito:
→ “mova-se rápido, mas não quebre as coisas — e, se quebrar, que ao menos seja possível consertar.” - Produza código com velocidade, mas sobre uma base de engenharia sólida
- A IA pode ser um cinzel poderoso nas mãos de um artesão
→ mas ainda são mãos humanas que manejam esse cinzel
- Então, desenvolvedores, entrem no vibe — mas com cautela
- Abracem o futuro, mas sem abrir mão dos princípios fundamentais que nos trouxeram até aqui
- vibe coding não é uma desculpa para justificar baixa qualidade,
→ mas uma oportunidade de mostrar quanto mais podemos construir quando o julgamento humano se combina com a capacidade generativa das máquinas
- equipes que internalizarem esse princípio não vão apenas ficar mais rápidas,
→ vão criar software que vale a pena manter vivo por muito tempo
> Happy coding — e vibe lá em cima, qualidade mais ainda.
3 comentários
+1
Concordo.
Aviso: conteúdo longo
Opiniões no Hacker News
Redefiniram o significado de "vibe coding"
O hype em torno de programação com IA ficou tão grande que parece impossível corresponder à realidade
Isso lembra o período do começo dos anos 2000, quando grandes empresas tentavam terceirizar desenvolvimento para países de baixa renda
Tratar a IA como um desenvolvedor júnior da equipe pode acabar consumindo mais tempo
Depende do caso de uso
Existem diferentes perspectivas sobre qualidade de software
Há uma questão sobre se programação assistida por IA pode afetar negativamente o crescimento dos desenvolvedores
Usam vibe coding para medir a dificuldade do trabalho
As pessoas tendem a poupar energia, e vibe coding viabiliza um desenvolvimento de baixo esforço
O artigo inteiro parece inflar a frase: "antes de colocar vibe code em produção, um humano precisa revisar"