The Friction AI Removes (and Why I Keep Putting It Back)

Where this came from

I didn’t set out to write about failure modes. I’d been building real things with Claude Code - my own site, small tools, prototypes for mobile and desktop, a menubar meter that tracks my AI usage - and I kept hitting the same problems. Not random bugs: the same shape, every time.

Then a colleague sent me his notes from Designing with AI 2026, and one talk after another put a name to exactly what I’d been running into. Around the same time I was working through Limity AI, Iwo Zmyślony’s podcast series - the most clear-eyed, anti-hype examination I’ve found of what these models actually do to our work and our thinking. The two collided with my own experience, and this post is me sorting out what I learned.

Along the way I stopped only using the tool and started writing its instructions. Two of the things I now use every day are skills I wrote myself: one that routes design work through a gated process, and one that runs the writing process this post came out of.

That matters more than it sounds. When you write the rules yourself, you know what the tool is doing and why - which changes what trust means. Instead of trusting the output in general, you know the specific places to check.

Characteristics, not bugs

A bug is a defect you fix. A characteristic is a property you design around. The problems below won’t disappear with the next model release, because they aren’t defects in the tool - they are the shape of the tool. The job isn’t to avoid AI. The job is to notice what it quietly takes away from the design process, and decide deliberately what to put back.

It agrees with you

Bring a half-formed idea to a model and it will affirm it, elaborate it, and hand it back looking stronger than it is. The friction that kills weak ideas early - a colleague’s frown, a hard question in a design crit - is gone. Beth Chapell of Articulate put it better than I could:

“AI doesn’t make bad ideas more dangerous. It makes unfinished ideas look more convincing. And once they look finished, people stop questioning them.” Beth Chapell · Designing with AI 2026

What I do about it: force disagreement back into the process. Before committing to a direction I define failure criteria - what would make this wrong - and I ask for at least two genuinely different directions, then make the model argue against its own favourite. It feels slower. It is the crit I had removed.

It is confidently wrong

It invents a component API, a citation, a user flow, a rationale - fluent, plausible, wrong. In design work this is more dangerous than a rough sketch, because confident-and-wrong passes review; rough-and-honest doesn’t.

The Limity AI episode on hallucinations reframed this for me - not because of the podcast, but because of the guest. Michał P. Karpowicz is a mathematician who heads Samsung’s AI lab in Poland, and he had just published a formal proof. Iwo Zmyślony summarised the thesis back to him and asked whether he had it right:

“Complete control over hallucinations in large language models is mathematically impossible - in other words, hallucinations are a necessary, ineliminable feature of every LLM. And that ineliminability doesn’t come from temporary engineering limitations, from architecture or hardware, but from the mathematical properties of the process of aggregating and processing this data at scale.” Iwo Zmyślony, summarising Michał P. Karpowicz, “On the Fundamental Impossibility of Hallucination Control in Large Language Models” · Limity AI · translated from Polish

Karpowicz’s answer was “wonderful, that’s all correct.”

I took Stanford’s machine learning and generative AI course partly so I would stop taking claims like that on trust.

The short version of why it holds: the model produces a probability distribution over what comes next, and samples from it. Fluency and accuracy come out of the same mechanism. There is no separate internal signal marking “I know this” apart from “this sounds right.” You can push the error rate down. You cannot get a guarantee out of a process built this way.

Two more limits turned out to matter as much, once I knew to look for them.

The first is retrieval. When a model appears to know your document, it is usually being handed selected pieces of it - that is what retrieval-augmented generation does - and the selection is itself a guess. Get the selection wrong and the model answers confidently from the wrong material.

The second is the context window. A session has a finite working memory, and as it fills, the model loses its grip on what was said earlier. It does not tell you when this is happening. You just notice the answers getting worse.

That second one bothered me enough to build for it. My menubar tool began as a token-usage meter; it now also watches the context window of each session - because until you can see it, you cannot tell the difference between a model that is wrong and a model that has forgotten. Knowing where the limits sit is not the same as being afraid of the tool. It is what lets you work around them on purpose.

That shifts the target. If hallucination is a property, not a bug, then the goal isn’t “zero errors” - it’s visible uncertainty, cheap detection, and cheap reversal. What I do about it: keep facts, assumptions and hypotheses visibly separate, and treat every gap the model fills as a labelled assumption to verify - especially the load-bearing ones. Worth remembering before anyone promises stakeholders “AI that doesn’t make mistakes.”

It races to the solution

Ask for a feature, get an implementation. The framing work - what problem, for whom, what does “good” even mean here - gets skipped, because the model can produce a running answer faster than you can ask the question properly. This is the one that finally made me change how I work. Paul Bakaus said the quiet part plainly: “It is slop, because there is no intent.”

I have watched this play out in workplaces more than in my own work, and the pattern gets sharper higher up the org chart. The belief is that with very little context and very little effort you can now get a great result. It is an easy thing to believe when you only ever see the output. And it is wrong in a specific way: the model will produce something for any input, so a thin brief never fails loudly. It just returns a confident answer to a question nobody framed.

Allan Lowson’s reworked Double Diamond from the same conference names the fix: a whole first diamond for context, before anything gets built. Intent before creation - even when you’re vibe-coding. What I do about it: triage first. This is what the design skill I mentioned earlier is for - it decides how much process a task deserves before anything gets built, and for anything non-trivial the problem gets framed before any code exists. Speed at making must not become speed at deciding.

It moves the effort - it doesn’t remove it

The finding I keep coming back to is from a METR study of 16 experienced open-source developers across 246 real tasks. Before the work, they expected to be about 24% faster. After it, they still believed they had been about 20% faster. Measured, they took 19% longer.

