{"slug": "how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news", "title": "How to Review AI-Written Code: Lessons From the Claude Code Team and Hacker News", "summary": "A Hacker News thread that drew 614 points and 748 comments surfaced a consensus on reviewing AI-written code: engineers should own the design and treat agents as implementers, then verify behavior through heavy testing and automated review rather than line-by-line reading. The discussion cited the Claude Code team's seven-layer review pipeline, published by Addy Osmani, Morgan Westlee Lunt and Qing Wang, in which a second agent reviews diffs in a fresh context and no PR can merge while bug or security findings remain open. Commenters warned that AI-generated tests can share the same blind spots as the code they check, and that at least one person must be able to explain any code shipped to production.", "body_md": "**Short answer:** Reviewing AI-written code requires moving design decisions upstream and automating verification before a human opens the pull request. Treat the agent as an implementer working against an explicit design spec. Run tests, linters, and a fresh-context subagent review locally, gate pull requests by change risk rather than code author, and route sensitive paths to human reviewers.\n\nOn October 19, 2026, Hacker News user rzk posted \"Ask HN: How to deal with shipping AI-written code you don't understand?\" on Hacker News. By October 23, 2026, the thread had 614 points and 748 comments. The post quoted a LinkedIn update from a Meta engineer detailing the core problem: \"I'm writing code these days and it all feels like a black box.\"\n\nThe same post explained why line-by-line review stops scaling when agents write most of a change: \"if we're going to spend our time checking each line of code, it's going to take forever.\"\n\nThe practical answers in the thread fall into two groups: control the design before the agent writes code, and verify behavior after it does. The Claude Code team's published process does both, and adds rules for when a human must approve.\n\nIn the largest subthread of 183 replies, bitwizeshift argued that control must happen before the model writes any code. The commenter wrote: \"I don't let the LLM design the code at all, I let it implement a design I have created.\" They added: \"I may not know how each unit is implemented, but I know each unit's responsibilities and how they interact with one another.\"\n\nOther engineers in the thread shared this focus on separating system architecture from code implementation. Commenter jedberg summarized the dynamic plainly: \"Your job is to design, the AI builds like the junior engineers. Then you review their work.\" Clear interfaces give the human reviewer a strict boundary against which to evaluate generated logic.\n\nVerification strategies focused heavily on rigorous execution rather than passive reading. Commenter ChrisMarshallNY stated: \"Testing. Lots and lots of testing.\" The same engineer observed: \"I don't find coding errors, but I do find implementation errors.\"\n\nRelying purely on automated tests brings its own specific trap. As commenter edwin0 pointed out: \"The part that makes me uneasy is when the AI writes both the code and the tests. They might agree with each other and still miss the same thing.\"\n\nAccountability remains a requirement for production systems. Commenter plastic041 emphasized: \"You must read the code before shipping it to production.\" The commenter continued: \"At least one person in your company should be able to explain the code!\"\n\nEngineers also adjust their oversight depending on the system layer. Commenter bob1029 noted that UI code is \"basically entirely vibe coded\", while \"For things like the SQL schema I am still doing things entirely by hand.\"\n\nClaude writes about 90 percent of Claude Code's own code. On October 15, 2026, Addy Osmani, Morgan Westlee Lunt and Qing Wang published \"How the Claude Code team does code review\", outlining their seven-layer pipeline.\n\nThe first layer verifies the work before anyone else looks at it. Claude runs tests, the build, and the linter and shows the output. Then \"a second agent reviews the diff in a fresh context\".\n\nThe second layer runs an automated AI review on every pull request against the whole repository and the PR's stated intent. Findings are checked by other agents and tagged Important, Nit, or Pre-existing. This directly connects to the advice from bitwizeshift and jedberg, as the explicit intent serves as the review target.\n\nThe third layer is a dedicated security review that holds blocking power. The team established a strict merge condition: \"A PR can't merge while any finding from the bug review or the security review is still open.\"\n\nThe fourth layer enforces blocking automated checks across the codebase. These are lint, type checks, tests on every platform, and a build.\n\nThe fifth layer applies human approval scaled strictly by risk. The sixth layer routes code into a merge queue with feature flags and gradual rollout, exposing new behavior to Anthropic employees first.\n\nThe seventh layer provides fast detection and fast rollback. It relies on feature flags that \"turn off without a deploy\" and a weekly on-call rotation.\n\nTo keep the automated reviewer accurate, the team converts past incidents into an eval set. They collected historical pull requests that caused incidents or reverts and run the reviewer against that test suite daily. Every update to the reviewer's prompts, tools, or model is scored against this incident library.\n\nAnthropic made Code Review for Claude Code generally available on October 15, 2026 for Claude Team and Enterprise organizations. Admins pick Quick, Standard (the default), or Deep per repository. Most reviews now take 6 to 10 minutes, down from about 20 minutes during the research preview.\n\nThe Claude Code team relies on three explicit rules to govern review responsibilities. First, \"The change sets the tier, not the author.\" Second, \"An agent's approval never counts as a person's.\" Third, \"An approval covers one specific commit.\"\n\nLow-risk changes require zero human approval once automated review and security checks are green. This tier covers documentation, copy updates, internal-only features, and additive changes isolated behind a feature flag. This matches the split bob1029 described, where interface code gets lighter review than the database schema.\n\nMedium-risk changes require approval from one person. This category includes ordinary product changes and sensitive areas such as caching logic, the auto-updater, or system prompts.\n\nHigh-risk changes require approval from two people. This tier is reserved for the highest-risk code alongside a small set of sensitive repository paths. This keeps human attention on the changes where a missed bug costs the most.\n\nThe Claude Code team measured the impact of this review system on their internal pull requests. The share of pull requests passing after just one review and fix round increased from 65% to 78%. Pull requests requiring five or more rounds dropped from 8.9% to 1.5%.\n\nReview iteration cycles shortened across the engineering team. The mean number of review rounds required to pass dropped from 2.08 to 1.32.\n\nThroughput expanded alongside code stability between June and September. During that period, total merged pull requests more than doubled while the share of pull requests that had to be reverted fell by more than 40 percent. These figures represent the team's own reported numbers.\n\nList all checks an agent can execute inside a short `CLAUDE.md` file. Add hooks that run formatters and linters automatically.\n\nRun `/code-review` and `/security-review` commands locally before opening a pull request, or trigger a fresh-context subagent review. The first human reviewer then starts from a diff that has already had one review.\n\nMaintain a `REVIEW.md` document in your repository and migrate repeated review feedback directly into its rules. Update your pull request template to require sections for \"Testing\", \"Risk\", and \"How to revert\".\n\nCap the number of review rounds. After the first few rounds, restrict automated re-review so it checks only the newly modified diff rather than re-evaluating the full branch.\n\nConfigure `CODEOWNERS` and branch protection rules so that auth, billing, CI workflows, release workflows, and installers always require a human approver.\n\nTrack human engineering time spent on reviews while monitoring revert and production incident rates as your primary guardrail. If revert rates rise, tighten the risk tiers or expand the automated eval suite.\n\nClaude Code can run directly with a Tokely API key through Tokely's Anthropic-compatible `/v1/messages` endpoint. Set `ANTHROPIC_BASE_URL` to `https://api.tokely.me` and `ANTHROPIC_AUTH_TOKEN` to your key, as in this single-line command from the Tokely guide:\n\n```\nANTHROPIC_BASE_URL=https://api.tokely.me ANTHROPIC_AUTH_TOKEN='<YOUR_TOKELY_API_KEY>' ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5 ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5 ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-5-5 claude\n```\n\nLocal `/code-review` and `/security-review` runs are billed per token from your existing Tokely balance.\n\nThe same Tokely API key also accesses OpenAI and Google models, such as GPT-6.1 Sol and Gemini 4 Argon, through the OpenAI-compatible Chat Completions endpoint. That makes it possible to send an agent's diff to a model from a different developer for a second review.\n\nThe switch is a change of the model ID. It is one option for edwin0's concern about code and tests sharing the same blind spot, not a proven fix. Tokely is an API gateway and does not run Anthropic's hosted Code Review GitHub App. For implementation details, consult the guide on [Claude Code with Tokely](https://tokely.me/blog/claude-code-cheaper-api) and the [Tokely Claude Code guide](https://tokely.me/docs/claude-code).\n\nThe community perspectives in this guide come from [the Ask HN thread](https://news.ycombinator.com/item?id=50151036) posted on October 19, 2026. The review framework and reported metrics come from [How the Claude Code team does code review](https://claude.dev/blog/solving-code-review-at-anthropic/) and the product announcement [Code Review is now generally available](https://claude.com/resources/articles/code-review-is-now-generally-available), both published on October 15, 2026.\n\n*Originally published at [tokely.me](https://tokely.me/blog/how-to-review-ai-written-code).*", "url": "https://wpnews.pro/news/how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news", "canonical_source": "https://dev.to/tokely/how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news-aba", "published_at": "2026-10-23 09:29:11+00:00", "updated_at": "2026-10-23 09:42:12.301221+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Hacker News", "Claude Code", "Anthropic", "Addy Osmani", "Morgan Westlee Lunt", "Qing Wang", "Meta", "LinkedIn"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news", "markdown": "https://wpnews.pro/news/how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news.md", "text": "https://wpnews.pro/news/how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news.txt", "jsonld": "https://wpnews.pro/news/how-to-review-ai-written-code-lessons-from-the-claude-code-team-and-hacker-news.jsonld"}}