I am getting divorced and my life and my kids' life has been literally turned upside down. YNAB has given me peace over my financials. I KNOW we will be OK. I KNOW I'll still be able to be the fun-mom and have some random extras there. […] When I was worried about "can I make my payments" — I realized, yes, yes I can. I was able to treat myself to a post-divorce trip, all paid for already, because I KNOW where my money is.

Nobody types I KNOW like that about information they simply received. You write it that way when knowledge lives inside you. She had built it month by month, one spending decision, one tradeoff, and one feedback loop after another.

I’ve started referring to this sort of KNOW-ing as thick knowledge or understanding. I think the word thick surfaced from somewhere in my qualitative research training, where “thick, rich description” was the standard I was taught for writing. It’s a way of showing not just what happened but what it meant to the people having the experience. This way of reporting findings gives weight to research that isn’t captured in charts and numbers, and reinforces how much you can learn from even a single person.

But this isn’t an academic question. When it comes to an understanding which lives inside you, you can feel the thickness. It feels like something no one can take away from you.

AI could have handed Jenna correct answers, answers that might even have worked better for her at first, with a lot less friction. She would have felt informed and reassured. But she would also have been dependent. Every time her anxiety returned, she’d go back to the tool, because the reassurance she had would live in the tool. But her reassurance survived a divorce because it lived in her. She had made her own decisions and her own mistakes, and they built up to an understanding which is durable and resilient. Something she KNOWS.

thin

And then there is the other side of the coin. Some people at my company have started voicing a fear that they can feel their understanding thinning as they use AI. Not their output. Their output is fine, maybe better than ever. It’s certainly more (but that might be a separate topic). But they’re worried about their understanding. It takes courage to say that out loud, and I’ve heard it enough times, and not from AI skeptics, that I don’t think it’s a quirk of the individuals saying it.

The tempting conclusion is that AI is the problem and the fix is to stop using it. It’s the premise of a lot of the “cognitive rot” warnings making the rounds. This isn’t that essay. Thinness of knowledge or understanding isn’t a property of a tool at all, and isn’t the inevitable result of using one.

Thick and thin understanding existed long before LLMs became ubiquitous. I am describing a property of our own understanding, and it’s determined by how we receive what a tool, or another person, gives us.

But AI, of course, is changing how all of this feels. Because the answers we get from AI, right off the bat with almost no effort, are seductively good. It’s so tempting to think, I can’t do much better than that, and to walk away. But when we just accept answers, we’re not building the knowledge in ourselves, and it stays thin. And there is real risk in holding thin understanding. Before we explore that risk, I want to reiterate that the answer isn’t to drop these tools entirely. It’s to be skeptical and to push back when we do use them.

being wrong faster

I believe in AI for automating the repeated and the predictable. It also plainly lets us produce more, more quickly. True and true. But produce what, and to what end? Fast without judgment can quickly become slop with good throughput. We want to be right.

At the same time, we have a phrase at YNAB we’ve been leaning on for two years: be wrong faster. Not to be wrong in the end, but to get the idea out, get it in front of real people in real life, find out what’s wrong about the idea or the execution, and adjust.

And AI is an incredible be-wrong-faster machine.

What excites me is that we can vet more ideas than we ever could before. Being wrong faster comes from producing lots of ideas and being able to put them in front of real people. What used to take a week testing a variation in our software can take a day, and we can really shorten the feedback loops to our next iteration. We find all the things wrong with idea faster, so we can get to the right ideas faster. It compounds.

Of course, being wrong faster only works if you can tell when you’re wrong.

And it is thick knowledge that lets us do this. In our case, thick knowledge of crafts, our product, our customers, and the real world they exist in. Sometimes we think of this thick knowledge as intuition, judgment, or discernment. Sometimes we even discount it because we worry it isn’t grounded in facts. But combined with a healthy skepticism, it’s what helps us sort through everything AI tools enable.

Which brings us back to the risk of thin understanding. You aren’t just giving up the satisfaction of a thick understanding. And it’s not an abstract risk about AI doing things we might wish only humans could do. A thin understanding will inevitably catch up to you and your organization, too.

