Designing
with Intention

A keynote on building. The title sets the thesis before the talk starts: when generation is free, intention is the only thing left to optimise for. That single line is what the next ten minutes are going to defend. The audience reads it before I say a word. By the time I open my mouth, they already know where this is going.

I want to start with a failure of mine.

Last year I built a car website called AutoScout. I posted it on Reddit. Car people were blunt. Trash. Slop. Eight features on one site, none past 80% reliable. Not good enough to be real.

The mistake wasn't that I shipped. The mistake was that I kept moving to the next feature before I understood the problem underneath. I'd been moving so fast with AI tools that I forgot to ask whether any of those features were even worth building. The shipping wasn't wrong. The not-stopping-to-think was wrong.

I keep coming back to one idea from this experience. The most valuable work is often the work nobody sees. We'll come back to that at the end. For now, just notice that the failure wasn't about speed. It was about direction.

It would be easy to write off AutoScout as my personal failure. It isn't. Pendo studied 615 software products and tracked usage over twelve months. The finding: 80% of features in the average software product are rarely or never used. Twelve percent get used frequently. Eight percent moderately. The rest — fifty-six percent rare, twenty-four percent never touched — is waste.

My eight half-built features weren't the exception. They were the rule.

This is the baseline for the whole industry. And it's the baseline before AI made shipping ten times cheaper. AI didn't cause this problem. It multiplied it. So the question isn't "what's wrong with vibe coding?" It's "what's wrong with the way we build, full stop?" Vibe coding just made it more visible.

So what's the point of building fast?

Two ideas on one slide. The first: when generation becomes cheap, craft and judgement become the only real moat. Anyone can ship now. Anyone can prompt their way to a working prototype. What survives that levelling is the part of the work that AI can't do. The judging. The choosing. The deciding what's worth keeping.

The second idea follows from the first: what's the point of building fast if it solves a problem for no one?

Speed feels like progress. But building fast with nothing to solve is just motion. Motion that looks like work. Motion that gets rewarded. Motion that produces eight features and twenty-six fetch errors.

So why do we keep doing it?

This is the slot machine in your IDE. Every AI prompt is a lever pull. You don't know what you'll get. Sometimes it's gold. Sometimes it's nothing. Sometimes it almost works. The unpredictability is the hit.

Anna Lembke at Stanford studies this. Dopamine peaks during anticipation, not consumption. The chemical your brain releases when you're chasing something is bigger than what it releases when you actually get it. The hit is in walking to the freezer, not the ice cream. The hit is in the next prompt, not the shipped product.

That's why the loop is so hard to leave. Variable rewards on a fast cadence — the same mechanic that built every casino on earth. Your brain isn't broken. It's working exactly as evolved. The wiring that kept us foraging for food now keeps us prompting.

And good output is the trap, not the win. If the output were bad, you'd stop. AI is good enough to keep you in the loop, but not good enough to make the macro decisions for you. So you stay in the micro-loop. Prompt, evaluate, prompt. Never zoom out to ask whether you should be in this casino at all.

There's another layer. Once you have one idea, you stop asking if it was the right idea. Kahneman calls it anchoring. The first idea you have becomes the bar. Every alternative gets judged against it. You ask "better than mine?" and stop asking "is mine even right?"

Cal Newport in Slow Productivity calls this pseudo-productivity: using visible activity as a proxy for real output. Knowledge work doesn't have factory-style metrics, so organisations default to measuring what they can see. Email volume. Slack activity. PRs merged. Tickets closed. Calendar density.

None of that is productivity. All of it gets treated as if it is.

Here's what AI did to this loop. It removed the human rate-limiter. Before AI, your manager could roughly tell the difference between thoughtful work and shallow work because both took time. AI made shallow work look identical to deep work on the outside. The artifacts are the same shape. A PR I thought about for three hours and a PR I generated in three minutes look the same to a manager reviewing visible output.

So pseudo-productivity now wins even harder. The whole metric system was already pointed in the wrong direction. AI just put a turbocharger on it.

Newport's answer is what he calls slow productivity: do fewer things, work at a natural pace, obsess over quality. Those three principles map almost cleanly onto what I'm about to argue for.

Before every flight you've ever taken, two pilots ran through a checklist. Fifty items. Wing flaps. Brakes. Fuel quantity. Hydraulic pressure. It takes about seven minutes. They've done it hundreds of times. They don't skip it.

They don't run it to fly slowly. They run it to land where they said they would, in a plane that works.

That's the analogy at the heart of what I want to argue for. Builders don't have a pre-flight checklist. We have post-launch regret. We ship, we hope, we find out later.

So I built a checklist for myself. Five questions. Fifteen minutes. Before I open any AI tool. I'll show you in a minute. But first, some context from the design world about what's been happening to our process.

Fifteen minutes of clarity saves fifteen hours of rework. That's the math worth holding.

Jenny Wen at Anthropic and Julie Zhuo, formerly head of design at Facebook, have both written about this. The design process is dead.

The old flow — idea, then mocks, then PRD, then code, then launch, then surprise — has stopped working in the AI era. Capabilities change weekly. Outputs are non-deterministic. You can't write a PRD for a product whose behaviour you can't predict.

The new flow leads with prototypes. Prototype, test, learn, prune. Hold many ideas loosely. Stay anchored on the problem, not on your first solution.

Julie Zhuo and Henry Modisett at Perplexity have named the three gates every prototype faces. Capability: can today's tech even do this? Accuracy: will it consistently meet user expectations? Speed: can it perform smoothly enough for real-world use? If the answer to any of these is no, the idea is pruned. You move on.

