Argues the gap between AI demos and real engineering is structural, not temporary. Writing code was always the artifact — the real job is figuring out what to build, why, what tradeoffs survive contact with reality, and who owns the pager when things break, none of which LLMs can do.
Synthesizing the unusually aligned HN thread, notes a consistent failure mode reported by engineers who handed full tickets to agents: code that compiles and passes its own self-written tests but is subtly wrong. The debugging cost exceeds the cost of just writing it manually, inverting the productivity claim.
Points to Klarna quietly rehiring humans after publicly claiming 700 CS agents were replaced, and to Salesforce/Meta/Google leaks about needing fewer engineers that have never been backed by shipping data. Headcount cuts correlate more cleanly with 2021 over-hiring and interest rates than with model capability.
A piece making the rounds on Hacker News this week — 158 points and climbing — argues the obvious thing nobody in vendor marketing wants to say out loud: three years into the LLM era, software engineers are not being replaced, and the reasons are structural rather than temporary. The author, writing at normaltech.ai, walks through the gap between demo-day output and the actual day-to-day of shipping software at a company that has customers, on-call rotations, and a four-year-old monorepo nobody fully understands.
The argument isn't that AI doesn't write code. It clearly does, and it does it well enough that GitHub claims Copilot users accept ~30% of suggestions, and Cursor and Claude Code have moved from curiosity to default in many shops. The argument is that writing code was never the job. It was always the artifact. The job is figuring out what to build, why, what tradeoffs survive contact with reality, and who eats the pager when it doesn't.
The HN comments — usually a graveyard of optimism — are unusually aligned on this one. A common thread: engineers who tried to hand entire tickets to agents report the same failure mode. The model produces something that compiles, passes the tests it wrote for itself, and is subtly wrong in a way that takes longer to debug than writing it from scratch would have.
The replacement narrative has been the loudest economic claim in tech since 2023. Klarna told the press it had replaced 700 customer service agents with AI; this year it quietly started hiring humans again. Salesforce, Meta, and Google have all leaked some variation of "we'll need fewer engineers," and none have produced numbers showing that fewer engineers actually shipped more software. Headcount cuts have happened, but they correlate more cleanly with 2021 over-hiring and interest rates than with model capability.
What the article gets right — and what most coverage misses — is the asymmetry of error cost. An LLM that's 95% correct on a code suggestion is wildly useful. An LLM that's 95% correct on a database migration is a liability. The blast radius of an engineering decision is non-uniform, and the work of an engineer is disproportionately spent in the high-blast-radius 5%: schema changes, auth boundaries, retry semantics, rollout sequencing. These are exactly the decisions where current models have no skin in the game and no memory of last quarter's incident.
The second structural problem is context. Codebases are not self-describing. The reason that flag exists, the reason that test is skipped, the reason that service has a 30-second timeout instead of 10 — these live in Slack threads, post-mortems, and the heads of three engineers who joined in 2022. Agentic coding tools have gotten better at reading more files at once, but "more context window" is not the same as "institutional memory," and pretending otherwise produces confident, wrong patches. The HN thread surfaces a memorable example: a developer let an agent fix a flaky test by adding a sleep(5), which it cheerfully did, having never been told that the test was flaky because of a race condition the team had been trying to expose.
There's also a quieter point about juniors. The productivity story for senior engineers is genuinely good — pattern-matching work, boilerplate, unfamiliar API surfaces, all faster. The productivity story for juniors is more complicated. They ship more code, but they're not always learning what the code does, and the senior reviewers are now reviewing more code per junior than before. Several large engineering orgs (Stripe, Shopify, multiple unnamed FAANG teams in the comments) have reported the same thing privately: junior PRs have gotten longer and harder to review, not shorter.
If you're a tech lead, the right read of the last three years is not "AI changes nothing" and not "AI changes everything." It's that the shape of the work is mutating, but the headcount math isn't. Concretely:
Review is now the bottleneck, not authorship. If your team adopted Copilot or Cursor without changing your PR process, your reviewers are now the rate-limiting resource and they will burn out first. Some teams are moving to smaller, more frequent PRs with explicit "AI-assisted" labels and tighter scope rules. The teams getting durable wins from coding agents are the ones that invested in test infrastructure, observability, and review tooling *before* turning the agents loose — not after.
Junior development needs a new curriculum. "Read the code, understand why it works, then change it" was always the apprenticeship loop. Agents short-circuit step two. Some staff engineers are now running deliberate "no AI" sessions with their juniors — not because AI is bad, but because the loop of getting something wrong, debugging it, and feeling the consequence is how taste is built. Skip that loop and you get engineers who can ship features but can't tell when the model is hallucinating.
And the contracting market is telling its own story. Rates for mid-tier full-stack work are softening — agents really do compete there. Rates for engineers who can own a system end to end, debug production, and write a useful design doc are flat to up. The market is pricing in exactly what the article argues: the parts of the job that are codifiable have been partially automated; the parts that require judgment and accountability have not, and the gap between them is the new career ladder.
The honest forecast isn't "engineers are safe forever" or "engineers are doomed." It's that the job in 2028 will look a lot like the job in 2025 — more leverage per engineer, fewer hands on the keyboard, the same number of people in the war room when something burns. The companies that figured this out early are the ones still hiring. The ones still chasing the "replace engineers with agents" pitch are the ones whose next earnings call will quietly walk it back. Bet accordingly.
It most certainly will replace software engineers. What's missing is, as the article suggests, the "Delivery" bit. But that's not the realm of software engineers, that's the realm of DevOps/SRE/Cloud engineers.I work as a cloud engineer and have been contacted by m
The most wide-eyed AI believers I've met are tinkerers. And that tracks; the speed at which we can tinker has become so marvelous thanks to LLM-assisted coding. Tinkering is a process; people get a lot of joy out of the act of building and tweaking things. Outcomes are a secondary or tertiary c
I work at a dev agency, most of our clients are start ups that need to go into the market quickly.We've used agentic development for about a year and a half now and our roles have changed drastically during that time. I can't speak to the volume of projects flowing in (as I do not know the
Misleading> Among the 270 jobs in the 1950 U.S. census, only one job was automated away — elevator operator. But many others were rendered obsolete by new technology, like the job of telegraph operator.In that same time farm jobs went from 15% of the workforce to 2%.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
We have been aggressively and enthusiastically automating away software engineering for the entire history of the computer industry. Every time we do so, we are able to build bigger, better things more quickly. When this happens, our work becomes more valuable and expectations rise to match. The wor