[simonw]

> Lines of code per developer grew from 4,450 to 7,839 as AI coding tools act as a force multiplier.

Is that a per-year number?

If a year has 200 working days that's still only about 40 lines of code a day.

When I'm in full-blown work mode with a decent coding agent (usually Claude Code) I'm genuinely producing 1,000+ lines of (good, tested, reviewed) code a day.

Maybe there is something to those absurd 10x multiplier claims after all!

(I still think there's plenty of work done by software engineers that isn't crunching out code, much of which isn't accelerated by AI assistance nearly as much. 40 lines of code per day felt about right for me a few years ago.)

[observationist]

If you actually work, the amount of work you do is absurdly more than the amount of work most others do, and a lot of the time, both the high and low productivity people assume everyone just does as much as they do, in both directions.

A lot of people are oblivious to Zipf distributions in effort and output, and if you ever catch on to it as a productive person, it really reframes ideas about fairness and policy and good or bad management.

It also means that you can recognize a good team, and when a bunch of high performers are pushing and supporting eachother and being held to account out in the open, amazing things happen that just make other workplaces look ridiculous.

My hope for AI is that instead of 20% of the humans doing 80% of the work, you end up with force multipliers, and a ramping up, so that more workplaces look like high function teams, making everything more fair and engaging and productive, but i suspect once people get better with AI, at least up to the point of AGI, is we're going to see the same distribution but 10x or 50x the productivity.

[Garlef]

My experience with coding agents points into the other direction: It's mentally very taxing!

Usually, you have a lot of time to think on the side while coding on what to do next, strategize, etc. But if you work in small increments with an LLM agent, this time is reduced and you have to be ready for the next thing once one increment is done.

So I don't see this as an equalizer. Rather, those who can constantly push forward are getting much more than those who don't.

[rnewme]

1k loc per day or 1k git additions? I don't think one person can consistently review 1k loc, and grow codebase at that speed and size and classify it as good, tested and reviewed.. Can you tell us more about your process?

[simonw]

I'm effectively no longer typing code by hand: I decide what change I want to make and then prompt Claude Code to describe that change. Sometimes I'll have it figure out the fix too.

An example from earlier today: https://github.com/simonw/llm-gemini/commit/fa6d147f5cff9ea9...

That commit added 33 lines and removed 13 - so I'm already at a 20-lines-a-day level just from that one commit (and I shipped a few more plus a release of llm-gemini: https://github.com/simonw/llm-gemini/commits/a2bdec13e03ca8a...)

It took about 3.5 minutes. I started from this issue someone had filed against my repo:

Then I opened Claude Code and said:

  Run this command: uv run llm -m gemma-3-27b-it hi 

That ran the command and returned the error message. I then said:

  Yes, fix that - the gemma models do not support media resolution

Which was enough for it to figure out the fix and run the tests to confirm it hadn't broken anything.

I ran "git diff", thought about the change it had made for a moment, then committed and pushed it.

Here's the full Claude Code transcript: https://gistpreview.github.io/?62d090551ff26676dfbe54d8eebbc...

I verified the fix myself by running:

  uv run llm -m gemma-3-27b-it hi

I pasted the result into an issue comment to prove to myself (and anyone else who cares) that I had manually verified the fix: https://github.com/simonw/llm-gemini/issues/116#issuecomment...

Here's a more detailed version of the transcript including timestamps, showing my first prompt at 10:01:13am and the final response at 10:04:55am. https://tools.simonwillison.net/claude-code-timeline?url=htt...

I built that claude-code-timeline application this morning too, and that thing is 2284 lines of code: https://github.com/simonw/tools/commits/main/claude-code-tim... - but that was much more of a vibe-coded thing, I hardly reviewed the code that was written at all and shipped it as soon as it appeared to work correctly. Since it's a standalone HTML file there's not too much that can go wrong if it has bugs in it.

[WhyOhWhyQ]

Whenever I start reviewing code produced by Claude I find hundreds of ways to improve it.

I don't know if code quality really matters to most people or to the bottom line, but a good software engineer writes better code than Claude. It is a testament to library maintainers that Claude is able to code at all, in my opinion. One reason is that Claude uses API's in whacky ways. For instance by reading the SDL2 documentation I was able to find many ways that Claude writes SDL2 using archaic patterns from the SDL days.

I think there are a lot of hidden ways AI booster types benefit from basic software engineering practices that they actively promote damaging ideas about. Maybe it will only be 10 years from now that we learn that having good engineers is actually important.

[simonw]

> Whenever I start reviewing code produced by Claude I find hundreds of ways to improve it.

Same here. So I tell it what improvements I want to make and watch it make them.

I've gained enough experience at prompting it that it genuinely is faster for me to tell it the change I want to make than it is for me to make that change myself, 90% of the time.

[HDThoreaun]

Ok then you just make review comments and it fixes them. Still faster than writing code yourself

[WhyOhWhyQ]

You missed the point. The original post is about not reading code.

You actually missed the point in two ways, because my response had little or nothing to do with speed of producing code. I'm not sure why you felt the need to express that irrelevant objection.

[rnewme]

My approach used to be similar few months ago before I figured out a way to automate and paralleize part of this process. However the part I'm still curious about is how to get into consistent and sustainable 4 digit LOC daily (assuming up to 8h of work). I can have 10k PR today but debug it and refine it whole week and it'll still be weak code long term..

[lumost]

There is a long tail of engineers working on mature/stable code bases where there are fewer extremely large diffs, or the review burden is extremely high. If you work on core software - then you can never say that a line of code was wrong "because of the AI." e.g. places where you might need 2-3x code approvers or more.

[noosphr]

I'm a good aerospace engineer, my rockets weigh an extra 50kg after every day I work on them.

[leothetechguy]

I couldn't in good conscience work like that, I believe the risk of bad AI generated code due to the tiniest of output variation is far too high. Especially in systems that need to maintain a large state governed by many rules and edge cases.

[simonw]

I recommend having the AI do the typing while still reviewing, comprehensively testing and even dictating the exact shape of every line that you commit.

[CrzyLngPwd]

1,000 lines of debt that you didn't review and probably have no idea what they do.

[AlexandrB]

Yeah, I don't get it. It's well know that "LOC" is not a good metric of developer productivity. But now that AI is writing those lines of code, it's fine as a metric?

[noosphr]

Senior developers know that every line of code is debt. Junior developers think that every line of code is wealth.

[simonw]

I only commit code to production repos if I have fully reviewed it, manually tested it and could explain exactly how it works to someone else.

[WhyOhWhyQ]

You're writing Python and Javascript right? Those languages are extremely easy to write in (which conversely means the legibility is likely to be poor). People maintaining legacy systems in systems level languages aren't going to be able to produce as much code as people writing Python and Javascript.

[simonw]

Yes, mostly Python and JavaScript and SQL. I'm dabbling a little more with Go these days too.

[WhyOhWhyQ]

I do want to pick up Go. I'm also interested in learning Zig, but I'm worried about employability (no knock on Zig, it looks pretty cool).

Anyway, sorry if any of my comments seemed harsh. I always appreciate your posts and comments.

[simonw]

It's a per MONTH number! https://news.ycombinator.com/item?id=46301886#46305425

7,839 / 30 = 261 lines of code per day.

(Given that mistake, I'm slightly amused at the number of replies my post here drew defending that incorrect 40-per-day number. AI-haters-gonna-hate.)

[dakshgupta]

This is per month, I see now that's not super clear on the chart!

[cmdtab]

I saw your example and it was a simple cli tool. Of course you can have claude make commits effectively to it!

[simonw]

Totally. I have dozens of "simple CLI tools" that I work on - and small plugins, and HTML+JavaScript utilities.

If I was hacking on the Linux kernel I would be delighted with myself for producing 40 lines of landed code in a single day.

[eikenberry]

They are obviously talking about writing code against expectations greater than these simple tools. Why troll with the hyperbole?

[simonw]

I don't actually think the CLI tools and JavaScript apps I work on are particularly "simple". I think they're the level of complexity that most developers spend effectively all of their time building.

Kernel / database / systems engineers are a pretty rare breed.

[waterproof]

Looks like it's a monthly number.