The Wall in Week 8

By week seven, the team was flying. A student project, AI-accelerated, shipping features faster than anything Professor Margaret-Anne Storey had supervised in a decade. Then, by week eight, they were paralysed. Not by bugs. Not by a server outage. By the silence in the room when she asked them to walk through a simple change.

In her essay on cognitive debt, Storey describes the moment with unsettling clarity: "By weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected… no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together… They had accumulated cognitive debt faster than technical debt, and it paralyzed them."

The code wasn't messy. The architecture wasn't the problem. The theory of the system — the shared mental model of why anything had been built the way it had — never formed in the first place. The code shipped fast for two months. The understanding never did.

This is not a student-team story. It is a population-scale one, and most of us think we already know what it looks like. The honest data is sharper than that.

The Metric You Thought You Saw

You have probably read the line: Stack Overflow visits dropped from 200,000 to 3,607 a month. It has been quoted in keynote decks and podcast intros for a year. It is also wrong — in the way precise people care about.

The 200,000 figure is questions per month at the 2014 peak, not visits. The forum still serves millions of monthly readers consulting the archive. What collapsed is the question volume. DevClass put December 2025 at around 3,862 questions — a 78% year-on-year decline and roughly 97% off the 2014 high. Gergely Orosz called it "as low as when Stack Overflow launched in 2009." Stack Overflow cut 28% of its staff in October 2023. The archive is alive; the contribution layer is dead.

The other line worth correcting: the "40% senior speedup" figure in practitioner threads is not senior-specific — it is a gross task-time speedup pulled from mixed-seniority lab studies. Cui et al.'s Microsoft and Accenture field experiments (1,974 developers) point the other way: juniors gain more. Seniors approach zero. METR measured experienced developers 19% slower with AI while they felt 20% faster — the same perception-reality gap I have written about elsewhere in this series.

The inversion the data supports is uncomfortable: AI makes junior output look senior-level, while the skill formation underneath is what's at risk. And the sharper distinction has been sitting in the cognitive-science literature for twenty-five years.

Atrophy vs Foreclosure

Two failure modes look identical on a dashboard. They are structurally different.

Atrophy is a skill you built and are losing through disuse. The senior engineer who hasn't written a regex from scratch in two years. The muscle is dormant, not gone. A weekend of practice brings it back. Reversible.

Foreclosure is a skill that never gets built at all. Much harder to reverse, because the substrate to build on never formed. You can't refresh a map you never drew.

Maguire et al. (PNAS, 2000) measured the hippocampi of London taxi drivers — the ones who had memorised "the Knowledge," 25,000 streets and 100,000 landmarks. The posterior hippocampus was measurably larger than in controls, and its volume correlated with years driving. The brain physically adapted to the skill being practised.

The cohort that learned to drive after Google Maps never built that substrate. They reach the destination just as reliably. The internal map is never drawn.

If atrophy is the senior risk, foreclosure is the junior one. So the question becomes: what previously caught the foreclosure, and what did we just lose?

Rendering diagram...

The Collapsed Learning Layer

Stack Overflow was never primarily a place to get an answer. The cognitive value was the wrestling. Formulating a precise question. Reading three wrong answers and noticing why they were wrong. Watching senior engineers correct each other in public over a typo in a regex.

AI returns an answer, not a thread. There is no wrong-answer-then-correction arc to read. There is no public formulation of the problem. There is no community signal that says "this question is malformed, here's how to think about it." That whole social verification layer is gone for juniors. The strain has been engineered out.

Cal Newport, writing about exactly this: "In a learning environment, the feeling of strain is often a by-product of getting smarter. To minimize this strain is like using an electric scooter to make the marches easier in military boot camp; it will accomplish this goal in the short term, but it defeats the long-term conditioning purposes of the marches."

Strain is the learning. AI removes the strain. The march finishes. The legs don't develop.

