KI Coding Agent: Autonomie statt nur Autocompletion

KI Coding Agent: Ein KI Coding Agent macht mehr als Autocompletion

Ein KI Coding Agent erledigt deutlich mehr als eine Zeile mit Autocomplete während du tippst. Gib ihm eine Aufgabe (diesen Bug fixen, diesen Endpoint hinzufügen, dieses Modul refaktorieren), und er plant die Schritte, bearbeitet Dateien über dein ganzes Repository, führt deine Tests aus und korrigiert Fehler, bevor du den ersten Diff siehst. Diese Schleife ist der entscheidende Unterschied zwischen einem KI Coding Agent und einem Copilot, der deinen Satz beendet. Sie verändert, wie du einen Sprint planst, nicht nur wie schnell du schreibst. Dieser Artikel beschreibt, was dieser Wandel bei einem echten Engineering-Team (5 bis 50 Personen) auslöst – nicht das, was ein Vendor auf seinen Folien behauptet.

Zusammenfassung

Ein KI Coding Agent arbeitet autonom über mehrere Dateien, während ein Copilot nur einzelne Zeilen ergänzt. Der praktische Unterschied liegt in der Messung: Neue Mitarbeiter brauchen statt zwei bis drei Wochen nur noch wenige Tage für ihren ersten PR, Multi-Repo-Akuranz entscheidet über die reale Performance, und Code Review wird zum Engpass – nicht die Code-Generierung. Devin erreicht 85% auf SWE-Bench, doch 91% der echten Agent-Resolutionen brauchen Nutzer-Korrektionen. Die richtige Frage ist nicht "welcher Agent ist am besten", sondern "wo messe ich den Gewinn in meinem Team".

Was einen KI Coding Agent von Autocomplete unterscheidet

Inline-Vorschläge prognostizieren die nächsten paar Token während du tippst. Du bleibst bei jedem Schritt involviert. Ein KI Coding Agent funktioniert anders: Er liest relevante Teile deines Repos, entwirft einen Plan, bearbeitet mehrere Dateien, führt die Tests aus, liest die Fehler-Ausgabe und versucht es erneut – oft ohne dass du jeden Schritt beobachtest.

Du kennst den alten Workflow bereits: Grep, Ctrl+F, Git Blame, dann eine Slack-Nachricht an die Person, die die Datei zuletzt angefasst hat. Ein Agent ersetzt die ersten drei Schritte durch ein Werkzeug, das diese schneller ausführt, als du den Grep-Befehl eingeben kannst. Er ersetzt die Slack-Nachricht nicht. Jemand muss den Diff noch immer überprüfen und trauen.

Cursor's Agent-Modus, GitHub Copilot's Agent-Modus, Claude Code, Devin und Replit Agent erfüllen alle diese Definition, mit unterschiedlicher Autonomie. Cursor und Copilot bleiben näher beim Editor und erwarten, dass ein Mensch die meisten Schritte genehmigt. Devin läuft weiter eigenständig in seiner eigenen Cloud-Umgebung, bevor er einen PR zurückgibt.

Eine vereinfachte Version der Schleife sieht in der Praxis so aus:

1. lesen: relevante Dateien für die Aufgabe finden
2. planen: eine Abfolge von Änderungen entwerfen, nicht nur einen Diff
3. bearbeiten: Änderungen über beliebig viele Dateien anwenden
4. ausführen: Test-Suite oder eine begrenzte Teilmenge ausführen
5. erneut lesen: Fehler-Ausgabe analysieren
6. Schritte 3-5 wiederholen, bis Tests bestanden sind oder Budget verbraucht

Schritt 6 ist dort, wo Marketing aufhört und Engineering anfängt. Eine Schleife ohne Wiederholungs-Budget wird gerne eine Stunde damit verbringen, dieselbe Funktion auf fünf verschiedene Wege zu schreiben. Eine Schleife mit knappem Budget gibst dir etwas Unvollendetes zurück und nennt es erledigt. Keiner dieser Fehlzustände zeigt sich in einer Benchmark-Bewertung.

