The argument that software's middle class is disappearing

An article titled 'AI is removing the middle class of software engineering' reached Hacker News on 12 August 2026 with three points and no comments. The headline sums up the thesis: artificial intelligence is not eliminating software engineering, it is hollowing out its middle tier. The idea has been circulating for months in forums and hallway conversations, and it deserves a less automatic reading than the one it usually gets.

It is worth reading the original text before forming an opinion, because the public debate tends to collapse into two equally lazy positions: the one announcing the end of the profession and the one claiming nothing is happening here.

The argument, in short

The condensed version goes like this. At the junior end there will always be people coming in, because it costs little and someone has to be trained. At the senior end there is still demand for people who decide architecture, take responsibility and know why something broke at three in the morning. The middle tier, the profile paid to translate a reasonably clear specification into correct code, is precisely what models do better and more cheaply every quarter.

That diagnosis has an uncomfortable side: the middle work was also the mechanism by which someone went from junior to senior. If you automate the stretch where people learn, the question stops being how many roles disappear and becomes where the seniors of 2032 come from.

What we see day to day

At ElephantPink we work daily with Claude Code, with subagents for parallel tasks and with hooks that fire checks on every change. The measurable effect in our projects has not been writing less code, but shifting the time: writing goes much faster and reviewing goes much slower. The bottleneck has moved from production to verification, and that is a different skill, one not everyone has or wants to develop.

What counts as expensive work has changed too. Scaffolding a CRUD, migrating an integration or covering a module with tests are tasks we now delegate under supervision. What we do not delegate is deciding what gets built, which data contract survives three years, and what stays out of scope because the client will never use it.

Where the argument leaks

The weak point of the thesis is that it treats the middle tier as if it were only code production. In practice, that profile also holds the project context, negotiates with the business side, takes the on call shifts and knows which part of the system should not be touched on a Friday. None of that is covered by a model, however good it is at generating functions.

There is also a second order effect that rarely gets cited: the more code you generate, the more code there is to review, maintain and delete. Production capacity has multiplied and review capacity has not. If anything is scarce in the teams we talk to, it is not people who can write a function, it is people who can say no to a function that is not needed.

What a mid level profile would do today

Become a good reviewer. Read other people's code with judgement, spot the subtle failure and know when a generated solution is correct but unsuitable.
Learn to specify. Half the quality of an agent's output depends on whether the assignment was well scoped and carried the necessary context.
Build guardrails: tests, CI, hooks, linters, reproducible environments. The more automatic code comes in, the more the barriers slowing it down are worth.
Understand the plumbing of the ecosystem: MCP, agents, permissions, context limits. Whoever connects models to a company's real systems is not in the tier being compressed.

Our reading is more measured than the article's. We do not see the middle class of engineering disappearing, but changing tasks, with a fairly unpleasant transition period for anyone who has spent years being paid for the automatable part. The useful conversation is not whether this is happening, but what each team is doing so that its juniors still learn something once the easy part arrives already written.