Vibe Coding x Desenvolvimento Assistido por IA: onde termina a experimentação e começa a engenharia
Nos últimos meses venho vendo o mesmo erro se repetir em conversas com conhecidos, recrutadores, alunos do MBA e times técnicos: chamar qualquer uso de IA para programar de "vibe coding". É uma simplificação que esconde uma diferença que, na minha experiência construindo sistemas em produção, separa protótipo de dívida técnica.
Vibe coding e desenvolvimento assistido por IA usam as mesmas ferramentas. Cursor, Copilot, Claude Code, Codex, Replit, Lovable, tanto faz. O que muda não é o produto, é o comportamento de quem está no teclado. E essa diferença de comportamento é o que determina se o código que sai dali serve para validar uma ideia ou para sustentar um negócio.
O que é vibe coding, na prática
Vibe coding é descrever o que se quer em linguagem natural e deixar a IA gerar a maior parte do código, muitas vezes sem revisão profunda. A Merriam-Webster define o termo como criar código, páginas ou aplicativos pedindo a um programa de IA o que se quer, deixando a IA produzir o resultado, sem exigir que a pessoa entenda como ou por que aquilo funciona.
Simon Willison, que cunhou boa parte do vocabulário que hoje usamos para isso, fez uma distinção que considero a mais precisa que já li sobre o tema: usar um LLM para escrever código não é, por si só, vibe coding. Vibe coding é construir software com LLM sem revisar o que foi escrito.
O fluxo costuma ser assim:
- A pessoa descreve uma ideia, por exemplo "crie um sistema de login com dashboard".
- A IA gera uma aplicação inicial.
- A pessoa roda, vê o erro, cola o erro de volta.
- A IA corrige, mexe em arquivos, adiciona dependências novas.
- A pessoa pede mais telas, mais ajustes, mais comportamento.
- No fim, existe algo funcionando, mesmo que ninguém entenda totalmente a estrutura por baixo.
Não vejo problema nenhum nisso quando o risco é baixo. Para protótipo descartável, ferramenta pessoal, prova de conceito, validação rápida de hipótese, esse fluxo é ótimo. Reduz o atrito inicial e coloca uma ideia de pé em horas em vez de semanas. O problema aparece quando esse mesmo fluxo vira a forma de construir um produto que vai para produção com cliente pagante do outro lado.
Onde o risco técnico realmente mora
O risco do vibe coding não é a IA escrever código ruim. Eu escrevo código ruim às vezes, qualquer engenheiro sênior já escreveu. O risco é a ausência de compreensão, critério e responsabilidade técnica sobre o que foi entregue.
Quando uma aplicação cresce a partir de prompts sucessivos, sem desenho arquitetural, sem teste consistente e sem revisão de diff, eu já vi os mesmos sintomas se repetirem em projetos diferentes: regra de negócio espalhada em lugar errado, componente acoplado demais, dependência adicionada sem necessidade real, ausência de tratamento de erro, falha de segurança em autenticação e validação de entrada, código duplicado, zero observabilidade, critério de aceite inexistente, e uma dificuldade crescente de manutenção a cada nova alteração.
Um estudo com 96 engenheiros do Google mediu redução de tempo em tarefas assistidas por IA, mas deixou claro que o ganho depende do contexto, da tarefa e da senioridade de quem está usando a ferramenta. Uma análise sobre Copilot em projetos reais encontrou ganho em documentação, testes e debugging, mas limitação clara em tarefas complexas, funções grandes e contexto proprietário, exatamente os cenários onde o software crítico costuma viver.
Ou seja: IA acelera, mas não substitui engenharia. Nunca substituiu.
O que é desenvolvimento assistido por IA
Desenvolvimento assistido por IA é uma abordagem em que a IA atua como parceira técnica, mas a responsabilidade sobre arquitetura, qualidade, segurança e manutenção continua sendo minha, do desenvolvedor.
Nesse modelo, uso a IA para explorar uma base de código existente, sugerir implementação, explicar trecho complexo, gerar teste unitário, revisar código, escrever documentação, propor refatoração, simular cenário de erro, gerar script de migração, apoiar debugging e automatizar tarefa repetitiva. A diferença central é que eu não saio do processo. Mudo de posição: em vez de escrever cada linha manualmente, atuo como arquiteto, revisor e responsável técnico pelo que é entregue.
A própria documentação do GitHub sobre o Copilot Chat descreve a ferramenta como interface para dúvida de código, conceito, caso de teste e depuração, e o GitHub também documenta agentes capazes de pesquisar um repositório, propor plano de implementação, alterar código em branch, melhorar cobertura de teste e abrir pull request para revisão humana. O ponto que sustento aqui é justamente esse: para revisão humana. Não para merge automático.
A diferença que realmente importa: responsabilidade
No vibe coding, a pergunta que orienta o trabalho costuma ser "funcionou na tela?". No desenvolvimento assistido por IA, a pergunta que eu faço em qualquer entrega é outra: funciona, é seguro, é testável, é observável, é sustentável, e eu consigo explicar essa decisão técnica para outra pessoa?
Código gerado por IA pode passar no primeiro teste visual e ainda assim estar longe de pronto para produção. Produção exige teste automatizado, revisão de segurança, análise de dependência, log, métrica, rastreabilidade, controle de custo e critério de manutenção. A própria documentação do GitHub sobre uso responsável do Copilot cita alucinação como risco conhecido de LLM e reforça a necessidade de revisão humana sobre qualquer saída gerada. Uma avaliação do Copilot Code Review encontrou falha na detecção de vulnerabilidade crítica, como SQL injection, XSS e desserialização insegura, o que confirma algo que já defendo há tempo: revisão automatizada por IA não substitui ferramenta dedicada nem auditoria humana.
Comparação direta
| Critério | Vibe coding | Desenvolvimento assistido por IA |
|---|---|---|
| Objetivo principal | Sair rapidamente da ideia para algo funcionando | Acelerar engenharia mantendo controle técnico |
| Papel da IA | Geradora principal da solução | Assistente ou par técnico supervisionado |
| Papel do humano | Descreve, executa, ajusta por tentativa e erro | Define arquitetura, revisa, testa, assume responsabilidade |
| Revisão de código | Baixa ou superficial | Obrigatória |
| Entendimento do código | Parcial ou inexistente | Necessário |
| Uso recomendado | Protótipo, MVP simples, ferramenta pessoal | Produto real, sistema crítico, software corporativo |
| Risco | Alto se for direto para produção | Controlado por processo técnico |
| Testes | Manual ou inexistente | Automatizado e integrado ao fluxo |
| Segurança | Frequentemente negligenciada | Parte obrigatória do processo |
| Manutenção | Tende a degradar com o tempo | Planejada desde o início |
| Governança | Baixa | Alta, com padrão, revisão e rastreabilidade |
Um exemplo que já vivi de perto: a tela de login
Peço para pensarmos num pedido comum: "crie uma tela de login com recuperação de senha".
No vibe coding, o prompt tende a ser direto e vago:
""Crie uma tela de login bonita com e-mail, senha, botão de entrar e link de recuperação. Use React e deixe moderno."
A IA gera o componente, a pessoa roda, cola o erro de volta quando algo quebra, pede ajuste visual, pede correção de botão. No final existe uma tela que parece funcionar. O que costuma ficar de fora, porque ninguém perguntou, é se a senha trafega em HTTPS, se existe proteção contra brute force, se o erro exposto não vaza informação sensível, se o token de recuperação expira, se o fluxo permite enumeração de usuário, se há rate limit, se os campos são acessíveis, se existe teste, se a lógica está separada entre UI, serviço e domínio, e se o fluxo respeita LGPD ou política interna de privacidade.
No desenvolvimento assistido por IA, o mesmo pedido fica assim:
""Implemente o fluxo de login em React seguindo a arquitetura existente. Separe componente visual, hook de estado e serviço de autenticação. Não armazene token em localStorage. Trate erro genérico para evitar enumeração de usuário. Crie teste unitário para validação de formulário e teste de integração para sucesso, credencial inválida e falha de rede. Antes de alterar, explique quais arquivos serão modificados."
A IA continua ajudando, mas dentro de um processo que eu defino. Estabeleço restrição, peço plano antes da execução, reviso o diff, valido teste, verifico segurança, e só então integro ao branch principal.
Onde vibe coding faz sentido
Defendo vibe coding sem ressalva quando o risco é baixo e o objetivo é aprender, explorar ou validar uma hipótese rápido: protótipo descartável, landing page experimental, automação pessoal, ferramenta interna sem dado sensível, simulação de interface, prova de conceito, aprendizado de biblioteca nova, boilerplate inicial, experimento de UX, validação rápida de hipótese de produto.
Nesses casos velocidade vale mais que robustez. O erro não é usar vibe coding aqui, o erro é confundir "funcionou no meu ambiente" com "está pronto para receber cliente pagante".
Onde o desenvolvimento assistido por IA é o único caminho aceitável
Sistema financeiro, autenticação e autorização, integração com API externa, processamento de dado sensível, produto SaaS, sistema com SLA, aplicação corporativa, pipeline de dado, agente de IA em produção, sistema multiusuário, qualquer software que afete operação, receita ou reputação. Nesses cenários uso IA o tempo todo, mas dentro de processo de engenharia.
A IA pode gerar a primeira versão de uma função, mas cabe a mim avaliar complexidade, legibilidade, efeito colateral, performance e segurança. Ela pode sugerir teste, mas alguém precisa validar se aquele teste cobre o risco correto. Ela pode revisar um pull request, mas a aprovação final continua sendo humana. Isso não é conservadorismo, é a diferença entre entregar software e entregar risco disfarçado de software.
O novo papel do desenvolvedor
Com IA no fluxo, meu valor como engenheiro deixou de estar em escrever código rápido. Passou a estar em formular problema, impor restrição, avaliar solução e sustentar sistema em produção. As habilidades que considero centrais hoje: escrever prompt técnico com contexto suficiente, decompor tarefa grande em etapa menor, fornecer exemplo e contraexemplo, revisar código gerado, identificar alucinação, validar dependência, exigir teste, medir custo e latência, avaliar impacto arquitetural, criar guardrail, documentar decisão, manter rastreabilidade.
A IA não elimina a engenharia. Ela aumenta a importância dela.
Trato a IA como um júnior extremamente rápido, não como um sênior invisível
A metáfora que uso com meus alunos é essa: a IA é um desenvolvedor júnior muito rápido, com boa memória contextual, mas sem responsabilidade real pelo negócio. Ela produz muito em pouco tempo, lembra API, padrão e sintaxe, sugere solução razoável. Mas também inventa, omite risco, gera código inseguro, ignora requisito implícito e propõe solução que parece elegante e não se sustenta na prática.
Por isso a pergunta certa nunca é "a IA consegue fazer?". A pergunta certa é: eu consigo revisar, explicar, testar, operar e manter o que a IA fez? Se a resposta for não, aquele código não vai para produção, ponto final.
Conclusão
Vibe coding e desenvolvimento assistido por IA fazem parte do mesmo movimento, a programação mediada por linguagem natural e modelo generativo. Mas não representam o mesmo nível de maturidade técnica, e tratá-los como sinônimos é o que gera a maior parte dos incidentes que vejo em projetos que tentaram pular etapa.
Vibe coding é excelente para exploração, aprendizado e prototipação rápida. Democratiza o acesso à criação de software. Desenvolvimento assistido por IA é engenharia de software usando IA como acelerador, onde a responsabilidade por arquitetura, segurança, teste, manutenção e observabilidade continua sendo minha.
A diferença não está em usar ou não usar IA. Está em como eu uso. Quando a IA gera código e ninguém entende, testa ou assume responsabilidade por ele, estou apenas acelerando a criação de dívida técnica. Quando a uso dentro de processo técnico, com revisão, critério, teste e governança, ela vira uma das ferramentas mais poderosas que já tive disponível como engenheiro.
O futuro do desenvolvimento não vai ser escolher entre humano ou IA. Vai ser saber combinar a velocidade da IA com julgamento técnico humano. Essa é a diferença entre codar na vibe e construir software de verdade com IA.
