The Frictionless Trap

Skip to main content

I've been observing several teams with high adoption of AI coding agents recently. PR volume is up, and perceptions of productivity are higher. The surface looks healthy.

But engineers naturally seek the simplest path to a working solution. This is mostly healthy — pragmatism is a professional virtue. Under delivery pressure, though, that tendency extends further: into skipping the cognitive work that builds understanding, not just the work that builds features.

AI coding agents don't create this tendency. They lower the friction on it. In teams where throughput is the dominant metric, the default quickly becomes: let the agent write it, ship it, move on. And something quieter begins to thin.

The code gets written faster. The understanding doesn't. And the more I think about it, the less I believe code generation itself is where the real shift is happening.

Engineering organisations depend on something they've never had to deliberately build: the accumulated understanding of the systems they operate. It forms as a byproduct — through years of implementation, debugging, and the slow development of accurate mental models of how things actually behave under pressure. It lives in how engineers reason, not in documentation. AI coding agents are changing the conditions under which it forms.

Some of the strongest engineers I've worked with were never primarily valuable because they could write code quickly. What made them effective was their ability to build coherent mental models across multiple layers of the system — usually through years of debugging difficult issues, tracing unexpected behaviour, refining broken assumptions, and gradually developing intuition for how the system actually behaved. Not from reading documentation. From repeated direct encounter with the system itself.

Learning theory has long observed that durable understanding forms through active reconstruction rather than passive exposure.¹ Implementation work, in hindsight, may have always carried a second function beyond delivery: it forced engineers to reconstruct parts of the system internally until those models became intuitive. Not as a side effect — as the mechanism. I'd call it the reconstruction dividend — the part that quietly disappears when friction does.²

This becomes easier to miss because modern software organisations already separate most engineers from large parts of the underlying system — through frameworks, platforms, APIs, and cloud services that abstract away physical constraints. None of this is inherently bad. Most of it is precisely what allows modern systems to scale.

But abstraction has always involved a tradeoff. It removes cognitive load locally while also increasing the distance between engineers and the underlying behaviour of the system. AI-assisted development compresses that distance further.

What makes this hard to see is that gains appear immediately while costs remain mostly invisible for long periods. Complex systems tend to hide the consequences of optimisation until stress reveals where understanding has become thin.

The immediate impact of AI-assisted development is easy to measure because output is measurable. Delivery speed, implementation throughput, and PR velocity all surface quickly in operational metrics. Understanding does not. I've yet to see a dashboard that captures whether a team actually understands the system they're operating. Shared mental models, debugging intuition, architectural reasoning, and deep systems comprehension compound slowly and erode quietly.³

Teams can continue operating successfully long after parts of the underlying understanding have begun to thin beneath them. In fact, highly optimised environments often become operationally successful precisely because they reduce the amount of direct cognitive engagement required from individuals during normal execution paths.

The problem is that expertise rarely forms during normal execution paths.

A system that keeps working smoothly provides no forcing function for the reconstruction that builds understanding. High throughput, clean dashboards, few incidents — these are exactly the conditions under which the gap stays invisible longest.

It forms during reconstruction. During ambiguity. During debugging sessions where the system behaves differently than expected. During incidents that force people to mentally traverse multiple abstraction layers at once until a coherent explanation emerges.⁴

AI-assisted development does not remove the need for understanding. But it changes the conditions under which understanding forms — and that distinction matters more than it might appear.

That gap surfaces the first time the system breaks in a way the implementation didn’t anticipate, and no one on the team has the right model to explain it. The code didn’t fail. The understanding to interpret the failure was never built.

It's possible that AI changes where this reconstruction...