The Expertise Collapse Thesis Is Right About the Diagnosis and Wrong About the Cure

The diagnosis in Lars Faye’s viral post this week is accurate. The prescription is too timid, and the prognosis misses what actually happens to industries when their tools absorb entry-level cognitive work. I have been writing software professionally since 2003. I have watched five distinct waves of tooling change what “junior developer” meant, and none of them produced the expertise collapse that was predicted at the time. This one is different in degree, not in kind — but that difference matters more than the similarity, and the industry’s response so far is almost precisely wrong.

The JetBrains-cited study Faye references is real and the results are damning. Novice programmers using Copilot heavily finished sessions with an illusion of competence. They skipped planning stages. They outsourced judgment before they had judgment to outsource. The UPenn mathematics study showing 17% worse performance for unrestricted AI users against a textbook is also real. These findings are not cherry-picked — they align with how I personally watch junior engineers work when I leave them unsupervised with AI tooling for a sprint or two. The code ships. The understanding does not. I have seen this specific failure mode enough times now that I can recognize it in a pull request within three minutes of reading it: the code is syntactically fluent, structurally consistent, and conceptually hollow in exactly the ways that only show up under load or edge conditions.

But here is where I part ways with the conclusion: the expertise pipeline has always been leaky, and the industry has always adapted by changing what expertise means, not by protecting the old definition of it. Faye’s article treats expertise as a fixed resource that AI tooling is depleting. I think it is a renewable resource that AI tooling is redirecting. The direction matters, and getting it right requires more precision than “use AI as a Socratic partner, not an answer machine.”

The Historical Pattern Nobody Wants to Acknowledge

In 2001, Java IDEs with autocomplete and real-time error checking were going to produce a generation of developers who did not understand the JVM. In 2005, Ruby on Rails was going to produce a generation of web developers who did not understand HTTP or relational databases. In 2012, jQuery was going to produce a generation of frontend engineers who did not understand the DOM event model. In 2016, Docker was going to produce a generation of infrastructure engineers who did not understand Linux process management or networking primitives. Each prediction had studies behind it. Each prediction cited real cognitive shortcuts the tools enabled. Each prediction was partially right about what would be lost and almost entirely wrong about what would replace it.

The pattern is not “expertise survives because brave practitioners resist the tool.” The pattern is “expertise migrates upward in abstraction, and the old form becomes a niche specialty.” There are still people today who understand x86 assembly well enough to write hand-optimized cryptographic routines for constrained hardware. There are still people who write raw SQL across seven joined tables without an ORM. The pool is smaller. The pay is higher. The work is genuinely important in the cases where it still matters. But the majority of working engineers now operate at a higher abstraction layer, and the industry did not collapse — it expanded, absorbed more people, and created more economic value than it would have without the abstraction tools.

Treating this historical pattern as irrelevant to the current moment requires assuming that LLM tooling is categorically different from prior tooling waves in a way that breaks the analogy. It might be. But the argument for that categorical difference needs to be made explicitly, not assumed. Faye does not make it. He treats the current situation as obviously unprecedented, and I think that treatment is doing a lot of quiet work in his argument.

What the Friction Argument Gets Right and Gets Wrong

Faye’s “friction is a feature” argument draws on a real cognitive science finding: desirable difficulty in learning produces better retention than smooth, AI-assisted path-clearing. Robert Bjork’s research at UCLA on this has been robust across decades. The UPenn tutor study supports the application to AI: the group that was forced to solve problems themselves, using the AI only as a Socratic interlocutor, performed 127% better in practice sessions than the group with unrestricted AI access. I have used exactly this approach when onboarding new engineers on my own teams. I will not let a junior engineer ask the AI to write the function. I will let them ask the AI to explain what happens to heap memory when a garbage collection cycle interrupts in the middle of object allocation, and then I will ask them to write the function themselves. The distinction matters, and it is not that hard to enforce with a clear policy and consistent code review that asks “explain what this does” before it asks “does this work.”

But Faye’s prescription — “largely disregard the pure code generation capabilities of these models” — treats this as a binary choice between using AI as a generator or using it as a tutor. It is not binary. The actual practice I have found effective is graduated restriction: for any concept the engineer is learning for the first time, AI code generation is off the table. For any concept the engineer has demonstrably mastered — confirmed through code review, occasional debugging sessions without AI, and ability to explain the code verbally — AI acceleration is appropriate. The friction is preserved where it matters and offloaded where it does not.

This is not a new discipline. It is how every skilled trade has worked since apprenticeship was formalized. A first-year welder does not use the automated MIG welding rig on production runs. A third-year welder does. The journeyman distinction exists precisely because “you can operate the tool” and “you understand what the tool is doing and why it can fail” are different competencies that develop at different rates. The tool’s existence does not prevent expertise formation. The tool’s misuse — specifically, deploying it before the foundational understanding is in place — does.

