undefined | Better HN

0 pointsdm_22d ago0 comments

I think this is the key point.

A few years ago, if I send a complex PR that compiles and passes tests, that implies a certain amount of time and cognitive investment on my part. It seems likely that I wouldn't invest that if I didn't also understand the codebase, the feature or bug I'm working on, etc.

Now, that understanding is roughly as expensive as before, but AI has vastly reduced the cost of generating the code that compiles and passes tests.

Probably-well-intentioned community members are happy to contribute the cheap thing( Claude Code tokens) but, because it's so cheap, it's not a good indicator they've contributed the expensive thing (human understanding).

0 comments

2 comments · 2 top-level

dm_OP22d ago

Also, this paper seems relevant: https://www.nber.org/papers/w35275

"Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools"

As the FT summarizes,

> They found an explosive impact at the top of this funnel — coders created or edited almost 300 per cent more files — but that boost was halved to 150 per cent by the time they got to the number of discrete pieces of work submitted for review, and that in turn shrunk fivefold to a roughly 30 per cent uplift in the number of full software releases.

https://www.ft.com/content/8e9ae7a4-7209-4e2c-aa36-f3af77d6c...

So as I wrote, AI vastly improves labor productivity on _coding_, but not nearly as much on code _review_ or other parts of the release pipeline.

And, unfortunately, for many open source projects, it's easy for volunteers to send code for review, but hard for them to volunteer reviewing PRs, managing releases, etc.

winterbourne22d ago

> that implies a certain amount of time and cognitive investment on my part

Yes, this is the takeaway for me. A PR can no longer be a reasonable proof of work.

1 more reply

j / k navigate · click thread line to collapse