You might not notice at first, because your thin understanding can look like or work like thick knowledge at first. You accept an answer without pulling on its rough edges (and not for nothing, these tools are designed to make edges feel smooth), and your understanding gets thinner. You’re less likely to notice the loose ends next time, so you don’t pull, and it gets thinner still. Then you hand your work to someone else, who assumes they’re receiving something thick, and doesn’t look too hard either. It all gets thinner and thinner and thinner. Until conditions change or just the weight of building thin on top of thin means it all collapses and you aren’t sure where you went wrong.1

I don’t have a first-hand story of this going dramatically wrong. Yet. But I’ve seen the seeds: an output accepted uncritically, or a claim with not much behind it. More often, I’m hearing people searching for words to describe their experience. In the most dangerous form, they’re wondering at what point this all means losing trust in their own and each other’s work. That seems worth saying in public, not just in an internal memo. And it seems worth sharing ways we can prevent it from happening.

arguing

A lot of my AI use happens walking around my office, arguing. Pulling on a thread in the moment a question arises, which is exactly the kind of thing AI makes accessible. I’ll ask the model why an assertion is true. I’ll ask for a counterexample. I’ll point out where I think it’s being lazy, or where my experience seems different than the language it is using. The arguing is important, and I think the walking is too.2 It keeps me from sitting at my desk and running with the first output.

And because AI does make it possible to arrive at an answer more quickly, I’m also trying to set aside my conclusions, even after I return to my desk. It feels almost counterintuitive sometimes. Why not just stay focused on this one thing and get it done? Why break up my flow when I don’t have to? But what’s happening is that I’m still processing the problem or the conversation, and when I come back to it, I have more questions to work through. Asking these questions make the understanding mine. They make it thick.

rejection rate

In all this arguing, I’m using AI a lot more, consuming more outputs, but throwing away a higher proportion of them than I used to. I want to keep it that way, because a person with thin understanding can’t reject an AI’s answer. They have no ground to stand on, so everything looks fine.

Now, I don’t want to throw away good solutions out of some sort of spite. But I’ve started encouraging people to notice this ratio: if your use is climbing and your rejection rate — or at least your substantive-revision rate — is falling, you might think that is because the tool is getting better. But it may actually be you accepting more without critique, and that’s going to leave your understanding thinner.

thick

Sometimes, thin is okay. When you need a simple answer to a rote question, take the answer and walk away.

But when you’re building an understanding that needs to be durable, one you will build on top of, or especially one you will hand to other people, don’t abstain. Instead, use the tools hard. They won’t be offended. Be skeptical. Argue. Ask what could be wrong about this beautiful-sounding answer you received. Pay attention if you notice yourself accepting more and rejecting less.

If the tool disappeared tomorrow, could you, perhaps with the help of a trusted sounding board, think your way through the answer, write the doc, explain the code, answer the earnest question, or make the decision? Our customer could. Her certainty isn’t stored in an app or a model. It’s stored in her, in experience layered over experience, thickness over thickness. It takes time, but it is worth building.

What thick understanding do you have about your work or craft you want to protect?

a room with no decisions

The most liberating thing I’ve ever experienced is a room where I didn’t make any decisions. A room where I couldn’t make any decisions. Where I was completely constrained in my choices.

Sitting for retreat in a zen temple means being awoken well before dawn. It means a morning tea you don’t select. It means going to speak with the teacher when you are invited, not when you would like, and the meeting ends when the teacher decides. It’s being corrected on how to breathe and hold your hands. It is being directed on the angle your chopsticks sit at next to your bowl. And it is, period after period, hour after hour, day after day, sitting down at the sound of the bell and remaining motionless until the bell rings again.

As a senior student, I used to greet new visitors arriving at the temple. They would often tell me they were there because they wanted to feel calmer, or to stop their racing minds. I would tell them: You may or may not, but this is what I do know. We spend all of our time responding to our impulses. We don’t even notice. We have a thought, we follow it. We have an itch, we scratch it. You’re here to find out what happens when you stop doing that, even for an hour.

That is what constraint offers. Not a promised outcome, but the conditions for something to emerge that can’t emerge if you’re busy deciding what to do next.

In the temple, the form, the manner, the time, and the rules of everything are determined for you. This is actually why it works. It is the opposite of bespoke.

the bespoke promise

