Notas de Engenharia

Code Smells para Agentes de IA: A Infraestrutura que Você Já Tem É a Governança que Faltava

TV
Thiago Victorino
11 min de leitura

Eno Reyes, cofundador da Factory, deu uma entrevista ao Stack Overflow está semana sobre “code smells para agentes de IA”. A conversa toca em pontos importantes — qualidade de codebase como pré-requisito para produtividade com IA, sinais de validação como camada de governança, a disciplina emergente de “harness engineering”. Mas a entrevista também faz o que entrevistas de fundadores costumam fazer: apresenta uma narrativa conveniente para o produto da empresa.

O que segue não é uma crítica à Factory. É uma tentativa de separar os insights reais — e eles existem — das premissas que merecem escrutínio.

O Dado que Importa

O estudo de Stanford liderado por Yegor Denisov-Blanch, analisando mais de 100.000 desenvolvedores em mais de 600 empresas, chegou a uma conclusão que deveria ser manchete: qualidade do codebase é o preditor mais forte de ganhos de produtividade com IA. Não o volume de código gerado, não a taxa de adoção de ferramentas, não a densidade de agentes por equipe. A qualidade da base existente.

Reyes cita esse dado na entrevista. Mas o estudo de Stanford diz mais do que ele menciona.

A pesquisa mostrou que IA impulsiona tarefas simples em projetos greenfield entre 30% e 40%. Até aqui, a narrativa otimista se sustenta. Mas para codebases maduros e complexos — exatamente o tipo que a maioria das organizações mantém — o ganho cai para algo entre 0% e 10%. E o dado mais incômodo: a manutenibilidade do código caiu 9% com o uso de IA.

Nove por cento. O código gerado por IA é, em média, menos manutenível que o código que substitui.

Isso não invalida o uso de IA em engenharia. Mas inverte a narrativa dominante. A promessa é “IA acelera tudo”. A realidade é “IA acelera tarefas triviais e pode degradar o que não é trivial”.

A Espiral que Ninguém Menciona

Se qualidade do codebase determina a eficácia da IA, e o uso de IA reduz a manutenibilidade do código, temos um loop de feedback negativo que merece atenção.

O ciclo funciona assim: IA gera código de qualidade inferior em manutenibilidade. Código menos manutenível degrada a qualidade geral do codebase. Codebase degradado reduz a eficácia da IA. IA menos eficaz gera código ainda pior. Repita.

Nenhum slide de produto vai mostrar esse diagrama. Mas ele é consequência direta dos dados que a própria pesquisa de Stanford apresenta.

A quebra desse ciclo não vem de agentes mais inteligentes. Vem de infraestrutura de qualidade — linters, verificadores de tipo, suítes de teste, scanners de segurança — que intercepta a degradação antes que ela se acumule. A mesma infraestrutura que bons times de engenharia construíram por décadas, por razões que não tinham nada a ver com IA.

O Gap de Percepção

O estudo da METR, publicado em julho de 2025, adiciona uma camada de complexidade que torna a discussão ainda mais delicada.

Pesquisadores mediram o desempenho de desenvolvedores experientes com e sem ferramentas de IA. Resultado: desenvolvedores com IA foram 19% mais lentos. Não mais rápidos. Mais lentos.

Mas quando perguntados, esses mesmos desenvolvedores estimaram que a IA os havia acelerado em 20%.

Releia esses números. Um gap de quase 40 pontos percentuais entre percepção e realidade. Desenvolvedores que acreditavam estar voando estavam, na verdade, rastejando — em termos relativos.

Isso não significa que IA é inútil. Significa que a sensação subjetiva de produtividade com IA é um indicador perigosamente não confiável. E significa que organizações que medem adoção de IA por satisfação do desenvolvedor — “nosso time adora a ferramenta!” — podem estar medindo o equivalente a um placebo.

Cem Estagiários e Uma Premissa Escondida

Reyes usa uma analogia na entrevista que é instrutiva tanto pelo que revela quanto pelo que esconde. Ele compara agentes de IA a contratar cem engenheiros nível estagiário. A conclusão implícita: você precisa de infraestrutura de supervisão proporcional.

A analogia é útil até certo ponto. Estagiários precisam de code review, linters detectam erros comuns, testes automatizados capturam regressões. Tudo verdade.

Mas a analogia contrabandeia uma premissa: que o problema é apenas de supervisão. Que se você supervisionar bem, os estagiários produzem valor líquido positivo.

A evidência sugere algo mais complicado. Estagiários aprendem. Agentes de IA, no estado atual, não retêm aprendizado entre sessões. Estagiários desenvolvem julgamento contextual ao longo do tempo. Agentes operam com a mesma janela de contexto limitada, sessão após sessão. Estagiários eventualmente se tornam seniores. Agentes permanecem estagiários.

A diferença não é semântica. É econômica. O investimento em supervisão de estagiários tem retorno composto — cada hora investida hoje reduz a necessidade de supervisão amanhã. O investimento em supervisão de agentes tem retorno constante — a mesma hora de supervisão será necessária na próxima sessão, e na seguinte.

Isso não significa que agentes não valem o investimento. Significa que o modelo econômico é diferente do que a analogia sugere, e que organizações precisam precificar essa diferença.

Harness Engineering: O Conceito Certo, a Atribuição Errada

