Think With the Machine

In the last chapter you built a game by talking to a machine. You described what you wanted, the machine made it, you played it, and you directed what came next. That is a remarkable thing to be able to do, and for many people it is where their picture of AI stops: a very fast, very willing builder that does what it is told.

This chapter is about the larger opportunity. The machine can help you decide what to tell it.

Asking AI to implement an idea and asking it to help develop the idea are different uses of the same tool. The first makes you faster at producing what you already had in mind. The second changes what you have in mind. I have come to think the second matters more. Faster implementation compresses the time between an idea and its result. Better thinking changes which ideas you have in the first place — and no amount of implementation speed rescues an idea that was never worth building.

The machine can help you think

Most software begins with a decision that has already been made. Somebody knows what they want, or believes they do, and the work is to produce it. Traditional programming reinforced that habit, because thinking was cheap and building was expensive, so the thinking had to be finished before the building could start.

When building became cheap, that constraint loosened. Chapter 13 showed one consequence: you can build several versions and choose between experiences rather than arguments. This chapter shows the other. The thinking itself — understanding a problem, finding out what is already known, imagining alternatives, judging a result — can now be done in conversation with a machine that has read more than any of us and never tires of being asked “why?”.

That does not make the machine wise. It can be fluent and wrong, confident and shallow, agreeable when it should object. Chapter 09 described how to recognise those behaviours. What follows assumes you will keep recognising them. But a thinking partner does not need to be infallible to be useful. It needs to widen what you consider, challenge what you assume, and help you see your own idea more clearly than you could alone.

I find it useful to think of the work as eight overlapping activities: notice, understand, research, imagine, choose, build, experience, improve. They are not stages to pass through in order, and I do not want them to become another framework with boxes to tick. They are simply the places where a machine can help, and where it helps differently. A discovery in any one of them can send you back to any other — and often should.

Begin before you know what you want

Ideas rarely arrive as problems with clear edges. They arrive as a frustration, a curiosity, an itch, a half-formed wish to make something. Most methodologies ask you to convert that into a requirement before anything else happens. I think that is usually premature.

Start instead by noticing. What actually happened that made you want this? What did you see, feel, or keep running into? You can say it badly. The machine does not need a specification; it needs your honest account of the situation, however untidy.

Then let it help you understand. The most valuable thing a machine can do at this point is not answer but question. Ask it to tell you what it thinks you are really asking for, and where your description is ambiguous. Ask it for two or three different explanations of what might be going on. Ask what would have to be true for your first framing to be wrong.

Suppose you have the arcade game from Chapter 13 and your instinct is to say “add more enemies, levels and weapons.” That is a perfectly reasonable instruction, and the machine will happily carry it out. But it is a solution, and you have not yet said what problem it solves. Perhaps the game feels thin. Perhaps you are bored of it. Perhaps you showed it to a child in your family and she lost interest after a minute, and what you actually want is a game she would enjoy. Those are different problems, and “more weapons” answers at most one of them.

The machine should not simply agree with your first statement of the problem. If it does, push it: tell it you want challenge, not confirmation. Chapter 04 described this kind of exploratory conversation as a way of discovering intent before implementation. Here I want to carry it further, because understanding is not a phase you finish. You will come back to it every time something you build surprises you.

Find out what you don’t know

This is the capability I most want readers to take from this chapter, because it is the one people most often overlook. The machine is not only a builder and a conversational partner. It is a research assistant — and used properly, a very good one.

Most ideas sit on top of knowledge the person having them does not possess. Someone who wants to make a calmer, more absorbing game probably does not know what game designers have written about pacing, reward, or flow, or which existing games already do something similar, or what has been tried and abandoned. Before AI, finding that out meant hours of searching, reading and sorting through material of uneven quality, and so most people simply skipped it and built from their own assumptions.

Now you can ask. What is known about this? What approaches exist? What have other people tried, and what happened? What are the main schools of thought, and where do they disagree? Explain this concept to me three different ways. Which of my assumptions would an expert question first?

Research conversations have one rule that matters more than all the others: a fluent explanation is not evidence. A model can describe a study that does not exist, attribute a quotation to someone who never said it, or present an opinion with the confidence of a fact. It does this without malice and often without any sign in its tone. So research with a machine has to be conversational and evidence-based at the same time.

In practice that means a few habits. Ask for sources, and ask the machine to separate what its sources say from what it is suggesting itself. When a claim matters to a decision you are about to make, open the source and check it. Ask the machine how certain it is, and what would change its answer. Ask it for the strongest objection to the view it has just given you. And when the question depends on anything recent — current tools, prices, research, events — use an assistant that can actually search, and be suspicious of any that answers confidently without having looked. If your tools cannot reach current information, the honest response from the machine is to say so, and the honest response from you is to treat its answer as a starting point rather than a finding.

