How I write software with LLMs

stavros.io · article · 2026-03-09 source ↗ Reader 🖥️

Agent Harness Agent Planning Artifacts Human-in-the-Loop Multi-Agent Orchestration Supervisory Programming

A solo practitioner can now sustain multi-week, tens-of-thousands-of-line AI-written software projects at a lower defect rate than hand-writing, but only by replacing 'ask one model to do everything' with a fixed division of labor across models (a strong model as architect doing interactive up-front design, a cheaper model as developer doing strict implementation, and one-to-three structurally independent models as reviewers) plus explicit human approval gates -- and only on technology the human already understands well enough to catch bad architectural decisions before the agent compounds them.

practical · mixed — Primarily practical (argues for a specific workflow to adopt), expository in its description of the multi-model architect/developer/reviewer pattern, and narrative in its long annotated real-session transcript that carries most of the concrete evidence.

Structure

Part	Role
The benefits: for the first time, LLM-written code (Opus 4.6 era) has a lower defect rate than hand-written code for the author, without losing system-level understanding, though his engineering skills have shifted from writing code to architecting systems	claim/context
What I've built: a list of real, used-daily projects (a security-focused personal-assistant agent, a voice-note pendant, a kinetic art clock, a multiplayer canvas) offered as evidence against the 'LLMs only make toy scripts' criticism	evidence
The harness: two hard requirements (multi-vendor model support; native agent-to-agent delegation) that rule out single-vendor-locked harnesses like Claude Code, Codex CLI, or Gemini CLI	method/constraint
My workflow: the architect/developer/reviewer role split, hand-written per-agent instructions, the explicit 'approved' gate, and the escalation path when reviewers disagree	evidence/method
Failure modes: unfamiliarity with the underlying technology is the single condition under which the whole approach breaks down, producing compounding, unrecoverable messes	qualification
A real session: a full annotated transcript adding email support to the author's agent, illustrating every stage of the workflow in practice	evidence/narrative

Key terms

