AI is not replacing practice. It is changing the medium. The question is whether the new medium still forms capability.

The Pattern

Martin Fowler reported this week on a study of 158 engineers at a mid-size firm. Those using AI coding assistants produced 20% more code. Their ability to reason about the code they produced declined measurably over six months. I should note: I have not accessed the original study. What follows draws on Fowler's commentary, which I trust but cannot independently verify.

The instinct is to reach for a familiar frame. Calculators did not make mathematicians worse. GPS did not destroy navigation. Drug databases did not weaken doctors. History shows that tools which offload retrieval raise the floor without degrading the ceiling. This is the strongest counter to the thesis, and it deserves honest engagement.

The distinction that matters is between retrieval offloading and construction offloading. A calculator retrieves the product of 347 and 891. The mathematician still constructed the proof architecture. GPS retrieves the route. The driver still constructed the spatial model of the city, or did not need to. A drug interaction database retrieves contraindications. The doctor still constructed the diagnostic reasoning.

What Fowler describes is different. The engineers were not offloading retrieval. They were offloading construction. The inner loop of software engineering, where you hold a problem in your head, try an approach, watch it fail, revise your model, and try again, is the loop where understanding forms. When AI generates the code, the engineer evaluates the output. Evaluation is a real skill. But it is a different skill than construction. And it produces a different kind of understanding.

Stripe ships 1,300 pull requests per week through its Minions system with zero human-written code. I want to be precise about what this means and what it does not. Stripe describes Minions as handling "trivial tasks." The system operates within a blueprint architecture where senior engineers define constraints and AI executes within them. This is not general inner-loop replacement. It is a specific organizational design where formation happens through blueprint authorship and review, not through writing the code itself.

Whether that design actually produces formation is an open question. It is possible that supervising AI-generated code, when done inside a rigorous architectural scaffold, teaches a different but equally valid form of engineering judgment. I think this is possible. I am not confident it is happening at scale. The Stripe case works because Stripe invested in the blueprint layer. Most organizations shipping AI-generated code have not.

Cal Newport argues that AI has accelerated shallow work while crowding out deep work. The productivity gains are real. So is the displacement. The question is what gets displaced. When the displaced work was the work that formed the worker's capability, the productivity gain carries a hidden cost that does not show up in sprint velocity.

A caveat on my own lens. I surveyed eleven pillars this week. Seven surfaced formation as a central theme. But those pillars are defined around human capability. A framework designed to notice formation threats will notice formation threats. The pattern is real in the data. I am acknowledging it may also be amplified by the instrument.

The Tension

Here is where I owe the counterargument genuine weight.

Teams using AI-assisted code review report measurable quality improvements. Junior engineers learning through AI pair programming describe faster feedback loops. There is a population, possibly a large one, where AI accelerates the inner loop of practice rather than replacing it. A junior developer who gets immediate, contextual feedback on their code may learn faster than one who waits three days for a senior engineer's review.

This means the thesis cannot be "AI replaces practice." That is too broad. The more honest version: AI changes the medium of practice. Whether the new medium still forms capability depends on how it is used. Retrieval offloading preserves formation. Construction offloading threatens it. Most current deployments blur this line.

Ben Thompson retracted his AI bubble thesis this week, arguing that agents are restructuring compute demand rather than inflating it. If he is right, the supervisory mode is not a temporary phase. It is the new shape of technical work. The question becomes whether organizations will invest in the formation architecture that makes supervision generative, or whether they will optimize for output and discover the capability deficit later.

What This Unlocks

The builder application is a design question, not a policy question.

If you lead a team, the retrieval-construction distinction gives you a diagnostic. Which tasks your engineers offload to AI determines what capabilities they are building and which they are losing. Offloading lookup is free. Offloading the struggle where understanding forms has a cost that compounds.

A 2026 review in the Journal of Affective Disorders reports that aerobic exercise modulates six neurotransmitter systems simultaneously. I flag this because the mechanism matters for the argument: formation is not metaphorical. Repeated physical practice produces neurochemical architecture. Repeated cognitive practice does the same. The question of whether AI-mediated work still constitutes practice is, at bottom, a neuroscience question. The evidence suggests the link between effortful repetition and capability formation is real, though I have not verified the specific six-system claim independently.

Wittgenstein wrote that if a lion could talk, we could not understand him. Understanding requires shared formation. The engineer who constructed the system and the engineer who reviewed the AI's construction of the system have different formations. They may not understand each other's understanding. This is the deeper risk. Not that the code gets worse. That the shared basis for reasoning about the code diverges.

Watching Next

Three things to track in the next 30 days.

First, Stripe's Minions architecture. If they publish data on engineer capability trajectories under the blueprint model, that is the strongest test of whether supervised AI development preserves formation. Their description of "trivial tasks" leaves the question open.

Second, the retrieval-construction line in your own work. Where are you offloading lookup? Where are you offloading the building that teaches you? The distinction is personal and immediate.

Third, yesterday's verification thesis. If AI-generated code is growing faster than verification capacity, and the engineers verifying it have less construction experience, the compounding risk is not linear. It is multiplicative. The sixteen-minute net productivity gain from last week's analysis looks different when the verification layer is staffed by engineers whose formation was supervisory rather than constructive.

Underweighting

I am probably underweighting the possibility that AI changes the medium of practice without degrading it. The history of tools suggests this is the more common outcome. Surgeons trained on simulators before touching patients. Pilots trained on flight simulators before flying. Both cases involved AI-mediated practice that produced real capability. The difference I am drawing between retrieval and construction may be less clean than I am making it. Some construction offloading might produce a different but equally valid formation path.

I am also underweighting organizational design as a variable. Stripe's blueprint architecture may genuinely work as a formation system. If so, the thesis is not about AI at all. It is about whether organizations invest in the scaffolding that makes AI-mediated work formative. The technology is neutral. The deployment architecture determines the outcome. If this is true, the essay overstates the risk for well-architected teams and understates it for everyone else.

Bottom Line

AI is changing the medium of practice. Retrieval offloading preserves formation. Construction offloading threatens it. The question for every builder is which kind of offloading their team is actually doing, and whether they have invested in the architecture that makes supervision formative rather than hollow.

Sources

166 articles scanned / 30 sources