Comment by ryandvm
11 hours ago
It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around. Before 2025, the underperformers/coasters were at least relatively identifiable by the paucity of their contributions. Now all of the sudden every single engineer is filing PRs, code reviews, technical design documents, and every other artifact under the sun with perfect formatting and at least superficial plausibility. This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible, but it's also just a game theory respopnse because it's in every engineer's best interest to be as prolific as possible.
We are absolutely drowning in documentation and code that seems legit and the only recourse is to lean on AI to help process the sheer quantity of it. I have a feeling that the fallout from this phase of the industry is going to be an exotic form of technical debt that is remarkable mostly in its enormity.
I'm sure this is gated by where you work (especially by how technically savvy your manager is), but the most effective contributors at my job tend to be the ones with near-zero (or sub-zero!) net LoC.
LLMs are prolific and they love to add shit. Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts.
"Truly capable engineers are able to achieve more business outcomes with less code / fewer moving parts"
I'd simplify to "Truly capable engineers are able to achieve more positive outcomes" - half of what makes a capable, dependable engineer is knowing what outcomes are needed and making them happen.
Good revision!
I really can't agree with this. Sure pure LoC is a bad metric. But there is a correlation between output and LoC. Outside of a very senior developer, maybe a Principal or Lead that is spending all day in architecture meetings and reviewing PRs, most high performers are also outputting code.
This is exactly what the article is addressing:
> But there is a correlation between output and LoC.
That is less true today than it ever has been, due to LLMs.
"High performers". Can't believe we have normalized this vocabulary, among us, "hackers".
3 replies →
The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.
We had a library written by a former employee who was a prolific producer of code. He insisted we needed it and spent over a year developing it in company time.
The library was a masterpiece of what if driven development. It was about 50k LoC, and it had 300k LoC of dependencies. It was a nightmare to modify. And no one wanted to take over maintenance so people would submit PRs to the former employee when they did modify it.
I wanted to change something in the library to support a large migration I was in charge of. When I went digging it turned out that we were barely using any of the features in the 2 years since he’d finished it. I replaced the 50k LoC library and 300k LoC of dependencies with 300 lines in less time than it would have taken me to modify the library (a few days).
1 reply →
Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC.
High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.
8 replies →
> The most effective contributors at your job remove more code than they add?
Yes.
> That doesn't sound effective that sounds like digging ditches to fill them.
It sounds effective to me, like removing garbage from sidewalks so people can walk straight instead of walking around the trash.
> Every line of code removed is a line that was previously added.
Correct. Today I cleaned up
to
and contributed various other negative lines of code in multiple areas.
Every line of code removed is a line that was previously added.
Do you have any experience coding before LLMs?
3 replies →
> The most effective contributors at your job remove more code than they add
Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks)
> Every line of code removed is a line that was previously added
Yes. This os not a failure. Code has a surprisingly short half-life.
4 replies →
Thought experiment: if you can solve a problem with 100 lines of dependency free code, or with 10,000 lines of code that depends on hundreds of things - which is better?
There's an obvious answer of course. And that is the direction that these effective senior engineers move towards.
I definitely agree with the GP, and the point is that most often someone else (or an LLM) added all those LOC that are removed to make the system sensible.
> That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.
Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them.
The idea that "I would have written a shorter letter, but I did not have the time" also applies to code, and sometimes later you are blessed with more time than you had when implementing something under deadline pressure.
3 replies →
… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.
if you're trying to use sloc as a proxy for productivity in any way, shape or form you've already lost the game.
i tend to find that the most productive teams make better decisions and work fewer hours. the quality of decisions is such a huge force multiplier that it renders actual hours worked almost an irrelevant variable.
YES! this is exactly why at $work we have moved from loc to number of pr's per week!
in fact, i've sent over 20 variable rename prs and am now topping the leaderboard!
• LoC/LOC = Lines of Code
• sloc = Source Lines of Code
.. so I suppose nloc would mean Net LoC
[dead]
There are also people who think AI is magic. I have often heard - "we want to use AI to automate processes but we don't have full documentation about the processes, we hope AI can help". Despite being told that no one can create outputs from thin air - every AI topic turns into the same discussion.
Often the solution to create those document to feed into these AI automations? Use AI. Its like ouroboros. Create docs using AI, then summarize and ingest using AI, explained by AI.
Same thing is going to happen with code. Create 1000s of line of code using AI. Then explain it using AI etc.
> It is now significantly harder to figure out who understands the systems and is using AI effectively and who doesn't know shit and is just slinging LLM copypasta around.
It's okay, I'm sure the algorithm questions during the interview phase totally weeded out the fakers of systems knowledge right?
>I have a feeling that the fallout from this phase of the industry is going to be an exotic form of technical debt that is remarkable mostly in its enormity.
This.
I feel like it is going to become illegal for older engineers to retire until its all cleaned up. When the debt catches up its going to be civilisation level problem, like asbestos or lead.
Illegal? Get fucked. They will retire and you can deal with the mess, you have AI.
When you can no longer pay off technical debt, you turn to technical bankruptcy: start over from scratch, greenfield.
I predict what will happen is eventually the number of technical bankruptcies will rise, and there will be some new movement to only build codebases that fit within human heads, no AI required. This means no more architecture astronauts or code bases where you spiral around massive abstractions just to implement simple features. I look forward to this, as it will become a sort of competition between engineers to see who can do the most with the least amount of new code.
>Illegal? Get fucked. They will retire and you can deal with the mess, you have AI.
Considering the balance of my job is cleaning up technical debt, that's my own retirement I am worried about.
>When you can no longer pay off technical debt, you turn to technical bankruptcy: start over from scratch, greenfield.
What that looks like in say, 2030, I can only guess. We saw this happen to a multinational shipping company due to cryptolocker, but I dont know if theres going to be any interest in replicating that. Certainly the AI barking in the ear of the CEO isnt going to recommend it.
>I predict what will happen is eventually the number of technical bankruptcies will rise
Outside of industries required for national security maybe.
> there will be some new movement to only build codebases that fit within human heads, no AI required.
I suspect that rational governments are probably going to require No AI clauses in their tenders, but that we will also get hundreds of high profile "Whoops we used AI in this contract when we shouldn't" scandals that come to nothing.
I've even seen AI-generated roadmap documents that promise the world, are broadcasted to director+, who sign off without a thought.
Words and code are so cheap they're meaningless, while human focus, attention, and understanding are so expensive and overloaded.
Maybe the solution is to look out for the most silent engineers. Those that output less despite having the ability to create near infinite output.
Not sure how to understand that. You mean as the best engineers?
Funnily at my company, the few engineer that did the majority of the work before AI still do the majority of the work now. By majority I mean tackling both more issues and better.
However there is a general verboseness and over engineering trend across the board.
I've been thinking about the manga Blame! a lot recently, where the entire story takes place in a run away machine built mega structure that is larger than at least the solar system.
I think it depends a little on how and where you work. In the energy industry of Europe where we are extremely regulated AI has been writing some excellent and maintainable code. Of course we can't do any of that CLEAN SOLID DRY stuff, or any abstraction and implicity really, and I imagine that AI would struggle with that. Though you have to wonder if any of those religions ever really worked when you consider that they've still failed to replace most COBOL systems 30 years later. Anyway, that's a different discussion and even Uncle Bob has moved on to functional programming.
I've yet to have Opus 4.8 fail me with defensive explict code. Often it'll write code that is better than what I might have done. I imagine it would be a nightmare to go through one of the OOP debug chains with implict error handling, but when every function has a runtime assertion which is basically the contract for how it is supposed to work and exactly what to do if it encounters a corrupt state, then things are just so much easier with AI.
I do agree with you on documentation. The amount we have has exploded in the post AI world. Which is a little ironic since the assertion is frankly what you'll need to know and not the 10 pages of prose the AI autogenerated in the shared loop (microsoft's terrible confluence). It is what it is though, and at least it's easier to meet EU compliance rules now, since those are more about the bureaucracy than actual security.
You'll recognise the good engineers as the ones that remove code.
>This is mostly due to incredible pressure from the C-level for every engineer to be using as much AI as possible
I think this is an important point. Software engineers always had the right instincts on how to approach AI for coding -- cautiously. Execs got too coked up on LinkedIn puff pieces from nobodies and adver-prophesizing CEOs selling their tokens and chips that they forced something unnatural upon their orgs.
Now what we see in the software dev space is incredible levels of malicious compliance ("you want slop, I'll give you slop").
I don’t know. I mean, I agree with you overall, but it seems like tons of engineers, especially here on HN, have been more than willing to go all-in on AI for at least the past year, with many dire warnings of “coding is a solved problem,” “if you’re not programming swarms of agents, you’re going to be left behind,” and so on.
This has not been my experience with my fellow engineers IRL on average, but I do feel like there is a significant contingent of us who are ready and raring to yield engineering in its entirety to the LLMs.
Eh, are you using the loop engineering effectively? Remember, Boris can merge more than 200 PRs a week mostly with merely a phone and despite his busy schedule. Anthropic engineers do not write code manually any more, and they don't need to review most of the code either.
In all seriousness, though, I'm indeed curious about Anthropic's engineering practice, particular how they can achieve such level of autonomy.
Remember Facebook's original motto: Go fast and break things. That's where the speed is coming from.
Anthropic's speed of development is about 20% AI and 80% technical debt. We all could be faster if we stopped trying to build things right.
Once Anthropic floats, I predict a screeching halt in feature development to fix all the technical debt that they're accumulating.
AI usage perhaps will have to be monitored by AI.
This game-theory phase seems to go hand-in-hand with totally myopic grift/gig/hustle thinking too. There is no product but the confidence act needed to win each moment.
Chalk up yet another echo of the 1920s Gilded Age? Between all these economic spasms and the simultaneous tilting towards fascism, I think there is way too much historical rhyming going on right now...
So, in other words, all the "awesome engineers" can't really tell good code from bad unless it's really obvious? Why should we listen to you about AI code being crap, then? Maybe, in the end, you don't really know. Maybe AI is better at it than you?
No. Your AI tool that summarized the comment did you dirty. The key here was this:
> perfect formatting and at least superficial plausibility
Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem. Before, they coudln't stand up a fake library.
The issue comes down to time and effort.
> Basically, a library full of books that have nice covers is going to take time to see that all those books are just filled with ipsum lorem
Worse if it’s a mixture of good content and ipsum lorem.
[dead]