Bounded Chaos

15 July 2026svg]:pointer-events-none [&>svg]:size-3 bg-secondary text-secondary-foreground [a&]:hover:bg-secondary/90">14 min read<br>Bounded Chaos<br>h2]:text-2xl [&>h2]:font-semibold [&>h2]:text-foreground [&>figure]:flex [&>figure]:flex-col [&>figure]:gap-2 [&_figcaption]:text-sm [&_figcaption]:text-muted-foreground [&_img]:w-full [&_img]:rounded-2xl">Most "AI writes your code" demos end right where the hard part begins: the second hour.<br>When a new model comes in, it can draft a feature in one shot. Fable 5, for instance, is<br>capable of building whole games from one prompt! You can open it and play right away. Do you<br>want special assets? Music? Just name it. It's really impressive.

But it's also not the job. Real feature work isn't a cold-start demo; it's the second hour,<br>and the tenth, spent extending a system that already has a shape and opinions.

Without control, boundaries, and validations, a model tends to ignore the<br>spec, skip the tests, and quietly ship the thing you didn't ask for. You can't<br>fix that by trusting the model more. The trouble is structural: an LLM is<br>non-deterministic by construction, and no amount of prompting makes it otherwise.

My workflow makes a different bet: contain, don't trust. The spec and the<br>gates are a containment vessel. The model does real work<br>inside it and can't talk its way past the walls. Every rule I can make<br>deterministic is one less thing riding on the model behaving.<br>The long game is to keep pushing that boundary outward - every gate, every spec, every<br>promoted rule is territory reclaimed from chance.

This post walks the one flow I run for real feature work, end to end. It's a set<br>of skills and review agents that turn a loose intent into a reviewed,<br>shipped pull request. Each phase is another wall of the vessel; I'll walk through what every phase<br>is for and the state machine the work moves through.

The feature flow#

For any work that earns a spec, the whole chain runs in a fixed order. Each phase<br>is a command I run explicitly. Nothing auto-advances. Partly that keeps me in<br>the loop, but there's a mechanical reason too: an auto-advancing chain balloons the<br>context fast (each validation pass dumps its findings into the same session the<br>next phase inherits), and a runaway context means a token blowup, which means a doomed<br>run. So the workflow stops between phases. Continuity lives on disk: every<br>phase starts in a fresh, isolated session and picks up the state the previous one<br>left behind. No single context carries the whole feature from start to finish; each<br>phase is bounded and resumable.

Each command owns one phase of the flow. Here's what every phase is for:

explore - capture requirements, size the work#

This phase runs a relentless "grill" interview to pin down intent. It then grounds that intent in the domain: it updates CONTEXT.md - the project's living domain glossary, the canonical vocabulary the model has to speak - and writes ADRs for the hard-to-reverse, surprising calls. Finally it infers the tier and feature config once, up front (the tier dials are spelled out in The spec config below).

propose - turn intent into a contract#

Here a Security Engineer writes a threat model before any spec exists. The spec.md that follows carries functional requirements, API contracts, a data model, and BDD scenarios.<br>With that in place, we run specialized agents that attack the step from different angles:

Project Manager decomposes the spec into vertical slices - each a piece of work that delivers a small working element of the whole feature.

Test Strategist designs the cross-task test strategy: which test proves which scenario, and at which level - all before any of it reaches implement.

[Human gate] Spec & tasks review<br>:last-child]:mb-0">Before a line of code gets written, I read the spec, the design, and the task<br>breakdown end to end. This is where I catch a wrong contract or a bad slice while<br>it's still cheap - a misread requirement here costs minutes; the same mistake<br>caught after implement costs a rebuild.

implement - build one task, test-first#

This phase builds exactly one eligible task, on its own branch, through a red-green-refactor loop; the next eligible task is picked off the dependency graph - the build order already set in propose. It runs inline or routes to the implementer agent named in the task, driving the task todo → in-progress → implemented and opening a draft PR.

[Human gate] Draft-PR review<br>:last-child]:mb-0">This is the first place in the implementation phase where I stop and read code. I open the draft PR, pull the diff<br>into context, and make sure I understand what the model actually built. At this point it doesn't have to be deep - just enough to grasp the changes made. That's how I'm ready to rule on the validation findings later instead of trusting them blind.

validate - stop trusting one perspective#

This phase runs the deterministic gates and fans out a parallel panel of advisory agents,<br>plus a coverage audit...