Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?

This. Isn't. News.

People. Already. Know. This.

It hasn't been the bottleneck for decades for the majority of products.

Code has never been the bottleneck, and it was always an illusion that it was. I mean, programmers on the whole are a group that jerks around probably 95% of their time (this isn't an attack as I've spent my career as a software developer, and this included countless hours on Reddit, HN, Slashdot, and so on).

> Engineers don't want to do QA because it's "beneath them"..

I’m fine with doing QA. But the fact is that it’s not how management measure my productivity. Spending hours doing QA looks like wasting time to them because it’s not an activity they track. They track my tickets so any hours not spent on them is literally harmful.

Also there’s the fact that you can’t QA your own output. It’s easy to overlook mistakes and defects.

> and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.

Just like QA, code review takes time. It’s easy to justify that time when the submitter has put in the effort to ensure that the contribution is worthwhile. Or can explain the design clearly. Not so much when it’s slop thrown over the wall.

> Deciding what to build. Reviewing Code. And testing code. Are the new bottleneck.

None of those are truly bottleneck. Deciding what to build is obvious: Something that solve a user problem. Reviewing code is easy when the intent of the code is clear (with additional prose if needs be). Testing code is equally easy and should already be automated.

The one slow activity has always been about designing the solution. And it has no relation to code. It’s mostly deep thinking and research. I do it on the sofa or in front of a whiteboard. If I’m typing, I already have a solution in mind.

This weird trend reached an apex in a Feb 2026 OpenAI blog post [1], recently on the front page [2], which describes the process for building... something... written 100% by agents.

There is no description of what the thing is, no indication of what value it provides its users. The closest it gets is "the product has been used by hundreds of users internally, including daily internal power users".

But the fact that the thing has a million lines of code is repeated twice in the first few hundred words.

[1] https://openai.com/index/harness-engineering/

[2] https://news.ycombinator.com/item?id=48416264

I kinda feel as if this was the money quote:

> If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster?

That shows that it's really just short-sighted profit-taking. Boss wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.

I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to, except apparently it was not satire at all, and indeed seemed to reflect the position of many CEOs etc when it comes to LLM code generation.

I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down. More pragmatic and realistic takes are seemingly shared more openly, and are maybe even getting through to top leadership at some tech companies. Maybe not all is lost yet.

> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today.

Because they're bullshitting and using AI as an excuse to correct from their covid era over-hiring while simultaneously making themselves look good to investors by showing they're embracing the hip new technologies to become a more streamlined and cost-efficient operation than ever.

>When a company says “AI made everyone more productive, so we need fewer people”,

They are implicitly saying that as a company, they don't want to be more productive. They want the same productivity by paying fewer more productive people.

Why is there an imbalance between what an employer gets paid for a unit of production and what an employee gets paid for a unit of production?

If your A+ senior developer spends 8 months working on a feature that ultimately doesn’t get shipped or a MVP that gets killed, then you wasted that A+ senior developer and their productivity was the same as the other two B+ engineers that also worked on the project. This is actually a very common issue and usually ignored when it comes to things like hiring or assigning resources to a project. AI won’t change that in a meaningful way, your team may just finish their tasks a lot faster but the bureaucratic layer above will likely remain the same, which will make any AI coding gains negligible. Companies would have to be rebuilt from the top down for AI and that’s very unlikely to happen.

It is endlessly... amusing (?) to me, that we as a community spent decades trying to make it clear that our productivity is not easily measured because what we're doing is complicated and long running, only for AI to come along and suddenly LoC, Nx multipliers, tickets / week etc are held up as useful if not objective measurements.

The reasons we rejected LoC and other measurements have not changed (broadly: code output isn't important, quality output is). AI has all the same problems people do. But for whatever reason we are throwing what we've learnt away. It's kind of embarrassing.

>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.

It is weird that the author seems to understand that the pro-AI claims made by AI companies about the product’s necessity are not falsifiable, but then backtracks with “woah woah woah but don’t think I’m anti-AI.”

How is the assertion above any more rigorous than the productivity claims the author is criticizing throughout the rest of the article? That you won’t “survive” if you don’t adopt AI within a few months?

It is not true when the AI CEO says it, and it is not true when the person calling BS on the AI CEO… for some reason also says it…

> Measuring programming progress by lines of code is like measuring aircraft building progress by weight.

https://www.goodreads.com/quotes/536587-measuring-programmin...

Weird baseless push for AI on the end, with no reasoning, no goal, no claim of gain. "Just go and use AI, people, developers must adopt new things."

It's not the first article I've read recently that is an ad for AI after a short context pretending to criticize it, with nothing connecting them.

>The difference this time is pace: you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.

I don't think so. Take a good company A (with a good product and a good pace of good features) of today. Take the extreme case they decide not to use AI at all. Well, they will still be shipping good features at their current pace.

No amount of AI will make a bad company ship a better product than A's. If any, bad/mediocre companies will be pushing crap faster than they did before, but that's it.

AI can make good companies better, but cannot make bad companies good. Why does company A need to worry about shitty companies using AI? Sure, other good competitors could be using AI, but all in all, shipping "faster" is not the "mark" of good quality

More that LoC is a simple metric that has always been a problem.

Non-Functional requirements is a vestigial term from ‘function point analysis’ which is from the late 70s, and which also ended up being a proxy for LoC.

The entire industry is so focused on measuring now, and incentives are so skewed to short term that lagging indicators like maintainability are a non starter in many organizations that it will be challenging to fix this time.

I don't see LOC as that different from number of hours in the office. They'd always say pre-pandemic "If they're not in the office, how will I know they're working?" Simple, use the output metrics that you use to evaluate all of your workers to see what they contribute to the business.

It seems to naturally follow that a company that sells lines of code would want to measure success in lines of code.

Not a better publicist, but:

A) a newly-receptive audience - engineers who have discovered that they very much enjoy and appreciate the tradeoff of proximity to the code for amplified velocity and impact, now that it's possible to achieve without being a manager of messy human teams.

