Introdução ‒ equívocos e realidade sobre a produtividade de desenvolvedores com IA
- Mark Zuckerberg (CEO da Meta) declarou que "até o fim de 2025 substituirá todos os engenheiros de nível intermediário por IA", e isso fez com que CTOs de várias empresas sofressem a mesma pressão.
- O palestrante deixa claro que "a IA não pode substituir totalmente os desenvolvedores" e enfatiza que a adoção de IA claramente ajuda a produtividade, mas nem sempre; em muitos casos, a produtividade pode até diminuir.
Desenho da pesquisa e dados
- Medição feita ao longo de 3 anos, com mais de 600 empresas, mais de 100 mil engenheiros de software, mais de 1 bilhão de linhas de código e dezenas de milhões de commits.
- A maior parte dos dados vem de repositórios privados (Private Repo) → isso permite medir mudanças reais de produtividade em equipes e empresas.
Limitações de estudos anteriores
- Relatórios conduzidos por vendors muitas vezes têm como objetivo promover suas próprias ferramentas de IA, o que reduz a objetividade.
- Mudanças no número de commits/PRs ou no tempo médio de trabalho podem distorcer a produtividade real.
- Ex.: logo após começar a usar IA, também aumentam commits de bugs ou de retrabalho (rework), o que superficialmente faz parecer que a produtividade subiu.
- Em "experimentos greenfield (projetos novos)", o efeito da IA parece muito grande, mas em código existente (brownfield) a diferença diminui.
- Pesquisas com desenvolvedores (self-report) têm pouca correlação com a produtividade real (diferença de mais de 30 pontos percentuais entre percepção e realidade).
Modelo de medição de produtividade de Stanford
- Uso de um modelo automatizado baseado em IA semelhante à avaliação de um painel de especialistas:
- Medição por commit de mudanças funcionais (added/removed/refactored/rework)
- O foco não é apenas "número de linhas", mas "funcionalidade, manutenibilidade e qualidade"
- Há precisão na medição de volume de introdução de funcionalidades, refatoração e proporção de retrabalho (rework) em commits recentes.
Principais resultados da pesquisa
- No geral, a produtividade média aumenta de 15% a 20% com a adoção de IA.
- Porém, uma quantidade considerável de "retrabalho" (rework) acompanha esse ganho, o que pode levar a uma percepção exagerada do benefício.
- Há grande variação conforme equipe, empresa e tipo de tarefa.
Causas da diferença de produtividade: dificuldade da tarefa, tipo de projeto, linguagem e tamanho da base de código
| Tipo de projeto | Baixa complexidade | Alta complexidade |
|---|---|---|
| Greenfield (novo) | 30~40% ↑ | 10~15% ↑ |
| Brownfield (existente) | 15~20% ↑ | 0~10% ↑ |
- Em projetos novos (greenfield) e de baixa complexidade, o efeito da IA é grande.
- Em sistemas existentes (brownfield) e complexos, o efeito cai de forma evidente e, em alguns casos, também foram encontrados casos de queda de produtividade.
- Isso foi mencionado na palestra com base em uma amostra real de 136 equipes de 27 empresas.
Popularidade da linguagem e efeito da IA
- Em Python/Java/JavaScript (linguagens populares), o ganho de produtividade com IA é maior.
- Em COBOL/Elixir/Haskell (linguagens menos populares), a ajuda da IA é quase inexistente e, em tarefas complexas, ela pode até desperdiçar tempo e reduzir a produtividade.
- Ex.: no caso de linguagem pouco popular e alta dificuldade, ela "erra muito e não consegue gerar código correto" → é melhor não usar.
Tamanho da base de código e efeito da IA
- Quanto maior a base de código, mais rapidamente diminui o efeito de ganho de produtividade da IA.
- Motivos:
- Limite da janela de contexto: o LLM não consegue incluir todo o contexto de vários arquivos ou de centenas de milhares a milhões de linhas.
- Redução da "relação sinal/ruído": quanto mais informação contextual existe, mais difícil fica para a IA identificar corretamente o que é relevante.
- À medida que aumentam as complexidades por domínio e por serviço, a dificuldade real de reimplementação sobe
- Na prática, LLMs grandes e recentes (como o Gemini 1.5 Pro) sofrem uma queda brusca de precisão de 90% para menos de 50% à medida que o número de tokens aumenta.
- Motivos:
Resumo geral: quando a IA é eficaz?
- Na maioria dos casos, a IA de fato melhora a produtividade do desenvolvedor, especialmente na escrita de código novo e simples.
- Porém, em ambientes com manutenção complexa, código antigo (e grande), linguagens de nicho e muitas dependências, as limitações são grandes.
- A melhor estratégia de produtividade com IA deve ser desenhada com cuidado de acordo com as características da empresa, da equipe e da tarefa (não existe one size fits all).
- Pesquisas, métricas de marketing e simples aumento no número de commits são pouco confiáveis; é preciso uma medição baseada na realidade, como funcionalidade real do código, proporção de trabalho repetitivo e volume de retrabalho.
Comentários adicionais e casos
- "Engenheiro fantasma": os dados também identificaram que 10% dos engenheiros praticamente não trabalham e apenas recebem salário.
- Foi enfatizada a necessidade de ferramentas de "tomada de decisão baseada em métricas" para que líderes de equipe e CTOs consigam diagnosticar problemas reais com rapidez.
Conclusão
- A IA aumenta a produtividade na "maioria das situações", mas é preciso evitar tanto a superestimação quanto a subestimação desse efeito.
- É necessário identificar as condições específicas em que a adoção funciona bem (simples/novo/linguagem popular/codebase pequena) e aplicar a tecnologia nesses contextos; uma adoção acrítica e indiscriminada pode ter efeito contrário.
2 comentários
Mesmo sem aplicar ao software principal, a IA economiza muito tempo em programas de teste ou na etapa inicial de um projeto.
Mesmo deixando de lado o fato de ela escrever código, acho que os recursos de assistência mudaram da água para o vinho depois da adoção da IA. Agora, acredito que vivemos uma era em que a IA não é mais uma opção, e sim uma necessidade.
Na prática, ajuda bastante no MVP. Especialmente para comentários, logging e escrita de histórico, acho que tem que usar sem falta.
Por outro lado, quando a base de código cresce, aparecem alucinações, ele esquece o código existente e produz resultados estranhos. É preciso pensar em usar engenharia de contexto ou em maneiras de reduzir a base de código.
Acho que isso melhoraria se fosse possível usar prompts maiores.
No momento, parece funcionar bem com Java, Python, JavaScript e Go. Uso principalmente o Copilot, além do Claude e do ChatGPT.