AI is removing the middle class of software engineering?

> bad engineers were always a liability

This part of the article hits home for me. With AI, "bad" engineers can now amplify their "bad" engineering x10 across the organization. The most egregious of these cases for me is often long tenured engineers who have lost interest in the craft, creating a dangerous combination of having enough merit to ship but not enough interest to make what they ship _good_.

I am still a firm believer in garbage in -> garbage out, AI is only as good as the abstractions and contracts you put in place for it. I don't subscribe to the idea that AI generated code is fundamentally bad, just that people lack the right skills today to wrangle agents into writing good code.

Earlier in the year I put together a talk for my company on what the future of architecture & design means for us in the career, I'm very proud of it and will share here in case folks have their own thoughts to share on the topic: https://youtu.be/SIZrt9Rt05Q?si=W57eirniWmoSFeBu

I think of it more as "the automation of the stackoverflow engineer". In enterprise software, there has always just been a non-negotiable large volume of code that was required to be written. This has traditionally been offloaded by having seniors do the hard thinking then distill it into a jira ticket which could be handed off to an engineer that'd actually write the code and punch every hiccup into google along the way. This hand off is no longer necessary as that same senior can just kick off an agent and have it handle the implementation for them.

I've heard some refer to this as a "nature is healing" scenario for the industry where if you only signed up for a high paycheck and didn't care to think critically about any of the work you're doing then this will be painful because that previously manual process has been automated. The floor of what's necessary to be considered valuable has been raised.

This blog post illustrates the importance of NEVER outsourcing your critical thinking or outsourcing decision-making to an LLM. And to never take shortcuts with learning. Learning is hard, but learning things properly allows you to understand what is happening and allows you to ask the right questions about whether the changes an agent wants to make are the changes that will best serve the goals of the project (without creating an unwieldy level of tech debt in the future).

Personally speaking (and I'd love to hear others' takes on this): when using an LLM for work-related and development tasks, I never use the "full-auto" mode, and I never manually approve of something that I don't understand. When I don't understand something an agent wants to do, I go on a side-quest to learn more about said thing and to educate myself first. This takes extra time, but I feel that it's the right thing to do, so I can at least approve/deny/redirect from a more informed position, rather than flying blind and hoping for the best.

In addition to what the author discusses, I think skill-atrophy, stagnation due to complacency (i.e.: "why grow and learn if an agent can do it" mindset), and cognitive laziness are additional risks that come with overrelying on LLMs. Humans were meant to think. LLMs are a tool.

Technology has been doing this for decades. I think a lot of our "K shaped economy" discourse is about the bifurcation of the upper middle class creating downwardly mobile educated young people. Nobody in my wife's immediate family finished college. She and all of her cousins are quite indisputably better off than their parents. My father in law drove a forklift at a soup factory. My sister in law is studying to be a nurse. It's a big step up. But the "white collar" middle class has become very winner-take-all. To use an example from my field, if your dad was a partner at a regional law firm, that path probably isn't open to you. Technology enabled consolidation and scaling, so you don't need lawyers in every city in the U.S. to be able to handle legal work there. Lawyers at national firms serving Wall Street clients are making more money than ever, but the drop below that has become pretty precipitous. The same has happened to small businesses all over the country competing with Amazon, etc. It's had a huge impact on the petit bourgeoisie.

Of course, this is economically efficient. Nobody is going to give up Amazon same-day-delivery so that some local small business owner's kids can live better than the median person.

Between AI and competing against the world with H-1B, it's really never been harder to get an entry or mid-level software engineering job.

Which means our pipeline to senior engineer is completely broken.

>AI makes projects with weak engineering culture fail much faster.

>There used to be a time when people sat down and talked about how they'd do something. Now they can just prompt an agent for a few hours and open a PR.

>The most tragic aspect of this way of working is that, to the untrained eye, it works.

>If you pull the branch and test it, you'll probably get something somewhat functional. So what do they do? They keep going. Again and again. Until the project reaches a point where no one knows how anything works.

Isn't this the opposite of failing faster, it lets people who would have never made it past the first few hurdles and give up get deep in and then the false hope that they can then prompt their way out of whatever mess resulting in deeper and deeper spaghetti.

> You were never expected to understand every service and every database. But at least someone did and would explain it to you.

I agree with most of this except this. Think there’s some rose tinted glasses here or I’ve got bad luck over time.

Life before ai was bad as well. There wasn’t any one to explain to you anything! You had to figure it out yourself. The people either already left or was busy with something else.

