Coding-Agenten 2026: Nicht der beste Prompt zählt, sondern der beste Arbeitsauftrag
Codex CLI, Claude Code und Gemini CLI sind keine drei Bewerber für denselben Job. Entscheidend ist, welche Aufgabe ein Team sauber begrenzen, prüfen und verantworten kann.
Um 16:40 Uhr ist das Ticket noch harmlos: Ein Fehler in einer Importmaske, eine klar beschriebene Ausnahme, vermutlich zwei Dateien. Um 17:05 Uhr liegt ein Agenten-Diff vor. Er fasst zwölf Dateien an, zieht eine Hilfsfunktion hoch, ergänzt Tests und schlägt nebenbei eine Umbenennung vor. Alles wirkt plausibel. Genau deshalb wird es unbequem.
Die entscheidende Frage lautet jetzt nicht: Welcher Coding-Agent ist am klügsten? Sondern: Wer kann dieses Ergebnis morgen früh noch erklären, prüfen und verantworten? OpenAI Codex, Claude Code und Gemini CLI können Arbeit in einem Repository übernehmen. Sie sind aber keine drei austauschbaren Autocomplete-Fenster. Sie verändern, wie ein Team Aufgaben schneidet, Kontext bereitstellt und Risiken begrenzt.
Der Vergleich beginnt bei der Aufgabe, nicht beim Modell
Ein Agent ist am nützlichsten, wenn ein Team ihm keinen Wunsch, sondern einen Arbeitsauftrag gibt: Fehler reproduzieren, die Ursache in einem abgegrenzten Modul suchen, einen kleinen Patch erzeugen und die vorhandenen Checks ausführen. Das klingt nüchtern. Es ist jedoch der Unterschied zwischen Delegation und Wunschdenken.
GitHub empfiehlt für Pull Requests kleine, fokussierte Änderungen, Kontext für Reviewer und einen Selbstcheck mit Build und Tests. Diese alte Disziplin wird durch Agenten nicht überflüssig. Im Gegenteil: Weil ein Agent mehr Dateien schneller berühren kann als ein Mensch, wird sie zum Sicherheitsgurt. Ein riesiger, beeindruckender Diff ist selten ein guter erster Pilot.
Codex: gut, wenn der Arbeitsauftrag schon überprüfbar ist
OpenAI Codex passt in Teams, deren Repository nicht nur Code, sondern auch einen verlässlichen Arbeitsrahmen enthält: nachvollziehbare Skripte, Tests, Linter, Vorschauen und klare Hinweise für Mitwirkende. OpenAI beschreibt Codex als Agenten zum Verstehen von Codebasen, Bauen, Testen, Reviewen und Ausliefern fokussierter Änderungen. Der operative Vorteil liegt deshalb nicht in einem spektakulären Prompt, sondern in einer klaren Kette: Ticket, begrenzter Diff, nachweisbare Checks, menschliche Entscheidung.
Das macht Codex nicht automatisch sicher. Wenn test rot und unzuverlässig ist oder niemand weiß, welche Migration gefährlich wäre, erbt der Agent genau diese Unklarheit. Für den Einstieg eignen sich Reparaturen mit vorhandener Reproduktion, kleine UI- oder Testaufgaben und Dokumentationsarbeit. Produktionszugriffe, Secrets oder irreversible Datenänderungen gehören nicht in den ersten Auftrag.
Claude Code: gut, wenn Regeln nicht nur im Kopf existieren
Claude Code ist dann interessant, wenn der Auftrag viel Erklärung und Projektwissen braucht: eine ältere Komponente verstehen, eine Entscheidung gegen Alternativen abwägen oder eine Refactoring-Idee zuerst als Plan sichtbar machen. Das ist kein Freifahrtschein für große Umbauten. Es ist eine Einladung, Architekturregeln so zu dokumentieren, dass sie auch außerhalb des Kopfes einzelner Senior-Entwickler existieren.
Die CLI führt Berechtigungen ausdrücklich als Steuerungsebene; ein Überspringen der Abfragen wird dort selbst als gefährlich markiert. Das ist eine nützliche Erinnerung: Geschwindigkeit entsteht nicht, indem Teams Schutzmechanismen unsichtbar abschalten. Sie entsteht, wenn vorher klar ist, welche Befehle ein Agent ausführen darf, wann er anhalten muss und wer bei Unsicherheit entscheidet.
Gemini CLI: gut, wenn Kontext eine Struktur hat
Gemini CLI hilft besonders dort, wo ein Auftrag mehrere Ebenen eines Projekts berührt. Seine Dokumentation zu GEMINI.md beschreibt hierarchische Projektanweisungen und modulare Imports. Praktisch heißt das: Teamregeln können global gelten, in einem Teilbereich präziser werden und bei Bedarf erst geladen werden.
Das ist wertvoll für Monorepos und gewachsene Systeme, aber nur dann, wenn die Struktur gepflegt wird. Viel Kontext ist kein Ersatz für eine Entscheidung über die Änderungsgrenze. Ein Agent, der das gesamte Repository lesen darf, sollte nicht deshalb das gesamte Repository ändern dürfen.
Eine Pilotwoche, die wirklich etwas beantwortet
Wer drei Agenten vergleichen will, sollte nicht drei Demos gegeneinander laufen lassen. Sinnvoller ist eine Woche mit derselben Klasse von Aufgaben: etwa reproduzierbare Bugs in einem nicht kritischen Modul oder Testlücken um bekannte Fehlerfälle. Für jede Aufgabe werden vorab vier Dinge notiert:
- Welche Dateien und Systeme dürfen berührt werden?
- Welche Befehle sind der Beleg für den Patch?
- Welche Entscheidungen bleiben beim Menschen?
- Kann ein Reviewer den Diff in einem überschaubaren Durchgang verstehen?
Danach bewertet das Team nicht den schönsten Chatverlauf, sondern die Qualität des Übergangs: War der Patch kleiner oder größer als nötig? Waren seine Annahmen sichtbar? Konnte der Reviewer ihn zügig begründen oder nur auf grüne Tests hoffen? Diese Fragen zeigen, ob ein Agent zum eigenen Arbeitsmodell passt.
Der eigentliche Gewinner ist ein begrenzter Prozess
Coding-Agenten verschieben Arbeit vom Tippen zum Entscheiden. Das kann Teams spürbar entlasten, solange die Delegation klein genug bleibt, um überprüfbar zu sein. GitHub Copilot und Cursor können im Editor der schnelle Gesprächspartner sein; CLI-Agenten übernehmen eher ganze Arbeitsschritte. Beide Rollen sind nützlich. Keine ersetzt die Verantwortung für einen Merge.
Die richtige Schlussfrage für Codex, Claude Code oder Gemini CLI ist deshalb nicht: „Welcher gewinnt?“ Sondern: „Welchen klaren, reversiblen Arbeitsschritt vertrauen wir diesem Werkzeug als Nächstes an?“ Wenn ein Team das beantworten kann, wird aus Agenten-Hype ein belastbarer Entwicklungsprozess.