An agent is a loop · Read the Loop

Before the fix Keep the ball in play with the paddle. It follows your finger or the mouse; with a keyboard, click or Tab into the game and use the arrow keys or A and D. Watch the first ball: it lands on the right half of the paddle and falls straight through.

The setup

You've seen this game before: a paddle at the bottom, bricks at the top, a ball bouncing between them. Here the ball falls through the right half of the paddle as if it weren't there. On the left half it bounces as it should.

We gave the game's folder to Claude Code, an AI coding agent, and typed one sentence:

The agent can't see the game, let alone play it. It can ask for kinds of thing: . So it has to work from the code and from the game's tests, a file of small checks that Node (a program that runs JavaScript) can run with nothing to install.

The session took seconds, and in that time the model was called times. It was recorded on with . We recorded runs of this task and show run , picked by a rule we fixed before recording: the first run that runs the tests both before and after its fix. All are in the repo. One success on a toy game doesn't prove that agents fix bugs; chapter 7 is about when they don't.

Step through the calls below with the buttons, the slider or your arrow keys. Or press Watch it live to see them at the speed they happened.

The whole idea, in 10 lines

messages = [instructions, your_message]
while True:
    reply = model(messages)  # reads all of it, every time
    messages.append(reply)
    if not reply.requests:   # no request: finished
        break
    for request in reply.requests:
        result = run(request)  # harness runs it
        messages.append(result)
show(reply.text)

The fixed game

This is the game with exactly as the agent's edit left it. Nothing else changed. Watch the first ball again.

After the fix Same controls as before: your finger, the mouse, or the arrow keys once you've clicked into the game.

Three things worth noticing

It checked before and after

The model never saw the game. Before it changed anything, it ran the tests, and a failing test came back: . The edit came on the next call, along with a second test run in which all passed. Each of those was a round of the loop, and each result was text the harness pasted in. That's also why the rule picked this run:

It reads everything, every time

The model keeps nothing between calls. The conversation is its memory, so the harness sends all of it every time. To change lines, calls read tokens between them, of them from the cache. Chapter 3 is about the cache.

"Done" is the model's own call

Nobody tells the agent to stop. Its last reply had no request in it, so the harness stopped. The same reply says the agent checked that a fast ball can't skip past the paddle, and that check exists only as sentences in the reply. Here the tests and the fixed game back up the main claim. Chapter 7 is about the times when nothing does.

model calls

seconds

at list price

lines changed, before → after

Chapter 2: The context window

On a -file toy, in calls, the conversation grew from to tokens, times its size at the start. Most of the growth, tokens, was the code it read. A real project has thousands of files, and sessions that run for hours. What does the model read when the project is real and the session is long?

The game, before the fix