I recognise that gap from the inside. AI gives instant gratification - code appears, the brain records progress - and the real cost surfaces later, in review, debugging, and the question of whether the thing should have been built at all.

Claire Dhoosche of Criteo asks the question I now ask of every AI step in my workflow: is it saving time across the whole workflow, or just moving the effort somewhere else?

What I do about it: read the whole pipeline, not the step; reuse the design system instead of generating from scratch; and treat “this felt faster” as a hypothesis to check, never as a result.

It erodes your judgment - slowly

The most insidious one, because it feels like progress the entire time. Lean on the model for every first draft, every layout, every argument, and the muscles you can’t outsource - taste, craft, the critical eye - quietly atrophy. Limity AI devotes a whole episode to what this does to our brains: uncritical acceptance, and competence you lose without noticing you are losing it.

For a designer this is existential, and it is worth being specific about what actually goes. Visual craft, yes - the thing you stop practising is exactly what AI is worst at, and exactly what you most need to keep. But the rest of it is quieter: the ability to lead a product process instead of following one, to make an informed decision instead of asking for one, to hold a position in a room full of people who disagree.

The tell is what happens when the tool is not there. The session breaks, or you hit a limit, and you notice you would rather wait than think.

What I do about it: I stopped relying on my own resolve here, because resolve is the exact thing this problem defeats. I built something instead.

It has three parts. Anything I find worth keeping goes into one vault, in my own words, with my own comment attached - and the comment is the part that matters, because it is exactly the thinking I would otherwise hand over. Claude files it into the structure I already use, so it is still findable months later. Then a small bot reads that vault and sends me a daily insight and a quiz over Telegram, on a spaced-repetition schedule, so a question comes back around the time I am about to lose it. The bot can only read; it can never write to my notes.

This post is a product of that, as it happens. Most of what is in it was scattered across notes I wrote months ago and had half-forgotten.

It sounds like a study toy. It is the most direct answer to this problem I have found. Deskilling happens because you stop practising, and good intentions do not make anyone practise. A timer does.

The through-line

Writing these down, I noticed they are all the same move. AI removes friction: the friction of disagreement, of being visibly wrong, of framing the problem, of seeing the whole pipeline, of practising your craft. And design quietly depends on that friction - it’s where the thinking happens.

So my answer isn’t less AI. It’s putting the friction back on purpose - intent, constraints, critique - at the points where it earns its keep.

That was my answer for months, and it worked well enough that I kept doing it. But it left a question I couldn’t answer: which friction? Every process carries ceremony - steps that survive because nobody removed them. “Put the friction back” gives you no way to tell the two apart. I noticed it every time I added a step and couldn’t say whether I was being careful or just slow.

The answer came from looking at what I had actually added, instead of at what it felt like I was adding:

• Force two directions before committing.
• Define what would make this wrong.
• Keep facts, assumptions and hypotheses visibly separate.
• Decide how much process a task deserves before starting it.
• Stop at a checkpoint and do the judging myself.

None of those are friction. Friction is what they feel like from the inside. What they are is constraints - places where I decided in advance what the tool is allowed to do, or what has to be true before the work moves on. I had been describing the sensation and mistaking it for the mechanism.

The distinction isn’t academic, because constraints come with a test and friction doesn’t:

All three have to hold. Silently, because if you would catch it anyway, you don’t need the rule. Wrongly, because if the default answer is usually fine, you are adding ceremony. Expensively, because if it is cheap to reverse, you can afford to be wrong. Ceremony is friction that fails that test. That is the line I couldn’t draw before.

Running my own five back through it turned up something I didn’t expect: two come out conditional. Confident wrongness is only expensive for the assumptions a design leans on - which is why those get verified and the rest don’t. Skipping the problem framing is only expensive for non-trivial work - which is exactly why the first step in my own process is deciding how much process the task deserves.

I had built that rule into my tools before I could say it in a sentence. Writing this is where I found out.

I’ve gone as far as encoding this into my own Claude Code skill, so my tools run an AI-assisted design process with the constraints built in, and skipping the thinking stops being the default. How that came about - including a 30,000-token manual that didn’t work, and an eval I accidentally contaminated - is a story for the next post.

What I haven’t done yet: this with other people

Everything above comes from my own projects, where I am the only person who has to agree with the rule. That is the easy version.

The harder version is a team. I’m doing some of this at work now - defining prototyping workflows, building reusable skills, connecting what comes out of the tool back to the design system. But a constraint that lives in my head is a preference. A constraint a team keeps is a process, and the distance between those two is most of the work.

What I want to avoid is the shape this usually takes: someone reads that AI makes teams faster, a tool arrives, the process bends to accommodate it, and nobody asks what got quietly removed.

That is problem three again, one level up - speed at adopting instead of speed at deciding. I don’t know yet where the right entry point is, or what the smallest version looks like when more than one person has to live with it. I would rather say that than pretend I have a playbook.

What’s still open

I don’t want this to sound more finished than it is. The test above is new: it has been through my own work, not a production codebase with a team around it, and it may not survive contact with people who didn’t invent it.

I’m also not certain the constraint framing holds all the way down. The obvious counter-argument is that some ambiguity is load-bearing - it’s where taste and context live, and a system that specifies everything produces work that obeys without landing. My current answer is that a good system doesn’t remove judgment, it marks the places where judgment is required. I hold that loosely.

And the list keeps growing as I keep building. If yours looks different from mine, I’d genuinely like to hear it.

A last note, which I only found while checking the source for this piece. Karpowicz’s newest revision of the paper reframes his own result. A hallucination, he says, is imagination operating without constraints.

I didn’t plan that symmetry, and I’m a little suspicious of how neatly it lands. But it does describe what I have been doing. The friction I kept putting back was never really friction. It was the constraint that makes imagination usable.

Wojtek from 80/20 Design