Originally published on The AI Prism
The top story on Hacker News this morning is not a product launch, a benchmark, or another funding round. It’s a 4,000-word essay arguing that the people who write code are quietly losing the ability to understand it. “Coding expertise is going to collapse from AI reliance” has been sitting at the top of the front page with 536 points and 530 comments — an audience of working developers arguing about whether their own profession is eating itself.
The essay comes from Lars Faye, a developer who has spent the last year warning about “the skilled orchestrator paradox”: the skills you need to manage AI coding agents are the same skills the agents quietly replace. The more you lean on the tool, the less you practice the craft — and the craft is exactly what the tool demands you know to use it well.
Here at The AI Prism, we’ve been watching this debate build for months. Then three days ago, ZDNet published survey data that gave the worry a number: 80% of developers say their AI use feels more like dependence than an advantage. The collapse argument is no longer hypothetical — the studies are in, the addiction data landed, and the industry is betting trillions on a pipeline that may be eroding the very skills it needs to survive.
Here’s the uncomfortable part: the evidence says the erosion is real. What’s still open for debate is whether it’s inevitable.
The Developers Who Need AI Least Benefit Most
The first thing Faye’s essay does is invert the standard productivity story. The people getting the most out of coding assistants, he writes, are industry veterans — developers with years of experience that predates the tools. The people getting the least, and the most damage, are the novices being told to lean on AI from day one.
The study behind that claim, “The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers” — highlighted recently by JetBrains — analyzed live coding sessions and found heavy AI assistance actively derailed learning. Participants “often skipped crucial planning stages,” finished with an “illusion of competence” instead of understanding, and the novices who performed best were the ones who mitigated or ignored the AI entirely. The best performers had developed what the researchers call “negative expertise” — the ability to ignore incorrect or unhelpful AI suggestions.
That’s the core of the collapse argument: the tool’s value curve is inverted. Experts steer it, audit it, and catch its lies. Beginners hand it the wheel and end up lost. In Faye’s words, the least restricted novices in the study “had skipped crucial steps in the programming problem-solving process, and were now lost.”
The Expert Novice Is Already Here
Now consider the signals the industry is sending. For three years, the mantra has been “AI won’t replace you — someone using AI will.” In the same breath, everyone from senior engineers to Robert “Uncle Bob” Martin says juniors shouldn’t touch AI tooling for their first three years. The tools demand expertise to wield responsibly — and the industry is pushing the least experienced people to use them first.
Faye calls the result the “expert novice”: a developer who needs expert-level judgment to evaluate AI output, but has been denied the years of friction that build that judgment. The HN thread is full of working confirmation. One commenter watching it happen in real time reports reviewing “vibe-coded” work that is “some seriously low quality garbage” — but it’s functional enough to keep the person who generated it convinced they can code. Another describes enterprise mandates straight from leadership: “if you’re writing code manually, you’re doing it wrong,” with engineers producing code faster than humans can understand or honestly review it.
The junior rung of the market is where this squeeze shows up first — and it’s exactly the rung our earlier analysis of the AI job market flagged as the most exposed. The people who most need to build expertise are being trained, by mandate and by habit, to never practice it.
Confidence Without Comprehension
The most dangerous part of the erosion isn’t what developers forget. It’s that they don’t know they’ve forgotten it. The Widening Gap study’s participants “thought it was like having a personal tutor” — and the data showed the opposite: they used the tools as an answer machine, skipped planning, and believed they were learning while their comprehension stayed flat.
The effect isn’t limited to coding. In UPenn’s 2025 study of 1,000 students learning math with an LLM, the AI-assisted group performed 17% worse than students with a plain textbook — while simultaneously believing they were excelling. The tool had produced confidence without comprehension, and the students couldn’t tell the difference.
Faye’s metaphor for this is a compass that always points north, wherever you suggest north might be. When you’re exploring unfamiliar territory, you don’t know what you don’t know — and the model’s accommodating confidence fills the gap with certainty instead of understanding. An infinite answer machine is a terrible teacher, because it never tells you you’re wrong until you’re already lost.
The Friction Is the Feature
The collapse argument rests on a simple claim about how expertise forms: it requires friction. Coding has endless moments of tracing obscure errors with no log file, feeling the performance difference between two approaches, rewriting something that won’t scale. That applied struggle is what builds “developer intuition” — what Faye calls Fingerspitzengefühl, the fingertip feeling that makes a senior dev look at code and think “yeah, this is probably going to cause problems.”
The same UPenn study that found the 17% harm also tested a fix. Students using a “Tutor” version — where they asked for help, then independently solved the problem — performed 127% better in AI-assisted practice. The model wasn’t doing the work; it was forcing the student to.
When the friction stays, the learning lands. When it disappears, so does the imprint.
Anthropic’s 2026 study on how AI assistance shapes coding skill formation reached the same conclusion in its own words: “Cognitive effort — and even getting painfully stuck — is likely important for fostering mastery.” One HN commenter put the muscle analogy bluntly: if you stop training the muscle of logic and reasoning, it atrophies, just like an unused physical muscle. The irony, as Faye notes, is that the most productive learning that can happen with an AI coding tool is when it isn’t used to generate much code at all.
The Addiction Numbers Are In
Then there’s the behavioral layer, which the expertise debate usually treats as a side effect but is increasingly the main event. A Coddy Tech survey of 305 developers, reported by ZDNet on August 22, found 80% say their AI use has felt more like dependence than an advantage.
The same survey found 43% keep coding with AI after hours when they meant to stop. 32% have put off sleep to keep going. 39% say the tools made it harder to switch off from work.
The headline story is Quentin Rousseau, CTO and co-founder of the incident-response company Rootly, who posted on LinkedIn about watching Claude Code refactor a module at 2:47 a.m. with no deadline and no outage: “I can’t stop.”
“Agentic coding is addictive,” he explained. “When the agent gets things right, you get a dopamine hit. When it fails, you get an adrenaline rush.”
Rousseau says he eventually sought medical help. His diagnosis of why the loop hooks so hard deserves a second read: “Watching an agent’s work is passive enough to feel like rest, active enough to keep you hooked.”
Here’s the part that should make every engineering leader uncomfortable: the same survey found 74% of heavy AI users said it made a raise or promotion more likely — and 51% said they were more likely to burn out. The reward and the cost are being handed out together, and the industry is measuring the first while ignoring the second.
Trust Is Falling Faster Than Adoption Is Rising
Addiction isn’t the only crack. The 2025 Stack Overflow Developer Survey shows adoption still climbing — 80% of developers now use AI tools in their workflows — while trust in their accuracy fell from 40% to 29% in a year, and positive sentiment dropped from 72% to 60%. Nearly half, 45%, said they were frustrated by AI answers that are “almost right, but not quite”: output that looks convincing and creates difficult debugging work.
ZDNet’s Vaughan-Nichols gives that phenomenon a name worth keeping: verification debt. The code arrives instantly, but you still have to establish whether it’s correct, secure, maintainable, and consistent with the architecture. The time saved on writing is spent on verifying — and the verification skill is exactly the expertise that’s eroding. One HN commenter summarized the trade-off cleanly: with agentic coding you are “practically trading accuracy and control for speed and efficiency.”
That’s the trap in one sentence. The industry is optimizing the metric it can see — throughput — while the invisible metric, the ability to judge what the machine produced, falls.
And employers amplify the loop: when organizations treat AI as a way to multiply developer capacity, workers face pressure to ship more features and close more tickets in the same hours. The time saved on writing gets re-spent on larger pull requests, more generated changes to inspect, and more operational risk to manage. The dependency is doing the work the org chart assigned to management.
The Pipeline Problem: Who Reviews the Code No One Understands?
The collapse argument gets its sharpest form from the HN thread itself. One commenter describes the industry as a snake eating its own tail: the developers who refuse to “cook their brains” with AI end up reviewing terrible AI-generated code written by people who did, and their reward for staying sharp is more of that review work. “Completely unsustainable.” Another, a security-minded dev, puts it personally: the more the LLM writes the code, “the less good critique I’ll be able to give in the future” — because review ability is itself a skill built on reading and understanding code.
The experts see the same failure mode. David Cramer, co-founder of the error-tracking company Sentry, told an interviewer what he thinks of the belief that future models will clean up the junk this generation generates: “I don’t think that’s true. I think it’s a science experiment… You want to flex that you can generate all of your code and have hundreds of things going in parallel, I will flex and show you how broken the code is 100% of the time.”
The counterargument, well-represented in the 530 comments, goes like this: we’ve been here before. Assembly expertise “collapsed” when compilers arrived, and nobody demands that modern programmers know microcode — the world got faster, not worse. One commenter jokes that “coding expertise is going to collapse from compiler reliance” sounds exactly like a 1985 Turbo Pascal detractor.
Others point out that scarcity can pay: COBOL-style expertise, they note, eventually commands a premium. A third commenter honestly reports learning more from LLMs than losing to them — wider tooling exposure, deeper familiarity, faster reach.
But the strongest rebuttal on the thread cuts the historical analogy apart: programming languages are deterministic, and LLMs are not. The boundary between an abstract concept and something executable used to sit in the programmer’s head; with an LLM, it becomes shared between the programmer and the matrix-multiplication machine. Leaky abstractions are fine when the leak is deterministic. When the abstraction itself invents the leak, the analogy breaks.
Friction-First Is the Only Strategy Left
So what do you do with this? The individual answer is to treat AI as a sparring partner, not a ghostwriter. The studies are consistent: Socratic use — ask the model to question your approach, then solve the problem yourself — produces the learning, while answer-generator use produces the illusion of it.
Faye’s rule for his own work is friction-first: let the model audit your code, but don’t let it write what you haven’t first thought through. That’s the difference between a developer using AI and a developer being used by it.
The organizational answer is harder, because it fights the incentive structure. Companies that measure developers by output will keep getting output — and losing reviewers. The leaders who survive this transition will be the ones who measure understanding: who require that merged AI code be explainable by the person who merged it, who reward the engineers who catch the model’s lies rather than the ones who ship the most tokens.
Joel Spolsky’s Law of Leaky Abstractions, written in 2002, has aged into prophecy: code generation tools which pretend to abstract something, like all abstractions, leak — “and the only way to deal with the leaks competently is to learn about how the abstractions work.”
There’s a third answer, and it’s the one nobody wants to say out loud: the industry may simply be making a trillion-dollar bet that this knowledge won’t matter. Faye names it directly — the bet that LLMs will “take up the slack and effectively become the new generation of developers.” If that bet is right, none of this matters. If it’s wrong, the industry has spent the best years of its junior cohort training them to never become senior.
The Bottom Line
The collapse of coding expertise isn’t a prediction about the technology. The technology is fine — it writes plausible code at astonishing speed. The collapse is a prediction about the people: a generation of developers is being shaped by tools that reward speed over understanding, confidence over competence, and dependence over mastery.
The studies, the surveys, and the 530-comment argument on the front page all point the same direction. Friction is how expertise forms, and we have built an industry-wide machine for removing friction from the exact people who need it most.
None of this has to be inevitable. The tools can be used pedagogically; the incentives can be redesigned; juniors can be protected for three years the way Uncle Bob suggests. But every week the industry spends promoting generation-over-comprehension is a week it spends shrinking the pool of people who can still read the code being written.
The people writing code are losing the ability to read it — 530 HN comments and counting. If the last generation that can read code is the one writing it today, who audits the machines once the machines write everything?
References
• Lars Faye — “AI Coding will Prevent Expertise”
• Hacker News — “Coding expertise is going to collapse from AI reliance” (536 points, 530 comments)
• arXiv — “The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers”
• Anthropic Research — “How AI assistance impacts the formation of coding skills” (2026)
• Stack Overflow Developer Survey 2025 — AI trust and adoption data
• Robert C. Martin on junior developers and AI tooling (via HN thread)
• Joel Spolsky — “The Law of Leaky Abstractions” (2002)
• The AI Prism — “What Is Actually Happening to Jobs: Separating AI Hype From Reality”
The post Coding Expertise Is Collapsing — and AI Is Why appeared first on The AI Prism.
Cross-posted from theaiprism.com — Cutting Through the AI Noise 🧊
Top comments (0)