LLMs Are Eroding Software Engineering Careers

One engineer's post on Bearblog this week described something specific: not mass layoffs, not dramatic displacement, but a slower erosion. Fewer greenfield projects. More "just have the AI do it." A growing sense that the work requiring judgment was shrinking and the work requiring execution was disappearing. The post got several hundred upvotes on Hacker News and sparked a thread that ran past 400 comments. That ratio of signal to noise tells you something about how widespread this feeling is.

Three positions engineers are taking right now

The Hacker News thread broke roughly into three camps. It is worth mapping them against what each approach actually costs and requires, because the advice varies wildly depending on your situation.

Position	Core claim	Evidence it is working	Evidence it is not
Adopt and accelerate	Use Cursor, Claude Code, Copilot heavily. Ship more. Stay ahead by being the person who multiplies AI output.	Some engineers report billing 3-4x the hours on the same project scope. Senior devs using AI for boilerplate report genuine productivity gains.	If your entire team adopts, the productivity multiplier becomes the baseline expectation. Billing 3x only helps until the client recalibrates.
Specialize in what AI cannot do	Focus on system design, architecture decisions, cross-team coordination, and production incident diagnosis. These tasks require context LLMs do not have.	Senior SREs and principal engineers report no slowdown in demand. Complex distributed systems work still requires humans who understand the full history.	This path requires 5+ years of deep experience to be credible. Mid-level engineers cannot easily jump to it in 12 months.
Wait and see	The hype will normalize. CRUD work will still need human oversight. Quality will matter more once AI-generated code debt accumulates.	Several HN commenters noted that AI-assisted PRs are generating real review burden and that someone still needs to own correctness.	Waiting is a plan if you have runway. It is not a plan if you are a junior engineer trying to break in right now.

If you are a senior engineer with five or more years of production systems experience: the specialization path is defensible. If you are a junior engineer hired in the last two years primarily for execution tasks: the "adopt and accelerate" path is not optional, it is a survival move.

What the original post actually said

"I used to spend my days solving interesting problems. Now I spend my days reviewing AI output, fixing AI mistakes, and justifying to my manager why something the AI did in 30 seconds took me two hours to make production-ready."

That quote captures the specific failure mode that the "AI will just make developers more productive" framing misses entirely. The promise was that AI handles the boring parts, freeing engineers for the interesting parts. What is actually happening in a lot of teams is the opposite: AI handles the first-pass interesting work, and humans are left with the correction, validation, and liability.

Reviewing AI output is not the same cognitive task as writing code. It is closer to auditing. And auditing someone else's work, where the "someone else" has no understanding of your production environment, your team's conventions, or last quarter's outage postmortem, is often harder than writing it yourself. The author's two-hour figure is not surprising. What is surprising is that anyone thought it would be different.

What this transition actually costs an engineer

The career cost is harder to quantify than the tool cost, but both are real.

On the tool side: Cursor's Pro plan versus GitHub Copilot runs $20/month versus $10/month. Adding Claude API calls for heavier code generation, maybe $30-50/month for a working engineer using it daily. Call it $60-80/month in tooling to stay competitive. Not catastrophic, but it is now a real line item and the expectation is you absorb it yourself.

The time cost is more damaging. Learning to prompt effectively for code generation is not the same as learning a new framework. You are not building transferable knowledge in the same way. An engineer who spent six months getting good at using GitHub Copilot for React components has not necessarily improved their ability to architect a system. The skill being built is AI-specific and potentially fragile as models change.

The setup friction is real for mid-career engineers. If you were hired in 2019 as a solid mid-level developer doing mostly feature work, your muscle memory is in a workflow that is now slower than the AI-assisted baseline. Retraining on the new workflow takes two to four weeks to feel natural, not because the tools are hard, but because the review-and-correct loop requires a different kind of attention than writing code from scratch.