None of this makes research slow. It makes it trustworthy enough to build on. The reward is that you start projects knowing what you are standing on rather than discovering it halfway through — and sometimes you discover that the thing you wanted already exists, which is the cheapest possible outcome.

Explore more than one possibility

Once you understand the situation better, ask the machine to imagine. This is where its contribution becomes genuinely interesting, because it can generate directions you would not have reached by yourself.

Ask for conventional solutions and unconventional ones. Ask for the simplest thing that could work and the most ambitious thing worth attempting. Ask what someone from a completely different field would do. Ask it to combine two ideas that do not obviously belong together. For the arcade game, that might produce a cooperative version for a parent and child, a slow game about tending a fragile space station, a shooter where the enemies are words in a language you are learning, or a game that teaches something about orbital mechanics without ever announcing that it is educational.

Some of these will be silly. That is fine. The point of imagining widely is to stretch the set of things you are able to consider, so that your eventual choice is a choice and not a default.

Two warnings. First, the machine converges, as Chapter 04 described: unless you insist on genuine difference, three ideas may turn out to be one idea described three ways. Ask explicitly for directions that disagree with each other. Second, generated novelty is not quality. A strange combination is not automatically an interesting one, and the machine cannot yet reliably tell the difference for you. Novelty earns its place only when you try it and find it better.

Choose something worth trying

Exploration ends, provisionally, in a choice. Not the theoretically best answer — you will not find that by thinking — but a direction promising enough to test.

The machine can help you compare. Ask it to weigh each possibility against what you actually care about: the experience you want people to have, how complicated it would be, how much time and money it would cost, whether it is feasible with the tools you have, what constraints it must respect, and — the consideration most often left out — what you would learn by trying it. An idea that is uncertain but cheap to test can be a better choice than one that is safe but teaches you nothing.

Let the machine recommend a direction and explain its reasoning. A good recommendation is useful, and pretending you are above taking advice is not independence. But treat the recommendation as an argument to be examined, not a verdict to be accepted. Ask what it would recommend if your main priority were different. Ask what the case is for the option it ranked last. If you notice you are about to choose something purely because the machine sounded certain, stop and ask yourself whether you agree.

Choosing is where your judgement first becomes visible in the work. Everything up to this point could, in principle, have been done by anyone with the same tools. The choice is yours.

Build to learn

Then make it tangible. Chapter 13 covered the mechanics of building by conversation, so I will not repeat them. What changes here is the reason for building.

You build this version not because you are confident it is right, but because experiencing it is the fastest way to find out whether it is. The thinking you did with the machine produced a hypothesis: this direction will be more enjoyable, more useful, more interesting. The build is the experiment. It needs to be just large enough to test the hypothesis — a single level, a rough screen, one working journey — and no larger.

This is the step that used to be impossible to take casually. When a prototype cost weeks, it had to be justified in advance, and so most ideas were judged entirely in the imagination. Now research, imagination and implementation can sit next to each other in the same afternoon. You can read about a design idea at two o’clock and play a rough version of it at four.

Evaluate the idea, not just the implementation

When the experiment exists, use it. Play the game. Read the page. Try the workflow. Navigate the site as someone who has never seen it. Pay attention to what you actually feel and do, not what you expected to feel and do.

Then bring the machine back in. It can check that the thing works as specified, look for obvious gaps, compare the result against the intention you recorded earlier, suggest what to test, and offer a critique from a fresh perspective. Much of this evaluation can be delegated, and more of it will be.

It helps to keep four kinds of evaluation distinct, because they answer different questions. Your own experience of the product tells you whether it achieves what you wanted. Technical verification tells you whether defined properties hold — does the restart work, does the score save. A machine’s critique tells you what another reader of the situation notices. And where something matters enough, independent evidence — real users, measured results, a second reviewer — tells you whether any of the above was wishful. The common mistake is to let one stand in for the others: to accept the machine’s report that everything works as proof that the game is good, or to take your own enjoyment as proof that it is correct.

Above all, evaluate the idea as well as the implementation. A technically flawless version of the wrong idea is still the wrong idea. The calm space-station game may run perfectly and still be boring. That is not a bug. It is an answer — and a useful one, since it cost you an afternoon rather than a month. Chapter 15 will go much further into evaluating the product itself; for now, the habit to build is asking two questions instead of one: does it work, and was it worth making?

Let the idea change

What you learn from an experiment rarely confirms your original idea exactly. Sometimes it needs a small correction. Sometimes it needs to be simplified drastically. Sometimes it reveals that you misunderstood the problem altogether: the child did not want a calmer game, she wanted a game where she could make the spaceships herself. And sometimes an accident in the build turns out to be the most interesting thing about it.

The machine can help here too. Ask it to organise your observations. Ask what the result suggests about your original assumptions. Ask for the next experiment, and for an alternative to the next experiment. Ask, plainly, whether you have been solving the wrong problem.

Progress does not always mean adding. It can mean removing a feature, abandoning an approach, or returning to the beginning with a better question. The cycle is working when your understanding grows, not when the volume of output does.

