Nach 3.400 Commits im letzten Jahr, die meisten davon durch irgendeine Kombination aus Claude Code, Codex CLI, PI, Gemini CLI und OpenCode geshipt — die alle parallel auf demselben Working Tree liefen — habe ich starke Meinungen darüber, was das ist und was es nicht ist. Es ist kein Autocomplete. Es ist kein “Produktivitätsboost”. Es ist ein neues Kollaborationsmodell, und die Teams, die es wie Autocomplete behandeln, lassen den Großteil des Werts auf dem Tisch liegen.

Was Autocomplete war

Das Autocomplete-Framing — Copilots ursprüngliches Pitch, ungefähr — war: Du bist noch immer die Engineerin, die KI ist eine schnellere Tastatur. Du denkst, du tippst, sie vervollständigt. Die Loop ist eng, der Kontext ist lokal, der Output ist Zeile für Zeile.

Das war nützlich. Es ist jetzt ein kleiner Bruchteil dessen, was die aktuelle Generation von Tools tut.

Was das Kollaborationsmodell ist

Ein moderner Coding-Agent (Claude Code, Codex, Gemini, Cursor, OpenCode, egal welcher) vervollständigt nicht deine Zeile. Er übernimmt einen Task — manchmal mit 50+ Dateien in seinem Kontext, manchmal beim Ausführen einer Shell, manchmal iterierend für Minuten, manchmal pausierend, um dir eine klärende Frage zu stellen, die er tatsächlich beantwortet brauchte.

Das ist kein Autocomplete. Das ist ein Junior-bis-Mid-Engineer, der mit 40-facher Geschwindigkeit arbeitet, vollen Lesezugriff auf deine Codebase hat und 90 Minuten lang recherchiert, während du in einem Meeting sitzt.

Die richtige Analogie ist ein Pair-Programmer zu haben, der günstig genug ist, um ihn parallel zu betreiben. Und die Implikation dieser Analogie: Du musst die Arbeit anders planen, als du es beim zeilenweisen Vervollständigen getan hast.

Fünf Dinge, die ich in meiner Arbeitsweise geändert habe

1. Ich schreibe immer zuerst eine Spec, dann implementiere ich

Wenn ich selbst den Code schreibe, kann ich etwas frei drauflos machen. Viel meines besten Codes entsteht durch Selbstbearbeitung — ich tippe eine schlechte Version, schaue sie an, refactore, lande irgendwo Anständiges.

Das funktioniert mit einem Agent nicht. Ein Agent, dem man eine vage Spec gibt, produziert eine vage Implementierung, plus drei plausibel aussehende Abstraktionen — und rechnet dir die Zeit an, sie alle zu reviewen. Du musst die Klarheit vorneweg investieren. “Bau eine Sache, die X macht, mit diesen Constraints, unter Verwendung dieses bestehenden Patterns aus Datei Y, und füge keine allgemeine Abstraktion hinzu, solange ich nicht danach frage.”

Meine Specs sind jetzt um eine Größenordnung expliziter als damals, als ich den Code selbst schrieb. Das allein hat meinen Code besser gemacht — nicht nur meine KI-Interaktionen.

2. Ich lese das Diff sorgfältig. Jedes Mal.

Es gibt eine starke Versuchung, wenn der Agent 500 Zeilen funktionierend aussehenden Code produziert, ihn zu überfliegen und zu akzeptieren. Nicht überfliegen. Die 500 Zeilen enthalten regelmäßig:

  • Eine Abstraktion, nach der du nicht gefragt hast.
  • Einen Kommentar, der Code beschreibt, der früher mal anders war.
  • Einen erfundenen Funktionsnamen, der nicht der Naming-Convention deiner Codebase entspricht.
  • Ein “TODO”, das der Agent sich selbst geschrieben und dann nicht gemacht hat.

Keines davon ist ein Bug im Agent. Es sind die Kosten der Delegation. Die Disziplin ist dieselbe, die du auf einen PR eines Junior-Engineers anwenden würdest: Lies es, als ob du es für immer warten müsstest — weil du es wirst.

3. Ich betreibe mehrere Agents parallel für unabhängige Tasks

Das ist der größte Unlock überhaupt. Ich betreibe einen Agent in einem tmux-Pane bei einem Backend-Refactor, einen anderen in einem zweiten Pane bei einem Docs- Pass, einen dritten in einem dritten Pane beim Evaluieren einer Library. Sie kollidieren nicht, weil ich sie auf disjunkte Teile des Repos gescopet habe. Das Wechseln zwischen den Panes ist der Ort, wo ich die eigentliche Senior-Arbeit mache — reviewen, dirigieren, ablehnen, Kontext zwischen ihnen einfügen.

