Whoever writes does not approve

This is the third of five posts in the behind-the-scenes series about Olha o Bichim!. In the previous one, I talked about how the idea becomes a spec. Now, how the spec becomes code.

A programming AI has a flaw similar to an anxious intern's: it says it is done. "10 of 10 tests passing", "implemented as requested", and sometimes it isn't, or it is half done, or it did something else. So the whole execution process for the game was built on a simple premise: whoever writes is never whoever approves.

From plan to commit

After the spec is approved comes the implementation plan, written with the writing-plans skill. It is written for a capable engineer with no context on the project, so each step gives the exact file, the test signatures and assertions, the command to run and the expected result.

The plan for the Asa Branca, the game's level 14, for example, points to the spec ("read before starting") and each task gives the test that must fail and the expected message: Expected: FAIL — Expected: <14> Actual: <13>. A curious detail is that in old versions of Superpowers the plan contained the full code; since 6.4.2 it records decisions instead of transcribing code, because newer models tried to implement the whole project inside the plan. Plans started coming out in a quarter of the time and with about a third of the tokens, with the same result.

TDD: the test comes first

Every task follows the TDD cycle (the test-driven-development skill): write a failing test, write the minimum code to make it pass, and only then improve the code with the test protecting it.

In the game, this is a written rule. The game engine, the pure 2048 logic, is plain Dart, with no Flutter, no Firebase, no input or output at all, and every change to it is TDD, no exceptions. And "fix a bug" means "write the test that reproduces the bug and make it pass". That is why there is the ratio of almost one line of test for each line of code I mentioned in the first post: the suite grows along with the bugs.

One task, agents that don't know each other

Execution uses Subagent-Driven Development, another Superpowers skill. There is a coordinator, which reads the plan and the spec, and each task goes to a new subagent, with a clean context, which receives only the exact text of the task.

The implementer can ask questions before starting, does the TDD, commits, reviews itself and writes a report to a file, returning a status: done, done with concerns, needs context, or blocked. Then another new subagent comes in, the reviewer, which receives the commits and the diff and checks two things: whether the code does what the spec asks and whether it is well built.

There is also a ledger, a progress file that survives when the coordinator's context is compacted. It looks like a detail, but it is documented that the most expensive failure observed was a coordinator losing the thread and re-running entire sequences of tasks that were already done. And the model is chosen by complexity: mechanical tasks go to a fast, cheap model, integration to the standard one, and architecture and final review to the most capable.

The fix loop

If the reviewer finds a critical or important problem, the fix loop kicks in, with up to five rounds.

In the first three, the same implementer fixes it, with its context intact. In rounds four and five, a new implementer comes in, on a more capable model, because sometimes the agent simply can't see its own mistake. Every round ends with a new review focused on the fix, and each finding is marked as addressed or not. "Attempted" is not "fixed". If it still hasn't converged by the fifth round, the coordinator decides and records the decision, the reason and the cost of being wrong. The line from the skill I like best is: "A ruling that dies with the workspace was a decision made in secret."

How the review blocks hallucinations

And here, as I see it, is the heart of the process. The instruction the reviewer receives is literally: "Do Not Trust the Report."

Everything the implementer says is an unverified claim until it matches the diff. Even justifications like "left it that way per YAGNI" are treated as claims and can't be used to downgrade the severity of a problem. The reviewer is a new subagent, without the session's history, so it doesn't have the bias of whoever did the work. It looks for what is missing, what is extra (what nobody asked for) and what was misunderstood (the right feature built the wrong way). What can't be verified from the diff becomes a flagged item, so it isn't made up. And the coordinator is forbidden from "going easy" on the reviewer with instructions like "don't flag this".

Anyone who read my post about hallucination rates understands why I like this so much. The model makes mistakes, and will keep making them; the difference is that here one agent's mistake has to get past another, distrustful agent and concrete evidence (file and line, test output) before it reaches the game.

Our adaptation: one worktree per agent

The original skill says never to dispatch several implementers in parallel, because they would fight over the same directory. In the project, we solved this by giving each parallel implementer its own git worktree and branch. Once the review comes back clean, the commits are brought into the feature branch, and reviewers always look at a range of commits, never the working folder, which may be being touched by another agent.

And after each implementer, regardless of what it said, a mandatory check runs: static analysis of the whole project, a check of the changed files and of anything left untracked. This rule has a written justification: an unused import sat forgotten in a file for several commits, and two dead variables slipped past a file-by-file check. An implementer saying "done" doesn't mean it is done.

The safety net

Finally, underneath all of this, there is the test pyramid: about 1,500 unit and widget tests, more than 95 end-to-end scenarios that run without a device in under a minute, reference image tests (5 screens in 3 sizes) and even a test APK that runs the scenarios on the phone itself and exports a report.

And on every push, GitHub Actions runs static analysis and the tests, and blocks everything if coverage drops below 70%. There were 1,681 commits in six months, and that is only sustainable because this net exists. Tests don't make the project slow; they are what lets you go fast without breaking what already worked.

In the next post, I talk about the house rules: the CLAUDE.md files, which are the project's memory, and a skill called Ponytail, which describes itself as a "lazy senior".