Engenharia Agêntica: Por Que o Nome Que Você Dá ao Desenvolvimento com IA Importa

Addy Osmani publicou esta semana um artigo que deveria ser leitura obrigatória para qualquer líder de tecnologia. Não pelo conteúdo técnico — que é sólido — mas por uma decisão que parece menor do que realmente é: a escolha do nome.

Ele distingue “vibe coding” de “engenharia agêntica”. E essa distinção não é estética. É infraestrutura organizacional.

O Problema Não É a Ferramenta — É o Vocabulário

Quando Andrej Karpathy cunhou “vibe coding” no início de 2025, descreveu algo real: programar seguindo a intuição, aceitando o que a IA gera, iterando por tentativa e erro. É desenvolvimento por vibração — sem revisão, sem testes, sem responsabilidade formal sobre o resultado.

A descrição era honesta. E justamente por isso, perigosa como modelo organizacional.

“Vibe coding” não cria estruturas. Não define quem revisa. Não estabelece quem responde quando o sistema falha. Não produz descrições de cargo, não gera processos de qualidade, não alimenta indicadores.

“Engenharia agêntica” faz tudo isso. Não porque a palavra seja mágica — mas porque ela carrega expectativas de engenharia. Engenharia pressupõe método, revisão, responsabilidade. Quando você diz que sua equipe faz “engenharia agêntica”, imediatamente surgem perguntas: qual o processo de revisão? Quem valida a arquitetura? Como medimos qualidade?

Quando você diz que sua equipe faz “vibe coding”, a única pergunta é: funciona?

Onde o Vibe Coding Funciona (e Onde Mata)

Osmani é honesto ao reconhecer os contextos legítimos do vibe coding: MVPs em hackathons, scripts pessoais, exploração de tecnologias novas, prototipagem criativa. São contextos onde o custo do erro é baixo e a velocidade importa mais que a durabilidade.

O problema é quando essa prática migra para código de produção sem mudar de nome — e, portanto, sem mudar de governança.

É como a diferença entre cozinhar em casa e operar uma cozinha industrial. Na sua casa, você pode improvisar com o que tem na geladeira. Numa cozinha que serve centenas de pessoas, improvisação sem protocolo é um risco sanitário. Não é que improvisar seja errado — é que o contexto exige estrutura.

Em empresas brasileiras, vejo essa migração acontecer com frequência. Um desenvolvedor descobre que o Claude ou o Cursor aceleram seu trabalho. Começa a usar informalmente. Outros copiam. Em semanas, metade da equipe está gerando código com IA sem nenhum processo de revisão adaptado, sem testes específicos para código gerado, sem clareza sobre quem é responsável pelo resultado.

Ninguém decidiu que isso era aceitável. Simplesmente não tinha nome — e o que não tem nome não tem governança.

O Workflow Que Osmani Propõe

O framework de engenharia agêntica que Osmani descreve tem quatro pilares:

Planeje antes de pedir. Escreva um documento de design ou uma especificação antes de abrir o prompt. A qualidade da entrada determina a qualidade da saída. Isso não é novo — é engenharia de requisitos adaptada para um novo executor.

Dirija e revise. Trate o agente de IA como um desenvolvedor júnior talentoso mas inconsistente. Revise cada saída com o mesmo rigor que você aplicaria a um pull request de um colega novo. A tentação de aceitar sem ler é proporcional à velocidade de geração — e inversamente proporcional à segurança do resultado.

Teste implacavelmente. Suítes de teste abrangentes transformam agentes não confiáveis em sistemas confiáveis. Sem testes, você está delegando sem verificação. Com testes, você está delegando com rede de segurança.

Assuma a propriedade do código. Mantenha documentação, controle de versão e monitoramento em produção. O código que a IA gerou é seu código. Se falhar às três da manhã, é seu problema.

Nenhum desses pilares é revolucionário isoladamente. Juntos, formam algo que falta na maioria das organizações: um processo explícito para desenvolvimento assistido por IA.

A Assimetria de Senioridade

Um dos pontos mais importantes — e menos confortáveis — do argumento de Osmani é sobre quem se beneficia da engenharia agêntica.

Engenheiros seniores se beneficiam desproporcionalmente. Eles sabem o que pedir, sabem avaliar o que recebem, sabem quando o agente está errado mesmo que o código compile. Têm repertório para detectar erros conceituais sutis — o tipo de erro que a IA comete com mais frequência à medida que fica melhor em erros sintáticos.

Engenheiros juniores correm risco de atrofia de habilidades. Osmani alerta para a possibilidade de criar uma geração de desenvolvedores que sabem pedir mas não sabem depurar. Que conseguem gerar código mas não conseguem entender por que ele falha.

