A IA torna desenvolvedores de código aberto mais lentos. Peter Naur pode explicar o motivo

• Pesquisas recentes indicam que, quando desenvolvedores de código aberto usam ferramentas de IA em codebases que conhecem bem, o tempo de trabalho na verdade aumenta 19%
• Os desenvolvedores acreditam que a IA os torna mais rápidos, mas na prática ficam mais lentos, mostrando uma lacuna entre percepção e realidade
• A causa principal está no modelo mental sofisticado (estrutura de compreensão) que o desenvolvedor possui e nas limitações de transferência de conhecimento entre ele e a IA
• Segundo a teoria de Peter Naur, o mais importante na programação é o "modelo mental" que existe na cabeça do desenvolvedor
  • Pioneiro dinamarquês da ciência da computação e vencedor do Prêmio Turing de 2005. Contribuiu para a notação Backus-Naur Form (BNF), usada para descrever a sintaxe de linguagens de programação
• Em uma perspectiva de longo prazo, para entender profundamente um projeto, é importante construir o modelo mental escrevendo código diretamente

---

O fenômeno de a IA tornar desenvolvedores de código aberto mais lentos

• Segundo um estudo da Metr, usar ferramentas de IA levou a uma resolução de problemas 19% mais lenta
• Antes das tarefas, os desenvolvedores esperavam que a IA ajudasse a trabalhar 24% mais rápido e, mesmo depois, acreditavam ter sido 20% mais rápidos do que realmente foram
• O estudo foi conduzido com desenvolvedores experientes que mantêm diretamente projetos de código aberto que conhecem em profundidade
• O resultado não se generaliza necessariamente para todos os desenvolvedores, mas mostra que, nesse grupo, as ferramentas de IA tiveram efeito negativo na produtividade
• Em ambientes corporativos ou para desenvolvedores comuns que precisam se adaptar a uma nova codebase, as ferramentas de IA podem ter um papel mais positivo no aumento de produtividade

Por que a IA torna desenvolvedores experientes de código aberto mais lentos

• Segundo o artigo “Programming as Theory Building”, de Peter Naur, o verdadeiro produto da programação não é o código, mas o ‘modelo mental do desenvolvedor sobre o projeto’
• Esse modelo mental é central para entender o sistema, diagnosticar problemas e fazer melhorias de forma eficaz
• A IA baseada em LLM não consegue acessar diretamente o modelo mental do desenvolvedor e, mesmo quando parte da informação é fornecida, ocorre uma perda inerente no processo de transferência de conhecimento
  • Como exemplo, ao pedir a alguém que faça um bebê dormir, mesmo explicando claramente, muitas vezes a pessoa age de forma diferente da intenção original
• A transferência de modelos mentais é extremamente complexa, e é quase impossível para a IA absorvê-la apenas por texto
• Portanto, delegar trabalho à IA em um projeto que você entende profundamente pode reduzir a produtividade
• O rico contexto e a compreensão intuitiva do desenvolvedor não podem ser facilmente substituídos pela IA

Devemos proibir ferramentas de IA no trabalho?

• Não necessariamente. Isso se aplica apenas a “quem trabalha em projetos que conhece e entende muito bem”
• Muitos desenvolvedores em empresas acabam mantendo código deixado por seniores que já saíram, ou trabalham sem entender profundamente a arquitetura completa do sistema
• Nesses ambientes, a IA pode contribuir para ganhos de produtividade no curto prazo ao entender rapidamente a codebase e gerar alterações automaticamente
• Se o foco for produzir valor de negócio no curto prazo e eficiência imediata, as ferramentas de IA podem ter um papel positivo na produtividade

Construção de modelo mental e IA

• Se você não tiver um modelo mental do projeto, um LLM pode ajudar a aumentar a produtividade
• Porém, se a essência do desenvolvimento de software estiver na ‘construção de modelos mentais’, depender demais da IA pode enfraquecer essa capacidade
• No longo prazo, se você quiser entender profundamente o projeto e transformá-lo de forma ativa, é necessário ter experiência escrevendo código diretamente
• Por outro lado, se o trabalho for apenas “fazer funcionar de qualquer jeito”, usar IA pode ser eficiente

