Tell the Machine a Better Story

For about two years I've built with AI across the whole range — quick throwaway prototypes, real production products, client work with deadlines and consequences. And for most of that time my stack kept changing underneath me. Every week there was a new plugin, a new MCP, a new agent framework, a new "this changes everything" tool. I tried a lot of them. My setup swung from maximalist — wild integrations stacked on integrations — to deliberately minimal.

Most of those tools shared a quiet assumption: that the way to get a better result was to throw more machinery at it. More tokens to design something. More tokens to verify it. More agents arguing with each other. It was fine. It worked, technically. But over the long run I kept landing in the same place — not quite satisfied with the result, and more importantly, neither were my clients.

So I changed the order of operations. Not the tools. The order.

The Part AI Replaced, and the Part It Didn't

Let me be clear up front, because this is the easiest thing to get wrong: I am not an AI skeptic. The opposite. If "building" means actualizing — turning a clear intention into working software — then hand it to AI by all means. I delegate almost all of my implementation now, and I've written before about why I think coding was never the job and why someone still has to architect the system.

But there's a layer above architecture that gets almost no attention, and it's the one that decides whether the thing is worth building at all.

The four skills I keep coming back to — the ones I'd tell anyone building with AI to invest in — aren't framework skills. They're thinking, imagination, storytelling, and writing. They sound soft. They are, in fact, the hardest part, and the part that doesn't get cheaper when the model gets better. If anything it gets more valuable, because the cost of building the wrong thing has collapsed — and the wrong thing here isn't a wrong architecture, it's a wrong idea, decided before a line of code exists. When implementation was slow, a bad idea cost you a quarter. Now it gets built beautifully, in an afternoon, and you don't notice it was the wrong thing until it's in front of users.

Thinking and Imagination Come First — Away From the Keyboard

The change that actually moved my results had nothing to do with prompts. It was giving the early stage time.

Before I open any tool, I sit with the problem. I try to understand the user and what actually hurts for them — not the feature they asked for, the ache underneath it. Then I do the thing I think most people skip: I imagine. I picture a specific person struggling with the specific problem. I run their day in my head. Where are they when this comes up? What did they just finish doing? What are they dreading next? What would make them exhale?

Imagination is the design surface. Everything downstream is just rendering it.

I do this on purpose on surfaces that have no technology in them. I think on paper — a reMarkable, long walks, the deliberate boredom of not reaching for a tool. There's a reason for this beyond preciousness: the moment a tool is in front of me, it starts answering questions I haven't finished asking. It narrows the imagining before the imagining is done. So I keep the early stage analog, and then — and only then — I bring AI in to brainstorm against what I've already imagined. The AI is a fantastic thinking partner once you have something for it to push on. It's a poor substitute for having the thought in the first place.

Then I sleep on it. I let it sit. I go for a walk and try to watch the imagined user use the imagined thing. This sounds slow. It is the cheapest time in the entire project. I've made the same argument from a different angle in first ideas feel right — that's the problem: the first solution that arrives feels like clarity, and that feeling is exactly when you should wait.

Storytelling Is How You Transmit the Imagining

Here's the part that took me longest to learn, and it's the bridge between the two halves: you did a great job imagining in your head — now you have to get it out of your head and into the machine. The line Karpathy made famous — that "the hottest new programming language is English" — gets quoted a lot, usually as a joke about prompts. I think it's literally true, and it raises the stakes on a skill most engineers spent a career avoiding: the discipline that transmits an idea best is the oldest one we have. Writing. Storytelling.

Not "prompt engineering." Writing. Structure, sequence, cause and effect. A beginning that sets the stakes, a middle where a real person hits a real wall, an end where the wall is gone. When I hand an AI a clean narrative of who this is for and what their day looks like and what changes for them, the output is in a different league than when I hand it a bullet list of features. The features were never the thing. The story is the thing; the features are what fall out of it.

There's a second, quieter reason storytelling matters more than it looks, and it's about you, not the machine:

This is why I trust a good story more than I trust a spec document. A spec can be complete and still be incoherent — a hundred true statements that don't add up to a thing anyone would use. A story can't hide that. The moment the narrative skips a beat, you've found the place your thinking skipped a beat. A coherent story doesn't prove you're right — fiction is proof enough that consistency isn't truth — but an incoherent one is a guarantee you've left a gap, and that's the cheaper error to catch early. Leslie Lamport — the computer scientist behind TLA+ — puts it more bluntly than I would: if you're thinking without writing, you only think you're thinking. Writing is not how I record the idea after I've had it. Writing is how I find out whether I actually had one.

None of this is new, which is the reassuring part. Amazon institutionalized exactly this years before LLMs: their "working backwards" method makes a team write the press release and FAQ for the finished product — the customer's story, in full sentences — before anyone is allowed to build it. Jeff Bezos famously banned PowerPoint from senior meetings in favour of six-page written narratives — for the same reason I keep coming back to. You can fake a coherent slide. You cannot fake a coherent paragraph. The narrative forces the thinking the bullets let you skip. An AI builder just makes the payoff faster: the clearer the story going in, the closer the first build lands.

So Can't AI Just Do All of It?

Plenty of people insist the whole loop — idea to shipped product — can be done end to end by AI now. Maybe it can for someone. I haven't been able to, and I've genuinely tried.

What I keep running into is that the model is brilliant at the middle of the loop and weak at the ends. Hand it a clear, well-imagined, well-told problem and it will build faster and often better than I would have. Hand it the vague version — the version where I outsourced the imagining too — and it produces something plausible, confident, and subtly wrong, and I lose more time untangling it than I'd have spent thinking first.

The careful research lands in a similar place, with a useful sting. A 2025 randomized trial from METR put experienced developers on mature codebases they knew well and found they were about 19% slower with AI tools — while believing they'd been roughly 20% faster. I'd be careful not to over-read it: that's a narrow setting, the case where AI helps least, and it says little about juniors or greenfield work. But the perception gap is the part that stuck with me. The leverage is real; it's just leverage on your clarity, and it multiplies a zero as happily as it multiplies a one. Speed feels like progress even when it isn't, which is exactly why the slow, unglamorous front of the loop is the part I refuse to give up.

So my workflow stays deliberately human at the front: imagine the specific user living the specific day, then write the story until it holds together with no gaps. Then I bring in the machine — to brainstorm against the story, and to build it — and I keep reviewing the output against that story, because the only way I know the build is right is that I can still tell it while looking at the screen. I've written about why I explore before I instruct — this is the same principle one level up.

If You Want One Lesson

If you take a single thing from this for building AI prototypes and shipping AI-assisted products, take this:

Write the story before you write the prompt. AI has made imagination the bottleneck and writing the interface to it. The build is cheap now — so the leverage moved entirely to imagining the right thing and telling its story clearly enough that the machine, and you, can both see it whole.

What I'm Still Working Out

Which leaves the questions I haven't finished answering — and that I think are the real work now:

• What are the attributes of a story worth building from — what makes one cohere, and another quietly fall apart on contact with a real user?
• What does it actually mean to write well for a machine — and where does that part company with writing well for a person?
• How much of the imagining can you genuinely hand to AI before the thing stops being yours?

I'll be sharing how I think about each of these in notes to come. Until then, the whole discipline fits in one instruction: before the next prompt, write the story.