We have reached the subtitle of the book. For twenty-four chapters you have learned to program, the hard way and the right way—understanding every line you wrote. Now we add a partner that can make you dramatically faster: an AI coding assistant.
Here is the thing, though, and it is the reason we did it in this order. An AI assistant is a phenomenal accelerator for someone who already knows how to program, and a dangerous trap for someone who doesn't. If you can read code, you can direct an AI, judge what it produces, catch its mistakes, and steer it toward something good. If you can't, you are simply pasting in whatever it gives you and hoping—which is how people end up with apps they cannot fix, extend, or even understand. You spent Acts 1 through 3 making sure you are the first kind of person. Now you get the payoff.
This chapter is about how to work with an AI well. The next two chapters put it into practice, building two new games with AI assistance. Your results in those chapters will differ from mine, and from every other reader's—and that is entirely the point.
In this chapter, we will:
- Understand what AI coding assistants are good at and bad at.
- Look at the kinds of AI tools available.
- Learn to write prompts that get genuinely useful answers.
- Meet the vibe coding loop: describe, generate, review, run, refine.
- See why you must always read the code before you trust it.
- Use AI to debug, and to learn.
- Stay in control of your own project.
Let's learn to direct a very capable, very fallible assistant.
AI as a Coding Partner
The AI tools we mean are large language models—ChatGPT, Google Gemini, Claude, and their kin. You describe what you want in plain English, and they write code, explain concepts, find bugs, and suggest designs. They have read an enormous amount of code and documentation, and for common programming tasks they are astonishingly capable.
But it is worth being clear-eyed about what they are. An AI does not understand your game the way you do. It predicts plausible text based on patterns it has seen. Most of the time, for well-trodden problems, that plausible text is correct and useful. Sometimes it is plausible and wrong—and an AI will hand you a confident, well-formatted, completely incorrect answer with exactly the same cheerful tone it uses for correct ones. It will, with total conviction, tell you that two plus two is five, and unless you know better, you will not notice.
So the mental model that works is this: an AI is a brilliant, fast, tireless junior partner who has read everything and remembers nothing about your specific project, occasionally makes things up, and never says "I'm not sure." It can do enormous amounts of work for you. It cannot be trusted blindly. Your job is to be the senior partner—the one with judgment, who sets the direction and checks the work. That framing will keep you out of almost every trouble AI coding can cause.
What are they genuinely good at? Writing boilerplate you have written a hundred times. Generating a first draft of a system from a clear description. Explaining an error message. Suggesting an approach you hadn't thought of. Translating an idea you can describe into code you can read. What are they weaker at? Anything that needs real understanding of your whole project at once, anything genuinely novel, and—crucially—knowing when they are wrong. Play to the strengths, guard against the weaknesses.
The Tools
AI coding assistance comes in a few shapes, and the field moves fast, so treat this as a snapshot rather than a fixed list.
The simplest is a chat window—ChatGPT, Gemini, Claude, and others, in your browser. You paste in code and questions, it answers. This is all you need for everything in this book, and it is where I would start. It keeps a clean separation: the AI proposes, you decide what goes into Android Studio.
More integrated tools live inside your editor—code completion that suggests whole blocks as you type, and assistants that can read and edit your project's files directly. These are powerful and increasingly common, but they also make it easier to accept code without really reading it, which is the one habit we most want to avoid while you are still building judgment. For this book, the humble chat window is perfect: it forces you to read and understand each piece before you bring it across.
Whichever you use, the principles in the rest of this chapter are the same.
How to Prompt Well
The single biggest factor in the quality of an AI's answer is the quality of your question. A vague prompt gets a vague, generic answer—often using libraries you don't have or features you haven't learned. A good prompt sets the AI up to succeed. You have actually been practicing this all book, in every AI exercise. Here is what those well-formed prompts were quietly doing.
Give context. Tell the AI exactly what you are working with. Our games are Kotlin, on Android, using a custom SurfaceView and Canvas, with no game engine and no Jetpack Compose. If you don't say so, the AI will reasonably assume you want the popular path—and hand you Compose code, or a game-engine answer, that does not fit your project at all.
Be specific about what you want. "Make my game better" is useless. "Add a parallax background of slow-scrolling hills behind the existing grass" is something an AI can actually do well.
State your constraints. This is the one beginners forget, and it matters enormously. Tell the AI what not to use. "I'm a beginner; use only classes, lists, and lambdas—no coroutines, no libraries I'd have to add." Without that, the AI will happily reach for advanced features you can't read, and the whole benefit—code you understand—evaporates.
Ask for explanation. Add "explain each new line" or "comment the changes." You want to learn from the answer, not just collect it.
Put together, a strong prompt looks like the ones you have seen throughout the book:
"I have a Kotlin Android endless-runner game using a custom SurfaceView game loop (no engine, no Jetpack). It's organized into Atlas, Player, Obstacle, and GameView classes; movement uses delta time. I'm comfortable with classes, lists, lambdas, and the game loop, but I have not used coroutines or external libraries. Add a parallax background of hills that scroll slower than the foreground grass. Show me the new code, keep it to the tools I listed, and comment each change."
Notice everything that prompt does: who you are, what you have, exactly what you want, what to avoid, and how to present it. That is the difference between a useful answer and a generic one. Reuse this shape.
Vibe Coding: The Loop
"Vibe coding" is the name that has stuck for building software in a loose, iterative, conversational way with an AI—coding by feel, in collaboration, rather than planning every line in advance. It is a genuinely productive way to work, once you can read what comes back. It runs in a loop of five steps:
- Describe what you want, in a good prompt.
- Generate: let the AI produce the code.
- Review: read it. Do you understand it? Does it fit your project? Is it sensible?
- Run: put it in, build it, try it.
- Refine: it is rarely perfect first time. Tell the AI what was wrong or what you want next, and go round again.
That loop is the rhythm of the next two chapters. You will describe a feature, get a draft, read it critically, run it, and then refine—"that works, but the hills scroll too fast," "that crashed with this error," "now make them parallax in two layers." Each turn gets you closer, and because you are reading every turn, you stay in command of a codebase you understand.
The "review" step is the one that separates productive vibe coding from building a house of cards. Never skip it.
Always Review the Code
This deserves its own section because it is the whole game. Read every line the AI gives you before it goes into your project. Not skim—read, with these questions in mind:
- Do I understand what this does? If not, ask the AI to explain it before you accept it.
- Does it fit my project—my classes, my style, the features I actually have?
- Did it quietly use something I didn't ask for—a library, a Compose component, a coroutine—that I'd now have to set up or learn?
- Does it look like it changed things it had no business changing?
You are well equipped for this. Twenty-four chapters have given you the eyes to read Kotlin and the judgment to smell something off. Use them. When the AI is right, you will see that it is right, and you accept it with confidence. When it is wrong—and it will be, regularly—you will catch it, precisely because you know what correct looks like. That confidence, born of actually understanding the code, is the entire reason we learned things the hard way first.
AI for Debugging
One of the most useful everyday jobs an AI does is help you debug. When something breaks, the AI is a tireless partner to think out loud with. Paste the exact error message (from Logcat or the build output) and the relevant code, and describe what you expected versus what happened:
"This Kotlin code crashes with [paste the exact Logcat error]. Here's the function [paste it]. I expected the player to jump when I tap, but instead the app closes. What's going wrong?"
The AI is often excellent at reading a stack trace and spotting the cause. It is the world's most patient rubber duck—the classic trick where explaining a problem out loud reveals the answer—except this duck has read every error message ever written and talks back. Even when it is wrong about the fix, the act of describing the bug precisely often shows you the answer yourself.
AI for Learning
Do not think of AI only as a code generator. It is also a tutor available at any hour. Whenever something in your own code, or in the AI's, isn't clear, ask:
- "Explain this line as if I've never seen it."
- "Why did you do it this way instead of [the way I'd have done it]?"
- "Show me two different ways to write this, and explain the trade-offs."
Asking why, not just how, is what turns AI from a crutch into a teacher. The reader who asks the AI to explain its choices, and then forms an opinion about them, gets better at programming. The reader who just pastes and runs learns nothing and slowly loses control of their own project. Same tool, opposite outcomes—decided entirely by how you use it.
Staying in Control
A final caution, and then we build. The danger of AI is not that it writes bad code; it is that it writes plausible code quickly, and it is tempting to let it run ahead of your understanding. A few accepted-without-reading suggestions, and you can find yourself with a program you no longer comprehend—at which point you cannot fix its bugs, cannot add features cleanly, and cannot tell when it has gone wrong.
The way to stay in control is simple discipline: keep the architecture in your own head. You decide what classes exist and what they are responsible for—the clean structure you practiced in Act 3. The AI fills in pieces, but the shape of the thing is yours. When a suggestion would muddy that structure, you reject or reshape it. You are the senior partner; the AI works for you, not the other way around.
Hold that mindset and AI is pure acceleration—you will build bigger, richer games far faster than you could alone, while understanding every part. Lose it and you are back to being a hostage to whatever the model spits out. The difference is judgment, and you have spent a whole book earning it.
Summary
AI coding assistants are powerful partners and unreliable oracles at the same time. They are brilliant at boilerplate, first drafts, explanations, and debugging help, and they are confidently, fluently wrong often enough that you must never trust them blindly. The way to get the good without the bad is to prompt well—context, specifics, constraints, and a request to explain—and to work in the vibe coding loop: describe, generate, review, run, refine. Read every line before you accept it, use the AI to learn as much as to produce, and above all keep the architecture in your own head. You are the senior partner.
You are now ready to put this to work. In the next chapter we take the endless runner you built in Act 3 and let an AI expand it dramatically—parallax backgrounds, particle explosions, and more—following the vibe coding loop step by step. Your version will come out different from mine, and you will understand all of it. That is exactly how it should be.