Ein Google-Ingenieur hat sich letzte Woche für Surmado Code Review angemeldet. Das Produkt läuft auf Scout, unserem AI research analyst. Er schrieb eine STANDARDS.md-Datei für sein Projekt, öffnete seinen ersten Pull Request und ließ Scout darüber laufen.
Scout markierte einen kritischen Architekturfehler, der die Produktion zerstört hätte.
Er hat nicht gemerged. Er schrieb uns eine E-Mail und beschrieb seinen Workflow:
„Ich nehme das Feedback von Surmado und kopiere es in Gemini. Gemini geißelt sich selbst und gibt mir dann einen neuen Prompt für Gemini Code Assist in meiner IDE. Gemini Code Assist nimmt die Änderungen vor. Ich aktualisiere den Branch und Surmado prüft die neue Version automatisch erneut. Erst wenn ich diesen Loop ausgeschöpft habe, tagge ich meine Mitarbeitenden zur Review.”
Lesen Sie das noch einmal. Da steckt ein Loop drin, der einen Namen verdient.
Der Loop
- Gemini Code Assist schreibt den Code in seiner IDE.
- Surmado prüft ihn gegen seine
STANDARDS.md. - Er fügt Surmados Review in den Gemini-Chat ein.
- Gemini liest Surmados Urteil und schreibt den Prompt für sich selbst um.
- Code Assist generiert den Code mit dem neuen Prompt neu.
- Er pusht den neuen Branch. Surmado prüft automatisch erneut.
- Wenn er den Loop ausgeschöpft hat, tagged er seine menschlichen Mitarbeitenden.
Der letzte Schritt ist der, auf den wir immer wieder zurückkommen. Der Loop ersetzt nicht die menschliche Review. Er sorgt dafür, dass die menschliche Review nur dann eingreift, wenn sie wirklich gebraucht wird. Wenn ein Mensch sich den PR ansieht, ist das Offensichtliche bereits behoben. Die Architekturfehler, die Verstöße gegen Standards, die Dinge, die ein aufmerksamer Leser an einem müden Dienstagnachmittag erwischen würde. Weg. Der menschliche Reviewer bleibt mit den Teilen zurück, die wirklich einen Menschen brauchen: Design-Abwägungen, Absicht, Urteilsvermögen.
Das ist die Version von KI im Dev-Loop, die tatsächlich funktioniert. Nicht „KI ersetzt Menschen”. KI übernimmt den konvergierenden Teil. Menschen übernehmen den entscheidenden Teil.
Was Gemini sagte
Der Ingenieur fügte Surmados Review während der Sitzung zweimal in Gemini ein. Beide Male stimmte Gemini Surmado sofort zu.
Die erste Antwort:
„Surmado hat gerade einen kritischen Architekturfehler entdeckt, der Ihre Produktionsseite zerstört hätte, und hat ihn markiert, indem es direkt die
STANDARDS.md-Datei zitiert hat, die wir vor 20 Minuten geschrieben haben. Sie sollten diesen PR auf keinen Fall jetzt mergen. Hier ist genau, was passiert ist und warum Surmado völlig richtig liegt.”
Die zweite:
„Surmado hat eine Lücke in unserer Ausführung gefunden, und ehrlich gesagt habe ich beim Prompt, den ich Ihnen für Code Assist gegeben habe, geschlampt.”
Dieses zweite Zitat ist das, auf das wir immer wieder zurückkommen. Gemini hat nicht das Modell beschuldigt. Gemini hat den Prompt beschuldigt. Die Anweisungen, die Gemini Code Assist gegeben hat, enthielten nicht die Konventionen des Teams, weil Gemini die Konventionen des Teams nicht kannte.
Surmado wusste sie, weil der Ingenieur sie zwanzig Minuten zuvor aufgeschrieben hatte. STANDARDS.md ist die Brücke zwischen dem, was dem Team wichtig ist, und dem, worauf das Modell handeln kann.
Warum genau das das Produkt ist
Die meisten KI-Code-Review-Tools prüfen auf generische Best Practices. Rücken Sie Ihren Code ein. Schatten Sie keine Variablen. Vermeiden Sie Magic Numbers.
Das ist Pflichtprogramm. Jeder Linter macht das. Der Grund, warum Teams immer noch schlechten Code mergen, ist, dass die Bugs, die der Produktion wehtun, nicht generisch sind. Sie sind spezifisch dafür, wie das Team baut. Sie stehen in Ihrem Wiki, Ihren Design-Docs, in den Konventionen, die in den Köpfen von drei Senior-Engineers leben.
STANDARDS.md ist der Ort, an dem das hingehört. Scout liest sie. Jeder PR wird daran geprüft. Jeder erneute Lauf liest den neuen Diff und die vorherige Review, sodass Scout sagen kann, ob frühere Probleme behoben wurden.
Der Loop des Ingenieurs funktioniert, weil jedes Teil das tut, worin es gut ist. Gemini schreibt Code. Surmado prüft ihn gegen die Regeln des Teams. Gemini korrigiert sich selbst, wenn es externes Feedback bekommt. Menschen prüfen, was übrig bleibt. Die Integrität entsteht aus dem Loop, nicht aus einem einzelnen Modell.
Wie sich das anfühlt
So beschrieb er seine vorherigen Versuche mit Web-Projekten:
„Ich war begeistert von den Reihen von Code, die generiert wurden, und wartete dann erwartungsvoll darauf, meine Schöpfung zum Leben erwachen zu sehen. Nur um wirklich enttäuscht zu werden, wenn sie unweigerlich kaputtging.”
Jeder, der versucht hat, ein echtes Projekt mit Vibe-Coding aufzubauen, kennt diesen Bogen. Die Begeisterung. Die erwartungsvolle Vorfreude. Der Absturz.
Dann das:
„Heute Abend nicht. Ich habe PRs committet, die genau das erreicht haben, was ich mir vorgenommen hatte.”
Das ist der Unterschied. Nicht „KI hat Code geschrieben”. Nicht „KI hat Code geprüft”. Ein Loop, der zu funktionierender Software konvergiert, mit einem menschlichen Checkpoint am Ende, wenn einer gebraucht wird.
Der Rahmen, der uns gefällt
Die meisten KI-Tools positionieren sich gegen Menschen. „Schneller als ein menschlicher Reviewer.” „Findet Dinge, die Menschen übersehen.”
Surmado positioniert sich zwischen KIs. Nicht schneller als Gemini. Nicht klüger als Claude. Das Modell, das den Code geschrieben hat, weiß nicht, was dem Team wichtig ist. Das Modell, das ihn geprüft hat, weiß es, weil es jemand aufgeschrieben hat.
So sieht ein Orchestrierungsprodukt aus. Das LLM ist nicht das Produkt. Die Art und Weise, wie das LLM mit den tatsächlichen Regeln Ihres Teams verdrahtet ist, ist das Produkt.
Der Ingenieur fasste es in seiner letzten Nachricht zusammen: „Sehr beeindruckt. Es ist auch so perfekt in den Flow integriert.”
Das ist es, was wir bauen.
Zwei Klicks. Dann funktioniert es einfach. 15 USD pro Monat für 100 PRs. Wir schauen uns Ihren Code nie an. Die Frontier-Labs, die wir nutzen, auch nicht.