AI slows down open source developers. Peter Naur can teach us why • Hacker News Board

Re: AI slows down open source developers. Peter Naur can teach us why

#171

Post by ted_bunny » Mon, Jul 14, 2025, 7:30 PM UTC

rsynnott wrote: post #109

bko wrote: post #59

Earlier quoted context omitted.

When anecdote and data don't align, it's usually the data that's wrong. Not always the case, but whenever I read about these strained studies or arguments about how AI is actually making people less productive, I can't help but wonder why nearly every programmer I know, myself included, finds value in these tools. I wonder if the same thing happened with higher level programming languages where people argued, you may…

> I can't help but wonder why nearly every programmer I know, myself included, finds value in these tools. One of the more interesting findings of the study mentioned was that the LLM users, even where use of an LLM had apparently degraded their performance, tended to believe it had enhanced it. Anecdote is a _really_ bad argument against data that shows a _perception_ problem. > Even if we weren't more "productive",…

Also, "anecdotes > data" as a general heuristic is a red flag. But like if clowns had a country and their flag were red. That kind.

Re: AI slows down open source developers. Peter Naur can teach us why

#172

Post by piker » Mon, Jul 14, 2025, 7:32 PM UTC

charcircuit wrote: post #72

piker wrote: post #37

My main two attempts at using an “agentic” coding workflow were trying to incorporate an Outlook COM interface into my rust code base and to streamline an existing abstract windows API interaction to avoid copying memory a couple of times. Both wasted tremendous amounts of time and were ultimately abandoned leaving me only slightly more educated about windows development. They make great autocompletion engines but I…

I had the opposite experience. Gemini was able to work with COM and accomplish what I needed despite me never using COM before.

Actually hadn’t tried Gemini with it yet. Perhaps worth taking a look.

Re: AI slows down open source developers. Peter Naur can teach us why

#173

Post by piker » Mon, Jul 14, 2025, 7:35 PM UTC

crinkly wrote: post #43

piker wrote: post #37

My main two attempts at using an “agentic” coding workflow were trying to incorporate an Outlook COM interface into my rust code base and to streamline an existing abstract windows API interaction to avoid copying memory a couple of times. Both wasted tremendous amounts of time and were ultimately abandoned leaving me only slightly more educated about windows development. They make great autocompletion engines but I…

This is typically what I see when I’ve seen it applied. And as always trying to hammer nails in with a banana. Rather than fit two generally disparate things together it’s probably better to just use VSTO and C# (hammer and nails) rather than some unholy combination no one else has tried or suffered through. When it goes wrong there’s more info to get you unstuck.

To be fair though, unsafe rust (where the COM lives) is basically just C, so I totally expected it to be tractable in the same way it has been tractable for the last 20ish years? But it isn’t.

Why is interacting with the OS’ API in a compiled language the wrong approach in 2025? Why must I use this managed Frankenstein’s monster of dotnet? I didn’t want to ship or expect a whole runtime for what should be a tiny convenience DLL. Insane

Re: AI slows down open source developers. Peter Naur can teach us why

#174

Post by trey-jones » Mon, Jul 14, 2025, 7:35 PM UTC

jpc0 wrote: post #168

trey-jones wrote: post #166

