Lines of code got a better publicist

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'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.

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…

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.

>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?

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, in reality, it's short-sighted profit-taking. Boss just wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.

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.

I largely think that we engineers are to blame for LoC being still perceived as an asset rather than a liability. We are proud of stuff we create, but it turns out that you can't describe how "big" something is without some metric, and so we fall back on the metric that is easiest to compute.

Suggestion: we should all shift our terminology, and in particular make heavy use of phrase "...and it cost N lines of code". And say what we spent those LoC on.

"I implemented new feature X, and it only cost 200 lines!"

"That bug was brutal to figure out, but in the end it only cost 6 lines of code."

"It was doing something in case X that it didn't do in case Y, and it turns out that the distinction wasn't even needed. So I fixed the problem and saved 20 lines of code at the same time!"

Lines of code are a price you pay. We don't go around bragging about how we spent $200 without any mention of what we purchased with that money. Why do we do that with LoC? "I had to pay an extra $200 because I signed up late" and "I only paid $200 for my hand-painted artisanal pottery lamp hanger. Factory-made ones cost upward of $1200 on Amazon!" are two very different statements, and map to exactly the same distinction in code.

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.

Large enterprises class systems are notoriously difficult to work Ai. It’s the context window limitation. Assuming 10 tokens per LoC. The best models today cannot wrangle 100k distributed LOC across multiple repos. It’s great for building new and maintaining smallish codebases. All this code being written is fantastic, but maintaining them efficiently over the code lifecycle is tricky.

I think a better metric these days is what percentage of code is not reviewed / understood by humans. That is the real bottleneck. Until we can stop looking at the code, AI barely matters - you are just trading quality for quantity.

Thats why it is so amazing for speed runs and prototypes. Here it is legitimately > 10X faster.

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.

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

If developers burn through thousands in AI tokens a day, does it really matter, and is it a good spend? Are the outputs actually checked for sanity, fitness, qa/qc, security etc. How much rework is coming out because of lack of validation, or too much automation in the soup.

The more I read, the more I feel that 1 dev, 1 ai agent with the dev as a gatekeeper is probably the most appropriate workflow. Where you now treat the single dev + ai as a team in terms of planning and cost analysis and you get about 1.2-1.3x the throughput compared to a traditional team of 3-5 devs with partial PM and partial QA where the Dev now needs to take on those roles too.

The output should include more/better testing, examples, demos etc... since the bus factor is now 1, but AI is expected to be able to do the heavy lift.

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...

LoC by itself is useless and so is AI LoC, it doesn't really show anything by itself.

But if you pair AI LoC in a range and also task completed in the same range and then compare that with historical data over a similar range without AI, then you have something tangible.

You also need to look at defect reports to understand the full picture of is AI being helpful.

So, we do need to measure AI LoC and AI PR counts, but we also need to make sure we are using other metrics to help paint the full picture.

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

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

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

The paradigm used to be create good enough abstractions you can express what you need in a few dozen lines or whatever. Those lines will be clearer and more precise than English for describing what it does.

I wonder if we'll ever get back to that? If it's still relevant?

It is pretty funny how this whole industry in a very short amount of time, with tons of experience and knowledge to lean on, reverted back to dubious measurements of productivity. If you track LoC and tokens used as productivity measurements, developers are going to max their LoC and token usage! Its so predictable that we have a Law named after this phenomenon! The fallout was so predictable I feel like I should have been positioning myself for all of the potential consulting work that's about to be needed.

Reporting on percentage of AI generated lines of code is very different from total lines of code. Yes I know both of them are missing what's the value delivered, but the later assumes the value is the number of lines, while the former assumes value is at least the same but delivered faster.

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.

My old CTO has a spiritual metric that always resonated with me: Revenue / Lines of Code. The higher the number the better.

I agree with the main point but this misses something crucial:

> why wouldn’t you use it to deliver more value to your customers, faster? That should show up as MAU, conversion, revenue

Most roadmaps are full of garbage and would be better off being deleted. You get very few truly useful new features in a year.

To paraphrase ESR: the value to your customers is in them being able to know that can rely on your product still operating next year, not in those 20 new features.

Or to think about it another way, maybe block will be better off with fewer developers, but only if they produce sufficiently FEWER features so that they’re forced to prioritize.