Discussão adicional e conclusão

• No estágio atual, é difícil para ferramentas de IA aumentar a produtividade de desenvolvedores que já possuem um modelo mental suficientemente rico
• Ainda são necessários mais pesquisa e desenvolvimento para que a IA consiga realmente apoiar modelos mentais ou elevar radicalmente a produtividade de desenvolvedores experientes
• No futuro, com a evolução dos modelos, pode chegar o dia em que desenvolvedores humanos não precisem mais necessariamente ter um modelo mental, mas no estágio atual, compreensão e aprendizado diretos continuam sendo essenciais
• Em última análise, a IA pode atrapalhar em ambientes nos quais eu entendo profundamente o que estou fazendo, e pode virar uma ferramenta de produtividade em ambientes nos quais resultados rápidos são o mais importante

[paruaa]

> Os desenvolvedores acreditam que a IA os tornou mais rápidos
Com a pesquisa usando IA ficando mais rápida, como também é possível elevar a qualidade, talvez até no mesmo trabalho o resultado acabe saindo com uma qualidade um pouco melhor. Será que os desenvolvedores não pensam que, para desenvolver de acordo com a qualidade esperada do resultado final, é mais rápido chegar lá com a ajuda da IA do que sozinhos?
Também fico pensando se, caso nem tivessem usado IA para começar, acabariam implementando só com o conhecimento que já dominam um pouco melhor, e seria por isso.

[tested]

Pelo contrário, se for um tipo de trabalho de “só fazer funcionar”, usar IA pode ser eficiente.

Não são só os desenvolvedores, mas como existem pessoas com perfis muito diversos, às vezes a pessoa acabou virando desenvolvedora e tem aversão ou medo de escrever ou olhar código; quanto mais a mentalidade for a de que basta funcionar, em vez de interpretar a partir de uma perspectiva de estrutura sistemática ou de manutenibilidade, mais forte me parece ser a dependência ou a fé cega na IA. Ou talvez não.

[xguru]

Medindo o "impacto da IA" na produtividade de desenvolvedores experientes de open source

[GN⁺]

Opinião no Hacker News

