Fast AI Work Needs a Stop Rule

A fast implementation can leave the important decision untouched.

The code exists. The build passes. There is a screenshot in the report. But should this version reach a user? What does the evidence actually establish? Who decides what happens next?

Those questions become more important when an AI assistant does much of the building. It can prepare another version quickly. That makes it tempting to treat the next step as a continuation of the previous one, even when the next step carries a different kind of risk.

I have written before about the division of work in my Godot projects: Instinct does much of the implementation and testing; I own the direction, the standard and the decision to ship.

The practical question is how to make that boundary useful without turning every small change into a meeting.

My answer is a stop rule.

Separate the work from the commitment

Researching a change, implementing it in a candidate build and releasing it are different decisions.

An assistant can prepare a candidate without deciding that people should receive it. It can run a test without deciding that the result answers every product question. It can propose a fix without deciding that the cost of changing the current version is acceptable.

This is not an argument for asking permission before every line of code. It is an argument for naming the point where preparation becomes commitment.

Before that point, keep the work moving. At that point, require the evidence the decision needs.

A passing test has a limited meaning

The close-call mechanic in Ctrl+Alt+Liberate is a useful example.

In the candidate described in my earlier article, a hostile shot passing near the ship could give a small FOCUS reward. Desktop regression checks covered conditions such as excluding protected passes and preventing the same shot from awarding the reward repeatedly.

Those checks mattered. They did not establish how the vibration felt in a hand, whether a player could read the margin on a phone, or whether the game was balanced for people rather than scripted controllers.

A desktop pass supported the next implementation decision. It did not settle the release decision.

That distinction is easy to lose in a report that says only "tests passed." A better report names the claim that passed and the claim still waiting for evidence.

Write the stop rule before the result arrives

A useful stop rule is specific enough that a team can apply it without another round of interpretation.

For a hypothetical Android release, I would write something like this:

Prepare the candidate and run the regression route. Stop before release if the intended gameplay screen is not visible, if input fails on the target device, or if the device check has not happened. A desktop pass alone does not clear the release.

This is an example, not a report that those checks have been completed on a current build.

The rule gives the assistant room to work. It also prevents missing evidence from becoming a quiet assumption.

The most important phrase is often "has not happened." A missing check is different from a failed check, but neither should be presented as a pass.

Keep a small decision card

I would put five fields beside a candidate change:

• Decision: What are we deciding now?
• Evidence: What observation could change that decision?
• Limit: What does this evidence not establish?
• Owner: Who can make the commitment?
• Stop condition: What blocks the next step?

For the hypothetical release above, the decision is whether to release, not whether the code compiles. The evidence includes the target-device route. The limit is that one successful route does not prove long-term balance. The owner is the person responsible for the release. The stop condition includes an absent device check.

This is a small amount of writing. Its value comes from making the boundary visible before a good-looking result makes everyone impatient.

Stop the wrong next step, not the whole project

A stop rule should leave useful work available.

If the release is waiting for a device check, the assistant can prepare the test route, document the known limits or investigate a separate regression. It should not describe the release as complete or replace the missing device evidence with more desktop runs.

The same principle applies when a test fails. The next useful action may be diagnosis rather than another feature. More output is not automatically more progress.

I want AI assistance to reduce the work I have to carry, not hide the decisions I still need to make. Clear boundaries help with both.

The assistant can do much of the work. The evidence tells us what we know. The person responsible decides what that knowledge is enough to justify.

A note on how this article was made

Instinct helped prepare this article from my published project writing. I remain responsible for what appears under my name.