Migration risk is the most overlooked cost. Engineers who have built their professional identity around clean, precise coding are discovering that "I write careful code" is no longer a differentiator at the level it used to be. Reinventing your professional value proposition at 35 or 40, while also keeping up with delivery expectations that assume AI assistance, is a real burden that most discussions of "the AI transition" skip past entirely.

Two engineers, one conversation

Engineer A (10 years experience, principal level): This has been the same conversation since IDEs got autocomplete. The floor rises, the work shifts. I spent three months worried about Stack Overflow making me redundant in 2009.

Engineer B (3 years experience, mid-level): You had ten years before the floor moved. I had three. The delta matters.

A: Fair. But the alternative is what? Stop using the tools?

B: The alternative is being honest that "AI makes you more productive" is a company benefit, not always an engineer benefit. Faster delivery at the same headcount still means same headcount.

A: The answer to that is negotiate from productivity data, not from fear. Document what you shipped with AI assistance. Make the case for scope expansion, not just maintained employment.

B: That works when the economy is good and the company is growing. Right now a lot of companies are using AI adoption as cover for headcount reduction they wanted anyway.

A: Then the problem is the economy and the company, not the tools. Those are different problems with different solutions.

The mechanism the headline missed

The blog post's title frames this as an LLM problem. The mechanism is actually a problem of compounding productivity pressure, and it has been building since at least 2022 when companies started treating AI coding tools as productivity evidence rather than productivity support.

Here is what happened structurally. When GitHub Copilot launched broadly, the narrative was "developers are more productive, companies benefit." That framing immediately created a problem: if one developer is now doing 1.5x the work, why do you need as many developers? The productivity argument for AI tools is also, arithmetically, the headcount reduction argument for AI tools. Both claims cannot be true and separate. They are the same claim.

This is not unique to software. Any time a productivity tool reaches the mainstream, it shifts the baseline expectation rather than expanding the pie for the people using it. The engineers who adopted Copilot early got a window of advantage. That window is now largely closed. Using AI assistance is now assumed. Not using it makes you slower than the baseline, not faster than it.

What the original post's author is experiencing is the closing of that window combined with a job market that has not yet figured out how to price the new baseline. Companies are paying 2022 salaries for 2025 productivity expectations. The gap is not primarily about technology. It is about negotiation and labor market adjustment that lags the tool adoption curve by two to three years.

The deeper problem is that the work being automated first is the work that builds junior engineers into senior engineers. The pathway from "writes CRUD endpoints" to "designs distributed systems" has historically run through years of writing CRUD endpoints, encountering edge cases, debugging production issues at 2am, and gradually accumulating the judgment that makes senior engineers valuable. If AI handles the execution layer of that apprenticeship period, it is not obvious that the judgment layer still develops on schedule. This is the career erosion that the post is pointing at, even if it does not quite name it. The tools are not just replacing tasks. They may be collapsing the developmental path that produces the engineers who can do what AI cannot yet do.

Back to that erosion

The engineer who wrote the original post described work becoming less interesting and career progression feeling less certain. That is accurate, but the picture is more specific than the title suggests. The erosion is not uniform across seniority levels, and it is not primarily about job loss today. It is about compressed learning pathways, recalibrated productivity baselines, and a mismatch between what experienced engineers built their careers on and what teams currently reward.

The 400-comment Hacker News thread did not produce a consensus. That is probably correct. There is no single answer because the problem is not a single problem. A principal engineer at a large company with five years of system design experience faces a different situation than a junior contractor whose entire value was fast feature delivery. The same tools, the same market shift, two completely different situations that require completely different responses.

What the post got right is the emotional texture: the ambiguity, the slow change that is hard to name until it has already happened. That is the thing that is notably new. Previous technology shifts in software were faster and more visible. This one is incremental enough that many engineers did not notice the floor moving until they looked down. You can read more on how AI coding assistants compare in practice in our Cursor vs GitHub Copilot breakdown, and the recent analysis of code search agents covers where automated code tasks currently stop and where human judgment still starts.