Does a Governed SDLC Beat a One-Shot? An Isolation-Lab Study of Coding Agents

PromptOwl / ContextNest · SDLC Isolation Lab · August 2026 · model: moonshotai/Kimi-K2.7-Code via OpenCode, in Docker

Thesis. A one-shot prompt to a strong coding model produces something that looks finished; a governed, context-isolated software pipeline — where each role gets only what it needs and a verification loop closes the gap — produces something that works. We built a lab that runs the same vague request three ways (raw one-shot, leaky all-context-in-one-dir, tight isolated roles) and tested it on two tasks. On a trivially simple task (Minesweeper) the arms barely separated — a single shot can hold the whole thing in its head. On a real business app (a service-company invoice/quote builder) they separated sharply: raw shipped an impressive-looking app that doesn't save (no test/eval stage ever checked it); tight shipped a right-sized, working, 22-test, product-reasoned app whose eval loop caught and fixed its own failures. The process tax is small in dollars (~$0.30) and large in time — and it buys the difference between "loads" and "works."

1. The lab

Every run gives three arms the identical vague one-liner and the identical model; only the context discipline differs:

raw — one prompt, one shot. No stages, no standards, no verification.
leaky — the same multi-stage pipeline, but every stage runs in one shared directory and receives all context unfiltered (every standard, every prior artifact). Maximal bleed.
tight — each stage/role runs in its own directory and receives only its declared inputs plus its one governing standard. Real isolation, with feedback loops.

Everything runs headless in Docker; every deliverable is render-verified with a real browser, and cost is measured cost-faithfully (see §5).

2. Experiment 1 — Minesweeper (the null result that taught us the method)

"Build a better Minesweeper that people love."

Minesweeper fits in a single context window, so a one-shot can basically hold the whole task. The arms did not cleanly separate, and that itself was the finding: process has nothing to save you from when the task is small. After several tuning iterations the tight arm produced a clean, tested game — but so did raw, most of the time.

▶ Play the governed pipeline's Minesweeper: wiredcognition.com/demos/minesweeper — or see all three arms side by side. Every screenshot below is a real headless render of the live build.

minesweeper gameplay — The governed pipeline's Minesweeper, running liveplayable — click to play it right here: flood-fill, colored numbers, difficulty presets. (This is the unedited build; in print it becomes a screenshot.)

arm	plays?	files	tests	real cost	note
raw	yes	1 (monolith)	0	~$0.09	high run-to-run variance
tight (tuned)	yes	9 modules	42	~$0.28	polished, difficulty presets
leaky	no	—	—	—	cross-module export mismatch (`GAME_STATES`)

tight minesweeper Kimi — Tight (Kimi), liveplay — classic board, colored numbers, presets.

tight minesweeper Glimmer — Same recipe, dirt-cheap 30B, liveplay — still works.

model comparison — Fig 4. Model swap on the same recipe.

three arms side by side, live — The live exhibit: all three arms (two models) running side by side, each in its own frame, with the full stat line per tile — wiredcognition.com/demos/lab.

2.1 The model sub-study: capability, not price, decides

Holding the recipe fixed and swapping the model exposed a sharp rule. A cheaper but tool-capable coder (Muse-Glimmer-30B) drove the whole pipeline and shipped a working game for the same ~$0.30 as the flagship. A cheaper general-instruct model (Llama-3.3-70B) chatted instead of writing files, produced no game, and — because it got no prompt caching — cost $1.85 (6.6×) for zero output. Lesson: the recipe amplifies a model that can do agentic tool-use; it cannot rescue one that can't. "Cheaper per token" is a trap when the agentic loop can't cache.

3. Experiment 2 — A service-company invoice/quote builder (the real test)

"Build a quote-and-invoice app that a service company — like a flooring contractor — would love: measure the job, list materials with photos, add labor, produce a clean accurate invoice."

This is real software: multiple interacting subsystems, money math with edge cases (waste factor, taxable-vs-non-taxable, rounding), photos, persistence, printable output. It overflows a single shot. For this experiment the tight arm ran a full role-based pipeline (Product-Marketing → Red-Team → Designer ⇄ Design-Research → PRD → Developer ⇄ Eval), with two capped feedback loops. This is where the arms finally told the story.

arm	outcome	LOC	files	tests	real cost	time	verdicts
raw	shiny, doesn't save	1,914	15	0	~$0.15	~4 min	none (no eval)
tight	works + tested	2,842	12	22	~$0.44	~54 min	all 3 yes
leaky	math ok, UX broken	1,653	3	36	~$0.14	~12 min	—

3.1 raw — impressive and broken

The one-shot reached for a heavyweight React + TypeScript + Express + SQLite monorepo (it needed npm install + tsc + a Vite build + a running server just to open). It renders a beautiful quotes table — and saving is broken. With no eval or test stage, nobody ever checked whether it works; it only had to look done. This is the "loads ≠ works" gap, shipped.

raw invoice app — raw — a polished quotes/invoices UI (React+SQLite). Looks great; save fails.

3.2 tight — right-sized, working, product-reasoned

