Stop trying to replace code reviewers. Brief them.

In the last 18 months, AI changed how code gets written. It also broke how it gets reviewed — and most of the industry is fixing the wrong thing.

Pull requests today are bigger, more frequent, and harder to read. Engineers ship in hours what used to take days. The keyboard is no longer the bottleneck. The reviewer is.

The dev-tools industry's response has been to point AI at the same problem — but in the wrong direction.

The "AI reviewer" trend, and why it stalls out

Open any PR with an AI review bot installed and you'll see the same shape: a flurry of inline comments. "Consider extracting this method." "Add a null check here." "Possible race condition."

Some are useful. Most are noise. A few are wrong. None of them tell you the thing you actually need to know on a 26-file PR:

What is this change really doing? Where do I look first? What's likely to break?

The premise of these tools is that the AI is the reviewer. The human's job is to read the bot's comments and rubber-stamp.

That premise is wrong.

On any PR that genuinely matters — the migration, the perf overhaul, the security-sensitive endpoint — the reviewer is the one who has to make the judgment call. The AI's job isn't to take that call away. It's to prepare the reviewer to make it well.

What "prepared" actually means

Imagine your most senior engineer is about to walk into a code review for a PR they've never seen. What do they want, in the first 60 seconds?

1. Intent — what is this PR actually trying to do?
2. Architecture — what's the shape of the change?
3. Reading order — of these 26 files, which 3 explain everything else?
4. Risk surface — what's the most likely place this breaks?
5. Questions for the author — what's worth asking before approving?

That's a briefing. It's what a good tech lead gives a reviewer who's about to go cold into someone else's diff. It's not opinions. It's context.

That's what we built. We call it Cicero.

Cicero, in one PR

https://github.com/Kyberkt-Labs/Cicero

We just ran Cicero on a real 26-file PR from a working repository. Two threads were bundled into one change: a major performance overhaul of an MVT velocity-compute pipeline, plus a fix to an anonymous-share-link viewer flow. The kind of PR that makes a senior reviewer sigh.

65 seconds. $0.44. One briefing.

Here's the actual structure it produced:

• Intent — one paragraph identifying that the PR was actually two independent threads bundled together, and flagging that as something to call out to the author.
• Architecture — 6 bullets, each pointing at a specific module, naming the contract change, and explaining how the rest of the diff implements it.
• Reading order — 7 files in dependency order. The worker contract first, then helpers, then consumers, then the unrelated map-init fix last. Not alphabetical. Not file-tree order. The order a human should actually read them.
• Risk surface — 7 specific concerns, each tied to actual code locations: a worker/TypeScript source-of-truth drift problem, a date-range cache short-circuit that assumes invariants the data producer might not honor, a referential-stability change that could cascade through downstream useMemos.
• Questions for the author — 6 questions ready to paste into the PR conversation, including the bundling concern, a missing-localStorage-key migration, and a parity check between two near-duplicate code paths.

A reviewer reads that in 2 minutes, then walks into the diff with a plan.

Total review time drops by something like 40%. And the actual review gets better — because the reviewer isn't filtering through bot noise, they're inspecting against a checklist they can trust.

Why this is better than what's out there

Three differences that matter:

1. We don't write in the PR.
Bot comments live forever in the conversation thread, even when they were wrong. Cicero's output is for the reviewer's eyes, on the side. Cleaner PR history. No "actually that's a false positive" replies clogging the conversation.

2. We don't pretend to know if the code is correct.
We tell you where to look. The judgment stays with the human — which is the only place it can responsibly stay until AI is good enough to be trusted on the high-stakes calls. (It isn't, yet.)

3. We're hallucination-disciplined.
The briefing comes with a path-existence guard: any file path the model mentions that doesn't exist in the actual diff gets stripped and replaced with [unverified path]. You'll never click a Cicero suggestion and land on a file the model invented. If you've used AI tools that confidently cite functions and files that don't exist — you know how rare and load-bearing that property is.

Other tools are betting that AI can replace the reviewer.

We're betting that AI can make the reviewer faster, sharper, and more confident — without taking the call away from them.

The bigger pattern

The "AI does the work for you" framing has a ceiling. It works for tasks where the cost of being wrong is low and the cost of verification is high (autocomplete, doc summarization, glue code). It breaks for tasks where the cost of being wrong is high and the cost of verification is also high — code review, system design, security audit, anything where the human is responsible for the outcome.

For those tasks, the right framing is the opposite: AI as the prep-work specialist. Do the reading, the orientation, the dependency-tracing, the surfacing of likely problems — then hand the informed human the keyboard.

Cicero is the first version of that idea applied to PR review. The same framing maps onto incident response, design review, and security triage — anywhere a senior person has to make a high-stakes call inside a context they don't already hold.

Try it

Cicero V0 is the engine — works as a CLI today, with a Chrome extension landing next. Bring your own Anthropic API key and a GitHub token, point it at any PR you can read, and you'll have a briefing in under a minute.

cicero brief https://github.com/your-org/repo/pull/123

If you find yourself asking "where do I even start?" on a PR more than once a week — try it on the next one.

Two minutes of reading the briefing should be enough to tell you whether your code reviews would benefit from a co-pilot that does the prep work and stays out of the way.

Built for the AI-coding era, where the reviewer is the bottleneck — not the keyboard.