Chapter 11 drew a sharp line between deliberately adopting a new direction and passively drifting into one, and that line holds here. Changing the idea in response to what you learned is the point of this whole chapter. Changing it because the machine kept proposing additions and you kept saying yes is not. The difference is whether you can say why the idea changed.

The same method, outside a game

The arcade game is a convenient example, but nothing in this chapter is specific to games or even to programming. Consider a hypothetical secondary-school geography teacher who wants her students to understand flood risk in their own town.

She begins with a frustration: the textbook explains floods in general terms, and her students do not connect it to the river they walk past every day. With a machine, she works out what she actually wants — not a lesson about floods, but an experience of seeing their own streets under different conditions. She asks what public data might exist for her area, what approaches other educators have taken, and what she needs to be careful about; the machine points her to the kinds of sources to look for, and she checks the ones that matter herself before relying on them. She asks it to imagine possibilities: an interactive map, a simple simulation where students adjust rainfall and watch the water rise, a role-play where groups advise the council. She chooses the simulation because it is the one she can test quickest with a single class. The machine builds a rough version. Her students use it, and their questions reveal that what fascinates them is not the flooding but why some houses were built where they were. The next version follows their curiosity.

She did not need to be a programmer. What she brought was something no machine had: knowledge of her town, her students, and what a good lesson feels like from the front of a classroom. The machine brought research, imagination on demand, and the ability to build. The result was something neither would have produced alone.

I have made her up, and I have not tested her simulation. But nothing in her story requires capabilities that do not exist today.

Try Machine Coding — Explore Before You Build

You will need the game from Chapter 13, or, if you have not built it yet, the description of Neon Defender from that chapter as a starting idea. Speak each prompt aloud and continue the conversation naturally after each one. These are examples, not scripts; your conversation will go somewhere mine would not, which is the point. The exercise has not been run as a recorded demonstration for this book, so nothing below reports results.

Understand the intention.

I’ve built a little arcade game, but I’m not sure what I want it to become. Ask me some questions to help me understand what kind of game I’d actually enjoy creating, and who I’d want to play it.

Research the possibilities.

I want to understand what makes a simple arcade game enjoyable. Help me research different approaches to game design — pacing, difficulty, reward, what keeps people playing. Explain the important ideas, show me examples, and keep a clear line between what your sources say and what you’re suggesting yourself. Tell me where you’re uncertain.

Pick one claim that matters to you and check its source yourself.

Imagine alternatives.

Based on our conversation, suggest three directions for the game that genuinely disagree with each other. For each one, tell me what makes it interesting and what we’d learn by trying it.

Choose and experiment.

I like the second idea. Help me design the smallest experiment that would show whether it’s actually fun. Keep it simple — I want to try it before we commit to a redesign. Then build it.

Evaluate and improve.

I’ve played the new version. Here’s what I liked and what I didn’t. Help me understand what worked, what didn’t, and whether we should improve this approach, try a different one, or rethink what I wanted in the first place.

Success is not a better game, although you may get one. It is finishing with a clearer idea of what you want than you started with — and with at least one decision you made because of something you learned, rather than something you assumed.

Find your own way

I have described how I think with machines. I want to end by asking you not to copy it too closely.

If everybody follows my tools, my methods and my ideas, they will probably end up creating things that look like mine. That would be a poor outcome, and not because my ideas are bad. Every reader has their own experience, their own interests, their own problems and their own way of seeing the world. That particularity is what makes your contribution potentially different from anything I would make. AI makes it increasingly possible for one person to turn a particular interest into a working creation. It would be a waste to use that possibility to produce the same things everyone else produces.

This is not a promise that originality guarantees success, or that being different makes your work valuable. It is a narrower and, I think, more important point: the decisions in this chapter are where your individuality enters the work. Which problem you choose to care about. Whether you accept the first framing or question it. What you go and research that nobody asked you to. Which of the three directions you pick, and why. When you reject the machine’s recommendation. What standard you hold the result to. What you take from each experiment into the next. A person who makes those decisions deliberately, over many projects, develops a way of working that is genuinely their own. A person who outsources them — to the machine, or to me — gets something competent and interchangeable.

So adapt what is useful here. Simplify what is too heavy. Replace whatever does not suit how you think. Abandon any technique that gets in your way. Use my approach to get started, and develop your own to get somewhere interesting.

The machine will not find the best answer for you. What it gives you is assistance at every point in the creative process — understanding, research, imagination, judgement, improvement — that was never available before. What you do with that is up to you. That is rather the point.

What comes next

Throughout this chapter, one activity kept appearing and kept being deferred: experiencing the result and judging it honestly. That is harder than it sounds, especially when the machine is telling you everything works. The next chapter, Read the Product, Not the Code, is about how to look at what has been built — and why, increasingly, the product rather than the source is where that looking should happen.