---
title: 'In the News: October 16, 2026 (Extra 2)'
description: "Anthropic's Claude Code team reports doubled merged PRs and 40% fewer reverts under layered AI review; Postgres 19 slips after LLM review surfaces defects."
canonical_url: 'https://darkfactory.dev/news/2026-10-16-extra-2'
markdown_url: 'https://darkfactory.dev/news/2026-10-16-extra-2.md'
collection: news
date_published: '2026-10-16T16:20:00-04:00'
date_modified: '2026-10-16T16:20:00-04:00'
---

# In the News: October 16, 2026 (Extra 2)


The Claude Code team has published how it reviews code at the volume agents produce it, with before-and-after figures for reverts and review rounds. A separate account from the PostgreSQL project shows the other side of cheap review: it finds defects faster than people can fix them, and a release slips.

## 1. Claude Code team: merged PRs more than doubled while reverts fell by more than 40 percent

**[How the Claude Code team does code review](https://claude.dev/blog/solving-code-review-at-anthropic/)** · Addy Osmani, Morgan Westlee Lunt and Qing Wang · Anthropic, claude.dev, October 15, 2026

The authors say Claude writes about 90 percent of Claude Code's own code. From June to September, merged pull requests to its codebase "more than doubled while the share that had to be reverted fell by more than 40 percent." The review path has layers: the author's agent verifies its own work and a second agent reviews the diff in fresh context; every PR gets a Claude review in which several agents hunt for bugs and a separate group votes on each finding; a security review can block the merge; and human approval is set by a risk classifier, with none, one or two people required. Open findings from either review block the merge, and an agent's approval never counts as a person's.

The post also reports a failure of its own. One CLI PR went through more than fifty rounds of review and fixes overnight. By the authors' count, about 59% of what the reviewer kept flagging was code present since its first pass. After adding a three-round cap, diff-only re-review and no repeated findings, they report that PRs passing after one round rose from 65% to 78%, PRs needing five or more rounds fell from 8.9% to 1.5%, and mean reviews to pass fell from 2.08 to 1.32. They also say past incidents and reverts now form a daily eval set for the reviewer, and that they do not yet have circuit breakers that tighten approval when revert or incident rates rise. All figures are the team's own internal measurements; the post publishes no underlying data.

**Why it matters:** The useful part is the shape of the loop: risk-tiered human approval, a reviewer scored against your own incidents, and a cap on review rounds so an agent author and an agent reviewer do not keep each other busy. The numbers come from one vendor's own repository, so treat them as a design reference, not a benchmark.

## 2. PostgreSQL 19 slips to November after LLM-assisted review turns up more defects than the project could fix

**[The reverts will continue until morale improves](https://peter.eisentraut.org/blog/2026/10/09/the-reverts-will-continue-until-morale-improves)** · Peter Eisentraut · personal blog, October 9, 2026 · reported by [The Register](https://www.theregister.com/databases/2026/10/16/postgres-19-delayed-after-ai-reviewers-find-more-bugs-than-humans-can-fix/5303471), October 16, 2026

Eisentraut, a PostgreSQL committer who works at EDB, writes that about 8 to 10 significant features were reverted from the PostgreSQL 19 branch after beta began, against roughly one per cycle as normal. He attributes part of it to LLM-assisted code review: issues that "would not have surfaced until much later" now surface at once, "and then you're staring at a list of like forty defect reports." Even at three lines each, he says, a fixed overhead per report means "you run out of time." He adds that most affected features were written before such review was useful, so the effective quality bar rose after they were committed. He also lists other factors: some features had real architectural defects, and senior developers were pulled onto security fixes during part of the cycle. He describes it as "just my opinions at this point." The Register reports the release is now expected around November 19.

He does not blame "vibe coding," since the code predates it, and he argues that LLM-assisted fuzzing should become part of feature development.

**Why it matters:** This is a maintainer's account, not a measurement, and it mixes several causes. It is still a concrete case of review capacity outrunning fix capacity: if your reviewer is cheap and your fixers are not, the backlog shows up at release time. Item 1 shows one response on the review side, a round cap; it does not address the fix-capacity side.