Skip to content
Blazej Mrozinski
PL

Deliberate Friction Is the Design Pattern Against AI Cognitive Offloading

Deliberate Friction Is the Design Pattern Against AI Cognitive Offloading

The single most counterintuitive design choice I make when wiring AI into a workflow is putting friction back in. Friction is exactly what AI is sold as removing. The whole pitch is that the model handles the boring parts, the slow parts, the parts where you used to wait for someone else to weigh in. Most AI integration projects optimize for less friction. The ones that hold up over time do something more selective. They strip out the wasteful friction and then engineer specific kinds of friction back into the parts of the workflow where the friction was doing real work.

This shows up across three company cases I have been reading about and in the way I run my own work. The pattern is consistent enough that I am going to call it a design pattern, with all the load-bearing weight that phrase implies.

Table of Contents

Three companies that engineered friction back in

The three cases come from a Harvard Business Review article by Graham Kenny and Ganna Pogrebna. The authors describe the companies under pseudonyms, so what follows is their account, retold.

An Australian telecom carrier noticed that its planning teams had become “order-takers from the algorithm.” They could present three AI-generated strategy options and could not defend why one was superior. The fix was a cadence of strategy sessions without AI in the room. Cross-functional teams had to argue strategic questions on their own judgment, document the reasoning, and only after that consult the model. Alongside that came a six-month residency that rotated high-potential managers through complex decisions with the head of strategic planning. The residency existed to rebuild the human capacity that the previous AI workflow had been quietly thinning.

A U.S. regional bank watched its credit committee start making decisions on autopilot. The committee still met. Senior lenders still reviewed a slice of the applications, roughly 15% of them. Yet the committee leaned so heavily on AI recommendations that it had stopped doing the deliberative work it existed to do. The bank’s response was to add “credit standards roundtables,” held every quarter, at which the committee argues out and writes down how its lending criteria should evolve. The committee had been asking the per-loan question of whether a given application met the bank’s standards. The roundtables added the meta-question that had been missing, namely whether the standards themselves were still the right ones. The bank also changed how junior analysts train: rotations through committee apprenticeships and paired sign-offs with senior lenders on complex cases, a pipeline that had not previously existed.

A U.K. advertising agency lost clients even though its campaigns were hitting their performance metrics. Exit interviews surfaced a complaint that working with the agency felt like using a vending machine, with no creative partner on the other side. The agency banned AI-generated content from client-facing presentations and required teams to build original strategic narratives. It also gave every account a senior “strategic lead” whose job was specifically to challenge AI outputs and argue for approaches the algorithms might miss.

In all three cases the company kept the AI. None of them rolled back. What they added was deliberate friction at exactly the points where the previous AI workflow had been removing friction that was doing real work.

What cognitive offloading to AI quietly removes

If you read the case studies one at a time they are about three different problems. Strategic capability in the telecom. Deliberative function in the bank. Creative judgment in the agency. They are about three things that are easy to lose without noticing.

The harder thing to see is the common mechanism. In each case, the AI took over a whole process, and that process had cognitive byproducts. When a planning team wrestles with a strategic question on judgment alone, it produces a recommendation and, in the same motion, practices the work of producing recommendations under uncertainty. When a credit committee debates a case, it approves or denies the application and also surfaces implicit standards and updates them in real time. When account teams build creative narratives by hand, they deliver a deck and also develop the muscle to defend creative choices to clients.

Removing the deliberative process removes the deliberation, and it removes the byproduct along with it, which was the practice that maintained the capability. The capability atrophies gradually, the way any skill atrophies without use. The atrophy is hard to detect because the visible output, recommendations, decisions, decks, still gets produced. The thing that goes is the underlying competence to produce the visible output without the AI on the next, harder, qualitatively different problem.

A second mechanism shows up in the work on how AI affects social bonds. When employees turn to AI for advice and answers instead of to colleagues, the speed gain is real. The cost is the small acts of help and consultation that used to build mutual reliance. Constance Noonan Hadley and Sarah Wright surveyed 1,545 U.S. knowledge workers who use AI regularly at work. Three in four used it for at least one kind of personal support, such as career advice or emotional validation. More than half still rated themselves moderately or highly lonely at work, and their relationships with coworkers predicted job satisfaction more strongly than any AI variable the researchers measured. My reading is that the AI is doing exactly what it was asked to do, and the asks were quietly subtracting the ground on which trust gets built.

