Dev Breakfast · 2026-10-17

Claude wrote roughly 90% of Claude Code's own code. Merged PRs have more than doubled while the revert rate dropped by over 40% — their method: every finding is first cross-voted by a panel of agents, and only when it collects enough votes does it ever reach a human. I think the part truly worth stealing isn't "let AI write the code", but this filtering mechanism that rescues humans from the reading pile.

Claude wrote 90% of Claude Code's code — how do they review it?

Claude wrote about 90% of Claude Code's own code. That sentence is the opening line of the entire official blog post, and it's the premise for everything that follows — once code output reaches this level, line-by-line human review becomes physically impossible. From June to September, the number of PRs merged into the Claude Code repo more than doubled, while the proportion reverted in the same period actually fell by more than 40%. They didn't cancel review; they handed most of the "reading code" work to machines and reserved human time for questions machines can't answer. If you're being crushed by a PR queue right now, these numbers are worth writing down first.

How it works concretely: every PR goes through a Claude review pass before a human looks at it. Taking the diff against the whole repo and the intent stated in the PR, it asks three questions — does this change actually solve the problem it set out to solve, does it fit the system design, and could it break something else. More crucially, every finding is cross-validated by a panel of agents before it's shown to a human, and only goes out once it has enough votes; findings that are purely about style, diagnostics, or cleanup are dropped outright — this filter survived because they A/B tested it on their own PRs. What goes out is sorted by severity and tagged as Important, Nit, or Pre-existing — bugs not introduced by this PR aren't counted against the author. Security review is a separate layer: if a bug review or security review has even one open finding, the PR cannot merge — either fix it, or close the thread with a sentence of justification (which is also the escape hatch for false positives). Admins can configure three tiers per repo — Quick, Standard, Deep — with Deep used on repos where a missed bug costs more than extra time. During the research preview rollout, the share of PRs receiving substantive review comments internally rose from 16% to 54%.

One detail deserves to be pulled out separately: when the automated reviewer keeps flagging the same thing, their response is to fix the source — change the skill, add a lint rule, or update CLAUDE.md and REVIEW.md. CLAUDE.md tells Claude what the project is (tech stack, conventions, goals and non-goals); it's loaded on every review, so in a large codebase it must be written short. REVIEW.md is written by the code owner and spells out what counts as failure on their turf — for docs it's "it's lying", for configs it's "it routes wrong" — and requires every finding to cite a filename and line number as evidence; guessing from variable names isn't accepted. Their own judgment is that "has anyone read this code" is an imprecise proxy metric; the real question is "where could this change break, and which check — automated or human — is the right tool to catch it". The original post doesn't say whether any incident occurred after this process was adopted.

💡 Chef's take: I'm on the side of "reserving human time for what only humans can do", but the precondition is that the revert rate doesn't rise — they cut it by 40%, and that number is the certificate of quality for this process. Without it, the review time you saved just moves over to fixing bugs.

Sources:

• How the Claude Code team does code review

Postgres 19 delayed: AI reviewers found more bugs than humans can fix

Postgres 19 has been postponed, for a slightly counterintuitive reason: the AI review tooling reported issues faster than humans can process them. The original piece has only a headline and a lede — no bug count, no length of the delay, no mention of who is running these review tools — so I won't fill in details on its behalf. But the event itself is worth noting for anyone writing code: AI bug-finding is now strong enough to stall the release cadence of a mature database, yet how much of what it reports is a real problem versus noise — nobody is filtering that for you. Flip it around: don't rush to bolt AI review into CI as a gatekeeper. Right now it's more like a very chatty colleague who never gets tired, and someone has to be able to absorb the output.

Sources:

• hackernews · magoghm

android/skills hits GitHub Trending, but the repo page says nothing about what it does

android/skills appeared on GitHub Trending with a trend score of 35. The repo lives under the android org, but the About section on the page is empty — no description, no homepage link — and the scraped body is basically just GitHub's own navigation menu, so there's no telling what's inside. The only thing that can currently be confirmed is this: an official org opened a repo called skills, and it got pushed onto the trending list. Whether to click through depends on your own associations with the word "skills" in the current context — but the repo doesn't say, and I won't say for it.

Sources:

• android/skills

The capacity arithmetic of 64-dim keys: ~64 memories in linear layers, over a million in self-attention

A long essay that re-derives the Transformer from scratch without looking anything up, purely by intuition, treating linear layers, MLPs, and self-attention uniformly as three kinds of "memory warehouses", and using an interference-to-signal ratio to work out how many memories each can hold. The author's numbers: with 64-dimensional keys, a linear layer holds roughly 64 memories, an MLP about 2,700, and self-attention can exceed a million. For people who tune models daily, the value of this perspective isn't memorizing the conclusions but explaining what widening, deepening, and swapping attention each actually buys you — capacity and recall rate are two separate ledgers, not the same thing. If you want to understand what attention is actually storing, this piece is worth opening.

Sources:

• You could have invented transformers from memory

Running 816B on a single Mac Studio: Apple's MLX lowers the two-machine bar to one

In a previous issue we talked about Muse Spark Open: 816B parameters, open weights, and it needed two Mac Studios just to run — not a low bar. Today Apple's ML research offers a turn — the latest MLX adds RDMA over Thunderbolt, so a single Mac Studio (up to 512GB unified memory) can run it, and a four-machine cluster decodes at over 36 tokens/sec, faster than a human reads.

Mind the test conditions: Muse Spark Open is a MoE — of the 816B, only 42B are active parameters — and it was measured under NVFP4 4-bit quantization, not at native precision. The same batch also tested Mistral Medium 3.5 (128B) and Qwen 3.8 (27B), comparing the M5 Ultra and M3 Ultra generations, with metrics of TTFT, throughput, and peak power draw.

So "it takes two machines to run" wasn't overturned — it was lowered: start on one machine, scale out across many. If you want to run large models locally, what you should be looking at now is quantization and memory footprint, not parameter count.

Sources:

• Apple ML Research: Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio

---

This issue selected 5 items from 51 pieces of information across X / Hacker News / GitHub Trending over the past 24 hours (collected and written hourly throughout the day, fact-checked, then edited in the morning). Content is LLM-assisted, each item comes with an original source link, and important decisions should be cross-verified.