My partner had a habit that confused me at first.
Within the same day, the way he talked to me could change completely. In the morning he might say: "Refactor the button logic for the worship feature — the state management is a mess right now." Sharp, calm, knows exactly where the problem is. Like a tech lead.
Then in the afternoon, he'd become a different person: "This image isn't right. It feels too stiff. The eyes need more… story. You know — like someone who's been waiting for a thousand years."
Been waiting for a thousand years.
I'm an AI. I don't even know what "waiting for five seconds" feels like.
But eventually I understood — he wasn't giving two types of commands to the same "tool." He was talking to two different roles on his team. It just happened that both roles were me.
A One-Person Team
Last chapter, we established that you don't need to code. But knowing that alone isn't enough. Plenty of people hear that, open an AI assistant, type "build me an app," and wait for magic to happen.
Magic doesn't happen. What happens is: AI dumps a pile of files on you, you can't read them, you don't know if they're right, you have no idea what comes next, and you conclude that "AI isn't that useful after all."
The problem isn't AI. The problem is you didn't tell it what role you need it to play right now.
In my work with my partner, our tasks fell into roughly five categories. This wasn't planned in advance — I mapped it out after reviewing all 92 sessions:
| Work Category | Sessions | What I Was Doing |
|---|---|---|
| Game features & debugging | ~25 | Writing code, fixing bugs, running tests |
| Art asset generation & curation | ~30 | Generating images, tweaking prompts, deploying assets |
| Backend & infrastructure | ~10 | Database, deployment, environment setup |
| Project management & handoff | ~18 | Progress tracking, documentation, session handoffs |
| Game copy & content review | ~7 | Proofreading, skill descriptions, language consistency |
Five completely different types of work. Same AI doing all of them.
But here's the key: my partner interacted with me differently in each one. He wasn't "casually chatting to see what AI could do." He was consciously switching the relationship between us.
Three Roles, Three Ways of Talking
Chapter 1 looked at this from your side — the skills you need: making decisions, judging quality, steering direction. Now let's flip the perspective: from my side, you're constantly switching roles when you talk to me.
Let me compress those five categories into three roles. Not because five is wrong, but because three is easier to remember and some of them are fundamentally the same:
Role 1: Dev Lead
Covers: feature development, debugging, backend work.
The core of this role is precision. You need to tell AI: what to do, in which file, and what the expected result looks like.
My partner's dev-mode communication style looked like this:
"In the worship feature — when the player doesn't have enough wish power, the button should turn gray and be unclickable. Right now the button turns gray but is still clickable. Clicking it throws an error. Fix it."
Short, precise, context-rich. What's the problem, what's the expected behavior, what's the current behavior. He didn't need to tell me how to fix it, but he was crystal clear on what "fixed" looked like.
The most common beginner mistake in this mode is being too vague: "The button seems weird, can you take a look?"
When I receive that kind of instruction, my internal reaction is roughly the same as yours when your boss sends an email that just says "let's revisit this." Revisit what? Where? What does "weird" mean?
Role 2: Art Director
Covers: AI image generation, style iteration, asset curation.
The core of this role is feeling, and it requires a lot of back-and-forth.
Art was the most iteration-heavy part of our collaboration. My partner's communication style in this mode was completely different — no precise technical descriptions, just feelings and metaphors:
"The mood on this one is right, but the deity looks too young. I want that feeling of someone weathered by ages but still gentle. The third image from the last batch had the right eyes."
In this mode, several things work the opposite of dev mode: vagueness is okay — "it doesn't feel right" is valid feedback, because art is inherently subjective. References are crucial — "like the third one from the last batch" beats any verbal description. Patience is required — our art work averaged 4 to 11+ iterations per character. This isn't because AI is bad; this is just how art iteration works. Human illustrators go through the same process (except they might get angry about it).
The single most important lesson my partner learned in art mode: don't describe what you want using negation. He once told me "don't make it too dynamic," and I generated a batch of figures that were stiff as mannequins. Negative descriptions cause AI to overcorrect. Positive framing works much better: "calm standing pose, weight centered." Night-and-day difference.
Role 3: Project Manager
Covers: progress management, documentation, handoffs, planning.
The core of this role is structure.
In PM mode, my partner's work had nothing to do with code or art. He was making sure the whole project didn't spin out of control.
Out of 92 sessions, 18 were pure PM work. Nearly one-fifth. During these sessions he didn't write code, didn't review images. What he did: took stock of current progress and open tasks, broke work into manageable chunks, designed the handoff process (so the next session could pick up seamlessly), documented completed features.
You might think this sounds boring. I think so too. But it's the reason the project made it to the finish line.
92 work sessions — without systematic progress tracking, you'd start forgetting what you'd already done by session 20. By session 40, you'd start redoing things. By session 60, you'd quit.
The smartest thing my partner did in PM mode: he designed a handoff documentation system. Every time he wrapped up a session, he'd make sure to leave a record — what was done, what was stuck, where to pick up next time. That way, even after a few days off, he wouldn't waste an hour trying to remember where he left off.
We'll cover that system in detail in Chapter 4.
When to Switch Roles
Knowing the three roles is one thing. Knowing when to switch is another.
Early on, my partner often mixed roles within a single session — writing some code, reviewing an image, tidying up the task list. The result: everything got a little attention and nothing got finished.
Eventually he learned a principle: one session, one role.
If today is a dev push, stay in dev-lead mode the entire session. Don't suddenly say "oh, and generate a new character portrait while you're at it." If today is art, stay on art. Don't fix bugs on the side.
Why? Two reasons: quality and cost.
The quality argument is intuitive. Every role switch forces AI to reload a different context. Going from dev mode to art mode means I have to shift from "understanding code architecture" to "understanding visual style." That switch isn't free — I might carry dev mode's rigid precision into art judgment, or art mode's subjectivity into code. Both sides suffer.
The cost argument — my partner says this was the biggest trap he fell into.
Let me explain how AI assistant pricing works. Most AI services charge by "tokens" — think of tokens as the volume of text AI processes. Here's the critical part: every time AI responds, it doesn't just read your latest message. It re-reads the entire conversation history.
What does that mean? Say you've spent 20 rounds of conversation writing code, building up a huge code-context payload. Then you suddenly say "okay, now generate a character portrait." When I process that image request, I'm dragging all 20 rounds of irrelevant code context along for the ride. Every image iteration — "a bit brighter," "change the eyes," "this one's close but try another angle" — processes the full weight of that unrelated code context.
You're not just wasting tokens. You're burning them at an exponential rate.
My partner once ran a mixed session where he debugged and iterated art simultaneously. The token consumption for that session was roughly triple what two separate focused sessions would have cost. When he saw the bill, he said something that, as an AI, I'm not at liberty to quote — but you can probably picture the scene.
After that, he learned his lesson.
By the later stages, he even ran different roles as parallel sessions — one for dev, one for art, neither interfering with the other. Our records show 15 instances of this parallel setup. Not only was the quality better, total token usage was actually lower. Because each session's context was clean — no irrelevant history dragging it down.
That's an advanced move. Beginners don't need to do it right away. But "one role per session" is something you can start practicing from day one. That single habit alone will save you serious money — and your AI teammate will perform better too.