This series runs a rule that works against its own author: from the seventh post on, every entry must carry a measurement — including when the measurement disproves what we designed. So far it has disproved it twice. That’s also the shortest description of how the series differs from a typical build log: it doesn’t sell the success, it shows the price of each decision and the failures along the way.
We’re building Forge — an agent orchestrator that hooks into someone else’s monorepo through configuration (it doesn’t live inside it) and drives a ticket from a business request all the way to production, with the developer reduced to a few decisions a day and a human as the gate before every irreversible action. Why the loop should close at production rather than at the PR — and how that differs from what off-the-shelf tools deliver — is what post #1 takes apart. This post is about something else: how we design the whole thing, and the rule we write about it by.
The guiding principle: measurement beats a plan
The entire series rests on one distinction: a claim about quality is worth exactly as much as the gate or the measurement behind it — never as much as an assurance. In the design phase, the rule binds the author: every meaningful decision shows its price as a Trade-off, rather than being sold as free. In the build phase, it sharpens into numbers: a post with a measurement beats a post with a plan, and if a run fails in an instructive way, it jumps the queue — because a failure is better material than a success.
Trade-off: publishing measurements that disprove your own design looks worse than a smooth “it all works” narrative. We pay that price deliberately — a build log without a single failure is an ad, not a report, and the reader will spot the difference on their first real run anyway.
That this isn’t just a claim: the two measurements so far both went straight against the design, and we published them anyway. Post #7 — the tool meant to price the work before the investment needed an investment of its own before it could say anything. Post #8 — the runtime gate passed a static check on a manifest that looked complete, and fell over on the first real boot. Both failures are in the series because the rule lets them in.
The map: two phases, design before code
We don’t start with npm install. The series has two phases, and the first happens before the first line of code:
- The design phase (#1–#6) — from PR to production and why the loop should close there (#1); autonomy as a function of risk (#2); six verification gates rising in cost (#3); Jira as the human interface (#4); a review of our own plan (#5); a confrontation with the industry’s incidents and studies (#6). Decisions with their prices, not verdicts.
- The build phase (#7+) — the measurement rule starts binding hard; #7 and #8 jumped the queue precisely because the first runs on real repositories contradicted the design.
The repo is the single source of truth: posts link to plan.md, architektura.md, and — from #7 — the code under forge/, instead of repeating their content.
Who this is for
Developers curious what designing an agentic SDLC looks like in practice — not a one-prompt demo, but decisions you’ll have to live with, and numbers you have to show even when they’re inconvenient: where an agent’s autonomy ends, how to make quality a gate instead of a promise, and what it really costs to bring someone else’s repo to a state where those gates have something to stand on.
What’s next
The next post moves to the thesis this one only previewed: why the loop should close at production, not the PR — with a buy-vs-build confrontation and the metrics where quality is the gate and time is only the goal.
Bibliography
- Project documents
plan.md(goal, metrics, the ordering of gates and milestones M0–M7) andarchitektura.md(the build order of components) - The series’ first two measurements, both against the design: #7 Repo Readiness Check, #8 .NET Aspire Ports
Leave a Reply