• Pessoal do HN, sou o autor do artigo.
  Acho que o post do blog abordou de forma interessante um fator específico que pode contribuir para a IA desacelerar o desenvolvimento.
  Também há citações de desenvolvedores no artigo (seção C.1.5), então vale a pena conferir.
  Muita gente lê o artigo, encontra um fator com o qual se identifica e acaba concluindo: “esse único problema é a razão da lentidão”.
  Mas, na prática, há vários elementos envolvidos (pelo menos 5 são prováveis, e até 9 não podem ser descartados; veja a tabela de fatores na p.11).
  Em vez de assumir uma única causa, faz mais sentido analisar causas múltiplas.
  Se alguém aqui pretende fazer seu próprio experimento, eu adoraria que compartilhasse os resultados pelo e-mail indicado no artigo.
  E, sobre o título do artigo ter sido escrito como “AI slows down open source developers. Peter Naur can teach us why”, acho que algo mais preciso seria “No início de 2025, a IA desacelera desenvolvedores experientes de open source. Peter Naur oferece mais contexto sobre um fator específico.”
  Talvez seja menos chamativo, mas considero a precisão importante.
  Mais uma vez, obrigado pelo ótimo texto — continuo lendo os comentários
  Discussão relacionada anterior
  Artigo completo
  • Tenho uma curiosidade pessoal: no estudo, como vocês mediram de forma confiável quanto o tempo real mudou antes e depois do uso de IA? Fico pensando se os desenvolvedores estimaram antes quanto tempo a IA economizaria, e depois vocês mediram o tempo real de uso para comparar a diferença. E também queria saber como a equipe controlou casos em que a dificuldade da issue ou o tempo necessário para resolvê-la eram difíceis de estimar. Concordo que esse tipo de medição é realmente complexo
  • Concordo com os resultados e agradeço pela resposta. Não pretendo mudar o título porque gosto de um estilo mais radical, mas vou corrigir claramente no artigo o que estiver mal formulado. Também deixo claro no texto que os principais fatores de contribuição do estudo, como “alta familiaridade do desenvolvedor com o repositório”, “repositórios grandes e complexos” e “contexto implícito do repositório”, estão alinhados com o que escrevi. Eu também gostaria de fazer esse experimento comigo mesmo, mas criar um ambiente controlado enquanto lido com exigências de trabalho parece muito difícil. Também faltam listas de tarefas claras que possam ser concluídas em pouco tempo
  • Eu esperaria que mudar um workflow já otimizado em um projeto que você conhece bem causasse lentidão no começo. O ponto importante é observar como esses desenvolvedores estarão daqui a 6 meses ou 1 ano. Este estudo não mostra a tendência de longo prazo, então espero que pesquisas futuras revelem como o desempenho muda depois que a mesma pessoa se acostuma. Eu mesmo percebi que, com IA, consigo transformar em scripts muitas tarefas que antes eram difíceis de automatizar. É preciso sempre se perguntar: “isso vale o tempo investido?”
    Quadrinho do xkcd sobre gestão do tempo
  • Também menciono que dizer “no início de 2025 a IA desacelera desenvolvedores experientes de open source” ainda é uma generalização excessiva. Há tarefas específicas em que a IA pode economizar tempo, então o efeito depende do tipo de trabalho
  • Ficar mais lento não é necessariamente algo ruim; programação lenta (programação literária / estilo Knuth) pode até ajudar mais na teorização. Também dá para defender que, em vez de programação fast-food, o importante é um desenvolvimento mais lento, com reflexão e abstração suficientes
• Concordo com esse fenômeno de “o desenvolvedor não consegue perceber se a ferramenta realmente o deixou mais rápido ou mais lento”. Usando como exemplo um barco que sai do rumo por causa do vento e da correnteza, a pessoa observa apenas o movimento ao redor no momento e não sente intuitivamente se está chegando ao objetivo. Por isso, tende a escolher estratégias que dão “sensação de progresso”, e isso pode levar a caminhos ineficientes ou até mais lentos na prática (por exemplo, fazer muitas conversões à direita ao dirigir)
  • Quando comecei a usar ferramentas de IA, gostei dessa sensação de nunca travar e de o trabalho estar sempre andando. Mas, na prática, mesmo quando seria mais rápido corrigir uma linha manualmente, eu acabava chamando a IA por hábito. É parecido com a analogia da direção: quando uma rota trava, você pode acabar voltando repetidamente para o caminho anterior, como um GPS que sempre sugere a mesma rota
  • É parecido com apps de navegação como o Waze, que às vezes mandam por um caminho mais longo, mas por causa dos desvios complicados dão a ilusão de que você está “avançando”, então parece mais rápido. Com ferramentas de IA, a programação também parece mais fácil, mas a produtividade real pode cair. Os humanos tendem a lembrar apenas da experiência de curto prazo de seguir sem sofrimento, e, por não ter sido difícil, sentem que houve progresso
  • No fim, os humanos instintivamente preferem algoritmos gananciosos (greedy algorithm)
  • Usuários de Linux/Unix acham que controle por teclado e ferramentas de CLI são o auge da eficiência, mas há pesquisas mostrando que, na maioria das tarefas, o mouse é mais rápido. A razão de parecer que digitar é mais rápido é que o número de ações por segundo é maior
  • Código gerado por IA quase nunca é revisado, e muitos desenvolvedores já acham code review algo difícil, então se recusam a ler. Por isso surgem fenômenos como a popularidade de novos frameworks ou reescritas de código
    Joel on Software: Things you should never do, part I
    Grande parte do código gerado por IA simplesmente é produzida, passa por alguns testes simples e pronto. Há cada vez mais código cujo próprio autor não entende suficientemente o contexto geral nem o motivo de ele existir
