Engenharia de Software com IA vs. Vibe Coding: por que processo importa mais do que nunca
Por André Souza | AI Engineer · Engenheiro de Software Sênior
Em fevereiro de 2025, Andrej Karpathy, ex-diretor de IA da Tesla e um dos fundadores da OpenAI, publicou uma reflexão que nomeou algo que o mercado já fazia há meses: o vibe coding.
A ideia é simples. Você abre o Claude Code, o Antigravity ou o OpenCode, digita a intenção, aceita o que a IA sugere sem questionar, e vai construindo por impulso. Em 48 horas, tem um “produto”. Em 72, já postou no LinkedIn com orgulho.
Funciona. Por um tempo.
O problema aparece seis meses depois, quando ninguém mais consegue adicionar uma feature sem quebrar três outras.
O que o vibe coding entrega (e o que esconde)
Tem uma analogia no livro “Engenharia de Software com Agentes Inteligentes”, de Sandeco Macedo, que resume bem: imagine que você contrata um pedreiro pra reformar a cozinha. Ele derruba as paredes certas, instala o revestimento, posiciona os armários e entrega tudo em uma semana. Você fica satisfeito.
Dois anos depois, resolve ampliar. Aí descobre que o pedreiro passou os fios elétricos sem conduite, misturou canos de água quente com fria sem identificação, e os armários foram parafusados direto na estrutura de sustentação do teto. Tecnicamente tudo funciona. Mas qualquer modificação vai custar o dobro e exigir demolir boa parte do que foi construído.
Isso é débito técnico na construção civil. No software, a história é igual. A parede que vai cair é digital e o custo aparece no sprint mais inoportuno possível.
Código gerado sem processo não é produto. É protótipo bem vestido.
O maior sintoma do vibe coding é a ausência de requisitos. Quando você não sabe o que o sistema precisa fazer de verdade, quem vai usar, em qual escala e com quais restrições, qualquer código que “pareça” fazer algo já satisfaz. A IA preenche os buracos com suposições razoáveis, e seis meses depois você descobre que essas suposições eram tudo menos razoáveis no contexto real do negócio.
Um exemplo real do livro: uma startup gerou por prompts sucessivos um sistema de gestão financeira. Em três semanas, o produto estava “pronto”. Seis meses depois, descobriram que o cálculo de impostos aplicava uma alíquota fixa, ignorando completamente o regime tributário de cada empresa. Nenhum teste cobria isso porque nenhum requisito tinha documentado isso. O custo de corrigir foi três vezes o custo de construir.
A crise que nunca foi resolvida
Em 1968, a OTAN reuniu cientistas em Garmisch, Alemanha, para discutir o que já acumulava vítimas: sistemas de software atrasando, estourando orçamento e falhando em produção de formas criativas. Daquela conferência nasceu o termo “crise do software” e com ele a ideia de que construir software é uma atividade de engenharia, não de inspiração.
Cinquenta e seis anos depois, o CHAOS Report 2020 do Standish Group registra que apenas 31% dos projetos de software são entregues no prazo, dentro do orçamento e com o escopo completo. Outros 50% chegam com restrições. 19% são cancelados. Esses números são quase idênticos aos de 1994.
Três décadas de avanço tecnológico. A taxa de sucesso quase não se moveu.
O que mudou foi a velocidade. Um projeto sem processo nos anos 70 levava meses para acumular débito técnico suficiente para se tornar intratável. Com agentes inteligentes gerando código na velocidade da digitação, esse mesmo nível de entropia pode ser atingido em dias.
O erro que mais vejo no mercado
O problema não é usar IA para escrever código. É usar IA para substituir o processo.
Um agente dentro de um processo estruturado, com requisitos definidos, testes automatizados e revisão humana consciente, é uma ferramenta de produtividade genuína. Um agente operado sem nenhuma dessas salvaguardas acelera o acúmulo de débito técnico. A diferença não está na ferramenta. Está em quem a usa e com qual método.
Dar um bisturi de última geração para alguém que nunca estudou medicina não melhora o resultado cirúrgico. O instrumento é excelente. O resultado, nem tanto.
O que a Engenharia de Software oferece
A definição clássica do IEEE diz que engenharia de software é “a aplicação de uma abordagem sistemática, disciplinada e quantificável ao desenvolvimento, operação e manutenção de software”. Cada palavra importa: sistemática significa que existe um método; disciplinada significa que o método é seguido, não só quando dá vontade; quantificável significa que é possível medir e melhorar.
E perceba o trecho final: “desenvolvimento, operação e manutenção”. O ciclo não termina na entrega. Ele continua enquanto o software estiver vivo, o que costuma ser muito mais tempo do que o time original esperava. Estudos históricos indicam que entre 60% e 80% do custo total de um sistema é gasto em manutenção: correção de bugs, adaptação a novos ambientes, adição de funcionalidades, refatoração de código que envelheceu mal.
Engenharia de software não é burocracia. É o que transforma a criação de software numa atividade controlada e previsível.
SDD + TDD na era dos agentes
Dois conceitos que todo AI Engineer precisa dominar:
Spec-Driven Development (SDD): antes de escrever uma linha de código, você escreve a especificação. Não um documento de cem páginas. Um conjunto compacto de quatro arquivos:
- PRD.md: por que o sistema existe, para quem e qual o critério de sucesso.
- ARCHITECTURE.md: como os componentes se organizam e por que, com as decisões registradas.
- API_SPEC.md: o contrato técnico. Cada endpoint, método, formato de entrada e saída.
- RULES.md: invariantes de domínio que não podem ser violadas.
Cerca de quarenta linhas no total. Nenhuma linha de código. E qualquer agente moderno tem contexto suficiente para gerar a aplicação inteira, incluindo testes, numa única passada. A spec define. O código executa. O agente é o operário, não o arquiteto.
Test-Driven Development (TDD): você escreve o teste antes de escrever o código. O ciclo tem três fases:
- Red: escreve um teste que descreve um comportamento ainda inexistente. Confirma que ele falha. Essa falha é importante porque ela prova que o teste mede algo real.
- Green: implementa a menor quantidade possível de código para o teste passar. Sem elegância precoce, sem generalização.
- Refactor: com o teste passando, limpa o código, melhora os nomes, extrai funções. Os testes garantem que qualquer regressão aparece na hora.
Com IA no ciclo, o papel do humano sobe um nível. Em vez de digitar testes à mão, você define a intenção em forma de spec. O agente traduz essa intenção em casos de teste executáveis, implementa o código mínimo que faz esses testes passarem e refatora sem quebrar a suíte. O humano não some do circuito: ele revisa e valida os testes gerados, porque um teste errado contamina tudo que vem depois.
O que sobra pro humano fazer
Se a IA escreve o código, o que sobra? Sobra o que importa. Cinco responsabilidades que nenhum agente absorve:
Definir intenção. O agente não sabe por que o sistema existe. Ele não esteve nas reuniões com o cliente, não viu o problema do usuário em campo. Quem traduz desejo em spec é o humano.
Desenhar arquitetura. Escolher entre monolítico e microsserviços, entre SQL e arquivos, entre síncrono e assíncrono. Essas escolhas têm consequência de cinco anos.
Impor restrições. Limites de segurança, requisitos regulatórios, contratos de SLA: tudo isso entra na spec como restrições explícitas, escritas pelo humano e respeitadas pelo agente.
Validar entregas. O teste verifica se o código respeita a spec. O humano verifica se a spec respeita a realidade.
Governar o ciclo. Decidir o que entra na próxima sprint, como o time evolui, qual stack vale a pena trocar. Governança é trabalho humano por definição.
Tem uma frase do livro que resume bem: “SDD escreve a partitura. TDD afina a orquestra. A IA toca os instrumentos. O humano é o regente.”
A escolha que o mercado vai cobrar
O desenvolvedor que aprende a escrever spec, a desenhar testes e a supervisionar agentes fica mais valioso, não menos. Quem domina esse ciclo entrega o trabalho de uma equipe inteira em fração do tempo. Quem continua tentando competir com a IA na digitação de código está jogando um jogo que a IA joga melhor por construção.
A diferença entre o vibe coder e o AI Engineer é prática: o vibe coder está reconstruindo pela terceira vez um sistema que nunca foi especificado direito, respondendo ticket de bug às onze da noite. O AI Engineer já entregou, testou, documentou e está evoluindo a próxima versão.
Para fechar
O vibe coding tem seu lugar. Para explorar uma ideia rapidamente, validar uma hipótese, construir um protótipo descartável, ele é genuinamente útil. O erro não está em usar IA para gerar código. Está em confundir o protótipo com o produto, o rascunho com a entrega.
O profissional que o mercado vai buscar nos próximos anos não é o que digita mais rápido. É o que pensa com precisão suficiente para guiar agentes com contexto.
Este artigo é baseado nos conceitos do livro “Engenharia de Software com Agentes Inteligentes” (2026), de Sandeco Macedo, combinados com a prática real de desenvolvimento de agentes em produção.
Você já enfrentou as consequências do vibe coding num projeto? Me conta nos comentários.
André Souza Engenheiro de Software Sênior · AI Engineer