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 writer, back in February[1], noted "Every major tech CEO is now competing on what percentage of their code is written by AI"

1 https://www.thepragmaticcto.com/p/lines-of-code-are-back-and...

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.

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

[flagged]

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.

[flagged]

[dead]