• A ideia central deste estudo pode ser resumida como: “a IA cria a ilusão de um ganho de produtividade maior do que o real”. Apenas alguns participantes tiveram pequeno aumento de produtividade, e a maioria na verdade piorou bastante. Há muita gente dizendo que sua produtividade explodiu graças à IA, mas o insight do estudo — de que esse efeito em si pode ser ilusório — está sendo ignorado. A IA é um produto otimizado para fazer o usuário acreditar que precisa usar isso e que é útil. O valor pessoal percebido é uma realidade subjetiva, então não há muito o que contestar, mas quem depende fortemente de IA precisa tomar muito cuidado com distorção da autoimagem, falsa sensação de realização e dependência da ferramenta. Às vezes a IA responde com um fluxo de tokens otimizado, mas vale refletir qual é o verdadeiro objetivo dessa otimização
  • LLM ajuda quando você quer aprender alguma coisa, mas a compreensão que ele produz parece muito abstrata e “ao estilo LLM”. Para aprender, acho melhor misturar vários métodos
  • Ferramentas de IA dão ao desenvolvedor menos a sensação de “ser mais rápido” e mais a de “ser ágil no instante”. Há um aspecto de ilusão de menor carga cognitiva; é um efeito curioso em que a própria sensação muda por causa de outros feedback loops, e o mecanismo de formação de memória também muda
• Enquanto discutia o estudo que diz que “desenvolvedores experientes de open source ficam mais lentos ao usar IA em seus próprios projetos”, acabei trabalhando em uma codebase de 3 meses, feita totalmente por outra pessoa, com um framework que eu não conhecia. Usando Claude Code, consegui concluir em poucas horas algo que em outros projetos anteriores teria levado um ou dois dias, ou até duas semanas no máximo (como sincronização de dados), e isso me deu um enorme impulso inicial. À medida que a complexidade aumentar, provavelmente vai ficando mais lento, mas foi impressionante como a ferramenta acelerou o começo
  • Tive experiência semelhante, mas o que o estudo descreve não é essa fase de ramp-up que nós vivemos, e sim o caso de desenvolvedores de open source já muito familiarizados usando IA nas tarefas. O LLM de fato acelera a adaptação a uma nova codebase, mas, depois que você já se acostuma, minha experiência é que ele passa a atrapalhar
  • Toda vez que aparece a história de “um PR que levaria 2 semanas saiu em poucas horas”, sempre vem junto a narrativa de aumento de produtividade, mas raramente verificamos o quão precisas são nossas previsões de prazo. Também é preciso avaliar se a qualidade desse PR apressado realmente bate com o esperado, ou se, na pressa de entregar rápido, ele não pulou contextos importantes do sistema e aumentou a chance de bugs. Mesmo sem IA, abrir mão de qualidade também acelera
  • Também fico em dúvida se, com IA, a familiaridade média com a codebase e o sistema realmente cresce de forma natural. O efeito de aprendizado ao usar LLM parece com conseguir ler um novo idioma, mas ter dificuldade para escrevê-lo do zero. Usando C++ como exemplo: dá para ler e modificar o que já existe, mas é difícil começar algo novo do zero
  • O que eu quis dizer é só que tive um enorme jumpstart graças às ferramentas de IA, não que eu quisesse criticar o estudo, o texto ou o artigo, e sim mostrar que, em certos contextos, a IA realmente ajuda. Não é só escrever código: por exemplo, o Claude Code também tentou se conectar diretamente ao cluster da AWS dentro do contêiner interno do projeto, e isso ajudou bastante a entender toda a infraestrutura e a arquitetura. Na minha experiência, em 80% a 90% dos casos, “valor de negócio” é priorizado acima da qualidade do código. Não sei quão útil isso seria em trabalhos onde a qualidade do código realmente importa, ou em áreas que exigem algoritmos e estruturas de dados especiais. Ainda assim, também tive a experiência de que, se você fornece bons exemplos e contexto claro, ele escreve um código bem utilizável. As ferramentas evoluem rapidamente, semana a semana ou mês a mês. No fim, IA não é mágica, é ferramenta, e a responsabilidade pelo produto/resultado continua sendo minha
  • Vale lembrar que o artigo (TFA) trata de casos em projetos muito familiares. O caso que vivi foi justamente o oposto: a IA foi mais útil em um cenário pouco familiar
