The original poster describes a year of reviewing LLM-generated PRs and debugging hallucinated output, watching their scope shrink from designing systems to validating model proposals. They argue the threat isn't job loss but a quiet demotion-in-place where title and salary remain stable while the actual craft of engineering erodes.
Frames the post as the clearest evidence yet that the replace-vs-augment debate is the wrong framing. Argues the internal apprenticeship loop — writing CRUD, debugging race conditions, getting PRs torn apart by senior engineers — has been quietly demolished, eating the industry's seed corn for producing future seniors.
A cohort in the 600+ reply thread insists the job is naturally shifting toward validation, orchestration, and higher-level system design, and that velocity metrics prove the model is working. They frame the OP's discomfort as resistance to change rather than evidence of a structural problem.
A smaller faction argues the erosion of generalist software work was foreseeable and that the appropriate response is individual reskilling into ML infrastructure, evals, or other LLM-adjacent specialties. They treat the career disruption as a personal optimization problem rather than a systemic one.
A large share of the 600+ replies report the same pattern from their own jobs: PR review queues dominated by model output, shrinking design ownership, and a creeping sense that the craft is being hollowed out. Their volume suggests the OP's experience is widespread rather than idiosyncratic.
A post titled *"LLMs are eroding my software engineering career and I don't know what to do"* hit 864 upvotes on Hacker News overnight, parked on a bearblog — no monetization, no newsletter pitch, no consultancy outro. That detail matters. The author isn't selling a course on "thriving with AI"; they're documenting the slow unbundling of what their job used to be.
The specifics in the post are mundane and that's the point. They describe spending the last year reviewing PRs the LLM mostly wrote, debugging output the model hallucinated, and watching their internal scope shrink from *"design the system"* to *"validate the system the model proposed."* Their tenure is mid-senior. Their employer is happy with the velocity numbers. Their performance review went fine.
The unease isn't about being replaced — it's about being demoted in place while the title and salary stay the same. The comments section, now past 600 replies, breaks roughly into three camps: engineers reporting the same drift, managers insisting the role is "just evolving," and a smaller cohort arguing this was always going to happen and the complainers should retrain into ML infra. None of those framings engage with what the post is actually about: the career *ladder* is breaking, not the career.
The industry has spent two years arguing about whether LLMs replace engineers. That framing is wrong and the HN thread is the clearest evidence yet. Nobody is being fired. Headcount in most shops is flat or up. What's collapsing is the *internal apprenticeship loop* — the years of writing CRUD endpoints, debugging your own race conditions, and getting your PR torn apart by a staff engineer who'd been there five years longer. That loop is how mid-levels became seniors. It's been quietly demolished and nobody priced it in.
Replacing junior output with model output doesn't save you money long-term — it eats your seed corn. Consider what a 2024-vintage senior engineer learned the hard way: how Postgres locks degrade under specific write patterns, why your retry logic doubles the load on the very service that's failing, what "eventually consistent" actually means at 3am when the eventually is taking 40 minutes. Those lessons came from production incidents on systems the engineer themselves had written. If the LLM wrote the system, the engineer reviewing it never accumulates the muscle memory. They learn to spot LLM tells (mismatched bracket styles, fabricated APIs, the same five design patterns over and over) but they don't learn the *physics* of the systems they own.
Gergely Orosz has been making a version of this argument in *Pragmatic Engineer* for months. Simon Willison has been more bullish but conceded recently that "the model is a force multiplier on what you already know, and a confident liar about what you don't." The HN post is the practitioner expression of both observations — the engineer feels themselves getting better at *managing* the model and worse at the underlying craft, and they correctly intuit that this is a bad trade if their next employer asks them to debug something the model can't.
The brutal middle-management question nobody is asking out loud: who promotes the senior engineer in 2028 when there are no mid-levels to promote? Staff engineers are made from seniors who survived three or four production fires. Seniors are made from mid-levels who shipped enough wrong code to develop taste. If the LLM is doing the work that produces taste, you're optimizing a current-quarter velocity metric against a 2027 talent gap that doesn't show up in any dashboard.
The counterpoint — that this is just the next abstraction layer, like assembly to C, C to Python — doesn't hold up under inspection. Each prior abstraction *kept* the practitioner in the loop of designing the system. They wrote less code but understood more structure. The LLM abstraction inverts this: the practitioner writes less code *and designs less structure*, because the model is doing both. There's no historical analog. The closest is the difference between a chess grandmaster and a Stockfish operator — and the operator, however good their meta-skills, is not a grandmaster.
If you're an individual contributor reading this, the move is not to refuse the tools. That's the tradesman-vs-power-tool argument and it always loses. The move is to ruthlessly defend the parts of the job the model can't do, and let go of the parts it can. That means: own the production diagnosis when something melts down. Own the cross-team negotiation when two services need to converge on a contract. Own the system invariants — the things that have to be true for the architecture to work — and write them down before the model can paper over them. Stop measuring yourself on PR throughput; that game is now a race to the bottom.
If you're running engineering for a company larger than 50 engineers, the question is whether your hiring funnel still assumes a normal seniority pyramid. Most do. Most should not. Either you start treating mid-level hires as a deliberate training investment with a 24-month payback (and budget accordingly), or you accept that you will be buying seniors on the open market in 2027 against a thinner supply than today. Sequoia and a16z portfolios are already quietly running the numbers — the *Stratechery* read on this is that AI-native shops will resemble film production: small permanent staff, large project-based contractor pools, and almost no internal mobility.
If you're earlier in your career, the trade is also clear and unwelcome: optimize hard for the first two years to get production exposure on systems where the LLM can't carry you. Embedded, distributed systems, anything with hard real-world physical constraints, anything where the bug surface is so weird the training data doesn't cover it. Boring back-end CRUD is being eaten and the on-ramp from CRUD to architect is being eaten with it.
The next eighteen months will sort engineering orgs into two camps: ones that recognize they're degrading their own talent pipeline and budget for it, and ones that discover the bill in 2027 when they can't find a staff engineer who has actually shipped anything load-bearing in three years. The HN post will keep climbing because it's the first widely-shared articulation of something thousands of working engineers feel and can't quite name. Expect a flurry of "how to stay relevant" content to follow. Most of it will be wrong in the same way: treating this as an individual upskilling problem when it's actually a structural mismatch between how the work is now done and how careers in this field were designed to compound.
I spent most of the last two years making a rather large hobby project. A 3D renderer for cad/visualization. It's pretty hard and slow work because getting anything wrong is usually hard to debug. Get a sign wrong and you have a black image suddenly, with painstaking debugging following. I
I see many comments saying, "AI can't do X with 80-100% accuracy; therefore our professions are in good hands."While I don't want to sound overly pessimistic, the models are improving at a rapid rate. If asked ~3 years ago where the state of the models are today, it would sound l
My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently.LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger imp
I always remember of the infamous Steve Jobs quote "Ideas are cheap". If execution is everything, and frontier LLMs solve execution, then ideas are the gateway to abundance now, but abundance alone does not guarantee "stickiness".What I think is often overlooked is the human &quo
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
Wut? I pilot LLMs all day but there's no way in hell I'd agree to be at the helm of a finance product. That first pillar is still there. Maybe the author isn't aware of the impact they have, but I know, with the evidence of reverted PRs, that when I step outside my area of deep knowle