Das Problem
Wir sind ein kleines Team. Fünf Leute, die eine KI-Plattform bauen. Zu jedem Zeitpunkt haben wir 14 aktive Repositories. Das bedeutet viele PRs und nicht genug Menschen, um sie gründlich zu prüfen.
Reviews dauerten zu lange. Wichtige Dinge wurden überflogen. Wir lieferten Code schneller aus, als wir ihn verifizieren konnten.
Also haben wir unseren eigenen Code-Review-Bot gebaut. Er begann als Nebenprojekt, um einen internen Schmerzpunkt zu beheben. Heute ist er ein Produkt: Surmado Code Review. 15 $ pro Monat für 100 PRs.
So haben wir ihn tatsächlich gebaut. Was vibe-coded wurde, was nicht, und das Framework, das wir jedem empfehlen würden, der eine KI-Pipeline prototypisiert.
Phase 1: Start mit Vibe Coding
Die erste Version war ein Zusammenfassungs-Agent. Mehr nicht. Einen PR öffnen, eine verständliche Zusammenfassung der Änderungen bekommen. Wir haben alles vibe-coded. Schnell, pragmatisch, mit Claude als Hauptarbeitstier.
Dann begannen wir zu fragen: Kann er auch Bugs erkennen?
Ab da wurde es interessant.
Phase 2: Der Forward-Backward-Pass
Das ist der Teil, den wir für wirklich teilenswert halten. Ein Framework, das Sie auf jede KI-Pipeline anwenden können, nicht nur auf Code Review.
Wir haben ein Konzept aus dem ML-Training übernommen: den Forward-Backward-Pass. Aber statt die Gewichte eines Modells zu trainieren, haben wir die gesamte Pipeline so behandelt, als wäre sie ein LLM.
So funktioniert es.
Forward Pass. Sie definieren einen Satz kontrollierter Inputs. In unserem Fall PRs mit absichtlich eingebauten Bugs. Sie schicken sie durch die Pipeline und erfassen, was erkannt wird und was durchrutscht.
Backward Pass. Sie analysieren die durchgerutschten Fälle. Sie passen Prompts, Struktur und Review-Logik an. Dann führen Sie es erneut aus. Wird der Bug diesmal erkannt? Hat die Zahl der False Positives zugenommen?
Wiederholen. Jeder Zyklus ist schnell und günstig. Sie trainieren kein Modell neu. Sie iterieren über Code, Prompts und Architektur, mit sofortigem Signal, ob es funktioniert hat.
Der zentrale Gedanke: Sie machen Claude Code zum synthetischen Nutzer. Sie geben ihm einen erwarteten Input und einen erwarteten Output. Sie lassen ihn weitere Testfälle erzeugen und die Ergebnisse gegen Ihre Pipeline bewerten. Das ist Ihr Test-Harness.
Test-Harnesses lassen sich leicht vibe-coden. Wenn Sie eine aktive API haben, können Sie so etwas in einem Nachmittag aufsetzen. Etwas Deployedtes, Containerisiertes oder auch nur lokal Laufendes. Sie definieren die Bug-Typen, die Ihre Pipeline erkennen soll, generieren Testfälle, führen sie aus und iterieren.
Das war unser v1 und v2. Wir hatten 10 verschiedene Theorien, wie sich die Review-Logik strukturieren lässt. Statt zu diskutieren, haben wir alle 10 durch den Harness geschickt und die Ergebnisse entscheiden lassen.
Phase 3: Wo Vibe Coding an die Decke stößt
Durch all dieses Experimentieren haben wir den eigentlichen Hebel gefunden: Grounding durch Standards.
Der Review-Agent wurde deutlich besser, sobald er ein gut geschriebenes Standards-Dokument zum Nachschlagen hatte. Die tatsächlichen Coding-Konventionen und architektonischen Entscheidungen unseres Teams.
Wenn Sie Vibe Coding betreiben, haben Sie wahrscheinlich schon eine CLAUDE.md oder .cursorrules. Das ist ein Schreibvertrag. Er sagt dem Agenten, was zu produzieren ist. Aber die meisten Teams haben keinen Review-Vertrag. Es gibt keine entsprechende Datei, die irgendjemandem, Mensch oder Maschine, sagt, was in den Merge darf. Aus dieser Asymmetrie entsteht Drift.
Wir haben für jedes Repo eine STANDARDS.md geschrieben. Sobald diese Datei existierte, hatte der Review-Agent etwas Konkretes, mit dem er abgleichen konnte. Keine generischen Best Practices. Unsere konkreten Überzeugungen dazu, wie wir bauen.
Aber eine Sache ist wichtig. Das Standards-Dokument selbst ließ sich nicht vibe-coden. Die Formatierung, die Einbettung in die Pipeline, die Sprache und Struktur. All das verlangte sorgfältiges menschliches Urteil. Wir haben geschrieben, getestet, wie der Agent es interpretierte, und überarbeitet. Diese Schleife wurde von Menschen geführt.
Die Produktisierung war komplett handgebaut. Jedes einzelne Teil.
Authentifizierung und Zahlungen. Bewusst verdrahtet. Das Geld der Kundin liegt uns am Herzen.
Fehlerzustände und Rückerstattungen. Handgemacht entworfen. Wenn etwas schiefläuft, müssen wir genau wissen, was passiert und warum.
Datenschutz. Nicht verhandelbar. Kundencode läuft durch unsere Pipeline. Das verlangt bewusste Architektur, keinen generierten Code.
Integration mit Scout. Scout ist unsere KI-Research-Analystin. Die Verdrahtung zwischen Surmado Code Review und Scout war sorgfältig, getestet und absichtsvoll.
Wir haben außerdem viel Zeit in die Gewichtung der Modelle in der Pipeline gesteckt. Bewusst darin zu sein, welches Modell was übernimmt, Kosten und Qualität auszubalancieren. Solche Entscheidungen eignen sich nicht für Vibe Coding. Sie erfordern, dass man seine Margen, die Erwartungen der Kunden und die Fehlermodi jeder Modellstufe versteht.
Nichts davon haben wir der Maschine überlassen.
Phase 4: Menschliche Review und Feinschliff
Nachdem der vibe-coded Prototyp und die agentische Testschleife uns ein solides Fundament gegeben hatten, war der Rest eine Menge menschliche Review-Arbeit. Outputs lesen. Sie mit dem vergleichen, was ein Senior-Engineer tatsächlich markieren würde. Das Standards-Dokument nachziehen. Falsche Positive ausmerzen.
Wir haben es über alle 14 internen Repositories dogfooded. Zum Zeitpunkt, an dem wir v7 veröffentlichten, hatte es Tausende echter PRs auf echtem Code gesehen, der uns wichtig war.
Ergebnis: Dreifache Verbesserung der Zeit bis zum Merge über diese Repos. PRs blieben nicht mehr liegen. Senior-Engineers erwischten nicht mehr dieselben fünf Dinge in jeder Review. Juniors rieten nicht mehr bei Konventionen. Agent-generierte PRs drifteten nicht mehr in Formen ab, die niemand im Team geschrieben hätte.
Am Ende hat mein Dev-Team 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 ein Produkt daraus gemacht.
Das Framework (einfach übernehmen)
Wenn Sie eine KI-Pipeline bauen, Code Review oder etwas anderes, folgt hier das Muster.
1. Vibe-coden Sie Ihren Prototyp. Bringen Sie den Grundfluss zum Laufen. Denken Sie nicht zu viel über die Architektur nach. Lassen Sie die KI das Gerüst bauen.
2. Bauen Sie einen agentischen Test-Harness. Definieren Sie erwartete Inputs und Outputs. Lassen Sie Claude Code als synthetischen Nutzer agieren. Das ist der Forward-Backward-Pass. Er ist schnell aufgesetzt, wenn Sie eine API aufrufbar haben, und er lässt Sie 10 Ideen in der Zeit testen, in der Sie manuell eine bewerten würden.
3. Lassen Sie die Daten die Sieger küren. Debattieren Sie nicht, welcher Ansatz besser ist. Schicken Sie alle durch den Harness. Das Signal ist unmittelbar.
4. Finden Sie den Grounding-Mechanismus. Bei uns war es ein Standards-Dokument. Bei Ihnen könnte es ein Style Guide, eine Rubrik, ein Regelsatz oder ein Referenzdatensatz sein. Die Sache, die Ihre Pipeline konsistent und meinungsstark macht. Das ist Ihr eigentlicher Unterschied, und fast sicher erfordert er menschliche Handarbeit.
5. Bauen Sie handwerklich, was Ihre Kunden schützt. Auth, Zahlungen, Datenschutz, Fehlerzustände. Das ist kein Vibe-Coding-Gebiet. Das ist, wo Vertrauen entsteht. Machen Sie es bewusst.
Das ehrliche Fazit
Vibe Coding ist ein phänomenales Framework für Prototyping und Experiment. Die agentische Testschleife, das Forward-Backward-Muster, hat uns in der frühen Entwicklung schneller vorangebracht, als wir es sonst jemals hätten schaffen können. Wir sind von „Was wäre, wenn wir einen Code-Review-Bot bauen” zu einem laufenden Prototyp, der echte Bugs erwischt, in wenigen Tagen gekommen.
Aber die Dinge, die ein Produkt vertrauenswürdig machen, erforderten Menschen, die bewusste Entscheidungen mit vollem Kontext trafen. Das Grounding über Standards. Die Modellauswahl. Die Zahlungsflüsse. Die Datenschutzarchitektur.
Vibe-coden Sie Ihre Prototyping- und Experimentierschichten. Bauen Sie handwerklich, was Ihre Kunden schützt. Das ist die Grenze. Wir halten sie für die richtige.
Testen Sie es in Ihren eigenen Repos
Surmado Code Review. 15 $/Monat für 100 PRs. Gebaut von einem fünfköpfigen Team. Dogfooded über 14 Repositories.
Sehen, wie Surmado Code Review funktioniert oder eine Review an Ihrem nächsten PR starten.
Weiterführende Artikel: