Most of the code on this site was written by an agent. That isn’t a shortcut; it’s the discipline I’m paid for, and the discipline lives in one place: the review. The agent writes the happy path. My job is to make sure the failure modes ship as intentionally as the feature.
Three checks cover most of what slips through.
Fail fast, don’t fall back
When a required value is missing, the correct response is to crash with a message that names what’s missing — not to return an empty string and keep going. A missing API key that returns "" and lets the app run will, soon enough, call the wrong endpoint in production and look like a healthy system doing the wrong thing. A crash with RuntimeError: GLM_API_KEY not set is fixed in thirty seconds.
The rule I give every agent: if a config value is required, the code that reads it either succeeds and returns a real value, or raises. There is no third branch that silently points the app somewhere plausible. value or "glm-4-plus" is a bug, not a fallback.
No config strings in business logic
Model names, URLs, env-var names, endpoint paths, magic thresholds — none of these belong as string literals inside a function. They belong in one place: a config class. The test is simple. If the same URL or model name appears in two files, the code is already wrong, because the second writer didn’t know about the first.
# wrong — the URL lives where it's used, and only there
url = "https://open.bigmodel.cn/api/paas/v4/chat/completions"
# right — one source of truth, business logic imports it
from config.llm import LLMConfig
url = LLMConfig.chat_completions_url()A grep for a known model name or API host should hit one file. If it hits two, the review sends it back.
Every commit gets a separate review
This is the one that does the most work, and the one agents resist most, because it slows them down. Every discrete change is its own commit, and every commit is reviewed by a separate pass that hasn’t watched the reasoning — before the next stage starts. Fixes fold back into the same commit, so the history reads as one clean feature, not a feature plus a trail of “fix typo”, “actually fix”, “fix the fix”. And there’s a hard two-round cap per stage, because a review that can’t converge in two rounds is usually pointing at a requirement that’s wrong — more rounds would just spend tokens confirming it.
What that actually caught here
The UCP checker on this site (POST /api/ucp-check, which reads a domain and fetches its commerce manifest) was built that way, and the history shows what a review pass catches that the writing agent didn’t.
The handler reads the domain from the request body. The agent wrote const domain = payload.domain ?? "", which looks defensive — until a client sends { "domain": 123 }. 123 isn’t nullish, so it passes straight through; the next line calls .trim() on it and throws a TypeError, and the worker returns an opaque 500 where the spec said 400. The agent had assumed request.json() would always return a string. It doesn’t. The TypeScript type is an assertion, not a runtime guarantee.
The same endpoint does await res.text() to read the target’s response. If the target server starts a response and then drops the connection mid-body, that line throws too — another 500, where the right answer was a clean { status: "error" } telling the user the fetch couldn’t finish.
Neither bug was exotic. Both were the normal class of “the happy path was tested, the failure modes weren’t”. The review pass, whose only job was to look for failure modes, caught both; they were folded into the same commit (c6eb29f), and the history shows one feature landing clean instead of a feature plus two repair commits. That’s the whole point of the discipline: the failure modes ship as intentionally as the feature.
The discipline is the product
The conventions above live in an AGENTS.md that every agent reads before it writes a line, and the git history is the audit trail. AI doesn’t make the review optional; it makes it load-bearing. The value was never in the typing.