Both raw and tight correctly concluded the app must be dynamic (a real invoice tool needs a backend for photos, persistence, and shareable customer links). But tight right-sized that requirement to a zero-dependency Node server (only http/fs builtins — npm install installed nothing) plus a vanilla client. Its Product-Marketing stage surfaced a genuine insight — "homeowners approve faster when they see who they're hiring" — which became a "Company & trust info" onboarding (license #, insurance). Its eval stage started the server and ran a scripted end-to-end test (create a quote, 16'×12' room @10% waste → 212 sq ft, signature approval, price list); the Developer⇄Eval loop fired (round 1 flagged failures, round 2 fixed them, round 2 passed). Result: a working, 22-test app for ~$0.44.

tight invoice app — tight — "FloorQuote", zero-dep dynamic app, render-verified, eval-passed.

A closer look at the tight build's actual screens — each one shows a product decision the governed pipeline reasoned its way to, not a default:

tight onboarding, company and trust info — PMM-reasoned onboarding: license #, insurance, warranty — *"homeowners approve faster when they see who they're hiring."*

tight new quote form — New quote: customer, site vs bill-to address, a quote-expiration date ("lock the price"), per-quote tax rate.

tight room measurement — Live measurement: 16'×12' = 192 sq ft, Good/Better/Best material tiers, waste %, per-room material subtotal.

3.3 leaky — the bleed shows as broken UX

With all context in one dir, leaky produced a coherent-looking single-page app whose math is correct (174.92 sq ft → $1,519.57) but whose line-item UI is garbled — overlapping, colliding labels. Isolation is what keeps a stage's concerns from smearing into the next; without it, the surface degrades even when the logic is right. (Note: an earlier leaky run was contaminated by a harness bug that hard-coded filenames into its prompt; once fixed, the bleed still showed — as UX rot, not contamination.)

leaky invoice app — leaky — correct totals, but overlapping/garbled Materials line-items.

4. Empirical results

The dominant cost of the governed pipeline is time (~54 min vs ~4 min): seven roles and two feedback loops mean ~11 model calls. The dollar difference is modest (~$0.30) — small next to the quality delta (a working, tested, product-reasoned app vs a broken shiny one).

5. Principles the lab produced

1. Process depth is a computed output, not a constant. Decompose the request to first principles: flat-apply what's solved, and spend cognition only on the irreducibly uncertain (e.g. "what does better mean here?"). We twice mis-set this as a constant — first as maximalism (a 10-module Minesweeper; a 1,420-file Vite monster), then as dogma ("always a single static HTML file"). The stack and the effort must be derived from the requirements.

2. The verification loop is the value. "Loads" is not "works." Unit tests on a pure core pass while a page is dead; a one-shot ships bugs it never checks. The tight arm's eval gate that actually runs the app end-to-end, and loops back to the developer, is the single change that most separates it from raw.

3. Right-size the stack from context. A real app may legitimately need a backend; a trivial tool needs one file. Neither gratuitous scaffolding nor dogmatic minimalism — the architecture stage decides and justifies. Tight's zero-dep server vs raw's SQLite monorepo, for the same requirement, is the clearest illustration.

4. Model tool-use, not price, decides — and caching dominates agentic cost. A cheaper coder can match a flagship; a cheaper non-coder can cost 6.6× and produce nothing. Prompt-cache behavior swamps nominal per-token price in an agentic loop.

5. Measure cost faithfully. The obvious token counter (tokens.total) is running context-window size — ~99% cheap cache-reads — not spend. Reporting it inflates cost 10×. Sum billable input+output (+ discounted cache) instead.

6. Isolation prevents bleed. Shared-context stages smear concerns into each other; leaky's correct math still shipped a broken UI. Give each role only what it needs.

6. Limitations & honest caveats

N=1 per cell. Single draws; raw's architecture is a coin flip (across three invoice runs it built a Vite monster, a tidy static app, and a client/server monorepo — same prompt).
tight still ships UX bugs. Its eval caught functional/save failures but over-graded polish (DESIGN_AWESOME: yes while real UX bugs remained). The eval/design-research standards need to hunt UX defects specifically — a concrete next tightening.
Time cost is real. ~54 min/run makes the loop slow to iterate; caching upstream stages would help.
Process bugs are our bugs. An early "leaky leaked Minesweeper files" claim was a harness bug (hard-coded filenames), not emergent bleed — caught and corrected. Verification discipline applies to the experimenters too.

7. Conclusion

On tasks small enough to fit one shot, skip the ceremony. On real software, a context-isolated, governed pipeline with a closing verification loop turns "looks done" into "is done" — for a modest dollar premium and a real time premium. The one-shot's ceiling is high and its floor is the floor; the process trades a little of the ceiling for a dependable floor, a paper trail, and the difference between an app that renders and an app that saves.

Reproducibility: all three arms, both tasks, run headless in one Docker image (ContextNest CLI + OpenCode + Kimi via Together). Every figure is measured from run logs; every screenshot is a real headless render. Live exhibits: the three-arm Minesweeper gallery and the playable tight build.