The failure in the software industry right now is not that AI tools exist. It is that the industry adopted the tools across all levels of experience simultaneously, with no principled distinction between “this engineer is ready to use generation” and “this engineer is not.” Companies rolled out Copilot to entire engineering organizations in a single quarter. The mandate was productivity. The conversation about what expertise prerequisites that productivity assumed was not had.

The Pipeline Collapse Is Real, But It Is Selective and Detectable

I want to be honest about what I have personally observed that does support Faye’s concern, because I think the concern is real even if the scope is overstated. I reviewed code from three different startups in 2025 — not as a formal audit, but as a technical advisor being brought in after things had already gone wrong. In all three cases, the codebase had a distinctive signature I have come to recognize: consistent surface-level correctness, catastrophic edge-case blindness, and architectural decisions that looked reasonable in isolation but interacted destructively at scale.

In one case, a payments processing service had been built by a team of four engineers with an average of two years of experience, using AI tooling heavily from day one. The happy path worked perfectly. The error handling was a patchwork of retries that could, under a specific race condition involving a network partition during the confirmation step, charge a card twice without returning a duplicate charge error to the caller. Nobody on the team had ever built a payment system from scratch without AI tooling, and the AI tooling had helpfully generated the idiomatic Stripe integration without generating the intuition that payment systems require paranoid pessimism about partial failures. The bug was live for four months before a customer complaint triggered investigation. The cost was not catastrophic. It was not zero.

This is the precise failure mode Faye is pointing at. The code looked right. The tests passed. The engineer did not know what they did not know, and the AI did not surface the gap. David Cramer’s quote from the article is the most honest thing in the piece: “I will flex and show you how broken the code is 100% of the time.” Cramer co-founded Sentry, which exists specifically to make the invisible visible. His vantage point is empirical. He sees error telemetry from tens of thousands of production applications running AI-generated code. When he says the code is broken 100% of the time, he does not mean syntactically broken. He means broken in the ways that observability systems are designed to catch — unexpected paths, unhandled states, assumptions that held in development and failed in production.

The second startup I looked at had a different failure mode. The AI tooling had been used to generate a microservices architecture that was internally consistent and externally incoherent. Each service was well-structured. The service boundaries were wrong in a way that guaranteed high-latency joins for the queries the application actually needed to perform. A senior engineer with distributed systems experience would have caught this in the design phase. The team did not have a senior engineer with that background, and the AI tool had optimized for “looks like good microservices architecture” without having any model of what the application’s actual query patterns would be. Migrating the service boundaries eighteen months into production took three engineers six weeks of careful, manual work.

These are real costs. They are also detectable costs, and they point at a solvable problem: the absence of experienced review at the design stage, not the presence of AI tooling at the implementation stage. The tools did not cause the failures. The absence of human judgment at the layers where human judgment is not replaceable caused the failures.

Where the Thesis Overreaches: The Utility Analogy Works Differently Than Faye Thinks

The Sam Altman quote Faye opens with — intelligence as a utility, sold on a meter — is being used as a dire warning. I think it is actually a prediction that will partially come true, and that this is not the catastrophe Faye implies. Consider the utility analogy more carefully.

Electricity is a utility. The existence of cheap, reliable electrical power did not eliminate electrical engineers. It eliminated the need for every factory to employ someone who understood AC versus DC power generation at the level of a 1910 electrical contractor who had to specify and commission their own generation equipment. The expertise did not disappear. It concentrated in a smaller group of people who work at the infrastructure layer — grid engineers, power plant operators, electrical code inspectors — while a vastly larger group of people learned to use the utility effectively without understanding its internals. The total number of people who understand electrical systems at a deep level is probably higher now than it was in 1930, because the economy that the utility enabled is large enough to support more specialists.

Software engineering will stratify the same way. The question is not whether entry-level cognitive work will be absorbed by AI tooling — it will, and faster than most people expect. The interesting question is what the intermediate layer of “knows enough to use the tools effectively and catch their failures” actually requires, and whether that intermediate layer is teachable in a way that the current industry’s onboarding practices can support.

Faye’s checklist is an attempt to answer this. It is a good checklist. “Could I accomplish this task without the AI tool?” is a meaningful self-diagnostic. “Am I using the model to deepen understanding or expedite the answer?” is the right question. But a checklist is a procedure, and expertise is not a procedure. The gap between “follows the checklist” and “has internalized why the checklist items matter” is exactly the gap that the friction of learning is supposed to close. Asking junior engineers to apply a checklist about expertise does not give them the expertise to apply it correctly. That requires the foundational understanding the checklist is supposed to verify.

