Stop Coding With AI. Start Thinking With It.

Most game devs are using AI wrong.

The pattern I see in every Discord, every prototype, every "vibe coded in 4 hours" demo: paste the prompt, take the code, glue it together, ship it. Six weeks later the game doesn't make sense to anyone — including the dev who built it.

I've shipped puzzle, casual, and casino games with and without AI in the loop. The difference between teams that benefit from AI and teams that drown in it isn't model choice or prompt skill. It's whether they treat AI as a code generator or as a thinking partner.

Here's the workflow that actually works.

The Direct-Code Trap

Default usage looks like this:

"Write me a match-3 board with cascade clears."

You get a 200-line script. It works for 5 minutes. Edge case 12 breaks something. You can't debug it because you didn't design it. You ask AI to fix the bug, it adds 60 lines. By week 3 you have a 900-line file nobody understands and you're scared to touch it.

This isn't an AI problem. It's a workflow problem. You skipped the part where you decide how the system should work, and outsourced both the design AND the code in one prompt.

The output is "functional" code on top of a structurally broken understanding.

Reframe: AI as a Senior PM, Not a Junior Dev

Pretend you've hired a senior game designer who has shipped 100 titles, has read every postmortem on the internet, has seen every published codebase, but who has zero context on YOUR game.

How would you actually work with that person?

You wouldn't say "write me a match-3 board." You'd say:

• "Here's my mechanic — what's the state machine you'd suggest?"
• "What edge cases do Royal Match and Block Blast handle that I might miss?"
• "Walk me through 5 ways this could break in production."
• "If you were reviewing this design at Dream Games, what would you challenge?"

You're using their pattern library to upgrade your own thinking. The output isn't code. It's a sharper version of you.

That's where AI's leverage actually lives.

The Three Modes That Matter

I split AI usage in game dev into three modes. Most people only use Mode 3.

Mode 1 — Brainstorming Partner. "Here's a half-baked mechanic. Pick it apart. What makes it sticky? What kills retention? What's the meta wrapper?" Output is a list of considerations you didn't have, framings you can adopt or reject, names of similar games to study.

Mode 2 — Architecture Reviewer. "Here's how I'm thinking about the state model. Where will this break at 10x scale? What's the cleaner separation? Compare ECS vs OOP for this specific case." Output is an architecture diagram in your head, not a class file.

Mode 3 — Code Generator. "Write the level loader." Output is code — but ONLY for the parts where you already know exactly what you want.

Most devs jump straight to Mode 3. The leverage compounds when you spend 70% of your AI time in Modes 1 and 2.

The Power of Reverse Questioning

Here's the trick that changed everything for me: before AI gives you a solution, force it to ask YOU questions.

"Before you write any code for this puzzle board, what are the 10 questions I should answer first?"

The questions it surfaces are the ones a senior reviewer would ask in a design meeting:

• How are levels stored — JSON, ScriptableObject, procedural?
• Is the board state authoritative on client or server?
• Do special tiles spawn on a curve or by RNG?
• What's the win condition resolution order when multiple trigger at once?
• How does undo work? Or doesn't it?
• Where does difficulty live — config file, tuning sheet, runtime balancer?

Half of these will be questions you hadn't considered. Answering them forces clarity. By the time you actually ask for code, the spec is so tight that the implementation is almost mechanical.

This is the inverse of how most people use AI. Most ask "give me X." The leverage is in asking "make me clearer about X."

Algorithm First, Code Second

For any non-trivial mechanic, my workflow is:

1. Describe the goal in plain language. "I want a match-3 with cascading clears that prioritizes longest matches."
2. Ask for the algorithm in pseudocode. Not C#. Not Unity-specific. Just the logical steps.
3. Stress-test the algorithm with edge cases. "What happens if two cascades complete on the same tile?" "What if the board has no valid moves after a clear?"
4. Refine the algorithm until edge cases are handled in pseudocode.
5. Only then ask for code, or write it yourself.

By step 5, you understand the algorithm so well that the code is just typing. AI can do that part — but it's the lowest-value 20% of the work.

The mistake is starting at step 5.

The Architecture Conversation

For systems-level decisions, AI is a brilliant sparring partner because it's seen 1000 codebases and you've seen maybe 20.

Real conversations I have weekly:

• "I'm storing player progression in PlayerPrefs right now. At what scale does this break?"
• "Compare event bus vs direct refs vs reactive streams for inter-system communication in a Unity casual game."
• "If I add a battle pass system to this puzzle game, where does the data layer want to live?"
• "Walk me through three ways to structure a level editor — pros, cons, complexity tier."

The output is never code. It's a 3-paragraph framing that helps me make the call. Sometimes the framing surfaces an option I didn't know existed.

That's worth way more than a generated class.

When AI Should Actually Write Code

There are absolutely times to skip to Mode 3. Code generation is genuinely high-leverage for:

• Boilerplate. Data classes, JSON serializers, enum-to-string converters, basic UI scaffolds.
• Pure utilities. A pathfinding helper, a math function, a string formatter — anything well-bounded with no game state.
• One-shot scripts. Migration tools, asset processors, throwaway editor utilities.
• Translating between known shapes. "Convert this REST response into this DTO." Mechanical, low-risk.

What you don't want AI generating without heavy review:

• Game loop logic
• State machines for core mechanics
• Multiplayer synchronization
• Monetization flow (the bug that costs you revenue)
• Save/load (the bug that loses player data)

The rule: if the bug would be expensive, you write it. If the bug is cosmetic or quickly visible, AI can write it.

The Workflow That Compounds

A week of my AI usage on a real project, roughly:

• 40% asking AI to question my plans before I write anything
• 25% architecture conversations — "where should this live, why"
• 20% reviewing pseudocode for edge cases
• 10% generating boilerplate I'd otherwise write by hand
• 5% debugging — pasting an error and getting a hypothesis (not a fix, a hypothesis)

The output isn't faster code. It's a system I understand end-to-end, with edge cases I would've otherwise found in production.

Compared to "vibe coding" the whole thing in 4 hours: I ship a week later, but the game doesn't fall apart at scale.

What Changes When You Work This Way

Three things shift when you stop asking AI to code and start asking it to think:

1. Your specs get sharper. You can't have a vague conversation with AI; it'll give you vague answers back. Tightening your prompts tightens your design.

2. You actually learn. Mode 3 (code gen) skips the learning. Modes 1 and 2 force you to engage with the why of every decision. Six months later, the second project is 3x faster — not because of AI, but because you internalized patterns you'd have skipped past.

3. Your code becomes maintainable by you. The dirty secret of vibe-coded projects is that nobody — including the original author — can extend them safely after week 4. Code you understand at the algorithm level is code you can refactor.

Bottom Line

AI's real leverage in game dev isn't typing speed. It's cognitive bandwidth.

Treat it like a senior PM who'll spar with you on design, surface edge cases, propose architectures, and challenge assumptions — and the games you ship are sharper, more thought-through, more shippable.

Treat it like a junior dev who'll write whatever you ask — and you'll ship a prototype fast, then watch it collapse the moment real players hit it.

The tool didn't change. The framing did.

Build the framing.