Quando comecei a estudar o fenômeno batizado de "vibe lawyering", vindo do campo jurídico, meu primeiro impulso foi tratá-lo como uma curiosidade setorial, algo distante do dia a dia de quem constrói software. Engano meu. Quanto mais analisava os relatos de advogados usando modelos de linguagem para redigir petições sem verificar fontes, mais eu enxergava padrões familiares em sprints de desenvolvimento que já conduzi ou auditei. O termo descreve a prática de delegar decisões a IAs generativas com base apenas na "vibe" — na sensação de que a resposta parece correta, sem repertório técnico para validá-la. No mundo jurídico, isso já produziu jurisprudências fantasmas e citações de leis que nunca existiram. Na engenharia de software, o equivalente é igualmente perigoso: gerar código, arquiteturas ou testes sem compreender os fundamentos, confiando cegamente na fluência superficial do assistente de IA.
A falsa sensação de competência gerada por interfaces polidas
Existe um viés cognitivo que todo engenheiro experiente conhece bem: a fluência da interface influencia nossa percepção de confiabilidade. Quando uma IA generativa entrega uma resposta em linguagem natural, bem estruturada e com tom de autoridade, nosso cérebro tende a aceitá-la como verdadeira. É o mesmo mecanismo que nos faz confiar mais em um site bem desenhado do que em um portal amador, mesmo que o conteúdo do segundo seja mais preciso. A diferença é que, ao usar IA generativa em decisões técnicas, estamos terceirizando não apenas a tarefa, mas a responsabilidade pela validação. Já vi times inteiros adotarem bibliotecas sugeridas por assistentes de IA sem verificar se a licença era compatível com o projeto, ou se a vulnerabilidade reportada no CVE da semana anterior já havia sido corrigida naquela versão. A "vibe" da sugestão parecia boa, e ninguém parou para questionar.
O termo "vibe lawyering" destaca justamente essa armadilha: a confiança na aparência substitui a verificação sistemática. Em um dos casos que analisei em consultoria, uma equipe de backend aceitou a sugestão de uma IA para reescrever um microsserviço de pagamentos em uma linguagem que o time mal dominava, porque "o assistente gerou o código completo e parecia funcionar nos testes unitários". Seis semanas depois, o serviço entrava em produção com um bug de concorrência que só aparecia sob carga real, gerando duplicação de transações. A IA não tinha repertório contextual sobre o domínio financeiro, mas a equipe, seduzida pela resposta pronta, automatizou a própria imprudência.
O repertório como barreira técnica contra alucinações
A fonte que inspirou esta análise descreve o fenômeno de advogados que, ao delegarem tarefas de pesquisa e redação a IAs sem possuir repertório jurídico consolidado, acabam incorporando erros graves a documentos oficiais. No desenvolvimento de software, a situação é análoga. Um engenheiro júnior que usa IA para gerar consultas SQL complexas sem entender joins, índices e planos de execução está essencialmente fazendo "vibe development". A diferença é que, em vez de uma petição com lei falsa, o resultado é uma query que degrada o banco de produção quando o volume de dados cresce. O repertório — o conhecimento acumulado de princípios, padrões e experiências — é o único antídoto confiável.
Do ponto de vista de arquitetura de software, isso se traduz em uma regra prática que adoto em todos os projetos que lidero: o desenvolvedor precisa ser capaz de explicar, sem a IA, por que aquela solução é adequada, quais são suas alternativas e onde estão suas limitações. Se a resposta for "a IA sugeriu", o código não deve ir para revisão. É um critério severo, mas necessário. Modelos de linguagem não possuem intencionalidade nem entendem o contexto do seu sistema — eles aproximam padrões estatísticos. Confiar sem repertório é transformar a ferramenta em um oráculo, e oráculos não dão garantia de SLA.
Automatizar imprudência na camada de decisão técnica
Outro paralelo direto com o "vibe lawyering" está na automação de decisões arquiteturais. Há uma tendência crescente de usar assistentes de IA não apenas para escrever código, mas para projetar sistemas: sugerir tecnologias, definir topologias de deploy, escolher bancos de dados. Essas decisões têm consequências de longo prazo e envolvem trade-offs que um modelo generativo, por melhor que seja, não consegue ponderar adequadamente. O modelo não sabe se a equipe tem expertise em Kubernetes, se o orçamento permite instâncias reservadas na nuvem, ou se a latência aceitável pelo domínio do cliente exige um cache distribuído específico.
Em um projeto recente de reconstrução de plataforma, observei um líder técnico pedir à IA que comparasse bancos NoSQL para o novo sistema de catalogo de produtos. A resposta foi tecnicamente correta em linhas gerais, mas sugeriu uma tecnologia cujo driver oficial não tinha suporte maduro para a linguagem usada pelo time. A sugestão foi aceita de imediato, sem que ninguém verificasse a compatibilidade real. Isso é automatizar imprudência: usar a IA para encurtar o processo de decisão, mas eliminando justamente a etapa de validação que o repertório humano deveria garantir. A ferramenta deve acelerar a execução de tarefas bem compreendidas, não substituir a reflexão estratégica.
Privacidade e segurança: o perigo silencioso do conteúdo gerado sem verificação
No campo jurídico, o "vibe lawyering" já levou a violações éticas graves, como a inclusão de informações protegidas por sigilo em prompts de IAs públicas. No desenvolvimento de software, o risco se amplifica quando engenheiros colam trechos de código proprietário em ferramentas online para "debugging" ou "refatoração", sem considerar que o modelo pode incorporar esses dados ao treinamento ou expô-los em respostas futuras. Já vi casos em que chaves de API e strings de conexão com banco foram enviadas inadvertidamente para assistentes de IA. A violação de privacidade nesses cenários é muitas vezes irreversível.
Em relação à segurança, o problema é ainda mais sutil. Um código gerado por IA que parece seguro em uma varredura superficial pode conter vulnerabilidades lógicas que ferramentas automáticas de SAST não detectam. O repertório humano é indispensável para entender padrões de ataque específicos do domínio, como lógica de negócio que permite escalonamento de privilégios ou falhas em workflows de aprovação. Se o engenheiro delegar a criação dessas regras de segurança à IA sem compreender o contexto, ele está criando uma superfície de ataque invisível. A automatização da imprudência, nesse caso, não gera apenas bugs — gera brechas exploráveis.
O que aprendemos com a comparação entre advocacia e engenharia
O artigo que motivou esta reflexão acerta ao apontar que a IA generativa exige repertório prévio para ser usada com responsabilidade. Na engenharia de software, isso significa que a ferramenta deve ser empregada como um par sênior que sugere, mas não decide. Um engenheiro com repertório sabe quando ignorar a sugestão da IA porque ela viola um princípio de design, porque introduz uma dependência desnecessária, ou porque a solução embora funcione, não escala. Sem repertório, o engenheiro não tem critério para discriminar, e qualquer resposta fluente será aceita.
Minha recomendação editorial é clara: invista tempo na construção de fundamentos sólidos antes de delegar tarefas a IAs generativas. Estude algoritmos, padrões de projeto, modelos de concorrência, princípios de segurança. Use a IA para exercitar esses conceitos, não para evitá-los. O profissional que automatiza a imprudência está, no fundo, terceirizando seu próprio amadurecimento técnico. E, em um mercado que valoriza cada vez mais a capacidade crítica sobre a velocidade de entrega, esse é um risco que nenhum engenheiro pode correr.