No one wrote tests (to my standard). Most of the ops works was skipped. Docs were just not there. Nobody linted properly. Just bad mannnn

It’s difficult to have spent a long time learning something, only for that thing to suddenly become accessible to anyone; something that was once scarce and valuable is now abundant and cheap.

There are still machinists doing things by hand, but for real production or prototyping, most will now use a 5-axis CNC machine. It still requires an operator of sorts, but much of the work that once required skilled manual machining is now done by CNC.

I think the same thing is happening here; it’s just that the transition is messy.

Give it five years, and how we get to the end result will not matter nearly as much as it does now. A messy codebase will be irrelevant, as it will be something managed and controlled by the LLM, written in a way optimised for itself, not for you or I.

Now the question is - no one was born good or best engineer/programmer/scientist. Often it was a long path of sleepless nights, daily grinding, failing million times, doing dumb mistakes along the way, the usual package of suffering sometimes called "experience". What is the path now for the next generation of good or best engineers? There will be no opportunities/budget to do the same anymore.

I have witnessed first hand this and must say is a disaster, the person that came up with a fix to an issue that I didn't understand tried everything to convince me that the automated fix works.

Indeed the fix did work, but when I asked him to explain me the problem and the fix he started to use the prompt to get answers.

At that point I just let it go, the only thing that I mentioned later on is that I'm ok with pushing that to prod if that was ordered to me but I'm not responsible for it.

I prefer to keep the bug live until I fully understand the problem, reproduce it, come up with a solution and maybe just maybe perform a check against what a computer generated.

Please note that the bug came from a real human code base but being complex and not familiar with that part of the code (moreover the code was handed to us without any type of support/documentation) rendered me in a weak position where I couldn't come up with a solution so far.

How can someone trust so much a computer generated hotfix without fully understanding a problem is what still baffles me.

Still resisting to use any aided coding, no LLM is not going to steal the capacity to use my brain. The day I'm forced to used these tools, the day I quit.

People should realize that programming is not a liability. Programming per se is the actual creation of detailed knowledge by writing.

You get a task, how does it interact with all other invariants? What are the implications on data flow, processing and user workflows? You can rarely answer those questions beforehand, you step on them during programming as the formal language forces you to take them into account sooner or later.

If you outsource this knowledge-building you’re losing the steering ability when stuff hits the fan. You lose the ability to navigate the code properly in order to identify bug or violations of invariants.

LLM optimize locally, that’s their nature. Invariants are often implicitly scattered around the whole code base. Explaining them to the LLM is much more tedious than just to write the code in the first place. At least for me as I have much better expression-ability in Code than in natural language when it comes to describing any form of computation.

I'm simultaneously frustrated and I see a business opportunity - I now know that we senior folks are very far from replaceable - and soon there might be consulting to fix big problems. No one will say it's AI's fault necessarily - you'll just be living with painful complexity that works for a startup or an individual entrepreneur but not in an enterprise environment. To wit:

>The person adding Kafka should have been able to explain exactly why it was needed.

Here it is. People who don't know what they are doing are adding infrastructure layers they don't understand, can't envisage operationally in the future, and missing scalability. I'm seeing this. In fact I'm spending hours a week fighting it. I had to set up a call with a senior developer recently to explain why his prescriptive attempt to make infrastructure changes in his project can't be done with Claude like he did it.

It's playing wack-a-mole as the "velocity" has gone up of changes, and it's promulgated by every manner of product manager and senior developer under an attempt to please the brass.

>The person who built the feature should have been able to explain where the data came from without sending a link to a Claude conversation.

And they won't - because it's too embarrassing when you see what Claude responded with and someone failed to question.

We're in a new era, that's for sure.

I think it is less about junior/mid engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.

This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to do their work anyway.

