ONLINEREV · 2026-09-02§ BLOG · 2026-08-17-THE-BEST-CODE-REVIEWER-IS-A-RIVAL-VENDORS-AIPUBLISHED · 2026-08-17
All Posts
§ Journal2026-08-17

The Best Code Reviewer Is a Rival Vendor's AI

By Corey SlickPublished

The strongest check on an AI's work is a different vendor's AI. This week a cross-vendor review loop drove a safety-sensitive feature from fifteen findings to zero, a golden test set caught a five-figure double-counting bug, and a fleet of automations moved onto hardware built to be trusted.

The solo dev's hardest problem isn't writing the code

When you ship across eight-plus products by yourself, generation stops being the bottleneck almost immediately. AI writes the first draft of nearly anything now. The hard part — the part that actually decides whether a feature is safe to put in front of a user — is review, and review is exactly where working solo hurts most: there's no second engineer to catch what you and your tools both missed.

The best trick I've found for closing that gap doesn't require hiring anyone. It's structural: make the thing that checks the work a different, independently-trained system than the thing that produced it. This week that idea showed up three separate times, in three different forms — a rival model, a golden test set, and a dedicated machine — and it's the throughline worth writing up.

Make the reviewer a different vendor than the author

The build highlight of the week was pushing a safety-sensitive voice-agent feature through a review process designed to catch what a single model — or a single vendor — reliably fails to see in its own output.

The pattern: one model does an initial safety-focused pass and produces a ranked list of findings. Then a different vendor's coding agent re-verifies each fix independently — an adversarial, cross-vendor check, not the same model grading its own homework. The first pass surfaced fifteen findings; after two more rounds of fix-then-re-verify, the list went to zero before anything touched a real user.

The value here isn't subtle, and it's measurable: a model is genuinely worse at spotting its own blind spots than a differently-trained model is. A system reviewing its own work shares its own failure modes. Structuring the loop so a second, independent model has to argue with the first one's fixes turns "the AI says it's fine" into something you can actually defend — and it's a tiny process change that pays for itself immediately on anything safety-adjacent.

A golden test set beats a confident agent

The same principle, in a completely different domain, ran the biggest unglamorous chunk of the week: data-integrity work on a personal-finance pipeline.

The work was mining an old ledger export to fill multi-year gaps, correcting an account-scoped deduplication bug that had been inflating spend by tens of thousands of dollars in double-counted transactions, and fixing false-positive matching between two overlapping data sources. This is exactly the kind of multi-pass reconciliation where an agent earns its keep — cross-referencing tens of thousands of rows across multiple source formats and proposing exclusion rules is work no human wants to do by hand.

But notice where the trust actually comes from. I don't trust the agent's exclusion rules because the agent sounds confident about them. I trust them because they get checked against a golden test set before they ever touch a live report. I own the judgment calls — which categories are legitimately "spend" versus internal transfers, which source wins when two disagree — and the agent owns exhaustively applying that judgment across a dataset too large to eyeball. The golden set is the independent reviewer that keeps a confident-sounding rule from quietly corrupting a number I actually rely on.

A fleet is only as reliable as the box it runs on

The third form was infrastructure: finishing the migration of the always-on machine that runs everything — the scanners, the finance pipeline, the news digest, the API monitors — onto a beefier dedicated box, with its own headless authentication path and a pile of Dropbox-symlink quirks worked out along the way.

This is the least glamorous work imaginable; it shows up on no feature list. But it's the same idea one more time. Every automation I lean on inherits the reliability of the single machine underneath it, so that machine can't be an afterthought running scripts in a corner — it has to be treated as its own first-class piece of infrastructure, hardened deliberately. A fleet of monitors is only ever as trustworthy as the box they all boot from. Making that box a considered, dedicated thing is what turns "I set up some scripts" into something you can actually delegate to and stop watching.

The unglamorous win: a 48-hour cliff

Worth one paragraph, because it's the kind of catch that justifies the whole apparatus: a scheduled agent diffing public API changelogs against my own integration surface flagged that an image-generation model family I depend on for a note-search feature was being fully shut down by its provider — not deprecated, shut down — in two days. The same pass caught a location-data API that had quietly gone end-of-life three months earlier, and a mail integration returning a hard 410 Gone after its vendor retired basic auth. You don't get to choose when a dependency disappears out from under a live feature. You only get to choose how many days of warning you built yourself.

The throughline

None of this week's real work was typing. It was designing, in four different places, a second independent thing whose entire job is to distrust the first: a rival vendor's model arguing with my code, a golden test set arguing with my reconciliation rules, a hardened machine standing behind a fragile fleet, a changelog diff arguing with my assumption that last week's integrations still exist. Generation is cheap now; adversarial verification is the scarce, valuable part — and building it in on purpose, rather than hoping the thing that wrote the code will also catch its own mistakes, is the actual job.