KI-generierten Code prüfen: Designentscheidungen nach vorn verlagern
Wer Code von Claude Code und ähnlichen Agenten reviewen will, sollte Designentscheidungen vorab in einer Spezifikation festlegen und Tests, Linter und Reviews durch einen Subagenten automatisieren, bevor ein Mensch den Pull Request sieht.
Veröffentlicht am 23. Okt. • Zuerst veröffentlicht auf tokely.me
Die kurze Antwort: Die Überprüfung von KI-geschriebenem Code erfordert, dass Designentscheidungen nach vorn verlagert und die Verifizierung automatisiert wird, bevor ein Mensch den Pull Request überhaupt öffnet. Behandle den Agenten als Implementierer, der gegen eine explizite Designspezifikation arbeitet. Führe Tests, Linter und eine Subagent-Review mit frischem Kontext lokal aus, kontrolliere Pull Requests anhand des Änderungsrisikos statt anhand des Codeautors und leite sensible Pfade an menschliche Reviewer weiter.
Am 19. Oktober 2026 postede der Hacker-News-Nutzer rzk die Frage "Ask HN: How to deal with shipping AI-written code you don't understand?" auf Hacker News. Bis zum 23. Oktober 2026 hatte der Thread 614 Punkte und 748 Kommentare erreicht. Der Beitrag zitierte ein LinkedIn-Update eines Meta-Ingenieurs, das das Kernproblem auf den Punkt brachte: "Ich schreibe heutzutage Code, und alles fühlt sich an wie eine Blackbox."
Derselbe Beitrag erklärte, warum eine Zeile-für-Zeile-Prüfung nicht mehr skaliert, wenn Agenten den Großteil einer Änderung schreiben: "Wenn wir unsere Zeit damit verbringen würden, jede Zeile Code zu prüfen, würde das ewig dauern."
Die praktischen Antworten im Thread lassen sich in zwei Gruppen einteilen: die Kontrolle des Designs, bevor der Agent Code schreibt, und die Verifizierung des Verhaltens, nachdem er es getan hat. Der veröffentlichte Prozess des Claude-Code-Teams macht beides und ergänzt Regeln dafür, wann ein Mensch zustimmen muss.
Im größten Unterthread mit 183 Antworten argumentierte bitwizeshift, dass die Kontrolle stattfinden muss, bevor das Modell auch nur eine Zeile Code schreibt. Der Kommentator schrieb: "Ich lasse das LLM den Code überhaupt nicht entwerfen, ich lasse es ein Design implementieren, das ich erstellt habe." Er ergänzte: "Ich kenne vielleicht nicht die Implementierung jeder einzelnen Einheit, aber ich kenne die Verantwortlichkeiten jeder Einheit und wie sie miteinander interagieren."
Andere Ingenieure im Thread teilten diesen Fokus auf die Trennung von Systemarchitektur und Codeimplementierung. Der Kommentator jedberg fasste die Dynamik schlicht zusammen: "Deine Aufgabe ist das Design, die KI baut wie die Junior-Ingenieure. Dann prüfst du ihre Arbeit." Klare Schnittstellen geben dem menschlichen Reviewer eine strenge Grenze, an der er generierte Logik bewerten kann.
Die Verifizierungsstrategien konzentrierten sich stark auf gründliche Ausführung statt auf passives Lesen. Der Kommentator ChrisMarshallNY stellte fest: "Testing. Ganz, ganz viel Testing." Derselbe Ingenieur beobachtete: "Ich finde keine Coding-Fehler, aber ich finde Implementierungsfehler."
Sich rein auf automatisierte Tests zu verlassen, bringt eine eigene spezielle Falle mit sich. Wie der Kommentator edwin0 anmerkte: "Was mich beunruhigt, ist, wenn die KI sowohl den Code als auch die Tests schreibt. Sie könnten sich gegenseitig bestätigen und trotzdem dasselbe übersehen."
Verantwortlichkeit bleibt eine Anforderung für Produktionssysteme. Der Kommentator plastic041 betonte: "Du musst den Code lesen, bevor du ihn in Produktion bringst." Der Kommentator fuhr fort: "Mindestens eine Person in deinem Unternehmen sollte den Code erklären können!"
Ingenieure passen ihre Aufsicht auch je nach Systemebene an. Der Kommentator bob1029 bemerkte, dass UI-Code "im Grunde komplett vibe coded" sei, während er "bei Dingen wie dem SQL-Schema weiterhin alles vollständig von Hand macht."
Claude schreibt etwa 90 Prozent des eigenen Codes von Claude Code. Am 15. Oktober 2026 veröffentlichten Addy Osmani, Morgan Westlee Lunt und Qing Wang den Beitrag "How the Claude Code team does code review", in dem sie ihre siebenschichtige Pipeline beschreiben.
Die erste Schicht verifiziert die Arbeit, bevor jemand anderes sie sich ansieht. Claude führt Tests, den Build und den Linter aus und zeigt die Ausgabe. Anschließend "prüft ein zweiter Agent den Diff in einem frischen Kontext".
Die zweite Schicht führt eine automatisierte KI-Prüfung für jeden Pull Request gegen das gesamte Repository und die angegebene Absicht des Pull Requests durch. Die Ergebnisse werden von anderen Agenten überprüft und als Important, Nit oder Pre-existing markiert. Das verbindet sich direkt mit dem Rat von bitwizeshift und jedberg, denn die explizite Absicht dient als Prüfziel der Review.
Die dritte Schicht ist eine dedizierte Sicherheitsprüfung mit blockierender Wirkung. Das Team legte eine strenge Merge-Bedingung fest: "Ein Pull Request kann nicht gemerged werden, solange ein Ergebnis aus dem Bug-Review oder dem Security-Review noch offen ist."
Die vierte Schicht erzwingt blockierende automatisierte Checks über die gesamte Codebasis. Dies umfasst Lint, Typprüfungen, Tests auf jeder Plattform sowie einen Build.
Die fünfte Schicht wendet menschliche Freigabe an, die strikt nach Risiko skaliert. Die sechste Schicht leitet Code in eine Merge-Queue mit Feature-Flags und schrittweisem Rollout, wobei neues Verhalten zuerst Anthropic-Mitarbeitern zugänglich gemacht wird.
Die siebte Schicht ermöglicht schnelle Erkennung und schnelles Rollback. Sie stützt sich auf Feature-Flags, die "ohne Deployment abgeschaltet werden können", und eine wöchentliche On-Call-Rotation.
Um den automatisierten Reviewer präzise zu halten, wandelt das Team vergangene Vorfälle in einen Eval-Satz um. Sie sammelten historische Pull Requests, die zu Vorfällen oder Reverts geführt hatten, und lassen den Reviewer diese Testsuite täglich durchlaufen. Jede Aktualisierung der Prompts, Tools oder des Modells des Reviewers wird gegen diese Vorfällsbibliothek bewertet.
Anthropic machte Code Review für Claude Code am 15. Oktober 2026 allgemein für Claude-Team- und Enterprise-Organisationen verfügbar. Administratoren wählen pro Repository Quick, Standard (den Standardwert) oder Deep. Die meisten Reviews dauern inzwischen 6 bis 10 Minuten, verglichen mit rund 20 Minuten während der Research Preview.
Das Claude-Code-Team stützt sich auf drei explizite Regeln, um die Review-Verantwortlichkeiten zu steuern. Erstens: "Die Änderung bestimmt die Stufe, nicht der Autor." Zweitens: "Die Freigabe eines Agenten zählt nie als die einer Person." Drittens: "Eine Freigabe gilt für genau einen bestimmten Commit."
Änderungen mit niedrigem Risiko erfordern keine menschliche Freigabe, sobald automatisiertes Review und Sicherheitsprüfungen grün sind. Diese Stufe umfasst Dokumentation, Textaktualisierungen, rein interne Funktionen und additive Änderungen, die hinter einem Feature-Flag isoliert sind. Das entspricht der Aufteilung, die bob1029 beschrieb, bei der Interface-Code leichter geprüft wird als das Datenbankschema.
Änderungen mit mittlerem Risiko erfordern die Freigabe einer Person. Diese Kategorie umfasst gewöhnliche Produktänderungen und sensible Bereiche wie Caching-Logik, den Auto-Updater oder Systemprompts.
Änderungen mit hohem Risiko erfordern die Freigabe von zwei Personen. Diese Stufe ist dem Code mit dem höchsten Risiko vorbehalten, zusammen mit einer kleinen Menge sensibler Repository-Pfade. So bleibt die menschliche Aufmerksamkeit auf den Änderungen gerichtet, bei denen ein übersehener Bug am teuersten wird.
Das Claude-Code-Team hat die Auswirkungen dieses Review-Systems auf ihre internen Pull Requests gemessen. Der Anteil der Pull Requests, die nach nur einer Review- und Korrekturrunde durchgingen, stieg von 65% auf 78%. Pull Requests, die fünf oder mehr Runden erforderten, sanken von 8,9% auf 1,5%.
Die Review-Iterationszyklen verkürzten sich im gesamten Engineering-Team. Die mittlere Anzahl der Review-Runden bis zur Freigabe sank von 2,08 auf 1,32.
Der Durchsatz wuchs zwischen Juni und September gemeinsam mit der Codestabilität. In diesem Zeitraum mehr als verdoppelte sich die Gesamtzahl der gemergten Pull Requests, während der Anteil der Pull Requests, die zurückgesetzt werden mussten, um mehr als 40 Prozent sank. Diese Zahlen stellen die vom Team selbst berichteten Werte dar.
Liste alle Checks, die ein Agent ausführen kann, in einer kurzen CLAUDE.md-Datei auf. Füge Hooks hinzu, die Formatter und Linter automatisch ausführen.
Führe die Befehle /code-review und /security-review lokal aus, bevor du einen Pull Request öffnest, oder starte eine Subagent-Review mit frischem Kontext. Der erste menschliche Reviewer beginnt dann mit einem Diff, der bereits eine Review durchlaufen hat.
Pflege ein REVIEW.md-Dokument in deinem Repository und übernimm wiederkehrendes Review-Feedback direkt in dessen Regeln. Aktualisiere deine Pull-Request-Vorlage so, dass sie Abschnitte für "Testing", "Risk" und "How to revert" verlangt.
Begrenze die Anzahl der Review-Runden. Nach den ersten Runden beschränkst du das automatisierte Re-Review so, dass es nur den neu geänderten Diff prüft, statt den gesamten Branch neu zu bewerten.
Konfiguriere CODEOWNERS und Branch-Protection-Regeln so, dass Auth, Billing, CI-Workflows, Release-Workflows und Installer immer einen menschlichen Approver erfordern.
Verfolge die menschliche Engineering-Zeit, die für Reviews aufgewendet wird, und überwache Revert- und Produktionsvorfallraten als deine wichtigste Schutzleitschiene. Steigen die Revert-Raten, verschärfe die Risikostufen oder erweitere die automatisierte Eval-Suite.
Claude Code kann direkt mit einem Tokely-API-Key über den Anthropic-kompatiblen /v1/messages-Endpunkt von Tokely ausgeführt werden. Setze ANTHROPIC_BASE_URL auf https://api.tokely.me und ANTHROPIC_AUTH_TOKEN auf deinen Key, wie in diesem Einzeiler aus dem Tokely-Guide:
ANTHROPIC_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 Enter fullscreen mode Exit fullscreen mode Lokale /code-review- und /security-review-Läufe werden tokenbasiert von deinem vorhandenen Tokely-Guthaben abgerechnet.
Derselbe Tokely-API-Key bietet auch Zugang zu OpenAI- und Google-Modellen wie GPT-6.1 Sol und Gemini 4 Argon über den OpenAI-kompatiblen Chat-Completions-Endpunkt. Dadurch ist es möglich, den Diff eines Agenten zur zweiten Prüfung an ein Modell eines anderen Entwicklers zu senden.
Der Wechsel ist eine Änderung der Modell-ID. Er ist eine Option für edwin0s Bedenken, dass Code und Tests denselben blinden Fleck teilen, kein bewiesener Fix. Tokely ist ein API-Gateway und betreibt nicht Anthropics gehostete Code-Review-GitHub-App. Für Implementierungsdetails konsultiere den Guide zu Claude Code mit Tokely und den Tokely-Claude-Code-Guide.
Die Community-Perspektiven in diesem Ratgeber stammen aus dem Ask-HN-Thread vom 19. Oktober 2026. Der Review-Rahmen und die berichteten Kennzahlen stammen aus dem Artikel How the Claude Code team does code review und der Produktankündigung Code Review is now generally available, die beide am 15. Oktober 2026 veröffentlicht wurden.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 23 • Originally published at tokely.me
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.
On 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."
The 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."
The 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.
In 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."
Other 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.
Verification 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."
Relying 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."
Accountability 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!"
Engineers 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."
Claude 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.
The 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".
The 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.
The 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."
The fourth layer enforces blocking automated checks across the codebase. These are lint, type checks, tests on every platform, and a build.
The 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.
The 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.
To 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.
Anthropic 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.
The 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."
Low-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.
Medium-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.
High-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.
The 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%.
Review iteration cycles shortened across the engineering team. The mean number of review rounds required to pass dropped from 2.08 to 1.32.
Throughput 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.
List all checks an agent can execute inside a short CLAUDE.md file. Add hooks that run formatters and linters automatically.
Run /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.
Maintain 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".
Cap 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.
Configure CODEOWNERS and branch protection rules so that auth, billing, CI workflows, release workflows, and installers always require a human approver.
Track 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.
Claude 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:
ANTHROPIC_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 Enter fullscreen mode Exit fullscreen mode Local /code-review and /security-review runs are billed per token from your existing Tokely balance.
The 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.
The 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 and the Tokely Claude Code guide.
The community perspectives in this guide come from the Ask HN thread posted on October 19, 2026. The review framework and reported metrics come from How the Claude Code team does code review and the product announcement Code Review is now generally available, both published on October 15, 2026.