I tend to move quickly when an idea clicks. The interesting question is whether the software underneath it is keeping up.
When I first started using Fable, I pointed it backward: review the codebases of past projects, find the gaps and holes, and help me figure out what needed attention before slotting in more work and “the next big thing.” My portfolio needed to hold up. Client work needed to be robust. The next feature was going to inherit whatever decisions were already sitting underneath it, whether I had thought about them recently or not.
I already had a primitive division of labor going. ChatGPT was where I worked through game ideas, content, and planning; Claude handled engineering. That split was useful, but I was still developing a way to scrutinize the work as deliberately as I generated it.
When Astra came out and I saw the benchmarks, something clicked. What if I brought that level of scrutiny into each bounded unit of work, while the decisions were still fresh? I could catch potential problems closer to where they entered the system, before they accumulated into a codebase-wide cleanup exercise.
Robo Grower became the proving ground. Its combat engine gave me something substantial to build brick by brick, with enough moving parts to make vague definitions of “done” expensive.
The structure I arrived at is:
There are correction loops inside that shorthand, and the broader audit happens at a meaningful milestone. I still make the consequential calls. Having an intellectual teammate that can move at my speed is exciting. Giving that speed a structure is what makes it useful.
Read the diagram as text
The human builder sets intent, constraints, delegated authority, and consequential decisions. The Command Center sends a bounded assignment to the Implementer, who sends the exact candidate and evidence to the Reviewer. The Reviewer returns defects or evidence gaps for correction and reports its verdict to the Command Center. Any role routes ambiguity, contract conflicts, or scope changes back to the Command Center. At a milestone, the Command Center sends the completion contract, candidate, and accumulated evidence to the Completion Auditor. Audit findings return to the Command Center. Corrections go through the slice loop before affected audit claims are checked again. The human builder then accepts, revises, or holds the milestone; release requires a separate human authorization. A pass applies only to the exact candidate and stated scope.
Giving each role a clear job
The Command Center holds the project’s intent and current state: architecture, scope, decisions, acceptance criteria, and what is authorized next. It needs to know why a boundary exists, not just remember that somebody drew one. Otherwise, the next conversation can quietly reinterpret a decision that took real work to settle.
The Engineer or Implementer receives a bounded assignment, makes the change, and returns a specific candidate with validation evidence. What changed? What ran? What remains uncertain? The stopping point belongs in the assignment, because “while I’m here” can become a surprisingly large engineering department.
The Reviewer examines that candidate against its requirements. That includes interrogating the tests themselves. A green result tells me that the implementation satisfied the checks we wrote; I also want to know whether those checks would reject a plausible wrong implementation. There is a lot of engineering hiding in that second question.
The Completion Auditor zooms out to the larger unit of work. It checks whether the full contract has been covered, whether the pieces interact as intended, and whether the accumulated evidence supports calling the milestone complete.
My shorthand is that the Reviewer checks the change and its proof; the Completion Auditor checks the completion claim. A series of individually sound changes can still leave an awkward gap between them. Somebody has to look at the seams.
Those roles organize scrutiny. They also make the next decision legible: correct the candidate, resolve an ambiguity, gather missing evidence, or bring a product decision back to me. Nobody gets to expand the assignment simply because the adjacent problem looks interesting.
What brick by brick means in practice
Robo Grower’s agreed combat-engine plan separates target selection, intent, resolution, damage, defeat recognition, participation, and outcome. That is our architectural sequence; we are building and verifying it one stage at a time.
Consider defeat recognition. Its bounded question is whether Integrity crossed from a positive value to zero. Deciding who won the encounter belongs elsewhere. So do decisions about whether a unit remains targetable or gets another scheduled action.
That sounds almost excessively specific until you picture all those concerns creeping into one convenient function. Soon, recognizing a defeat also changes targeting, alters turn order, and declares victory. A small change now carries assumptions about half the combat engine. Good luck reviewing that as a single, tidy behavior.
With the boundary explicit, implementation and review have something precise to work against. Does the candidate recognize the required transition? Does it avoid taking responsibility for downstream decisions? Can the next stage consume its result without guessing what else happened behind the curtain?
The rhythm becomes manageable: define the unit, implement it, challenge it, address the findings, and decide whether it can advance. At the appropriate milestone, the audit checks how those units fit together.
I can follow that sequence mentally as the project grows. That matters. A solo builder needs to retain a coherent picture of the system while moving between design, implementation, and whatever else the day has decided to throw into the mix.
The handoff is part of the work
A handoff is where context either survives or starts quietly evaporating. “Implemented and tested” is a pleasant update, but it leaves the next role with a lot to reconstruct.
I want the handoff to identify the exact candidate, the behavior it is responsible for, its exclusions, the acceptance criteria, the checks actually performed, and anything unresolved. It should also be clear who makes the next decision. A commit or build identifier is useful here because evidence needs an address.
The implementation instruction can stay compact: complete this unit against the agreed requirements, report the candidate and validation results, disclose limitations, and stop at the boundary. The review then challenges both the implementation and the evidence. Findings need enough detail to reproduce or investigate, rather than leaving the implementer to interpret a vague expression of concern.
Corrections produce a new candidate. The relevant checks must apply to that corrected version; an earlier pass cannot simply hitch a ride through subsequent edits.
At a milestone, the audit gets the wider contract and accumulated evidence. Technical completion and human acceptance remain distinct decisions. I still need to judge scope, product behavior, and whether I am prepared to ship. A technically clean result can be ready for my review while still waiting on my answer.
What the checks can reveal
One mobile-game review made the value of this concrete. A suite with 883 passing checks accepted two deliberately wrong implementations. The production code had no demonstrated defect in that finding. The weakness was in what the tests could prove.
That changes the work. Fixing a production bug that has not been established would chase the wrong problem; strengthening the tests addresses the actual gap. The correction touched five test files, preserving production code. Fresh review confirmed 887 passing checks and detection of all 365 deliberately altered variants, including the two that had escaped. The verdict still retained a documented statistical caveat about false alarms.
A marketplace project exposed a different problem: stale capacity counts after a refresh failure. The correction received a limited recheck. That gave us a basis for the specific fix, while the broader release still needed its own evidence. In a Unity module, the technical completion audit similarly remained separate from human acceptance.
These distinctions can look fussy on paper. They become much less fussy when you are deciding what to change next, or trying to remember exactly what you agreed was ready.
Keeping the limits visible
Separate agents can share the same mistaken assumption. Assigning a Reviewer role does not magically produce an independent perspective, and a Completion Auditor can miss things too. The responsibilities help direct attention; the quality of the scrutiny still has to be earned.
There is also a subtle reporting problem: a narrowly scoped pass can lose its qualifications as it travels through summaries. By the third retelling, “this correction passed these checks” can start sounding like “the project is ready.” Keeping the candidate, scope, and evidence together helps prevent that convenient little promotion.
All of this has overhead. Requirements take thought. Handoffs need care. Findings sometimes reopen decisions I would rather have finished. I want the depth of review to match the consequences of being wrong, so the workflow supports momentum instead of consuming it.
For another solo builder, I would start with one bounded feature or module. Define its behavior and exclusions, give implementation a stopping point, and require evidence at the handoff. Let the correction loop do real work. Then check the broader completion claim when enough pieces exist for that question to matter.
I expect this practice to keep evolving. Refactoring will still happen; judgment will still matter. What I gain is a way to move quickly while keeping the decisions inspectable, and to ask a much more useful question than whether an agent sounds confident: what do I actually know about this version before I authorize the next piece?
Pretty normal operating rhythm for me at this point. Which is kind of ridiculous.
