Boris Cherny, bei Anthropic verantwortlich für Claude Code, hat heute einen Satz geschrieben, den ich seit Stunden mit mir herumtrage:
Production code written by Claude should have a higher bar than if it was written by a human.
Dahinter steht eine Aufzählung dessen, was bei Anthropic läuft, damit das eingehalten wird: viele Lint-Regeln, viele Tests, End-to-End-Tests, die Claude fährt, Fuzzer mit Claude dahinter, die täglich laufen, automatisierte Code-Reviews, automatisierte Security-Reviews, automatisiertes Refactoring. Ohne das, so Cherny, landet man bei einem Wust, der später schwer zu warten ist.
Warum “höher” und nicht “gleich”
Der naheliegende Einwand ist, dass Code Code ist. Wenn er funktioniert, getestet ist und gelesen wurde, ist die Herkunft egal.
Der Einwand stimmt für das einzelne Stück Code. Er stimmt nicht für die Menge. Wenn du an einem Tag das Fünffache produzierst, kommt die Prüfung nicht mehr hinterher - und die Prüfung war schon vorher der Engpass, nicht das Schreiben. Eine Stichprobe, die bei zwanzig Pull Requests pro Woche funktioniert hat, deckt bei hundert kaum noch etwas ab.
Dazu kommt die Art der Fehler. Von einem Menschen kennst du sie: Er vergisst den Randfall, den er noch nie gesehen hat, und er schreibt keine dreihundert Zeilen, die schön aussehen und an einer Stelle das Falsche tun. Modelle machen genau das gelegentlich, und zwar in einer Form, die beim Überfliegen richtig wirkt. Solche Fehler findet kein müder Reviewer um 17 Uhr, sondern ein Test.
Die Liste ist die eigentliche Nachricht
Schau dir an, was da steht. Lint-Regeln und Tests hat fast jedes Team. Aber tägliche Fuzzer, automatisierte Security-Reviews und automatisiertes Refactoring? Das haben die wenigsten - und Anthropic fährt es, weil ein großer Teil des eigenen Codes von Claude kommt.
Der Punkt dahinter ist unbequem: Wer die Produktion beschleunigt, muss die Kontrolle mitbeschleunigen. Und das geht nur maschinell. Menschliches Review skaliert nicht mit, egal wie diszipliniert das Team ist.
Es passt übrigens zu dem, was Simon Willison und Alex Garcia diese Woche bei Datasette gemacht haben: Sie haben ein Audit mit drei Modellen gefahren und jeden Befund erst durch einen Test bestätigen lassen. Dieselbe Bewegung von zwei Seiten. Modelle schreiben mehr Code, also müssen Modelle auch mehr prüfen.
Was ich daraus mitnehme
Ich habe mich beim Lesen ertappt gefühlt. Meine Absicherung bei Claude Code ist: Ich lese den Diff. Bei kleinen Projekten reicht das. Bei allem, was länger lebt, ist es genau die Stichprobe, die mit der Menge nicht mithält.
Drei Dinge, die ohne großen Aufwand gehen:
- Tests zur Bedingung machen, nicht zur Zugabe. Kein Feature ohne Test, auch wenn Claude beides schreibt.
- Ein zweites Modell drüberschauen lassen - andere blinde Flecken, und es kostet Minuten.
- Lint- und Typ-Regeln streng stellen. Was die Maschine automatisch ablehnt, musst du nicht lesen.
Der Satz taugt als Faustregel, auch für Ein-Personen-Projekte: Wenn du dich beim Prüfen entspannst, weil das Modell so sicher klingt, hast du die Latte gesenkt statt erhöht.
Quellen: Boris Cherny auf X, Simon Willison