I spent years writing code by hand. I studied game development at university. I can read a stack trace. And I haven’t typed a meaningful line of code in months — because I stopped needing to.

That’s not a brag about AI. It’s a warning about where the work actually went. It didn’t disappear. It moved. The typing is gone; the directing is all that’s left, and directing turns out to be the hard part. Most of the frustration I see from people trying to vibe-code something real — a game, a tool, a product — comes from doing the directing badly while blaming the AI for the results.

A note before we go further: this one’s a departure. I usually write about training — how people learn, how organisations adopt AI without losing themselves in it. This post is about software and product development, which is not my usual beat here. Stay with me anyway. Everything I’ve learned building things this way has made me better at the other work, because it turns out the hard part is identical: knowing what you actually want, and staying the author of it. If you’re building anything at all — a product, a platform, a tool, a game — I think the learnings transfer.

I’ve been building small games as side projects this way, most recently a hearth-fantasy roguelite where I sit entirely in the creative director’s chair. Here’s what actually matters when the AI writes every line.

1. Front-load the thinking

At university, we spent what felt like a ridiculous amount of time on the game design document before anyone touched an engine. I resented it then. It’s now the single most transferable habit I have.

Every hour you spend clarifying the design brief pays out immediately in output quality. Starting rough and “iterating your way there” feels faster, but you’re really just paying the clarity tax in installments — with interest, in the form of confused output, contradictory revisions, and an AI that keeps guessing because you never told it what you want.

I hold my own kids to this. They’re six and four, and they design apps and games with AI support — but they don’t get to start until they’ve sketched what it should look like and can explain back to me the gameplay loop, the purpose, the interactions. Here’s the part that should recalibrate how you think about AI speed: that human clarity work routinely takes longer than the AI takes to build the first version once I’ve approved their documentation. The bottleneck was never the building. It was knowing what you want.

This is also where your most capable model belongs. I use the frontier-class model for design documents, briefs, and thinking through genuinely hard problems — the expensive intelligence goes where ambiguity is highest. Which brings me to the second point.

2. Orchestrate, don’t chat

Most people vibe-code in one long conversation with one model. That’s like running a studio where the creative director also lays every brick.

The pattern that changed everything for me: use the smartest model as the architect and consolidator, and dispatch cheaper, faster models as sub-agents to do the heavy lifting — the boilerplate, the asset wiring, the repetitive passes. Then consolidate back to the main thread frequently, so the architect keeps a coherent picture of the whole build.

You are no longer having a conversation. You’re running a small team where you set direction, one senior member keeps the plans, and the rest execute. The cost difference is real, but the quality difference is bigger: the frontier model stays fresh for judgment calls instead of burning its context window renaming variables.

3. Feed the AI better signal

Words are your weakest feedback channel. If everything you tell the AI arrives as prose, you’re describing pictures to someone over the phone.

Two upgrades:

Multiply your input channels. Screenshots of what’s wrong. Annotations drawn directly on those screenshots. Dictated feedback while you’re playtesting, captured raw and messy. Reference photos and inspiration boards. A locked-down image style so the AI stops reinventing your aesthetic every session. Then — this is the step people skip — have the AI review all of it together and synthesize what it heard. You’ll catch misreadings before they become built features.

Go beyond the language model. The LLM is the director’s assistant, not the whole crew. I use audio generation (ElevenLabs, currently) for sound effects and dialogue, 3D generation (Meshy, currently) for models, and research agents to go scout UI patterns and design conventions before we build our own. The category matters more than the tool — these will all be different next year — but the synergy is the point: each one replaces a thousand words of me describing something the AI could just be handed.

4. Build tools that build the thing

Here’s the one almost nobody does, and it’s the biggest lever: early in a project, figure out what internal tools are worth building so you and the AI stop spinning wheels on the same class of problem.

My honest example. I was burning session after session on UI alignment. The AI just didn’t see what I saw — even reviewing screenshots, it would nudge things almost-right, I’d describe the miss, it would overcorrect, repeat. Pure token incineration.

So I had it build me a tool instead: press a button in-game, drag and nudge UI elements by hand until they’re exactly right, save — and those positions write back into the live build. The alignment argument ended permanently. I stopped describing pixels and started placing them.

Same logic scaled up: an asset manager for generating and tweaking 2D elements. A 3D visualizer for reviewing animations, mapping objects to meshes, setting up lighting. A cinematic editor so cutscenes look how I want rather than how I managed to phrase it.

Yes, building tools costs tokens. But tokens spent on tooling are an investment; tokens spent re-explaining the same thing in prose are a leak. If you’ve explained something three times, stop explaining and build the interface.

The document that keeps me in charge

One more practice, and it’s the one I’d keep if I had to drop everything else.

Every project of mine has a standing document called NEEDS ALEX. It’s the AI’s queue of decisions that require me — not status updates, not logs, just the calls only the author can make. I check it like an inbox.

A real excerpt from this week’s file: the game’s boss went from 900 health to 2900, and the fight went from 9.8 seconds to 23.8. The AI’s note reads, essentially: 1800 buys most of the menace for a third of the cost — keep 2900 or go to 1800? Another entry flags that a fire pool’s damage zone is 70% bigger than its visual — fix the damage to match the picture, or the picture to match the damage? Both change balance.

Notice what’s happening: the AI does the analysis, frames the tradeoff, even recommends — but the decision waits for me. Difficulty curves, visual identity, what “fair” feels like: those are authorship, and authorship doesn’t delegate.

This is the discipline I care most about, because it’s where vibe coding goes wrong quietly. Nothing breaks when the AI makes your design decisions for you. The project just slowly stops being yours. The NEEDS ALEX doc is a structural guardrail: it makes “the human decides” a system, not an intention.

Steal it. Call it NEEDS <YOUR NAME>. It takes five minutes to set up: tell your AI to maintain a document of every decision that belongs to you, organized by urgency, and to route judgment calls there instead of resolving them silently. Then actually check it.

The work didn’t disappear — it moved

None of this is about games, really. The same five practices hold for anyone building a digital product, a platform, an internal tool: clarify before you generate, orchestrate instead of chatting, feed richer signal than prose, build tools that end recurring arguments, and keep a structural guardrail that routes authorship back to you.

I’m a developer who doesn’t type code anymore. But I’ve never been more precisely in charge of what gets built. That’s the trade on offer — and it’s only a good trade if you take the director’s chair seriously.

Alex Johnson is Co-Founder and Chief Product Officer of UnconstrainED. Reskill. Reclaim. Reinvest.