Precisamos Parar de Chamar Tudo de Vibe Coding

Voltei a programar após uma longa pausa, e o Lovable foi onde retomei. Os aplicativos pareciam ótimos, funcionavam à primeira vista e eram montados em poucas horas. No início, isso parecia notável. Mas deixou de ser suficiente no momento em que quis saber o que o código estava fazendo – e por quê. Foi então que minha abordagem começou a mudar.

A diferença não está na ferramenta, nem na quantidade de código que a IA escreve para você. Trata‑se do contrato que você aceita com sua saída: se pode explicar o que acabou de lançar ao mundo, ou não.

Vibe coding, em seu sentido original, significa aceitar software gerado por IA sem examinar ou entender adequadamente o que está por baixo dele. O desenvolvimento assistido por IA é diferente. O modelo ainda pode escrever a maior parte do código, mas a pessoa que constrói o sistema continua responsável por entender seu comportamento, testar suas suposições e decidir se está pronto para ser entregue.

Para um experimento descartável que nunca sai da sua própria máquina, a distinção pode ter poucas consequências. Uma vez que o software é implantado, usado por outros ou conectado a dados reais, isso passa a importar enormemente.

Como o “Vibe Coding” perdeu seu significado

A expressão “vibe coding” foi criada em fevereiro de 2025 por Andrej Karpathy, cofundador da OpenAI. Seu exemplo era deliberadamente casual: um “projeto descartável de fim de semana” construído clicando automaticamente em “Aceitar tudo”, ignorando as diferenças e deixando o código crescer além de sua compreensão.

Semanas depois, o desenvolvedor e criador de ferramentas Simon Willison percebeu que a expressão estava sendo usada de maneira muito diferente: como substituto para qualquer programação assistida por IA, o que, segundo ele, dilui o termo e cria uma impressão falsa do que o desenvolvimento responsável assistido por IA pode alcançar.

É revelador que Karpathy tenha acabado concordando. Um ano depois, ele apresentou um termo diferente para o trabalho mais disciplinado com agentes de programação. Ele descreveu “engenharia agêntica” como um fluxo em que desenvolvedores dirigem e supervisionam agentes, em vez de simplesmente aceitar o que produzem. A distinção importa: o desenvolvimento profissional assistido por IA exige planejamento, análise e responsabilidade de formas que o vibe coding casual não exige.

A linha é responsabilidade

A regra de Willison é simples e funciona como teste para qualquer pessoa: não faça commit de código que você não consegue explicar a outra pessoa. Isso não significa ler cada linha; com agentes gerando centenas de linhas de uma vez, nem desenvolvedores experientes fazem mais isso. Significa compreender a lógica central e conseguir justificar exatamente por que o código faz o que faz. Se você consegue, não importa se foi um modelo ou você quem escreveu: isso não é vibe coding, mas o uso de uma ferramenta para construir software.

Uma pesquisa publicada em dezembro de 2025 sustenta essa distinção. Com base em observações de campo e em uma pesquisa qualitativa com desenvolvedores profissionais, os pesquisadores constataram que profissionais experientes mantinham o controle do projeto e da implementação do software, em vez de entregar todo o processo à IA. Eles tratavam os agentes como colaboradores, planejavam cuidadosamente o trabalho e continuavam envolvidos na supervisão.

Portanto, a experiência por si só não explica a diferença. A questão é estar disposto ou não a assumir responsabilidade pelo que a IA gerou. Todo desenvolvedor toma novamente essa decisão em cada projeto.

O que acontece quando o controle está ausente

As consequências de lançar software sem compreender nem verificar sua segurança não são abstratas. Tea, um aplicativo criado para ajudar mulheres a permanecer seguras durante encontros, expôs dezenas de milhares de fotos de identidade e mais de um milhão de mensagens privadas em dois incidentes de segurança. As falhas incluíram um bucket de armazenamento sem proteção e um banco de dados separado acessível sem autenticação.

