The operating system
How I build with AI
The claim on my homepage — platforms built almost entirely by AI agents — earns a lot of raised eyebrows. This page is the honest answer to the follow-up question: how, exactly?
The short version: I run a fleet of Claude-powered agents called J, organized like an engineering team — with roles, permissions, protocols, and a review process none of them can skip. It started as a ticket-to-pull-request pipeline; it now covers the whole lifecycle, from a sentence describing a need to a deployed product with tests and monitoring. The interesting part was never the code generation. It is the process engineering around it: ten years of delivery-process design, applied to agents instead of humans.
I stay the product manager and the engineering lead — on the loop, not in it. There are exactly four places where the work stops and waits for me: the spec, the architecture, the pull request, and the production deploy. Between them the fleet runs unsupervised. I set the standard once and it gets checked every run, instead of me inspecting every line by hand.
The fleet
product
The Product agent
Interviews me about the need, digs into the parts I have not thought through, and writes the spec — testable criteria, and every boundary stated out loud rather than left to silence.
architect
The Architect
Chooses the stack with reasons, records the decisions that are expensive to reverse, and breaks the work into tasks that each carry a command proving they are done. It plans; it never writes what it planned.
implementer
The Implementer
The single writer on a workstream. Turns one task into code and tests, matches the conventions of the surrounding repo, and runs the task’s own check before calling it finished.
reviewers
The Reviewer panel
Independent agents that critique the diff in parallel — correctness, security, consistency, coverage. One of them is blind by design: it sees the diff and nothing else, no plan and no author’s intent.
qa
The QA agent
Compiles acceptance criteria into an executable suite and proves each new test by making the behaviour genuinely break first. It writes tests and never touches source — an author who can change the subject grades their own work.
ops
The Ops agent
Makes a repository runnable before features exist, then ships it and watches it. Every monitor gets verified by firing it, because an untested alert is an assumption.
supervisor
The Supervisor
Watches whole epics end to end — progress, blockers, stuck waves — and escalates only what actually needs a human decision.
orchestrator
The Orchestrator
Routes every request, owns the run end to end — branches, PRs, ticket transitions — and, when review passes and CI is green, merges and deploys under policy.
Roles are enforced, not aspirational: the Planner cannot write code, reviewers cannot push, and nothing merges without a passed panel and green CI. If that sounds like an org chart — that is exactly the point.
From a sentence to production
- 1
A need
Work starts as a sentence, not a ticket. The Product agent interviews me until the hard parts are answered, then writes a spec with criteria a machine can check.
I approve the spec
- 2
Architecture
Stack chosen with reasons, decision records for anything expensive to reverse, and a dependency-ordered task list. Every task names the criteria it satisfies.
I approve the plan
- 3
Bootstrap
Repository, CI, and a dev loop that actually runs — with a deployed walking skeleton before the first feature is written. Each quality gate is proven by breaking something on purpose.
- 4
Build loop
One writer per task, verified by running the task’s own check. Reviewers critique in parallel, and each finding has to survive agents whose job is to refute it before it reaches me.
- 5
QA
Acceptance criteria compiled into tests, plus a sweep for the failure classes machine-written code reliably produces: secrets, unchecked input, authorisation gaps, unbounded work. The pull request arrives carrying evidence, not assurances.
I approve the pull request
- 6
Ship & operate
A deploy behind an explicit authorisation, a smoke test against the live URL, and monitoring verified by firing it. Errors get reproduced as a failing test before anything is fixed.
I authorise the deploy
→ jira2pr TICKET-214 "Add bank-statement import"
planner approach approved — simplest of 2 options
implementer 11 files changed · verify green
reviewers security ✓ · consistency ✓ · coverage ✓
cold-read BLOCK: N+1 query in import loop
refute finding held — 2/2 could not explain it away
implementer fixed — single query with joins
reviewers re-review ✓ ✓ ✓ ✓ — PR ready
orchestrator CI green · policy ok — merged, deployed
supervisor epic on track · nothing to escalateThe rules the fleet cannot break
Every business mutation leaves an audit trail — what changed, when, how, and who triggered it — in the same transaction.
Writes happen in explicit transactions — and background jobs are idempotent: safe to re-run is the default, not a feature.
Status changes are domain commands — valid transitions enforced, history recorded — never a generic update endpoint.
No PR skips the review loop — the panel reviews every change, including the boring ones. Especially the boring ones.
Anti-patterns block automatically — N+1 queries, blocking I/O, logic in controllers — a known list, enforced by reviewers, not by memory.
Docs ship with the code — API contracts, data model, decision records — updated in the same PR or the PR is not done.
Human on the loop
I don’t approve every step — I author the system that makes approval unnecessary: the constraints, the review gates, the merge policy. What stays mine is judgment — which problem is worth solving, what “good” feels like, the call to kill a feature — plus the exceptions the fleet escalates, and the accountability for everything that ships. The loop runs itself; the taste is still the job.