Argues that making code cheaper to produce doesn't shrink demand for engineers — it expands the universe of problems worth solving with software. BLS and industry headcount data show engineering employment still climbing despite Pichai, Amodei, and Cursor's claims, because the bottleneck was never typing speed.
Frames software delivery as four hard problems — deciding what to build, agreeing on 'done,' integrating into systems nobody fully understands, and owning the 3am pager — of which LLMs only help with one (typing). Argues AI arguably makes integration and accountability harder, not easier, since surface area grows and ownership gets murky when a model wrote the diff.
Notes that Pichai's 30% figure conflates single-line IDE autocompletes with meaningful code generation, and that Amodei's '90% by mid-2025' prediction has not materialized. The credibility gap between vendor forecasts and BLS employment data is itself the story.
Field reports from senior engineers describe spending the same total hours per week, but with less greenfield typing and more time reviewing AI output, writing specifications, designing architecture, and debugging code they didn't write and don't fully trust. The job composition changed; the job did not disappear.
Junior engineers report the inverse of the senior experience: the entry-level tasks AI handles best — boilerplate, simple CRUD, isolated functions — are exactly the tasks juniors used to cut their teeth on. This breaks the apprenticeship pipeline even if aggregate headcount holds.
A post on normaltech.ai titled "Why AI hasn't replaced software engineers, and won't" hit 249 on Hacker News with the kind of comment thread that only shows up when a piece names something practitioners have been muttering for a year. The argument is unsentimental: despite Sundar Pichai's "30% of new code at Google is AI-generated," despite Cursor's revenue curves, despite Dario Amodei's prediction that AI would write 90% of code by mid-2025, BLS and industry headcount data show software engineering employment is still climbing. The doom forecasts have a credibility problem.
The author's frame is economic, not technical. Jevons paradox: when you make a thing cheaper, you don't get less of it, you get more of it applied to problems that were previously uneconomical. Cheaper code means more software gets built, not less software work. The bottleneck in shipping was never how fast humans could type — it was how fast organizations could decide what to build, agree on what "done" means, integrate the result into a system nobody fully understands, and stay on the hook when it breaks at 3am. LLMs help with exactly one of those (the typing) and arguably make two of them harder (integration surface area grows; accountability gets murkier when a model wrote the diff).
The HN thread reinforces this with field reports. Senior engineers describe spending the same total hours per week, but the mix has shifted — less greenfield typing, more reviewing AI output, more time in specification and architecture, more time debugging code they didn't write and don't fully trust. Junior engineers report the opposite pressure: the entry-level tasks AI handles best are exactly the tasks juniors used to learn from.
The gap between vendor claims and observed reality has gotten wide enough to be its own story. Pichai's 30% figure is real but misleading — "AI-generated" at Google includes single-line autocompletes accepted in the IDE, which is closer to a fancy snippet expansion than autonomous engineering. Cursor's "46% of code is AI-written" claim measures the same thing: keystrokes saved, not decisions made. When Stripe ran the same measurement honestly, the number that came back was "AI accelerates parts of our workflow" — not a headcount story.
Meanwhile the actual structural data points in the opposite direction. Software engineer postings on Indeed are down from the 2022 peak, but so is every white-collar job category, and the proximate cause is ZIRP unwind plus over-hiring in 2021, not AI substitution. The roles that have measurably contracted — copywriting, basic translation, first-line customer support — share a property software engineering does not: the work is fully specified in the prompt. A ticket that says "add a checkbox" hides fifty decisions about state, persistence, accessibility, analytics, A/B exposure, and how the new behavior interacts with the eleven other features the PM doesn't remember exist. An LLM can write the checkbox. It cannot decide whether the checkbox should exist.
The deeper community reaction is about Goodhart's law applied to AI metrics. When "lines of AI-generated code" becomes the bragging metric (and it has, across Microsoft, Google, GitHub, Cursor, Anthropic), the incentive flips: vendors optimize for the number, not for whether the resulting code is good, reviewed, or maintained. Senior engineers are now spending real time deleting AI-generated tests that pass without testing anything, AI-generated abstractions that have one caller, and AI-generated comments that restate what the next line does. The cost of bad code didn't go down; it just shifted from production to review.
There's also a labor-market subtlety the doom forecasts miss. If AI made every engineer 2x as productive, the demand-side response in a healthy software market is roughly 2x more software, not 0.5x the engineers. The places where headcount IS contracting — large enterprise IT shops, some FAANG infra teams — are the places where the software backlog is already saturated and demand is inelastic. Most of the industry is not those places.
If you're hiring: the junior engineer pipeline is the actual problem, and it's not solving itself. The tasks AI handles best — CRUD endpoints, glue code, boilerplate refactors — are the same tasks that used to onboard juniors into a codebase. Teams that lean fully on AI for those tasks are quietly accumulating a five-year hiring cliff. Treat AI as a force multiplier for seniors and an apprenticeship gap for juniors; budget mentoring time as a first-class line item, not as something that happens by osmosis.
If you're an IC: the work hasn't shrunk, it's shifted. The hours you used to spend writing the obvious code now go to reviewing generated code, writing specs precise enough for an LLM to act on, and integrating outputs into systems with their own opinions. The senior skill that's appreciating fastest isn't "prompt engineering" — it's the taste to recognize plausible-but-wrong code in three seconds and the architectural memory to know which integration paths will detonate in six months. Invest there.
If you're a manager: be suspicious of any productivity metric whose denominator is keystrokes. The "46% AI-written" stat tells you nothing about defect rate, review cost, or whether the team is faster end-to-end. The honest measurement is cycle time from ticket to shipped + the rolling 30-day incident count. If both move the right direction, AI is working. If only the first one does, you're paying down the difference in production.
The "engineers are obsolete" narrative will keep running for another funding cycle because it's load-bearing for every AI vendor's TAM slide. The reality on the ground will keep diverging from it. The bet to make isn't "AI replaces engineers" or "AI changes nothing" — it's that AI changes the shape of the job faster than it changes the headcount, and the engineers who reshape fastest are the ones who treat the model as a junior collaborator they're permanently on the hook for. That's not a future that requires fewer engineers. It requires better-judged ones.
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