@GKev1n: Stop obsessing over having Sub-agents review each other's code — you think it's "stepping on your own foot to reach the sky," but it's really "pickpocketing yourself." I couldn't agree more with poteto's take today!! She said outright that adversarial code review is mostly just burning tokens ——
Summary
The author agrees with poteto, criticizing adversarial code review between sub-agents as a waste of tokens, pointing out its three fatal flaws — meaningless nitpicking, over-engineering, and mismatched compute — and noting that top teams are shifting toward real testing, formal verification, and actual red-teaming to find issues.
View Cached Full Text
Cached at: 11/03/26, 02:35 PM
Stop Getting Hooked on Sub-agents Reviewing Each Other’s Code — You Think It’s “Stepping on Your Own Foot to Reach the Sky,” But It’s Actually “Pickpocketing Your Own Wallet.” 🔥🤖
Couldn’t agree more with what poteto said today!!
She bluntly stated that adversarial code review is mostly just burning tokens for nothing. Not only did she significantly cut back on the interrogate skill in pstack, but she’s also planning to pour all the saved compute into “empirical testing + formal verification.”
Anyone who’s run automated agent workflows knows that static AI-on-AI code review has three nearly unsolvable fatal flaws:
▸ Manufactured suffering: The reviewer, in order to prove it “did some work,” will nitpick a pile of trivial code style issues even when there are no real bugs.
▸ Over-engineering (YAGNI): To defend against the reviewer’s imagined “edge cases,” the main agent keeps stuffing the code with unnecessary abstractions and defensive logic. The more it changes, the bloated it gets, and the context just gets dirtier and dirtier.
▸ Compute mismatch: Spending the most expensive reasoning tokens to “guess” whether the code will throw an error, instead of just running it with the free compiler and linter.
On one side, xAI engineers are cutting model-versus-model brawls and going back to hard-core verification. On the other, OpenAI and Muse are throwing up bounties today, literally paying external hackers to poke at their systems and find bugs.
Top teams are voting with their actions: 10,000 bickering lines between two models in the terminal don’t come close to a single red test from the test framework — let alone a punch from a real red team.
In your own workflow, is the AI reviewer actually helping you catch real vulnerabilities, or just helping you run up your API bill?
lauren (@poteto): maybe a hot take but i now consider adversarial reviews mostly a waste of tokens. far better to use those tokens on empirical combined with formal verification. i have updated pstack to use the interrogate skill less, and eventually i think i may remove it altogether
i have
Similar Articles
@vintcessun: Alibaba open-sourced a code review tool. The core idea is interesting — a hybrid architecture of deterministic engineering + Agent. Common issues with pure LLM review: incomplete coverage, line number drift, and unstable quality. It uses a deterministic pipeline for file selection, grouping, and rule matching, while the Agent is only responsible for dynamic decision-making and context...
Alibaba open-sourced Open Code Review, an AI code review CLI tool that adopts a hybrid architecture of deterministic engineering and Agent. It has been running internally for two years and has discovered millions of defects.
@shao__meng: How can you trust your Agent's work more? @poteto from the Grok Bot team proposed a four-layer "inverted pyramid" framework for trusting AI Agent outputs. She argues that instead of spending effort "disciplining" the Agent, you should spend effort reshaping the codebase itself! # The Four-Layer Inverted Pyramid...
@poteto (Lauren) from the Grok Bot team proposes a four-layer "inverted pyramid" framework for trusting AI Agent outputs: prioritize investing in codebase improvements and static analysis over rule files and manual review, and engineer the environment so Agents do the right thing by default.
@dotey: I remember saying half a year ago that I don't review PRs much anymore, and a lot of people in the comments disagreed, thinking that was irresponsible. Looking at it again now, more and more people aren't reviewing PRs. For instance, in the podcast I just listened to, Lauren Tan, who builds the Grok Bot at SpaceXAI, merges 2,500 PRs a month — and she also doesn't review them one by one: at night she lets the AI check and merge on its own, and she spot-checks in the morning.
Baoyu's commentary on the podcast interview with Lauren Tan and Matt Pocock: Lauren builds the Grok Bot at SpaceXAI and merges 2,500 PRs a month without reviewing each one, relying instead on AI-driven automated verification, code conventions, and an open-source Skill system called pstack to guarantee quality. The article cautions readers not to rush to copy her approach — first understand what makes it possible for her: models strong enough, token costs, the limits of AI verification, and having your own domain expertise to steer things.
@modal: What happens to code reviews, costs, and hiring when agents write most of the code? At Runtime, @_catwu (Claude Code) a…
在 Runtime 播客/讨论中，Claude Code 的 @_catwu 与 OpenCode 的 @thdxr 探讨了当 AI agent 编写大部分代码时，代码审查、Token 成本（可达薪资 1-2 倍）、事故复盘以及工程招聘标准将如何变化。
@Saccc_c: Beginners in AI Coding often overlook the crucial "review" step, causing bugs to pile up. But you can easily use Codex's built-in /review feature to quickly perform code review. It's simple, just two steps: 1. Set up an independent context for review mode, allowing it to start a new session for code review, to avoid...
Introduces a two-step method for code review using Codex's built-in /review feature, and mentions adversarial review techniques to improve AI review effectiveness.