Build to Find Out

The previous chapter ended with three words: build to find out. This chapter explains what they mean, and then asks you to do it.

The idea is simple to state. When building something becomes cheap enough, the built thing stops being the end of the process and becomes the fastest way to think. You do not decide what you want and then build it. You build several things and discover what you want by using them.

That sounds like a small change in sequence. It is a large change in how software comes into existence.

Specification was the price of expensive building

For most of the history of software, the order of work was fixed: decide, then build. Not because deciding first is wise in itself, but because building was expensive. If a version took three months, nobody could afford to build the wrong one. So we argued, wrote requirements, drew diagrams, reviewed documents and held sign-off meetings — every one of them an attempt to predict, in advance, what a thing would be like once it existed.

That ceremony was insurance, and the insurance was rational. It was also, to a large degree, guesswork. A specification describes a product nobody has yet used. Anyone who has delivered a carefully specified system and then watched its first real users has seen the gap between what the document promised and what the experience turned out to be. The document was not wrong because its authors were careless. It was wrong because experience cannot be specified ahead of time with any reliability. It has to be had.

Chapter 12 argued that a task crosses a threshold when doing it yourself stops being worth it. Building has crossed a similar threshold. When a working version costs an afternoon, or a few minutes of conversation, the old order inverts. Building becomes the cheapest available way to answer a question — cheaper than the meeting, cheaper than the document, and far more truthful than either.

A prototype is a question

Chapter 04 distinguished building to learn from building to finish. This chapter pushes that distinction further, because the economics have changed what a prototype is for.

When prototypes were expensive, they were a preliminary step — something you did reluctantly, before the real work, and then usually kept far longer than you should have. When prototypes are cheap, they become the main instrument of thought. You do not sit with a question in your head waiting for an answer to form. You ask the machine to build an answer, and you look at it.

What a built thing teaches cannot be learned from a description. A description of a game says it should be fast and challenging. Thirty seconds of play tells you whether it is. A description of an interface says it should be simple. One attempt to use it tells you where you hesitated, what you ignored and which button you kept looking for. Feel, pacing, confusion, delight: these are properties of experience, and they only appear when there is something to experience.

So I have come to treat a prototype as a question asked in the only language its answer can arrive in. The question might be: is this idea any good? Which of these directions feels right? What happens when someone actually tries to do the thing? The machine builds the question; I supply the answer by using what it built.

Build more than one

The deeper change is that you no longer have to choose between ideas before you have seen them.

When building was expensive, choosing came first by necessity. You could only afford one implementation, so all the comparison had to happen in argument. Now you can ask for three versions of a game in three different moods, or three versions of a screen organised three different ways, and compare experiences instead of opinions. The question “which of these is better?” becomes answerable by trying them rather than by debating them.

There is a skill to this. Machines tend to converge, as Chapter 04 described: ask for three versions and you may receive one idea in three colours. Ask instead for versions that are deliberately different — in mood, in how they play, in what they assume the user wants. Keep each one small, because its job is to answer a question, not to be finished. And keep the question narrow: not “which of these is complete?” but “which of these is worth continuing?”

Divergence is now cheap. Convergence remains your job. The machine can produce alternatives faster than you can evaluate them, so the scarce resource is your attention to each one. Three is usually enough. Ten is usually a way of avoiding a decision.

Throw it away

Hand-written code carried a moral weight it did not deserve. Because it had cost us days, we kept it — patched it, defended it, built on it long after we knew it was the wrong foundation. The cost of having written it disguised itself as a reason to keep it.

A machine-built prototype cost almost nothing to produce, so it can be discarded without ceremony. If you build three versions and keep one, you have not wasted two. You have bought two answers. Discarding them is the purpose of having built them.

What survives is the lesson. A line in the project’s README or Intent Record — tried a slower, calmer version; it felt like a screensaver; abandoned — is worth keeping, because the next session, or the next machine, would otherwise try the same thing again. Chapters 06 and 10 argued for recording what happened. Here the record is cheap and the thing it records is cheaper still.