[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...

Look, stupid companies who use A.I. to generate their code will simply fail. Companies that use bright engineers to engineer their product and write code (and pay them accordingly) will thrive and thrash the competition.

Darwinism in action.

I don't believe A.I. will change much, but it will lead to winners and losers, that's certain. Lessons will be learned, A.I. will remain but play a minor role, just like IntelliSense and ReSharper.

People need to understand that when things break management will hold you accountable, not the A.I. If you can't fix it you'll be out of a job. So you'd better make sure that you understand the generated code and clean it up before putting it in production because you'll be maintaining it.

Do we yet have actual, irrefutable evidence of SWE job losses attributable to successful implementation of LLM coding agents? They've been around long enough and management has been horny enough about the whole thing long enough that we should be able to point to some notable examples.

> Fixing it would require such a colossal amount of work that it would be impossible to even start justifying it to anyone in management.

Bad news: by delegating the thinking to somebody else (Claude) you have become the management.

All of this is my fault.

I decided to start learning programming about 6 years ago as a possible new career path. The universe was not going to have that so AI was created.

> - "Why are we doing this here?" > They send you a link. It's a Claude conversation.

LLMs spared my neck of the woods for now but is this really how PR review looks like these days for an average SWE or its just an example of a Junior in a team?

> You were never expected to understand every service and every database. But at least someone did and would explain it to you.

This hasn't been my experience. Especially when it comes to enterprise software, eventually everyone that was involved with the design of and iteration on a system will have left the company. Yet, often those systems need to continue running because they support "legacy" customers (who sometimes actually tend to be more economically valuable to the company than the customers on the shiny new system).

Before AI, in these cases you just had to dive into the code and start trying to understand it yourself from zero. Usually, you would come to a very limited understanding of the system, just enough to fix the latest bug or keep it running until it hit another issue.

I'm not sure why it's necessarily worse to rely on an agent to do this for you these days.

One thing this post did not discuss is the enormous effort required to explain to the management why number PRs has increased and number of lines changes, which in their view, means explosion of productivity, yet one engineer is destroying the team's momentum.

From the title I thought this post would be about something completely different. The post is about splitting the world into "good" and "bad" engineers with an emphasis on the bad engineer. Ok but what does that have to do with the middle class? The post leaves the best part out.

What I thought the post would be about is the dissolution of the White Collar Kitchen Brigade The kitchen is run by the Chef but it needs the Sous Chef, Line Cooks, Kitchen Hands to operate.

Many software engineers have made a good living acting as the sous chefs and line cooks underneath the rockstar chefs, but with AI companies are inclined to turn the whole kitchen over to the top dog and their AI crew and the ordinary human crew is slowly being churned out.

Agree with the article the way I think of it is basically like before AI good engineers put in effort either currently or over cumulated years of experience.

A bad engineer has been lazy for years and will never change.

You likely have experience with this already first hand. Ever had a lazy day and just hit "yes" "continue" on the AI over and over? I've had to revert entire days of work because I was so burnt out I didn't put effort into the design.

A good rule of thumb though is if an AI can't solve the bug and fixing it creates more you have a bad abstraction and architecture that needs a gutting and rebuild from near scratch.

I thought this was a good read. From my experience and to my dismay, what is considered a "good" or "bad" engineer/developer can be surprisingly subjective. I completely agree that an engineer should never submit a massive PR and instead break the work down, question, and understand the AI-generated code. I also agree that any reviewer should push back on being asked to review that and request the PR to be divided up. Unfortunately, what I've seen happen is that someone else with more power in the organization might find that PR fine and approve it and management might be raving about how good (fast) said engineer is. Those weird bugs which appear down the road get offloaded to other engineers.

Faced with that situation repeatedly, most people would find it sensible to resign. Which leads me to another point: if you leave, it will likely be difficult to land another job assuming that companies will impose a ridiculous interview process in fear of a bad hire which will be increasingly expensive as the author argues.

I realize that this is nothing new, but if there are fewer middle-class engineering roles, then I expect that these existing problems to become amplified.

I got a person from my small team fired before the sommer holidays. Not that I wanted to, but he didn't deliver the quality that I was expecting from a thinking human with an engineering degree.

Adding AI to the mix just made things worse. I'm still finding issues in the codebase/documentation that I need to review, test and fix.

The replacement is being trained. I made sure that, while I expect them to use LLM supported development .. they own their contribution.

This is going to be a fun ride.

It baffles me that someone can just send a PR without knowing the gist of how it works and why it’s done this way.

If you can’t answer this basic question then why tf do we even need you around?

LLMs are an automated Indian dev-shop. That’s all. The code is poorly thought out, poorly implemented and doesn’t take performance into account. But the code works and you got it for cheap. That’s my mental model and I’m happy with it

I forget the economics term for this but doesn't an improvement in tools result in little net change because everyone across the industry is given effectively the same leg up? Doesn't this mean that things will mostly stay the same employment wise? Most people aren't 10x engineers even with agents. Certain things are true: most products need someone on call 24/7, a group of people who know how to support a product (with varying degrees of knowledge), someone who plans what to build, someone who builds it (usually different people), inefficiencies in communication, etc. at least at the company I work for, agents have all largely improved these things, but by no means eliminated them. So it seems like things will largely be the same. There are only so many incredible engineers out there. They'll become more and more valuable but they were valuable pre ai. It's not like the industry will consolidate to only amazing engineers.

AI generated code is the new "lines of code" metric used by middle management.

I saw close some companies getting completely lost with AI code

So, blame the engineers now? Most likely they were forced by a manager to push more PRs faster else piped.

First day of work, immediately Ultracode refactor the entire codebase, do a massive 800k line force push to main, git comment, "Hey guys! First day, first commit -- fixed codebase with Claude. Hope this works!"

The main thing it's removing is the skills you gain through actual practice, and replacing those with the demand that you subscribe to OpenAI etc to do your job.

But, moreover, the demand your company subscribes. But not your company anymore, because you'll probably be replaced by one engineer (and an AI subscription) who's now trying to do your job and about four or five other jobs.

And this one engineer will become more and more reliant on AI companies, AI companies that'll go for the throat once they've hollowed out all the skills that used to exist in the engineering market.

> This was already happening before AI. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can get there in just a few months.

And who is going to want to fix that? Maintainers and systems people were the first to be laid off, by management who never valued the "cost centre" they represented, and the few remaining are trying to fight gravity and will likely take the blame when the systems they oversee fall in a heap.

Any new hire knows they will spend a few years building a mental map of institutional knowledge, only to be tossed on the scrapheap as soon as the system is working again.

If companies want to develop internal software as they appear to, they need to stop defining business processes in code, and certainly stop defining them in Jira tickets. Middle management has outsourced so much of their work to the software or operations departments and now its about to backfire.

I think this might be the key point to be honest, though not quite in the way the article suggests:

> My bet is that AI pushes salaries further apart. To be employable, there's a bar you have to clear and that bar is whatever the current best model du jour can do.

Since well, there are a lot of jobs in the tech industry that for all extents can be 'solved' with AI. Like if you're developing themes and plugins for a CMS (like say, WordPress), something like Claude can do a very passable job at that exact type of work.

So, only the more senior developers are even needed in that type of work anymore. And even they only need to review what the LLMs provide and fix issues maybe 10% of the time.

Hence the most basic, most entry level friendly engineering opportunities are likely about to be decimated. If your work involves building simple themes and plugins, managing the website of a small to medium sized business or being contracted to build sites for mum and pop companies, then your job security right now is questionable at best.

Being better/more skilled than AI is basically the bar you need to clear to find meaningful employment in this field now.

Interesting article, and it makes a lot of salient points.

I think I can agree with most of it while also arguing that I don't think good code has ever had an honest measurement of quality. From an end user perspective, the end product either works or doesn't. Working terribly is the same thing as doesn't work and working well is the same as works.

What AI changes is the actual code part. The actual code lines output by AI is identical to or better than the best programmers. The systems design, architecture, QA, integration into existing legacy systems, to just name a few, is where the strengths and skillset lies.

In order to be a good engineer, you have to be a systems thinker. AI or no AI does not change that. The entire picture has to be taken in to account, and I think this is going to obliterate the vast majority of engineers who cannot or don't want to think about systems. It's no longer about putting on your headphones and outputting code. It's about having to interact with other humans, systems, architectures, organizations, and an API or MCP is not going to help with that.

I truly do feel bad for terrible older aged engineers, and the young new grads. I think it's unfair that a lot of new grads were told that CS was a great career, only for them to start their freshman year before AI, and then graduate when AI coding is in full use at nearly every workplace.

I think there's a corollary to this. Not only is it hollowing out the middle class, it's preventing the junior engineers from stepping up to the senior level.

Everyone starts off as a bad engineer. Just like any other profession, you to make lots of mistakes to learn. But now you're less likely to get wisdom from another human to build up the knowledge and experience you need. And more likely to delegate the hard stuff to Claude so you don't learn from your mistakes.

> Good engineers have become more valuable because AI lets them move much faster. They don't need as many people around them just to do the implementation work anymore.

This would be true if the goal was to get good working code faster. But the actual goal is to get any code faster. So, in reality, it doesn’t matter whether you are a good or a bad engineer. It just amplified how good you are at manipulating the hiring process with your fine tuned resume and how smoothly you can talk your way through.

Writing code was never the job. Creating value was the job -- coding was just how to implement that goal.

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.

This piece is so god damn spot on. I have recently been raising every single one of these exact issues in our team. AI prerequisites good working practices and ways of working more than ever before. And people need to own their contributions, no matter how they produced them.