Architect
The single, strongest-available model the author personally interacts with via chat; its job is to negotiate goals/constraints/tradeoffs with the human until explicitly told 'approved', then split the agreed design into a low-level, file-and-function-level task plan for the developer.
Developer (agent role)
A deliberately weaker, more token-efficient model (Sonnet 4.6 in the author's setup) whose job is strictly to implement the architect's plan with minimal latitude for its own high-level choices, then hand off to reviewers.
Reviewers (cross-family review)
One to three models, deliberately drawn from different vendors/families than the model that wrote the code, that independently critique the plan and diff; disagreement among reviewers is escalated to the architect rather than resolved by the developer.

Propositions

explicitFor the first time (around Codex 5.2 / Opus 4.6), the author can write software with LLMs at a defect rate probably significantly lower than hand-writing it, without losing the benefit of knowing how the entire system works.conf: high
explicitThe author's own engineering skills have not become useless but have shifted: knowing how to write code correctly matters much less now, while knowing how to architect a system correctly and make the right usability choices matters massively more.conf: high
explicitOutcome quality is gated by the human's familiarity with the underlying technology: on projects the author knows well (e.g. backend apps), code stays maintainable at tens of thousands of lines; on projects he doesn't understand well (e.g. mobile apps), the code quickly becomes a mess of bad choices regardless of model quality.conf: high
explicitAcross LLM generations, the granularity of code the human must review before trusting it has moved upward -- from line level, to function level, to (currently) general architecture level -- and the author speculates (without evidence) that even architecture-level review may become unnecessary within about a year, though 'for now, you still need a human with good coding skills.'conf: medium
explicitA specific model behaves like a person with persistent opinions, strengths, and weaknesses even across clean contexts, so asking a model to review the code it just wrote is close to useless because it tends to agree with itself; asking a structurally different model to review produces a real improvement because it supplies an independent 'second set of eyes.'conf: high
supportsHave your agent record video demos of its work with shot-scraper video · p9 — Both independently describe cross-family/cross-model review as reliably catching real issues that same-model self-review misses, despite initially sounding superstitious.
extendsAgentic AI and Code Reviews · p5 — Where the other document frames adversarial, structurally-independent review theoretically (via the GAN/Zero-Trust analogy), this article supplies a concrete, named production workflow (architect/developer/1-3 reviewers, escalation on disagreement) that instantiates the same principle.
explicitAn effective harness must support multiple vendors' models (ruling out single-vendor-locked harnesses like Claude Code, Codex CLI, or Gemini CLI) and must let agents call each other directly, or the human ends up manually ferrying information between separate LLM sessions.conf: high
supportsThe New SDLC With Vibe Coding: From ad-hoc prompting to Agentic Engineering · p13 — The author's own architect-is-strong-model/developer-is-cheap-token-efficient-model split is a concrete personal instance of routing tasks to different models by cost and complexity.
explicitThe architect agent is instructed to never begin implementation until the human explicitly says the word 'approved', because models left to their own judgment tend to be overeager and start implementing once *they* believe they understand, rather than once the human has confirmed that understanding.conf: high
extendsNew Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets · p9 — Both require an explicit human confirmation gate before implementation begins and treat the pre-implementation conversation as where facts/decisions get negotiated; this article shows the same discipline enforced by prompt instruction and a magic word ('approved') rather than by a dedicated harness skill.
supportsThe AI-Native SDLC playbook · p6 — Both converge on 'no implementation without an accepted plan' as the core safety mechanism, though this article enforces it through agent-instruction discipline in a vendor-agnostic harness (OpenCode) rather than through a specific product's structural plan-mode.
explicitPer-agent instruction files (architect, developer, reviewer prompts) are written by hand rather than generated by an LLM, on the reasoning that asking a model to write its own operating instructions is circular and doesn't actually produce a better agent.conf: high
explicitThe up-front, interactive architecture conversation with the architect model -- sometimes up to thirty minutes of back-and-forth -- is both the most time-consuming step of the whole workflow and the step where the author locates his own authorial claim over the resulting software ('this direction is what lets me call projects mine').conf: high
explicitWhen reviewers disagree with the developer's implementation, the disagreement escalates to the architect rather than being resolved by the developer itself, and the architect is trusted to filter out overly pedantic feedback that is technically correct but low-value in practice.conf: high
explicitThe dominant failure mode is compounding, unrecoverable error: when the human lacks enough domain familiarity to catch an early bad architectural decision, the agent keeps building on top of that decision, and when told the code doesn't work, repeatedly declares it has found the fix and makes things worse rather than escaping the flawed foundation.conf: high
implicitThe author has never read most of the code in several of his shipped, daily-used LLM-written projects, yet considers himself 'intimately familiar' with each project's architecture and inner workings -- i.e. his personal unit of ownership/understanding has shifted from code itself to architecture.conf: medium
implicitThis entire workflow implicitly depends on one human being the sole, continuously-updated holder of architectural context across every change to a given project; the article never considers what changes when more than one human must jointly hold that role, as on a team.conf: medium

Arguments

A durable, trustworthy coding-agent workflow for a solo practitioner requires a fixed, named division of labor across structurally independent models (architect, developer, reviewers) plus enforced human approval gates, rather than one model doing everything end to end in a single session.

Explicit premises:

A model reviewing its own just-written code is close to useless, since it tends to agree with its own prior decisions even from a clean context.
Different models have genuinely complementary, somewhat stable strengths and weaknesses (Codex: pedantic/good reviewer; Opus: decisions that track the author's own judgment; Gemini Flash: creative problem-finding).
Models left unsupervised at a decision boundary tend to act overeagerly, starting implementation once they believe (not once the human confirms) that the plan is understood.

Implicit premises:

A human with strong pre-existing domain knowledge of the target technology is a precondition for the whole workflow's safety -- the system does not actually catch its own architectural blind spots; the human's domain knowledge is the thing that does, which the workflow's framing as a general 'how to write software with LLMs' method understates.
The token/latency overhead of relaying work between an expensive architect model, a cheap developer model, and up to three reviewer models is worth paying, even though the author himself notes this ferrying is 'annoying' without native agent-to-agent harness support.

Inferences:

If review quality comes from structural independence between the drafting and reviewing model rather than from any one model's raw capability, the practice generalizes beyond a solo practitioner's personal taste into an organizational policy question -- i.e. an argument for mandating cross-vendor model diversity in team tooling, which the article never frames as anything beyond individual preference.

Narratives

A full, lightly-trimmed annotated transcript of a real session adding email support (inbound webhook parsing, outbound SMTP, allowlist domain-wildcard matching, an owner-identity bug, a refactor to a shared channel-list constant, and a security fix against an '@'-boundary spoofing trick) to the author's personal-assistant bot, taking about an hour start to finish.
→ Carries nearly every proposition in the piece concretely: the architect's clarifying-questions phase, the explicit-approval gate, the developer/reviewer handoff, the human catching both a design smell (hardcoded per-channel if-blocks) and a security edge case (quoted-local-part email spoofing) that the model missed on its own, and the escalation/negotiation pattern when the human pushes back on the model's first answer.
A list of shipped, daily-used side projects (a security-focused LLM personal assistant, a voice-note-taking pendant, a kinetic art clock with irregular ticking, a multiplayer drawing canvas) that the author says he built without reading most of the generated code.
→ Supports the claim that LLM-assisted solo development now produces real, maintained, daily-driver software rather than only disposable toy scripts, and illustrates the 'architecture-level understanding without code-level reading' claim.

Questions addressed

✅ What specific workflow lets multi-week, tens-of-thousands-of-line AI-written projects stay maintainable instead of degrading into unmaintainability after a few days, as the author says used to happen to him?
A fixed architect/developer/reviewer role split across different models, hand-written agent instructions, and an explicit human approval gate before implementation begins.
⭕ Does this workflow's safety mechanism (a human who understands the architecture well enough to catch bad decisions) survive when the 'human' is not one person but a team that must share that understanding?
Not addressed; the article is written entirely from the frame of a single practitioner who personally holds all architectural context across every change.
⭕ Why does review granularity (line -> function -> architecture) keep moving upward as models improve, and does that trend eventually eliminate the need for the human-domain-knowledge safety net the rest of the article depends on?
The author notes the trend and speculates review may not even need to happen at the architecture level 'next year', but does not reconcile this with his own claim, two sections later, that unfamiliarity with the underlying technology is specifically what causes the workflow's main failure mode.

Gaps

incompleteThe workflow's entire safety mechanism rests on one human continuously holding architectural context across every change ('I still know every choice that was made above the function level'). The article never considers the team-scale version of this: what happens to the approach when more than one human must jointly own that architect role, how plan files or chat transcripts become durable shared artifacts rather than one person's private conversation history, and how disagreement among human architects (not just among reviewer models) would be resolved.
Read next: Look for work that extends a single-practitioner architect/developer/reviewer agent pattern to a team setting with multiple human architects and durable, shared planning artifacts -- e.g. extract-skills-v1-1-wayfinder-flow-skills and extract-claxton-ai-native-sdlc-playbook, which both formalize the plan-then-approve gate as a team-shareable artifact rather than a private chat.
incompleteThe central claim -- a defect rate 'probably significantly lower' than hand-written code -- is entirely self-reported impression with no measurement methodology: no defect count, no time-to-resolution figure, no comparison baseline. This is the same claim that extract-tornhill-borg-code-red-business-impact-code-quality and extract-the-economic-benefit-of-refactoring attempt to quantify rigorously (defect counts via Jira correlation; token cost via a controlled before/after experiment), which this article could be measured against but isn't.
Read next: See extract-tornhill-borg-code-red-business-impact-code-quality and extract-the-economic-benefit-of-refactoring for quantified methodologies this article's central claim could be tested against.
illogicalThe article asserts a trend toward needing less human review per model generation (line -> function -> architecture, possibly disappearing next year) while simultaneously asserting that the workflow's core safety property depends on a human who deeply understands the architecture catching bad decisions before they compound. If review granularity keeps moving upward to the point of disappearing, the same logic implies the human safety net the rest of the article depends on would disappear with it -- a tension the piece never surfaces or resolves.
incompleteThe costs of the prescribed safety apparatus -- up to three reviewer models per change, an architect conversation that can run thirty minutes, and an explicit human approval gate -- are never weighed against the speed/defect-rate benefits the article narrates in detail. There is no accounting of total token spend, wall-clock time, or how the cost/benefit shifts for a less important change where the author says he uses fewer reviewers.