This is what was unfolding in week eight of Storey's project. No public formulation, no peer correction, no wrestling — just confident, plausible code that ran until it didn't. Then a single Anthropic paper, published in January, made the mechanism measurable.

AI-Enhanced Productivity Is Not a Shortcut to Competence

Shen and Tamkin (arXiv:2601.20245), Anthropic, January 2026. A randomised controlled trial: 52 junior software engineers learning a new Python async library, split into AI-assisted and no-AI conditions. The headline finding: AI use impaired conceptual understanding, code reading, and debugging — without delivering significant efficiency gains on average.

The split inside the AI group is the part that matters.

Passive delegators — the engineers who asked AI to generate code — scored 24–39% on the comprehension quiz. Active explainers — the engineers who asked AI to explain concepts rather than write code — scored 65–86%. Same tool. Same library. Forty-point gap.

The paper's verbatim conclusion is the line worth carrying around: "AI-enhanced productivity is not a shortcut to competence."

The narrower, more useful reading: the mode of use determines whether the tool builds skill or forecloses it. Same tool, two trajectories, depending on whether the engineer asks it to think with them or for them. Fifty-two engineers is a small sample and the longitudinal question — does the gap close or widen over five years? — is still open. But sitting on top of Maguire, Storey, and the collapsed learning layer, the finding lands.

So what does mode-of-use look like on a real team, this quarter?

Three Things That Work

I have tried versions of these on the teams I run. They cost nothing — no budget line. The first one starts tomorrow.

1. Implement twice. Addy Osmani's recommendation, verbatim: "Implement projects twice, once with AI, once without, and compare." And: "occasionally disable your AI helper and write key algorithms from scratch." Most teams won't adopt this for production work. As an onboarding protocol or a side-project habit, it is the closest thing to deliberate practice we have for this era. The second pass is the calibration: it shows the junior what their hands knew versus what the AI knew.

2. Default L1/L2 to Socratic mode. A system-prompt tweak, no more. The AI is told, up front, that it must not rewrite the code — it must point at the line, explain the conceptual flaw, and ask the engineer a question. This maps directly onto what the Shen and Tamkin high-scorers were doing organically. For juniors, make it the default AI mode for the first two years on the team, the path of least resistance. The foreclosure stops.

3. Seniority-gated review where the author has to explain the code. The reviewer's first question for any L1/L2 pull request is always the same: walk me through this block. If the author cannot, the PR does not merge. This is the rule code review was always supposed to be; AI just made it possible to skip without anyone noticing. Reinstating it is free — you just have to mean it. Or, as Osmani put it: "If the original author can't explain why the code works, how will the on-call engineer debug it at 2 AM?"

Which brings me to the post I wrote six weeks ago. And the contradiction I owe the reader an answer to.

Two True Things

I wrote AI as the Great Equaliser in April. It argued that AI is the first accommodation neurodivergent professionals can access privately, without disclosure — a tool of agency, dignity, and inclusion. I stand by every word.

This post argues that AI is foreclosing skill formation in a generation of juniors. I stand by every word of this one too.

Both are true because the practice around the tool is the variable, not the tool. AI used to translate ability — to take the idea you already had and clear the path between your head and the workplace — is liberating. AI used to substitute for the cognitive work that builds the ability is corrosive. The difference is which side of the foundational-skill line the user is standing on.

The three interventions above keep that line visible. For the juniors you hire. For the ones you mentor. For the engineer you used to be — the one who wrote the bad regex four times before getting it right, and who is now the senior because of those four wrong attempts.

I'm the senior now. So is anyone reading this who manages a team in 2026. The next post in this series looks at the five-layer harness — the deterministic scaffolding that gives all of this somewhere to live. That is the systems side; this is the human side of what the 5-Step Loop post named at the architecture level. The verification gap isn't only inside the agent. It is inside the people who used to be the verification.

The wall in week eight was never about the code. It was about what the code had cost the people writing it.