>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

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.

Many mid size to large companies are hilariously inefficient and the executives have no idea how work actually gets done. This means you can (in theory) fire a decent percentage of your workforce without affecting your output. You can then claim they’ve been replaced by AI without anyone ever challenging that assertion. I’m not making a pro or anti AI claim here, just saying that you won’t know whether you were wrong about it until/unless things start to go really badly.

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.

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

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

Converting the production database to Prolog to ship LOC.

It’s worth looking at sectors where LLM code generation hasn’t been very visible, such as certification-accredited flight-control, braking, train-control, medical, or nuclear-control source code involving real-time embedded operating systems. This sector relies on assurance: deterministic scheduling requirements, detailed commit traceability, tool qualification, configuration management, independent verification, etc.

Since this is an area where failure can lead not to Instagram accounts getting hacked, but planes falling out of the sky and nuclear reactors spewing radioactive elements, it’s worth a close look. Some of the most visible companies in this sector include: QNX, Wind River, SYSGO, Lynx, Green Hills, Siemens Embedded, etc. None of them seem to have much if any adoption of LLMs for source code generation based on public statements.

Research in this area agrees with this view:

“In this paper, I have conducted a comparative analysis of the C++ code generated by popular LLMs including: OpenAI ChatGPT, Google Gemini, DeepSeek, Meta AI, and Microsoft Copilot for compliance with MISRA C++. The study revealed that none of the evaluated LLMs generated MISRA-compliant code despite clear prompts, with DeepSeek showing the fewest violations and Meta AI the most.”

https://arxiv.org/abs/2506.23535

> "Augment surveyed 219 engineering leaders and asked them to define “AI-native engineering” . They got 219 different answers."

I mean, if you give 219 people a free text box and ask them to explain anything, you're extremely unlikely to get the exact same answer twice...

> But adoption is the starting line, not the scoreboard.

Yes yes, shout it from the rooftops! Over the next few years I think we're going to see that companies that get this point will keep doing meaningful things, and stand a chance of weathering this transition period.

I think we're going to see a bunch of companies that went all in on AI for AI's sake go under because they've lost their mission, lost their implementation, and won't have a way to get those back in a reasonable timeframe and at a reasonable cost.

Writing. Code. Is. No. Longer. The. Bottleneck.

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

So of course we don't see massive productivity gains. Because these parts of the SCLC were always bottlenecked but their capacity matched the throughout. We fired all the dedicated QAs years ago. Sr+ engineers that do all the code review are limited.

Teams have not re-organized to match the new code-input velocity.

Engineers don't want to do QA because it's "beneath them".. and most engineers don't like performing or are not Sr enough to do extensive or high quality code review.

The kloc fallacy never actually disappeared. Project and engineering managers got wise to the fact that it was only loosely correlated with shipping features, and stopped emphasizing it. Most everyone else has carried on silently believing it without really thinking about it. And of course engineers themselves have always believed it. How many times have you heard some guy talk about how he wrote 10kloc over the weekend as a brag?

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

> But! Hold my beer… in February 2026 METR effectively walked it back : their follow-up estimates flipped to a speedup (with error bars wide enough to ride a Moto Guzzi, with panniers, through!), and they abandoned the study design entirely - because developers now refuse to work without AI, and can’t reliably self-report time on agentic work. Their latest position: AI probably speeds developers up in 2026, and we can no longer cleanly measure by how much.

This may be true, but they followed in May with this [0]:

> Importantly, survey results are not necessarily grounded in reality. There are reasons to be skeptical of people’s responses to counterfactual questions such as about AI’s effect on productivity — for instance, our study in early 2025 found that people overestimated AI’s effect on their time spent on tasks by 40 percentage points on average.

[0] https://metr.org/blog/2026-05-11-ai-usage-survey/#productivi...

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.

I don't get how if productivity is barely moving, how a decrease in comprehension will improve anything.

I don't know about anyone else, but for me, even though the AI writes a lot of code, the vast majority of that code tends to be... tests. Same with my coworkers.

This morning I reviewed a 1,200 LoC PR. Pretty large by pre-AI standards. But most of it was tests. Before AI, it would be a lot smaller, but only because the PR author wouldn't be nearly as diligent with test coverage as AI tends to be.