• Citando a analogia de que “ferramentas agentic de IA (Claude Code, Amp, Gemini CLI etc.) são para programação o que a serra de bancada foi para a marcenaria”, argumenta-se que, aprendendo a usar, dá para fazer certas tarefas melhor e mais rápido, mas, quando você ainda não está acostumado, pode até acabar machucando o dedo. Com IA agentic, tenho me sentido mais disposto a tentar projetos mais ambiciosos e deixo tarefas repetitivas ou chatas para a IA, o que abre mais espaço mental. Por outro lado, também tomo cuidado para não deixar a IA fazer tudo e simplesmente dar commit sem entender. Como qualquer ferramenta, é preciso se esforçar para aprender a usá-la melhor
  • Acho que a analogia com a serra de bancada não combina. A serra de bancada é uma ferramenta precisa em comparação com ferramentas manuais, enquanto IA agentic está longe de ser precisa
  • A lógica de “você está usando IA do jeito errado” é ofensiva para desenvolvedores que já tinham construído toda a stack open source antes mesmo de a IA aparecer. Além disso, ainda não há provas de que a IA tenha produzido software valioso
• Neste estudo, houve apenas um desenvolvedor com mais de 50 horas de experiência com Cursor (incluindo o tempo da própria pesquisa), e esse desenvolvedor teve ganho de 25% de velocidade. Todos os demais eram iniciantes, então é totalmente esperado que fiquem mais lentos usando uma ferramenta nova. Acho difícil tirar conclusões sobre produtividade com IA com base apenas neste estudo
  • Se você olhar os detalhes do artigo, estudos anteriores com participantes de experiência semelhante (ou até menor) com a ferramenta também relataram aumento de velocidade. A maioria já tinha bastante experiência com prompts de LLM, e também vale considerar que o Cursor é parecido com o VSCode, então não há uma curva de aprendizado tão grande assim. Se todos os desenvolvedores ficarem extremamente acostumados com ferramentas de IA, pode acontecer de a habilidade deles sem IA piorar; nesse caso, a referência passa a ser um estado já degradado, e usar IA pode parecer mais rápido apenas em comparação com esse novo padrão pior. O insight importante não é qual ferramenta foi usada, e sim o fato de os relatos subjetivos de produtividade terem sido otimistas demais em relação à realidade. Para julgar o efeito real, é preciso ter métricas concretas
    (Isso é discutido com mais detalhes na seção C.2.7 do artigo, “Uso abaixo da média de ferramentas de IA”)
  • Para desenvolvedores que usam sua IDE há muitos anos (Vim/Neovim etc.), trocar para uma nova ferramenta (como Cursor) pode derrubar bastante a produtividade por vários meses
  • Penso o mesmo. Quem usa uma ferramenta desconhecida inevitavelmente fica mais lento. A IA não é exceção
