Der Diskurs über KI-Coding-Agents stellt ihn meistens als Winner-takes-all-Rennen dar: Claude Code vs. Codex vs. Cursor vs. Gemini, wähle deinen Champion, verteidige ihn in Hacker-News-Threads. Meine tägliche Realität ist, dass ich fünf davon in Rotation betreibe — Claude Code, Codex CLI, Gemini CLI, PI und OpenCode — jeder gut bei einer anderen Art lokalem Minimum, gewechselt via einem Tool, das ich aus persönlicher Frustration heraus geschrieben habe. Dieser Post ist das Argument, warum das das richtige Modell für ernsthafte Arbeit 2026 ist.

Das Problem mit Einzel-Agent-Commitment

Jeder Coding-Agent ist gut bei leicht verschiedenen Dingen. Die Unterschiede sind nicht offensichtlich aus Benchmarks — sie zeigen sich in deiner eigentlichen Arbeit, in der Form der Tasks, die du ihnen gibst:

  • Claude Code tendiert dazu, am vorsichtigsten zu sein, was das Nicht-Brechen von bestehendem Verhalten angeht. Er liest Dateien gründlich, bevor er bearbeitet, bleibt nah an Projektkonventionen und ist der, dem ich bei einer Codebase, die mir am Herzen liegt, am meisten vertraue.
  • Codex CLI generiert schnell plausibel aussehende Scaffolds. Das ist der, den ich nehme, wenn ich einen ersten Draft von etwas will, bei dem der genaue Output weniger wichtig ist als die Geschwindigkeit.
  • Gemini CLI hat eine andere Reasoning-Textur, die manchmal durchbricht, wenn ein anderes Modell 15 Minuten lang in einer Schleife festgesteckt hat. Seine Failure-Modes sind verschieden — das ist der Punkt.
  • PI und OpenCode finden noch ihre Nischen in meinem Workflow — beide haben Momente, in denen sie mich positiv überraschen, besonders bei Tasks, bei denen die anderen drei sich austauschbar anfühlen.

Keine dieser Beobachtungen ist absolut. Für den Workflow von jemand anderem wären sie alle falsch. Sie sind jedoch real für meine Arbeit, und der einzige Weg, sie zu entdecken, war, jeden Agent monatelang auf echten Tasks zu betreiben.

Das Config-Switching-Problem

Fünf Agents zu betreiben klingt harmlos, bis man erkennt, dass jeder von ihnen seine eigene:

  • Auth-Token oder API-Key hat.
  • Config-Datei in seinem eigenen Geschmack (JSON, YAML, TOML, selbstgebaut) hat.
  • Rule-Files / Skill-Files / Instruction-Files unter leicht verschiedenen Pfaden hat.
  • Meinungen darüber hat, wo “der Projekt-Root” ist.
  • Meinungen darüber hat, welches Shell-Profil er sourcen soll.

Ich habe das Naheliegende zuerst versucht — ein großes dotfiles-Setup mit bedingten Blöcken pro Agent. Das hat eine Woche funktioniert. Dann habe ich ein neues Engagement hinzugefügt, das einen anderen API-Key brauchte, und das Ganze wurde zu einem Durcheinander aus “welches Env ist in welchem Terminal aktiv?” Multipliziert mit fünf Agents und zwei Clients ergibt das einen Vollzeitjob, der kein Schreiben von Software ist.

Was ich tatsächlich gebaut habe

Ich habe raise gebaut — ein Go-CLI, das zwischen per-Engagement-”KI-Profilen” via atomare Symlink-Swaps wechselt. Ein Befehl, und das komplette Set von KI-Tool-Configs kippt um. Es unterstützt aktuell 17 KI-Tools über die wichtigsten Coding-Agent- und General-Assistant-Familien.