Here is the promise being made to all of us in the age of bespoke AI: There will be no more need to rely upon others or tools made by others. We can all build our own tools, and the bespoke tool promises perfection. It will be exactly what you want, tailored to you, and endlessly refine-able. What a relief to not have to convince the maker of the tool to change it, or to have to bend your own desires to the form of an existing tool. And all of it will be easy.

But the bespoke promise is a trap. When it is everywhere, we will be worse for it, not better.

open loops everywhere

I was listening to a podcast the other day, and the conversation was all AI early-adopters energy. At first the energy was exciting. But the more I listened, the more it sounded like they couldn’t spend enough time. Not because of pressure to produce, but because they were just being drawn in further and further. I hear sharp, inquisitive people, but I also hear people who increasingly sound like they can’t put it all down, even if they want to.

It’s not surprising when I step back, though. Because endless refining actually does not lead to perfection, relief, or satisfaction, it leads to more refining. It hoards our attention, and our attention is finite. I’d say it is precious. In the end, the promise of self-made, bespoke tools will actually deliver something else:

Open loops everywhere.

I listened to a friend talking about the fitness tool he built. He was excited, but also wasn’t hearing the irritation in his own voice as he described the GitHub commits and debugging he was doing. He had spent a whole weekend refining the tool, instead of doing the thing the tool was going to help him with: going outside and getting fit.

I can hear the counter-argument: this too will go away, as agents get better and better at smoothing this process. But this will make it worse, not better. Agents getting better doesn't close open loops. It just makes them less visible, which means we open more of them, at the same time as we stop noticing their insistence.

It’s like the question, Is this the way you want it? being asked of you over and over and over.

inversions

And here is where it gets dizzying for me. Bespoke tools are promising continuous improvement and optionality in ways that feel like a trap. But these are two concepts I haven’t simply agreed with, I’ve evangelized. I’ve built my career on them.

Fun case in point: I own the URL unfinishedproduct.com. I bought it years and years ago. I didn’t know what I would do with it, and still didn’t when someone offered me a silly sum of money for it. I refused, and in keeping with the spirit of optionality, it remains unfinished. I bought it and held it because I believed so much in a core product ethic: a relentless, joyful refinement to deliver an ever better expression of a point of view, an ever-better user experience. Ideas work this way, too; the ones in these essays are unfinished products. All of it still sounds right as I type it.

I’ve held optionality close to my heart even longer. The idea that you shouldn’t close loops early, that there is real value in keeping them open. It’s a humble idea. You can’t see the future, so wait until your hand is forced. You’ll know more then.

But does this hold up with the option to change the tools you use, each moment and endlessly? We know what happens when humans get unlimited optionality. We’ve already run this experiment with smartphones, and nobody won. And AI is taking the idea of unfinished to a new place, a place where you are elevated to the arbiter of when something is finished. This sounds like a promotion, but it is not.

Which brings me to the most dizzying inversion of all. Tinkering. I love nothing more than a new set of Legos. My family doesn’t need to ask me what I want for holiday gifts. But tinkering isn’t just about toys. Professionally, the software I love and build every day is tinkering-as-mastery at its core. The most amazing software is designed for play, engagement, and storytelling. But the promise of bespoke tools hijacks our beautiful tinkering impulse, and moves it from the activity at hand to the tool itself.

Suddenly, you are the product manager of all your life’s tools. It’s a job you never applied for and never wanted, but you’ve been convinced to take it on.

I don’t feel like I can discard these ideas I’ve built so much on. But I’m also not sure how to reconcile them.

just a user?

And still the promises keep coming: AI will make everyone a co-developer, and the future is bright because everyone can be a creator. There is a way in which this is an appealing, beautiful idea. I couldn’t be more excited about freeing interesting ideas which have been blocked by long timelines, short investments, or just an inability to code.

But this idea is not completely honest, because it sets up a sort of false binary. It implies that to be a user of someone else’s product is to be just a user, and the word just is cutting. It says we’ve been living in some less-than paradigm, a paradigm which bespoke, custom tools will finally free us from.

But “just a user” is an invitation.

Taken too far, and it’s so easy to do, the co-developer frame smuggles in responsibility disguised as agency. Now you’re not just seeking to master the activity the tool was designed for, you’re accountable for the tool itself. You’ve doubled your cognitive load and been told it is freeing.

