Ein Jahr lang habe ich es gemacht wie die meisten: das Modell nehmen, das gerade als bestes gilt, Chat auf, Aufgabe beschreiben, lesen was zurückkommt.

Das trägt, bis die Arbeit so groß wird, dass du nicht mehr alles lesen kannst.

Heute fahre ich weniger eine Werkzeugwahl als ein System: Arbeit wird nach der Art von Urteilsvermögen verteilt, die sie braucht, Pläne entstehen vor Code, und was ein Agent produziert, prüft nie derselbe Agent allein. Darum geht es hier, und um die zwei Regeln, die den größten Teil davon tragen.

Vorab, damit die Erwartung stimmt: Eine Vorher-Nachher-Zahl habe ich nicht. Ich fahre das Setup seit Monaten und es fühlt sich deutlich besser an, aber meine Ausgangslage habe ich nie sauber gemessen — was ich dir nennen würde, wäre eine Schätzung im Gewand von Daten. Was ich habe, ist eine empirische Auswertung von 24.560 Pull Requests, gerechnet in der Freizeit, aus Neugier, ob die Behauptung „KI-Code ist schlechter" ein Matching übersteht. Daher stammt die Begründung für alles Weitere.

Routing: erst Fähigkeit, Kosten zuletzt

Mein Fehler über lange Zeit war, Modellwahl als Budgetfrage zu behandeln. Günstiges Modell für Kleinkram, teures für Schweres.

Falsche Achse. Kosten entscheiden Gleichstände, sonst nichts. Geroutet wird nach zwei Dingen:

Intelligenz — wie schwer ein Problem sein darf, das das Modell unbeaufsichtigt löst. Nicht wie gut es abliefert, während ich danebensitze. Wie gut es abliefert, wenn ich eine Spezifikation übergeben habe und etwas anderes tue.
Taste — UI und UX, Codequalität, API-Design, Benennung, Produkturteil, Texte, die Nutzer lesen.

Die beiden fallen weiter auseinander, als man vermutet. Ein Modell erledigt eine gut spezifizierte Migration exzellent und liefert dazu Interface-Texte, bei denen du zusammenzuckst. Ein anderes schreibt einen Absatz, den du sofort ausliefern würdest, und übersieht die Randfälle.

Für beides halte ich eine grobe Bewertung und verteile danach:

Arbeit	Geht an	Warum
Gut spezifizierte Implementierung, mechanische Refactorings, Migrationen, Tests	`gpt-5.6-terra`	Klare Spec, prüfbares Ergebnis. Hier liegt der Großteil.
Extraktion, Klassifikation, Datei-für-Datei-Transformationen, enge Checks	`gpt-5.6-luna`	Günstig und wiederholbar. Nie etwas, das Urteilsvermögen braucht.
Unklare Arbeit, Architektur, schweres Debugging, sicherheitsrelevante Änderungen	`gpt-5.6-sol` oder Fable 5	Hohe Anforderung; Fable 5, wenn auch Taste gefragt ist.
Alles, was ein Nutzer sieht — UI, Texte, API-Oberfläche, Benennung	Fable 5 oder Opus	Harte Untergrenze bei Taste. Technische Korrektheit reicht dafür nicht.

Die letzte Zeile breche ich am seltensten. Ein technisch fehlerfreies Feature mit Texten im Ton einer Compliance-Mitteilung ist nicht fertig.

Fix sind die Bewertungen nicht. Es sind Voreinstellungen, die ich überschreibe, sobald das Ergebnis die Latte reißt, und ich rechne eine Aufgabe lieber auf einem stärkeren Modell neu, als Mittelmaß auszuliefern. Eskalieren kostet fast immer weniger als schlecht ausliefern.

Plan vor Code

Implementiert wird nichts, bevor ein geschriebener Plan existiert.