In both mechanisms the failure mode is the same. AI makes the visible work easier. The work that was invisible, but actually load-bearing, gets thinned at the same time. Companies that ignore the second part end up “technically advanced but competitively fragile.” The phrase is Kenny and Pogrebna’s, and it is a good one because it captures the lag. The fragility stays invisible until something demands the capability that has quietly been lost.

Why speed is the wrong metric for an AI integration

The rhetoric around AI integration is dominated by speed. Faster drafts. Faster decisions. Faster onboarding. Faster everything. Speed is a real metric and worth pursuing in the parts of the work where speed is what was missing.

Speed is also a misleading proxy for value when the work being accelerated has cognitive byproducts that compound over time. The credit committee’s value lay in the slow, repeated, deliberate practice of debating standards. How fast it approved loans was secondary. Cutting that practice to zero removes the function the committee existed to perform. The new shorter committee meeting is a different artifact from the old longer one, even if the agenda looks similar.

This is the part the friction pattern handles. Judging an AI integration only on the metric that AI is good at moving leaves half the evaluation undone. The other half is asking what the previous process was producing as a byproduct, and whether the byproduct mattered. If it did, the AI integration is incomplete until you have engineered something back in that produces the same byproduct, possibly through a different mechanism. The credit standards roundtable is the bank rebuilding that byproduct on a different cadence than the original committee.

The human-in-the-loop friction I run in my own work

I work as a solo operator with AI as my primary technical partner. The temptation to remove friction is constant. The friction patterns I keep coming back to look like the corporate ones above, scaled down.

The first is verification. In April I built a literature review skill for my academic work with an explicit verification loop, because a single-pass extraction had produced a confident, wrong aggregate figure on its first real use. The verification step looks like friction, and it does slow the skill down noticeably. What it replaces is a worse piece of friction: me independently double-checking the output later, possibly by repeating the original literature search. The friction in the skill is engineered to be cheaper than the friction it is preventing.

The second is the design specification before the agent runs. Most non-trivial build work I delegate to AI starts with a spec, written by me with AI help, that describes what the work is and what the success criteria are. Writing the spec is friction. It is also the artifact that lets me run the AI without holding the structural context in working memory while the work is happening. The spec absorbs the cognitive load that would otherwise be paid every minute the agent is running.

The third is a working habit. The AI I work with is configured to justify decisions and narrate as it goes. That increases the surface area of every step. It also means that when something surprising appears I see it in real time, in the narration, well before it would show up in the diff. Most production scares I have read about with agentic workflows happened because the AI moved past a decision boundary nobody noticed it crossing. Narration is the friction that makes those crossings visible.

The fourth is an explicit list of decisions I retain. The working protocol I maintain between myself and the AI assigns them. Technical calls are the model’s. Product and priority calls are mine. Architectural calls are split: the model lays out options with tradeoffs and recommends one, and I pick. Anything risky or irreversible on a production server stops until I have prepared and given an explicit go-ahead. The list itself is friction. It also means that when the model is moving fast on a class of decisions I have delegated, I do not have to be involved, and when it approaches a class of decisions I have retained, the boundary is named and the model stops and asks. The friction is in writing the protocol. It removes a much larger friction, which is having to make the boundary call in the moment, every time.

Engineered friction is different from preserved friction

Keeping the old friction wholesale would mean refusing to integrate AI, or integrating it half-heartedly, which is its own failure mode. The pattern is closer to a re-engineering. You strip the wasteful friction, the friction that was pure tax. You then build new friction back in at the points where the original friction was doing real cognitive or social work. The new friction does the same job through a different mechanism, often a more efficient one.

A credit standards roundtable that runs quarterly is a different artifact from a longer credit committee meeting. It is deliberately separated from the per-application decision flow, and it does the byproduct work the original meeting used to do as a side effect. It runs less frequently and probably costs less in total time than the embedded version. It also produces a higher-fidelity version of the byproduct because it no longer competes with the immediate decision pressure.

A verification loop in an AI skill is a shorter, more targeted check than a manual second pass over every output. It runs before the output is committed, sized to the specific failure modes the skill is prone to. It is cheaper than the manual review and catches more of what matters.

A design spec replaces the meeting where you brief a team. It is a single-pass document that absorbs the briefing once, lives in version control, and is read by the AI on every relevant session. It does the work of context-setting that briefings do, with less repetition.

In all three cases the engineered friction does the load-bearing work the original friction was doing, on a different cadence and with a different cost structure. That is the pattern. It is unobvious because it looks like reintroducing the inefficiency the AI was supposed to remove. It is the move that separates AI integrations that hold up from the ones that quietly leave the company technically advanced and structurally weaker than it started.