Top
Best
New

Posted by florianherrengt 9 hours ago

AI is removing the middle class of software engineering?(blog.florianherrengt.com)
628 points | 514 commentspage 7
dmezzetti 5 hours ago|
As an open source maintainer, I can chime in on this.

With TxtAI, I've seen a large uptick in PRs (https://github.com/neuml/txtai/pulls?q=is%3Apr+is%3Aclosed+s...). While the extreme verbosity of Claude messages and commits is very annoying (plus the constant defending itself on why it's a bug), I do think it's a positive that more people are enabled.

It does require reviewing the PRs. Some can be tricky just like a human. For example I did merge this PR (https://github.com/neuml/txtai/pull/1136) and it would have completely broke search. But a human could also do that.

From an open source standpoint, I say the more the better. You just have to be willing to do the work to review and no not just having AI agents to review what the AI agents are submitting. There still needs to be a human in the loop, if you care about quality.

waffletower 6 hours ago||
While there are bad engineers, I imagine that teams that have evolved alongside AI and have maintained their size and consistency without adjustment may have structural issues. I would argue that team size counts ought to be smaller now than before Claude. Unfortunately this idea could feed an AI-induced layoff trend, but it could instead lead to product diversification instead.
1294876 7 hours ago||
"There are also people who essentially make it harder for everyone else. And now anyone can produce more code in a day than they used to in a year."

That is the "democratization" that AI shills speak of:

https://xcancel.com/dhh/status/2087538364580835804#m

Once a CEO with a snowboard-optimized brain gave you a board seat, there is no way back.

jdw64 7 hours ago||
I'm not sure what skill really means, or what's considered bad anymore. AI coding ability and human coding ability are different, and different organizations need different skills. No skill is inherently bad—it just depends on what the organization needs.

I understand that AI writes better code than people like me in many cases. But an industry should still provide opportunities for those people. And sometimes those people create things that are better than AI in certain areas. The problem is when even those opportunities are taken away.

florianherrengt 5 hours ago|
The industry doesn’t really owe people opportunities. Even if you think it should, that’s not how companies are going to behave.
jdw64 4 hours ago||
That is an incredibly short sighted view. By acting this way, the industry is essentially selling its future for short term gains. A systemic reduction in the number of people capable of maintaining systems directly correlates with an inevitable collapse in overall software quality.

The perspectives of market advocates often stop at this short sighted level. In reality, their modeling is incredibly simplistic. I will not elaborate at length on their poor modeling here. The short sighted local optimization that only chases the margin of the next quarter is the exact enemy we must guard against the most. (Of course, given the nature of HN, this specific part of the comment will likely be attacked.)

It is not a matter of companies not owing anything; rather, companies are actively committing self sabotage.

Is it truly right to eat tomorrow's seed corn today?

The essence of the software industry is not the 'generation' of code, but the 'maintenance' of it throughout its life cycle. Why is Linux continually maintained, and why is Windows continually maintained? The core of this industry is fundamentally tied to the entire life cycle of a product.

You might be able to fix code with AI. However, under the current LLM structure, can it actually modify projects spanning hundreds of thousands or millions of lines? It cannot. The skill required to partition those architectures is still entirely left to humans. And the ability to define those boundaries is born strictly from experience.

Labeling certain individuals as useless or inadequate inherently destroys the resilience and buffer of the collective as a whole.

Why do humans embrace and care for the vulnerable when society has the capacity to do so? Why do we strive to preserve diversity? It is because, depending on the context, those very traits might prove to be more advantageous. Every human possesses distinct skills, and their unique temperament and proficiency simply manifest depending on the situation they face.

florianherrengt 2 hours ago||
[dead]
jqpabc123 8 hours ago||
In the words of Admiral Ackbar, "It's a trap".

Any apparent short term gain is really a prescription for long term pain.

Ignore what AI fanboys say and instead look at what they do.

https://northeasttimes.com/2026/08/07/oracle-bans-ai-code-fr...

tp3358 7 hours ago||
Is it long term pain if a small startup in a very competitive vertical gets to market quicker with code gen and finds market fit? Whether that results in a rewrite or a refactor, that is still a huge win and one that a lot of people will gamble on.
dgellow 7 hours ago|||
Do you have examples? Ideally a startup that isn’t itself selling AI to other AI companies
florianherrengt 5 hours ago|||
Debt is debt. Some of it is absolutely worth taking on.

I don’t have any issue with intentional debt when you understand the trade-off and have a clear payoff plan.

packetlost 8 hours ago|||
Oracle banned AI code for copyright reasons, you cannot interpret that as a assessment of the practical output of the models.
stonefoot 7 hours ago|||
That's only one of the three reasons in the article: 1) Reviewer burden - LLMs can produce a deluge plausible but incorrect code which can overwhelm human reviewers. 2) Safety and Security - Many corporations depend on the JDK so stability is a high priority. 3) Copyright/IP about who owns submissions generated by AI is not settled in law.

The article also goes on to compare the JDK teams policy to GraalVM, also in Oracle which is more similar to the Linux kernel policy, where AI submissions are allowed, but the human submitter is accountable to them, which is reasonable too.

It's not unreasonable, in my opinion, for the JDK team to limit AI contributions based on their stated priorities, just like how other teams might not require those same restrictions.

ok123456 7 hours ago||||
Oracle banned AI code from a public project they maintain and backport/share with a commercial product because they're a very litigious company, anticipating future legal cases.
SpicyLemonZest 7 hours ago|||
It strongly argues against a position that many people including myself have taken, that all code will soon be AI code and the only people still writing code by hand are those who haven’t gotten the memo. (I don’t mean to rule out the possibility that Oracle, despite their involvement in AI infrastructure, is just being dumb and the lawyers made them create a policy that’s not compatible with the modern practice of software development.)
gfhhnki 7 hours ago||
Just look at how they bragged for a year now about how AI built entire apps with a single prompt.

And now that code is being watermarked by AI, suddenly they’re artists, painstakingly prompting, crafting, to get just the right code; the watermark is unethical even!

AI psychosis is real, and even some of the smartest people I know how succumbed to it.

j45 6 hours ago||
Ai isn't removing the middle class of software engineering.

Software engineering is evolving, and the middle class (and beginner) is going to have to grow instead of being able to leverage the same skills for longer and longer.

It's so true from some of the other posts that you can outsource your thinking, but you should never outsource your learning and understanding.

fithisux 7 hours ago||
Very good article.

But it does cover the case where someone makes it to the top if he/she is junior. Who experience is gained?

Maybe I ask too much from a short article.

florianherrengt 5 hours ago|
[flagged]
KronisLV 3 hours ago||
> But once you start storing data there, you can't just remove them. You have to come up with a migration plan, make sure you don't disrupt the system because people are paying to use this every day. You have to think about what you'll do if the migration fails. Make sure you don't end up with orphaned foreign keys. It's just so much harder to fix. Even with the best model you can get.

Migration plan? Just ask Claude when shit hits the fan. You'll make a plan when you need one.

> By the time you've untangled one bad decision, five more have been merged.

I'm slowly (partially ironically/sardonically/nihilistically) adopting a mindset of accelerationism towards the collapse of software development - it was largely done wrong from day 1 and wasn't "real engineering" to a sufficient degree to not lead to the mess that we've been in maybe for the past 20-40 years. The only thing AI did was take away the brakes and press down on the accelerator, we're already headed towards a cliff and have been for a long time.

If the code in airplanes and spaceships was developed with the same degree of care and attention as "good code", you'd see those dropping out of the sky regularly. If they built bridges like we build software, they'd fall apart regularly as well. Good code CANNOT hinge on the opinions of some senior dev, or even a group of them - it must be provably good. And if it must be provable, then these checks must be automatable. Bad code (whatever that means, however you'd manage to classify the difference between AI slop and what you want to see) should be IMPOSSIBLE to get into the system at all, due to those automated checks.

Be it good enough test coverage, automated checks for usability and end to end coverage of the features, project/domain specific lists of architectural rules (think ArchUnit), needing proofs not just tests etc. We will never have that - our OSes are bad, our browsers and other essential software is bad, our programming languages are bad (the fact that unchecked exceptions even exist in languages is a cardinal sin), same for databases and tbh any other class of software you can look at.

This impassioned comment might border on a rant, but my argument is that the past decades aren't the baseline of good code, we'd probably need to spend 10-100x more effort to produce 100-10x less code, but make the existing code bulletproof - there is no reason for more than one OS to exist, no reason for more than one UI framework to exist (or even all of the egregious ways how the web platform was transformed from documents and links to a collection of badly written apps, which eventually infected the desktop with Electron, due to the native GUI development also being severely neglected), no reason for more than one web framework to exist or even more than one programming language to exist in mainstream usage outside of research and looking for the solution to use for the next decade/century of software development. Yes, I'm exaggerating, but the correct answer is probably closer to 1 than to 1000.

Obviously that'd lead to death by comittee and some degree of experimentation is necessary, so hey we end up with a new slopped together library every week and I know nothing and nothing works anyways. I wonder if we had ONE high level programming language, whether over time it would have evolved from C++ to Rust (sans odd parallelism), and if it was based on formal proofs, then migrating between language features could have also been fully automated, alongside enough pushback to any feature deemed not worth it. On the other hand, even with all of the world's developers concentrating effort, something like that might be above our cognitive abilities, so probably not - just too hard to reason abuot.

jplusequalt 5 hours ago||
This blog conflates productivity with expertise.

Are LLMs rewarding experienced developers with tons of productivity gains? Yes.

Are LLMs actively degrading their expertise of understanding code? Also yes.

This article has made the implicit assumption that the top quartile of engineers are immune from skill decline. They're not. If you're an engineer who increasingly outsources the planning, writing, and analysis of code to an LLM, you're losing your ability to plan, write, and analyze code.

All of this is to say--senior engineers who have fully adopted AI tools are blowing smoke up their asses to dodge the reality of their own obsolescence. The senior engineers can talk about productivity all day, but they're only marginally closer to understanding a complex system that was written by LLMs than the "middle class" of engineers are.

You reading this--yes you--get over yourself. Your skills are depreciating too.

florianherrengt 3 hours ago|
[dead]
deadbabe 5 hours ago|
A pattern I have noticed is you get way better results if you just have one skilled senior engineer coding everything with AI vs a lot of people.

Having large teams in the age of AI is pointless. It slows things down and spreads accountability too thin.

When you have one good engineer doing many things, a lot of stuff lives in their head and they know what to look for in their own PRs. Also, people tend to like their own AI slop, but not others. So overall you will have at least an engineer who is satisfied with the codebase vs a lot of people who either have some gripe about something someone else did, or just don’t care at all.

That means you have to put way more trust in a single individual, but if it’s the right individual you propel the organization further ahead than a team of mediocre engineers or senior engineers limited in what they can accomplish.

More comments...