Can One Person and AI Make a Game Team?

In part 1, we looked at how a single idea became a testable core loop. The next question is who does all the work needed to turn that loop into a game.

“One person plus AI is a game team” makes an appealing slogan. In real development, though, it needs a more careful definition.

At the scale Kibble Street TD had reached during the period covered here, one person working with AI could cover the main tasks in design, programming, art, audio, and testing, and move the project from a concept toward preparing a first version. That did not give one person the experience of five specialists. Nor did it make AI responsible for the product.

The more accurate conclusion is this: one person and AI can form a small production process. Whether it works like a team depends on clear handoffs, verification, and someone taking responsibility for decisions.

A smaller team still has the same kinds of work

The work required to make a game does not disappear because there is only one developer.

Design defines the core rules, the scope of the content, and the priorities. Programming turns those rules into systems that run reliably. Art establishes recognizable characters, a clear visual hierarchy, and useful feedback. Audio provides atmosphere, responses to player actions, and a sense of rhythm in battle. Testing finds errors and checks whether the result meets the original goal.

Each of these had a concrete counterpart in Kibble Street TD. Battle and economy rules needed ongoing documentation. The game logic and screens needed implementation. Characters, interfaces, backgrounds, and effects needed production and integration. Background music and sound effects needed to be mapped to the right situations. Configuration, battles, builds, and device behavior needed repeated checks.

The difficulty in a small team is often the constant change of perspective. One moment you are judging the pace of play; the next you are dealing with image dimensions, a programming error, or a test result. AI can lower the effort needed to begin each kind of task. It does not make the task itself disappear.

Collaboration happens at the handoffs

Giving AI a broad request and immediately accepting its output is not much of a team process. It is a handoff with no acceptance check.

The more useful approach in Kibble Street TD was to give every round of work clear inputs, a concrete result, and an owner.

A person first defines the problem and writes down what must stay unchanged and what will count as success. AI then reads the current project and turns the request into documentation, code, configuration, candidate assets, or a way to run a check. Once the first draft is ready, automated checks expose structural errors. A person reads, plays, and visually reviews the result to decide whether it is actually usable.

When a result misses the goal, “it feels wrong” is not enough feedback. The observation needs to become a constraint for the next round: keep the existing dimensions and change only the brightness; leave battle values unchanged and fix only target selection; preserve the flow and rebuild only the presentation.

The point is not that AI gets everything right on the first attempt. It is that errors can be found, explained, and carried into the next correction.

People and AI own different parts of the same job

In design, AI can organize rules, find omissions, and flag conflicts. A person still decides the direction, priorities, and trade-offs. In programming, AI can trace existing calls, implement a change, and run regression checks. A person needs to define the system boundaries and the conditions for acceptance.

Art makes this distinction particularly clear. AI can produce candidates, crop and resize images, and check transparency and asset specifications. Whether a character is convincing, an interface feels coherent, or the visuals fit the product still needs human review. Audio has a similar boundary: mapping, integration, and missing-file checks can be systematic, but a file's existence says little about its mood, rhythm, or how it sounds in play.

Testing brings the two sides together. AI can repeat structural checks, rule regressions, and simulations. People are better placed to judge whether controls feel smooth, information is clear, battles have a useful rhythm, and the game behaves as intended on actual devices and platforms.

The useful division is therefore more involved than “AI executes; the person writes requests.” AI extends the range of work that can be covered. People remain responsible for the goals, judgment, and final result.

A real revision: passing technical checks was not enough

The game's ad-loading button provided a concrete example. Its first version met the technical requirements for dimensions, nine-slice stretching, and a rotating loading icon. It also worked in the game. A visual review still found it too dark.

The next round kept the component intact and added a tighter constraint: preserve the structure, dimensions, and stretching behavior of the button and loading icon, and improve only visibility. The median brightness of the button's visible pixels increased from 83 to 189. The revised version still passed the existing dimension and boundary checks.

An automated check could establish that the button had become brighter. It could not establish that the brighter button belonged in the surrounding interface. In the records used for this article, that version remained a candidate awaiting final visual approval. The game continued to use the previously approved version.

This revision shows the handoff clearly. A person notices an experience problem and decides the scope of the change. AI turns the feedback into executable constraints and produces a revision. Checks establish that the revision has not broken the specifications. A person makes the final decision about using it.

Verification belongs in every round of work

When code and assets can be produced quickly, verification needs to be part of each round. Leaving it until the end of a version creates too much unchecked work.

The first layer is structural: are the files, configuration, asset identifiers, and references complete? The second is runtime behavior: do rule regressions, simulations, and builds show that the system runs as intended? The third is human acceptance: do the controls, visual hierarchy, pacing, device behavior, and platform results meet the goal?

Passing the first two layers establishes consistency within the checks that have been defined. It does not automatically establish that the game is fun, that the visuals are suitable, or that the product is ready to publish. The reverse is also true: “it looks fine to me” cannot replace repeatable checks of configuration and code.

A one-person project can keep moving by automating the repetitive checks and reserving limited human attention for judgments that those checks cannot make.

The result is a production process, not a headcount equation

For an independent project of Kibble Street TD's scale, one person and AI could already sustain a process spanning several roles. Requirements became implementations. Implementations went through checks. The results became constraints for the next round, while playable work continued to accumulate.

That still did not make it equivalent to an established studio. Deep expertise, visual judgment, research with real users, access to devices and platforms, business decisions, and final accountability do not follow automatically from faster generation. One person remains the main bottleneck for direction and acceptance, and bears the cost of poor decisions.

Who is responsible for what?

The person is the product owner: defining goals and priorities, setting the boundaries that must not change, reviewing the experience, and taking responsibility for the final version.

AI is an assistant for production and checking across several roles: reading the current state, translating requirements into work, creating a first draft, running repetitive checks, and organizing findings into inputs for the next round.

Automation provides repeatable observations. It does not make the product decisions for either side.

Five rules to start with

Before adopting this way of working, establish five basic rules:

1. Give each task one clearly defined problem to solve.
2. Write down what must stay unchanged and how the result will be accepted before making changes.
3. Require AI to read the current project facts before proposing an implementation.
4. Leave a small, repeatable check for every nontrivial change.
5. Keep final acceptance of visuals, game feel, device behavior, and release results with a person.

These rules matter more than adding ever more instructions to a prompt. They determine whether AI's output can enter a reliable development process—and whether one person gains the practical capacity of a team, rather than simply producing files faster.