alt Hacker NewsLines of Code Got a Better Publicist
Comments
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.
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.
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.
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.
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 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...
So, how the comapny will be evaluating the students on what basis?
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.
Converting the production database to Prolog to ship LOC.
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.
> 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...
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?
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.
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?
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.
> "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...
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.”
We need a Slop Audit methodology.
That is why I have created one (Open Honest Slop Audit).
How do you get to discuss without going to the article directly
[flagged]
[dead]
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