Meta usa dados de alterações de código para avaliar o impacto da IA na engenharia

Segundo um relatório do newsletter.getdx.com, a Meta está usando medições feitas a partir de alterações individuais de código para entender como as ferramentas de engenharia e a inteligência artificial estão afetando o trabalho dos desenvolvedores. O pesquisador Moritz Beller afirma que a empresa observou uma queda de mais de 40% no tempo gasto para criar uma alteração, em comparação com o ano anterior, mesmo enquanto os engenheiros produzem mais alterações e alterações maiores.

A métrica, conhecida como tempo de autoria do diff, registra o esforço ativo envolvido na criação, nos testes e na revisão de uma alteração de código. Analisar as alterações individualmente dá à Meta uma visão mais específica do que calcular a produtividade com base em tudo o que um desenvolvedor faz durante um dia.

A Meta não usa essa métrica para classificar ou avaliar engenheiros individualmente. Em vez disso, examina padrões entre equipes, departamentos e a empresa como um todo. O objetivo é detectar regressões, identificar melhorias úteis e decidir onde novos investimentos em ferramentas de engenharia se justificam.

Uma visão mais detalhada da produtividade

A empresa trata o tempo de autoria do diff como um entre vários indicadores. A produtividade, o tamanho das alterações e sua qualidade são considerados em conjunto, porque nenhuma métrica isolada consegue descrever a produtividade de engenharia de forma confiável. Um tempo menor para concluir uma alteração, por exemplo, não é necessariamente benéfico se o código resultante for ruim ou exigir correções substanciais.

Essa abordagem também permite à Meta testar se mudanças em frameworks e ferramentas para desenvolvedores produzem benefícios práticos. O relatório cita a memoização automática no compilador do React como exemplo. Em comparação com a inclusão manual de cache, a abordagem automática do compilador reduziu em cerca de 30% o tempo necessário para criar uma alteração. Beller apresenta resultados dessa magnitude como evidência de que melhorias fundamentais no ambiente de desenvolvimento podem ser mais importantes do que pequenos aperfeiçoamentos nas interfaces.

A queda no tempo de autoria não é totalmente explicada por uma digitação ou geração de código mais rápidas. Beller acredita que os desenvolvedores podem estar usando o tempo economizado para reunir contexto e lidar com tarefas relacionadas à implementação. A redação de prompts parece representar apenas uma pequena parcela dessa atividade adicional.

À medida que gerar código se torna menos dispendioso, o problema mais difícil pode ser definir o que o código deve fazer. A intenção do desenvolvedor ganha valor quando um sistema automatizado consegue produzir rapidamente uma implementação, mas pode interpretar mal uma solicitação incompleta.

O que as métricas de produtividade não capturam

A telemetria tradicional é melhor para registrar alterações de código do que para captar o trabalho que as precede. Quadros brancos, sessões de brainstorming e discussões sobre arquitetura podem ser cruciais para um resultado sem deixar uma conexão clara com um diff posterior. Transcrições de reuniões e outros registros criados por IA podem, no futuro, facilitar o estudo de parte dessa preparação.

Isso não torna a arquitetura menos importante. Evitar um documento de projeto pode simplesmente transferir o ônus para os revisores, que então precisam inferir a estrutura pretendida a partir da implementação concluída. Uma produção mais rápida pode, portanto, ocultar trabalho adicional em outras partes do processo de engenharia.

O estudo anterior de Beller, Mind the Gap, comparou atividades registradas automaticamente com as próprias avaliações dos desenvolvedores sobre sua produtividade. O tempo de programação foi um indicador significativo, mas o descanso, as interrupções e os plantões também influenciaram o quanto as pessoas se sentiam produtivas. Uma nova versão precisaria examinar como os desenvolvedores trabalham com agentes, quanta confiança depositam neles e se coordenar várias tarefas automatizadas ao mesmo tempo gera uma sobrecarga cognitiva excessiva.

Mais produção também não garante uma experiência de trabalho melhor. A discussão observa que a produtividade pode aumentar enquanto a concentração, o esforço mental e a satisfação geral permanecem inalterados ou diminuem. Relações interpessoais, entendimento compartilhado e troca informal de conhecimento são importantes para o trabalho de engenharia, mas continuam difíceis de representar na maioria das métricas.

Reduzir reuniões desnecessárias pode melhorar a produtividade, mas eliminar colaboração em excesso pode privar as equipes de ideias e contexto. Pequenas interações sociais também importam: uma pesquisa discutida no episódio constatou que conversas informais antes e depois das reuniões previam a produtividade declarada pelas pessoas com mais força do que a qualidade da internet.

O desafio de testar agentes de IA

Os agentes de IA tornam barato criar testes unitários e de ponta a ponta, o que pode ajudar a resolver uma lacuna antiga entre desenvolvedores que antes escreviam pouca cobertura automatizada. Mas uma coleção de testes aprovados pode transmitir uma falsa sensação de segurança quando a implementação e os testes compartilham a mesma interpretação equivocada de uma solicitação ambígua.

Um agente pode produzir código e testes internamente consistentes e, ainda assim, não atender ao objetivo real do desenvolvedor. Esse risco torna mais importante definir a correção antes do início da implementação. A conversa sugere que o desenvolvimento orientado por especificações pode se tornar um contraponto ao desenvolvimento orientado por testes à medida que os agentes assumem mais trabalho de programação.

A velocidade da implementação automatizada também aumenta o risco de as equipes construírem, sem saber, a mesma coisa em paralelo. Métricas melhores precisarão levar em conta não apenas o código concluído, mas também o alinhamento, a comunicação e o trabalho duplicado. Os dados da Meta no nível do diff oferecem uma forma de observar alguns efeitos de novas ferramentas, mas a discussão mais ampla deixa claro que a produtividade de engenharia continua sendo um problema humano e organizacional, além de técnico.