The 'LLMs are eroding my career' post that hit HN's front page

What happened

A post titled *"LLMs are eroding my software engineering career and I don't know what to do"* landed on Hacker News this week and climbed to 320 points with a comment thread that crossed 600 replies before falling off the front page. The author, writing anonymously on bearblog under the handle *human-in-the-loop*, describes a year of using Claude and Cursor inside a mid-size product org and the slow realization that the work they're paid to do has changed shape without anyone announcing it.

The specific grievances are concrete, not abstract. Their day is now 70% reviewing generated diffs, 20% prompting, and 10% writing code from scratch — and the 10% is the only part that still feels like engineering. Pull requests have gotten longer because the marginal cost of generating code dropped to near zero, but the marginal cost of reviewing it didn't. Bugs that used to surface during authorship — the kind you catch because you had to type the variable name and noticed it was wrong — now surface in production. Onboarding juniors has become harder, not easier: they ship faster but can't explain what they shipped.

The post is not anti-AI. The author still uses the tools daily and concedes the throughput gains are real. The argument is narrower: the loop that made senior engineers senior — write, fail, debug, internalize — has been replaced by a loop that produces working software but not better engineers. That, they argue, is what's eroding. Not jobs. Skill formation.

Why it matters

The reason this resonated isn't novelty — variants of this complaint have been on HN every other week since GPT-4. It resonated because the framing finally separated two things the discourse keeps conflating: *am I going to be unemployed* and *am I going to be worse at my job in three years*. The post argues the second is happening now, and the first is a distraction.

The comment thread split along predictable lines but with sharper edges than usual. Senior engineers — people with 10+ years and strong opinions about abstractions — overwhelmingly agreed and added their own examples: lost intuition for memory layout, atrophied debugger muscle, an inability to estimate work because they no longer remember how long things take when *they* do them. Managers and founders pushed back: throughput is up, defect rates are flat or down, and the romantic attachment to authorship is exactly the kind of thing the industry has dismantled before (assembly → C, C → managed runtimes, on-prem → cloud).

The interesting wrinkle is the junior cohort. A noticeable number of commenters with under three years of experience said they don't recognize the loss the author is describing, because they never had it. To them, 'real engineering' has always included an LLM, and the senior engineer's nostalgia reads like a COBOL programmer mourning punch cards. This is probably the most important data point in the thread, and it's the one neither camp wanted to engage with directly: the craft isn't being eroded for the next generation, it's being redefined, and the people doing the redefining are the ones who never knew the old version.

What's missing from the post — and from most of the comments — is data. There's no published study showing senior engineer skill decay from LLM use, because the tools aren't old enough and the metric is unmeasurable in any clean way. The closest proxies are GitHub's internal Copilot studies (which measure speed, not retention) and a handful of academic papers on cognitive offloading in other domains (GPS use degrades spatial memory; calculator use degrades arithmetic). Neither tells you whether the senior engineer who reviews 40 LLM PRs a week will be able to architect a system from a blank file in 2028.

What this means for your stack

If you're an IC, the actionable read is to deliberately preserve the authorship loop the post describes, even when it's slower. Block off time where the LLM is off — not as productivity theater, but as the only known way to keep the skills that make you valuable when the tool is wrong. Pick the gnarliest problem in your queue each sprint and do it by hand. The cost is real (you'll ship less that week); the alternative is becoming the kind of engineer who can only operate when the autocomplete is working.

If you run a team, the operational implication is that PR review is now the bottleneck and you're probably not staffing it like one. Review used to be a tax on shipping. It's now most of the job, and the tooling around it (diffs, comments, approval flows) was designed for a world where humans wrote the code and other humans spot-checked it. That world is over. Code review tools that surface *why* a change was made, not just *what* changed, are going to matter more than the next IDE plugin.

If you hire, the harder question is what 'senior' means now. The traditional ladder assumed that the path from junior to senior was paved with the specific kinds of mistakes you make when you write code yourself. If juniors are reviewing generated code from day one, that path doesn't exist for them. Either the industry invents a new one, or 'senior engineer' becomes a credential held only by people who started before 2023.

Looking ahead

The post will be forgotten in two weeks — HN's memory is short — but the underlying question won't be. The honest answer is that nobody knows yet whether LLM-assisted development produces engineers who can operate without LLMs, and we won't have evidence either way until the first cohort of all-LLM-trained engineers is asked to debug a production incident at 3am when the API is down. That's the real test, and it's coming on its own schedule.