• Sou revisor regular de código do Burn (framework de deep learning baseado em Rust). Recentemente fechei um PR de correção de bug que parecia ter sido escrito inteiramente por um agente de IA. O PR não corrigia a causa do problema, apenas ignorava o erro, adicionava código desnecessariamente prolixo em tom de justificativa e ainda incluía testes para ignorar o erro. Parecia mais um movimento para registrar commits. Esse tipo de abuso de IA está se espalhando de forma preocupante
  • É curioso como, quando o LLM não sabe a resposta, ele solta qualquer coisa, e, quando você aponta que está errado, responde algo como “isso mesmo, vou corrigir”. Dá medo de que pessoas sem experiência não consigam distinguir essas situações, ou passem cada vez menos a prestar atenção ao código. Também há preocupação de que surja uma enxurrada de vulnerabilidades e casos de abuso em larga escala
  • Ao revisar o MR de um colega, notei casos de teste claramente com cara de terem sido gerados por IA (variáveis como thing1, thing2 etc., mudando só o nome, com conteúdo padronizado). Sugeri no feedback nomes mais distinguíveis, e então a IA passou a dar nomes de variáveis longuíssimos, quase listando todas as características de cada caso, o que deixou o código ainda menos legível à primeira vista. Talvez o autor tenha sentido que escreveu tudo muito mais rápido, mas, na prática, o tempo gasto com feedback, revisão e correção apagou qualquer ganho de produtividade
  • Também apareceu uma opinião brincando com a ideia de “framework de deep learning em Rust → ciclo ruim envolvendo IA”
  • Na prática, essa cultura de usar IA só para registrar commits já existe há bastante tempo. A IA apenas facilita ainda mais a produção de spam
    Referência: um antigo problema de spam com IA
  • Aponta-se que LLMs costumam ampliar demais blocos try:catch, o que dificulta rastrear a origem do problema. Eu prefiro que o problema apareça rápido e com força (fail fast) para poder corrigi-lo imediatamente
• Compartilhando minha impressão pessoal: programar com IA quebra demais o fluxo de concentração e cansa mais facilmente. A ideia de codar o dia inteiro é um mito; o normal é focar por 1 a 3 horas e fazer pausas. Até o tempo gasto lendo código ou mudanças de colegas conta como trabalho, mas muitas vezes sem progresso visível. IA agentic (como pequenos refactors) pode ser útil, mas não vejo grande salto de produtividade. Autocomplete de código (como o Copilot inicial), pelo contrário, traz mais ruído desnecessário
  • Se alguém gravasse o que realmente fez ao longo de um dia inteiro, o resultado talvez fosse bem deprimente. Especialmente em codebases maduras, até uma hora de foco pode ser exagero
• Ao depurar um bug complicado (como uma race condition) em uma codebase desconhecida, é essencial adicionar logging, trocar funções de biblioteca, melhorar a estrutura etc. Se a IA simplesmente disser “a race condition está aqui e corrige assim”, oferecendo uma solução rápida de curto prazo, há o risco de isso prejudicar a compreensão da estrutura e da lógica do código. Se a edição de código guiada por IA continuar no longo prazo, o código pode até se degradar a um ponto em que nem a própria IA consiga mais reagir adequadamente
  • Sempre que ouço relatos do tipo “usei IA para contribuir em uma linguagem e numa codebase que eu não conhecia”, penso que, no curto prazo, pode até funcionar, mas fico me perguntando o que de fato foi aprendido. Talvez esse tipo de contribuição sirva para tarefas pequenas, mas quase não vejo relatos sobre manutenção de longo prazo
• Como retrospectiva do meu primeiro projeto em que usei ferramentas de IA de forma ativa, cheguei a três conclusões: 1) não fiquei mais rápido, 2) talvez eu até tenha ficado mais lento, 3) a qualidade do resultado melhorou. A lentidão e o aumento de qualidade estão ligados, porque usei IA principalmente como apoio para validar ideias e explorar alternativas. A IA também me proporcionou uma boa experiência de aprendizado em áreas menos familiares e, na minha área principal, fui refinando minhas próprias ideias ou as da IA, o que acabou melhorando a qualidade final. Velocidade não é tudo e, embora qualidade seja difícil de quantificar, ainda assim me parece valioso
  • Como a IA pode de fato contribuir para melhorar a qualidade, hoje em dia prefiro IAs que argumentam, contestam e não concordam cegamente. Se eu peço ideias para a IA e ela ataca os problemas ou me ajuda a procurar falhas nas minhas ideias, isso é produtivo. Talvez eu nem implemente tudo, mas isso me ajuda a enxergar ângulos que antes eu não teria considerado. Na prática, é uma experiência parecida com conversar com um colega que consegue opinar de forma razoável sobre o domínio

[eususu]

Eu também tinha uma ideia parecida, mas era difícil expressá-la em palavras.
Modelo mental é um nome bem apropriado. Vou tentar usar isso com frequência.