Top
Best
New

Posted by florianherrengt 6 hours ago

AI is removing the middle class of software engineering(blog.florianherrengt.com)
474 points | 395 commentspage 4
jadar 3 hours ago|
I appreciate that the OP puts his finger on the problem. I think he's right. I wish there was more optimism or ideas about how to solve it, though. How do I fight against it as an engineer? Or, how do I become a "good" engineer? It feels like sometimes the only solution people have is effectively "don't use it."
adamtaylor_13 3 hours ago||
It's not clear to me what "the middle class" is supposed to be here. All engineers exist on some spectrum between "good" and "bad" and it's pointless to try to identify the exact markings, but we all know good engineers and bad engineers.

So AI isn't really doing anything but giving sharper tools to both groups.

So, as it was before, we simply need to set expectations and remove those who cannot adapt and meet expectations... You know, the way it's always been.

So why is AI the problem here?

game_the0ry 3 hours ago||
Writing code was never the job. Creating value was the job -- coding was just how to implement that goal.
mattbettinson 1 hour ago||
I shudder to think of anyone in the industry this would be mind-opening to
Kinrany 2 hours ago||
"Creating value", "making money", etc. are meaningless
TiccyRobby 3 hours ago||
The premise does not make any sense, it is a technical culture problem which you need to enforce. If you let it go wild, yes it will go wilder than ever but this is relatively trivial problem.
maerF0x0 4 hours ago||
> In the story above, everyone is failing:

IMO The author fails to list the hypothetical person with 13 PRs to review is also failing.

> * The engineer who refuses to change with the times

IMO many of the old ways of software engineering were local maxima. We're still seeking how to hit a new maxima and the journey may take us through zones lower than the previous local maxima.

florianherrengt 3 hours ago||
I use AI heavily, so this isn’t about refusing to change.

You still have to understand the change yourself if you’re going to take responsibility for approving it.

That work is fundamentally much slower than generating the code, even with the help of AI.

We’ve made producing a large change extremely cheap and fast. We haven’t found an equivalent shortcut for building a correct mental model of what that change does, how it interacts with the rest of the system and whether the decisions behind it are actually sound.

Maybe one day we'll find one. As of today, I don’t think we have.

jplusequalt 3 hours ago||
> * The engineer who refuses to change with the times

There is plenty of software in existence where being incorrect, even once, can spell disaster.

Everything about the picture being painted in the article is anathema to keeping such systems safe and reliable.

i_idiot 5 hours ago||
So, blame the engineers now? Most likely they were forced by a manager to push more PRs faster else piped.
florianherrengt 3 hours ago|
[dead]
ryandvm 4 hours ago||
Lord, this hits close to home.

It doesn't seem to be happening everywhere, but if you are unfortunate enough to work someplace with a "LinkedIn thought leader" high up on the engineering food chain, there's a really high likelihood that your organization is currently in the throes of an "everyone must be using AI for everything" fever dream.

And boy let me tell you, it is every bit as disastrous as the OP claims. Engineering managers are asking Claude to write up entire initiatives, then they hand off these nebulous AI slop manifestos to the teams where the requirements folks are having Claude shit out tons of superficially plausible Jira tickets. It finally lands on some poor engineer's plate and since these tickets are the technical equivalent of Finnegans Wake, they just end up asking Claude to read all this shit on `ultracode` and draft up a pull request. Which is then peer-reviewed by somebody using Claude.

I wish I were exaggerating.

alpha_squared 2 hours ago||
Anecdotally, the essay is so spot-on. In my last job, I'd regularly have to review +20k-line change PRs from mid/junior devs only to reach a point where I'd have to just shut down the PR and ask for it to be broken apart. Sometimes, the issue would get escalated and I'd have to speak to their management/director chain. More often, they'd realize that if they spent some time trying to understand how to break it apart, the changeset actually needed to be much smaller and I'd come back to a 400 or 500-line PR to review.

In one particular case, a senior teammate of mine went the extra effort to actually explore what the intent of the change is and created a whole new PR for the junior dev that was a simple configuration change of 5 lines instead of the 14k lines they put for review.

This is utterly unsustainable and something will give at some point.

crnkofe 3 hours ago|
All this mindless droning about societal collapse, destruction of jobs, people moving on is really getting old. Sure people have caused mayhem by following (and enforcing) bad practices which resulted in a toxic workplace, a mix of pissed of client due to constantly failing to reach deadlines, unimaginably bad codebase that was a horror to work with and teammates each defending their own turf. LLMs now allow this deterioration to happen much quicker and more effectively.

On the other hand the problem can also be triaged quicker and rewritten faster. Pretty much every startup I joined had at its core disastrous code written by students and overworked techies. I can totally see this shitty base being the future base all startups. It'll likely need an army of agents or devs to make sense of all the spaghetti being written. I won't be surprised if demand for devs skyrockets after the first generation of spaghetti western code "matures".

More comments...