And to preempt some common rebuttals:

1. I always read the tests to make sure they are meaningful, and rules and subagent review routines in place to make sure stuff like "assert 1 == 1" or "Process.sleep(5000)" never make it in.

2. Tests do add a maintenance burden as well, but I find that it's pretty easy to refactor and condense tests.

How do you get to discuss without going to the article directly

> I think every engineer should be using AI daily.

Why?

I guess nobody cares anymore that AI is built on one of the largest thefts in history.

We need a Slop Audit methodology.

That is why I have created one (Open Honest Slop Audit).

To play devil's advocate for a moment (although I hate it): LoC often actually means NIH... but NIH suddenly has a pretty big proponent in the form of resistance to supply-chain attacks.

Basically the choices are:

1. Roll your own

2. Lockfile your deps for too long

3. Chase the bleeding edge for every dependency

The first is security-through-obscurity because DIY libs will have bugs and vulns but they won't be well-known. The second means missing known vulnerabilities. The third means supply-chain risk.

The rash of attacks and the ease of LLM-powered roll-your-own has shifted the risk-reward calculus towards 1.

But I hate it. This is the further Peter Pan never-gonna-grow-up of our industry that we cannot develop solid best-practice tools and must churn endlessly.

I'm reminded of my first tech job about 25 years that had some not very technical manager who had a technical toady write up a script to check lines of code added as a productivity measure. I was in big trouble because it didn't account for lines removed or modified, only new lines added. The copy paste guy was praised of course for how productive he was for.

Funny how AI is continuing the same story of non/semi technical busy bodies with their dumb bullshit.

Amateurs. Using LLMs merelly to generate code. pfft... so 2026....

A few of my workflows now are: Use an LLM to generate code that generates code.

"Second Order AI Software Engineering(TM)"

Another AI slop article urging me to use AI on the orange AI fanboy site which has guidelines against AI slop comments, but AI slop submissions, that's just fine I reckon... Screenshot since the share button demands I have some social media login.

https://imgur.com/a/UW15xVE

"As someone who spends a lot of time writing x86_64 Assembly and optimizing pure-JAX code for TPU clusters, this recent obsession with LLM-generated 'Lines of Code' metrics feels like a massive step backwards. In High-Performance Computing (and especially things like quantum simulation, which I work on), the entire goal is reducing complexity and overhead. The magic of frameworks like JAX/XLA isn't how many lines of code you write, but how elegantly a few purely functional lines can compile down to highly parallelized hardware instructions. If an LLM writes 100,000 lines of boilerplate for a project, someone eventually has to maintain, debug, and pay for the compute to execute that bloat. The real value of AI in engineering shouldn't be churning out a million lines of CRUD per month; it should be helping us build better differentiable systems, grokking complex mathematical landscapes, or spotting inefficiencies in low-level execution. We spent decades learning that Goodhart's Law applies heavily to software engineering (more code != better software). It’s strange seeing leadership forget that just because the code is now generated by an agent."

The thing LOC measures best is how much code someone now has to read, understand, and keep alive. That number going up is a cost, not an output.

I spend a lot of my time taking over codebases other people left behind, and the AI-heavy ones have a recognizable shape: lots of plausible-looking code, thin tests, and nobody who can tell you why a given abstraction exists. Writing was never the hard part. Deciding what not to build, and being able to delete it confidently later, is the part that does not get faster with a model.

What did get faster for me is reading and reverse-engineering unfamiliar code - which is a little ironic, since the same tools are now producing more of the unfamiliar code that needs reverse-engineering in the first place.

[dead]

[dead]

Bragging about an AI agent generating a million lines of code is exactly like bragging about an automated factory generating a million tons of airplane weight. It completely misses the point of engineering. The bottleneck in software development hasn't been "typing speed" for a very long time; it's domain understanding, system design, and long-term maintenance.

Every line of code an LLM instantly spits out is a line a human engineer will eventually have to read, understand, debug, and migrate when the underlying business logic changes. The "better publicist" might be successfully selling these generation metrics to executives, but it's the actual engineering teams who are going to be paying the maintenance tax on all this auto-generated sprawl for the next decade.

[dead]