Kein Plan im Kopf. Eine Datei, mit Begründung, Schritten und Checkliste. Der Plan wird geprüft, bevor eine einzige Zeile entsteht, und während der Arbeit fortgeschrieben, damit jemand, der später übernimmt, das auch kann.

Klingt nach Prozess-Overhead, ist es auch. Und trotzdem das Billigste, was ich tue — weil der Fehlermodus, den es verhindert, der teure ist: Ein Agent baut zwanzig Minuten lang überzeugt das Falsche, und mir fällt es erst im Review auf, wenn die ganze Form nicht stimmt.

Ein Plan ist außerdem das Artefakt, mit dem Arbeit an ein günstigeres Modell gehen kann. Das meiste, was eine Aufgabe „schwer" macht, ist Unterspezifikation. Spezifiziere sie ordentlich, und die Anforderung sinkt.

Kein Agent reviewt seine eigene Arbeit

Wenn ich alles andere wegwerfen müsste, bliebe diese Regel.

Der Agent, der etwas implementiert hat, ist der denkbar schlechteste Prüfer dafür. Er hat allen Grund, seine Ausgabe für richtig zu halten — dieser Glaube hat ihn überhaupt fertig werden lassen. Lässt du ihn seine Arbeit prüfen, findet er die Probleme, nach denen er ohnehin gesucht hat. Also per Definition nicht die, die er übersehen hat.

Geprüft wird deshalb immer von einem anderen Modell. Oft von zweien, mit bewusst verschiedenen Blickwinkeln: Opus oder Fable 5 auf Taste und darauf, ob die Sache taugt, gpt-5.6-sol auf Korrektheit, Randfälle und Repo-Konsistenz.

Wichtiger als die Regel ist ihre Folge: Ein erfolgreicher Lauf beweist nicht, dass das Ergebnis stimmt. Exit Code null heißt, der Prozess ist durchgelaufen. Mehr nicht. Bevor ich delegierte Arbeit annehme, sehe ich mir den Diff an, prüfe, ob er meine Aufgabe löst und nicht eine benachbarte, suche nach Abstraktionen, die niemand brauchte, und nach fremden Änderungen, die sich eingeschlichen haben — und lasse Typecheck, Lint und die passenden Tests laufen.

Schreibt ein Agent Tests, prüfe ich, ob sie das beabsichtigte Verhalten absichern oder nur behaupten, was die Implementierung ohnehin tut. Im grünen CI-Lauf sehen beide gleich aus.

Zwei Dinge machen diesen Checkpoint billiger. Erstens ein zweiter maschineller Prüfer: Schick einen Code-Review-Bot auf den Pull Request — Greptile, CodeRabbit, was zu deinem Stack passt — damit den Diff etwas liest, das ihn nicht geschrieben hat, bevor er bei dir landet. Der fängt das Naheliegende ab und lässt dir die Urteilsfragen.

Zweitens, und das ist kein Werkzeug: Lies selbst bis zu hundert Zeilen Code am Tag, bewusst, auch wenn nichts zu prüfen ansteht. Das findet Dinge, die kein Bot markiert, und es verhindert das langsame Abrutschen, an dessen Ende du den Code nicht mehr lesen kannst, den du ausliefert.

Und hier kommen meine eigenen Daten ins Spiel. In der Auswertung werden 23,4 % der menschlichen PRs, die in CI scheitern, irgendwann repariert. Bei KI-generierten sind es 9,3 %. Einundneunzig Prozent der gescheiterten KI-Pull-Requests werden liegen gelassen — der Agent hat erzeugt, eingereicht und weitergemacht, und niemand kam zurück.

So sieht eine Pipeline ohne Prüfschritt von außen aus. Die Antwort darauf ist kein besseres Modell, sondern ein menschlicher Checkpoint, durch den die Arbeit muss, bevor sie als fertig gilt.

Parallele Agenten brauchen eigene Worktrees

