Anthropic's own engineers write 200% more code than they did a year ago. Not a typo. Claude Code writes so much of it, Anthropic built a separate tool to keep pace with reviewing it.
I read about the tool this week. It's called Code Review, a research preview for Claude Code teams. Multiple AI agents look at every pull request in parallel, flag logic errors, rank them by severity, and hand a human a shortlist instead of a wall of diffs. Before it existed, only 16% of pull requests at Anthropic got a substantive review comment. After, the number jumped to 54%. On big, 1,000+ line pull requests, 84% turned up real findings, averaging 7.5 issues each. Anthropic's head of product, Cat Wu, put the problem plainly to TechCrunch: "Now that Claude Code is putting up a bunch of pull requests, how do I make sure those get reviewed in an efficient manner?"
Read it again. Volume went up. Review coverage went up to match it. Nobody at Anthropic decided more code meant less scrutiny.
So why is this exactly what happens with feedback?
The Bottleneck Nobody Names
Every engineering leader I talk to has a code review process. It's not optional. You don't merge without eyes on it, or these days, without an AI agent's eyes on it plus a human's. The bar for "this ships to production" keeps climbing even as the volume of code explodes.
Now ask the same leader about their last three pieces of feedback to a direct report. Not the annual review. The in-the-moment feedback: "good job on it," "let's talk about the deck," "you need to be more proactive." Was any of it reviewed before it landed? Checked for logic errors? Verified against evidence?
Almost never. Feedback ships straight to production. No review, no test suite, no rollback plan. And unlike bad code, you cannot revert a comment already sitting in someone's head for a week.
Anthropic's own numbers show the false positive rate on their Code Review tool sits under 1%. Compare it to how much manager feedback is correct, specific, and helpful. Nobody measures it, and the absence itself is the point. We built rigorous review for code because bad code is expensive and visible. We never built rigorous review for feedback because bad feedback is expensive and invisible.
Why Code Gets Scrutiny and People Don't
Part of it is history. Software engineering spent decades building a culture around review: pull requests, linters, static analysis, pair programming, now AI agents on top of it all. Getting code wrong leaves a stack trace. It fails a test. It throws an error at 3am and pages someone.
Getting feedback wrong doesn't throw an error. It erodes trust, quietly, over months, until someone quits and everyone acts surprised. No pager exists for it. No pipeline blocks a bad one-on-one from happening.
The rest of it comes down to how each feels. Reviewing code feels technical. Reviewing feedback feels personal. Nobody wants to tell a manager "what you said to your report was vague and unfair," the way we casually tell a developer "this function has a null pointer bug." One reads as a technical correction. The other reads as an attack. So it doesn't happen, and the manager never learns their feedback style has carried a bug for years.
What Reviewing Feedback Would Look Like
I'm not proposing you run manager comments through an AI model before anyone speaks. Its own nightmare, no doubt. But the model Anthropic used for code is worth borrowing, because it isn't about catching typos. It's about catching logic errors.
Anthropic's Code Review deliberately skips style nits and focuses on the highest priority fixes: real bugs, not preferences. Apply the same discipline to feedback and a short, useful checklist emerges:
Is it specific? "Good work" is a style nit. "The client pushback in Tuesday's call came from the pricing slide, not the roadmap slide, fix it before Friday" is a logic check.
Is it timely? Feedback delivered six months after the event holds the same value as a review comment on a pull request already shipped, merged, and blamed for an outage. None.
Is it falsifiable? Does a specific moment back it up? When feedback traces to no specific action, it isn't a finding. It's an opinion wearing a badge.
Does it hold up past one bad day? Anthropic's tool ranks by severity so a typo doesn't carry the weight of a security hole. Good feedback does the same: does this pattern affect the work, or did the manager have a rough Tuesday and take it out in a one-on-one?
None of this needs a model. It needs a manager willing to review their own feedback with the rigor they would demand for their code.
The Trust Problem Is the Same Problem
Anthropic built Code Review because Claude Code's revenue and adoption exploded and trust in the output hadn't kept pace. Companies like Uber, Salesforce, and Accenture ship more AI-generated code than any human team would eyeball line by line. Volume broke the old trust model, so Anthropic built a new one.
The same thing happened to feedback, slower and quieter. Teams grew. Managers went from five reports to fifteen. Slack replaced hallway conversations. Feedback volume never dropped, it got worse, because nobody scaled the review process alongside it. Ten times the headcount under one manager, with the same quality of attention on every single piece of feedback? Impossible, unless something exists to catch the ones slipping through.
This is why I built Step Up To BAT the way I did. It's a 360-degree feedback tool, built on the premise: feedback needs the same structured, multi-source review code gets. One person's opinion of your leadership style is a single data point. Confidential input from your team, your peers, and your own reports, gathered and reviewed together, mirrors what Anthropic does with multiple agents checking each other's work. Don't trust one reviewer. Trust the pattern across several.
What I Would Do Starting Monday
If you lead engineers, or anyone, here's the practical version of this argument.
Stop treating feedback as a one-way broadcast. Build in a review step, even an informal one. Before delivering hard feedback, run it against the four questions above: specific, timely, falsifiable, and does it hold up past one bad day.
Get a second source before acting on a single data point. If one person calls a team member "difficult," treat it as a comment from one reviewer. Don't merge it without another perspective.
Track your own false positive rate. How often has a gut read on someone turned out wrong once more context arrived? Without an answer, no review process exists, only a hunch generator.
Anthropic didn't build Code Review because AI is untrustworthy. They built it because volume outpaced verification, and verification is the thing keeping teams safe while moving fast. Feedback to your team sits under the same pressure. Its volume hasn't slowed. The question is whether you're reviewing it, or shipping it straight to production and hoping nobody finds the bug.
So, when did you last review your own feedback before giving it?