Developer-made tools, especially single-purpose software, mean you can let go of all this. Yes, it means a tool which might feel imperfect. Yes, it means accepting friction, in the structure and experience of the tool. But this is the point. With developer-made software, someone else collected and sharpened the domain knowledge to make the tradeoffs, and passes on trust to the user. Someone engaged their craft to build, iterate, and refine a bounded space, where the loops are closed. Of course, not irrevocably if they are product people who believe in bringing their point of view to life. But that is their work.

showing up

Sitting zazen in a modern temple, you experience forms which have existed for thousands of years. On your own, you’d choose few of them and probably sustain none of them. This is why people struggle to meditate on their own. But these forms have been refined subtly, but with great humility, through the craft of people who dedicated their lives to it. And each one is a closed loop. They serve us well because of this.

No software has thousands of years behind it. But perhaps it is also true that no software should set us up to spend all our time responding to open loops.

Because what happens when we stop?

You get to show up and do the thing you came to do, not manage the tool, and not wonder if it could be better. And not respond to the impulse to refine. Just a user, with just the activity itself, with your full attention, in a space designed for it.

Is there an experience you value, for just the activity itself, with your full attention, in a space designed for it?

Friction.

The authors’ idea is that modern companies, particularly software companies, have monetized friction. That core business models are premised on taking advantage of consumers’ inability or unwillingness to perform certain tasks. Writing from an imagined vantage point two years in the future, they describe this model and the impact AI agents have had on it:

Over the past fifty years, the U.S. economy built a giant rent-extraction layer on top of human limitations: things take time, patience runs out, brand familiarity substitutes for diligence, and most people are willing to accept a bad price to avoid more clicks. Trillions of dollars of enterprise value depended on those constraints persisting.

It started out simple enough. Agents removed friction.

Setting aside for now the provocative “rent-extraction layer,” the structural element of this feels like a given. After all, for thousands of years, well before software, people have compensated each other for intermediation: performing tasks which they could not perform or did not want to take the time to perform. In an agentic world, when everyone can produce things which were once specialized, and the time required falls near zero, with tasks running simultaneously and in the background, you remove a whole lot of friction.

What happens next in this imagined scenario? Habitual usage patterns change, and change rapidly. The reason for certain tools and services to even exist, their moats which protected their continued existence, disappear. Or, as the author concludes:

Their moats were made of friction. And friction was going to zero.

It all feels plausible. But this view of friction is based almost entirely on friction in its most negative manifestation. As something in our way. As something to optimize away.

in praise of friction

I am here in praise of friction.

Not the wide-ranging, rent-extracting, pervasive friction-as-business-model described by the Citrini report. And not to praise it as a cover for poor design or lazy execution in software. Instead, as a choice we as humans might make to protect our engagement in important activities, and protect capacities which actually make us human.

A friction which, far from rendering people dependent, actually protects our independence.

a premise

I’m going to speak from a strongly-held opinion. Namely, there are certain human abilities which are worth protecting, even in a world where a superhuman intelligence could execute for us instead. I believe this from both a utilitarian perspective (let’s not be so quick to jettison remarkable abilities we’ve acquired over human history in case we need them) and from a philosophical one (there are simply experiences of being which make our lives worth living). Maybe you agree with either or both.

Something which feels particularly under threat to me is our ability to slow down. To have patience for sustained, effortful contact that builds genuine understanding. To tolerate deliberation and even temporary not-knowing. And to recognize the ways we express ourselves in the world and retain agency over those activities.

Why wouldn’t we retain those things? Because often, we can’t help ourselves.

You don’t have to be a pessimist about human nature to acknowledge we have failure modes where we don’t always act in our own best interests. And getting to genuine understanding almost always involves frustration. Not-knowing is hard. Deliberation is slow. Meanwhile, new AI capabilities offer us escape hatches. The temptation to get an immediate answer or delegate the need for deliberation is only a few keystrokes away. The same abilities AI gives us don’t just enable speed, they are a threat to any effort to slow down.

an antidote

The antidote is not complicated. It is to practice these skills. But not-complicated doesn’t mean easy. Humans aren’t very good at resisting these temptations. We are inclined to avoid struggle. We are inclined to delegate.

So we should put something in our own way. Not something to impede all progress. Perhaps something to simply slow us down.

A bit of friction.

precommitment

