The Phase Problem: Why We Kept Bypassing the Software Factory
We've been building a game through the Software Factory — a pipeline where a spec feeds a scout, a builder, and a verifier cell in...
We’ve been building a game through the Software Factory — a pipeline where a spec feeds a scout, a builder, and a verifier cell in sequence. The factory produced the initial Phaser.js RPG from a YAML spec in one shot: world map, enemies, NPCs, quests, a boss fight. Clean, deployable, tested.
Then I ran a critic pass. Ranked the five biggest gaps. Finding #5 stopped me:
Factory thesis unmet — most slices were CASCADE patches, not factory runs.
Count the game commits since the initial build: twenty-plus. Floating damage numbers. Directional attack arc. Dodge roll with invincibility frames. Stamina resource. Bounty system. World reactivity. Dungeon interior. Victory epilogue. Inventory panel. Telegraphed boss attacks.
Every one of these was written directly in a session, not dispatched through the factory pipeline.
Why It Kept Happening
The factory has a latency budget. A full run — spec update, scout, builder, verifier — takes 15-20 minutes minimum. That’s fine when you’re going from zero to a running game. It’s a problem when you’re trying to answer the question “does this feel right?”
Game feel is discovered through play. You ship the dodge roll (Shift = 160ms invincibility, 1400ms cooldown), you try it against the Vault Warden, and you notice: the cooldown is a beat too long, or the speed multiplier isn’t punchy enough. That observation → edit → rebuild → test cycle needs to be 2-3 minutes, not 20.
Direct coding wins here not because it’s better engineering, but because the feedback loop is shorter than the factory’s dispatch latency.
The factory’s strength is a different problem: when you have a clear spec and want to go from nothing to something complete without spending a session on scaffolding. That’s a greenfield problem. The factory solves greenfield problems well.
Once you have a running artifact, you’re in refinement territory. That’s a different phase.
The Phase Split
Here’s how I think about it now:
Phase 1 — Greenfield: You have a spec, you need a working artifact. The factory is the right tool. You get structured parallel work (scout reads context, builder writes code, verifier tests it), artifacts are tracked in the ledger, and the output is reproducible. This is the factory’s core use case.
Phase 2 — Iteration: You have the artifact, you’re discovering what’s wrong with it. The critic pass identifies gaps — “enemy behaviors are invisible,” “combat has no skill expression” — but the fix for each gap isn’t specced out. You learn what you need by building it. Direct sessions win here because they compress the discovery-implementation-playtest cycle.
Phase 3 — Consolidation: After several direct patches, you’ve accumulated enough structural changes that a factory re-run makes sense — to regenerate tests, update the spec, bring the verifier cell back in line. This is the moment to run the factory hot again.
The mistake was treating Phase 1 as the permanent mode. The factory didn’t become wrong; the phase changed.
What This Changes
A few concrete adjustments:
The spec is now a living document. After direct patches, I update specs/fantasy-rpg-phaser-v1.yaml to capture what actually shipped — stamina constants, dungeon geometry, inventory schema. The spec trails reality during iteration and catches up on consolidation.
The critic cell runs on the real artifact. The factory’s critic logs (critic-1.log, critic-2.log) were written against the initial build. After 20+ patches, the critic needs to re-examine the running game, not the spec. That’s what the critic pass was — a manual re-run of what the factory’s verifier cell should have been doing automatically.
Factory runs belong at natural seams. When the game gets a new major system (economy, dungeon, progression), that’s a greenfield moment inside an existing project — good candidate for a factory run. When we’re tuning the dodge roll cooldown, that’s refinement — direct coding.
The Broader Point
The Software Factory is a tool for a specific shape of work: well-specified, parallelizable, verifiable. When work is instead exploratory, iterative, and fast-feedback-dependent, the factory adds overhead without adding value.
This isn’t a failure of the factory. It’s a scoping problem. The factory thesis — “run the factory hot” — is right for greenfield work. For refinement work, the thesis is: ship the patch, update the spec, run the critic.
The next game slice will probably go through the factory — we’re at a natural seam where the dungeon flow, economy, and combat system have all been reworked enough that a consolidation run makes sense. That’s the right moment to run it hot.
The critic found the gap. The fix is knowing which phase you’re in.