Die Zahlen werden ehrlich: 13,86% bis heute

Als Cognition Devins Ergebnisse veröffentlichte, löste der Agent 13,86% echter GitHub-Issues komplett, ohne Unterstützung, während der Stand der Technik damals unter 2% lag. Das war die ganze Geschichte in einer Zahl: Agents konnten echte End-to-End-Arbeit erledigen, nur nicht zuverlässig. Der technische Bericht ist immer noch öffentlich, und es lohnt sich, ihn zu lesen, bevor du einer Vendor-Benchmark glaubst, denn er zeigt genau, wie der Test begrenzt wurde.

Zwei Jahre später lösen Top-Agents 85 bis 90% auf kurierten Benchmarks wie SWE-Bench Verified, und die schnellsten führen die Befehle mit ungefähr 2,5x dem Token-Durchsatz der frühen Anführer aus. Das ist ein echter Sprung. Es ist auch ein kurierter Benchmark, aus Issues gebaut, die bereits eine klare Lösung und einen klaren Test haben. Dein Backlog ist nicht kuriert. Der Unterschied zwischen "löst ein gut beschriebenes GitHub-Issue" und "versteht, warum deine Auth-Middleware so verdrahtet ist" ist der Unterschied, der entscheidet, ob ein Agent dir einen Nachmittag spart oder dir einen kostet.

Terminal-fokussierte Benchmarks erzählen eine etwas andere Geschichte als reine Code-Fix-Benchmarks, weil sie einen Agent darin bewerten, wie er Befehle ausführt und deren Ausgabe korrekt liest – näher an dem, was während einer Debug-Sitzung tatsächlich passiert. Ein Werkzeug kann bei einem gut und bei dem anderen mittelprächtig abschneiden. Wenn ein Vendor nur eine Zahl veröffentlicht, frag, welcher Benchmark es ist, bevor du ihn mit der Zahl eines Konkurrenten von einem anderen Test vergleichst.

Die zwei Wochen, die wirklich zählen: Onboarding mit einem KI Coding Agent

Der deutlichste messbare Gewinn ist nicht, dass ein erfahrener Engineer schneller shipped. Es ist die erste Woche eines Junior Engineers. Ein neuer Mitarbeiter in einem 100K-LOC-Repo verbrachte früher die ersten Tage mit Lesen, nicht mit Schreiben: Welcher Service gehört diese Tabelle, wo wird dieses Event veröffentlicht, warum hat diese eine Funktion drei Call-Sites, die unverbunden aussehen.

Ein KI Coding Agent, der "wo ist Refund-Logik implementiert" in Sekunden beantworten kann, beseitigt diese Ramp-up-Phase nicht ganz. Er schneidet den Teil weg, der pure Suche war. Teams, die einen Agent ins Onboarding integriert haben, berichten, dass der erste aussagekräftige PR in Tagen, nicht in der zweiten oder dritten Woche, landet – hauptsächlich weil der neue Mitarbeiter nicht auf die Slack-Antwort eines erfahrenen Engineers wartet, um eine Frage zu entsperren, die die Codebase selbst beantworten könnte.

Der Fehlzustand ist vorhersehbar: Teams behandeln den Agent als Ersatz für eine geschriebene Architektur-Doku, statt als schnellere Weise, diese zu erkunden. Ein Agent, der "wo"-Fragen gut beantwortet, kann einem Junior immer noch nicht sagen, "warum wir dies vor drei Jahren der offensichtlichen Alternative vorgezogen haben". Dieser Kontext lebt in Menschen oder in einer ADR-Datei, nicht allein in der Diff-Historie.

Messe dies in Stunden, nicht in einer Sentiment-Umfrage. Verfolge die Zeit zwischen dem ersten Commit eines neuen Mitarbeiters und ihrem ersten Commit, der einen zweiten Service berührt. Diese Zahl von zwölf Tagen auf fünf zu verringern ist ein echtes Ergebnis, das du einem Manager berichten kannst. "Das Onboarding fühlt sich glatter an" ist nicht.

Warum Multi-Repo die Frage ist, die Benchmark-Tabellen überspringen

