What an AI Code Reviewer Catches in a Distributed System, and What It Misses

Pattern-level resilience mistakes are exactly what a language model reading a diff is well suited to flag: an outbound HTTP or database call with no timeout, a retry loop with no backoff or jitter, a write inside a retry path that isn't idempotent, a new dependency called with no circuit breaker or fallback, and an exception caught and logged but silently swallowed instead of propagated or handled. None of these require understanding the rest of the system. They're visible in the diff itself, which is why a well-configured reviewer catches them reliably and a generic linter usually doesn't, since most linters check style and typing, not resilience patterns.

Point an AI reviewer at these local, pattern-matchable mistakes first:

• An outbound HTTP or database call made with no timeout, which can hang a worker indefinitely.
• A retry loop with no backoff or jitter, which can turn a brief failure into a retry storm.
• A write inside a retry path that isn't idempotent, so a repeated attempt can duplicate its effect.
• A new dependency called with no circuit breaker or fallback if it slows down or fails.

Anything that depends on knowledge outside the diff is where AI review falls short. Whether a new field breaks a downstream consumer's schema assumptions, whether an ordering guarantee two services rely on still holds after a change, whether a distributed lock's TTL is actually longer than the slowest realistic run of the code it protects, and whether a change shifts load in a way that trips a capacity limit somewhere else in the system: none of that is visible from the diff alone. It requires knowing how the services fit together, which is exactly the context a code review tool doesn't have.

The default rule set in most AI review tools is written for a generic codebase. Point it at yours instead: feed it your idempotency key conventions, your per-service retry and timeout policy, and the postmortems from your last two quarters of incidents. A reviewer told that 'the checkout service has been the source of three timeout-related incidents this year' will flag a missing timeout on a new call to checkout far more reliably than one working from a generic prompt. Treat its output as a fast first pass that runs before a human looks at the diff, not as the thing that decides whether the diff merges.

If the review flags a newly added dependency with a known vulnerability, patch it on roughly the clock federal civilian agencies already use for internet-facing systems: critical issues within 15 days, high-severity ones within 30¹. That's a reasonable default even outside a regulated environment, because it forces a real decision (patch, mitigate, or accept the risk) instead of letting the flag sit open indefinitely.

Turn it on for new code first, not as a retrofit pass across the whole repository. A sweep across years of existing code produces hundreds of comments nobody will triage, and the team learns to ignore the tool before it's proven useful. Require a human sign-off only on changes above a defined risk threshold, meaning anything that touches a shared library, the payment path, or a service with an external SLA, and let everything else merge on the AI pass alone. Measure success by defects caught before merge relative to defects that reach production, not by how many comments the tool leaves; a chatty reviewer that never catches a real bug is worse than a quiet one that catches three.

A team that turns on AI review and treats a passing run as evidence the change is production-safe usually finds out the hard way that it isn't. The tool caught the formatting issues and a missing docstring; it didn't catch that a new retry loop had no backoff, because nobody had told it that retry-without-backoff was a pattern worth flagging for this codebase. A clean run means the patterns you configured it to look for weren't present, nothing more. Related reading on securing the pipeline that feeds it can help if you're also evaluating tooling for the security side of that pipeline.