Iterating With AI on a Real Project

This is the AI-collaboration chapter for the part, and the last one in the course. The previous AI skills were mostly about checking a bounded answer: read this code, test this edge case, compare these two approaches, critique this data design, verify this library call. A game project is less bounded. There is no single final answer. There are always more features you could add.

That makes AI both useful and dangerous. It is useful because an AI assistant can help you add a feature, diagnose a bug, or suggest a small variation quickly. It is dangerous because it can keep producing more code forever. If you accept every suggestion, your game can become larger without becoming better, and you may stop understanding the project you are supposed to be finishing.

The final skill is iterating with AI on a real project, and recognizing when to stop.

Why Project Iteration Is Different

Earlier exercises often had a clear target. A function returned the right value or it did not. A file was saved correctly or it was not. A pandas helper returned the expected dictionary or it did not.

A game has correctness, but it also has feel. The code can run, the rules can be consistent, and the result can still be less fun than the smaller version you had ten minutes ago. More features can create more bugs, but they can also create more decisions for the player than the game needs.

AI assistants are very good at offering the next thing:

• add enemies,
• add power-ups,
• add particles,
• add levels,
• add sound,
• add a menu,
• add high scores,
• add a shop,
• add difficulty settings.

Any one of those might be a good idea. All of them at once is a project that no longer has a shape. The skill is not getting ideas. The skill is choosing the next small change, checking it, and deciding whether the game is better afterward.

Start From a Game You Understand

Do not ask an assistant to write the whole game for you. Start from a game that already runs and that you understand line by line. Then ask for one change.

A weak request:

Make this game better.

A useful request:

I have a Pyxel game where the player is stored in a dictionary with
x, y, vy, and fuel. In update(), gravity increases vy by 0.2 every
frame. When the up arrow is held and fuel is above 0, subtract 0.5
from vy and subtract 1 from fuel. Do not rewrite the whole program.
Show only the changed update logic and explain which variables are
read or changed.

The second request gives the assistant a small box to work inside. It names:

• the current state,
• when the change happens,
• the rule,
• the edge case,
• and the constraint that the whole program should not be rewritten.

Those details make the answer easier to check. You can ask: does the code read fuel? Does it avoid thrust when fuel is empty? Does it change vy in the right direction? Does it leave the rest of the program alone?

The Iteration Packet

When asking for help on a game feature, give the assistant an iteration packet. It does not need to be long, but it should include the facts that keep the answer grounded.

The check matters. It turns a vague feature into something you can verify. Even if the game also needs to feel right, one or two concrete checks catch many mistakes before you start tuning.

Here is the same idea for a Breakout-style change:

I have a list of brick dictionaries. Each brick has x, y, w, h,
and alive. When the ball hits an alive brick, set alive to False
and increase score by 10. Do not remove bricks from the list.
Keep the collision helper separate from drawing. Show the helper
and one call site.

That prompt is not long because the feature is complicated. It is long because it removes guesses.

Check Before You Keep a Change

Treat each AI suggestion as a proposed change, not as finished work. Before you keep it in your game, run through a short checklist.

Read the changed code. If you cannot explain the change, do not keep it yet. Ask for a simpler version or an explanation tied to your variables.

Check the feature against your packet. Does it use the state you described? Does it run at the right time? Does it handle the edge case? Does it respect the constraints?

Check unfamiliar Pyxel calls. Working With AI on Libraries You Are Still Learning taught the library habit: a specific library call is a hypothesis. If the assistant uses an unfamiliar Pyxel function, check the Pyxel documentation, dir(pyxel), help(...), or a tiny program before trusting it.

Run the game and test one thing. Do not just play randomly. If you added fuel, exhaust the fuel. If you added bricks, hit one brick. If you added undo, make one move and undo it.

Keep the change only if the game is better. Better can mean clearer, more responsive, more interesting, or easier to understand. More code is not the same as better.

Before a risky change, first keep a known-working version. Professional programmers commonly use version control, which records versions of a project and lets them return to an earlier one. Learning version-control tools is outside the scope of this course, so for this project you can simply copy your file and give the copy a clear name. Either approach lets you experiment without losing the last version that worked.

When to Stop

Finishing is a skill. AI assistants make stopping harder because there is always another suggestion available.

Good stopping signals:

• The core game is playable from start to finish.
• The player can understand what to do without reading your code.
• The main loop, state, and rules are still understandable to you.
• Known bugs are either fixed or small enough to not impact gameplay.
• The next feature would require restructuring more than it would improve the game.
• You are adding features because they are available, not because the game needs them.

The last point is the sneaky one. A suggestion can be good in isolation and wrong for this project. A menu system may be useful in a larger game. A particle system may look nice. A shop may add strategy. But if your goal is to finish a small game, the best next action might be to stop adding features, clean up the code, and let someone play it.

Review the Worked Request

Return to the focused Lunar Lander fuel request from the start of this chapter. When an answer comes back, check it against the same compact list:

1. Does the change use the state named in the request?
2. Does thrust require both the up key and fuel above 0?
3. Does it change velocity and fuel by the requested amounts?
4. Does it leave unrelated movement, collision, and drawing code alone?
5. Are any unfamiliar Pyxel calls real and used with the documented arguments?

If the answer is correct, integrate it. If it is almost correct, fix the incorrect part. If it rewrites the whole game around a new class structure you did not ask for, reject that version and ask again with a tighter constraint.

The Full AI Arc

Across the course, the AI thread has not been about trusting or distrusting AI in general. It has been about becoming the programmer who can use it with judgment.

The assistant can type quickly, suggest possibilities, and explain patterns. You decide what the program is supposed to become. You check the code. You choose the next step. And when the project is good enough to share, you stop adding and finish.

Check Your Understanding

1. Why is “make my game better” a weak request?
2. What six pieces can be included in an iteration packet?
3. Why should you check unfamiliar Pyxel calls before keeping AI-generated code?
4. Name two signs that it is time to stop adding features.
5. What is the difference between a feature being good in isolation and good for your current project?