- As ferramentas de IA do início de 2025 foram avaliadas em um experimento randomizado controlado sobre seu impacto na produtividade real de desenvolvedores de código aberto
- Segundo o estudo, ao usar ferramentas de IA, o tempo para concluir tarefas foi, em média, 19% maior
- Os desenvolvedores esperavam que a IA os tornasse 24% mais rápidos, mas, ao contrário da percepção, houve desaceleração real
- O descompasso entre a capacidade da IA observada em benchmarks e na experiência cotidiana e seu efeito real foi bastante marcante
- O estudo enfatiza a importância de compreender com precisão o impacto da IA na produtividade e de adotar formas variadas de avaliação
Visão geral
- Este estudo realizou um experimento randomizado controlado (RCT) para verificar o impacto das ferramentas de IA do início de 2025 (Early-2025) na produtividade de desenvolvedores experientes de código aberto
- Ao contrário do esperado, foi constatado que os desenvolvedores levaram 19% mais tempo ao usar ferramentas de IA
- Esse resultado pode ser interpretado como um caso de medição do impacto real da automação da pesquisa em IA no desenvolvimento de software
- Com base nessa metodologia, os autores afirmam que pretendem continuar estimando os efeitos reais da aceleração de P&D em IA
Motivação da pesquisa
- Os benchmarks de coding/agentes existentes têm limitações para refletir adequadamente situações reais de trabalho
- Por causa de testes autocontidos, tarefas isoladas sem contexto e estruturas de correção automática, eles podem superestimar a capacidade da IA
- Por outro lado, na ausência de intervenção adaptativa humana, também existe a possibilidade de subestimar o desempenho real dos modelos de IA
- Para complementar essas limitações, o estudo mede o impacto real da IA por meio de experimentos sobre a produtividade de desenvolvedores reais de código aberto
Método do experimento
- Foram recrutados 16 desenvolvedores veteranos de código aberto, e selecionadas 246 issues reais em grandes repositórios nos quais cada um atuava havia anos (em média, mais de 22 mil estrelas e mais de 1 milhão de linhas de código)
- Para cada issue, os participantes foram distribuídos aleatoriamente em grupos com uso de IA permitido ou proibido
- Quando a IA era permitida, os desenvolvedores podiam usar livremente Cursor Pro e modelos recentes como Claude 3.5/3.7 Sonnet; quando era proibida, trabalhavam sem ajuda de IA generativa
- Os participantes gravaram o processo de resolução de cada issue (média de 2 horas) e reportaram por conta própria o tempo gasto
- Os participantes do experimento receberam US$ 150 por hora
Principais resultados
- Ao usar ferramentas de IA, o tempo médio para resolver issues aumentou 19%
- Os desenvolvedores esperavam que a IA aumentasse de fato sua produtividade em 24% e, mesmo após o experimento, ainda responderam que percebiam um ganho de velocidade de 20%
- Assim, surgiu uma grande discrepância entre percepção e desempenho real
- Para evitar certos mal-entendidos, este estudo não fornece evidências sobre os seguintes pontos:
- que a IA torna todos os desenvolvedores ou todo o desenvolvimento de software mais lento
- que o efeito da IA pode ser generalizado para outras áreas ou configurações
- que o mesmo resultado continuará a valer no futuro próximo
- que é impossível otimizar LLMs existentes ou técnicas de prompt
Análise dos fatores de impacto
- Foram analisados 20 fatores que poderiam explicar o atraso nas tarefas, e julgou-se que 5 deles tiveram efeito real
- Foi confirmado que variáveis importantes como condições experimentais, modelo, dificuldade da issue e qualidade do PR não tiveram impacto significativo nos resultados
- O fenômeno de atraso foi observado de forma consistente em diversos subconjuntos de dados e métodos de estimação
- A análise detalhada pode ser consultada no artigo original
Interpretação dos resultados e discussão
Conflito entre evidências e suas causas
- A diferença entre resultados de benchmarks de IA, relatos de casos e experimentos reais é clara
- Os benchmarks medem a capacidade da IA principalmente em problemas estreitos passíveis de correção automática
- SWE-Bench: PRs open source baseados em testes; RE-Bench: problemas avaliáveis por algoritmo
- Já no RCT real, em tarefas complexas e realistas que levam de 20 minutos a 4 horas, os humanos acabaram ficando mais lentos
- Por outro lado, no setor e na comunidade, há muitos relatos qualitativos de que a IA é bastante útil em trabalhos de longa duração
Framework de interpretação
- Cada abordagem tem a característica de medir a “capacidade real” de maneira diferente
- Abordagens por caso:
- Problema de subestimação do RCT: pode haver particularidades válidas apenas para a configuração deste experimento
- Possível superestimação em benchmarks/relatos de caso: distância em relação à resolução real e confiabilidade insuficiente de evidências autorrelatadas
- As três abordagens podem se ajustar bem apenas a alguns subproblemas do mundo real
- A discrepância entre diferentes fontes e a capacidade real pode ser interpretada em termos de erro/viés de medição (vermelho) e diferença de escopo de medição (azul)
Implicações adicionais do experimento
- Os resultados do RCT podem não se aplicar a ambientes em que os resultados da IA são amostrados centenas ou milhares de vezes
- Existe a possibilidade de que ganhos de eficiência só apareçam após dezenas a centenas de horas de uso de ferramentas de IA como o Cursor
- Em ambientes com código de alta qualidade e muitos requisitos implícitos (documentação, testes, formatação etc.), a capacidade da IA pode ser limitada
- Como os benchmarks têm escopo estreito, eles podem não refletir adequadamente a dificuldade do trabalho real
- Relatos qualitativos de sensação de ganho podem ter confiabilidade reduzida por superestimação e autoengano
- Como nenhum método único de avaliação é perfeito, destaca-se a necessidade de usá-los de forma complementar
Perspectivas futuras
- A intenção é continuar aprimorando essa metodologia para acompanhar quantitativamente o quanto as ferramentas de IA realmente mudam a produtividade dos desenvolvedores
- Se as ferramentas de IA aumentarem muito a eficiência dos desenvolvedores em campo, também podem surgir riscos de aceleração brusca em P&D de IA, falhas de supervisão e concentração de poder
- O desenvolvimento de frameworks de avaliação adequados a ambientes reais será muito importante para a evolução futura da IA e para a indústria como um todo
2 comentários
US$ 150 por hora? A partir daí o controle de variáveis já vai pro espaço kkkkkkkkk
Opiniões do Hacker News
Comentário de Simon Willison:
O artigo completo traz muitos detalhes que ficaram de fora do resumo link do artigo
Minha opinião pessoal é que existe uma curva de aprendizado muito mais íngreme do que as pessoas imaginam para obter ganhos reais de produtividade com ferramentas de IA baseadas em LLM
Este estudo contou com 16 participantes com diferentes níveis de experiência no uso de ferramentas de IA, e 56% estavam usando o Cursor pela primeira vez; o estudo era principalmente sobre o Cursor
Cada participante trabalhou em cerca de 15 issues no total, e para cada issue o uso de IA era permitido ou não de forma aleatória
Ou seja, cada desenvolvedor executou uma mistura de tarefas com IA permitida e sem IA permitida
Apenas 1/4 dos participantes teve melhora de desempenho, enquanto 3/4 pioraram
Entre os que mais usaram IA estavam pessoas que já tinham usado o Cursor por mais de 50 horas
Os próprios pesquisadores reconhecem que desenvolvedores com experiência suficiente no Cursor tiveram ganho de desempenho
Meu palpite é que este artigo mostra que, por causa da curva de aprendizado elevada no desenvolvimento colaborativo com IA, misturar isso imediatamente ao fluxo de trabalho existente no mundo real pode na verdade piorar o desempenho
Existe uma reação comum em relação a LLMs do tipo “é porque você não soube usar direito”, mas isso me parece uma desculpa que joga responsabilidade demais no usuário
Na maioria dos produtos de tecnologia, se o usuário não percebe valor, eu considero que o problema está no próprio design do produto. Fico me perguntando por que essa lógica não se aplica à IA
Obrigado, Simon, e obrigado por ler o artigo com atenção — sou fã de projetos OS e queria destacar alguns pontos importantes
1) Alguns estudos anteriores mostraram ganhos de desempenho mesmo com pouca experiência na ferramenta, então a teoria da “curva de aprendizado íngreme” sozinha não explica totalmente este resultado
2) Antes do estudo, mais de 90% dos participantes já tinham experiência com prompting em LLMs, e prompting era visto como a principal habilidade. A visão predominante era que, se você já se sente à vontade no VSCode, também consegue usar o Cursor com facilidade
3) Se todos já estavam acostumados com IA, eles poderiam até ter pior desempenho sem IA (pelo menos isso faz sentido para mim); nesse caso, isso reduziria o efeito, porque criaria a ilusão de que a IA parece melhor do que é
4) As informações sobre experiência foram compartilhadas antecipadamente com especialistas em previsão e, mesmo assim, os previsores superestimaram bastante o ganho de produtividade esperado
5) Pode de fato existir uma habilidade de cauda longa que só aparece depois de centenas de horas de uso, e este estudo não consegue dizer muito sobre isso
Como o artigo traz um resultado surpreendente, é fácil para quem lê escolher um único fator e concluir “foi isso!”
Na prática, pode haver causas múltiplas (pelo menos 5, e até 9 não podem ser descartadas; veja a tabela da página 11)
Uma implicação realmente importante: a satisfação autorrelatada dos desenvolvedores tinha uma discrepância enorme em relação à realidade, independentemente do tipo de ferramenta usada
Para medir produtividade, dados reais de campo são indispensáveis (veja a seção C.2.7 do artigo: “uso abaixo da média de ferramentas de IA”, onde isso é tratado em detalhe)
Dá para interpretar como “mesmo com 75% dos participantes tendo experiência com LLM, usar IA deixou o trabalho mais lento”; uma leitura é que a curva de aprendizado de LLM é muito íngreme, outra é que a eficiência real dos LLMs como apoio à programação está sendo superestimada. As pessoas estão errando consistentemente na previsão de desempenho
Mesmo ficando bom em usar LLM, a sua compreensão do código que você escreveu pode piorar
O desenvolvedor tende a ficar cada vez mais íntimo do código com o tempo, mas o LLM pode até piorar gradualmente
Dá para gerar código rápido com LLM, mas se você não prestar atenção suficiente, não acumula domínio real sobre aquele código
No começo o desenvolvimento parece leve e veloz, mas nos bastidores falta entendimento, e o LLM, que no início parecia útil, vai deixando de melhorar; em algum momento aquilo vira um caos de código que nem o LLM nem o usuário conseguem mais sustentar
Acho que é preciso resistir à tentação, insistir para que o LLM produza código mais limpo e, ao mesmo tempo, estudar de fato o código. É preciso fazer o esforço de entender por conta própria
Dá para ver que algumas pessoas ficaram mais produtivas com ferramentas de IA e outras não
Meu palpite é que quem consegue ler rapidamente textos longos ou código leva uma vantagem considerável
A capacidade de identificar rapidamente sugestões inúteis e iterar até obter uma boa resposta é muito importante
A habilidade de varredura rápida se correlaciona com experiência, mas curiosamente também há iniciantes que são bons nisso
Quem é bom de busca talvez também tenha vantagem ao usar LLM, num sentido parecido com saber pesquisar bem no Google
Isso me faz lembrar novamente da regra 80/20 — ela resolve 80% do trabalho em 20% do tempo e consome 80% do tempo nos 20% restantes
Sempre fica uma sensação de “está quase pronto”, então é fácil cair na falácia do custo afundado
A forma que tentei usar recentemente foi tratar a IA não como “solucionadora”, mas como “removedora de atrito”
Eu mesmo faço a programação, e só pergunto à IA coisas pequenas, como sintaxe que esqueci, para acelerar o trabalho
Quase nunca olho sugestões completas de código. Sempre escrevo pensando por conta própria, para evitar perda de compreensão e de habilidade
Antes era quase um anti-Pareto: 80% do trabalho exigia 80% do esforço, e os 20% restantes exigiam mais 80%
Concordo com o uso de IA apenas para resolver “pequenos obstáculos”
Ontem mesmo eu estava apanhando com
ConcurrentOperationsExceptionao processarListcom a stream API do JavaTentei escrever o método por conta própria, não consegui resolver, então pedi à IA um “método thread-safe de conversão de lista”, e ela me avisou que já existia um método embutido na própria API
Para esse tipo de problema variado, a IA é excelente — quando é complexo, mas bem definido
É especialmente útil como uma versão mais poderosa do Stack Overflow: quando eu sei mais ou menos o que preciso fazer, mas não sei exatamente como adaptar aquilo ao meu ambiente, e também ajuda em depuração e rubber ducking
“Gastar 80% do tempo nos últimos 20%” já era a minha experiência antes da IA. Só reduzir o tempo inicial já ajuda. A melhor avaliação de IA que ouvi de alguém com experiência no assunto foi: “90% das minhas habilidades viraram algo sem valor, e os 10% restantes ficaram mil vezes mais importantes”. É exagerado, mas gosto da ideia central
A ilusão de que “está sempre quase pronto” pode, na verdade, causar perda de tempo. A IA é especializada em fazer parecer que está sendo útil, então é preciso um alto nível de pensamento crítico para julgar se há ganho real de produtividade
É especialmente útil ao adicionar funcionalidades a uma base de código existente, em tarefas como “adicionar
fooalém dos parâmetros de busca existentes” ou “remover o código relacionado a x”Para os usuários do HN: sou o autor do artigo — uso HN há muito tempo e hoje estou tentando responder ao máximo às perguntas e feedbacks nos comentários. Se você não tiver tempo de ler o artigo inteiro, recomendo o post de apresentação no blog ou a thread de apresentação no x.com
A metodologia do artigo e a forma como o autor está se comunicando são muito profissionais e impressionantes. Excelente pesquisa
Acho que esta é uma das melhores pesquisas que já vi: apresenta os resultados com honestidade, sem clickbait, e está muito bem organizada e fácil de ler
Vocês consideraram se os tickets processados com IA eram realmente do tipo adequado para IA? Pedir “tente resolver este ticket com IA” é realista, mas pode ser ineficiente. Quando usada do jeito certo, a IA realmente ajuda bastante, mas em muitos casos o efeito é o contrário. Se os participantes tinham experiência suficiente com IA, talvez conseguissem fazer essa distinção, mas isso não ficou claro para mim ao ler o artigo
Gostaria de saber se seria possível divulgar um conjunto de dados brutos anonimizados, ou pelo menos acrescentar ao artigo os tempos absolutos de trabalho por desenvolvedor. Fico curioso para saber se os participantes com mais experiência em Cursor eram de fato mais rápidos que os demais, ou se eram originalmente mais lentos e por isso tiveram um ganho maior com IA. Foi ótimo ver uma avaliação experimental realmente boa, inclusive considerando o efeito Hawthorne
(Não li o artigo, só vi o post.) Vocês mediram fadiga subjetiva como um indicador que poderia explicar por que as pessoas acham que a IA é mais rápida? Depois de migrar de desenvolvedor para gerente, quando o cérebro está cansado, a IA parece melhor simplesmente por ser mais confortável
O resultado deste estudo, especialmente a parte de que “os desenvolvedores esperavam que a IA aumentasse a velocidade em 24%, mas na prática ficaram mais lentos e, mesmo depois da experiência, continuaram acreditando que tinham ficado 20% mais rápidos”, é muito interessante. Por que a diferença entre realidade e percepção é tão dramaticamente grande? Fico pensando se o cérebro não estaria confundindo “esforço mental” com a experiência subjetiva da passagem do tempo
Não tenho evidência, mas tenho um pensamento assustador: será que a interação com IA ao programar estimula o cérebro de forma parecida com um loop de dopamina de rede social (ainda que em outro grau)? Como a IA fica oferecendo respostas repetidamente, o cérebro pode sentir que está recebendo validação positiva, e isso faria o desenvolvedor avaliar a IA de forma mais positiva do que deveria. Será que, se isso chegar a gerar algo como vício, não acabaria levando a uma superestimação real do efeito sobre a produtividade?
Esse fenômeno também pode ser resultado de uma grande campanha de mercado que leva muita gente a acreditar que ferramentas de IA são melhores do que realmente são. O grupo de economistas e especialistas em ML se sobrepõe aos interesses das empresas de IA, e executivos aceitam isso ao pé da letra e prometem grandes resultados. Isso acaba elevando a expectativa de base no mercado inteiro, afetando até desenvolvedores experientes. É difícil provar empiricamente, mas talvez isso explique por que essa ilusão coletiva sobre produtividade com IA se espalhou tanto
Também me pergunto se muitos entusiastas de IA nos comentários do HN não caem nesse mesmo fenômeno. Na prática, se a pessoa não mede o próprio desempenho, fica difícil ter certeza de que a IA está mesmo aumentando sua produtividade
Às vezes tenho a experiência oposta. Hoje tentei usar o Claude code para criar o código de um app demo de exemplo; observando, parecia incrível e quase ficção científica, foi divertido, mas depois de 15 minutos eu já estava mentalmente entorpecido e entediado
Quando vejo a frase “os desenvolvedores esperavam que a IA fosse 24% mais rápida e, mesmo tendo ficado mais lentos na prática, acreditaram que tinham sido 20% mais rápidos”, sinto que há dois problemas aqui
Um é que é muito difícil para a mesma pessoa comparar corretamente quanto tempo levaria, no mesmo contexto, fazendo com IA e sem IA
O outro é que é fácil medir a eficiência da IA por indicadores superficiais, como o tempo até abrir ou fazer merge de um PR, mas na prática, com IA, mais tempo acaba sendo gasto em refatoração, testes, resolução de issues e outras etapas posteriores
É fácil se iludir achando que “o PR foi aberto mais rápido”, mas ignorar o aumento do trabalho futuro
É realmente muito difícil medir o impacto de uma tecnologia ou prática específica sobre a produtividade. Acho arriscado tirar conclusões confiando apenas em autorrelato (
anecdote), porque qualquer pessoa pode facilmente entrar em autoilusão. O próprio estudo reconhece suas limitações, então discussões sobre produtividade precisam considerar uma margem de erro grande. IA é a tecnologia mais estranha que já vi na vida; tentar inferir causalidade a partir de casos isolados ou benchmarks duvidosos é quase como ler horóscopoNo artigo, não foi observada queda de qualidade dos PRs entre as condições com e sem IA. A maioria dos participantes estava acostumada com os padrões do repositório e não era do tipo que “entrega qualquer coisa só para abrir um PR”. O tempo mediano de revisão dos PRs no estudo foi de cerca de 1 minuto. Como você disse, a forma de gastar o tempo muda completamente. Na página 10 do artigo há uma distribuição de tempo com e sem IA: com IA, o tempo de codificação diminui, mas aumenta o tempo de interação com a IA
Sobre a observação de que é impossível saber com precisão “quanto a mesma pessoa levaria no mesmo contexto com IA e sem IA”, o desenho experimental isola o efeito do grupo com IA e do grupo sem IA por meio de random assignment. Diferenças de indivíduo, situação e ambiente são compensadas pela aleatorização. Se a amostra e o tamanho do efeito forem grandes o suficiente, dá para extrair uma diferença estatisticamente significativa
A Figure 21 mostra que o tempo da implementação inicial em si (até o PR) já aumentou, e mesmo que o tempo após a revisão do PR também tenha aumentado, o impacto geral não parece tão grande. Como dá para ver na Figure 18, o tempo de codificação de fato caiu, mas esse ganho foi compensado pelo tempo gasto escrevendo prompts, esperando resultado e revisando a saída. Em tarefas simples de até 5 minutos, talvez fosse melhor nem usar LLM
Gostaria de comparar o conteúdo dos PRs entre diferentes fluxos de trabalho. O Copilot costuma sugerir mais código do que eu mesmo escreveria, e muitas vezes isso resulta em mais linhas sem necessidade, checks redundantes ou abstrações desnecessárias. Minha hipótese pessoal é que, ao ver o LLM despejando muito código, a percepção de quanto tempo levará para resolver o problema fica distorcida
A parte realmente difícil de usar LLM em uma base de código grande é descrever com precisão a tarefa que precisa ser feita. Muitas vezes só explicar um issue em meio a inúmeras interações do código leva mais tempo do que resolver manualmente, enquanto em projetos novos, para gerar boilerplate, parece ser onde LLM combina melhor
Só com recrutamento dos desenvolvedores participantes já foram gastos 300 x 246 = cerca de 73 mil, e o artigo nem foi publicado em periódico nem revisado por pares. O texto parece bem organizado por fora e não parece gerado por IA, mas fiquei curioso sobre como esse financiamento foi possível
O maior apoio financeiro veio do The Audacious Project, e isso pode ser confirmado no anúncio oficial. Além disso, o rodapé do site afirma que até abril de 2025 não houve remuneração recebida de empresas de IA por avaliações
Empresas frequentemente publicam esse tipo de “whitepaper”. É uma mistura de relatório técnico, proposta de política pública e material de divulgação
Acho que fixar-se apenas em periódico e revisão por pares não faz muito sentido. Na ciência, o importante não é quem publica, mas a reprodução e a repetição dos resultados. Como mostra a crise de reprodutibilidade na psicologia, estar em periódico não garante confiabilidade
Na maioria dos países existe financiamento público para pesquisa; nos EUA houve mais apoio no passado, mas recentemente ele foi bastante cortado
Pela página sobre a fundação, parece que eles recebem recursos de vários lugares, incluindo empresas de IA e governos
Em projetos OSS de hobby, a IA mais atrapalha do que ajuda. Geração de código/scaffolding nem é a grande preocupação; revisão de código e gestão da comunidade importam mais. Há limites claros para o que ferramentas de IA conseguem fazer. Mesmo assim, alguém colocou uma ferramenta de revisão de código com IA em um dos meus PRs abertos, e ela despejou um resumo de duas páginas com emojis e tópicos organizados para um PR de 30 linhas. Isso só gera ruído desnecessário e agora meu tempo real de manutenção diminui ainda mais, porque preciso apagar ou esconder esses comentários
Depois que você supera a curva de aprendizado, talvez fique mais rápido (ou, como alguém disse, “até esquecer como trabalhar sem IA”), mas o que realmente deveria ser medido é… quando o PagerDuty dispara às 3 da manhã, quanto tempo leva para depurar aquele código. E também como fica a qualidade de longo prazo desse código. Passei muito tempo melhorando a estrutura do código: puxando a lógica de negócio para uma pasta compartilhada, subindo a cadeia de chamadas e deixando a API mais limpa embaixo, separando lógica/API/exibição, encapsulando melhor, reduzindo acoplamento com injeção de dependência etc. O código gerado por IA vai produzir melhor qualidade, portabilidade e extensibilidade no longo prazo? Ou no fim vai acumulando código ruim até virar um lixão emaranhado, e metade do tempo passará a ser gasta só corrigindo bugs?