One pattern in the Revelara corpus carries an occurrence count of 161: authorization changes that reached production before anyone could see their downstream effect. The blast radius runs to multiple services and the time to resolve is typically measured in hours. The shape is consistent: the change goes out, the monitoring in place is pointed somewhere else, and the first signal is downstream API errors.

Your coding agent will review your next auth change and say nothing about any of that. It’ll check the logic, suggest a test, maybe catch a nil dereference, and then approve a change that matches one of the most repeated failure shapes in the corpus, because nobody ever told it the shape existed.

What the agent knows

Coding agents have read the reliability literature. The Google SRE book, the AWS Builders’ Library, the DORA reports, and a decade of conference talks and postmortem writeups that made it into the training data. That knowledge is real and it’s useful. Ask an agent why you want jitter on a retry and you’ll get a correct answer with the reasoning intact.

It’s also consensus-level knowledge, which means it’s the part of the discipline that got written down, generalized, and stripped of the specifics that made it worth writing down in the first place.

Your operational history is the part that didn’t survive that process. The agent has no idea which of your services is tier one, or that the catalog service degrades for four minutes before it fails outright, which makes a liveness-only health check useless during exactly the window that matters. It hasn’t been told that the failover on your primary datastore is documented as automatic and has been manual since the migration, or that the last change to this code path took checkout down for ninety minutes.

That’s the knowledge that makes a senior reviewer worth the salary. Everyone knows timeouts are good. The comment that saves you is the specific one: this call path has no budget for a slow dependency, and we’ve been burned here before.

Why the usual fixes don’t close the gap

You can write a very good system prompt about reliability review, and the agent will apply the literature more carefully for it. It still can’t tell you about an incident it was never shown, because prompting shapes how a model reasons over the information it has rather than adding any.

The context window isn’t the constraint either. Retrieval is. Your incident history lives in a Confluence space nobody has pruned since 2023, a folder of Google Docs, a few Slack threads, and the memory of the two engineers who were on call that night. None of that is indexed against a diff.

Pointing retrieval at the wiki gets closer and still misses, because the wiki holds runbooks and architecture decisions that describe how the system is supposed to work. Incident history describes how it actually failed, and that’s the corpus with predictive value. A wiki also has no way to tell the agent which advice is settled practice and which is a strong opinion someone wrote down in 2019 that nobody has revisited since.

Closing it at the moment the change is written

Three things have to be true for an agent to review like someone who was there.

The history has to be scoped to the change

A review that re-litigates the entire repository gets skimmed once and ignored after that. Change-scoped review is the version people actually read.

In practice that’s /rvl:reliability-review against your git diff during the session, and rvl scan --agent over the staged change set as a pre-commit or pre-push gate. The gate only flags risks introduced or worsened by the change, so pre-existing issues in the surrounding code stay out of scope. It also fails open by default when the agent is unavailable, which matters a lot if you’re installing something in front of every commit your team makes.

The evidence has to be graded

Reliability advice circulates as folklore. Somebody read a post, repeated it in a design review, and now it’s how your team does things. Some of it is well supported and some of it isn’t, and after enough repetitions the two become indistinguishable.

The practice catalog grades each pattern as best, good, or emerging, and carries a consensus state, a confidence value, an occurrence count, and the specific incidents behind it. An agent that can separate settled practice from an emerging one argues differently, because it can tell you a recommendation rests on 161 occurrences with settled consensus, or that it rests on five and the field hasn’t made up its mind yet. You’d expect a human reviewer to draw that distinction before telling you to go rewrite something.

The scar tissue doesn’t have to be yours

A company that’s two years old doesn’t have ten years of outages to learn from, which usually gets framed as a reason evidence-based review has to wait until you’re big enough to have failed a lot.

Other people’s postmortems are public, though, and the corpus is built from them, so the evidence is there on day one. You upload your own incident reports and RCAs as you accumulate them and they join the same graph, which is what starts sharpening the review toward your systems specifically instead of leaving that history in a folder. The queries the agent runs are the ones a reviewer would ask out loud: has anything like this failed before, what’s the control that addresses it, what does this service actually depend on.

The part that stays human

None of this gives the agent judgment. Judgment comes from having been there, and the agent hasn’t been anywhere. Deciding that a risk is acceptable this quarter, or that the fix costs more than the failure it prevents, stays with the people who own the service and carry the pager.

What the machine can do is carry the record of everyone who has been there into the moment you’re writing the code. Reliability knowledge has always been hard-won and badly distributed, sitting in senior engineers’ heads and in postmortems that get read once and filed. It’s worth more in front of a developer while the change is still a diff than it is in the archive.

Try it

The corpus is built from public postmortems, so the evidence is there before you’ve accumulated any of your own. Point it at a repo and read what comes back. Start here.