Most of the code in Quorum was written by directing Claude Code, an AI coding agent. That is not the interesting claim, and on its own it is not even a good one. An agent left to run unsupervised produces fast, plausible, locally-correct code that drifts into an incoherent system. The interesting part is the discipline that turned agent speed into a coherent, correct, multi-region database application. That discipline was an append-only architecture decision log.
The failure mode of agent-built software
An agent has no memory across sessions. It will happily contradict a decision it "made" yesterday, re-open a question that was settled last week, or quietly drift from the design because the local change in front of it looks fine. Each individual output is reasonable. The aggregate, without governance, is a system where the data model fights the access layer and the third change undoes the first.
This is the part people underestimate when they talk about AI coding velocity. Speed without a source of truth does not get you to a good system faster. It gets you to entropy faster. A fast writer with no memory and no sense of consequence is a liability at scale unless something outside the agent supplies the continuity.
The decision log
Quorum carries a file of numbered architecture decisions, DEC-001 onward, now past two dozen. Each entry has the same shape: the context that forced the decision, the decision itself, references to the prior decisions it refines or interacts with, and a status. Three rules make it work:
Append-only. Entries are never edited. A later decision can supersede an earlier one, but it does so as a new numbered entry that references the old one. The history of why the system is shaped the way it is stays intact and readable, including the choices that were later reversed and why.
Committed separately from code. The decision and the code that implements it are different commits. The log reads as a clean narrative of intent, independent of the diffs that carried it out.
It is the contract. Every prompt I gave the agent carried the log as context. When a new instruction risked contradicting an earlier decision, the log was there to catch it, for the agent and for me.
This is not documentation written after the fact to make the project look organized. It is the input that keeps the next change consistent with every change before it. The log is the memory the agent does not have.
The other guardrails
The log is the spine. A few standing rules are the ribs, and every prompt carried them:
- A 50-test end-to-end suite is the merge gate. Nothing lands that does not keep it green. The agent can write whatever it likes; it does not merge unless the proofs still pass on the real deployment.
- Conventional commits and a clean working tree, so the history stays legible to a human reading it later.
- Secrets hygiene as a hard rule: a secrets scanner runs clean before anything approaches a public branch, account identifiers live only in gitignored files, and deploys run through a CLI preflight that verifies the right account is selected.
None of this is exotic. It is the ordinary discipline of a careful engineer. The entire point is that the agent does not supply it. You do.
What got built this way
Under that governance, the agent built an event-sourced incident command plane on . The repository, including the full decision log, is at https://github.com/hocmemini/quorum. Two companion posts go deeper on [the event-sourced data model and optimistic concurrency] and [the failover layer and what the chaos demo proves].
This post was created for the purposes of entering the H0 "Hack the Zero Stack" hackathon. #H0Hackathon
SOCIAL SHARE CARD GENERATOR