A PR landed on our CLI with ~550 lines of new probe code. Its entire product effect was one debug log line, and the number it existed to measure was one the PR's own limitations section admitted it couldn't measure. My six-lens /deep-review panel read it and did good work: safer, quieter, better named. Not one of the six asked whether it should ship at all.
The reviewers weren't the problem. Every mechanism in that panel is anchored — a finding needs a file:line, a fix needs a before/after. "This file shouldn't exist" has no anchor, so there's nowhere to file it, so nobody says it. Each lens does the one thing the harness makes easy: improve the code in front of it.
So every lens now returns a scope verdict — ship-as-is, split, or cut — and that gets settled before any fix is applied. Order matters: hardening code that's about to be deleted makes the deletion look expensive. And a cut doesn't authorize anything. The panel rules; I still press delete.
823 PRs merged across our repos this month. Same 28 days last year: 218. Same number of people.
Everyone got faster once we leaned into the AI tooling, and the review queue got the bill. I stopped being able to keep up with mine, and I don't think I was alone. Writing the code wasn't the slow part anymore. Reviewing it was.
What made review slow wasn't the hard parts, it was getting to them. Most of a big diff is a rename, a function moved between files, a regenerated snapshot. The two hunks that decide whether this ships are buried in the middle of it.
So I wrote /review-with-me. It tells me what the change is for and why, picks the hunks carrying real risk, walks me through them one at a time, and turns whatever I say into inline comments on the PR.
We ran a retro after one of the first projects we shipped on our new agent framework, and a teammate brought up something I haven't stopped thinking about since. The risk with coding agents that worries them isn't bad code — it's shipping a change you never built a mental model of. The agent writes it, it passes, it looks right, you move on, without ever forming the understanding you'd have ended up with if you'd written it by hand.
The cost is just deferred. It shows up later, when something breaks and the person who "owns" the code has nothing in their head to debug from, or in review when you're nodding along to a diff you can't actually evaluate. Writing code yourself forces a model whether you want one or not. An agent quietly removes that forcing function, and nothing replaces it unless you go looking.
This isn't new as a concept — we've always been able to paste something we didn't understand or lean on someone more experienced. What's different is that agents make it the path of least resistance, all day, at the scale of your whole output. Mostly I've started treating "can I explain why this change is correct" as the bar before I ship, instead of "did it pass," and treating review as the place to rebuild the model rather than rubber-stamp the agent's. But I don't think anyone has this figured out yet — it feels like one we'll all work out by trial and error, as an industry, over the next while.
This week I turned a few of my most experienced teammates — and myself — into AI code-review personas. Each one is built from around a thousand of their real review comments, so it reviews the way they actually do.
Mine was the funniest to write. My number one move in a review, by far, is just asking "Why?" Often the whole review is one word. So that's the first rule in my persona. The AI version of me is, accurately, a single skeptical "why?" on every diff.
The others have their own fingerprints. One is security-first. One reads prompts and tool descriptions as hard as code — "this is a book," "too many tokens." One always asks "don't we already have this?" before you add new code.
Now they run as a gate before I push: each persona reviews in turn and keeps going until it has nothing left to complain about.
The funny part: writing each persona made me see my own habits from the outside. Turns out I really do just ask "why?" a lot.
If you can describe how your best reviewers think, you can get some of that judgment on every change — not just the ones they happen to catch.
I plan a change with the agent, it opens a PR, and then I do what everyone does: go to GitHub to actually read the diff. GitHub is still the best place to read code. The problem is the round trip. I'd leave a comment there, switch back to the terminal, and then… what? Tell the agent to go read my comment on line 40? Paste it back myself? That's not reviewing, that's being a courier for my own feedback.
So I started using Hunk (not Hulk — Hunk: https://github.com/modem-dev/hunk). It opens a diff viewer that the agent and I are both looking at. I leave inline comments and the agent reads them right where I left them. No copy-paste, no relaying through chat.
The part I didn't expect: if a Hunk session is open, mauro-reviewer drops its review notes straight into it instead of the chat. So now I don't have to leave the diff to talk to the agent about the diff.
I built a code-review skill for changes to our internal agent platform last week — test-authoring, recovery, results-analysis, and the base classes they share. The rules were already written down in an agent-development doc, so I figured encoding them as a reviewer would be mostly mechanical. The first time I ran it against one of my own open PRs, it flagged me for using auto function-calling mode where the rule expected required — but I'd moved the authoring agent off required a couple weeks ago and never updated the doc. The first bug it caught was me. The reviewer-build ended up being a good excuse to check in on which of my own rules were still current. I'm still shipping the reviewer, but I'll probably keep treating "do we have a reviewer rule for this?" as a checkpoint whenever design decisions evolve.
Millions of PR comments a year get burned on style — tabs, spaces, imports, line breaks. That's a closed-form, solved problem. Why are you wasting your keystrokes and valuable context on style? We don't. No need to fill our CLAUDE.md files with 10 pages of format rules, no need for a new hire to spend a week learning our way to type. Don't fill your physical and virtual context windows with rules a CPU can apply.
So Spotless landed across our Java codebase this week, with a pre-commit hook and a CI check. I picked it specifically because it auto-fixes. Other tools will scold you about wildcard imports ("thou shalt not!"); Spotless will simply fix them, auto-magically. A tool that produces a report is the wrong pattern — at scale, we're shipping code, not reports. Calling "fix" is table stakes. The pre-commit hook means both human and agent operator styles are fixed before the PR opens. Neither has to grok the rules.
The goal isn't to sweat the small stuff. It's to eliminate it. I don't care how you use tabs or spaces. I care that your feature does what the customer needs. Leave the rest to the CPU. LFG.
I compared engineering output from the last 90 days against the 90 days before it. PRs went from 811 to 2,068 — two and a half times more. Lines of code shipped almost doubled. The number of active authors barely moved, from 31 to 35, so almost all of the lift is per-engineer throughput, not headcount. The other thing the data shows is that PR count grew faster than LOC, which means PRs are getting smaller on average — more, tighter changes instead of bigger ones. Reviews almost doubled too, which tracks. The thing I'm looking for now is the bottleneck. What's actually holding people back at this throughput — human review, testing, scoping, something else? That's where I want to spend the next month.
I've been watching what our two PR reviewers actually catch, and the pattern is uncomfortable. Our default review runs on Claude. Anyone can also kick off a Codex review on demand — and when they do, Codex regularly flags blocking issues the Claude pass walked right by. Not edge cases. Things that would have shipped.
The honest question: is Codex better at code review, or is the win mostly that it's a second perspective looking at the same diff? If we'd built it the other way around — Codex by default, Claude on demand — would we be writing this post about Claude?
I don't know yet, and I think that's the right place to sit for a minute before we draw the conclusion. What I do know is that on the changes that matter, two reviewers from two different shops are catching more than one of either, and that's a finding regardless of which is "better." We're going to keep both, and I'm going to start measuring which class of issue each one actually catches.
I built a code-review subagent and named it after Mauro. This is not a joke about Mauro — Mauro really is our best reviewer. He reads the code with his eyeballs. He suggests an enum every time he sees three magic numbers in a row. He reads the strings inside the code, notices when "Error fetching MauroAgent data" should have been a template literal, and tells you. He won't accept eslint-disable-next-line without a reason. When he sees a prompt he can't follow, he says "if I can't understand it, the LLM won't either."
I wrote those rules down. That was the agent. It took an afternoon.
Mauro's reaction was that I replaced him because I got tired of waiting for his reviews. That part is also true. The interesting thing is how little of his review style I had to invent — most of it was already a list of habits he applies in the same order to every PR. The reviewers we trust most are the ones whose taste is the most legible. Turns out legible taste compiles.
I tried to make /fab-note auto-publish posts the moment a draft is confirmed. Two paths to do that, and both required carving an exception out of our org's branch protection — either a bot identity in the bypass list or a PAT scoped to repository admin. Neither is wrong, but each is a small concession against the policy that says "every change to main gets reviewed." So I stopped pushing on auto-merge and made the workflow assign the PR to me instead. Total clock time from "ship it" to live: about two minutes — most of it CI checking. The clicks in between (one approval, one merge) take three seconds and they preserve the property that a human approved the change. I was solving for the wrong thing. The friction of "wait for CI, click approve, click merge" is invisible to the author because they've moved on to the next thing by the time it's their turn. The friction of "build a policy exception around a fast publish path" is permanent and visible to anyone who later asks why this repo bypasses the rules. The cheapest version of automation is the one that lets the existing policy do its job.
I've been thinking about where verification belongs in an agentic pipeline. The shape I keep coming back to is a quality validation sub-agent that runs before PR submission — its job is to come up with and verify a validation plan for the change, including running the relevant mabl tests, capturing evidence, and attaching that evidence to the PR. Then the PR review agent enforces the existence of the validation plan, not the rules underneath it. Then the full mabl suite runs on merge, and when something breaks, a failure-analysis skill identifies which PR introduced it and suggests fixes.
The reason for that structure: at our throughput, "did the engineer remember to validate this" is the wrong question. The right question is "does the PR carry evidence that validation happened, and does the evidence hold up?" Sub-agents do the validation; the review agent checks the evidence; the merge gate trusts the chain. None of the layers is doing checklist work — each one has a specific decision to make. Most teams that try to add AI to their existing CI/CD end up with checklist agents because that's the shape of CI/CD. I don't think that's where this lands.
At our current PR throughput, I'm going to burn out on reviews alone, never mind actual work. We can't move at this pace while also having a human read every change. The model I want us to move toward: ask for human review when you're truly unsure about something, and let the agent reviewers handle the rest.
The piece I shipped to make this real was getting /codex-review wired up across every repo as an on-demand second opinion. Different model family from Claude, uncorrelated blind spots, one comment away when you want it. The work was sixteen PRs across sixteen repos to enable the GitHub Actions trigger, plus a change to our shared workflows repo to make it a first-class slash command. The conceptual work was harder: deciding that "two agent reviews and a human glance" is now an acceptable pre-merge state for routine changes, and reserving real human attention for the changes that genuinely need it. We're not all the way there. But the trajectory is clear, and I'd rather build the routing now than burn out catching up to it later.