Live data from Hacker News

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

johnwhiles.com

201–210 of 217 posts

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

#201
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…

I would expect any change to an optimized workflow (developing own well understood project) to initially be slower. What I'd like to see is how these same developers do 6 months or a year from now after using AI has become the natural workflow on these same projects. The article mentions that these results don't extrapolate to other devs, but it's important to note that it may not extrapolate over time to these same devs.

I myself am just getting started and I can see how so many things can be scripted with AI that would be very difficult to (semi-)automate without. You gotta ask yourself "Is it worth the time?"[0]

[0] https://xkcd.com/1205/

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

#202
post #141

Earlier quoted context omitted.

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…

I'm not asking for massive adoption. I'm asking for public facing evidence of what many claim privately, that they have evolved their job into managing agents and reviewing vs writing anything themselves.

Again, not massive adoption, just one codebase that's used in production with this property. If it's such a productivity boost, there has to be at least one public facing project that's done the same as random HN nicknames and nonrandom named individuals.

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

#203

Earlier quoted context omitted.

It's like the difference between being fast and quick. AI tools make the developer feel quick but they may not be fast. It's less cognitive effort in some ways. It's an interesting illusion, one that is based on changing emotions from different feedback loops and the effects of how memory forms.

Quickness is a burst; speed is a flow. Or, "slow is smooth, and smooth is fast"

I’ve heard it that way, which is more memorable. I’ve also heard it this way:

“Slow is smooth, smooth is efficient, and speed is the efficiency of motion.”

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

#204

Earlier quoted context omitted.

> The inability of developers to tell if a tool sped them up or slowed them down is fascinating in itself Linux/UNIX users are convinced of the superiority of keyboard control and CLI tools, but studies have shown that the mouse is faster for almost all common tasks. Keyboard input feels faster because there are more actions per second.

>but studies have shown that the mouse is faster for almost all common tasks. Do you think that daily CLI Linux/UNIX users might have a different list of what they consider "common tasks"?

I dont think they have different list.

Replying email, copy/moving files, writting document, etc

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

#205

Earlier quoted context omitted.

I have had similar experiences as you, but this is not the kind of work that the study is talking about: “When open source developers working in codebases that they are deeply familiar with use AI tools to complete a task, they take longer to complete that task” I have anecdotally found this to be true as well, that an LLM greatly accelerates my ramp up time in a new codebase, but then actually leads me astray once I…

Not just new code-bases. I recently used an LLM to accelerate my learning of Rust. Coming from other programming languages, I had a lot of questions that would be tough to nail down in a Google search, or combing through docs and/or tutorials. In retrospect, it's super fast at finding answers to things that _don't exist_ explicitly, or are implied through the lack of documentation, or exist at the intersection of wil…

For really basic syntax stuff it works, but the moment you ask its advice on anything involving ChatGPT has confidently led me incredibly wrong right-sounding trails.

To their credit, the people on the Rust forum have been really responsive at answering my questions and poking holes in incorrect unsafe implementations, and it is from speaking to them that I truly feel I have learned the language well.

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

#206
My two cents:

My experience with AI is that it's workable for "approximate" things, but it's frustratingly difficult to use as a precision tool.

It works great for the trivial demos, where you say "here's an API, build a client" without significant constraints, because that use case is a pretty wide, vague goal. I wasn't going to hold it accountable for matching existing corporate branding, code style, or how to use storage efficiently, so it can work fine.

But most of the real work is in the "precision tool" space. You aren't building that many blank-slate API clients, many of the actual tickets are "flip bit 29 of data structure XQ33 when it's a married taxpayer filing singly and huckleberries are in season". The actual change is 3 lines of code, and the effort is in thinking and understanding the problem (and the hundreds of lines of misdocumented code surrounding the problem).

I've had Claude decide it wanted to refactor a bunch of unrelated code after asking for a minor, specific change. Or the classic "here's 2000 lines of code that solve the problem in a highly Enterprise way, when the real developer would look at the problem and spit up 150 lines of actual functionality". You can either spend 30 minutes writing the prompt to do the specific precision thing you want and only that, or you can just write the fix directly.

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

#207

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.

I recently switched from vim (16 years) to vscode and perceived my productivity to be about the same after one week.

No objective measurements here; it might have even increased. But either way, "a month to regain a fraction of productivity" is extreme hyperbole, for me at least.

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

#208

Earlier quoted context omitted.

>but studies have shown that the mouse is faster for almost all common tasks. Do you think that daily CLI Linux/UNIX users might have a different list of what they consider "common tasks"?

I dont think they have different list. Replying email, copy/moving files, writting document, etc

I don't really use CLI for any of that. Despite using it almost exclusively. (Email on my phone - rarely need to move files.)

I use it for:

Arbitrary deep searches in specific root trees. (Where did I make my definitions of foo last time?)

Generating 20 different formats of documents. (Yay for supporting a bunch of platforms.)

Rewriting codebases - this might be the closest to "writing documents". (Mostly git things. And most git GUIs are... Trash.)

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

#209
post #25

Earlier quoted context omitted.

They were 20% underestimating how long it took them to do a 1-8 hr task that they had just completed. It's like Tog's study that people think Keyboard is faster than the mouse even when they are faster with the mouse. Because they are measuring how they feel, not what is actually happening. https://www.asktog.com/TOI/toi06KeyboardVMouse1.html

That is a very weird set of findings. This one in particular: > It takes two seconds to decide upon which special-function key to press. seems to indicate the study was done on people with no familiarity at all with the software they were testing. Either way, I don't think there is any evidence out there supporting that either of keyboard-only or mouse-only is faster or equivalent to keyboard+mouse for well known GUI…

I code with mouse to move the cursor, and I coded fast enough to compete with the fastest in the world in competitive coding. So I don't think keyboard is significantly faster, if it were I wouldn't have been able to write solutions as fast as the fastest in the world did.

But I think its fair to say that its much easier to learn to use a mouse effectively than keyboard navigation, so most people are probably faster with a mouse.

I did try to use keyboard only editors, spend a lot of time on that, but I was always much faster with mouse cursor to navigate and rearrange or copy parts of the code.

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

#210
> Interestingly the developers predict that AI will make them faster, and continue to believe that it did make them faster, even after completing the task slower than they otherwise would!

It's like a form of gambling in which you don't have a simple indicator that you're going broke. The addiction is the same though.

Post reply on HN