Sobald mehr als ein Agent auf demselben Repository arbeitet, kollidieren sie. Zwei Prozesse, die dieselben Dateien mit verschiedenen Absichten anfassen, hinterlassen ein Durcheinander, das schwerer aufzulösen ist als jede der beiden Aufgaben.

Jeder Agent, der Dateien schreibt und parallel läuft, bekommt deshalb einen eigenen Git-Worktree. Umsonst ist das nicht — Einrichtung und Plattenplatz pro Agent — also mache ich es nur, wenn tatsächlich geschrieben wird. Reine Recherche darf sich einen Checkout teilen, solange auch die Berichte nicht kollidieren.

Die andere Hälfte ist der Zuschnitt. Parallele Agenten bekommen getrennte Zuständigkeiten, und keine zwei Implementierer dieselben Dateien. Widersprechen sich ihre Empfehlungen, löst das ein separater Prüfer auf. Und parallele Arbeit merge ich nie, ohne mir die Summe anzusehen — jede Hälfte kann für sich stimmen und das Ganze trotzdem falsch sein.

Bemerkenswert: Werkzeuge liefern das inzwischen mit. T3 Code, Theos Oberfläche über Codex, Claude und Cursor, hat Git-Worktrees als vollwertiges Feature, statt dass du es dir selbst skriptest. Ich benutze es, und eine kürzliche Änderung daran war wichtiger, als ich erwartet hatte — wichtig genug für einen eigenen Text.

Ich tippe keine Prompts mehr

Kleine Sache, unverhältnismäßige Wirkung: Ich diktiere inzwischen fast alles. Voice to Text, keine CLI.

Zum Teil geht es um Tempo, aber das ist nicht der Kern. Tippe ich einen Prompt, schreibe ich das Kürzeste, was funktionieren könnte. Spreche ich, erkläre ich — Kontext, was ich schon versucht habe, was ich will, was ich nicht will. Heraus kommt eine besser spezifizierte Aufgabe, und nach dem Abschnitt oben ist bessere Spezifikation genau das, was Arbeit an ein günstigeres Modell gehen und korrekt zurückkommen lässt.

Es hat auch verändert, was ich abgebe. Eine Aufgabe laut zu beschreiben ist billig genug, dass ich Dinge delegiere, die ich früher einfach selbst gemacht hätte.

Was das nicht löst

Prüfen ist jetzt mein Engpass. Ich lese deutlich mehr Code als früher. Die Arbeit hat sich verschoben, nicht aufgelöst, und an schlechten Tagen fühlt sich das nicht nach Gewinn an.
Das System hat echten Overhead. Pläne, Worktrees, Prüfdurchgänge. Bei kleinen Aufgaben ist es langsamer, als es einfach zu tun. Für Einzeiler benutze ich es nicht.
Kein Agent versteht dadurch deine Codebase. Das Ergebnis wird prüfbar. Das ist eine andere und kleinere Aussage.

Next

Kurzfassung:

Route nach Intelligenz und Taste. Kosten entscheiden Gleichstände, sonst nichts.
Schreib den Plan zuerst. Unterspezifikation macht Aufgaben teuer.
Wer implementiert hat, prüft nicht allein, und ein grüner Lauf beweist nichts.
Gib parallelen Schreibern eigene Worktrees und getrennte Dateien.

Als Nächstes will ich die Messung klären. Nicht Durchsatz — dieser Zahl misstraue ich aus Gründen, über die ich ausführlich geschrieben habe — sondern eine Definition von „gut", die präzise genug ist, dass ein Skript sie ausrechnen kann, damit ein Lauf sich selbst bewerten kann, während ich nicht zusehe. Das ist schwieriger, als es klingt, vor allem weil die Loop anfängt, die Definition zu optimieren.

Fährst du etwas Ähnliches, würde mich interessieren, wie du entscheidest, was du abgibst — und was dich endgültig davon abgebracht hat, einem grünen Lauf zu glauben.

Let's worktogether

Cookie-Einstellungen

Let's work
together