Controlled Friction as Engineering Practice

In the AI Story

The practice meets predictable resistance in organizations that measure productivity through output metrics. A team spending three hours per week on manual implementation is a team producing less output than a team using AI for those three hours. The quarterly numbers are lower. The manager who authorizes the practice must justify, to a leadership team that measures output, why the team is deliberately producing less of it. The justification is the justification for any insurance premium: the cost is visible and constant; the cost of not insuring is invisible until catastrophic.

The aviation parallel is not metaphorical — it is structural. Pilots are professionals whose daily work does not require the skills they must maintain. Mandatory hand-flying hours exist because the industry learned, at the cost of human lives, that pilots who never exercise manual skills cannot deploy them under emergency conditions. The skills atrophy through disuse. The atrophy is invisible on normal flights. It is decisive on the abnormal ones. Software engineering is approaching the same structural situation with AI tools, and the aviation industry's response is the most developed institutional model available.

The content of a controlled-friction session matters less than the consistency. A small team might spend one afternoon a week implementing a feature without AI assistance. A larger organization might run quarterly 'bare metal weeks' where specific projects are deliberately built by hand. Post-incident reviews can be treated as structured friction, requiring deep engagement with the implementation layer where the incident occurred. The forms vary; what matters is that the practice is regular, deliberate, and protected from the productivity pressures that would otherwise consume it.

The practice also serves a teaching function. Senior engineers carrying the deep diagnostic strata that the Law of Leaky Abstractions makes valuable are the ones who can model what implementation-level work looks like. Junior engineers who have only worked in the AI-augmented environment have, by default, no exposure to the practices that build diagnostic intuition. Controlled friction is the mechanism through which the transmission happens — not through documentation, which captures explicit knowledge imperfectly, but through shared practice, which is how tacit knowledge has always been transmitted.

Origin

The concept of controlled friction as a named engineering practice was developed in 2025–2026 by practitioners responding to the observable consequences of full AI adoption. Its closest precedents are the aviation industry's recurrent training protocols and the 'manual code review' discipline that some organizations maintained through the transition to IDE-based auto-completion. The explicit framing as 'controlled friction' appears in Chapter 10 of this volume and in Edo Segal's epilogue, where he describes implementing weekly AI-free sessions on his own team.

Key Ideas

The practice is training, not protest. Its purpose is skill maintenance, not rejection of AI tools.

It requires institutional protection. Short-term productivity metrics will always argue against it; organizational commitment is the only counterweight.

Consistency matters more than form. The specific shape of a friction session varies; what matters is that it recurs on a schedule the productivity pressures cannot consume.

It serves a teaching function. Junior developers who have only worked with AI tools learn implementation-level craft through shared practice with senior engineers.

The aviation model is the best-developed precedent. Mandatory hand-flying hours are the specific institutional mechanism that maintains skills automation erodes.

Debates & Critiques

Skeptics argue that controlled friction is a romantic reaction to a structural change that institutions should simply adapt to — that the expertise the practice preserves is becoming genuinely obsolete, as typewriting skill became obsolete after the typewriter. The defenders' response is that the analogy fails: typewriting was a pure input mechanism, whereas implementation-level knowledge is the specific capability demanded when the abstraction fails. Until AI-generated systems stop leaking (which Spolsky's law predicts they will not), the capability will remain necessary, and its deliberate maintenance will remain justified.