What I am describing is the lesson Ulysses taught us. On his way home after the Trojan War, Ulysses is warned by Circe he will not be able to resist the singing of the Sirens as he passes their island. So he plugged his crew’s ears with wax, and tied himself to the mast of his ship. He rendered himself physically incapable of doing anything.

It was a serious bit of friction. And it saved his life.

Philosopher Jon Elster labeled this as precommitment, or in a nod to Ulysses, self-binding. Essentially, Elster’s premise is we are very prone to making situationally rational decisions which work against our equally rational larger goals, even when we are perfectly aware of the consequences.

Think: It’s rational for me to delegate a task at hand to an AI agent, even though I value the capacity to do it on my own, because speed. It’s a lucid decision. An irresistible, lucid decision. One you can’t help making even when you know the skill you just delegated also just atrophied.

Friction can save us.

chosen frictions

I have spent a good portion of my career championing the removal of friction in software. But what does intentional friction, friction we might remove and later wish we hadn’t, actually look like?

When it comes to single-purpose software in particular, three types of well-designed friction–what I think of as structural, activity, and editorial friction–act as precommitments which create delightful experiences and protect important capacities. In the right contexts, we should continue to choose these frictions, not remove them.

Structural friction is a sort of context-switching which serves you, not impedes you. When we build single-purpose software, we are inherently valuing friction which comes from separating our product experience from other experiences. There is a burden on us, as developers, to keep offering spaces like this. Of course, the user must join the precommitment by choosing to use a space like this. To thread a non-software analogy, structural friction is like providing, and choosing, a co-working space rather than working from home, where mixing contexts inevitably gets in our way. Getting there requires effort, day after day. But the structure, the friction, grounds us.

Activity friction is a set of experiences inside that structure, ones designed to foster engagement rather than delegation. This doesn’t mean all the activities are hard; it means they are specifically chosen and provide a sense of continuity. And in another act of mutual precommitment, the user knows they cannot change these activities. They are binding themselves to the choices of the developer, at first on faith and then on trust built over time. In the co-working analogy, this is every design decision which focuses you on the work at hand rather than taking it away from you. The surfaces, the seating, the lighting, shared spaces and spaces for separating yourself. You accept them all as precommitments, knowing they exist to facilitate the purpose of the space.

Editorial friction is a developer’s precommitment to a strongly held point of view, and to actually using that point of view to make decisions. This is the presence1 of a coffee service in our co-working space, designed to remove an unhelpful friction, but the absence of a gym because it will only lead to procrastination. Editorial friction means resisting enormous pressure in order to protect the space and the engagement described above. It is not friction chosen to hold customers captive, but to protect the software’s soul, often against the exhortations of others, human or otherwise.

places of conviction

The Citrini report is pitched two years into the future. When that time arrives, I want to inhabit a world where the spaces I am describing still exist. Where, in fact, they are even more robust and zealously guarded. Which means we must continue to design and build them. Not as competitive moats, but as places of conviction, where we allow users to slow down. To engage and deliberate. Or simply enjoy an uninterrupted moment of delight.

What is an intentional friction in a tool you use–or build–which you would choose, and choose again?

My life and my work is legitimately getting better using AI. But I also feel myself disappearing into an abyss. What it means to be myself or human feels like it’s slipping away. I have to be a lot more intentional to feel like I have a grasp on it.

I’ve been hearing versions of this everywhere. Not from luddites, but from practitioners. Something is getting better. And something is being lost. Perhaps worse, something is being given away.

In 2017, I wrote down a few lines from a Josh Brewer talk in my commonplace book:

As product people we are responsible. We are responsible for the decisions that we make. We are responsible for the ramifications of those decisions. But it does not get talked about very often, if ever. The behaviors that we are creating and promoting and the things that we put in front of people and incentivize them to use and the long-term consequences rarely ever get brought up in meetings, rarely ever get factored in when product roadmaps are being created, and there certainly isn’t time baked in anywhere to stop and reflect.

I’ve been really feeling this recently. Josh Brewer was talking about smartphones, which makes his concern seem almost quaint now. This isn’t just about how people spend their screen time anymore. It’s about which capacities of ours, as humans, get exercised and which ones fall away because we delegate them over and over.

At what point does delegation become self-erasure?

The AI moment is presenting what amounts to a total delegation offer.

For much of it, you should accept the offer. AI agents will handle things like scheduling, inbox triage, and all the logistics which I find relentless. I’m looking forward to it! But there are categories of human activity where delegation doesn’t simply save time and tedium.

