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.
> "the product has been used by hundreds of users internally, including daily internal power users".
My guess is it’s an email filter.
> million lines of code
> written 100% by agents
Yeah, probably an email filter. Or maybe a JS menu for a departmental wiki that basically recreates jquery using MS JScript and transpiles it into JS 5.
The email filter team is trying to match the pace of innovation of the email generation team. At stakes is the ability for the employees to process the billions of mission-critical generated emails each of them receives each day.
The entire Linux kernel is about 40 million LoC, and only something like 16 million LoC after you remove drivers. I have a hard time imagining whatever OpenAI was talking about there having anywhere close to 6% as much utility as the Linux kernel, despite having 6% as many lines of code. And I have a hard time imagining it's anywhere close to maintainable, regardless of how powerful their LLMs might be.
To be fair, few things of any number of LOC have as much utility as the Linux kernel, and it's also a particularly dense example of code. There's plenty of other examples that have higher LOC / utility ratio without being vibe coded. For example, Google's monorepo famously has 2 billion LOC, which is a statistic I've heard long before LLM coding took over.
Clarification: Google claimed to have 2 billion lines of code in their repo ten years ago, and a commit rate of 50,000 changelists per day, both on exponential growth trends.
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.
> I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down.
I wonder if a small part of this is more and more business and product people actually trying to incorporate AI into their daily workflows. I have seen this in both small companies I work for. People were very excited about getting Claude Cowork a couple of months ago, and while they use it daily, I would say they are rather underwhelmed compared to the magic they were expecting.
Complaints include the output being mediocre and verbose, it getting the most basic things wrong, hitting token limits all the time, and people going back to doing things themselves because it is faster.
Sure, there is some degree of holding it wrong in the beginning, but people are realizing that maybe, just maybe, there is still somewhat of a gap between what AI CEOs, LinkedIn grifters, and YouTube AI supplement peddlers claim and reality.
> 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.
“Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
And anyway, I’m pretty sure what people really mean by this “less is better” mantra is: the lowest amount of code that still accomplishes the goal and is still readable is preferred. Linux apparently has 40M lines of code, and I bet most of it is better than mine. Some things just take lots of code.
Which seems to leave room for these agent salesmen to pitch SLoC as a plus. We just have to believe those lines are all good ones. I that case, it would be impressive. I don’t believe it, but they are probably pitching to people who do.
> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.
More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.
I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!
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.
Technical debt is a indefinable quantity which makes it very prone to be abused to mean "I wish I could rewrite this in [insert some fashionable language, framework or coding style]".
AI slop is an easier concept to quantify. It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
> 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?
I don't care - porting the current architecture - with all the known I wish I had done this differently's - doesn't gain much. See some developers I've worked with who love Rust for "safety", even though they just put everything in unsafe at the first sign of trouble instead of thinking about how this should work safely.
Porting to a new language is easy, but does nothing useful. What we need is to fix the mistakes of the past so we can get to the future. We need to make acceptable performance.
> 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".
Making a grand claim of a goal and not really having an explanation on how to achieve it isn't really much better. I could say "we want to scale food production so that one farmer could manage a million acres of corn a month", but that wouldn't really be sensible. A line of code is less work than an acre of corn of course, but I don't think it's at all apparent what upper bound for how much code is actually plausible for a single engineer to generate in a month and have any degree of confidence in. Given the absurd levels of hype around AI from non-engineering management in the past couple of years, it's not clear why the benefit of the doubt is earned here when there legitimate are managers and executives claiming pretty much exactly what you're claiming this guy wasn't.
If everything in the initial code is 300% covered with excellently documented tests that should be minimally changed during transition (if transition don’t reveal any corner case tests were missing, maybe the transition is not such a bright move after all), that seems a possible thing to consider.
Otherwise it really sounds like a recipe for unnecessary huge risk with dubious expected positive outcome.
Not saying don’t have fun, but on the other side maybe not with the core product of you cash cow already?
> "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..?
Because many programmers don't believe that'd work. See the reaction to Bun's porting to rust. (I bet Bun will work and prove those programmers wrong, but that's another story.)
> 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"
These are one and the same. Whether it's ported code or not doesn't change that. The framing device also doesn't matter, because it's the exact "Oh it's our goal" shtick that executives use in the former's case.
"It's just a measure" doesn't cut it in a world where every single AI measure immediately gets turned into a target by executives greedy for efficiencies that don't exist.
EDIT:
Right, I forgot. This is HN where everyone is a galaxybrain and "Port a million lines of code per month" is a totally reasonable goal for a single individual.
I can easily game writing 1M LOC per month by having the LLM write code in more verbose ways, with useless indirections and abstractions thrown in for good measure. I could even ask claude to write code that does nothing but just takes up line.
In contrast, converting 1M LOC of code per month is a much more solid measure, as long as you measure LOC of the source, not the new code. Sure, in the short term you can pick the easy/verbose things to port, but it's hard to do sustainably. A 5M LOC code base would still be expected to be ported in 5 engineer months.
Granted, you can still rush the work, not test properly, neglect good planning and engineering. Ported lines of code should not be the only measure (just like with any other measure). But it's a much less problematic measure than coding 1M LOC
It is unmaintainable even if you spend 100k per month on tokens to have LLMs pretend they are maintaining it, if they slow down and make little ACTUAL progress. Sadly real progress is impossible to measure, if all you have is an overexcited """engineer""", a credit card, and so much cash spent you could hire all the best engineers you know and still have money for a porsche.
Well, software presumably has a goal of accomplishing something for some end-user, so the progress should be trivial to measure: are features/changes being completed?
The marketing ploys of OpenAI/Anthropic where agents build something that nobody uses might be hard to track given that there are zero users. But what about everyone using agents for real software? It's trivial to prove that agents make progress.
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.
>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.
Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.
> If you can deliver the same thing in fewer correct lines of code
it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.
Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?
Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).
> 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.
I think engineers tend to over index on this kind of thing being "waste". You didn't waste that investment, you paid for the option to ship that feature or MVP and the research into the question of whether it made sense to ship it.
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 non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.
IDK, I do think a lot of it is LLMs enable people who were not in our community to come into it (in an eternal september kind of way) and they are going through all this from first principals and ignoring their elders, but I've also seen technical people suddenly measuring themselves this way. The most optimistic read of this is that they _feel_ productive, and that feels nice, and they want to share how that feels, and so they are reaching for these garbage metrics because they have nothing else.
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?
I think LLMs will make vertical slice architecture more common using less abstraction. If juniors are mostly relying on LLMs then they will accept the long files it generates and not have the opportunity to learn abstractions.
>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?
> They want the same productivity by paying fewer more productive people.
I believe you mean same output but fewer people? But by definition that would be higher company productivity, as the definition of productivity at the company and/or national level is the ratio of outputs to inputs. If you have fewer people but are getting the same output, then the productivity of the company (or nation) has improved.
If you had fewer people but the same productivity then there would be no benefit to the company as the outputs would correspondingly be reduced (and it may actually be worse for the company if the company has any fixed costs).
> 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?
Because labor gets exploited to make the owners richer. That's the basic fact, even though the owners (as a class) have financed a lot of propaganda to justify and obscure it.
>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…
When the AI CEO says it, its because stock go brrr. I never believed that AI CEOs because they're making unverifiable claims that they never backed up, claiming you're firing people because of AI is so open for interpretation, and it shifts blame from you to the AI, reality is we should not blame AI for something a CEO did, you could have re-trained employees for AI, but you didn't why not? Maybe because it's not about AI is it?
AI is the new cloud. There's no market for people or companies who aren't committed to it. If you're a dev who refuses to use AI, no company will hire you; and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs). Their investors and big-ticket customers will also think twice before signing off on major commitments.
So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
> and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs)
Need more devs? Why? If a company was being profitable just fine prio AI era, they will still be profitable if they decide not to use AI. Shipping crap faster is not a formula for success. Shipping quality faster? I prefer shipping quality at a good pace
> 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 just wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.
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.
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.
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.
>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
Yeah I think it also really depends on what your business is. Many or most of us here (and likely also the author) work in the kinds of tech-forward businesses where competition is fierce and velocity is essentially. But there are many many businesses, and also tons of public sector organizations, where this is not the case. Leadership in those organizations should probably be going a lot more slowly, waiting and seeing, letting all the fast movers fight it out through all this churn, and adopting only whatever eventually rises to the top.
Yeah, that closing message was a little weird to me. I understand framing the article as "not anti-AI", especially if the author uses and enjoys the tools. But the end sounds like a call to blindly adopt the tools and figure out the justification later.
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.
Nah, as long as you're good a sport about it, it's all good. In fact, it's refreshing to have someone make a mistake like that so confidently, and then own up to it immediately.
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.”
> 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.
Anyone relying on a steady paycheck from an employer should panic a bit all the time, because nothing can save them from bad management. The reference to Jevons Paradox doesn't say anything about individual managers responding correctly. If 30% of managers screw up, that's a lot of collateral damage.
Now to respond to your actual point, I don't think software developers should panic. Even if pure software engineering gets hit hard, I'm having trouble imagining a scenario where years of software development skills plus knowledge in a specific domain isn't a good thing for current software developers. This is unlike what happened with international trade, where you had 60-year old textile workers losing their jobs, no alternative jobs, and no policy being offered to compensate them for the effects of trade.
> 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.
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.
One thing the AI tools have taught me is that it hasn't been my personal bottleneck for at least a very long time. It's made that part faster for me, and that allows me to take bigger bites at the apple each iteration, but it's not meaningfully speeding me up in the way people claim.
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.
'something that solves enough users problems it's worth it to implement it' rather, and I think it is often difficult to judge how much engineering time to spend on user issues.
I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)
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?
Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction:
> Be curious, try the new tools, test the latest models. To not do so is silly.
> [...]
> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.
> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s the latter, that’s not a curiosity problem, that’s a “there’s a gun to my head” problem.
It seems to be based on some idea that there's no way you can be productive enough without AI. But I've yet to see any companies really shipping meaningful software at some unprecedented speed that was not possible pre-AI. Instead, I see a lot of half baked features and buggy apps. I am not convinced that those that choose to either NOT use AI or use it more sparingly / judiciously (my preference), are somehow going to be "left in the dust".
Yeah, I’ll second that. I see folks moving _fast_, but boy oh boy are they breaking things (or delivering something that never worked) which if anything makes _me_ slower lol
Because I don't think that's the point of the article, which is just a commentary about how AI labs are marketing the effectiveness of their services by using terms like "8x more code per quarter" like that's an obvious good thing (which it isn't).
If you want a more in depth explanation, go look for interviews with devs who were already super-productive before LLMs and now came around to using them everyday.
Because it's fun. And why shouldn't we be into incremental automation?
I still write code manually to keep my trad-coding skills from withering away, but using AI without a doubt has allowed me to better test my existing apps. Create playwright automations I would've never had the time for. Allowed me to search through docs many times faster. And it just making programming more fun when I do use it for more challenging problems, and I actually get something working at the end of the day.
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.
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.
"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.
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.
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
> "the product has been used by hundreds of users internally, including daily internal power users".
My guess is it’s an email filter.
> million lines of code
> written 100% by agents
Yeah, probably an email filter. Or maybe a JS menu for a departmental wiki that basically recreates jquery using MS JScript and transpiles it into JS 5.
> My guess is it’s an email filter.
It may also be an email generator.
The email filter team is trying to match the pace of innovation of the email generation team. At stakes is the ability for the employees to process the billions of mission-critical generated emails each of them receives each day.
Your hilariously specific hypotheses remind me of how little I know about technology.
The entire Linux kernel is about 40 million LoC, and only something like 16 million LoC after you remove drivers. I have a hard time imagining whatever OpenAI was talking about there having anywhere close to 6% as much utility as the Linux kernel, despite having 6% as many lines of code. And I have a hard time imagining it's anywhere close to maintainable, regardless of how powerful their LLMs might be.
To be fair, few things of any number of LOC have as much utility as the Linux kernel, and it's also a particularly dense example of code. There's plenty of other examples that have higher LOC / utility ratio without being vibe coded. For example, Google's monorepo famously has 2 billion LOC, which is a statistic I've heard long before LLM coding took over.
Clarification: Google claimed to have 2 billion lines of code in their repo ten years ago, and a commit rate of 50,000 changelists per day, both on exponential growth trends.
That's a monorepo with hundreds if not thousands of different applications. It's not even close to an apples to apples comparison.
Chrome has 50 mil LoC
https://openhub.net/p/chrome/analyses/latest/languages_summa...
Chrome is basically reinventing each OS API and libraries. One day they’ll have their own tcp stack and packet filter.
It kinda makes sense given that one of their major products is a computer that runs an operating system literally called ChromeOS.
Arguably with QUIC it already does.
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.
> I do think that over the past few months, it feels like the hype around producing unmaintainable amounts of LoC has started dying down.
I wonder if a small part of this is more and more business and product people actually trying to incorporate AI into their daily workflows. I have seen this in both small companies I work for. People were very excited about getting Claude Cowork a couple of months ago, and while they use it daily, I would say they are rather underwhelmed compared to the magic they were expecting. Complaints include the output being mediocre and verbose, it getting the most basic things wrong, hitting token limits all the time, and people going back to doing things themselves because it is faster.
Sure, there is some degree of holding it wrong in the beginning, but people are realizing that maybe, just maybe, there is still somewhat of a gap between what AI CEOs, LinkedIn grifters, and YouTube AI supplement peddlers claim and reality.
> 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.
“Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
And anyway, I’m pretty sure what people really mean by this “less is better” mantra is: the lowest amount of code that still accomplishes the goal and is still readable is preferred. Linux apparently has 40M lines of code, and I bet most of it is better than mine. Some things just take lots of code.
Which seems to leave room for these agent salesmen to pitch SLoC as a plus. We just have to believe those lines are all good ones. I that case, it would be impressive. I don’t believe it, but they are probably pitching to people who do.
> “Less is better” is sort of… the position of the engineer who enjoys the craft of programming, right? I don’t think this is universally believed.
I think it is (or should be) a goal & business-oriented concern as well, not just an engineer's who enjoys their craft.
More complex systems are worse than simpler systems (that accomplish the same), in cost, maintenance, fragility, ease of understanding, etc. Fewer moving parts usually result in higher reliability, fewer things that can break down or fail to interact properly, etc. That's a business concern too, not just engineering craftmanship or whatever. Business people should care about this too.
I don't think this is the same as bikeshedding over irrelevant details, something we software engineers are often prone to. Monstrous complexity does impact the business!
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.
Technical debt is a indefinable quantity which makes it very prone to be abused to mean "I wish I could rewrite this in [insert some fashionable language, framework or coding style]".
AI slop is an easier concept to quantify. It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
> It's basically the code for which insufficient people in the organisation have a meaningful understanding of how it works or what it does.
Its connotation also includes being vastly larger than needed for the purpose it serves, _if_ there is even any purpose.
> 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?
I don't care - porting the current architecture - with all the known I wish I had done this differently's - doesn't gain much. See some developers I've worked with who love Rust for "safety", even though they just put everything in unsafe at the first sign of trouble instead of thinking about how this should work safely.
Porting to a new language is easy, but does nothing useful. What we need is to fix the mistakes of the past so we can get to the future. We need to make acceptable performance.
> 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".
Making a grand claim of a goal and not really having an explanation on how to achieve it isn't really much better. I could say "we want to scale food production so that one farmer could manage a million acres of corn a month", but that wouldn't really be sensible. A line of code is less work than an acre of corn of course, but I don't think it's at all apparent what upper bound for how much code is actually plausible for a single engineer to generate in a month and have any degree of confidence in. Given the absurd levels of hype around AI from non-engineering management in the past couple of years, it's not clear why the benefit of the doubt is earned here when there legitimate are managers and executives claiming pretty much exactly what you're claiming this guy wasn't.
If everything in the initial code is 300% covered with excellently documented tests that should be minimally changed during transition (if transition don’t reveal any corner case tests were missing, maybe the transition is not such a bright move after all), that seems a possible thing to consider.
Otherwise it really sounds like a recipe for unnecessary huge risk with dubious expected positive outcome.
Not saying don’t have fun, but on the other side maybe not with the core product of you cash cow already?
> "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..?
Because many programmers don't believe that'd work. See the reaction to Bun's porting to rust. (I bet Bun will work and prove those programmers wrong, but that's another story.)
Minor correction: LinkedIn, not twitter. https://www.linkedin.com/posts/galenh_principal-software-eng...
> 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"
These are one and the same. Whether it's ported code or not doesn't change that. The framing device also doesn't matter, because it's the exact "Oh it's our goal" shtick that executives use in the former's case.
"It's just a measure" doesn't cut it in a world where every single AI measure immediately gets turned into a target by executives greedy for efficiencies that don't exist.
EDIT:
Right, I forgot. This is HN where everyone is a galaxybrain and "Port a million lines of code per month" is a totally reasonable goal for a single individual.
I can easily game writing 1M LOC per month by having the LLM write code in more verbose ways, with useless indirections and abstractions thrown in for good measure. I could even ask claude to write code that does nothing but just takes up line.
In contrast, converting 1M LOC of code per month is a much more solid measure, as long as you measure LOC of the source, not the new code. Sure, in the short term you can pick the easy/verbose things to port, but it's hard to do sustainably. A 5M LOC code base would still be expected to be ported in 5 engineer months.
Granted, you can still rush the work, not test properly, neglect good planning and engineering. Ported lines of code should not be the only measure (just like with any other measure). But it's a much less problematic measure than coding 1M LOC
> Granted, you can still rush the work, not test properly, neglect good planning and engineering.
Which is the core point of my reply and not something to just be casually handwaved, thank you very much.
It's not unmaintainable if you have 1000 agents maintain it.
It is unmaintainable even if you spend 100k per month on tokens to have LLMs pretend they are maintaining it, if they slow down and make little ACTUAL progress. Sadly real progress is impossible to measure, if all you have is an overexcited """engineer""", a credit card, and so much cash spent you could hire all the best engineers you know and still have money for a porsche.
It's not unmaintainable if most of it is tests. Just have it write tests until it becomes safe for AI.
Well, software presumably has a goal of accomplishing something for some end-user, so the progress should be trivial to measure: are features/changes being completed?
The marketing ploys of OpenAI/Anthropic where agents build something that nobody uses might be hard to track given that there are zero users. But what about everyone using agents for real software? It's trivial to prove that agents make progress.
I think the reliability struggles of Github may have helped with this
I can't help but wonder if the causation is backwards here and the millions of lines of slop had more to do with the Github struggles than the reverse
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.
>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.
Why? If you can deliver the same thing in fewer correct lines of code wouldn't that be preferable? At a bare minimum if you're still insisting on using AI to slop out your project, having it do things in fewer lines of code means you can fit more into your LLM's context window.
> If you can deliver the same thing in fewer correct lines of code
it really depends on what you're doing. If your goal is "become interoperable with the N different and incompatible network protocols that people have devised for doing task X" I'd really like to know a solution that doesn't have at least some part of the amount of code that scales with N.
Example: consider https://bitfocus.io/connections which connects to 700 different things. Right now it's written with Node.JS, with one repo per connection (example: https://github.com/bitfocus/companion-module-meyersound-gala...). Let's say you want to make a similar product but that runs on ESP32 where performance is paramount so you need C++ or Rust. How do you do that without at least as many lines of code as the existing JS implementations for every system supported by Companion?
Without looking at the details, I expect that each network protocol has a checksum of some form, and there are likely a lot less than N different checksum algorithms. Similarly I expect several will have encryption - using one of a few standard algorithms (if any doesn't use a standard algorithm you have a strong case to say not supported). I also expect that there is a lot of protocol parsing - this can be done as custom hand coded for each, or using a parsing framework (and likely there are some places of generic code in between).
Then you simply produce those fewer lines of code even faster. The question is, how fast are you delivering correct code?
Moreover, writing too terse code harms readability and maintainability. There is such a thing as irreducible complexity.
> 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.
I think engineers tend to over index on this kind of thing being "waste". You didn't waste that investment, you paid for the option to ship that feature or MVP and the research into the question of whether it made sense to ship it.
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 non-technical people are in charge and they're not tethered to reality in the same way that engineers are. Objective reality will win in the end, but that doesn't prevent damage being done in the short term.
IDK, I do think a lot of it is LLMs enable people who were not in our community to come into it (in an eternal september kind of way) and they are going through all this from first principals and ignoring their elders, but I've also seen technical people suddenly measuring themselves this way. The most optimistic read of this is that they _feel_ productive, and that feels nice, and they want to share how that feels, and so they are reaching for these garbage metrics because they have nothing else.
All that to shill slop machines so the billionaire class can throw people out on the street.
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?
I think LLMs will make vertical slice architecture more common using less abstraction. If juniors are mostly relying on LLMs then they will accept the long files it generates and not have the opportunity to learn abstractions.
>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?
> They want the same productivity by paying fewer more productive people.
I believe you mean same output but fewer people? But by definition that would be higher company productivity, as the definition of productivity at the company and/or national level is the ratio of outputs to inputs. If you have fewer people but are getting the same output, then the productivity of the company (or nation) has improved.
If you had fewer people but the same productivity then there would be no benefit to the company as the outputs would correspondingly be reduced (and it may actually be worse for the company if the company has any fixed costs).
https://www.mckinsey.com/featured-insights/mckinsey-explaine...
> 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?
Because labor gets exploited to make the owners richer. That's the basic fact, even though the owners (as a class) have financed a lot of propaganda to justify and obscure it.
> Because labor gets exploited to make the owners richer
Only a person who never tried to organize labor into a company could ever have such a couch-sitter opinion
>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…
When the AI CEO says it, its because stock go brrr. I never believed that AI CEOs because they're making unverifiable claims that they never backed up, claiming you're firing people because of AI is so open for interpretation, and it shifts blame from you to the AI, reality is we should not blame AI for something a CEO did, you could have re-trained employees for AI, but you didn't why not? Maybe because it's not about AI is 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.
AI is the new cloud. There's no market for people or companies who aren't committed to it. If you're a dev who refuses to use AI, no company will hire you; and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs). Their investors and big-ticket customers will also think twice before signing off on major commitments.
So yes, use AI. Don't nitpick the costs and benefits. The world is headed this way; if you want to develop software for a living and afford to eat, you need to be too.
> and should a company decide not to use AI they will have a hard time retaining devs (and they will need more devs)
Need more devs? Why? If a company was being profitable just fine prio AI era, they will still be profitable if they decide not to use AI. Shipping crap faster is not a formula for success. Shipping quality faster? I prefer shipping quality at a good pace
youll be outcompeted by companies that do use it (caveat: effectively)
growth is much more important than profitability
Enjoy getting your milkshake drunk by AI-first companies then.
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 just wants another lambo in the garage, and doesn't really plan to be around, when it's time to pay the piper.
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.
> Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
https://www.goodreads.com/quotes/536587-measuring-programmin...
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.
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.
Yep, pendulum swung one way, now swinging back the other. No different than any other hype cycle.
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...
>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
Yeah I think it also really depends on what your business is. Many or most of us here (and likely also the author) work in the kinds of tech-forward businesses where competition is fierce and velocity is essentially. But there are many many businesses, and also tons of public sector organizations, where this is not the case. Leadership in those organizations should probably be going a lot more slowly, waiting and seeing, letting all the fast movers fight it out through all this churn, and adopting only whatever eventually rises to the top.
Yeah, that closing message was a little weird to me. I understand framing the article as "not anti-AI", especially if the author uses and enjoys the tools. But the end sounds like a call to blindly adopt the tools and figure out the justification later.
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?
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.
Confusing skeptic and sceptic will never not be funny to me (edit: I now live in shame)
Then I think you are the confused one, as they mean the same thing but one is US and one is UK+NZ+etc.: https://en.wiktionary.org/wiki/sceptic#English
I think you’re reading “sceptic” as “septic”. They are not the same word.
About as funny as “confusing” color and colour. Which is to say: not very.
Skeptic and sceptic are pronounced identically, because they are just different spelling of the same word.
Damn it - well, I'll never live this one down, I'll learn to shut up next time
Nah, as long as you're good a sport about it, it's all good. In fact, it's refreshing to have someone make a mistake like that so confidently, and then own up to it immediately.
It shows good character to own your mistakes.
Sure, live in shame, but don't let go of the humor in it all :)
I did get quite a laugh when the comments made me realize what an asshat I was
Sceptic is the UK spelling of skeptic.
Maybe you've confused it with septic?
How do you mean? Guy was born and raised in New Zealand and is using British spelling. There is nothing confused or confusing about this.
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
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.
> So maybe it is, indeed, time to panic a bit?
Anyone relying on a steady paycheck from an employer should panic a bit all the time, because nothing can save them from bad management. The reference to Jevons Paradox doesn't say anything about individual managers responding correctly. If 30% of managers screw up, that's a lot of collateral damage.
Now to respond to your actual point, I don't think software developers should panic. Even if pure software engineering gets hit hard, I'm having trouble imagining a scenario where years of software development skills plus knowledge in a specific domain isn't a good thing for current software developers. This is unlike what happened with international trade, where you had 60-year old textile workers losing their jobs, no alternative jobs, and no policy being offered to compensate them for the effects of trade.
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.
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...
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.
Was writing code ever the bottleneck for anyone other than raw juniors and non-programmers?
One thing the AI tools have taught me is that it hasn't been my personal bottleneck for at least a very long time. It's made that part faster for me, and that allows me to take bigger bites at the apple each iteration, but it's not meaningfully speeding me up in the way people claim.
Depends on your company. I'd say very rarely, and never for long.
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.
'something that solves enough users problems it's worth it to implement it' rather, and I think it is often difficult to judge how much engineering time to spend on user issues.
I'm currently working in an internal team, so I value cost savings estimation, but even before prioritising was also a bottleneck (although a small one compared to architecture and design)
I don't get how if productivity is barely moving, how a decrease in comprehension will improve anything.
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?
> "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...
> I think every engineer should be using AI daily.
Why?
Please read the full paragraph for the answer instead of cherry picking a quote for a knee-jerk reaction:
> Be curious, try the new tools, test the latest models. To not do so is silly. > [...] > you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months. The way we work has already changed, and it’s not changing back as far as I can tell.
> you could delay adopting “the cloud” for a couple of years and survive. With AI you might get a few months.
I really dislike these claims that act like they know the future of engineering, that they’ve been let in on some enlightenment that we haven’t been. What’s going to happen in a few months? Is Sam Altman going to nuke my house from orbit? Or is it because my CTO is going to fire me for not using AI? If it’s the latter, that’s not a curiosity problem, that’s a “there’s a gun to my head” problem.
It seems to be based on some idea that there's no way you can be productive enough without AI. But I've yet to see any companies really shipping meaningful software at some unprecedented speed that was not possible pre-AI. Instead, I see a lot of half baked features and buggy apps. I am not convinced that those that choose to either NOT use AI or use it more sparingly / judiciously (my preference), are somehow going to be "left in the dust".
Yeah, I’ll second that. I see folks moving _fast_, but boy oh boy are they breaking things (or delivering something that never worked) which if anything makes _me_ slower lol
And also delivering things nobody wants or will use, just because they can.
I read the entire paragraph, and the entire article. Nothing in there explained to me why every engineer should be using AI every day.
Because I don't think that's the point of the article, which is just a commentary about how AI labs are marketing the effectiveness of their services by using terms like "8x more code per quarter" like that's an obvious good thing (which it isn't).
If you want a more in depth explanation, go look for interviews with devs who were already super-productive before LLMs and now came around to using them everyday.
Because it's fun. And why shouldn't we be into incremental automation?
I still write code manually to keep my trad-coding skills from withering away, but using AI without a doubt has allowed me to better test my existing apps. Create playwright automations I would've never had the time for. Allowed me to search through docs many times faster. And it just making programming more fun when I do use it for more challenging problems, and I actually get something working at the end of the day.
Sounds like it's working for you, but none of that explains to me why every engineer should be doing that, and every day
How do you get to discuss without going to the article directly
Click the "n comments" link, like you must have done to post this comment?
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)"
We need a Slop Audit methodology.
That is why I have created one (Open Honest Slop Audit).
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.
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.
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.