Zwei Augen sehen mehr

Kurz gefasst: Ein Modell schreibt Code, ein zweites prüft ihn — unabhängig, in einer eigenen Rolle, mit einem anderen Fehlerprofil. Statt dass dasselbe Modell seinen eigenen Code abnickt, entsteht ein Vier-Augen-Prinzip für KI-gestützte Entwicklung. Der Reviewer ändert nichts direkt, sondern schreibt Audit-Logs und Plan-Dateien; der Implementierer baut daraus einen Fusionsplan und setzt erst den um. Das Schöne: Es braucht keine Spezial-Infrastruktur — Chat und ein paar Dateien reichen. Das Ganze gibt's am Ende als freies Kit zum Mitnehmen.

Das Problem: ein Modell nickt sich selbst ab

Wenn du mit KI entwickelst, kennst du den Moment: Das Modell schreibt einen Block Code, du fragst „passt das?", und es antwortet überzeugt „ja, sieht gut aus". Manchmal stimmt das. Manchmal verteidigt es eine Entscheidung, die schon im Ansatz schief war — mit derselben Souveränität, mit der es kurz vorher den Fehler gebaut hat.

Das ist kein Vorwurf an die Modelle. Modelle sind nicht perfekt, Halluzination gehört dazu — das ist normaler Teil der Technik, nicht ein Bug, den man wegdiskutieren kann. Die ehrliche Konsequenz daraus ist nicht „dann nutze ich KI eben nicht", sondern: Man muss es geschickt umgehen. Man baut sich Strukturen, die die Schwächen abfangen, statt so zu tun, als wären sie nicht da.

Und eine der billigsten, wirksamsten Strukturen ist uralt — sie kommt aus jeder Werkstatt, jeder Redaktion, jedem Filmschnitt: Lass es jemand anderen anschauen. Zwei Augen sehen mehr als eins.

Der Auslöser

Ehrlich gesagt war der Funke nicht meine geniale Eingebung, sondern ein YouTube-Video. Jemand erwähnte beiläufig, dass er beim Entwickeln zwei Modelle nutzt — eines, das baut, eines, das gegenliest. Das blieb hängen.

Kurz vorher hatte ich ohnehin angefangen, ein Multi-Modell-Muster in meine Projekte einzubauen — angelehnt an Andrej Karpathys llm-council, ein kleines Open-Source-Experiment, in dem mehrere Modelle gemeinsam an einer Frage arbeiten und sich gegenseitig bewerten, bevor eine Antwort steht. Die Idee dahinter ist simpel und genau deshalb stark: Mehrere Perspektiven, die sich gegenseitig kontrollieren, sind im Schnitt zuverlässiger als eine einzelne, die sich selbst beweihräuchert.

Von „mehrere Modelle beraten eine Frage" zu „ein Modell baut, ein anderes reviewt den Code" ist es nur ein kleiner Schritt. Eigentlich ist das Prinzip völlig klar — es ist einfach das Logische, wenn es um Qualität geht. Ich habe es nur konsequent in einen festen Ablauf gegossen.

Die Idee: Rollen trennen, nicht Modelle stapeln

Der entscheidende Punkt ist nicht „mehr KI". Es ist Rollentrennung.

Das erste Modell ist der Implementierer. Es schreibt und ändert Code. Das zweite Modell ist der Reviewer — und es darf den Produktcode bewusst nicht anfassen. Seine Aufgabe ist eine andere: lesen, Risiken clustern, Schwachstellen finden, und das Ergebnis als Audit-Log und als konkrete Plan-Datei festhalten. Kritik wird zu Material, nicht zu einem stillen Rewrite.

Warum das mehr ist als Kosmetik:

• Anderes Fehlerprofil. Ein zweites Modell stolpert über andere Dinge als das erste. Was das eine übersieht, fällt dem anderen auf — und umgekehrt.
• Keiner verteidigt seinen eigenen Code. Das ist der psychologische Kern. Ein Modell, das gerade etwas gebaut hat, hat einen Hang, es gut zu finden. Ein Modell in der reinen Reviewer-Rolle hat diesen Reflex nicht.
• Review wird nachvollziehbar. Audit-Logs mit Datei- und Commit-Bezug machen sichtbar, was geprüft wurde — nicht nur „habe drübergeschaut".
• Lange Läufe werden möglich. Eine Done-Liste auf Datei-Ebene verhindert, dass über viele Dateien hinweg immer wieder dasselbe geprüft wird. So skaliert das Ganze über ein großes Projekt, statt nach drei Dateien die Übersicht zu verlieren.

Und dann kommt der Teil, der mir am wichtigsten ist: Der Implementierer übernimmt den Review-Plan nicht blind. Er liest das Audit, schreibt einen eigenen Plan, vergleicht beide, und baut daraus eine Fusion. Erst diese Fusion wird umgesetzt und verifiziert. Kein „der Reviewer hat gesprochen, also mach ich das jetzt 1:1" — sondern zwei Perspektiven, die zu einer besseren dritten verschmelzen.

Mein Anteil: Regie führen

Hier muss ich ehrlich sein, und diese Ehrlichkeit ist mir wichtig: Ich schreibe diesen Code nicht selbst. Ich bin kein klassischer Entwickler. Der komplexe Code kommt von der KI. Von mir kommt etwas anderes — und genau das ist mein Job.

