A equipe de engenharia da Agoda investiu tempo considerável na promoção de ferramentas de programação com IA e depois fez um balanço. A conclusão é perturbadora:
A produtividade individual dos desenvolvedores aumentou, mas a velocidade geral de entrega do projeto praticamente não mudou.
Isso não é um problema exclusivo da Agoda. A Faros AI compilou dados de várias empresas e apresentou números preocupantes:
Equipes com alta adoção de IA tiveram um aumento de 98% no número de PRs mesclados e um aumento de 21% no número de tarefas concluídas. Mas, ao mesmo tempo, o tempo de revisão de PRs aumentou 91%.
Mais produção, mas revisões mais lentas. Os dois efeitos quase se anulam.
Qual é o verdadeiro gargalo
A equipe de engenharia da Agoda concluiu que o problema está no fato de que "codificar nunca foi o principal gargalo na entrega de software".
O preenchimento automático com IA torna a escrita de código mais rápida. Mas escrever código é apenas uma etapa da linha de produção – antes dela vêm análise de requisitos, design de sistema, alinhamento da solução técnica; depois vêm Code Review, testes, integração e implantação.
Acelerar a etapa do meio em três vezes não significa que toda a linha de produção ficará três vezes mais rápida.
Quando a IA faz a produção de código explodir, a capacidade de "digerir esse código" se torna o novo gargalo:
- Cada PR contém mais código (o código gerado por IA geralmente não é conciso)
- O Code Review precisa examinar mais coisas
- Mas o tempo dos engenheiros seniores é limitado
O gargalo mudou de "escrever código devagar" para "revisar código devagar", e o ritmo real de entrega não melhorou.
O problema mais profundo: Especificação
O engenheiro da Agoda, Leonardo Stern, vai além: ele acredita que o recurso verdadeiramente escasso subiu de nível – não é a Revisão, mas a Especificação – a capacidade de transformar requisitos de negócio vagos em especificações técnicas claras e executáveis.
Antes, os engenheiros passavam muito tempo escrevendo código, e a especificação podia ser vaga, porque "escrevendo, a gente esclarece".
Agora, você dá um requisito vago para a IA, e ela gera código que "parece utilizável", mas na direção errada. Depois você volta e ajusta a spec, a IA gera novamente, várias rodadas. Superficialmente, a produção de código é alta, mas na verdade você está testando erros com código, e a eficiência não é boa.
Especificações de requisitos de alta fidelidade estão se tornando o artefato central de engenharia. Não o código em si, mas "como descrever o que se quer".
O método "Caixa Cinza" de Stern
Stern propôs um método de trabalho chamado "Caixa Cinza", situado entre dois extremos:
- Caixa Branca: Cada linha de código gerada por IA é revisada, você é totalmente responsável pelos detalhes de implementação
- Caixa Preta: A IA escreve e vai direto para produção, você é responsável pelo resultado, mas não pelo processo
- Caixa Cinza: Intervenção em dois pontos-chave – escrever uma spec precisa e verificar se o resultado está de acordo com a spec
A lógica central da Caixa Cinza é: você não precisa entender qual método a IA usou para resolver o problema, mas precisa ser capaz de dizer claramente "o que significa resolvido" e verificar que realmente foi resolvido.
A essência desse método é concentrar o tempo e a atenção do engenheiro na parte em que a IA é pior – definir a intenção e verificar os resultados, em vez dos detalhes de implementação.
Para onde está indo o papel do engenheiro
Na suposição tradicional do papel do engenheiro de software, "escrever código de qualidade" era a competência central.
Agora, essa suposição está sendo abalada. Quando a IA consegue escrever código de qualidade aceitável, de onde vem a escassez do engenheiro?
Pela prática de empresas como a Agoda, a resposta está caminhando nesta direção:
- Pessoas que conseguem transformar problemas de negócio em especificações técnicas precisas
- Pessoas que conseguem projetar esquemas de verificação eficazes
- Pessoas que conseguem avaliar se o código gerado pela IA realmente resolveu o problema certo
Isso não significa que "a capacidade de escrever código não é mais importante" – mas que essa capacidade passou de recurso escasso para requisito básico, e a verdadeira diferenciação está mais a montante.
Nas palavras de Stern: A autoridade humana está migrando de "escrever código" para "definir intenções". Isso é uma mudança para um nível mais alto de abstração, não o desaparecimento de habilidades.
Como a gerência deve ver isso
Para gerentes de engenharia, o estudo da Agoda traz uma recomendação direta: Não meça o valor da IA pela quantidade de código produzido.
Número de PRs, linhas de código, tarefas concluídas – todos esses indicadores vão melhorar com as ferramentas de IA. Mas se as funcionalidades entregues não aumentaram, não ficaram mais rápidas e a qualidade não melhorou, esses números são apenas números.
Os indicadores que realmente valem a pena acompanhar são: ciclo de lançamento de funcionalidades, taxa de defeitos em produção, tempo de ponta a ponta do requisito à entrega. Esses números mostram se a IA está realmente ajudando a equipe ou apenas ajudando a equipe a "maquiar dados" no GitHub.
Da próxima vez que alguém apresentar números de PRs mesclados para mostrar o ROI de uma ferramenta de IA, você pode perguntar: E o tempo de revisão?
Fonte de referência: CocoLoop, AI Coding Assistants Haven't Sped Up Delivery Because Coding Was Never the Bottleneck (InfoQ)