Live data from Hacker News

Measuring the impact of AI on experienced open-source developer productivity

metr.org

181–190 of 501 posts

Re: Measuring the impact of AI on experienced open-source developer productivity

#181
post #49

AI by design can only repeat and recombine past material. Therefore actual invention is out.

Is that actually proven?

The easiest way to see this for yourself is with an image generator. Try asking for a very specific combination of things that would not normally appear together in an artpiece.

Re: Measuring the impact of AI on experienced open-source developer productivity

#182

Earlier quoted context omitted.

This is really disingenuous when you also say that OpenAI and Anthropic have provided you with access and compute credits (on https://metr.org/about ). Not all payment is cash. Compute credits is still by all means compensation.

Is it "really" disingenuous, or is it just a misinterpretation of what it means to be "compensated for"? Seems more like quibbling to me.

I was actually being kind by saying it's disingenuous. I think it's an outright lie.

Re: Measuring the impact of AI on experienced open-source developer productivity

#183
post #120

Wow these are extremely interesting results, specially this part: > This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%. I wonder what could explain such large difference between estimation/experience vs reality, any ideas? Maybe our brains are measuring mental effort and distortin…

I would speculate that it's because there's been a huge concerted effort to make people want to believe that these tools are better than they are.

The "economic experts" and "ml experts" are in many cases effectively the same group-- companies pushing AI coding tools have a vested interest in people believing they're more useful than they are. Executives take this at face value and broadly promise major wins. Economic experts take this at face value and use this for their forecasts.

This propagates further, and now novices and casual individuals begin to believe in the hype. Eventually, as an experienced engineer it moves the "baseline" expectation much higher.

Unfortunately this is very difficult to capture empirically.

Re: Measuring the impact of AI on experienced open-source developer productivity

#184

Earlier quoted context omitted.

> Current LLMs One thing that happened here is that they aren't using current LLMs: > Most issues were completed in February and March 2025, before models like Claude 4 Opus or Gemini 2.5 Pro were released. That doesn't mean this study is bad! In fact, I'd be very curious to see it done again, but with newer models, to see if that has an impact.

> One thing that happened here is that they aren't using current LLMs I've been hearing this for 2 years now the previous model retroactively becomes total dogshit the moment a new one is released convenient, isn't it?

Maybe it's convenient. But isn't it also just a fact that some of the models available today are better than the ones available five months ago?

Re: Measuring the impact of AI on experienced open-source developer productivity

#185

Earlier quoted context omitted.

> Current LLMs One thing that happened here is that they aren't using current LLMs: > Most issues were completed in February and March 2025, before models like Claude 4 Opus or Gemini 2.5 Pro were released. That doesn't mean this study is bad! In fact, I'd be very curious to see it done again, but with newer models, to see if that has an impact.

> One thing that happened here is that they aren't using current LLMs I've been hearing this for 2 years now the previous model retroactively becomes total dogshit the moment a new one is released convenient, isn't it?

Sorry, that’s not my take. I didn’t think these tools were useful until the latest set of models, that is, they crossed the threshold of usefulness to me.

Even then though, “technology gets better over time” shouldn’t be surprising, as it’s pretty common.

Re: Measuring the impact of AI on experienced open-source developer productivity

#186

Earlier quoted context omitted.

This is really disingenuous when you also say that OpenAI and Anthropic have provided you with access and compute credits (on https://metr.org/about ). Not all payment is cash. Compute credits is still by all means compensation.

Those are compute credits that are directly spent on the experiment itself. It's no more "compensation" than a chemistry researcher being "compensated" with test tubes.

> Those are compute credits that are directly spent on the experiment itself.

You're extrapolating, it's not saying this anywhere.

> It's no more "compensation" than a chemistry researcher being "compensated" with test tubes.

Yes, that's compensation too. Thanks for contributing another example. Here's another one: it's no more compensation than a software engineer being compensated with a new computer.

Actually the situation here is way worse than your example. Unless the chemistry researcher is commissioned by Big Test Tube Corp. to conduct research on the outcome of using their test tubes, there's no conflict of interest here. But there is an obvious conflict of interest on AI research being financed by credits given by AI companies to use their own AI tools.

Re: Measuring the impact of AI on experienced open-source developer productivity

#187
post #8

As an open source maintainer on the brink of tech debt bankruptcy, I feel like AI is a savior, helping me keep up with rapid changes to dependencies, build systems, release methodology, and idioms.

If you stewarded that much tech debt in the first place, how can you be sure LLM will help prevent it going forward? In my experience, LLMs add more tech debt due to lacking cohesion with it's edits.

Re: Measuring the impact of AI on experienced open-source developer productivity

#188

Earlier quoted context omitted.

Figure 6 which breaks-down the time spent doing different tasks is very informative -- it suggest: 15% less active coding 5% less testing, 8% less research and reading 4% more idle time 20% more AI interaction time The 28% less coding/testing/research is why developers reported 20% less work. You might be spending 20% more time overall "working" while you are really idle 5% more time and feel like you've worked less…

i just realized the figure is showing the time breakdown as a percentage of total time, it would be more useful to show absolute time (hours) for those side-by-side comparisons since the implied hours would boost the AI bars height by 18%

There's additional breakdown per-minute in the appendix -- see appendix E.4!

Re: Measuring the impact of AI on experienced open-source developer productivity

#189
post #38

Here's the full paper, which has a lot of details missing from the summary linked above: https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf My personal theory is that getting a significant productivity boost from LLM assistance and AI tools has a much steeper learning curve than most people expect. This study had 16 participants, with a mix of previous exposure to AI tools - 56% of them had never used Curso…

It seems really surprising to me that anyone would call 50 hours of experience a "high skill ceiling".

Re: Measuring the impact of AI on experienced open-source developer productivity

#190
post #44

Earlier quoted context omitted.

well we used to have a sort of inverse pareto where 80% of the work took 80% of the effort and the remaining 20% of the work also took 80% of the effort. I do think you're onto something with getting pebbles out of the road inasmuch as once I know what I need to do AI coding makes the doing much faster. Just yesterday I was playing around with removing things from a List object using the Java streams API and I kept r…

Code reuse at scale: 80 + 80 = 160% ~ phi...coincidence? I think this may become a long horizon harvest for the rigorous OOP strategy, may Bill Joy be disproved. Gray goo may not [taste] like steel-cut oatmeal.

1.6x multiplier is low, we usually need to apply 5x
Post reply on HN