Done Is the Whole Chain, Not the Screen

An AI agent will tell you a feature is done the moment the screen renders. It is almost never true. The button is on the screen, the coins animate, the test is green, and underneath it the purchase granted twice, the save only ever reached the device, or the rank is three hours stale.

I learned this building Tropic Tumble, a real match-3 game I shipped on Android and iOS, mostly with AI coding agents, under JPott Studios. The story of that build, what came fast and what took months, is in how I built a mobile game with AI agents. This is the part I can hand to you as a system: how I decide when something is actually finished, so an agent’s confidence stops being the thing you ship on.

Here is the rule I ended up with, and it is the spine of everything below.

A feature is not done because a screen renders. It is done when a player can use it through the real path, the value flows through the correct owner, the state persists, the backend and support can diagnose it, telemetry explains it, and the build people actually install contains it.

That sentence is the whole article. The rest is how to use it. Here is the whole chain in one box, so you have the map before the walk-through:

#	Link	Done when
1	Entry point	the player can reach and trigger it
2	Owner	a service, not the button, grants the value
3	Ledger / save owner	the grant persists, and once only
4	Backend authority	the server records it, not just the phone
5	Player feedback	the screen reflects what actually happened
6	Support / admin	someone can look it up later
7	Telemetry	a silent failure shows up as a number
8	Regression	a test re-runs the path and asserts it
9	Real-device evidence	you watched it happen on a real phone

Every player action runs a chain

The mistake is treating a feature as one thing that is either done or not. It is not one thing. Any action that touches something a player cares about, a purchase, a reward, a saved level, a rank, runs a chain, and the feature is only as finished as its weakest link.

Here is the chain I check, in order. A purchase in Tropic Tumble is the clearest example, so I have walked one through each step.

1. Entry point. The player taps Buy. This is the only part the agent usually proves.
2. Owner. A purchase service, not the button, validates the receipt and decides what happens. The UI asked; it did not grant.
3. Ledger or save owner. The grant is written where it persists, and it is idempotent, so a double tap or a retry moves the balance once, never twice, never zero.
4. Backend authority. The entitlement is recorded on the server, because the server is the truth, not the phone the player is holding.
5. Player feedback. The coin balance on screen now reflects what actually happened, not what the button hoped happened.
6. Support and admin. A support id can look that grant up later, so when a player writes in, you can answer what really occurred instead of guessing.
7. Telemetry. You can see the grant happened across everyone, so a silent failure shows up as a number, not a mystery.
8. Regression. A test re-runs the path, double-taps Buy, and asserts the balance moved exactly once.
9. Real-device or visual evidence. You watched it happen on an actual phone, through the actual path, not in the editor.

If any link is missing, the feature is not done. It just looks done. The agent can build links one through five and tell you it is finished, and a tester’s instinct is the thing that asks about six through nine. That instinct is the job.

The Treasure event taught me to trust that order over my own first guess. Players were seeing “Event Ended” when the event was plainly still live. The obvious story was a timing or fair-entry bug, a clock that had run out. It was not. The real cause was link four: a stale terminal Treasure state was being carried back in by a cloud restore and a save merge, so the server was handing the player a finished event from an old device. The screen was telling the truth about the state it was given; the state was wrong. I fixed the save merge and the repair path so a terminal state could not resurrect itself, added full restore regressions around it, and wrote down the part I got wrong, which was that my earlier proof had stopped at the UI. Check the backend authority, not the UI story you told yourself first.

Every real bug I chased had this shape: the screen looked done, and one link underneath it was not. A few of them, and where the break actually lived:

Screen looked done	The missing link	What fixed it
”Event Ended” on an event still running	Backend authority: a stale finished state rode back in on a cloud restore	Hardened the save merge and repair so a terminal state cannot resurrect, plus restore regressions
”Claim All” handed over the rewards	Player feedback and end state: mail stayed unread and a false badge remained	Claim now marks the mail read and settles the button, with no unread badge left behind
A coin or reward balance moved	Ledger: a double tap could grant twice	Made the grant idempotent, so a retry moves the balance once, never twice
A leaderboard rank on the screen	Backend authority: the rank was local and never confirmed on the server	Rank now reads from the server, which is the only source of truth

The screen never owns the value

The single rule that keeps the chain honest is this: the user interface requests an action, it never mutates the value. A button is allowed to say “the player wants to buy this.” It is not allowed to add the coins itself.

