Chapter 1: Put AI in the Passenger Seat
IN THIS CHAPTER
» Defining vibe coding without the sales pitch
» Recognizing useful jobs for an AI assistant
» Keeping human judgment in the loop
» Establishing a safe first workflow
AI can help you build a small game, but it can’t take responsibility for whether the game works. Think of it as an enthusiastic assistant who can draft instructions quickly and occasionally mistake a suggestion for a completed assignment. You still decide what belongs in the game and whether a change deserves to stay.
This chapter gives you a clear division of labor and a repeatable way to handle suggestions. You’ll use Star Basket, a desktop game about catching five falling stars, to separate useful assistance from unearned confidence. You don’t need installed tools or programming experience yet. A place to write four short lines is enough.
Defining Vibe Coding Without the Fog
Vibe coding is an informal way of developing software by describing what you want to an AI tool and working with its responses. You might ask for a moving basket, inspect the suggested instructions, and try them in your game. The description starts the work; it doesn’t prove the result.
A prompt is the request or instruction you give an AI tool. It can be as vague as “make a game” or as specific as “keep this basket inside the left and right edges.” Specific requests give you a smaller result to understand and a clearer way to judge it.
The attraction is practical: you can describe a desired behavior before you know every programming word needed to create it. An assistant can help bridge that gap. You still need to learn enough to recognize what its suggestion changes.
Source code is the human-readable instructions that tell software what to do. An AI tool can draft source code, but its response isn’t automatically compatible with your tools or faithful to your rules. A convincing explanation and a correct result are different things.
People use “vibe coding” to describe several habits, including rapid experiments where they barely inspect the generated code. I use a more careful approach here: request one small change, inspect it, apply it only when understood, and check the result. Experimentation is welcome; blind acceptance isn’t the method.
DON'T FORGET: An AI response is a proposal. Your review and an observed result are what let you accept it.
For Star Basket, that means asking for basket movement before asking for scoring, timing, and finished on-screen controls and messages. If the basket behaves incorrectly, you have one small change to investigate rather than a whole game to untangle. You aren’t expected to understand everything at once, and the assistant doesn’t get extra credit for delivering everything at once.
Giving AI Jobs It Can Actually Help With
An AI coding assistant is a tool that uses AI to suggest, explain, or revise programming instructions in response to your requests. Its useful role is to help you think and draft, not to certify that its own answer works. That distinction matters even when its explanation sounds precise.
Give the assistant a task with a visible result. Suppose Maya, a first-time maker, wants Star Basket’s basket to move left and right. Instead of requesting the whole game, she describes the current basket, the intended controls, and the change she wants.
Drafting is one useful job. Maya can ask for a proposed movement change that supports Left and Right as well as A and D. She should also ask where the change belongs and what it leaves untouched, so she isn’t handed a replacement game disguised as a minor edit.
Explaining is another useful job. Maya can ask, “Which part reads the keys, which part changes the basket’s position, and which part keeps it inside the play area?” An explanation that names those responsibilities is more useful than a claim that the code follows best practices.
Suggesting checks is a third job. The assistant might propose holding Left at the left edge, trying D at the right edge, and releasing both keys. Maya can compare these suggestions with the intended behavior, then perform the checks herself.
Diagnosing a narrow problem is a fourth job. If the basket moves with arrow keys but not A and D, that observation gives the assistant a focused question. “Nothing works” supplies much less evidence and invites much broader guesses.
These jobs remain suggestions until Maya checks them against the project. An assistant may overlook a missing setup step or explain code it hasn’t actually supplied. For tool choice, see Chapter 2; for clearer requests, see Chapter 5. The assistant can propose the homework, but it doesn’t grade its own paper.
Keeping Decisions That Belong to You
You own the game’s goal, limits, permissions, checks, and release decision. That ownership doesn’t require you to know every programming detail. It means you decide what the game should do and don’t let a generated suggestion quietly change the agreement.
An acceptance check is an observable test that tells you whether a requested behavior meets your stated expectation. For basket movement, one check is that holding Left at the left boundary doesn’t move any part of the basket outside the play area. “Movement feels professional” isn’t specific enough.
Star Basket’s goal is to catch five falling stars before the round ends. Suppose Maya receives a scoring suggestion that awards two points per catch and declares victory at five points. It might look tidy and produce cheerful feedback, but it permits victory after only three catches.
The problem isn’t whether the scoring instructions run. The problem is that they implement a different rule. Maya should reject the change or request a correction, then check that each catch advances the count exactly once and that victory follows the fifth catch.
Use this division of responsibility to distinguish the assistant’s drafting role from your decision-making role:
| Decision or task | Who owns it |
|---|---|
| Game goal and feature limits | You decide; the assistant can help clarify wording. |
| Proposed code and explanations | The assistant can draft; you review before use. |
| Permissions and rights to artwork or other materials | You establish permission; the assistant’s assurance isn’t evidence. |
| Checks and release approval | You choose checks, observe results, and decide whether to share. |
The table separates assistance from authority. You can ask for alternatives without giving the assistant permission to adopt them.
DON'T FORGET: Correct behavior means following your game’s rules, not merely running without an error.
For the full project limits, see Chapter 3; for inspecting code, see Chapter 7. An attractive scoring display isn’t an amendment to the rules.
Repeating One Small Build-and-Check Loop
A small build-and-check loop is a repeated sequence for changing the game without losing track of what caused the result. You save, request, review, apply, run, and check one change. Repeating that sequence turns a large task into decisions you can actually inspect.
Start by saving the current work and protecting a known-working version before editing. Note what already works, even if the answer is only “the game opens and shows a basket.” That gives you a starting point rather than a memory contest after the next change.
Next, request one behavior. For example, ask only for horizontal basket movement, leaving the falling star and score alone. Include what success should look like, such as movement with both key pairs and stopping at each edge.
Review the response before applying it. Confirm that it changes only the intended behavior, identifies where its instructions belong, and explains anything unfamiliar. If you can’t tell what a proposed operation does, pause and ask for clarification rather than treating uncertainty as approval.
Apply only the reviewed change, then run the game. Running tells you whether it starts; checking tells you whether it behaves as required. Hold each direction, release the key, and watch the basket at both boundaries rather than deciding from one brief movement across the middle.
SMART MOVE: Keep a three-sentence note for each change: what you requested, what you observed, and whether you kept it.
If the check fails, record the difference between expected and actual behavior before trying another change. If it passes, save that working state before moving on. Either outcome gives you useful evidence, provided you haven’t mixed several unrelated edits together.
For the playable game instructions, see Chapter 6; for saving versions and recovering work, see Chapter 8. A loop with six clear actions is more useful than a heroic afternoon with no reliable stopping point.
Setting Boundaries Before Anything Runs
Safe AI assistance starts with limits on information, tools, and permitted actions. Star Basket needs only a small game project on your computer, not access to your accounts or unrelated files. Establishing those limits early makes unexpected requests easier to recognize.
Keep passwords, API keys, personal information, and confidential code out of AI requests and public uploads. An API key is a secret credential that lets software use a service, and this game doesn’t need one. Share only the small, reviewed excerpt needed to explain the current problem.
Use trusted official sources for the tools you install. Don’t accept a download link merely because an assistant presents it confidently, and don’t add extra software to solve a problem this project can handle with built-in features. Tool selection belongs to a deliberate check, not an unexpected detour inside a coding response.
Reject surprise commands and operations. Star Basket has no online connections, accounts, advertising, purchases, or player tracking. A suggestion to contact an outside service, launch another program, request credentials, or operate on files outside the approved project workflow doesn’t fit its job.
DUMB MOVE: Pasting secrets, running unexplained commands, or disabling security protections can expose accounts or damage files. Stop instead of testing whether the assistant’s reassurance is justified.
Keep experiments inside your own project on a computer you’re permitted to use. Advice about a basket-catching game doesn’t grant permission to inspect someone else’s systems, modify third-party games, or work around restrictions on a shared device. Save a protective copy and use a separate practice copy when testing reviewed changes whose results you’re unsure about.
When an operation is unclear, ask a trusted adult or experienced developer to help assess it before anything runs. Younger readers should get appropriate help with permitted installations and sharing decisions, while respecting account rules. “It says this is necessary” is a reason to investigate, not a security policy.
Writing Your Ten-Minute Working Agreement
A working agreement is a short statement of what you’re building and how you’ll decide which changes to accept. It keeps your goals and safety limits visible when an assistant offers something impressive but unrelated. Ten minutes and four lines are enough to make it useful.
Start with Star Basket rather than a general promise to “be careful.” Your agreement should identify the goal, the assistant’s permitted work, the review gate, and the reasons to stop. You’re setting conditions for your own workflow, not relying on the assistant to enforce them.
Write the agreement using these four steps:
- Name the game’s job. Write: “Star Basket lets you move a basket to catch five falling stars before time runs out.” Keep extra features outside this sentence.
- Limit the assistant’s role. Write: “AI may propose one small code change, explain it, and suggest checks.” If you aren’t using AI, replace this with: “I’ll follow the book’s reference code and manual instructions.”
- Require a review gate. Write: “Before applying a change, I’ll save the working version, understand the proposal, and choose an observable check.” After applying it, record what actually happened.
- State your stop conditions. Write: “I’ll stop for secrets, unexpected downloads or commands, unrelated file access, unclear permission, or behavior I can’t explain.” Ask for suitable help rather than proceeding on confidence alone.
Your four lines are now a decision aid, not just a statement of good intentions. Read a proposed change against them before changing the project or copying instructions.
Sam follows the no-AI-account route on macOS using the book’s reference code. The same agreement still applies because copied instructions need understanding and testing regardless of their source. Where needed, a parent or guardian helps with permitted installation and sharing decisions, not account-rule workarounds.
Keep the agreement beside your game notes so you can consult it during the next change. No signatures in triplicate are required.