The Portal Pattern
How One Non-Programmer Runs Six Engineering Projects
At a Glance
- 350
- lines — the file-size ceiling above which the expensive model may not read
- 30s
- hard cap on a single delegated invocation; larger generations are split
- 2
- enforcement hooks that can actually refuse: check-file-size, check-bash-read
- 0
- lines of code hand-written by the operator across every project in this portfolio
- 4
- classes of work that are never delegated, on principle
The claim
Everything else in this portfolio — a production operations system, a three-month trading workspace, a sealed research experiment, a six-temple interactive atlas, a rebuilt website and a full brand system — was specified, verified and directed by someone who does not write code.
That is not a disclaimer. It is the method, and this is its specification.
The Problem
Frontier models are expensive per token and excellent at judgment. Most of what happens inside a coding session is not judgment. It is shuttling: reading a 900-line file to find one function, restating a specification in a slightly different form, moving text from one place to another. Paying frontier rates to move text is the single largest waste in agentic development, and it degrades output as well as cost — a context window filled with shuttled text has less room for reasoning.
The Routing Rules
Bulk reads are delegated. The expensive model never opens a file over 350 lines. Large reads go to a cheap worker that returns only structured bullets — name-led or line-led, never prose. The expensive model receives a map, not a manuscript.
Targeted reads pass through. A read with an explicit offset and limit goes directly. The rule is aimed at bulk, not precision.
Code generation is delegated. Given a specification and a required reference file, a cheap code-writer produces the code and writes it straight to disk — no fences, no commentary, no explanation. The expensive model reads the result, not a description of it.
The expensive model reasons and edits. It never shuttles text.
What is never delegated
File edits. Worker-reported line numbers are not reliable enough to trust with a mutation. Edits stay with the model that can verify what it is changing.
Reasoning, debugging, architecture, and anything safety-critical. These are the work. Delegating them defeats the purpose of the whole arrangement.
Anything small. A 10–30 second round trip outweighs the saving on a short task. Delegation has a floor.
Anything long. A single invocation is capped at 30 seconds, so large generations are split rather than attempted whole.
Where enforcement lives
Enforcement sits in PreToolUse hooks — check-file-size and check-bash-read — not in advisory instructions. The reasoning is structural: hooks are the only layer that can actually say no. Scripts handle plumbing. Skills are advisory and will be ignored under pressure. A rule that can be talked out of is a suggestion.
The governing principle: frontier-model tokens should only be spent on work that carries judgment.
The Habit That Makes It Work
Routing saves money. It does not produce correct software. The practice that does is a single verification discipline, arrived at independently across every project in this portfolio and stated the same way each time:
Nothing is accepted on report.
- A deployed fix is a fetched, cache-busted, JavaScript-off page — not an agent saying "done."
- A typeface decision is an extracted font from the printed PDF.
- A standards claim is a clause number in the BIS source document, not a secondary article.
- An adherence percentage is what the application computes, never a hand estimate — particularly when the hand estimate was more flattering.
- A rendered InDesign file is one that has been opened on the server and drawn back as an image.
- A measurement tool is verified before its output is trusted. Two such tools were found to be actively wrong mid-build and fixed first: a correlation test asking the wrong statistical question, and a colour classifier fabricating a 48% shadow leak that measured as exactly zero once corrected.
Where an agent, a summary or a first draft disagreed with the evidence, the evidence won.
Multi-Agent Coordination, From Practice
Adversarial review. A second, independent model audits the first one's claimed-complete work. On one repair cycle this produced six release blockers that a passing test suite had missed. The loop only converges once the definition of done is frozen and every new finding is forced through one arbitration question: does it corrupt data, or is it polish?
Concurrent editing. A second agent was discovered mid-build editing the same files with no prior coordination. Protocols developed on the fly and kept since: COORDINATION NOTE headers as a contract channel; TUNING CONTRACT comments protecting hard-won constants from being quietly re-broken; compare-and-swap edit patterns to survive concurrent writes; and a standing merge-over-replace discipline.
Divided ownership. One brief, one codebase, clear ownership: one agent implements, the other reviews at defined checkpoints on a separate branch. Overlapping writes are the failure mode to design against.
Configuration Discipline, Learned the Hard Way
A /doctor health-check session wrote two blocks into a settings file. One disabled thirteen named skills and worked exactly as documented — never the problem. The second disabled six app-delivered plugins, failed to achieve even its own stated goal, and silently took down roughly 150 plugin-delivered skills as an unintended side effect. Ten days of every custom skill failing across every project followed.
The diagnosis is the useful part. A plausible external explanation — a dated platform change in the same window — was investigated and rejected because it was not the cause, however well it fit the timing. The actual culprit was found by direct investigation, and the accountability was taken without hedging: the block had been shipped under a "recommended" label with an explicit caveat in the same report that it might not work.
The rule: a plausible-sounding explanation is not the same as the right one, and a caveat attached to a recommendation is a reason not to ship it.
The Standing Rules
- Frontier tokens buy judgment. Everything else is delegated or scripted.
- Enforcement belongs in hooks. Advisory rules are not enforcement.
- Never delegate an edit, a debug, an architecture decision, or anything safety-critical.
- Delegation has a floor and a ceiling: below ~30 seconds it costs more than it saves; above 30 seconds it must be split.
- Nothing is accepted on report. Only on evidence from the live artefact.
- Verify the measuring instrument before trusting the measurement.
- Every substantial session closes with a checkpoint document and a journal entry.
- Locked decisions are marked "do not re-litigate without reason."
- Rollbacks are named for their failure mechanism, not softened.
What It Demonstrates
The interesting claim is not that AI wrote the code. It is that a specification discipline, a verification habit and a routing architecture can substitute for a development team — and that the substitution is auditable, because every project in this portfolio carries its own decision record, its own bug table, and its own honest list of what remains unfixed.
This case study is the connective tissue of the portfolio. It belongs after the work, not before it — the reader should first believe the artefacts are real, then learn how one person produced them.