Der Skill, der sich hier multipliziert, ist Arbeitsdekomposition. Drei Stunden wirklich paralleler Arbeit zu identifizieren — nicht fake-parallel, wirklich parallel — und sie mit drei Agents aufzusetzen, ist eine seltsam spezifische Fähigkeit, die mir niemand beigebracht hat, und die ich jetzt reflexartig anwende.

4. Ich halte eine Shared-Skills-Schicht für alle Agents

Die verschiedenen CLI-Agents (Claude Code, Codex, Gemini, PI, OpenCode) haben unterschiedliche Eigenheiten. Was sie teilen, ist der Projektkontext — die Konventionen, die Rule-Files, die Test-Commands. Ich pflege diesen gemeinsamen Kontext an einem Ort (rice-shared-skills), und jeder Agent zieht davon. Wenn ich einen Coding-Standard ändere, sehen ihn alle Agents innerhalb von Minuten.

Das ist das Stück, das Multi-Agent machbar macht. Ohne es hat jeder Agent seine eigene idiosynkratische Sicht auf dein Projekt, und du verbringst deine Senior- Zeit damit, Drift zu reconcilen.

5. Ich tausche Agents mid-task aus, wenn einer feststeckt

Claude Code kann in einer Loop stecken bleiben, wenn er über einen bestimmten Refactor nachdenkt. Ich wechsle denselben Kontext zu Codex, füge den State ein und bin oft in Minuten unblocked. Nicht weil Codex in absoluten Termen “cleverer” ist — sie sind alle ungefähr vergleichbar — sondern weil die lokalen Minima jedes einzelnen Modells verschieden sind, und ein anderes Modell mit demselben Kontext billig daraus ausbricht.

Das ist einer der Gründe, warum ich raise geschrieben habe: zwischen 17 KI-Tools via atomaren Symlink-Swaps zu wechseln, mit Credential-Preservation, weil das manuelle Neukonfigurieren der Auth und Settings jedes Tools meinen Tag fraß.

Was das nicht ist

Ein paar Dinge, die das Kollaborationsmodell nicht ist:

  • Es ist kein Ersatz für Senior-Urteilsvermögen. Der Agent generiert; du reviewst. Wenn du nicht glaubwürdig reviewen kannst, publisht du zufälligen Code in Production. Der Bar für “ich kann das nicht reviewen” sollte “dieser PR shippt nicht” sein — genauso wie bei einem Menschen.
  • Es ist nicht kostenlos. Ich zahle dafür, und die Kosten sind nicht trivial. Die Teams, die LLM-gestütztes Engineering wegen der Per-Seat-Kosten ablehnen, machen Tabellenkalkulationsrechnung auf das Autocomplete-Framing und verpassen, dass der Agent bei den passenden Tasks 2–3 Stunden Arbeit in 15 Minuten erledigt.
  • Es ist nicht uniform über Tasktypen. Der Agent ist gut bei Refactoring, Boilerplate schreiben, Tests generieren, unbekannten Code erklären und Dokumentation schreiben. Er ist mittelmäßig bei Architekturentscheidungen, Produkturteil und allem, was Verhandlungen mit Menschen erfordert. Kenn die Asymmetrie.

Die CV-Implikation

Wenn du 2026 Senior-Engineers einstellst und die Interview-Loop nicht prüft, wie Kandidaten mit KI-Tools arbeiten, interviewst du nicht für den eigentlichen Job. Der eigentliche Job ist “kann diese Person die Arbeit eines Agents leiten, erkennen, wann der Agent falsch liegt, und auf dieser Basis glaubwürdigen Code shippen?” Kandidaten, die das nicht können, werden langsamer sein als Kandidaten, die es können — auf eine Weise, die sich über Quartale aufaddiert.

Ich sage die stille Wahrheit: Das ist der Bereich, in den ein Großteil meiner aktuellen between-seats-Bandbreite fließt. Echte Workloads durch echte KI-unterstützte Pipelines führen, aufschreiben, was funktioniert und was nicht, Tools shippen, die das Muster zuverlässiger machen. Wenn du für diesen Skill einstellst — ich bin hier, und ich habe den Commit-Graph, der den Anspruch belegt.