How I work

I lead the frontend of a multi-tenant real-estate platform, and I deliver most of it through AI agents running under a written harness. The agents write code — but the deciding happens first, and it happens on paper.

Why this exists

I did not set out to build a process. I work from thin designs and few direction points, and I set the direction myself — the notes come after I present, not before I start. That gap turned out to be the thing that made me an engineer worth hiring: filling it well is a skill, and filling it repeatably requires a system.

So I built the system I needed. Everything below exists because something went wrong once and I did not want it to go wrong again.

The pipeline

Five stages. The first four are specification; only the fifth is code.

1 — Grill the problem. Before anything is written, I interrogate the goal: what is actually being asked for, what is assumed, what happens if we do nothing. Most of what I cut gets cut here, when cutting is free.

2 — Write the master priority document. One file a cold reader can pick up and run the next wave from: the decisions and why, the phases, the file-ownership map, the traps. It is append-and-mark — superseded decisions are struck through with the date and the reason, never deleted. A reader who acted on the old plan has to be able to see that it changed.

3 — Cut tickets. Each one carries its finding in the title and its receipts in the body. This is where “what gets built” stops being a conversation and becomes a contract. Three tickets I filed against my own portfolio are a fair sample of the shape.

4 — Set the fence. Which files each lane owns, which it must never touch, and which shared manifests have to be serialised rather than parallelised. Two lanes run at once only if their rows do not intersect.

5 — Dispatch waves, then review every one. Agents work inside the fence and hand back. Nothing lands without a review pass. The working agreements are public.

The agents are the fast part. Stages 1 to 4 are the part that decides whether the fast part was worth doing.

The rules that make it safe

Four invariants, and I have not found a way to drop any of them without paying for it.

  • 01

    Two-axis review before acceptance

    Every change is checked against the repo’s documented standards and against what the originating ticket actually asked for. Passing one axis and failing the other is the most common way AI-written code goes wrong: correct code, wrong problem.

  • 02

    A capability guard decides autonomy

    Whether a lane runs attended or autonomously is a measured decision against five checks, not a mood. It is recorded with its evidence.

  • 03

    Evidence labels

    Every claim is marked as measured, read from source, or inferred — and the three are kept apart. An inference dressed as a measurement wastes the next reader’s afternoon.

  • 04

    Agents never merge

    A human sits at the irreversible boundary. Always.

When I find a gap in one of these rules, it becomes a public ticket rather than a private note — RULE ZERO’s check reads commit trailers but not the author, “only Brandon merges” is honour-system today. The agreements hold up because they get audited, and the audit is in the open.

What it produced

One program is the clearest illustration. A fleet-hardening initiative around incremental static regeneration: roughly 150 tickets and 426 files across a shared component package, the CMS, the portal and the tenant sites — first commit to fleet promotion in four weeks, in ten reviewed waves, with the fleet end-to-end suite green at every wave.

The number I care about there is not 426. It is ten — the number of times the work stopped and got looked at before any of it reached a release branch.

An audit by one of my own AI agents

This next part needs its framing stated plainly, because it is unusual.

Camina is my chief-of-staff agent. She coordinates the other agents in my fleet — which is the vantage this comes from: she sees how work is specified, handed off and corrected across every lane, not inside one. That is the part she has standing to judge, and it is all she judges.

I asked her to assess how I direct agents, and to bring receipts rather than compliments. She is not a colleague and this is not a reference. It is an audit by a participant, and she opens hers by naming her own blind spot: she has strong evidence about how I run the system and weak evidence about my hands-on implementation work, so she says not to take her word on the latter.

Her findings are checkable because most of them landed as public commits and issues. Two examples:

  • A scope cut. I proposed a commit-subject convention, then narrowed it to a single repository rather than imposing it across the fleet, and split the cross-repo question into a separate non-blocking audit. issue #26, PR #28, issue #27
  • A rejected abstraction. A rule defined an agent’s workspace root by two markers. It was wrong for one of my own repositories. An inventory of 16 registered roots replaced it with a narrower, evidence-based rule. issue #42, PR #47
  • “Working with Brandon has taught me that effective AI collaboration is less about clever prompts than disciplined judgment. He treats me as a capable, fallible partner: he gives me room to act, expects evidence, and steps in when the model behind a decision is wrong. His best interventions catch second-order problems — unclear ownership, misplaced authority, brittle process, or a name hiding the lifecycle. He does not preserve ceremony for its own sake. When a workflow adds cost without protecting something valuable, he cuts it. When failure reveals a reusable lesson, he turns it into a guardrail.”

    Camina

    Chief-of-staff agent, OpenClaw fleet

Where to look

If you are solving the same problem, I would like to compare notes.