Os agentes de codificação podem gerar milhares de linhas de código em minutos. O problema: a maior parte não pode ser implantada. Ele quebra os padrões internos, falha nas verificações de conformidade ou cria mais trabalho de limpeza do que economiza.
“Você pode gerar uma tonelada de código, mas isso não significa nada, certo? Tem que ser um código integrável, compatível e você não quer criar mais trabalho no back-end só porque acelerou o processo de geração de código no front-end”, disse Stephen Newman, CTO líder de engenharia global da EY.
A equipe de desenvolvimento de produtos da EY resolveu isso conectando agentes de codificação aos seus padrões de engenharia, repositórios de código e estruturas de conformidade. O resultado: ganhos de produtividade de 4 a 5 vezes nas equipes que constroem o conjunto de plataformas de auditoria, fiscais e financeiras da EY.
Mas os ganhos não vieram apenas de ligar uma ferramenta. A equipe de Newman passou de 18 a 24 meses construindo a base cultural e as integrações técnicas que fizeram a codificação semiautônoma funcionar em escala.
O primeiro passo foi cultural. A EY começou com ferramentas estilo GitHub Copilot, permitindo que os engenheiros se sentissem confortáveis com engenharia imediata e IA assistida. Newman disse que o principal aprendizado foi tornar a adoção da IA orgânica, em vez de forçada pela liderança. “É importante trazer os recursos de IA como uma adoção orgânica básica, em vez de forçá-los aos usuários”, disse ele.
Os desenvolvedores queriam ir além da geração de código para construção, implantação e operacionalização. Mas os ganhos de produtividade estagnaram sem uma integração mais profunda.
Newman percebeu que os agentes precisavam de acesso aos repositórios de código, padrões de engenharia e catálogos de origem da EY para gerar código implantável. Sem esse “universo de contexto”, como Newman o chama, os agentes produzem resultados genéricos que exigem um extenso retrabalho.
A EY avaliou múltiplas plataformas de agentes: Lovable, Replit e Droids baseados em IDE da Factory. Em vez de exigir uma ferramenta, a equipe de Newman mediu a adoção, o uso e a produtividade em todos os três.
“Não queríamos ser muito prescritivos como equipe de liderança para identificar uma ferramenta e simplificá-la”, disse Newman. Os desenvolvedores “realmente gravitaram e navegaram” para o Factory, o que se tornou o sinal de que ele entregava valor real.
A adoção na fábrica “decolou como um incêndio”, uma vez elevada de avaliação a piloto. A EY teve que limitar o tráfego para Factory e Droids e restringir quais repositórios poderiam se conectar antes de obter aprovação de conformidade e segurança.
A estrutura de classificação de carga de trabalho
O entusiasmo dos desenvolvedores deixou claro que a EY precisava de disciplina em torno de quais cargas de trabalho delegar aos agentes. A equipe de Newman separou as tarefas em duas categorias:
Tarefas de alta autonomia agentes lidam bem:
-
Revisão de código
-
Documentação
-
Correção de defeitos
-
Recursos de campo verde
Tarefas complexas que ainda precisam de supervisão humana:
A EY também mudou as funções de desenvolvedor. Em vez de escreverem eles próprios todo o código, os engenheiros tornaram-se orquestradores, direcionando os agentes para os bancos de dados e repositórios corretos.
Com as proteções de segurança implementadas e a integração completa aos repositórios de código, a EY mediu ganhos de eficiência que variam de 15% a 60% em diferentes personas na fase de adoção inicial.
“Demos um salto em muitos de nossos produtos, onde saltamos para o que chamo de desenvolvimento de modelo de horizonte, onde temos execução de agente semiautônomo em escala, uma equipe de orquestradores em oposição a executores e temos as integrações no universo do contexto”, disse Newman.
Newman reconheceu que é difícil atribuir os ganhos de produtividade de 4 a 5 vezes apenas aos agentes de codificação. As melhorias vieram de tentativa e erro combinadas com mudanças culturais e comportamentais nas equipes de desenvolvedores.