The discipline here isn't building. It's killing. The prototype is a learning vehicle, not a deliverable.

But the death of process doesn't mean you skip the problem. You still have to solve something people actually care about. The prototypes are how you find that. They're not a substitute for thinking. They're how you think.

Karri Saarinen, the co-founder of Linear, has been writing about craft in the AI era for a while now. His position: craft isn't a choice anymore. It's about being intentional about it.

His analogy is the sushi chef refining one knife for a decade. Or the furniture maker who knows wood. The skill isn't producing. It's judging, reinterpreting, and challenging what the tool gives back. The tool can do the cutting. The tool can't decide what to cut.

This is where intuition comes in. Intuition is compressed experience. It's the part of you that has watched things break enough times to know when something's about to go wrong. AI can simulate the output. It cannot simulate the years that tell you this output is wrong even when it looks right.

That's the moat. Not the speed. Not the volume. The years.

Let me show you what this looked like for me.

My mum lives in Essex. The trains run every thirty minutes on weekends and during off-peak hours. So you leave the house around the train times.

I built traintimesuk for my own commute. Wrong platforms shown. Departures that wouldn't load. API errors. I hit every one of those bugs myself, day after day, until I knew the product in my bones.

That's the discipline. Not researching the user. Being the user. Living the problem until the problem becomes obvious. Living it until you can predict where the next bug will appear before the user reports it. Living it until the gap between the idea and the actual experience closes.

You can't outsource this to AI. You have to put your own time into it. That's how the intuition compresses.

Here's what happened when I went deep.

The chart shows the train app from March to May. March: ten users, twenty-six fetch errors. A broken product barely anyone was using. By April, 848 people had found it. The cracks were showing — fifty-five fetch errors and sixty-four rage clicks in a single month. PostHog recording the exact moments users lost patience.

Growth kept coming. May brought 1,349 unique visitors, a fifty-nine percent jump. And while the error count was still high on paper, week by week the fixes were landing. By the final week of May: three errors. Zero rage clicks.

The app grew over thirteen thousand percent from launch. The bugs are down ninety-four percent.

Instead of four half-built features at 80%, I went deep on a few. Removed the bugs. Focused on craft. Two lines moving in opposite directions — visitors climbing, errors falling. That is what shipping a real product looks like.

Four moves AI can't make for you.

One: dogfood. Use your own product daily. Live every flaw. Watch session replays. The reps compound into instinct.

Two: research the problem. Not the solution. Scrape Reddit, X, LinkedIn for what people actually complain about. Go deeper with NotebookLM. Talk to real customers, not just friends. Friends will tell you it's great. Real users will tell you what's wrong.

Three: lead on taste and judgement. Learn the psychology that makes interfaces work. Hick's Law. Proximity. Cognitive load. Why social proof converts. Why a lock icon next to a payment field matters. These aren't decoration. They're the difference between a product that feels right and a product that feels off.

Four: ship in preview. Like Anthropic. Set expectations early. Learn in public. Don't pretend the early version is the final version.

AI cannot decide what to build. That is your job.

I built this for myself after AutoScout. Five questions, fifteen minutes, before any AI tool. I run it on every new project now.

Question one: what problem am I solving? One sentence a stranger could understand. For traintimesuk: show the next trains and the right platform for the stations I actually use.

Question two: who exactly is it for? Name five real people, not adjectives. Not "busy commuters." My mum in Essex. Two off-peak commuters I see on the platform. A colleague who travels for work. My flatmate.

Question three: what does success look like at the smallest scope? Don't think about the full product yet. Think about the smallest version that delivers value. One station, the next three departures, the correct platform, refreshed live.

Question four: what does good look like? What's the bar? For traintimesuk, good looks like this: loads in under a second and never shows the wrong platform.

Question five: what part can only a human decide? This is the question I keep coming back to. Which stations matter, and what 'reliable enough' feels like to an anxious commuter. AI can't decide that. That's yours.

Five questions. Fifteen minutes. Take a picture if you want. You'll want them tomorrow morning.

The Brief isn't a productivity hack. It's a pre-commitment device. The same family as a recovering gambler leaving their phone in the kitchen, or Odysseus tying himself to the mast before the sirens. You design around your neurochemistry, not against it.

One last reminder, then we're done.

There's a story about Alī ibn al-Ḥusayn, the great-grandson of the Prophet Muhammad, peace be upon him. At night he would carry sacks of flour on his back through the streets of Madinah, and deliver them to the widows and the poor.

He kept his face covered. Nobody knew it was him. He did this for years.

When he died, they noticed dark marks across his back from where the sacks had rested. And on the night he died, over a hundred households in Madinah found that no food had come. That is when the city learned what he had been doing all along.

I keep that story close because the work I've been describing tonight is the same idea at a much smaller scale.

The most valuable work is often the work nobody sees. The thinking before the prompt. The question before the build. The fifteen minutes with a blank page.

AI made the kitchen free. Stock it well, even when no one is watching.

Six reads if you want to go deeper. Karri Saarinen on quality. Julie Zhuo on the death of product development. Jenny Wen on prototype-first. Cal Newport on slow productivity. Anna Lembke on dopamine. Cory Doctorow on the slot machine analogy.

The hadith of intention from Bukhari and Nawawi grounds the close.

The rest of the source list — and there are sixty more — lives in the appendix.

This appendix names the tools behind the moment described earlier: Replit, Claude, ChatGPT, Cursor, and v0. They make it easier than ever to build, which makes choosing what to build even more important.

This appendix expands the anchoring point from the dopamine slide. Anchoring, confirmation bias, and sunk cost all make weak first ideas harder to abandon once AI has helped you generate evidence around them.