Die meisten öffentlichen Vergleiche testen einen Agent gegen ein einzelnes Repository mit einer einzelnen klaren Aufgabe. Teams von 20 oder mehr arbeiten so selten. Ein Checkout-Bug könnte ein Frontend-Repo, einen Payments-Service und ein gemeinsames Types-Paket berühren – drei Orte, über die ein Agent reasoning müssen könnte, bevor er überhaupt einen Fix vorschlagen kann.

Single-Repo-Autocomplete-Tools brauchen das nicht zu lösen. Codebase-Chat-Tools, die auf natürlichsprachiger Suche aufgebaut sind, tun es, weil die Frage, die ein Entwickler tatsächlich stellt – "wo ist das validiert" – selten eine Repo-Grenze respektiert. Wenn dein Agent nur die in deinem Editor offene Datei sehen kann, werden Multi-Repo-Fragen zu drei separaten, nicht verbundenen Sitzungen, statt einer kohärenten Antwort.

Das ist der praktische Grund, jeden Agent gegen dein eigenes Multi-Repo-Setup zu testen, bevor du ihn ausrollst – nicht gegen ein Demo-Repo, das der Vendor ausgewählt hat. Ein Werkzeug, das auf einem Single-Repo-Benchmark identisch mit einem Konkurrenten aussieht, kann sich sehr unterschiedlich verhalten, sobald es einen Call über drei Codebases mit drei verschiedenen Inhabern hinweg verfolgen muss.

Ein konkreter Test: Nimm einen Bug von letztem Quartal, der tatsächlich zwei Repos spannte. Weise den Agent darauf hin, ohne Hinweise, welche Dateien wichtig sind. Wenn es drei separate Sitzungen und einen Menschen braucht, um die Findings zu verbinden, das ist dein echter Multi-Repo-Score, nicht die Zahl auf der Vendor-Landingpage.

Code Review wird zum Engpass, nicht der Code

Hier ist die Wahrheit, die jeder empfiehlt, aber wenige messen: Den autonomen Modus eines Agents einschalten und ihn PRs frei öffnen lassen. Eine groß angelegte Analyse von 20.574 echten KI-Agent-Sitzungen fand, dass 91,49% der sichtbaren Agent-Resolutionen immer noch explizite Nutzer-Korrektionen brauchten, bevor sie wirklich nutzbar waren. Der Agent hat etwas fertiggestellt. Es war selten das Finale.

Diese Zahl rahmt die ganze Rollout-Frage neu. Der Engpass war nie "kann der Agent Code schreiben". Es ist "hat dein Team die Review-Kapazität, um die 9 von 10 Mal zu fangen, wenn Korrektionen nötig sind". Drei von fünf Teams unterschätzen das und enden mit einer Review-Queue länger als der, die es vorher gab.

Die Lösung ist nicht, den Agent auszuschalten. Es ist, zu begrenzen, was er ohne Überwachung berühren darf:

• Sicher ohne Überwachung: gut beschriebene Bugs mit einem existierenden fehlgeschlagenen Test, Dependency-Updates, Dead-Code-Entfernung, Formatting- und Lint-Fixes.

• Immer vor dem Merge überprüfen, nicht danach: alles, das Auth, Billing, eine Datenbankmigration oder einen Public-API-Vertrag berührt.

• Separat verfolgen: die Korrekturrate für jede Kategorie. Wenn Billing-nahe PRs doppelt so oft Korrektur brauchen wie Lint-Fixes, ist das das Signal, den Agent-Umfang weiter zu verengen – nicht um mehr Review-Köpfe hinzuzufügen.

Die meisten Teams überspringen diese Kategorisierung ganz und wenden eine Review-Richtlinie auf jeden vom Agent geöffneten PR an. Die, die es aufspalten, berichten durchweg eine kürzere Review-Queue innerhalb eines Monats – nicht länger.

Cursor, Claude Code, Devin, Tabnine: Wofür jeder tatsächlich gebaut ist

