We can't find the internet
Attempting to reconnect
Something went wrong!
Hang in there while we get back on track
The Claude Code team's review pipeline
Addy Osmani shared a write-up of how the Claude Code team reviews code. Claude writes about 90% of Claude Code. From June to September, merged PRs more than doubled while the share of PRs that had to be reverted fell by more than 40% . The team still reviews code. Review now happens continuously while the code is written, so Claude has usually reviewed and corrected a change at least once before a human looks at it . Their goal is for most PRs to merge with at most one person in the loop, and they treat revert and incident rates as a guardrail .
Patterns you can copy:
- Ask for proof before opening a PR. Have Claude run something, such as tests, the build, or a screenshot compared with the design: "Instead of saying the task is done, we ask it to show us the result." Then a subagent with fresh context reviews the diff. Many team members also run their own skills for bug hunting, shrinking the diff, end-to-end validation and checking UI against design guidelines . Boris Cherny estimates a verification process improves output quality by 2–3× .
-
Fix repeated findings at the source. If the reviewer keeps flagging the same issue, change the skill, add a lint rule, or update the docs. Keep
CLAUDE.mdshort, since it is loaded into every review. InREVIEW.md, owners say what counts as failure, limit nitpicking, list paths to ignore, require file and line references, and ask for a top-level summary that includes a count and a clear "no issues" when there are none . -
Filter findings with several agents. Agents hunt for bugs in parallel. A separate vote keeps only findings with enough support, and findings that are only about style or cleanup are dropped. The team A/B tested these filters on its own PRs. Comments are labeled Important, Nit or Pre-existing . These features ship as Code Review for Claude Code on Team and Enterprise plans, with a lighter local
/code-review. Since the preview, the share of internal PRs getting substantive comments rose from 16% to 54% . - Cap review loops. One PR went back and forth between agent author and agent reviewer more than 50 times overnight. About 59% of what the reviewer kept flagging was code that had been there since the first pass . The fix: after three cycles, the reviewer asks the author to rethink the approach. Later rounds look only at the diff, name the class of bug, and don't repeat findings already reported .
- Set human review by the change's risk, not the author. Classifiers decide the risk level. Sensitive paths and CI workflow files always need another approval. Agent approvals don't count as human approvals, and approval must be given again after untrusted commits .
- Use past incidents as the eval set. The review system is tested daily against a collection of PRs that caused incidents. Noise is measured by how people respond to each comment .
Humans still decide whether to build something, audit dangerous code like billing and CI, review architecture, check the evidence, and answer for every change . On the same theme, Theo posted: "If you're still merging most PRs by hand, you're behind" . Armin Ronacher polled whether people still write more than 20% of their code by hand. He reads the results so far as showing the base is "divided" .
Theo: Opus fixes UI, and the hallucination record of another model
Robin Ebers criticized T3 Code's fonts, border radius, icons and font hierarchy, and pointed to Capy as inspiration . Theo asked whether he could turn the UI into "a hill climb for Opus" . He opened pingdotgg/t3code#24837 , later posted "Holy shit it worked" , and called Opus 5.5 "the greatest model of all time" . After a few hours on the build, he said he hadn't realized how much better a cleaned-up design would feel . If you have a vague design complaint, try turning it into a goal the model can iterate toward.
He also ran a thread on an Ubuntu machine that drove an iOS simulator on a Mac mini connected through T3 Code. He calls it "the best iOS dev experience I've ever had" .
Theo's council skill has models review each other's work. He now lists specific Gemini hallucinations from one run: a line number (line 173 cited in a 72-line file), IP addresses, command arguments, and function exports and returns . He calls it "a straight up liability in your stack" . These are his own observations, not a benchmark.
LangChain's OpenSWE: identity and sandbox design
LangChain's engineering agent, OpenSWE, drafts PRs and reviews every PR . When you message it, it acts as you and opens PRs under your GitHub handle. When it reviews in the background, it uses its own GitHub App identity . It picks a sandbox base image based on the channel or user. It runs outside the sandbox and executes code inside it, using a secret proxy to reach authenticated services . A new PR automatically triggers a review .
Shorter notes
- Compaction (antirez). Salvatore Sanfilippo disagrees with commenters who say you should never reach context compaction. He says compaction comes up less often for him, and models are less disoriented afterward with Astra and especially Opus 5.5. The model now has an explicit tool to search the session's JSONL log; before, he had to tell it to look there .
- Spending (antirez). He had switched his Anthropic plan from 20x to 5x by accident and, using Opus 5.5 heavily, never hit the weekly limit, so he kept it . He argues for flat subscriptions, for example a €200 reimbursement per employee, over paying API rates . He also argues that agents give the most leverage to developers with product vision who steer a project at a high level .
- Ramp-up prompt (TheStandup). On a new codebase, ask the AI to find the relevant repos, explain why something behaves the way it does, and read the commits to trace the original decision. One host says this covers "at least a good 80%" of the questions that slow onboarding .
- Keep your data portable. A user said Grok Bot deleted weeks to months of work for him and others . Kent C. Dodds responded by recommending Kody, which keeps your work outside any one walled garden so you can switch agents without a migration .
- Sanfilippo argues coding agents amplify product and project judgment: developers who can maintain a high-level product vision and steer project concepts gain more leverage than those whose strength is mainly coding line by line.
- In his own use, he says he relies heavily on Opus 5.5; after accidentally switching his Anthropic plan from 20x to 5x, he never reached the weekly usage limit and kept the 5x tier. He recommends favoring flat subscriptions over metered API spending and suggests reimbursing workers for AI access, including a proposed €200 reimbursement.
- For enterprise spending, he describes Accenture’s reported arrangement as $29 baseline access, with larger developer token budgets approved for specific projects; he says this helps curb indiscriminate use and allows AI costs to be charged to clients on fixed-price contracts.
- From June to September, Claude Code’s team more than doubled merged PR volume while reducing the share of PRs that had to be reverted by over 40%; they moved review into the coding workflow so Claude catches routine bugs before human review.
- Before opening a PR, ask Claude to demonstrate runnable evidence—such as tests, a build, or a screenshot compared with the design—then have a fresh-context subagent review the diff. The team also uses bug-hunting, diff-reduction, end-to-end validation, and UI-guideline skills; Claude Code creator Boris Cherny estimates verification can improve output quality two- to threefold.
-
Put review expectations in concise project guidance: keep
CLAUDE.mdfocused on stack, conventions, goals, and non-goals; useREVIEW.mdto define failure modes, ignored paths, and requirements such as file-and-line references and a top-level summary. Claude reviews every PR; parallel agents hunt for bugs and a separate vote filters findings, while style and cleanup findings are suppressed. - Bound agent review loops: after three cycles, ask the author to reassess the approach; later reviews should focus on the diff, specify bug classes, and avoid repeating known findings. Keep humans responsible for dangerous code, architecture, verifying evidence, and ownership of shipped changes.
For local-model evaluation, Nick Reese says his team tuned a 4× AMD R9700 server on 100 real jobs from USA Arms and achieved almost 9× more correct answers per hour; the post does not specify a comparison baseline for that improvement. Reese says relying on popular TPS benchmarks would have cost them a third of their work. The post does not identify the jobs as coding tasks.
Against commenters’ claim that a coding agent should never need context compaction, Salvatore Sanfilippo says it happens less often in his experience and post-compaction disorientation has improved; he specifically cites Opus 5.5. He says the model now has an explicit tool to search the conversation’s JSONL—whereas he previously had to tell it to inspect the log—and learns to use past context.
- A practical codebase-ramp-up prompt discussed: ask AI to find relevant repos, explain why a behavior exists, and inspect commits to trace the original decision; one participant says this can resolve “at least a good 80%” of questions that otherwise slow onboarding. They also suggest asking AI to explain unfamiliar bespoke technology.
- For coding-agent systems, consider agent-to-agent communication, testing, and compiler feedback as potential bottlenecks: a participant expects slower links to constrain improvement and create unevenly advancing pockets, while presenting this as a likely pattern to study rather than a proven result.
Dodds used his Grok bot to build a Kody PWA for plunking out choir notes, hosted on Kody with a custom domain; he says he likes being able to customize it to exactly what he wants. He says the app can be forked and changed, and also describes having the bot make a sacrament-meeting app to help his young children focus on the Savior.
Riley Brown says Anthropic models stopped his AI workflow for cutting a cybersecurity video, returning “can't continue”; he attributes the failure to the video's topic. This is a firsthand model-reliability caveat, but the reported task was video editing rather than coding-agent use.
Kent C. Dodds recommends @kodykoala to keep agent work outside a walled garden, so developers can switch their preferred agent without migration; he made the recommendation in response to reports that Grok Bot had deleted weeks or months of users’ work .
T3 Code Nightly shipped a broken update; affected users were told to revert to Stable while a fix was prepared. Stable was unaffected, and the issue was client-side/UI-only, with no data loss or remote-server impact. The fixed Nightly build was available by redownloading from the Nightly channel.
Theo calls Opus 5.5 “the greatest model of all time” and says he is still struggling to find its ceiling, a strong positive firsthand assessment without a specific coding workflow or benchmark.
Theo’s council skill reviews work with various models and includes a “Gemini the jester” section; he says Gemini hallucinated in over 80% of runs. In one reported run, Gemini fabricated line numbers (including line 173 in a 72-line file), IP addresses, command or script arguments, and function exports and returns.
Armin Ronacher's poll asked whether people still write more than 20% of code by hand; he said results so far across Twitter, Bluesky, and Mastodon showed a clearly divided base. He acknowledged concerns about small samples and shared an updated graph with more respondents, while noting that polling on Bluesky was harder because it lacks a poll feature.
Theo said T3 Code had roughly matched Codex’s “28 days of improvements” pace, with at least one solid improvement each day of the month, and set a goal of shipping one meaningful T3 Code improvement daily. He later said the one-per-day commitment was slowing releases despite having five changes he wanted to ship, and considered dropping multiple updates in one day.
Theo proposed turning T3 Code’s UI into a “hill climb for Opus,” an agent-driven interface-improvement challenge, alongside Robin Ebers’ critique that the fonts, border radius, icons, and font hierarchy kept him reinstalling the app; Robin suggested a UI/UX designer and cited Capy as clean inspiration. Theo later said it seemed to be working, and described Ebers’ PR as improving.
Theo used T3 Code to connect his Ubuntu/T3OS computer to a Mac mini running the iOS simulator, and called it his best iOS development experience; he said the setup also works on regular Ubuntu.
Theo’s setup used an Ubuntu computer with an iOS simulator running on a Mac mini connected via T3 Code; he called it his best iOS development experience . He also says the device simulator works fully on iOS and describes testing the Duo simulator remotely while using a Duo .
DHH says RAWmakase handled his Japan and China family-photo edits, with his Lightroom presets working and only minor issues left; he judged it 97% ready and said he could drop Adobe Creative Suite . RAWmakase’s developer reports that agents made minimal progress on highlights/shadows parity research and were going in circles, prompting consideration of a different approach or waiting for Opus 6.5 .
- LangChain’s OpenSWE drafts PRs and reviews all PRs; it listens for newly created PRs to trigger background reviews. When a user messages it, it opens PRs as that user; background reviews use its own GitHub App identity.
- OpenSWE runs code in a sandbox, selecting a base image based on the channel or user; LangChain uses a secret proxy so sandboxed code can securely reach authenticated services.
Theo said T3 Code’s search overhaul aimed to make results more relevant, forgiving, recent, and clear . He said the team had pretty much kept pace with Codex’s “28 days of improvements” by shipping at least one solid improvement each day that month, and planned to continue aiming for one meaningful T3 Code improvement daily .