The Actual Structural Intervention That Is Missing

I have been managing engineering teams in various capacities since 2011. The intervention that consistently works is not asking developers to resist AI tooling. The intervention is changing what gets evaluated at the hiring stage, the promotion stage, and in day-to-day code review.

When I interview engineers today, I use a specific two-phase protocol. The first thirty minutes use their normal tooling, including AI, on a problem they have seen variants of before. Then fifteen minutes on a variant I have not given them, with AI assistance disabled. The delta between the two performances is more informative than either score individually. An engineer who performs identically in both sessions has either genuinely internalized the domain or is experienced enough to reconstruct the AI’s approach manually — both of these are things I want to hire. An engineer whose performance collapses in the second session has told me exactly what their AI dependency structure looks like under controlled conditions. I am not trying to trick anyone. I tell candidates in advance that the second phase disables AI. What I am measuring is the gap, not the absolute performance.

Most teams do not do this. Most teams have adapted their interview processes to allow, or even encourage, AI assistance throughout, because the post-interview task — writing production code — also uses AI. The reasoning is internally consistent. The outcome is that they are not measuring what they think they are measuring. They are measuring AI-augmented performance, which tells them almost nothing about the underlying capability that makes AI augmentation safe to deploy.

Code review has the same problem. The standard code review process asks: does this code work? Is it readable? Does it follow the style guide? It does not systematically ask: does the author understand what this code will do under conditions that are not covered by the test suite? That question requires the reviewer to have opinions about the problem domain, not just the code syntax. In teams where all engineers are using AI heavily, the reviewers often do not have those opinions because they have not developed the domain expertise that comes from debugging edge cases without AI assistance.

The solution is a review process that explicitly separates “does the code look correct” from “does the author understand what correct means in this context.” The second question requires the reviewer to ask the author to explain the code verbally, predict what will happen under specific edge conditions, and identify the assumptions the code is making about its inputs. This takes longer. It is worth doing. It is the pedagogical function that AI tooling cannot perform, because the AI will generate a confident, plausible explanation that may or may not reflect genuine understanding.

The Missed Opportunity in the Study Faye Cites

The Anthropic 2026 study on AI assistance and skill formation that Faye quotes — “cognitive effort and even getting painfully stuck is likely important for fostering mastery” — is being used as support for the friction-first argument. I think it actually points at something more specific and more actionable than “use AI less.”

The study’s key finding is not that AI assistance harms skill formation. It is that unrestricted AI assistance at the wrong stage of learning harms skill formation. The “tutor” condition in the UPenn study, which restricted AI to Socratic questioning rather than direct answers, produced dramatically better outcomes than either the unrestricted AI condition or the textbook-only condition in practice sessions. This is not an argument for resisting AI. It is an argument for a specific kind of structured AI use that is different from both “use it freely” and “don’t use it.”

The structured use requires knowing what stage of learning you are at for a given concept, which in turn requires the meta-cognitive skill of accurately assessing your own understanding. This is exactly the meta-cognitive skill that the illusion of competence problem described in the JetBrains study erodes. Junior engineers who use AI heavily become worse at knowing what they do not know, which makes them worse at knowing when to restrict their own AI use, which makes the illusion of competence problem self-reinforcing.

Breaking this loop requires external intervention. It cannot be solved by individual self-restraint, any more than a drug dependency can be solved by willpower alone without structural support. The structural support in this case is experienced engineers who can identify the gap between expressed confidence and demonstrated understanding, and who have the authority to adjust access to AI tooling accordingly. This is a management and process problem. Solving it requires changing management and process, not publishing checklists for individual developers to apply voluntarily.

What I Expect Over the Next Five Years

These are falsifiable predictions. I am stating them specifically enough that they can be checked against reality by 2030:

The junior-to-mid promotion rate will decline at companies without structured AI policies. Not because the engineers are incompetent, but because the behavioral signal that normally indicates readiness for mid-level work — debugging production incidents independently, making architectural tradeoffs under ambiguity, recognizing failure modes before they occur — will be harder to observe in AI-assisted workflows. The signal was always there. The AI tooling is obscuring it. By 2029, at least two major tech employers will publish retrospectives on this problem and the internal policy changes it prompted.

A specialist market in AI-output auditing will emerge as a recognized discipline. Analogous to how security auditing became a distinct function from software development in the 2010s, this discipline will focus on correctness properties that automated testing does not catch: semantic correctness, domain-specific edge cases, architectural coherence under load patterns not represented in the test data. By 2028, at least five companies with more than 1,000 engineers will have a formal role whose primary function is this kind of review. The job title will not say “AI” in it, because the role will look like senior engineering from the outside.