Doing my own post-mortem of a recent project (the first that I've leaned on "AI" tools to any extent), my feeling was the following: 1. It did not make me faster. I don't know that I expected it to. 2. It's very possible that it made me slower. 3. The quality of my work was better. Slower and better are related here, because I used these tools more to either check ideas that I had for soundness, or to get some fresh…

I do this a lot and absolutely think it might even improve it, and this is why I like the current crop of AIs that are more likely to be argumentative and not just capitulate. I will ask the AI for an idea and then start blowing holes in its idea, or will ask it to do the same for my idea. And I might end up not going with it’s idea regardless but it got me thinking about things I wouldn’t have thought about. Effecti…

I'm on record saying it's "like the smartest coworker I've ever had" (no offense).

Re: AI slows down open source developers. Peter Naur can teach us why

#175

Post by yomismoaqui » Mon, Jul 14, 2025, 7:36 PM UTC

jdiff wrote: post #141

yomismoaqui wrote: post #78

Earlier quoted context omitted.

> It is even more insulting because no actual software of value has been demonstrably produced using "AI". Claude Code and Amp (equivalent from Sourcegraph) are created by humans using these same tools to add new features and fix bugs. Having used both tools for some weeks I can tell you that they provide a great value to me, enough that I see paying $100 monthly as a bargain related to that value. Edit: typo

GP is pointing out the distinct lack of AI driven development in the wild. At this point, agents should be visibly maintaining at least a few popular codebases across this world wide web. The fact that there aren't raises some eyebrows for the claims that are regularly made by proponents. Not just the breathless proponents, either. Even taking claims very conservatively, FOSS maintainer burnout should be a thing of t…

It's disingenuous to expect that tools that are publicly available for less than a year have a massive adoption in the wild.

Think that these were internal tools that provided value to engineers on Anthropic, OpenAI, Google & others and now are starting to be adopted by the general public.

Some people are overhyped and some seem hurt because I don't know, maybe they define themselves by their ability to write code by hand.

I have no horse in this race and I can only tell you about my experience and I can tell you that the change is coming.

Also if you don't trust a random HN nickname go read about the experiences of people like Armin Ronacher (Flask creator), Steve Yegge or Thomas H. Ptacek.

- https://lucumr.pocoo.org/2025/6/4/changes/ - https://sourcegraph.com/blog/the-brute-squad - https://fly.io/blog/youre-all-nuts/

Re: AI slows down open source developers. Peter Naur can teach us why

#176

Post by rightbyte » Mon, Jul 14, 2025, 7:36 PM UTC

raincole wrote: post #65

antonvs wrote: post #54

Earlier quoted context omitted.

> You've missed the point of the article Sadly clickbait headlines like the OP, "AI slows down open source developers," spread this misinformation, ensuring that a majority of people will have the same misapprehension.

Which is a good thing for people who are currently benefiting from AI, though. The slower other programmers adopt AI, the more edge those who are proficient with it have. It took me an embarrassingly long time to realize a simple fact: using AI well is a shallow skill that everyone can learn in days or even hours if they want. And then my small advantage of knowing AI tools will disappear. Since the realization I've…

So you bother push some sort of self proclaimed false narrative with upvotes but then you try to counteract it by spelling it out?

Re: AI slows down open source developers. Peter Naur can teach us why

#177

Post by mung_daal » Mon, Jul 14, 2025, 7:37 PM UTC

narush wrote: post #27

Hey HN -- study author here! (See previous thread on the paper here [1].) I think this blog post is an interesting take on one specific factor that is likely contributing to slowdown. We discuss this in the paper [2] in the section "Implicit repository context (C.1.5)" -- check it out if you want to see some developer quotes about this factor. > This is why AI coding tools, as they exist today, will generally slow so…

[dead]

Re: AI slows down open source developers. Peter Naur can teach us why

#178

Post by piker » Mon, Jul 14, 2025, 7:42 PM UTC

tonyedgecombe wrote: post #156

charcircuit wrote: post #72

Earlier quoted context omitted.

I had the opposite experience. Gemini was able to work with COM and accomplish what I needed despite me never using COM before.

I've done a lot of work with COM over the years and that is the last technology I would trust to an AI. It's very easy to write COM code that appears to work but contains subtle bugs.

That was my issue. Integration works, Outlook itself not so much, afterwards. (I.e. memory error.)

Re: AI slows down open source developers. Peter Naur can teach us why

#179

Post by krona » Mon, Jul 14, 2025, 7:46 PM UTC

seanwilson wrote: post #116

narush wrote: post #27

Hey HN -- study author here! (See previous thread on the paper here [1].) I think this blog post is an interesting take on one specific factor that is likely contributing to slowdown. We discuss this in the paper [2] in the section "Implicit repository context (C.1.5)" -- check it out if you want to see some developer quotes about this factor. > This is why AI coding tools, as they exist today, will generally slow so…

If this makes sense, how is the study able to give a reasonable measure of how long an issue/task should have taken, vs how long it took with AI to determine that using AI was slower? Or it's comparing how long the dev thought it should take with AI vs how long it actually took, which now includes the dev's guess of how AI impacts their productivity? When it's hard to estimate how difficult an issue should be to comp…

An easier way to think about it might be if you timed how long it took each ticket in your backlog. You also recorded whether you were drunk or not when you worked on it, and the ticket was selected at random from your backlog. The assumption (null-hypothesis) is that being drunk has no effect on ticket completion time.

Using the magic of statistics, if you have completed enough tickets, we can determine whether the null-hypothesis holds (for a given level of statistical certainty), and if it doesn't, low large is the difference (with a margin of error).

That's not to say there couldn't be other causes for the difference (if there is one), but that's how science proceeds, generally.

Re: AI slows down open source developers. Peter Naur can teach us why

#180

Post by WhyNotHugo » Mon, Jul 14, 2025, 7:47 PM UTC

tomasz_fm wrote: post #31

Only one developer in this study had more than 50h of Cursor experience, including time spent using Cursor during the study. That one developer saw a 25% speed improvement. Everyone else was an absolute Cursor beginner with barely any Cursor experience. I don't find it surprising that using tools they're unfamiliar with slows software engineers down. I don't think this study can be used to reach any sort of conclusio…

An interesting little detail. Any seasoned developer is likely going to take substantially longer if they have to use any IDE except their everyday one.

I've been using Vim/Neovim for over a decade. I'm sure if I wanted to use something like Cursor, it would take me at least a month before I can productive even a fraction of my usual.