I don't write code, and I don't use "one person plus a chatbot." What actually builds and runs this infrastructure is closer to a small engineering organization: distinct AI roles at distinct skill tiers, a chain of delegation, testers who never wrote the code they test, a documentation function, and an audit function that checks the others. I sit at the top and judge outcomes in plain English. This page is the org chart.
This is an evergreen page: it describes the standing operating model rather than a single project, and it gets updated in place as the model evolves. Prefer the visual quick tour? The method also has its own page, with the org chart up top and links into each deep-dive.
One more thing about the names: the team goes by call signs. Blame the head of Corporate Security. He had one first.
The premise
Every line of code here (a couple dozen web applications, an iOS suite, and a private fleet of infrastructure) was written by AI coding agents. I'm not a hands-on coder; I build by directing, approving, and judging results.
The interesting part is not that AI wrote the code. It's the division of labor that emerged after the naive version (one capable model doing everything) kept failing in specific, logged ways. Nearly every role and rule below exists because something went wrong without it.
The roles
Zach (Pilot in Command): judges outcomes, not code
I approve in plain English or not at all. The standing rule binding every agent: before anything consequential, explain WHAT it does, WHY now, and the IMPACT if it's wrong, in 2–4 jargon-free lines. And if I can't tell what it does from the explanation, that's on the explanation. Certain decisions are reserved to me no matter which agent or machine is involved: anything that changes the shape of the fleet (a net-new service, an administrator credential, a new machine, new cross-machine wiring), any production change, and any metered spend. That rule has an origin story: an agent once stood up a new monitoring daemon and registered it with a hub's admin credential, fully autonomously. Every mechanism it used was permitted, but the composition was an organizational decision it had no business making alone. My own title changed in 2026, from Founder and CEO to Pilot in Command: this has no product and no customers to found a company around, and Pilot in Command is the aviation term for whoever is accountable for the flight, whether or not they're at the controls.
Charlie (Principal Architect): the escalation tier, not the resting tier
Genuinely hard problems (architecture, security decisions, whole-codebase reasoning, ambiguous scoping) escalate to a frontier-tier model, either as a focused subagent or by escalating the whole session. The rule cuts both ways: don't grind a hard problem at a lower tier to avoid escalating, and don't leave the expensive model running as the default. The second half was learned by measurement: one day of running the frontier tier as the default burned 94% of the day's entire output-token budget on ordinary read/search/verify turns that a mid-tier model handles identically.
Rooster (Engineering Manager & Tech Lead): scopes, delegates, verifies (nothing lands unverified)
Sessions run a high-tier model as orchestrator and tech lead. For bulk work, the standing model: the orchestrator scopes the items, parallel executor agents do the work (higher tier for code, mid tier for docs and audits, five to eight running at once), and the orchestrator independently verifies every result before anything is committed or applied. Two non-negotiables: nothing an executor produced lands without verification, and executors never touch gated actions: approvals always flow through the orchestrator to me. In proven runs (7 agents reality-checking ~208 backlog items, a 13-item batch across 12 repositories, a 12-item batch including a critical-infrastructure deploy), the verification pass has caught real executor errors in every batch so far. That track record is the entire argument for the role.
Iceman, Phoenix & Bob (the engineers): tiered by task, like any team
Model routing is codified, not vibes. 18 of the 19 operational skills that wrap my runbooks carry a pinned model tier: 2 on the frontier tier (the quarterly documentation audit, security audits), 9 on the high tier (deployment, incident response, restore drills, and the irreversible production-facing procedures), 5 on the mid tier (documentation updates, session summaries), and 2 on a small fast model at low effort (the mechanical row-appenders). The bulk orchestration skill is the deliberate exception: it used to pin the frontier tier, and now runs on whatever model the session already defaults to, because scoping and verifying a batch turned out to be high-tier judgment, not a frontier-tier problem. Genuinely hard problems still get a dedicated subagent instead of a session-wide switch. The routing principle: small model for mechanical work, mid tier for well-scoped single-concern tasks, high tier for complex multi-file work with a clear spec. Two guardrails against over-delegating: don't hand off work when the handoff costs more than doing it, and anything that might hide a judgment call stays with the orchestrator even if it looks mechanical.
Goose, Warlock & Hangman (the testers): three kinds, none of whom wrote the code
- A user tester: a dedicated, network-fenced machine that logs into my apps with a throwaway account and drives them like a real person. Its first two runs found bugs code review wouldn't: two layout breaks, a missing input validation, and an upload error masking a deeper bug.
- Security testers, two layers: inside-out, a frontier-tier audit skill that assumes the code is public and live-verifies every finding. Outside-in: an isolated black-box tester with no credentials and no source access, physically unable to become a foothold; its first run found an open chatbot endpoint, a leaky test server, and photos quietly carrying GPS coordinates and a camera serial number.
- Code reviewers: automated review on substantial changes, up to a multi-agent deep review for a whole branch.
The separation matters for the same reason it does in a human org: the model that wrote the code is the worst-positioned to find its blind spots. A different model, a different vantage point, a different account: each removes a class of shared assumption.
Viper & Fritz (the auditor and the researcher): two seats hired because the work was already happening
The rule for adding a role is that it must be justified by a logged failure: no failure, no seat. Twelve further roles are cast and deliberately left unbuilt for exactly that reason. Two came off the bench because their work was already being done, just by nobody in particular:
- An internal auditor: pulls facts out of the live systems and diffs them against what the documentation claims, reporting drift and never fixing it. Deciding which version is correct stays with me. Its standing rules are the ones that make an audit worth running: a check that cannot fail is not a check, census the whole class instead of sampling it, and surface contradictions rather than quietly picking a winner.
- A research engineer settles arguments with measurements rather than opinions: model bake-offs, tool evaluations, and prototypes built to answer one question and then discarded. Every result carries its method, its sample size, and what wasn't tested, and it lands in a benchmark file rather than a chat transcript. An evaluation nobody can find gets re-run from scratch in three months.
There's a second reason this pair exists. Both jobs are read-only, which is the only shape a delegated agent can safely take here: anything that touches a gated action stays with the orchestrator, because approvals run to me and only me.
Harvard, Sundown, Hollywood & Chipper (the planner, the search analyst, the editor, and the HR reviewer): four more seats, four more logged gaps
All four were added the same day, after a usage report gave the first real look at whether the crew model was actually being used. It wasn't: the named seats had barely any hours logged against a much larger pile of generic, unnamed agent runs, and every skill invocation on record up to that point had been run by the orchestrator personally instead of handed to a seat.
- A planner writes the plan before multi-step or hard-to-undo work starts, and never implements it. It exists so a plan doesn't depend on anyone remembering to ask for one.
- A search analyst runs broad read-only search across many files and reports where things are, deliberately without judging what it finds. Its first live run overstepped that boundary anyway, answering a locate-only question with a verdict, and had to be corrected by the internal auditor. A useful reminder that a role has to be held to its own boundary.
- An editor reviews and rewrites anything public-facing so it reads in my voice rather than a model's, and owns the standing rule against em dashes in published copy.
- An HR reviewer periodically reviews the crew itself: whether each seat is still earning its place, and whether one should be added or retired. Advisory only; it doesn't act on its own findings.
Fanboy & Merlin (Technical Writer and Knowledge Manager): the org's memory is a repository, not a model's context
Every fact about the fleet lives in a versioned documentation repository: the single source of truth agents must consult before claiming anything. Every session ends with a logged summary; every incident gets a troubleshooting entry; substantial projects become case studies (28 and counting, including this page). That memory is what lets a brand-new session (or a different agent tool entirely) pick up exactly where the last one left off.
The Watch (Site Reliability Engineer): numbered runbooks, executed in order
Deployment, promotion, decommissioning, restore drills, monthly container updates, incident response: all written as numbered phases, announced phase by phase, never skipped or combined. Restraint is an ops decision too: 13 autonomous scheduled-job specifications were built and 10 trialled successfully, and zero are on a schedule. The trials proved quality, but the case for running them unattended hadn't been proven yet, so they wait.
The Inspection (Internal Auditor): the function that checks the other functions
This function used to be called The Debrief; the name moved to a different process, session close-out, because an inspection runs on a calendar regardless of what happened, and a debrief follows an event. Quarterly, an audit re-derives the fleet's documented facts from the live systems and diffs them against the documentation. And after analyzing ~48 logged mistakes across three weeks of sessions, the dominant error class turned out to be subtle: a verified fact delivered next to an unverified adjacent claim, both stated with the same confidence. The fix is a provenance rule: every claim about a system's state carries either the check that produced it or the words "I haven't checked this." The evidence it works: in a truthfulness audit, every claim citing a commit hash checked out, and every false claim was citation-less prose.
Rules of Engagement & Clearance (Compliance and Change Management): the gates
Three approval tiers (a typed approval word for production, a lightweight chat confirmation for fleet-shape changes, a separate typed approval for anything with metered cost) and four absolutes (no local privilege escalation, no pushing to the release branch, no destructive commands, no credentials in chat), enforced in code for the primary agent tool and in binding prose for the rest. The full story is its own case study: Governing an AI Agent With Root on the Fleet.
The Schoolhouse (Executive Coach): the org teaches its owner
The flow isn't one-directional. Teaching-moment explanations get captured into a plain-English "mentor" book I keep: the deliberate mechanism by which I get better at judging outcomes over time. The approver improving is a feature of the org, not a side effect.
Why this shape works (and what it costs)
- Verification is the load-bearing wall. Every batch has caught executor errors; every live-verified security finding survived scrutiny; the citation-less claims were the false ones. Delegation without verification is just hoping, at scale.
- Tiering is an economics decision with a quality ceiling. The expensive model spends its attention on judgment (scoping, verifying, applying), not on search loops.
- Independence is what testers are for. The user-testing and black-box rigs exist to break the shared-assumption problem, not to add more of the same review.
- The org is written down, so it survives sessions. Roles live in files (rulebooks, routing tables, runbooks, skills), not in any one session's memory. A new session inherits the whole org on turn one.
- The cost is overhead. Handing off, verifying, documenting, and gating all take time and tokens. The standing rule absorbs that where it pays (bulk work, consequential changes) and skips it where it doesn't: trivial edits stay inline.
Lessons
- Structure beats capability. The failures that shaped this org were not model-intelligence failures. They were missing roles: no verifier, no independent tester, no auditor, no gate.
- Put the org in files, not in habit. Discipline that lives in behavior regresses; discipline that lives in configuration doesn't.
- Match the model to the task, and write the routing down. "Use the best model for everything" burned 94% of a day's budget on search loops.
- The approver is a role too: invest in it. Plain-English explanation rules and a running mentor book are what make a non-coder a real approver instead of a rubber stamp.
- Every role earns its box by a logged failure. If a role can't point to the failure it prevents, it's ceremony.