Für mich fühlt sich das an wie einen Produzenten steuern oder Regie führen. Ich besetze die Rollen, ich definiere die Gates, ich entscheide, was geprüft wird und wann eine Fusion gut genug ist, um umgesetzt zu werden. Die Modelle sind meine Crew; ich gebe die Richtung, die Systematik und den Qualitätsanspruch vor. Und ehrlich: Es macht mir Spaß. Es ist dieselbe Arbeit, die ich liebe — aus vielen Einzelteilen und Talenten etwas Ganzes formen, das am Ende funktioniert.

Das ist die Vibecoder-Realität: Ich kann dir keinen perfekten Algorithmus hinschreiben. Aber ich kann ein System aufsetzen, in dem zwei KIs sich gegenseitig auf die Finger schauen, und ich kann dafür sorgen, dass am Ende etwas Getestetes herauskommt statt etwas, das nur überzeugend klingt.

Bewusst manuell — und warum das eine Kostenentscheidung ist

Ein ehrliches Wort zur Mechanik, weil es leicht falsch verstanden wird: Das hier ist keine Automatik, die aus dem ersten Tool herausläuft und den Code per API ans zweite Modell schickt. Es ist ein manueller Übergang — ich starte den Reviewer von Hand und stoße den Review von Hand an.

Das ist Absicht, und der Grund ist banal: Kosten. Ich habe ein Abo bei Anthropic (für Claude) und ein Abo bei OpenAI (für GPT, das ich über Codex nutze). Beide laufen pauschal. Also lasse ich bewusst beide Werkzeuge — Implementierer wie Reviewer — über die Abos laufen, nicht über API-Schlüssel mit Pay-per-use. Genau daraus ergibt sich die Aufteilung in zwei getrennte Tools, die ich von Hand bediene: Der Implementierer baut, dann starte ich den Reviewer separat und stoße den Review an.

Man könnte das automatisieren — dann würde der Code automatisch ans Review-Modell wandern, typischerweise über die API (oder einen Router wie OpenRouter, der sich das Modell-Kontingent holt und separat pay-per-use abrechnet). Mehr Komfort, mehr Automation — aber eben Extra-Kosten obendrauf, obwohl die Abos ohnehin schon laufen. Diese Adaption ist jederzeit möglich; ich habe sie bewusst nicht gebaut. Für meinen Alltag ist der kleine Handgriff billiger als eine API-Rechnung, die mit jedem Durchlauf mittickt — und genau diese Abwägung ist Teil der Entscheidung.

Warum das (heute schon) den Aufwand wert ist

Man könnte einwenden: Das ist doch nur ein Workaround. Stimmt. Aber ein guter. Solange Modelle halluzinieren — und das tun sie alle, auch die aktuellen — ist die Frage nicht ob man gegensteuert, sondern wie billig und wie zuverlässig. Eine zweite Rolle, die nichts kostet außer ein bisschen Disziplin und ein paar Dateien, ist eine der günstigsten Versicherungen, die du in einen KI-Workflow einbauen kannst.

Mein Bauchgefühl: Das ist eine Übergangstechnik. Die aktuellen Modelle denken noch nicht von sich aus so — du musst die zweite Perspektive von Hand organisieren. Künftige Modelle werden in diese Richtung gehen und das vermutlich automatisch tun: erst bauen, dann in einer eigenen Rolle hart gegenprüfen, bevor sie etwas abliefern. Bis dahin organisiere ich es eben selbst. Und selbst wenn es Standard wird, bleibt das Prinzip dasselbe — es wird nur bequemer.

Zum Nachbauen — das Kit ist frei

🎁 Hol dir das Kit — kostenlos & Open Source

Der komplette Zwei-LLM-Review-Ablauf als fertiges Paket: eine Agent-Regel, der Reviewer-Skill, Plan-Vorlagen und ein Chat-Handoff-Template. Kein Login, keine Spezial-Infrastruktur — kopieren und loslegen. Open Source unter GPL-3.0.

→ open-skills auf GitHub ansehen · Tutorial: Schritt für Schritt einrichten

Dieser Artikel erklärt das Warum. Das Wie — Installation Schritt für Schritt, den Skill global einrichten, den Review-Loop fahren — steht im verlinkten Tutorial. Bewusst getrennt: Hier das Prinzip, dort die Anleitung. So musst du nicht durch eine Installationsanweisung scrollen, um die Idee zu verstehen — und nicht durch einen Essay, um sie umzusetzen.

Jens Fehrmann macht End-to-End-KI-Integration — von der Machbarkeitsstudie bis zur getesteten Endanwendung. Als Vibecoder: Konzept, Architektur und Systematik von ihm, der Code von der KI. Auf dem Fundament von 16 Jahren Film und CGI, aus Dresden.

Quellen & Transparenz - Andrej Karpathy, llm-council (Open-Source-Projekt, mehrere Modelle bewerten gemeinsam eine Frage): https://github.com/karpathy/llm-council - Das freie Kit zu diesem Artikel (open-skills, GPL-3.0): https://github.com/jnsfhrmnn/open-skills - Eigene Betriebserfahrung: Der beschriebene Implementierer-/Reviewer-Ablauf stammt aus meiner eigenen Arbeit über mehrere Projekte hinweg (eigene Beobachtung, nicht extern verlinkbar).

Genannte Marken, Logos und Modellnamen gehören ihren jeweiligen Inhabern; eine Kooperation oder Partnerschaft besteht nicht.