There’s a phrase that sends a chill through every development team: “I’ll know it when I see it.”
It’s the sentence that makes producers reach for their risk registers. It’s the thing designers learn to never say out loud, even when it’s the honest answer. Because in a team environment, “I’ll know it when I see it” translates roughly to “I’m going to waste your time until I figure out what I want.” And that’s not unfair. It is wasteful. It is stressful. It does erode confidence in design leadership when a feature gets steered left, then right, then left again before someone finally says “yeah, that’s the one.”
But here’s the thing. That instinct — the one that says “this isn’t right yet” or “wait, what if we tried…” — that’s often where the best work comes from. The problem was never the instinct. The problem was the cost of following it.
The Two Approaches
I’ve been watching how developers talk about Claude Code, and there’s a dominant pattern. It goes something like this: spend days writing detailed specifications, architecture documents, acceptance criteria. Feed the whole thing into Claude Code. Expect the output to be correct, or close to it. Get frustrated when it isn’t.
There’s absolutely nothing wrong with this approach. For well-understood problems with clear requirements, it’s efficient and it works. If you’re building a dashboard to a known spec, or migrating a database schema, or implementing a feature that’s been designed and approved — plan it, spec it, build it. That’s the right tool for the job.
But there’s another way to use these tools that I think gets overlooked, and it’s the one that’s changed how I work more than anything else in thirty years of making games.
How I Actually Work
My process starts nowhere near Claude Code. It starts with a conversation.
I’ll open Claude Desktop and just talk. “Hey, I’ve got this idea. I want to build something that does X, Y and Z. Let’s talk about it.” No documents, no specs, no architecture diagrams. Just a discussion. We’ll go back and forth, poking at the idea, asking each other questions, figuring out what the thing actually needs to be. If it’s something technical, we’ll research what other people have done. If it’s a game mechanic, we’ll look at similar systems and talk about what works and what doesn’t. If it’s a prototype, we’ll dig into the technical approach — how does procedural animation actually work, what are the tradeoffs, where do people get stuck.
By the end of that conversation, I’ve got something. Not a spec. More like a shared understanding of the shape of the thing. I’ll produce a document from that discussion and take it into Claude Code.
Here’s where it gets interesting. The first thing I do is ask Claude Code to assess the plan. Not just execute it — actually evaluate it, push back on it, flag things I’ve missed. Because it’s the one that’s going to be building this with me, and it often sees things from a different angle.
Then we build. And something gets up and running fast. Not perfect. Not polished. But functional. Depending on the complexity, this might take five minutes, or an hour, or a couple of days for bigger systems.
And this is where most people would call it done, or at least start filing bugs. But for me, this is where the real work begins.
The Part Nobody Talks About
I’ll spend time with that first build. Playing with it. Tuning it. Seeing what feels right and what doesn’t. Being surprised by things I didn’t expect. Going in directions I could never have predicted in that initial conversation.
This is the bit that doesn’t fit neatly into a LinkedIn post about productivity. It’s messy. It’s non-linear. Sometimes I’ll change something fundamental about how a system works because I’ve spent three days watching it run and realised the whole model is slightly wrong. Sometimes a small tweak reveals a possibility that sends the entire project in a new direction — a better direction, one I couldn’t have seen from the planning stage.
This is what I mean by the designer’s mind. It’s not about being unplanned or chaotic. It’s about recognising that some problems can’t be fully understood until you’re inside them. You can have the best intentions, the most thorough planning sessions, the most detailed documents — but you won’t know if a game mechanic actually works until you play it. You won’t know if a system feels right until you interact with it. You won’t know if something is fun until you’re the one with the controller in your hand.
Why This Used to Be Impossible
The reason designers learned to suppress the “I’ll know it when I see it” instinct is because following it had enormous human cost. Every iteration meant someone else’s time. Every pivot meant a team reworking something they’d already built. Every “actually, what if we tried…” meant burning goodwill.
And the thing is, that frustration was completely justified. If you’re a developer who’s just spent two days implementing a feature, and the designer comes back with “this isn’t quite what I had in mind, can we try something different?” — that’s a reasonable thing to be annoyed about. Their time has value. Their expertise has value. And here you are, essentially telling them you didn’t actually know what you wanted when you asked them to build it.
So designers adapted. We learned to commit to ideas earlier than we should. We learned to over-plan, to create certainty where there wasn’t any, because the cost of exploration was too high. The social cost. The time cost. The trust cost.
The work suffered for it, but that was the deal.
The Constraint That’s Gone
Claude Code doesn’t get frustrated. It doesn’t lose confidence in your leadership when you change direction. It doesn’t sigh when you say “actually, let’s try the complete opposite.” It doesn’t tell the rest of the team that design keeps changing their mind.
This isn’t about replacing a team. It’s about removing the one constraint that’s always made creative exploration expensive — the social cost of iteration. You can explore, pivot, throw things away, rebuild from scratch, change direction six times in an afternoon, and nobody’s frustrated. Nobody’s time has been wasted except yours. And it wasn’t wasted because you were learning. Every failed direction taught you something about the problem space. Every pivot brought you closer to the version that actually works.
By the time you bring something to a team — whether that’s other developers, artists, producers, whoever — you’re not bringing a rough idea that might work. You’re bringing something you’ve lived with, tested, refined, and have genuine confidence in. The team isn’t your iteration partner anymore. They’re your scaling partner. That’s a completely different relationship, and a much healthier one.
The Expectation Problem
There’s a related thing I see a lot, and it’s worth addressing. People who do take the meticulous planning approach often have an expectation that the output should be essentially correct once done. They’ve spent days making their documents watertight. They’ve anticipated edge cases. They’ve specified everything they can think of. And when the result still has issues — and it will, because these tools are still new and still imperfect — there’s a disproportionate frustration.
It’s the paradox of effort. The more work you put into the plan, the more you feel the output should match it. When it doesn’t, it feels like the tool failed you, or like you somehow planned wrong.
Starting from a different mental model avoids this entirely. If your expectation is “this first build is a starting point,” there’s no frustration. There’s only forward momentum. Every issue is just the next thing to address, not a failure of process. You’re already in the mindset that this is a conversation, not a transaction.
A Creative Exploration Tool
I think Claude Code is often positioned — and often used — as a programming tool. A way to write code faster. And it is that, and it’s good at it.
But for me, it’s something more fundamental than that. It’s a creative exploration tool. It lets me have an idea, implement it quickly, live with it, tune it, discover what I didn’t know I was looking for. It lets me follow the designer’s instinct — the one that says “this isn’t right yet, keep going” — without burning anyone else in the process. And it lets me arrive at solutions I could never have reached through planning alone, because some things only reveal themselves through the act of building and using what you’ve built.
That’s not a programming workflow. That’s a creative practice. And I think the more people approach it that way, the more they’ll get out of it.
Nic Cusworth is a Design Director with 30+ years in game development. He writes about AI, game design, and the space where they collide at niccusworth.com.