The coins are added by an owner: a service that validates, grants, persists, syncs, and emits the telemetry. This sounds like architecture pedantry until you watch what happens without it. When the screen owns the value, the screen can lie, and you get exactly the bugs I chased for weeks, a balance that moves twice, a rank that updates locally but never on the server, a purchase that closes the modal without granting anything. The specific scars are in the build log; I will not re-tell them here. The principle is what travels: find the owner before you build the feature, and never let the screen be the owner.

A status that tells you the truth

Because a feature is a chain, “done” is the wrong unit. I stopped asking “is it done?” and started running a small pass that asks where each feature actually is. It turns a vague feeling that something is unfinished into a list you can act on.

Where is this feature, really?	What it means
Decided	The rule exists and is written down, not just in my head
Built	The code runs without crashing
Owned	A real owner holds the value, not the screen
Persisted	It survives an app close, a reinstall, and a second device
Proven	The backend, support, and telemetry can see it, a test guards it, and I watched it on a real phone
Missing	The honest gaps: missing decision, missing owner, missing asset, or a production blocker

A feature that is Built but not Owned is the most dangerous state there is, because it demos perfectly and fails quietly. Most “it’s done” from an agent means Built. The work is everything after.

“Claim All” on the mail screen is the small version of this I keep using as a teaching example. The agent built a button that granted the rewards and reported the feature done. But claiming mail is not only granting rewards. It has to open the mail, mark it as read, and leave the screen in the right end state, with the button settling into its claimed, disabled form and no false unread badge left behind. The rewards landing is one link. A feature is not done when a button renders; it is done when the whole action resolves and the screen comes to rest where it should.

The way I keep links eight and nine from quietly slipping is to refuse to let risk live as a checklist. A checklist is a list of good intentions; nobody runs it under load. So a risk becomes an executable test instead. For the things that scare me most, player state and performance, I had the agent register an audit contract in the docs and back it with quick regressions, so the promise is a thing that runs and fails loudly, not a line I have to remember to honour. The first pass is never tight enough. On a second pass I narrow it, because the first version of a contract tends to assert that something happened without asserting that it happened correctly.

Build in slices, not piles

The chain also changes the order you build in. The temptation, especially when an agent makes features cheap to produce, is to build a pile: a shop, a leaderboard, an event, all half-connected. The honest way is vertical slices, where each slice runs the whole chain before the next one starts.

• Slice one: the loop, all the way through. Start, play, finish, reward, save, return. Not the board, the whole loop including persistence, because a game you cannot leave and come back to is not a game yet.
• Slice two: identity and support. Who is this player, and can you help them when something breaks on their phone?
• Slice three: money. Purchases, only after the core desire actually exists. Monetising a loop that is not fun yet is building on sand.
• Slice four: leaderboards and live ops. Only once score, identity, and validation are real enough that a ranking means something.

Each slice makes the next one honest. I added cloud save because I cared about progress, then purchases because progress meant something, then leaderboards because the game was worth competing in. That order is not an accident. It is the chain, applied to a roadmap.

The one link an agent cannot run for you

Most of the chain, an agent can help with. It can build the owner, write the ledger, add the regression test, read the telemetry, and inspect a fresh screenshot. The link it cannot run is the last one: looking at the real thing on a real device and owning the judgement that it is actually right. A model may flag a button that looks off-centre or a panel that appears to overlap its neighbour, but that finding still needs to be reproduced and checked. The full version of that lesson is in the visual bugs AI missed. For this article it is just the ninth link, and it is the one that stays human.

Why this is the whole game

People talk about building with AI as if the hard part is generating the feature. It is not. An agent will generate features all day. The hard part is knowing when one is finished, because “the screen renders” and “the player can trust it” are two completely different claims, and only one of them ships a product.

The trust chain is how I turned a pile of confident “it’s done” into a game that is actually real on someone’s phone. On one game, that gate is mine to hold. On a team, the same discipline scales up into QA as the control layer over everything an AI generates, which is its own article. It is also why I run agents the way I do, as a studio with a human gate, which is its own story in how I run three AI coding agents like a studio.

So take one feature your agent marked done and walk the chain, link by link. The one that is missing is the work. That gap, between what the agent proved and what a player can actually trust, is the whole job.

An agent’s “done” is a hypothesis. The trust chain is the test. A green screen earns nothing until the chain holds.