One AI, Three Hats: A Practical Workflow for Better Browser Games

The most useful AI technique I use for small game projects is not a clever prompt. It is a division of responsibility. Instead of asking one AI conversation to invent, build, test, and praise the same feature, I split the work into three passes: Planner, Tester, and Gameplay Reviewer.

WeightPlay uses these as different questions in its development workflow. The same pattern also works for a small website, a prototype, or a side project where one person is wearing every hat. The AI can help with all three passes. The important part is that the passes do not all ask for the same kind of answer.

Why one giant prompt gives cheap confidence

A large prompt often produces a convincing result: a feature list, some code, a test summary, and a sentence saying the experience feels good. The problem is that the same context created the assumptions, wrote the implementation, and judged the outcome.

That is not independent verification. It is one opinion repeated in several voices. Separating the roles creates useful friction. A Tester has to point to an action and an observed result. A Reviewer has to explain why a problem matters to a player. A Planner has to make the original intention clear enough for both of them to check.

Pass one: let the Planner make a small contract

The Planner is not there to generate twenty exciting features. The Planner turns an idea into a small contract that another person can verify.

Ask for five things:

1. Who is the first player, and what should they understand in the opening minute?
2. What is the main loop, stated in one or two sentences?
3. Which states must exist: start, active play, success, failure, and recovery?
4. What are the acceptance checks for the first playable slice?
5. What is deliberately out of scope?

The last question prevents scope from hiding inside enthusiastic AI output. A short contract is more useful than a long brainstorm because the next role can actually use it.

Pass two: let the Tester work from the artifact

The Tester should receive the current build, the exact route or entry point, the version being checked, and the Planner's acceptance checks. The Tester is not asked whether the idea is exciting. It is asked to perform the actions a player would take and record what happened.

A useful test note is concrete: “At a 390 × 844 viewport, the Start button is visible. After tapping it, the first round opens. Choosing the wrong target shows the failure state, and Retry returns to a playable state.” A vague note such as “mobile looks fine” cannot help someone reproduce or fix a problem.

If the AI cannot access a browser, it can still turn the contract into a test script. It must not invent the result. Run the steps yourself, or connect the Tester to a local build that it can actually inspect. Evidence beats confidence here.

Pass three: let the Gameplay Reviewer judge the experience

Once the feature works, the Gameplay Reviewer asks a different question: “Would a player understand the choice, enjoy the rhythm, and want to continue?” This is not a replacement for functional testing. It is a player-centred read of the working experience.

Ask the Reviewer to separate three layers:

• Observation: what appeared, what the player had to do, and where the interaction slowed down.
• Interpretation: what that moment may mean for clarity, pacing, or motivation.
• Recommendation: one change that could improve the next version, with a reason.

This separation matters because one play session cannot prove what every player thinks. It can reveal a confusing instruction, a dead moment, or a satisfying recovery. Treat those as evidence and hypotheses, not as invented user research.

Keep the handoff smaller than the project

The technique becomes practical when each role gets a small handoff instead of the entire repository or a huge conversation history:

Idea
  ↓
Planner brief + acceptance checks
  ↓
Current build + Tester evidence
  ↓
Gameplay Reviewer observations + next recommendation

You can use three separate AI chats, three saved prompts, or three explicit phases in one session. Label the phase clearly. Give the Tester the build and the checks, not the Planner's confidence. Give the Reviewer the tested experience and the evidence, not a request to approve the original idea.

A reusable role prompt

Start each pass with the same short frame and change only the responsibility:

You are the [Planner / Tester / Gameplay Reviewer].
Current artifact: [local URL, feature, or version]
Your question: [the one question this role must answer]
Use only: [brief, build, or observed evidence]
Return: facts first, then risks, then the smallest useful next step.
Do not claim a check happened unless the evidence shows it.

The final line is easy to overlook and does a lot of work. It stops a language model from turning an expected result into a reported result.

What AI still cannot own

AI can help write the brief, generate a checklist, compare observations, and suggest a next experiment. It cannot decide whether an unmeasured assumption is safe enough to ship, whether a privacy boundary is acceptable, or whether a trade-off matches your product. Those decisions still belong to the person responsible for the project.

For the next small feature, try three short passes: a Planner brief, a real Tester run, and a separate Reviewer read. If the answers disagree, do not average them into a nicer sentence. Find the missing evidence or make the decision explicit. That is where the three-role technique becomes more than prompt theatre.

This article was outlined with AI assistance and then checked and edited against the actual WeightPlay development workflow by the WeightStudio team.