Deliberate Friction

The agent finishes. The diff is four hundred lines, the tests pass, and the summary says exactly what I wanted to hear. I skim it, approve it, and write the next prompt. The whole exchange takes three minutes, and it feels like competence.

It is the third time today. If a colleague asked me to explain any of these changes, I would have to read them first.

Write a prompt, let the agent work, skim the result. That flow is comfortable and productive. It is also a training regimen for exactly the wrong thing. Delegating to an agent draws on skills built long before it: writing code yourself, holding a design in your head, reading critically, putting intent into clear words. Those stay sharp only through use. The same flow that makes delegation productive removes the reps.

Fluency feels like competence

Uberto Barbini, author of Process Over Magic, described the mechanism in a way that stuck with me. AI speed creates cognitive fluency, and fluency creates confidence. When a problem shows up, we do not slow down to understand it. We hand it back to the agent. Each fix feels cheap in isolation, so nobody tracks the cumulative cost. He calls the result Brownian motion drift. Scope expands, changes nobody asked for accumulate, and the time savings evaporate.

Unfortunately the tools reward exactly this behavior. Everything about agentic work nudges toward fast, automatic thinking. Getting real value out of it means bringing the slow kind back on purpose. Set a clear goal before the prompt. Decide where you will stop. Resist “just one more change.”

That sounds manageable, until you notice that the eroding skills and the correcting skills are the same ones. The discipline to review deeply depends on the ability to review deeply, and that ability is what skimming wears down.

The manager’s chair

This is not really a new problem. Managers have lived with it for decades. The moment you lead, you stop doing the work yourself, yet your value depends on still understanding it. Engineering management never fully solved this, but it developed real practices. Stay hands-on through small, low-stakes tasks. Review a few things deeply instead of everything shallowly. Pair. Keep one area of personal mastery. Decide which skills to maintain and which to let go.

AI delegation puts every developer in that chair, without the title and without the warning. The manager’s playbook is the best starting point we have.

One area of mastery

When my work at RYTLE shifted toward management, I applied one of those practices without knowing how general the question would become. I kept a single area for myself and stayed its main developer: the planning engine of our disposition software.

The decision mattered less than the selection criteria. The area was well within my technical competence, so the hours there kept real skills in use. More importantly, it was loosely coupled to the rest of the system; I could develop it with little synchronization. That second criterion was the one that mattered. Staying hands-on never put me on anyone’s critical path, which is where this usually goes wrong. A lead holds on to the interesting work, and the team waits.

There is a general rule hiding in that. Reserve hands-on work where the iteration loop is yours alone, so that being slow is a price only you pay. It translates directly to working with agents. The tasks worth doing yourself are the ones where your slowness costs nobody else anything.

Deliberate friction means doing some work yourself, on purpose, at a known cost, because the slowness is the practice. It has nothing to do with nostalgia for handwritten code.

Letting go on purpose

Not every skill deserves maintenance. I have let syntax fluency go. I do not remember argument orders or the argparse boilerplate anymore, and I do not plan to relearn them. Some knowledge is now a lookup, and that is fine.

Architectural judgment and critical review are different. They are the acceptance step - the moment where delegation either means something or does not. When they decay, nothing visibly breaks. The approvals keep flowing; the judgment behind them thins out.

So the discipline is choosing. Letting a skill go deliberately is a decision. Finding out it left on its own is the failure mode.

The honest caveat

Something keeps me from writing this as advice. Many managers lose their technical edge despite knowing everything above. The playbook half-works at best. If decades of engineering management could not reliably beat this problem, a paragraph about deliberate friction will not either.

Two differences give me some hope. The feedback loop is shorter. A manager can drift for quarters before the gap shows; agent output crosses my desk daily, so decay has less room to hide. And the practice dose is cheaper. Actually reading one diff costs twenty minutes; a manager has to defend a full coding day in their calendar. Whether that is enough, I do not know yet. I notice the pull toward skimming every day, and noticing is not the same as resisting.

The next diff is already waiting, with the same choice as every diff before it. Read it, or skim it and feel fluent. Most days, nobody can see the difference. It compounds anyway.