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

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.

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.

> 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

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

- unrelated but from your blog

- you have a very nice article on how llms work here https://blog.florianherrengt.com/how-llms-work.html

- but in your diagram titled "Word vectors plotted in semantic space" dont you think you need to add arrows to show where those vectors are actually pointing?

- because i dont get how you arrived at this Using vector arithmetic, you can calculate: woman + (uncle - man) = aunt without seeing the math vector directions

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.

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.

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

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

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.

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.

I think that piece is half right and half wrong.

I think it's largely correct that hiring bad engineers is dangerous to the company. But that's always been true, especially those "hack out a prototype, get director applause, and leave it for somebody else to own" people. But management has usually chosen to keep such people around, because they can look good on paper (see how many tickets they closed?).

The question is really a management / business-owner question -- will managers/directors stop hiring yolo-engineers? Will they empower engineers to close PRs simply on complexity/size grounds? Will they fund refactors and simplifications as first-class concern? If not, it will be a problem, and I don't envy the engineers who try to be the glue at such a company.

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.

Perhaps more broadly AI will hollow out "middle intelligence".

We could end up with a gulf between those who use AI for cognitive inquiry vs passive delegation. Those who accelerate learning by asking "help me understand this" vs those who relinquish understanding and analytical thinking to AI to complete their work.

I told my (small) team of developers that they're free to use anything to get them more productive: (company-provided) AI, black magic, WFH to avoid traffic, etc. But I also tell them that every human (including myself) is responsible for their own (direct/indirect through delegation) work so we can't say "a genie did that, not me". So far it's net positive for us with AI.

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?

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.

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

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

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

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.

I saw close some companies getting completely lost with AI code

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?

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.

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.

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

I have a theory that Claude regresses to complexity. It’s trained to mimic existing patterns - so the smallest grain of over-engineering or spaghetti-code is like a mind-virus, gradually infecting all future output and self-amplifying until all is spaghetti.

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

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

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

it seems not just the 'middle', but also the 'lower' classes are getting removed

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.

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.

It wasn't that long ago that many were demanding writing code be a required subject in elementary school.

It's very true, you used to have to hire people you knew were not very good just to have warm bodies who could throw together widgets, minor bug fixes, etc. You still had to have a competent developer review what they did, which was annoying, but ultimately a time saver over doing it themselves.

Now the competent developer can just run agents and do the same review process, except it's ~free (relative to human salaries, even outsourced).

So we've got a bimodal distribution going on where the bottom X% of developers have become essentially worthless while the top Y% of developers are now more valuable than ever.

At the same time, it also brings very low level "vibecoder" to the pool

Probably a good thing, we need more people building major mega projects like the Line. Potentially we need AI to mass produce architecture and scale up and out city/county building departments to open the gates to massive buildings in the United States.

"You can't afford bad engineers anymore"

You never could.

Great idea to include a link to Hacker News on your blog!

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

More like AI is exposing bad engineers faster than it would've been possible earlier. Previously they would simply outsource all their thinking to someone else, now they see massive progress with AI and delude themselves into wishful competence.

This is really well written. I deal with the exact same issues almost daily. Senior engineers who want to guard quality are becoming a bottleneck.

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.

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.

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.

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

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.

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.

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.

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

Wait till we realize that nobody is buying the software we vibe code anyway.

We've seen this game before, with the Dot Bomb and 9/11. A lot of you have 6 figure jobs that will simply be gone next year after the election, never to return.

That winter lasted about 5 years until 2007 when the iPhone and social media sites like Facebook went mainstream. This winter won't end. Or more accurately, it is the end.

Maybe we should stop debating whether we're in a crisis and start looking at the 5-10 year endgame of the Singularity. We're entering the eventuality that many of us have predicted since the arrival of the internet 30+ years ago, that prices will get lower but nobody will have any money to buy anything anyway. The feeling that we're doing something wrong with our lives will continue to intensify. We'll try so hard, and get so far, but in the end, it doesn't even matter.

I don't know about the rest of you, but I'm turning my attention away from trying to play the job game with AI. I'm looking instead at how we can provide time/money/resources to the middle class after capitalism can no longer provide them.

A conservative friend of mine just read the Communist Manifesto by Karl Marx, which I didn't see coming, especially since he beat me to it. In the neurodivergent spirit of not being able to do anything alone, what if we all read it?

https://oll.libertyfund.org/pages/marx-manifesto

https://www.marxists.org/archive/marx/works/download/pdf/Man...

I'm predicting that it stops just short of what full automation can provide. Loosely the evolution of economics goes: hunter-gatherer -> agrarian- > feudalist -> capitalist -> socialist -> communist. And now solarpunk (or something).

The working class is looking forward to the next chapter, but the capitalist class is looking backward to neofeudalism.

Those two directions can't coexist, so what does the future hold? Well, it's always darkest before dawn:

"It's easier to imagine the end of the world than the end of capitalism." - Mark Fisher.

https://www.youtube.com/watch?v=aCgkLICTskQ Mark Fisher: The Slow Cancellation of the Future

https://www.scribd.com/document/835022535/Mark-Fisher-The-Sl... (transcript)

https://goodscienceproject.org/articles/the-slow-cancellatio...

https://mediationsjournal.org/articles/end-of-world

If the endgame of capitalism is that it inevitably eats itself, then the game now isn't how to get more money and do nothing with it, but instead how to start doing something with no money.

I should add that even if I'm exploring anti-capitalist futures, that doesn't make me socialist. I don't like the 6 hour daily work requirement of many socialist societies. I think we can do better than that and get closer to 0, so that we can shrug off wage slavery and finally get real work done.

AI gives more leverage to exceptional people, its an amplifier not an extender

Economics would have always created this downward pressure on demand for software engineers regardless, either companies would replace the number of engineers they need with AI, or with low paid offshored workers.

I don't know what kind of company has got a large codebase and it's taking 20,000 loc pr's expecting that shit to be sustainable, but I work AI first and at the most PR's are touching 12 to 15 files, with the more radical ones sitting at 30. They are still human-reviewable. They are still the kind of change you can revert back to original without breaking all the rest... there are ways of doing this stuff, dear luddites.

> The engineer opening a 25,000-line PR should have stopped the agent long before it got there.

So many A car is simply a faster horse arguments being made here.

The “You must review every line of code” camp are going to be in for a seriously bad time when Claude/Grok/etc starts writing machine code, and they absolutely will and you will look like a crazy person the same way as those who said we can’t trust compilers back in the 1970s.

Breaking up code into small reviewable pieces is obsolete advice from legacy software engineering. We will probably be reviewing prompts or functional simulations as a form of review. Which brings me to the point that a Senior engineer in 5 years will look absolutely nothing like a Senior engineer in 2019.