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 Amazon Aurora DSQL in a multi-region active-active configuration, with a Next.js front end on Vercel. Optimistic-concurrency-based correctness so the incident record cannot fork under cross-region contention. A chaos-aware failover demo that is precise about what it simulates rather than overclaiming. Ingestion from CloudWatch through EventBridge and Lambda into DSQL. Credential-free auth over IAM with OIDC, so no static database secrets exist in the system.

The decision log is public in the repository, so the architecture is not only shipped, it is explained. You can read the reason for every choice, and you can read the reversals.

The actual lesson for engineers

Agent-assisted development at a senior level is not about typing less. The agent is fast and competent at the local task; that is settled. What it lacks is judgment across time: the memory of why a thing was decided, the refusal to re-litigate it, the sense of what a change will cost three decisions from now. That is the part you keep for yourself.

My job on Quorum was the architecture and the governance: the decision log, the test gate, the boundaries the agent worked inside. The decisions that needed a human were the ones an agent cannot weigh: choosing an event-sourced model so the audit trail and idempotency came for free, making the event UUID the idempotency key so retries are safe by construction, designing the chaos demo to simulate the real failure mode rather than fake a region kill, and owning the line between what the data plane survives and what the application tier does not yet. The agent wrote the code for those decisions. It did not make any of them.

If you are on a team adopting agents, the question is not "how much can the agent write." It is "what is your decision log, what is your gate, and who owns the judgment the agent does not have." Answer those three and the velocity is real. Skip them and the velocity is a trap.

The system is live at https://quorum-h0.vercel.app. 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