B) an ecosystem in which it's grown nearly impossible to connect a functional description of something to how much bespoke construction and effort was involved, partially because of marketing and partially because of how much software already exists to be built on top of. It's impossible to tell from a few paragraphs of functional description whether something was built in a weekend or took a team 4 years to ship, so volume of code is the natural fallback for describing complexity.

Not enough people read The Goal.

Ugh. Just imagine the following on a normal curve:

Pre-AI: The goal is to make more money.

With-AI: The goal is to ship more code.

Post-AI: The goal is to make more money.

Can't wait to see how we get there...

This is already changing again now that CEOs have wised up to the fact that they're paying for code by the line but these lines don't translate to profit.

Confusing skeptic and sceptic will never not be funny to me (edit: I now live in shame)

We're still in the FA phase of FAFO when it comes to LLM code generation, aren't we?

When will performance or lacks of bugs become a metric again?

I think this is important:

> When a company says “AI made everyone more productive, so we need fewer people”, I want to see the evidence - and I don’t believe it exists today. Show me that x% of your workforce is genuinely idle (or even just underutilised) because the work can now be done by fewer people. Even then: I’ve never seen a product/SaaS company that didn’t have an endless roadmap. If you got a free headcount increase essentially overnight, why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue.

I see some people calling for calm instead of AI panic by invoking Jevons Paradox. But at least within these companies there's no good evidence of Jevons in action, is there? The roadmap is endless, but when employees are perceived to be idle they get fired instead of being assigned more (or more ambitious) tasks.

To be fair, one could claim Jevons applies to "the market" at large, but at least we can say the evidence from tech companies is not encouraging. So maybe it is, indeed, time to panic a bit?

> Choosing the layoff instead tells me the productivity claim is doing PR work for a decision that was already made for other reasons (over-hiring, investor pressure, take your pick).

Yup, I think we all suspect this. Though it's probably a mix of the two factors.

When I read recent news on HN, I feel it is a fable about Goodhart's Law. The law says: 'When a measure becomes a target, it ceases to be a good measure.' The dog should wag its tail. But the tail is wagging the dog.

Converting the production database to Prolog to ship LOC.

So, how the comapny will be evaluating the students on what basis?

So what has actually shipped? I'm already using much many more AI-coded projects in my daily life than I was a few months ago.

> which basically read as satire to most engineers I talked to

Seemingly engineers get this wrong too. I'm reminded of when Cursor bragged about how many lines of code a group of agents could produce, with the underwhelming results of a barely working browser, when the same could be built with much less code.

But they highlighted the amount of code as they were proud over how much slop their constellation of agents had shit out, and these were supposedly engineers, really strange to see.

The word “slop” was a good choice to talk about the mass of code generated by AI. I think it resonates with non-tech people and it conveys disgust. It’s clear that we should avoid slop.

“Technical debt” never hooked management in the same way and we have found it hard to convince them that it needs to be addressed. Debt in general is something that can be a problem, but doesn’t need to be avoided or addressed until it is a problem so the can is kicked down the road.

It's not unmaintainable if you have 1000 agents maintain it.

I think the reliability struggles of Github may have helped with this

> I'm constantly thinking about that Microsoft guy who posted something like "we want 1 million LoC per engineer per month", which basically read as satire to most engineers I talked to

Did those engineers not actually read the complete tweet? Because it wasn't about "engineers should write 1M LOC per month of product code" it was "we want to scale automated porting of code to safe languages so that 1 engineer managing 1M LOC of automated conversion can work". Which doesn't seem like satire at all..? It just means "develop mostly reliable AI-driven refactoring tools with good guard rails". Which seems quite sensible, actually?

All else being equal, and assuming you are building the right thing, being able to deliver more correct lines of code is a good thing. The question is how to do it reliably, given that a human cannot possibly read all of it. The answer seems to me to involve spot checks with proofs of correctness and statistical quality control, the latter being things that can be automated. One issue I see is that the models are constantly changing and are therefore not well understood statistically.