Software factory pattern: agents plus deterministic code

Step-by-Step Breakdown

1. Start from three design principles: observable, customizable, reusable

   Observability comes first — "if you can't measure your agents, you can't improve them." Every workflow run is viewable in a swim-lane view showing each phase, the compiled system and user prompts, the agent config, the tools that were available, the coding agent and harness used, and a per-phase cost breakdown. The point is that you can only improve a system you can inspect after the fact.

2. Give the factory agentic access rather than driving it by hand

   The system can be operated manually — there are plain commands for the plan and build workflows — but he drives it through an orchestrator agent instead. He fires up a coding agent running Opus 5 inside a terminal multiplexer (he has moved from tmux to Herder), and the agent lazy-loads the rest of the skill's context before kicking off a workflow. He frames this as one of the pillars of agentic engineering: "if you're doing something you can teach your agents to do, why aren't you?"

3. Run the smallest unit — the scout workflow

   A two-phase workflow: a request comes in, one scouter agent runs. The prompt is "break down what this app is, its features, and suggest three new features to enhance the application," plus a definition of done. It runs on Gemini 3.6 Flash, which he classes as his A-tier workhorse at roughly $1.50 in. The orchestrator also rewrites the incoming prompt to be clearer and more concise before dispatching it — prompt enhancement is engineered into the factory itself.

4. Step up to a plan → build → test workflow

   The prompt: "Add light mode to contrast with dark default. Build a design system such that we can add other themes in the future if we want." The planner runs Kimi K3 (served through Fireworks); the builder runs Gemini 3 Flash and implements what the plan specified. Two deterministic code checks run after the build. If a check fails, the work routes back to the build agent to correct — the failure loop is code-driven, not agent-judged.

5. Make the handoff between phases deterministic and typed

   Phases hand off through a shared ADW sessions directory. Agents must emit JSON that is formatted and validated against a required structure — if validation fails, the agent has to produce it properly before the workflow advances. The planner also leaves a note for whichever agent comes next, so the builder's user prompt arrives carrying the previous envelope: the task, the plan, and the expected report format. "Determinism is wired into every one of my agent steps."

6. Run the full software development lifecycle with the state-of-the-art roster

   The prompt asks for a side-by-side markdown viewer with a toggle, covered with tests, and adds one extra instruction: "use the state-of-the-art configuration for this work." The agent researches the system, confirms the roster from a frontier config, and runs the full phase chain: plan → commit plan → build → test → fix on failure → review → revise on failure → document → commit docs. Claude Opus 5 plans; a review agent asks the single question "is what we built what we asked for"; the final step diffs the changes to document the work for the next set of agents.

7. Read the workflow code — it is deliberately small

   An adws/ directory holds the end-to-end workflows. The full SDLC, the largest one, is about 180 lines of Python. Each phase is delimited by a with statement marking entry and exit, and every step is tagged by kind — engineer, agents, or code — so the split between what an agent does and what a script does is explicit in the source and legible to the agents operating it.

8. Configure every agent through the "core four"

   A single YAML config file defines each role by context, model, prompt, and tools — "if you match the core four, you'll master the agent." The planner entry names its model and provider, sets thinking to high, states its purpose, carries its system and user prompt, and specifies its agent harness. Harnesses are per-role: he has enabled sub-agent support on the planner and on the scouter, so those agents can spin up their own sub-agents while others cannot.

9. Install the factory into another codebase

   Everything is wrapped in one skill. Alongside the core instruction there is a cookbook of lazy-loaded recipes — set up the factory in a new repo, create an ADW, modify an ADW, create the config, set up a new agent roster — that the agent loads only when the matching request comes in. Clone the repository and run /install; the agent copies the system into the target codebase from a set of templates. He is explicit that the shipped defaults are a starting point: "the tests I have set up here are not the tests you need."

Commands & Code Shown

/install

/install

Purpose: Runs the install workflow from the software factory skill — the agent copies the ADW system, the config, and the templates into the current codebase.

When to use: Once per codebase, after cloning the factory repository, to deploy the workflow system somewhere new. Customise the config and the checks afterwards; the defaults are scaffolding, not a finished setup.

The rest of the video is a screen walkthrough of a running system rather than a terminal tutorial, so there is no longer command list to reproduce. The workflow roster he demonstrates — scout; plan; build; quality check (lints, formats, type checks); documentation; and the composite plan-build-test, build-review, and full SDLC workflows — is presented through the orchestrator agent rather than as CLI syntax.

Gotchas & Caveats

• The demo runs on the main branch, and he says not to copy that. A real deployment wants the agent on its own branch, isolated in a sandbox, with a merge step at the end. He flags this as the most obvious thing missing from what he showed.
• This is over-engineering at small scale, and he says so first. The light-mode feature could have been done by a single agent in one shot. The payoff arrives at the hundredth and thousandth run, when validation becomes the only way to keep a large system moving — not on run one.
• Don't push everything into agents and skills. His warning is that you pay for it later in cost, speed, and performance, not only in mistakes. His example: there is no reason to feed passing test output back into an agent's context window when a deterministic code path can check it and only escalate failures.
• Stay "in distribution." No custom DSL. The system is Python, YAML, agents, and a skill — formats the models are already trained on. The only bespoke surface is the config file.
• Still read the critical path of your own code. He does not read the whole codebase, but he does read the essential parts — and argues the more you productionise something that will re-run repeatedly, the more you need to understand what it actually does.
• Model rankings in the video are his subjective read. He says he still prefers Fable 5 over Opus 5 for critical work while acknowledging the benchmarks disagree with him, and invites viewers to push back. Treat it as one practitioner's feel, not a measurement — see our benchmark aggregation for published numbers.

Key Takeaways

• A software factory exists for exactly one reason: leverage on your prompt. How much leverage you get is determined by how much you invest in the workflows, which is why he treats the ADW layer as the real product rather than any individual agent.
• Agents plus code beats agents alone. Code is deterministic, effectively free, runs instantly, and — his sharpest point — you actually own it. Models are rented. Anything that can be a validated code path should be one.
• Observability is the precondition for improvement. Compiled prompts, tool lists, agent configs, and per-phase costs are all inspectable after every run, because a system you cannot measure is one you cannot iterate on.
• Think in model stacks, not in a single best model. Cheap workhorse models handle building, stronger models plan and review, and each role is a separate cost, speed, and performance decision. "The best engineers now are building systems of agents. They're not debating which model is the best anymore."
• Configure agents by the core four — context, model, prompt, tools. One YAML file per factory, one entry per role, including a per-role harness that can grant or withhold capabilities like sub-agent spawning.
• Typed handoffs and deterministic gates between phases. Agents emit validated JSON; failed checks route work back to the responsible agent rather than letting a bad phase pass downstream.
• Build the system that builds the system. The factory is packaged as a skill with a cookbook and an /install command, so an agent can deploy and operate it — the meta-move he expects to define the next phase of agentic engineering.