Starten Sie fünf Instanzen von Claude Code auf demselben Ticket. Sie bekommen fünf funktionierende Implementierungen. Alle bestehen die Tests. Alle lösen das Problem. Keine sieht so aus wie der Code, den Ihr Team vor sechs Monaten geschrieben hätte.
Das ist die neue Ausgangslage. Der Raum möglicher gültiger Implementierungen ist explodiert, und er kollabiert nicht von selbst.
KI hat Code Review nicht überflüssig gemacht. Sie hat es zum Engpass gemacht.
Zehn Jahre lang war die Generierung die Begrenzung und Review die Aufräumarbeit. Ein Senior-Engineer verbrachte 30 % des Nachmittags mit Schreiben und 70 % mit Review. Der Engpass war, wie schnell Menschen denken konnten.
Dieses Verhältnis hat sich umgedreht. Generierung ist praktisch kostenlos geworden. Eine einzelne Entwicklerin mit Claude Code oder Cursor kann in einer Woche mehr Code produzieren als ein fünfköpfiges Team früher in einem Jahr.
Der Engpass hat sich verschoben. Jetzt lautet die Frage: Welche dieser fünf funktionierenden Implementierungen gehört tatsächlich in unseren Code?
Diese Frage hat keine Modellantwort. Sie hat eine Teamantwort. Der gewachsene Geschmack des Teams ist das Einzige, was „funktionierenden Code” von „Code, der hierher gehört” unterscheidet. Wie Sie Dinge benennen. Wie Sie Module strukturieren. Was Sie nicht importieren. Wann Sie früh abbrechen. Wie Sie Tests schreiben.
Ohne das ist jeder PR ein Münzwurf zwischen fünf plausiblen Optionen.
Ihr Geschmack ist der Moat. Kodifizieren Sie ihn.
Hier bleiben die meisten Teams stecken. Der Geschmack existiert. Er steckt in den Köpfen von drei Engineers. Er kommt in PR-Kommentaren heraus, in Slack-Threads, im Augenrollen, das ein Senior einem Junior an einem Dienstag zuwirft. Er ist real, und er ist der tatsächliche Unterschied zwischen Code, der Wert aufbaut, und Code, der ins Chaos abdriftet.
Aber er ist nirgendwo so festgehalten, dass eine Maschine ihn lesen kann. Das heißt, Agenten können ihm nicht folgen. Neue Teammitglieder können ihm nicht folgen. Selbst die Seniors können ihn nicht konsistent anwenden, weil sie müde sind, Rufbereitschaft haben oder in einer Besprechung sitzen, wenn der PR eintrudelt.
Die meisten Teams haben bereits ein CLAUDE.md oder .cursorrules. Das sind Anweisungen, wie Agenten im Repo Code schreiben sollen. Beachten Sie die Asymmetrie. Es gibt einen Schreibvertrag und keinen Review-Vertrag. CLAUDE.md sagt dem Agenten, was produziert werden soll. Es gibt keine entsprechende Datei, die irgendjemandem, Mensch oder Maschine, sagt, was in den Merge darf.
Diese Datei ist STANDARDS.md. Reines Markdown, im Repo, zusammen mit dem Code versioniert. Die gewachsenen Entscheidungen des Teams, explizit gemacht. Keine generischen Best Practices. Ihre konkreten Überzeugungen dazu, wie Sie bauen.
Nichts davon ist ein neuer Gedanke. Kleppmann argumentiert in Designing Data-Intensive Applications, dass Systeme dann Wert akkumulieren, wenn ihre Verträge explizit und maschinenprüfbar sind. Schema, nicht Bauchgefühl. STANDARDS.md ist dieselbe Disziplin eine Ebene höher. Der Vertrag ist nicht mehr zwischen Services, sondern zwischen dem PR einer Engineerin und dem gewachsenen Geschmack des Teams.
Sobald diese Datei existiert, werden drei Dinge möglich.
Agenten generieren Code gegen sie. Ihr Geschmack schränkt den Möglichkeitsraum ein, bevor Code geschrieben wird.
Jeder PR wird automatisch dagegen geprüft, egal ob der Autor ein Mensch oder ein Agent war. Kein Drift, keine Ausnahmen, kein „holen wir im nächsten Sprint nach”.
Neue Teammitglieder lesen ein Dokument und nehmen die Sicht des Teams in einem Nachmittag auf.
Die Standards-Datei ist keine Dokumentation. Sie ist die Kollapsfunktion. Sie nimmt die Explosion gültiger Implementierungen und projiziert sie auf Ihre Implementierung.
Wir haben unser Dev-Team um das Dreifache beschleunigt, indem KI jeden PR gegen unsere Standards prüft.
Wir sind intern vor drei Monaten genau auf diese Wand geprallt. Wir haben Surmado Code Review zuerst für uns selbst gebaut. Internes Werkzeug, v7. Läuft über 14 Repositories bei jedem Commit.
Unsere Standards leben in einer STANDARDS.md pro Repo. Scout liest sie, liest den Diff und sagt dem menschlichen Reviewer, was gut ist, was Arbeit braucht, worauf zu achten ist und welche Annahmen der PR macht.
Die 3× beziehen sich auf die Zeit bis zum Merge über unsere 14 Repos. Unsere PRs bleiben nicht liegen. Sie bewegen sich.
Diese Geschwindigkeit kommt nicht daher, dass der Bot die Review macht. Sie kommt daher, dass der Bot den Lärm reduziert, damit sich die Menschen auf das Wesentliche konzentrieren können. Die Senior-Engineerin hört auf, in jedem PR dieselben fünf Dinge zu erwischen. Der Junior hört auf, bei Konventionen zu raten. Agent-generierte PRs driften nicht mehr in Formen ab, die niemand im Team geschrieben hätte.
Wenn Sie noch keine STANDARDS.md haben, schreibt Scout sie mit Ihnen. Zwei Klicks zur Installation. Scout befragt Sie zu Ihrem Stack, Ihren Konventionen, Ihrer Testpraxis und den architektonischen Entscheidungen, die Sie bereits getroffen haben.
Wo Sie Meinungen haben, schreibt Scout sie auf. Wo nicht, schlägt Scout Defaults vor, die Sie annehmen, bearbeiten oder überschreiben können. Wenn Sie eine Vibe Coderin sind, die ihre Standards noch nie artikulieren musste, strukturiert Scout das Denken und bringt die Fragen zum Vorschein, die Sie noch nicht gestellt haben.
Die Meinungen bleiben Ihre. Das Gerüst ist dasselbe, das wir intern für unsere STANDARDS.md-Dateien verwenden. Die Art von Standards-Disziplin, für die ein größeres Team Wochen braucht, läuft bei Ihnen heute Nachmittag.
Mein Dev-Team hat mich gezwungen, es zu veröffentlichen. Sie hatten keine Lust mehr, befreundeten Gründerinnen zu sagen, dass sie es nicht haben können, weil es intern sei. Also haben wir daraus ein Produkt gemacht.
Über Ihren Code
Wir speichern ihn nicht. Wir trainieren nicht darauf. Wir lesen nicht Ihr gesamtes Repository.
Scout läuft auf Frontier-Modellen von Anthropic und OpenAI. Jede PR-Review schickt nur den Diff an deren APIs, unter den Standard-API-Vereinbarungen. Keine Speicherung. Kein Training. Nichts über Ihren Code bleibt in unseren Systemen, nachdem die Review abgeschlossen ist.
Lesen Sie die vollständigen Datenschutzbestimmungen und Nutzungsbedingungen. Alles ist dokumentiert.
Wofür das eigentlich gedacht ist
Der Pitch, den die meisten KI-Werkzeuge machen, lautet: Das Modell ersetzt den Menschen. Dieses Framing ist grundsätzlich falsch, und es ist heute besonders falsch.
KI-Generierung macht Teams schneller, aber sie lässt auch Codebasen schneller driften. Beschleuniger und Entropie kommen aus derselben Quelle. Die Teams, die vorn sind, haben herausgefunden, wie man menschliches Urteil so anhebt, dass es mit Maschinengeschwindigkeit Schritt hält. Sie haben es nicht ersetzt.
Surmado Code Review ist kein autonomer Reviewer. Es ist ein Kraftverstärker für den Geschmack Ihres Teams. Ihre Standards, angewendet auf jeden PR, jeden Push, jeden Agentenlauf. Menschen machen weiterhin die menschliche Arbeit: entscheiden, was die Standards sind, architektonische Entscheidungen treffen, das Team mentorieren, das Geschäft kennen. Der Bot macht den Teil, der Ihre Seniors ausgebrannt hat, nämlich Abweichungen von Entscheidungen zu erkennen, die Sie bereits getroffen haben.
Die Zukunft der KI im Code ist nicht Agenten, die Engineers ersetzen. Es ist der Geschmack der Engineers, einmal kodifiziert, überall angewendet, in Maschinengeschwindigkeit. Die Teams, die das zuerst begreifen, werden für die anderen Teams kaum wiederzuerkennen sein. Nicht, weil ihre Entwicklerinnen klüger sind, sondern weil ihr Geschmack auf jede Zeile Code wirkt, auch auf die, die sie nicht selbst geschrieben haben.
Wie alles, was wir bei Surmado bauen, stellt das den Menschen in den Mittelpunkt und stärkt den Agenten. Ihr Geschmack, verstärkt.
Probieren Sie es beim nächsten PR
Surmado Code Review. Zwei Klicks zur Installation. 15 $/Monat für 100 PRs. Keine Preise pro Sitzplatz. Keine Speicherung Ihrer Diffs. Gebaut für Solo-Entwicklerinnen und kleine Teams, die sich schnell bewegen. Nicht für Enterprise.
Surmado Code Review installieren oder lesen, wie wir es gebaut haben.
Weiterführende Artikel: