Who Reviews the Reasoning?
The code coming out of agents runs, and the reviewers shipping today catch the bugs. Nobody is reviewing the decision: was this the right…
Who Reviews the Reasoning?
The code coming out of agents runs, and the reviewers shipping today catch the bugs. Nobody is reviewing the decision: was this the right path? I built a plugin that does.
Baltimore
The code coming out of coding agents is fine. It compiles. The tests pass. A linter ran before I ever saw it, and lately an AI reviewer flagged the two bugs a person would have caught on a good day. Which leaves me looking at a change that has already passed every check, still asking the only question that was ever hard: is this the right thing, built the right way, and what will it cost me to keep it running? That question was never really about the code, and no amount of correctness tooling gets near it.
Look at what today’s reviewers actually do. They read the diff and check it against the rules: bugs, style, a missed null, and whether it follows the house conventions. The good ones score their own confidence, so they do not bury you in false positives. Anthropic ships one with Claude Code that runs a set of agents in parallel to find exactly those things. All of it is useful, and none of it tells you whether the change should have been written at all.
When a senior engineer reviews a change and stops, the pause is not about a line. It is about the decision behind the change. Was this the right approach, or the first one that worked. Does the code do what the business needed, edge cases and all, or what the ticket happened to say. Will the person who inherits this understand it. How does it fail at three in the morning. Is it as simple as it could be, or did the agent reach for an abstraction it did not need. Those are the questions worth a person’s attention, and nothing on the market asks them.
They turned out to be the hard part when I tried to automate them. You cannot judge whether something was the right path by staring at where it landed. The diff only shows you the end of the story. The decision lives in how the change got made: the plan the agent wrote, the approach it picked, and the ones it dropped, what it assumed without checking, the half-built attempt it backed out of, and left traces of. To review the decision, you have to rebuild that path, not just read the result.
So I built a plugin. It is called secondopinion, and it does that. Point it at a change, and it pulls the trajectory back together: the diff, the intent it was meant to serve, whatever plan or reasoning the agent left behind, the commit history, the patterns the codebase already uses. Then it hands all of that to a separate reviewer, running on its own so the context that wrote the code cannot lean on it to approve, and that reviewer works through the questions above and writes up what it found.
Here is what that looks like on a real change. The repo ships an unedited run against a small commit: a getUser function that hit the database, then a change adding a process-local cache, with the commit message "cache users in memory to cut db load." Nothing about it would trip a correctness reviewer. The tests pass, the logic is right, the code does cut database load. The decision reviewer came back with revise, and its reasoning is the product. It found that the one-line intent quietly carried four separate decisions, only one of which the commit message mentions: cache reads, never invalidate, let the cache grow without bound, and accept that every process holds its own copy. Then it walked through what each of those costs on a users table, where names, roles, and permissions change: stale authorization data served until the process restarts, memory that grows with every distinct user until something falls over, and different workers giving different answers about the same person. Its closing line to the approver was that none of this is what "cut db load" asked you to accept.
What comes out is shaped for whoever is approving. For a person, it writes a plain decision review: what the change is trying to do, the decisions that got made including the ones nobody flagged, the findings that matter, and, at the end, the risks you are signing up for if you approve it. For another agent, it also emits a verdict it can act on, approve or revise or block, with a confidence and the findings behind it, so an automated gate can stop on the ones that should stop. The aim is to either take the person out of the loop where the decision is clear, or, where it is not, hand them the one thing a diff never gives them: the reasoning behind the change they are being asked to sign.
There is one rule in it I care about more than the rest. It has to be honest about what it could not see. In the cache run, it capped its own confidence at medium and said exactly why: it never saw load figures proving the database was a problem, never saw whether the deployment runs one process or many, and had no recorded reasoning from the author, so the trajectory was inferred from two commits. A reviewer that hides what it never looked at is not reviewing anything; it is agreeing in a longer format. The honesty extends to the verdict itself. The output is a model’s judgment, so the wording varies between runs, and on this change an earlier run said block where this one said revise. The repo says that plainly rather than pretending the tool is deterministic, and the tests assert on the structure of the verdict, never the prose.
I wrote a while back that human code review was a temporary refuge, that the same drop in the cost of writing code was coming for the cost of checking it. This is what that collapse looks like up close. Not agents checking each other’s syntax, which is nearly free already, but agents interrogating each other’s judgment, the part we assumed only a person could do. None of this makes the person disappear. They move up, from reviewing the change to owning the outcome and deciding what should exist at all. That last decision is the one I still do not know how to automate, and I am not sure I want to.
I should be clear about what this is not. It is a second opinion and a forcing function, not an oracle. It will be wrong sometimes, confidently on occasion, and the responsibility for the merge stays with whoever hits the button. What it does is make the reasoning visible and hard to skip, which is most of what a good reviewer was ever doing.
Claude Code has a plugin marketplace now, so you can drop it into your own setup in two lines. The link is below. The rubric, the questions and how they are weighed, lives in a single file, and it is the opinionated part, so if your team judges these things differently, fork it and change the questions. Better that a hundred teams argue with my rubric than take it as given.
Get it: the plugin is at github.com/jmcdonald69124/secondopinion, with the full unedited example run in examples/decision-review.md. Install with /plugin marketplace add jmcdonald69124/secondopinion, then /plugin install second-opinion@second-opinion.
By Joshua McDonald on July 2, 2026.
Exported from Medium on August 26, 2026.
Reader discussion