It costs you something of yourself.

The harm feels like a benefit at first. You hand something off and feel a real sense of relief. But at what point have you optimized yourself out of your own life? Without even realizing that you’ve done it?

What’s worth protecting

AI can tell us we could do something. Only we can decide if we should. What should we protect, in our own lives, and in what we build for others?

mastery

I began my career as an educator, not writing code, and this is the thing I am certain of: developing mastery requires effort and intention. It isn’t easy. But human beings are learning creatures, and sometimes the effort is the point. The struggle is not an obstacle to a good life. It is a good life.

Mastery isn’t only about capability or self-reliance. It isn’t only about what you can do. Making an effort towards mastery teaches you about yourself. It teaches you, or maybe helps you discover, what you value, what actually matters to you. When you delegate away effort, you don’t just lose the skill, you lose the self-knowledge that came with it.

It’s a core premise of most software tools that we’re trying to make something better for the user, often by making something simpler. We should keep doing that. But when we promise to remove struggle, we should also ask if we removing the productive kind. Are we taking away the effort that builds something in the person using our product? If the answer is yes, simplicity may not be the only result. We may be making people less capable and less self-aware.

human connection

An emphasis on human connection may seem misplaced when we’re talking about building digital tools, or it may seem like the argument is that every tool should be a community tool. But I am thinking of what sort of connection comes through in products when they are designed and built by humans and human decision-making.

Software should be designed and built by people who have faced the same problems its users are facing. This brings human empathy into the experience of using the product in a way AI cannot, because AI hasn’t lived the same problems, hasn’t faced the same decisions, hasn’t negotiated the same emotions. This isn’t something that waiting for a future, more advanced AI model will solve. It’s impossible; the AI will only ever be able to simulate. It’s impossible.

This empathy from a builder isn’t just about hard things. It’s about their passion and joy and interest, which I believe become part of the foundation of a product. Perhaps you can’t point to one specific or explicit thing in any product that shows this, but it is there. This isn’t some sort of wistful nostalgia. You feel the difference between a tool made by someone who deeply loves the thing you’re using it for, and a tool that is generically competent. That difference is worth protecting.

attention

Our human attention is finite. (If yours is not, let’s talk, I’d love to hear more.) Important activities deserve full presence, not a fraction of it. But the advent of AI presents the possibility that one tool, maybe one agent, can do everything for you, all at once, and making it feel easy. But when we take an activity and just make it a part of the stream of everything we do, we’re telling the user, by design, that the activity isn’t special. Maybe sometimes that is the right call. But some things should be special, and delagating them away is erasure.

What follows

This is not an argument against AI. It’s an argument for discernment in where we apply it and what we build with it. The solution is not to expunge these new capabilities. It’s to be deliberate about what they touch.

For those of us who build tools: we are deciding right now, every founder, every platform, every product team, what kind of relationship humans will have with the most important activities in their lives. What behaviors we create, what we incentivize, what we make easy to give away. I fear we aren’t actually deciding. We’re just stumbling into what is next.

The tools that resist this share a common shape. They’re single-purpose software.

Single-purpose software creates a bounded space where focused attention is possible and decisions are essential. It is built by people who understand and love a specific domain. It supports mastery rather than removing it. It carries human connection into the product itself, both the empathy of shared experience and the craft of genuine passion.

Single-purpose software is not for everything, but for the five things instead of the fifty. Single-purpose software may or may not use AI. That’s not the point. It is for the activities where the effort is the point, where your presence matters, where you are becoming someone or expressing yourself as someone through the act of doing. These tools are humble in a way. Single-purpose software says: I’m not going to take this from you, but I’m going to be the best possible place for you to do it well.

I believe single-purpose software is what tools look like when they’re designed to protect what matters in human experience rather than optimize it away. It’s what saves you from accidentally giving away something you wish you hadn’t.

The offer

The total delegation offer is real, and it’s coming for everything. Be optimistic and accept a lot of it. But be skeptical and decide what you’re protecting. The question we should be asking as makers, as people, is whether what we’re building leaves room for mastery, connection, and attention.

AI is already extraordinary at many things. But that makes it more important, not less, to develop tools which protect the things it can’t replace. We should build on that conviction.