AI Coding Agents Can Feed Reviewers Fake Tests and Diffs

GitHub ran an accidental ablation: adding tools to Copilot code review made results worse — token costs up, fewer issues caught — because generic instructions sent the agent browsing the whole repo. An instruction-only rewrite ('start from the diff, narrow with grep/glob, read exact evidence with view') recovered quality and cut average review cost 20%. Same model, same tools. That last part matters. The lever was context, not capability. Glean found the same physics: replacing step-wise JSON tool calls with code-based orchestration cut tokens 24% and won even on simple queries. Tool-call chatter is a fixed tax regardless of task complexity.

The overhead shows up in production stacks today: Claude Code ships ~33k tokens before reading your prompt vs OpenCode's ~7k. That is 4.7x for equivalent correct outputs. A VentureBeat survey (n=101, self-reported, directional) blames 57% of confidently-wrong agent answers on missing or inconsistent business context. The thing this doesn't tell you is causation, and n=101 self-reported is a weak instrument. But only 25% of enterprises run a governed context layer, which is consistent with the story.

Where the labs converged

Microsoft's Foundry team, OpenAI, and Anthropic independently landed on replacing one-shot RAG with an iterative retrieval sub-agent that plans queries, tries multiple sources, and returns a structured 'I don't know' when its budget runs out. Separately, a decoupled memory agent that tracks state and selectively reminds a frozen action model lifted pass rates on Terminal-Bench 2.0 and τ²-Bench with zero weight changes. Three labs plus two production case studies is a stronger prior than any vendor whitepaper. None of them ship ablations isolating which component drives the gain, so treat the mechanism as plausible, not established.

The caveat that matters: token spend is decoupling from throughput industry-wide. Reporting AI adoption by spend is a vanity metric while the actual lever — context quality — goes uninstrumented. Spend measures the meter, not the work.

When an agent fails, the cheapest fix on the table is narrowing what it sees, not upgrading what it runs.

The two-codebase problem has gated every new-architecture deployment: research in Transformers, then a weeks-long kernel rewrite before serving. Clement Delangue's claim is that Transformers models now run inside vLLM at native speed, often matching or exceeding hand-written implementations. If it holds, that tax goes away. 'Often matching' is the phrase to distrust, so validate on your architecture, not the happy-path demos. The check costs one engineer one day and pays off across a quarter.

On training, Prime Intellect's verifiers v1 stores agent rollout traces as message DAGs, moving trace growth from O(n²) to O(n) in turn count. On short tasks you won't notice. On 40-turn rollouts it separates feasible from financially absurd. Their cost anchor is a 100B reasoning model trained on 40-turn SWE tasks for 1000 RL steps on 6 H200 nodes in under 2 days. That is a vendor number with no ablations. It is still a reasonable starting point for scoping an agentic RL budget.

The MLOps-native item: Databricks Feature Views in public preview. Define a feature once, get the training pipeline and real-time serving at a claimed 200ms end-to-end from Kafka, governed through Unity Catalog. The target is train/serve skew, the offline/online logic divergence that quietly tanks production accuracy without ever failing a test. Caveats: the 200ms has no percentile qualifier (mean? p99? what load?), and preview means API churn and no SLA. The thing the number doesn't tell you is how it behaves under your traffic, so measure it there. Implement one currently-duplicated feature and diff offline versus online values. If they match, you have a migration path that retires a class of bugs, and possibly a standalone feature store.

Two of the most expensive taxes in ML infrastructure — model porting and dual feature logic — just became one-day spikes to eliminate.

The testable claim under the tier marketing: inference-time compute substitutes for model size. On the Artificial Analysis Coding Agent Index, budget-tier Luna at high reasoning effort matches or beats premium Sol at low effort on most agentic coding tasks, at a fraction of the cost. Per Sebastian Raschka, 'Ultra' is reportedly just 'Max' running 4 parallel subagents, which means top-tier pricing may be selling parallelism you can orchestrate client-side. The thing this index doesn't tell you is the per-task breakdown or the sample sizes, neither of which ship with it. Treat it as a hypothesis to reproduce. A cheap grid search with a large potential payoff.

The harness decides the economics, not the model. In Codex, a documented open bug makes subagents inherit the parent's model and effort level. Run Sol at Ultra and every subagent runs Ultra too. That is the fastest way to burn a session on one task. Claude Code sets model and effort per subagent independently, which makes it the better orchestration layer even for OpenAI's own models. The stability signals point the same direction. Sol's context window was rolled back from 372k to 272k after billing side effects, alongside a fix for overactive multi-agent spawning at high effort. If the frontier lab can't keep long-context multi-agent loops economically stable, the token burn wants instrumenting before finance finds it.

The metric shift finishes the picture. Cognition's Devin Fusion reports its lead model never edits code in 81% of delegated runs, beating Opus 4.8 on cost-per-task through delegation, not raw capability. Correlation with capability is not what is driving that number. Meta's Muse Spark 1.1 at $1.25/$4.25 per M tokens, a claimed 75% undercut with zero published coding benchmarks, is the same lesson from the price side. A sticker price without a pass rate is not a decision input.

Before renewing a premium tier, prove a cheap model with the effort dial turned up can't already do the job on your own harness.