O mesmo problema fundamental — software que parecia funcionar enquanto sua lógica de autorização permanecia perigosamente errada — apareceu em um aplicativo criado na plataforma Lovable: uma pesquisa de segurança descobriu que a lógica de autorização estava invertida, bloqueando usuários autenticados enquanto permitia livre acesso a invasores não autenticados. Mais de 18 mil usuários, inclusive estudantes, foram afetados.

Esses não são casos isolados que acontecem apenas em projetos “ruins”. Segundo Google’s 2025 DORA report, 90% dos desenvolvedores já usam IA no trabalho, enquanto cerca de um terço relata pouca ou nenhuma confiança no que ela gera.

O uso de IA já é generalizado, embora a confiança continue limitada. Isso torna a revisão cuidadosa especialmente importante quando o código gerado lida com autenticação, permissões ou dados sensíveis.

O controle é construído em camadas, não de uma só vez

No meu caso, não comecei com uma auditoria formal de segurança. Simplesmente me recusei a avançar sempre que não conseguia explicar por que algo se comportava de determinada maneira — um instinto natural que levo ao trabalho como analista. Preocupo-me menos com a sintaxe do que com a correspondência entre o resultado e a necessidade original. Quando não corresponde, continuo investigando.

Meu fluxo de trabalho ficou mais estruturado à medida que os projetos se tornaram mais sérios. Em vez de depender somente de prompts, passei a preparar especificações antes de gerar qualquer coisa. Documentei requisitos de negócio, pilha tecnológica e integrações. Depois vieram testes unitários e testes Playwright para as principais jornadas do usuário.

As verificações de segurança foram acrescentadas de maneira semelhante. Revisei as bibliotecas escolhidas pela IA e adotei varredura antimalware para arquivos enviados. Cada controle nasceu da pergunta sobre o que poderia dar errado em seguida, em vez de uma lista de controles preparada no início.

Esse hábito detectou um problema em um projeto. A IA introduziu uma biblioteca incompatível com a versão do framework que eu utilizava. O aplicativo não havia falhado completamente, então a incompatibilidade poderia facilmente ter passado despercebida. Descobri-la mais tarde teria tornado a causa muito mais difícil de identificar.

Comparado aos casos Tea e Lovable, era um problema comum. Eu o encontrei cedo, corrigi e segui adiante. É assim que a revisão geralmente funciona na prática. Na maior parte do tempo, ela impede que problemas pequenos se tornem maiores.

Não desconfio do código apenas porque foi produzido por IA. Também não confio nele apenas porque o aplicativo funciona. Testes e revisão são como verifico se ele se comporta conforme o esperado.

Do Vibe Coding à Engenharia Agencial

A própria mudança de Karpathy de “vibe coding” para “engenharia agêntica” não é apenas uma troca de vocabulário. “Engenharia agêntica” oferece um nome mais útil para a direção do desenvolvimento profissional. Os desenvolvedores podem escrever menos linhas diretamente, mas isso não reduz sua responsabilidade. O trabalho muda para especificar o que o sistema deve fazer, dirigir agentes, testar os resultados e decidir o que é seguro lançar.

O perigo não é que a IA gere código rapidamente. É que a geração pode avançar mais rápido que a compreensão. Quando isso acontece, a aparente produtividade oculta riscos que ninguém examinou adequadamente.

Uma regra que vale a pena manter

Pare de usar “vibe coding” como rótulo para toda forma de desenvolvimento assistido por IA: isso dilui o termo e apaga uma diferença importante de controle. Adote uma regra simples: não lance o que não consegue explicar. E incorpore controles à medida que o projeto cresce, camada por camada, acrescentando verificações de acordo com os riscos que surgem.

A IA pode escrever a maior parte do código. Não pode assumir a responsabilidade por lançá-lo. Essa responsabilidade continua sendo nossa.