O estudo do METR, de 2025, oferece um dado que reforça essa preocupação: desenvolvedores experientes usando ferramentas de IA foram 19% mais lentos em tarefas que já dominavam — mas acreditavam estar 20% mais rápidos. A percepção de produtividade divergia da realidade medida.

Isso não invalida a IA como ferramenta. Mas invalida a suposição de que mais ferramenta automaticamente significa mais produtividade. A variável mediadora é competência do operador — e essa competência precisa ser desenvolvida, não assumida.

O Insight Que Osmani Não Articulou

Osmani constrói o argumento técnico com rigor. Mas há uma camada organizacional que ele toca sem desenvolver — e que, para líderes empresariais, é talvez a mais relevante.

O nome que você dá à prática define a estrutura que a organização constrói ao redor dela.

“Vibe coding” é uma atividade individual. Não cria papéis. Não gera processos. Não alimenta métricas. É como chamar o trabalho de análise de dados de “brincar com planilhas” — tecnicamente pode descrever o que acontece, mas não produz governança.

“Engenharia agêntica” é uma disciplina organizacional. Cria a necessidade de:

Papéis definidos: Quem arquiteta? Quem revisa código gerado? Quem mantém os prompts de sistema?
Processos de qualidade: Como validamos saídas de agentes? Qual o critério de aceitação?
Gates de governança: Que tipo de código pode ser gerado por IA? Que tipo exige revisão humana obrigatória?
Métricas de desempenho: Como medimos a eficácia da assistência por IA além da percepção subjetiva?
Descrições de cargo: “Engenheiro agêntico” é um papel que RH entende. “Vibe coder” não é.

Essa é a diferença entre adoção informal e adoção governada. E é exatamente o padrão que vemos repetidamente em IA empresarial: o gap entre capacidade e governança. As ferramentas estão prontas. As organizações, na maioria dos casos, não.

O Vocabulário Como Indicador de Maturidade

Simon Willison argumentou, em março de 2025, que código gerado por IA que é revisado e testado é simplesmente desenvolvimento de software — não precisa de nome especial. Ele tem razão no sentido técnico. Mas está errado no sentido organizacional.

Nomes importam porque criam categorias. Categorias criam expectativas. Expectativas criam processos. Processos criam resultados.

Uma organização que chama sua prática de “vibe coding” está sinalizando — para si mesma e para o mercado — que trata IA como experimento informal. Uma organização que chama de “engenharia agêntica” está sinalizando que integrou IA ao seu processo de engenharia com disciplina e intencionalidade.

Kent Beck, em seu ensaio “Programming Deflation” de setembro de 2025, aplicou o paradoxo de Jevons à produção de código: quando escrever código fica mais barato, a demanda por código aumenta — mas a demanda por código de qualidade aumenta ainda mais rápido. A deflação do custo de produção não reduz a necessidade de engenharia. Amplifica-a.

Isso é precisamente o que a terminologia organiza. Em um mundo de código abundante e barato, a governança sobre esse código é o diferencial competitivo. E governança começa com vocabulário.

O Que Fazer Com Isso

Se você lidera uma equipe de tecnologia no Brasil, três ações concretas:

Primeiro, nomeie a prática. Pare de chamar de “usar IA para programar”. Defina se sua equipe faz vibe coding (aceitável para protótipos) ou engenharia agêntica (necessário para produção). A distinção força clareza.

Segundo, crie o processo de revisão. Código gerado por IA precisa de revisão adaptada. Não é o mesmo que revisar código humano — os erros são diferentes, os padrões são diferentes, as armadilhas são diferentes. Invista em treinar seus revisores para os modos de falha específicos de código gerado por agentes.

Terceiro, meça além da percepção. O dado do METR é um alerta: a percepção de produtividade com IA pode divergir significativamente da realidade. Estabeleça métricas objetivas — tempo de ciclo, taxa de defeitos, retrabalho — antes de concluir que a IA está tornando sua equipe mais produtiva.

O nome que você escolhe para o desenvolvimento assistido por IA não é uma questão de semântica. É uma decisão de arquitetura organizacional. E como toda decisão de arquitetura, ela determina o que é possível construir em cima dela.

Fontes

Addy Osmani. “Agentic Engineering.” addyosmani.com, fevereiro 2026.
Andrej Karpathy. Cunhou o termo “vibe coding”. X/Twitter, 2025.
Simon Willison. “If it’s tested and reviewed, it’s software engineering.” simonwillison.net, março 2025.
METR. “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” metr.org, 2025.
Kent Beck. “Programming Deflation.” tidyfirst.substack.com, setembro 2025.