Graduated AI restriction policies will show measurable reliability improvements. Companies that tie AI code generation access to demonstrated domain mastery — measured through specific evaluation criteria at the hiring and promotion stages — will outperform peer companies on engineering reliability metrics within three years of implementation. The effect will be hard to attribute causally in individual cases, but will be visible in aggregate incident frequency data. The companies that figure this out first will not publish it, because it will be a competitive advantage.

The JetBrains study findings will replicate with a pedagogical intervention that moderates the effect. The replication will show that structured prompting templates — which force the learner to specify their expected approach before asking the AI to generate code — significantly reduce the illusion-of-competence outcome. This will validate the “tutor” model over the “generator” model and give companies a more specific intervention than “use AI less.” I expect the replication to come from a university research group collaborating with a major IDE vendor, and I expect it to be published by 2027.

The expertise pipeline is not collapsing. It is being restructured, unevenly, by people who did not design the restructuring and are mostly discovering the consequences by accident. The reconstruction will be painful. The intermediate period will produce identifiable failures that are more visible than the failures that occurred before AI tooling, because they will be concentrated in production systems rather than in the development cycles where junior engineers used to make their expensive mistakes. And the industry will adapt in ways that preserve expertise at the layers where it still matters.

It has done exactly this, every time, for thirty years. The question is not whether it will happen. The question is how much unnecessary cost the industry accumulates before the adaptation is complete. That cost is a function of how quickly companies build the structural interventions — in hiring, in code review, in promotion criteria — that the tooling transition requires. Faye’s checklist is a reasonable starting point for individual practitioners. It is not a substitute for the organizational response that the situation demands.

The Unsexy Answer: Differentiated Access, Not Blanket Restriction

Every organization I have consulted for in the last two years has been wrestling with the same surface-level question: should we restrict AI tooling or not? The question is wrong. The right question is: for which engineers, at which stages of their development, on which categories of problems, should AI code generation be available? Answering that question requires doing the work of defining what “intermediate understanding” means in your specific domain, building evaluation instruments that measure it, and enforcing the policy consistently. None of this is glamorous. All of it is tractable.

The companies that have moved fastest on this — and I am aware of three that have implemented explicit tiered access in 2025, though none of them want that fact publicized — have done so by borrowing from the medical residency model. Residents are not restricted from using diagnostic decision-support tools. They are required, by explicit policy, to form their own diagnosis before consulting the tool, and they are evaluated on the quality of their reasoning, not just the accuracy of their final answer. The tool is available. The scaffolding around the tool’s use is what produces the expertise.

Software engineering organizations can do the same thing with AI code generation. The technical implementation is not complicated: most AI tooling can be deployed with access controls. The hard part is defining the criteria and building the evaluation culture. That is a people and process problem, and it is the problem Faye’s article should have ended on. Instead, it ends on a checklist for individuals to apply voluntarily in an ecosystem that is, as Faye himself notes, actively working against that kind of restraint. Individual checklists are the right personal practice. They are not a systemic solution.

The expertise pipeline will survive this transition. I am confident of that, because it has survived every analogous transition before it. What is genuinely at risk is the intermediate period — the next five to eight years, during which a generation of engineers will form their initial mental models of software development in an environment that has not yet built the right scaffolding around AI tooling. Those mental models will be harder to revise later than they would have been to form correctly in the first place. That is the real cost of getting this wrong, and it is the cost that Faye’s article is pointing at, even if the proposed solution undershoots what the problem actually requires.

The friction is a feature. Building systems that preserve the right friction, for the right engineers, at the right stage of their development, is harder than either “ban AI” or “embrace AI.” It is also the only approach that takes both the tools and the expertise seriously enough to do justice to either.

The analogy I keep returning to is the introduction of power tools into carpentry. A hand saw requires the carpenter to feel the resistance of the wood, adjust pressure, correct for drift, and develop a physical intuition that no amount of watching could substitute for. A circular saw eliminates that particular friction. It does not eliminate the need for the carpenter to understand wood grain, kerf width, blade selection, or the physics of what happens when a blade binds. The experts who adopted circular saws early were more productive than those who resisted them. The novices who adopted circular saws without the foundational manual experience made different mistakes than their predecessors — faster mistakes, sometimes more dangerous ones, and in contexts where the tool’s limits were less obvious because the tool itself was so capable.

The industry figured out the right scaffolding for power tools: safety training, graduated access, apprenticeship norms that persisted even as the tools changed. Software engineering will figure out the analogous scaffolding for AI coding tools. The question is how many avoidable incidents it takes to motivate that figure-out, and whether any organizations are willing to do the work proactively rather than reactively. Based on what I am currently seeing, the answer is mostly reactive. The industry will learn the right lessons eventually. It will learn them from production failures, not from articles, no matter how accurate the articles are.