Das Design ist absichtlich langweilig:

  • Jedes Profil ist ein Verzeichnis unter ~/.raise/profiles/<profile>/.
  • Jedes KI-Tool hat einen bekannten Config-Pfad (z.B. ~/.claude/config, ~/.config/gemini/config.toml).
  • Profile wechseln ist unter der Haube ln -sfn — atomar, kein Partial-State- Failure-Mode.
  • Credentials bleiben außerhalb des Profil-Trees und werden bei Aktivierung neu gelinkt, damit du keine API-Keys in das Profil-Verzeichnis synchronisierst.

Das war’s. Das Ganze sind ein paar hundert Zeilen Go. Der Grund, warum es nützlich ist, ist nicht, dass es clever ist — es ist, dass es das einzige Tool in seiner Kategorie ist, das nicht davon ausgeht, dass du einem Vendor committed bist. Jeder andere “KI-Config-Manager”, den ich mir angesehen habe, war entweder vendor-gebunden oder hat das Credential-Preservation-Problem nicht sauber gelöst.

Shared Skills über alle Agents

Das zweite Problem: Jeder Coding-Agent hat sein eigenes Rule-File-Format (CLAUDE.md, AGENTS.md, .cursorrules usw.). Wenn du fünf davon unabhängig pflegst, driften sie auseinander. Sie gehen out of sync. Eins landet drei Monate hinter den Coding-Standards des Teams.

Ich pflege eine einzige Source of Truth — rice-shared-skills — und das Rule-File jedes Agents ist ein dünner Wrapper, der die kanonischen Skills aus dieser Quelle einbindet. Wenn eine Konvention sich ändert, aktualisiere ich sie einmal, und jeder Agent bekommt die Änderung bei der nächsten Aktivierung.

Die Shared-Skills-Idee ist nicht neu. Was bemerkenswert ist, ist wie viel tägliche Reibung sie beseitigt, sobald sie läuft. Das Hintergrundgeräusch von “weiß Claude Code eigentlich, dass wir in diesem Repo auf pnpm 10 umgestellt haben?” verschwindet einfach.

Warum fünf, nicht zwei oder zehn

Ich bin nicht dogmatisch über die Zahl fünf. Es ist eine Beobachtung, keine Vorschrift. Wenn du immer nur eine Art von Arbeit machst, reichen wahrscheinlich zwei Agents. Wenn du forschungsnahe Arbeit auf exotischen Tech-Stacks machst, willst du vielleicht mehr als fünf.

Das Prinzip ist: Betreibe genug Agents, um lokale Minima zu entkommen, und nicht so viele, dass die Wechselkosten den Ausbruch-Nutzen übersteigen. Für mich sind das fünf. Die Zahl wird sich wahrscheinlich verschieben, wenn sich die Agent- Landschaft verschiebt.

Der Meta-Skill, den das trainiert

Mehrere Agents zu betreiben trainiert einen Skill, den Einzel-Agent-Nutzer oft nicht entwickeln: zu erkennen, wann man feststeckt. Wenn ein einziger Agent scheitert, ist die Versuchung, weiterzumachen. Wenn man fünf hat, ist das Wechseln günstig genug, dass man die abnehmenden Returns des Bestehenauf-eins merkt. Dieses Bemerken ist letztendlich derselbe Senior-Engineering-Skill, der “eine Stunde allein debuggen” von “einen Kollegen nach 15 Minuten gepingt und in 20 Sekunden unblocked” unterscheidet.

Die Agents sind Stützräder für eine Disziplin, die schon immer gutes Engineering war. Die Reibung ist der Punkt.

Die 2026-These

Die Teams, die 2026 bei KI-gestützter Engineering-Velocity gewinnen, wählen keinen Champion und heiraten ihn. Sie betreiben Flotten von Agents, pflegen eine Shared- Skills-Schicht über ihnen und behandeln die Vendor-Wahl als austauschbare Ware. Alle anderen optimieren ein einzelnes Tool, dessen Lock-in sie in 18 Monaten bereuen werden.

Fünf Agents. Eine Shared-Skills-Schicht. Atomisches Profil-Switching. Das ist der Stack.