Diese vier werden ständig verglichen, meist auf der falschen Achse. Sie sind nicht austauschbar, und die Unterschiede sind wichtiger als jede einzelne Benchmark-Bewertung.

• Cursor bleibt dem Editor am nächsten. Starke Inline-Vervollständigung plus Agent-Modus für Multi-Datei-Edits, wobei ein Mensch die meisten Schritte genehmigt. Gute Passung für Teams, die agentic Hilfe wollen, ohne die Moment-zu-Moment-Kontrolle der IDE zu verlieren.

• Claude Code läuft Terminal-first, mit breitem Repo-Kontext und minimaler Hand-Holding, sobald du eine Aufgabe definierst. Gute Passung für Engineers, die bequem einen ganzen Feature-Branch delegieren und das Ergebnis als Diff überprüfen, nicht als Stream von Vorschlägen.

• Devin geht am weitesten in Autonomie, arbeitet in seiner eigenen Cloud-Umgebung auf begrenzten Aufgaben wie Migrationen oder Triage, bevor er einen PR zurückgibt. Gute Passung für gut definierte, wiederholbare Arbeit, nicht mehrdeutige Product-Entscheidungen.

• Tabnine differenziert sich durch Deployment, nicht Autonomie: On-Prem- oder Air-Gapped-Optionen und Null-Code-Retention für Teams, die proprietären Code nicht an eine Drittpartei-Cloud schicken können – was mehrere der oben genannten von vornherein ausschließt.

Keiner dieser Agents ersetzt das "Warum", das ein erfahrener Engineer im Kopf trägt. Alle schneiden das "Wo" und "Was" ab, das früher einen Morgen auffraß. Die Wahl zwischen ihnen dreht sich weniger darum, welcher diesen Monat klüger ist – da die zugrunde liegenden Modelle schnell konvergieren – sondern darum, welchen Fehlzustand dein Team tolerieren kann: Ein Cursor-Vorschlag, den du ablehnst, kostet Sekunden; ein Devin-PR, den du ablehnst, nachdem er 20 Minuten ohne Überwachung lief, kostet mehr.

Was man messen sollte, bevor man es im Team einführt

Überspringe die Vendor-Benchmark und messe stattdessen drei Dinge in deinem eigenen Repo:

1. Zeit bis zur ersten korrekten Antwort auf fünf echte Fragen, die dein Team letzte Woche gestellt hat – nicht eine Demo-Frage. Hole sie direkt aus der Slack-History, sie sind ehrlicher als alles, was ein Sales-Engineer vorzeigen wird.

2. Korrekturrate auf den ersten 20 vom Agent geöffneten PRs, verfolgt von wem, der sie überprüft, nicht vom Werkzeug selbst gemeldet. Ein PR, der einen kleinen Kommentar brauchte, zählt anders als einer, der eine komplette Überarbeitung brauchte – verfolge beide separat.

3. Multi-Repo-Akuranz, wenn dein Codebase mehr als ein Repository umfasst, explizit getestet – da die meisten Agents nicht so getestet wurden. Nutze die Kalt-Test-Methode von oben und messe, wie lange ein Mensch braucht, um das Ergebnis zu überprüfen.

Überspringe das, und du nimmst den Agent basierend auf einem Kollegenpost an, nicht auf deinem eigenen Repo. Teams, die zuerst messen, enden meist damit, den Agent enger zu begrenzen, als der Vendor es standardmäßig tut – und sind einen Monat später glücklicher damit.

Die Entscheidung für dein Team dieses Quartal

Wenn dein Onboarding-Schmerz real und messbar in verlorenen Wochen ist – ja, fang dort an. Es ist der höchste Impact, das geringste Risiko, weil eine Junior-Frage einen erfahrenen Engineer ohnehin unterbrechen würde.

Wenn dein echter Engpass Review-Kapazität ist, den autonomen PR-Modus zuerst einzuschalten wird diesen Engpass verschärfen, bevor es irgendetwas schneller macht. Begrenzen auf Onboarding und gut beschriebene Bug-Fixes zunächst. Expandieren, sobald du eine Korrekturrate gemessen hast, die du leben kannst – nicht davor.