Two cautions keep this honest. First, cheap is not free. Each version still consumes time, tokens and, above all, your attention, and endless experimentation that never chooses is a failure mode of its own. Build to find out has a stopping rule: stop when you know enough to choose. Second, the disposable stage ends the moment you keep something and start building on it. From then on, the disciplines of the earlier chapters apply — foundations, packages, process, evidence. Building to find out is the front of the loop. It does not replace the rest of it.

A note for experienced programmers

The exercise that follows assumes no programming knowledge. If you are an experienced developer, do it anyway, with one additional rule: do not open the code. Not once.

When something is wrong, describe what you see on the screen, not what you suspect is happening in the source. When you are curious how something works, ask the machine to explain it rather than reading it yourself. It will feel like working with one hand tied behind your back. That feeling is the old interface reasserting itself — the reflex Chapter 12 described, of treating the code as the place where the real work lives.

Notice how often you reach for it. That observation is part of the exercise.

Try Machine Coding: Build Neon Defender

Your challenge: create a real, playable arcade game, try several versions of it, keep the one you prefer, save it on GitHub and publish it on the web — without writing the code yourself.

The game is Neon Defender. A little spaceship flies across a starfield, fires glowing shots, dodges falling obstacles and earns points. There are explosions, a high score and a restart button. It is visually satisfying and technically simple: plain HTML, CSS and JavaScript running in a browser, with no database, no paid service, no package manager and no game engine. That simplicity is deliberate. Your first experience of machine coding should be about the game, not about the setup.

What you need: a GitHub account and an AI assistant that can work with a GitHub repository. Speaking is better than typing for this exercise, because it keeps you describing outcomes rather than composing instructions. At the time of writing (November 2026), ChatGPT’s Voice works with its Work and Codex modes, which can use a connected GitHub account within the permissions you grant. Other coding assistants that can work with a repository will do equally well, and if yours cannot listen, type. Nothing below depends on one product.

These are my instructions to get you started. They are not special, and they are not optimal. Change them. Say things differently. This is an exercise for you to run: each checkpoint describes what success looks like, not a report of my own session.

Step 1 — Create your project on GitHub

Open https://github.com/new and create a repository with these settings:

• Repository name: neon-defender
• Visibility: Public
• Add a README file: Yes
• Description: My first voice-built arcade game

Choose Create repository. You now have a home for your application. The README only establishes the repository’s first branch; you have not written any program code.

Step 2 — Tell the machine what to create

Open your assistant, connect it to GitHub if it is not already connected, and grant it access to your new repository. Then say:

I have a GitHub repository called neon-defender. I want you to build me a complete arcade game called Neon Defender.

It’s a colourful space game. I control a little spaceship at the bottom of the screen. Obstacles fall from above, my spaceship fires automatically, and I score points by destroying them.

I want to move using the mouse, arrow keys or touch on a phone. Give me three lives, a score, a high score, a start screen and a game-over screen with a restart button.

Make it look modern and impressive, with glowing colours and smooth animation.

Use ordinary HTML, CSS and JavaScript. Don’t use any frameworks, external services or paid APIs.

Create the files directly in my GitHub repository, commit the implementation, and tell me exactly what you created. Don’t claim to have tested anything you couldn’t run.

Checkpoint: your repository contains an index.html file and whatever JavaScript and CSS the game needs.

If connecting the repository defeats you, do not start copying hundreds of lines of generated code by hand. Ask instead for the whole game as a single index.html file you can download, save it, and open it in your browser. Playing comes first; publishing can wait until you have sorted out the connection.

Step 3 — Put your game on the internet

Say:

I want to play my game in a browser. Please help me publish this repository using GitHub Pages. If you can configure it with my permission, do so. Otherwise guide me through the necessary GitHub settings. Then give me the public address and check whether the page loads.

If you need to do it yourself: open the repository on GitHub, choose Settings → Pages, and under Build and deployment choose Deploy from a branch. Select main, then /(root), and save. When deployment finishes, the Pages settings show your site’s address.

Checkpoint: a public web page plays your game.

Step 4 — Actually play it

Open the published game. Move the spaceship, shoot, lose a life, reach game over and restart. Then say:

I’ve played the game. Now inspect it and check whether everything works.

Check movement, shooting, collisions, scoring, losing lives, game over, restarting and the saved high score.

Check the desktop experience and the mobile experience wherever your tools allow.

Correct any bugs you can establish. Don’t add new features yet. Commit the corrections and tell me what you tested and what still needs checking.

Checkpoint: you can play a complete round, lose, restart and play again.

Step 5 — Build three, keep one

This is the heart of the exercise and of the chapter. You have a game. Now find out what game it should be.

I want to find out what this game should become. First ask me a few questions about the kind of game I’d enjoy and what I want players to feel.

Then build three quick versions that are deliberately different — different in mood and in how the game plays, not just different colours. Keep each one small and put each in its own folder so I can open them side by side. Don’t change the original.

Don’t polish them. I only need enough of each to play it for a minute.

Answer its questions honestly. Then play each version — properly, for a minute or two each. Say out loud what you notice: which one you wanted to keep playing, which one bored you, which one surprised you. You might find an underwater version, a calm asteroid-drifting version, a frantic one, a children’s one, or something you would never have thought to ask for.

Then choose. You may pick one outright, or combine the best of two:

I’ve chosen the second version, because it feels tense without being frantic. Make it the main game. Keep the other versions in the repository as experiments, and add a short note to the README recording what each version tried and why I chose this one.

Checkpoint: you have played three games you could not have built by hand in an evening, and made a decision based on experience rather than description.

Step 6 — Make it impressive

Only now is polish worth spending. Say:

Now make the version I chose feel like a polished arcade game.

Improve the graphics, add attractive particle explosions, give the spaceship some personality, make the enemies visually interesting and create a beautiful title screen.

Make the game feel smooth and responsive. Add optional sound effects with a mute control, keeping sound off until the player enables it.

Keep the game simple and easy to play. Don’t introduce a complicated menu system or unnecessary features.

Make the improvements, test what you can, and update my GitHub repository.

Then play it again. If the polish has buried what you liked about the version you chose, say so — Chapter 11’s warning about slop applies to games too.

Checkpoint: the game looks and feels substantially better, and it is still recognisably the game you chose.

Step 7 — Finish and share

I want to finish this version of my game.

Check that the main game works, the restart works, the high score is saved in this browser, and the published page loads.

Update the README so someone who discovers the repository knows what the game is and how to play it.

Make sure the final changes are committed. Give me the live website link and the repository link.

Explain any limitations honestly, and don’t claim success for checks that haven’t been performed.

Open the game one last time and play it.

How you know it worked

Success is not that the machine produced code. It is this list, checked by you:

• The game loads from a public web address.
• You can move, shoot and score.
• Lives, game over and restart work.
• The high score survives a page refresh in the same browser.
• Desktop controls work, and touch controls have been tried on a phone.
• The source code and README are saved on GitHub.
• You built at least three versions, played them, and chose deliberately.
• You made at least one creative decision that is genuinely yours.

The published game is public, so it must contain no passwords, API keys or private data. GitHub Pages serves static files; it provides no private backend or database, which is exactly why this game was designed not to need one.

What you just did

Look at what happened, because the sequence is the method of this book in miniature.

You had an idea and communicated it. The machine built it. You experienced the result and directed corrections. And then you did something that hand-built software almost never allowed: you asked for three alternatives, used all of them, threw two away, and chose with evidence from your own experience. Only then did you spend effort on polish, and you spent it on the right thing.

You did not learn JavaScript. You did not install a development environment. You did not write the code. But you made every decision that mattered about what the game would be.

The prompts were mine. That was only to get you started. The important thing is not whether you built my game correctly. The important thing is that you discovered you can create software by communicating what you want — and that the fastest way to discover what you want is to build it and look.

Once you have discovered that, stop building my ideas and start building yours.

What comes next

In this chapter the machine was a builder: you told it what to make, and the thinking about what was worth making happened mostly in your head and in your hands, as you played. But the machine can take part in that thinking too — helping you understand a problem, find out what is already known, imagine directions you would not have reached alone, and judge what you built. That is the subject of the next chapter, Think With the Machine.