Agents do most of the typing. The gates stay human.
Over the last year I built Kanora across seven Apple and Android surfaces with a rotating cast of AI agents, and most of the real work turned out to be the system around them. I'm now extracting that system into Gatehouse, a method and toolkit for building large software estates with AI agents, consistently.
It isn't the code that rots.
Agents write decent code quickly. What goes wrong once there are several sessions, repositories and platforms in flight is the record: which work is in progress, who holds it, what was actually verified, which rule a change broke, and whether anyone independent looked.
Gatehouse keeps that record true while agents do most of the typing. The name is the shape of it, a set of gates a human holds and an author cannot pass alone.
From work item to merge, with four human gates
Every change, from a one-line bug to a new platform, gets a shortcode and runs the same loop. A rejection at review or QA goes back to implementation rather than to the start, so the gates stay cheap enough that nobody is tempted to skip them.
Work item
Intake skill
A shortcode, allocated from every git ref so it is never reissued
Spec
Author session
What and why, with acceptance criteria and marked unknowns
Spec gate
Product owner and design reviewers, then me
Verdict files on disk; I approve the spec, not a summary of it
Plan
Author session
A plan, a kickoff prompt, and one task file per row
Plan gate
Product owner reviewer, then me
Scope is cut here, where it is cheapest
Implement
One session, one worktree, one task at a time
Code and tests, under a lease that says who holds the work
Review gate
Architecture reviewer (and brand, if copy changed), then me
Findings cited by file and line against the constitution
QA gate
QA agent runs the gate itself, then me
GATE: PASS, FAIL or INCONCLUSIVE, with executed counts per leg
Merge
Pull request titled by shortcode
Wiki and log updated as part of done, not after it
A failed review or QA run goes back to implementation, not to the start. The spec and plan already passed their gates, so a rejection costs a fix rather than a rethink.
Author roles are skills loaded into the working session. Reviewer roles are agents spawned with fresh context. The difference is the whole reason the reviewers can be trusted.
Claude Code is the primary harness and Codex runs the same loop natively. Anything that must hold lives in the CLI, git hooks or the gate, not in one tool's settings.
Fresh context, and only one veto
Each reviewer is a separate agent that has never seen the authoring session, and each writes the same verdict file, ending with a section on what it did not examine. Three advise me at a gate; QA is the only one that can block. These are the measured results from one week of Kanora reviews in September 2026.
Product owner
Right problem, right scope, worth doing now.
That rejection killed a week of work that would have rewritten three files a higher-priority programme was about to delete.
Design
Design tokens, platform fit and the visual language.
Each found something real: a raw hex value where a token belonged, six accent icons where the language allows one.
Architecture
The constitution and conventions, cited by file and line.
Advisory by design, so it is judged by whether its notes change the work, not by its verdict field.
QA
Runs the verification gate. The only reviewer that blocks.
A blocking gate is measured by its rejections. This one uses its veto, which is the point of having it.
Five ideas everything else follows from
The record keeps itself.
Frontmatter on each work item is the only thing a person edits. Status pages, kickoff lists and indexes are generated from it and checked against what they would produce now, because a hand-written status page is wrong within a day.
A gate produces a file before it produces a decision.
At a spec gate the file is the spec; at a review gate it is the reviewer's report, on disk with its own shortcode. I decide from the file, never from the author's summary of it.
An author never reviews its own work.
Author roles are skills loaded into the working session. Reviewers are separate agents spawned with fresh context, since the session that wrote a change is the worst reader of its own red run.
Every enforcement has a backstop.
A rule that lives only in one tool's hook protects only that tool's sessions, so anything that must hold also lives in the CLI, a git hook or the verification gate.
Every rule carries the incident that paid for it.
A guard names the day it was earned. A rule nobody can trace is a rule nobody can delete, and the method prunes its own rules on evidence.
Rules with a receipt
The incident log behind the method has 31 entries. A few of them, and what changed because of each.
A gate printed TEST SUCCEEDED after running zero tests.
Every leg of the gate now prints its executed count, and zero executed is never a pass.
Five sessions wrote “verified” about a branch whose iOS target had not compiled for five days.
A leg that didn't build now ends the run as INCONCLUSIVE, the gate writes a run record that reports paste rather than remember, and known failures need an owner and an expiry that no agent may extend.
A cd that didn't land ran git reset --hard in the wrong repository and deleted untracked work.
A guard hook refuses a cd and a destructive command on one line, installed for both Claude Code and Codex sessions.
A repository warning fired 868 times with nothing to act on.
It was deleted. A warning the reader is right to ignore costs more than no rule at all.
From one project's habits to a toolkit
In October 2026 I started pulling the method out of the Kanora workspace into something any project can install. A single gatehouse.yaml describes the project to every command, skill, reviewer agent and hook; the core is a dependency-free Python CLI, packaged as a Claude Code plugin, with Codex supported natively.
The v0.1 acceptance run took an empty repository to a gated, independently reviewed commit in under six minutes. Next is moving Kanora itself onto it, then iOS and Android build-pipeline packs so the same gates cover signing, builds and release.
The clearest evidence it works came before it had a name. The Apple apps took a year. The Android client was seeded on 30 September with the same loop from day one, and within a week I estimated it was about three quarters of the way to the iPhone app. The difference was the process, not the platform.