A bat and a ball cost $1.10 together. The bat costs a dollar more than the ball. How much does the ball cost? Most people hear "ten cents" before they've decided to think about it, and the answer arrives with a pleasant feeling of being right. It's wrong. The ball costs five cents, which takes a few seconds to check once something makes you bother.
Daniel Kahneman made puzzles like this famous to show two modes of thinking. System 1 is fast and automatic: it reads a face, finishes a familiar sentence and offers ten cents without being asked. System 2 is the slow, effortful one you need for 17 × 24 or for following an argument step by step. Kahneman's point was that System 2 is lazy. Most of the time it signs off on whatever System 1 suggests, because checking is work.
Agents have handed every designer a second System 1, and it is very good at producing answers that feel finished. Our own System 2 is as lazy as it ever was. And design systems, which store slow decisions so nobody has to make them twice, have become the most important context these new fast thinkers get.
Making used to buy time for thinking
Before agents, a designer's day braided the two systems together. Craft ran on System 1: an experienced designer sees that a layout is off before they can say why and nudges spacing by feel. System 2 took the framing, the research synthesis, the flows and the trade-offs.
The slowness of making did something useful in between. Drawing the twelfth screen of a flow by hand, you'd notice there was no way back from step four. Building the empty state, you'd realize the copy assumed the user already had data. All those hours of production kept waking System 2 up with small surprises.
Agents take most of that labour away. It's a real gain, and I don't want the old way back. But the surprises left along with the labour, and nothing replaces them automatically.
Agents are System 1 without the surprise
A language model completes patterns: given some context, it produces the most plausible continuation, fluently, and it's as sharp at four in the afternoon as at nine in the morning. That's a fair description of System 1, and several of Kahneman's observations about it fit agents uncomfortably well.
Take what he called WYSIATI: what you see is all there is. System 1 builds the most coherent story it can from what's in front of it and doesn't ask what's missing, and an agent does the same with its context. If your design system isn't in that context, it builds from the average of everything it was trained on and rarely mentions that it's guessing. Human System 1 at least feels a jolt when something doesn't fit, whereas an agent tends to fill the gap smoothly and carry on.
Polish triggers what Kahneman called cognitive ease: things that are easy to process feel familiar, true and good, and that feeling relaxes System 2. Agent output is polished by default. A high-fidelity mock used to show that someone had spent days on it, and our System 1 still reads it that way, although fidelity now costs nothing. Bill Buxton argued that a sketch's roughness tells people the idea is still open, and agents rarely hand us anything rough.
Then there's substitution. Faced with a hard question, System 1 quietly answers an easier one. "Does this flow solve the user's problem?" is hard. "Does this look right?" is easy, and a polished screen answers it convincingly. Anchoring follows close behind: the first option an agent generates frames everything after it, and a morning of iteration can turn out to have been a morning of refining the model's first guess.
These effects would matter less if our own System 2 checked everything, but by the thirtieth review of the day the lazy controller, as Kahneman called it, is waving ten-cent answers through. Model makers now ship "thinking" modes that help with reasoning inside the frame you give them, but they still don't know your users, or why the team decided against a pattern last spring.
| Kahneman's idea | With agents in the loop | What helps |
|---|---|---|
| What you see is all there is | The agent builds from its context, and the reviewer judges only what's on screen | Put the system in the agent's context, with empty, error and loading states in every component's definition |
| Cognitive ease | Polished output feels considered whether or not anyone considered it | A low-fidelity review theme, so flows get judged without the polish |
| Substitution | "Does it look right?" stands in for "does it solve the problem?" | Reviews that open with the problem and the success measure, then the screens |
| Anchoring | The first generated option frames everything after it | Write down your intent before prompting, and ask for several directions at once |
| The lazy controller | By late afternoon, review turns into a rubber stamp | Automate everything with a right answer: tokens, contrast, accessibility, visual regressions |
| Valid intuition needs a regular world | Agents do well on common patterns and badly on your product's own flows | Document domain patterns so they're regular for agents too, and flag anything off-system |
A design system is slow thinking, saved
Design systems were built for this problem long before agents arrived. Somebody spent a week deciding how a disabled button behaves, or when a dialog is the wrong choice, and the component carries that decision to everyone who comes after. A product team moving fast inside a good system is using slow thinking that someone else already did.
That's why defaults matter so much. A default is the answer System 1 picks when nobody stops to think, which is most of the time, and agents pick defaults too, faster and more literally than any person. A good default in the system becomes a good default in a thousand generated screens, and a missing one gets filled in from the model's training data.
Kahneman and the psychologist Gary Klein argued for years about when expert intuition can be trusted, and ended up agreeing on two conditions. The environment has to be regular enough to learn, and the person needs plenty of practice with quick, clear feedback. A design system is largely a machine for making a product regular, with the same patterns and names everywhere. The more regular your product is, the more often fast judgment turns out right, whether it comes from a senior designer or an agent.
The system also has to supply the surprise that people mostly bring themselves. Agents don't reliably notice when something doesn't fit, so the system has to create that moment: tell agents to stop and say so when no component fits, instead of inventing one, and flag raw color values and unknown components in review. Each flag marks a place where the system has no answer yet: a request for slow thinking.
The same pattern at product scale
Product teams have their own version of this. Shipping experiments, reading dashboards and adjusting is the organization's System 1, fast and usually right about small things, while deciding what the product is for, and what it won't do, is System 2. Agents make experiments nearly free, which makes substitution easy at product level: a steady supply of answers to "which variant won?" can feel a lot like an answer to "should we build this at all?"
Teams used to think that second question through in the gaps while engineers were busy. When building takes an afternoon, it needs its own slot in the calendar. A design system helps by covering the common ground, so product conversations can spend their slow thinking on open questions instead of button styles.
Slow on purpose
If agents take over most of the making, a designer's work concentrates at the two ends that stay slow: framing at the front, judging at the back. Neither end got easier, but the middle got fast enough to make skipping both tempting.
- System 2 · youFrameThe problem, the person, and what you'll trade away
- System 1 · agentsMakeScreens, variants and code, as fast as you can review them
- System 2 · youJudgeWhat's missing, and whether it solves the problem
At the front, I'd write before prompting. Noise, Kahneman's 2021 book with Olivier Sibony and Cass Sunstein, recommends forming your own judgment before you see anyone else's, and an agent's first draft counts as someone else's. A paragraph of intent and a rough sketch, made before the model shows you anything, keep its answer from becoming your anchor. Then ask for several deliberately different directions, so no single one sets the frame.
At the back, take the polish away while you judge structure. If your tokens are semantic, a grayscale wireframe theme is cheap to build, and reviewing a flow in it strips out most of the cognitive ease. For flows that matter, run a premortem, the Gary Klein technique Kahneman recommended: assume the feature failed six months after launch and write down why. It takes a few minutes and tends to surface missing states faster than admiring the happy path.
In between, automate every check that has a right answer, such as contrast, token usage, accessibility rules and visual regressions, so that System 2's attention goes to the questions that don't have one. When a judgment settles something new, save it into the system as a component, a pattern or a rule the agents read, so people and agents can both answer it quickly next time.
The lesson of the bat and the ball was never to stop using System 1, which handles almost everything well. The skill is noticing which questions deserve a second look. I'm less sure how designers will build that skill when so much of the making happens somewhere else, since practice with feedback was half of what made intuition trustworthy.
What I am sure of is that we now work next to the fastest System 1 anyone has built. Saving our slow decisions in the design system makes its fast answers right more often, and the rest of the job is knowing when to stop and check the ball.