O gargalo que ninguém conta sobre agentes de IA no código
Quem acompanha o universo do desenvolvimento de software já sabe que agentes de IA capazes de escrever código em velocidade absurda deixaram de ser promessa faz tempo. O que pouca gente discute abertamente é o que acontece depois que esse código é gerado. Na maioria das empresas, o resultado simplesmente não sobrevive ao contato com a realidade: quebra padrões de engenharia internos, falha em verificações de compliance, ignora convenções de arquitetura e, no final do dia, gera mais retrabalho do que economia real. É como ter um estagiário extremamente rápido que entrega tudo fora do padrão — você gasta mais tempo revisando do que gastaria fazendo do zero.
Stephen Newman, líder global de engenharia de tecnologia para clientes da EY, resumiu bem o problema. Segundo ele, é possível gerar toneladas de código, mas isso não significa muita coisa se o resultado não for integrável, não estiver em compliance e acabar criando mais trabalho na retaguarda só porque o processo de geração foi acelerado na ponta. Esse é o tipo de armadilha que pega muitas empresas de surpresa: a ilusão de velocidade que, na prática, só empurra o gargalo para outra etapa do fluxo.
A EY, uma das maiores consultorias do planeta, decidiu encarar esse problema de frente. E o que o time liderado por Newman conseguiu entregar merece atenção de qualquer organização que trabalha com tecnologia em escala. Ao realizar a integração dos agentes de código diretamente aos repositórios, frameworks de compliance e padrões de engenharia já existentes na empresa, as equipes responsáveis por construir plataformas de auditoria, impostos e finanças alcançaram ganhos de produtividade entre 4x e 5x. Não estamos falando de métricas de laboratório ou provas de conceito isoladas — são resultados medidos em times reais, trabalhando em produtos reais, entregando para clientes reais.
Mas é importante deixar claro desde já: nada disso aconteceu da noite para o dia. O caminho até esses números envolveu entre 18 e 24 meses de construção que foi tanto cultural quanto técnica. Passou por adoção orgânica de ferramentas assistivas, escolha criteriosa de plataforma e, talvez o mais importante, uma transformação genuína no papel dos desenvolvedores dentro da organização.
Da assistência à orquestração: como a EY construiu o caminho
O primeiro passo da jornada da EY não foi sair implementando agentes de IA autônomos em todos os projetos. Na verdade, foi quase o oposto disso. A empresa começou com ferramentas no estilo GitHub Copilot, deixando que os engenheiros se acostumassem com prompt engineering e com o uso de IA assistiva no dia a dia. Essa fase inicial foi fundamental para criar familiaridade com a tecnologia e, principalmente, para que a adoção acontecesse de forma orgânica.
Newman foi enfático nesse ponto: o aprendizado mais valioso foi entender que levar as capacidades de IA como uma adoção de baixo para cima funciona muito melhor do que impor ferramentas de cima para baixo. Quando os desenvolvedores sentem que estão escolhendo usar a tecnologia — em vez de sendo forçados —, o engajamento e a qualidade do uso aumentam drasticamente.
Durante esse período, o time de engenharia mapeou quais atividades consumiam mais tempo, quais tipos de erro eram mais recorrentes e onde a intervenção humana realmente agregava valor versus onde era apenas burocracia operacional. Esse diagnóstico prático, feito com dados reais do dia a dia, foi o que permitiu dar o salto seguinte com segurança. Os desenvolvedores queriam ir além da simples geração de código — queriam avançar para construção, deployment e operacionalização. Mas os ganhos de produtividade atingiram um platô sem uma integração mais profunda.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
A virada de chave aconteceu quando Newman percebeu que os agentes precisavam de acesso ao que ele chama de universo de contexto: os repositórios de código da empresa, os padrões de engenharia e os catálogos de recursos internos. Sem esse contexto, os agentes produziam outputs genéricos que exigiam retrabalho extensivo. A integração não foi superficial. Os agentes passaram a consultar automaticamente as bibliotecas internas aprovadas, respeitar as convenções de nomenclatura, aplicar as regras de segurança exigidas pelo setor e até considerar requisitos regulatórios específicos de cada jurisdição. Na prática, o código gerado já nascia dentro do padrão, eliminando aquele ciclo interminável de review, correção e re-review que consumia semanas inteiras de trabalho.
A escolha da plataforma: sem imposição, com dados
A escolha da plataforma também não foi trivial. A EY avaliou múltiplas opções de agentes: Lovable, Replit e os Droids baseados em IDE da Factory. Em vez de mandar a equipe de liderança escolher uma ferramenta e impor a decisão, Newman e seu time mediram adoção, uso e produtividade em todas as três plataformas simultaneamente.
Newman explicou que não queria ser prescritivo demais como liderança, escolhendo uma ferramenta e simplificando a decisão. O objetivo era deixar os próprios desenvolvedores sinalizarem onde estavam encontrando valor real. E foi exatamente isso que aconteceu. Os engenheiros gravitaram naturalmente para a Factory, o que se tornou o sinal claro de que aquela plataforma entregava resultados concretos.
Quando a Factory foi elevada de avaliação para piloto, a adoção, nas palavras de Newman, se espalhou como fogo. A EY precisou até limitar o tráfego para a Factory e para os Droids, restringindo quais repositórios podiam ser conectados antes de obter aprovação completa de compliance e segurança. Esse tipo de entusiasmo descontrolado, que normalmente seria visto como positivo, na verdade acendeu um alerta importante: a empresa precisava de disciplina sobre quais cargas de trabalho delegar aos agentes.
O framework de classificação de cargas de trabalho
Com os desenvolvedores empolgados e a adoção crescendo rápido, ficou claro que a EY precisava de critérios claros para definir o que os agentes podiam fazer sozinhos e o que ainda precisava de supervisão humana. O time de Newman criou um framework que separava as tarefas em duas categorias bem definidas:
Tarefas de alta autonomia — onde os agentes brilham
- Revisão de código — agentes fazem varreduras rápidas e consistentes, identificando problemas de padrão e possíveis bugs
- Documentação — geração e atualização de documentação técnica a partir do código existente
- Correção de defeitos — identificação e resolução de bugs conhecidos com alta taxa de acerto
- Funcionalidades greenfield — desenvolvimento de recursos novos que não dependem de código legado complexo
Tarefas complexas — onde o humano ainda é essencial
- Refatorações em larga escala — mudanças estruturais que impactam múltiplos sistemas simultaneamente
- Decisões de arquitetura — escolhas de design que definem a direção técnica de longo prazo
- Integrações entre sistemas — conexões que envolvem múltiplas APIs, bancos de dados e dependências cruzadas
Essa classificação pode parecer simples à primeira vista, mas na prática ela resolve um problema que muitas empresas enfrentam ao adotar agentes de IA: a tentação de delegar tudo e depois lidar com as consequências. Com categorias claras, cada membro do time sabe exatamente quando pode confiar no agente e quando precisa assumir o controle. Isso evita tanto o uso excessivo quanto o subutilização da tecnologia.
O novo papel do desenvolvedor: de executor a orquestrador
Talvez a mudança mais profunda que a EY promoveu não tenha sido tecnológica, mas sim de mentalidade. A empresa também redefiniu os papéis dos desenvolvedores. Em vez de escrever todo o código eles mesmos, os engenheiros passaram a atuar como orquestradores, direcionando os agentes aos bancos de dados e repositórios corretos para cada tarefa.
Essa transição exigiu treinamento, acompanhamento e muita paciência organizacional. Os engenheiros que se adaptaram mais rápido foram justamente aqueles que já tinham uma visão mais sistêmica do desenvolvimento de software — profissionais que entendiam o porquê por trás de cada padrão de engenharia, não apenas o como. Para esses profissionais, os agentes se tornaram multiplicadores absurdos de capacidade, permitindo que um único desenvolvedor orquestrasse trabalho equivalente ao de quatro ou cinco pessoas.
Newman descreveu esse momento como um salto para o que ele chama de modelo de desenvolvimento horizon. Nesse modelo, a empresa opera com execução semi-autônoma de agentes em escala, uma equipe de orquestradores em vez de executores e integrações completas com o universo de contexto. É uma mudança fundamental na forma como equipes de engenharia se organizam e entregam valor.
Os resultados concretos e o que eles realmente significam
Com as proteções de segurança implementadas e a integração com os repositórios de código concluída, a EY mediu ganhos de eficiência variando de 15% a 60% em diferentes perfis de profissionais durante a fase inicial de adoção. Os ganhos maiores, de 4x a 5x, vieram com a maturação do processo ao longo dos meses seguintes.
Newman fez questão de reconhecer que é difícil atribuir esses ganhos de produtividade exclusivamente aos agentes de código. As melhorias vieram de uma combinação de tentativa e erro junto com mudanças culturais e comportamentais nos times de desenvolvimento. Essa honestidade é importante porque evita a narrativa simplista de que basta plugar uma ferramenta de IA e a produtividade magicamente se multiplica. Na realidade, a ferramenta é apenas uma peça do quebra-cabeça.
Os resultados de produtividade são impressionantes justamente porque não dependem de condições artificiais. Foram observados em contextos de produção real, com todos os requisitos de qualidade, segurança e compliance que operações de auditoria e finanças exigem. Quando o agente já conhece as regras do jogo antes de escrever uma única linha de código, o resultado sai aproveitável de primeira na maioria das vezes. Isso elimina o retrabalho, acelera os ciclos de entrega e libera os engenheiros mais seniores para focarem em decisões de arquitetura e inovação em vez de ficarem presos em code review de rotina.
Lições para quem quer seguir o mesmo caminho
A experiência da EY deixa algumas lições claras para organizações que estão pensando em adotar agentes de IA no desenvolvimento de software em escala:
Primeiro, invista em padrões antes de investir em ferramentas. Agentes sem contexto são apenas geradores de código genérico. Ter repositórios bem organizados, documentação de padrões atualizada e regras de compliance bem definidas é pré-requisito para que qualquer agente de IA gere código realmente aproveitável. Sem isso, você está apenas automatizando a produção de retrabalho.
Segundo, trate a adoção como uma jornada cultural. Os 18 a 24 meses que a EY investiu antes de alcançar os resultados mais expressivos não foram tempo perdido — foram a fundação que tornou tudo possível. Começar com ferramentas assistivas, deixar os desenvolvedores se acostumarem no próprio ritmo e usar dados de adoção para guiar decisões são práticas que reduzem resistência e aumentam a qualidade do uso.
Terceiro, classifique suas cargas de trabalho. Nem toda tarefa de desenvolvimento é igual, e nem toda tarefa deveria ser delegada a um agente. Ter um framework claro que define onde a autonomia funciona e onde a supervisão humana é necessária evita desastres e constrói confiança gradual na tecnologia.
Quarto, meça adoção com dados, não com opiniões. A decisão da EY de avaliar três plataformas simultaneamente e deixar os próprios desenvolvedores sinalizarem a preferência é um exemplo de como decisões de ferramentas podem ser feitas de forma pragmática em vez de política.
O futuro do desenvolvimento de software em escala corporativa não é sobre substituir desenvolvedores por IA. É sobre criar um ambiente onde humanos e agentes de IA trabalham juntos de forma inteligente, cada um fazendo o que faz de melhor. A EY mostrou que isso é possível — mas também mostrou que o caminho exige paciência, estratégia e muito mais do que simplesmente ligar uma ferramenta. 🚀