Reyes apresenta “harness engineering” como uma disciplina que a Factory está definindo. A ideia é genuinamente importante: a engenharia de conexão entre agentes de IA e ambientes de desenvolvimento reais — gerenciamento de contexto, injeção de informação ambiental, orquestração de chamadas de ferramentas.

Mas o conceito não nasce na Factory. A Anthropic documenta padrões de harness engineering em sua documentação de agentes. Aakash Gupta e Phil Schmid discutem a disciplina em publicações independentes. É um conceito emergente da indústria, não uma inovação de um vendor específico.

Reconhecer a origem correta importa porque a implicação muda. Se harness engineering é uma inovação proprietária, a conclusão é “compre nosso produto”. Se é uma disciplina emergente da indústria, a conclusão é “desenvolva essa competência internamente”.

A segunda conclusão é mais incômoda para quem vende ferramentas. E mais útil para quem as compra.

Sinais de Validação como Governança

A parte mais valiosa da conversa de Reyes é sobre sinais de validação — a ideia de que compilação bem-sucedida, conformidade com linters, passagem de testes, completude de documentação e métricas de complexidade formam uma camada de governança para agentes de IA.

O que torna isso valioso não é a novidade. É o reframing. Essas ferramentas existem há décadas. Linters existem desde os anos 1970. Verificadores de tipo, desde os anos 1980. Suítes de teste automatizadas, desde os anos 1990. Scanners de segurança, desde os anos 2000.

O insight é que essas ferramentas, construídas para governar código humano, são exatamente o que governa código de IA. Organizações que investiram em disciplina de engenharia por décadas agora descobrem que estavam construindo infraestrutura de governança de IA antes da IA existir.

A Gartner prevê que mais de 40% dos projetos de IA agêntica serão cancelados até 2027 por falta de governança. A ironia é que a governança necessária — pelo menos a camada técnica — já existe na maioria das organizações com maturidade de engenharia. Não precisa ser inventada. Precisa ser reconhecida.

O Que Isso Significa na Prática

A conversa sobre agentes de IA está dominada por duas narrativas concorrentes. A primeira: agentes vão revolucionar a engenharia de software. A segunda: agentes são hype que não entrega valor real.

Ambas estão erradas. A realidade é mais específica e menos dramática.

Agentes aceleram o trivial e arriscam degradar o complexo. Os dados de Stanford são inequívocos nesse ponto. Se sua organização gera predominantemente código greenfield simples, agentes provavelmente ajudam. Se mantém codebases maduros e complexos, o ganho é marginal e o risco de degradação de qualidade é real.

A infraestrutura de qualidade é a variável de controle. Não o modelo de IA, não o vendor, não o pricing. Linters, verificadores de tipo, testes automatizados, scanners de segurança — essas ferramentas determinam se agentes produzem valor ou amplificam dívida técnica. Se você não tem essa infraestrutura, comprar agentes é acelerar na direção errada.

A percepção de valor é não confiável. O gap de quase 40 pontos da METR significa que “o time gostou” não é evidência de produtividade. Meça resultados objetivos: tempo de ciclo, taxa de defeitos, manutenibilidade do código ao longo do tempo. Se você não mede, não sabe.

A governança já existe — se você a construiu. Organizações com décadas de investimento em disciplina de engenharia têm uma vantagem que não aparece em nenhum relatório de analista: a infraestrutura de governança que agentes de IA necessitam já está instalada. A questão não é “que ferramenta de governança comprar”, mas “como conectar o que já temos ao novo fluxo de trabalho”.

Não É Sobre Ferramentas Novas

A tentação é comprar algo. Um produto de harness engineering. Uma plataforma de sinais de validação. Um agent orchestrator com dashboard bonito.

A tentação é compreensível. Comprar é mais fácil que construir disciplina. Um contrato é mais tangível que uma mudança de cultura de engenharia.

Mas a evidência aponta na direção oposta. O preditor mais forte de sucesso com IA não é qual ferramenta você comprou. É qual infraestrutura você já construiu. Cobertura de testes. Conformidade com linters. Type safety. Documentação atualizada. Pipeline de CI/CD que bloqueia código abaixo do padrão.

Se você já tem isso, está mais preparado para agentes de IA do que imagina. Se não tem, nenhum produto vai compensar a lacuna.

A disciplina de engenharia que parecia apenas “boa prática” por décadas revelou-se, retroativamente, a fundação de governança para uma era que ninguém previu. E as organizações que a negligenciaram estão descobrindo que o custo não é apenas dívida técnica — é incapacidade de operar a próxima geração de ferramentas.

Não é sobre comprar ferramentas novas. É sobre reconhecer o valor das que você já tem.


Fontes

  • Yegor Denisov-Blanch et al. Estudo Stanford sobre produtividade com IA. 100.000+ desenvolvedores, 600+ empresas. 2025-2026.
  • METR. Estudo sobre impacto de ferramentas de IA em desenvolvedores experientes. Julho 2025.
  • Gartner. Previsão sobre cancelamento de projetos de IA agêntica por falta de governança. 2025.
  • Eno Reyes. “Code Smells for AI Agents: Q&A.” Stack Overflow Blog. Fevereiro 2026.
  • Anthropic. Documentação sobre padrões de harness engineering para agentes.

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa