Die meisten Unternehmen, mit denen ich spreche, budgetieren zwischen 50 und 200 Dollar pro Entwickler pro Monat für KI-Coding-Tools. Dann versuchen sie zu messen, ob die Entwickler dadurch 10 % schneller geworden sind. Coding Agents sind keine IDE-Plugins — und genau darin liegt das zentrale Missverständnis, weil Unternehmen Produktivität messen, obwohl sie Relevanz messen müssten.

Das ist wie den ROI zu messen, wenn man von JetBrains auf Visual Studio wechselt. Der Unterschied ist nämlich minimal, schwer messbar und von Person zu Person völlig verschieden. Deshalb verbringt man mehr Zeit mit der Diskussion über die Metriken, als man jemals durch den Wechsel gewinnt.

Das Problem ist also nicht die Messung. Das Problem ist das Denkmodell.

Warum Coding Agents in der IDE-Plugin-Falle stecken

Wenn Unternehmen über Coding Agents nachdenken, denken sie „IDE-Plugin“: Etwas, das man installiert, jedem Entwickler gibt und dann hofft, dass es ein paar Stunden pro Woche spart. Kleine Kosten, marginale Verbesserung, schwer zu quantifizieren — obwohl dieses Modell auf den ersten Blick plausibel wirkt, greift es dennoch viel zu kurz.

Für Copilot-Tab-Completion ist das zwar ein passendes Modell. Allerdings ist es für das, was Coding Agents gerade werden, das falsche, weil sich die Rolle verschiebt und der Impact dadurch größer, aber auch komplexer wird.

Die bessere Analogie ist daher ein Rechenzentrum. Ein Supercomputer. Eine große, strategische Investition, die sorgfältige Planung braucht, echtes Experimentieren und ernsthaftes Budget. Richtig umgesetzt macht sie das Team jedoch nicht 10 % schneller. Sie verändert, wie Software gebaut wird.

Die Lücke zwischen diesen beiden Denkmodellen — genau da stecken die meisten Unternehmen gerade fest.

Was Coding Agents für 20.000 Dollar liefern

Vor ein paar Tagen hat Anthropic einen Artikel veröffentlicht, den ich deshalb für Pflichtlektüre halte, weil er zeigt, was Coding Agents heute leisten — für jeden, der Entscheidungen über KI in Engineering-Organisationen trifft.

Das Setup: Nicholas Carlini, Forscher bei Anthropic, hat 16 Claude-Agents parallel laufen lassen. Jeder Agent lief dabei in einem eigenen Docker-Container, und alle teilten sich ein gemeinsames Git-Repository. Die Aufgabe: einen C-Compiler in Rust schreiben. Von Grund auf. Fähig, den Linux-Kernel zu kompilieren.

Kein Internetzugang. Kein menschliches Pair-Programming. Nur Agents, ein Test-Harness und eine Schleife: „Nimm die nächste Aufgabe, löse sie, push, wiederhole.“

Das Ergebnis nach zwei Wochen:

• ein Compiler mit rund 100.000 Zeilen Rust-Code
• ein bootfähiges Linux 6.9 auf x86, ARM und RISC-V
• Redis, SQLite, PostgreSQL, FFmpeg und QEMU werden kompiliert
• 99 % der GCC Torture Test Suite bestanden
• Doom lässt sich kompilieren und ausführen

Gesamtkosten: rund 20.000 Dollar an API-Nutzung.

Warum es funktioniert hat — und warum Coding Agents keine IDE-Plugins sind

Das Interessante an diesem Beispiel ist nicht nur das Ergebnis, sondern was nötig war, um dort hinzukommen. Die Agents haben nämlich nicht einfach nur Code geschrieben — sie brauchten Infrastruktur, damit sie auf Kurs bleiben, während sie parallel arbeiten:

• Ein hochwertiges Test-Harness, damit Ergebnisse ohne menschliche Review verifiziert werden können. Die Test-Suite musste nahezu perfekt sein — weil autonome Agents genau das „lösen“, was der Test misst. Auch wenn das nicht das ist, was man eigentlich will.
• Synchronisation über Git-Locks. Jeder Agent hat eine Aufgabe beansprucht, indem er eine Lock-Datei geschrieben hat. Wenn zwei Agents dieselbe Aufgabe wollten, hat der Git-Konflikt den zweiten gezwungen, etwas anderes zu wählen. Einfach, aber effektiv.
• Spezialisierte Agent-Rollen. Nicht jeder Agent hat Features geschrieben. Stattdessen hat einer duplizierten Code gesucht, ein anderer sich um Performance gekümmert, ein dritter um Dokumentation, und ein weiterer hat die Rust-Code-Qualität aus Expertensicht kritisiert.
• Feedback für LLMs, nicht für Menschen. Die Test-Ausgabe war minimal gehalten, damit das Kontextfenster der Agents nicht verschmutzt wird. Fehler waren außerdem so formatiert, dass grep sie findet. Zusammenfassungen waren vorberechnet, damit Agents keine Tokens verschwenden.

Das ist folglich Engineering. Nicht nur Prompt-Engineering — sondern Systems Engineering. Die Art von Denken, die man auch beim Design einer CI/CD-Pipeline oder eines verteilten Build-Systems braucht.

Wo es trotzdem gescheitert ist

Carlini ist erfrischend ehrlich über die Grenzen, und genau deshalb wirkt die Sache glaubwürdig.

Der generierte Code ist beispielsweise weniger effizient als GCC mit deaktivierten Optimierungen. Die Rust-Code-Qualität ist „solide, aber nicht auf dem Niveau eines erfahrenen Rust-Entwicklers.“ Außerdem haben neue Features regelmäßig bestehende Funktionalität kaputt gemacht. Das 16-Bit-x86-Real-Mode-Problem konnten die Agents nicht lösen — dafür mussten sie auf GCC zurückgreifen. Und als alle Agents auf denselben Linux-Kernel-Bug gestoßen sind, haben 16 Agents nicht geholfen — sie haben alle denselben Fix versucht und sich gegenseitig überschrieben.

Klingt bekannt? Mir schon. Denn ich habe all das in menschlichen Engineering-Teams genauso gesehen.

Die Rechnung, die niemand machen will

Manche Leute werden bei 20.000 Dollar für KI-Agents die Hände über dem Kopf zusammenschlagen. Zwanzigtausend Dollar! Für generierten Code!

Aber rechnen wir. Je nachdem, wo ein Unternehmen einstellt, sind 20.000 Dollar die Vollkosten von zwei bis fünf Senior-Entwicklern für einen Monat. Könnten zwei bis fünf Entwickler jedoch in einem Monat einen C-Compiler von Grund auf bauen? Einen, der die GCC Torture Test Suite besteht? Der den Linux-Kernel auf drei Architekturen kompiliert?

Keine Chance. Nicht in einem Monat. Nicht in sechs Monaten. Vielleicht nicht einmal in einem Jahr — es sei denn, sie haben es schon einmal gemacht.

Die 20.000 Dollar wirken also teuer, wenn man sie mit einem Copilot-Abo vergleicht. Vergleicht man sie allerdings mit Entwicklergehältern, sind sie ein Schnäppchen — selbst mit allen Einschränkungen.

„Aber Coding Agents machen doch Fehler“

Ja. Sie produzieren unnötigen Code. Sie laufen in falsche Richtungen. Sie erfordern Momente, in denen man alles noch mal von vorne denken muss. Das Anthropic-Projekt hat all das erlebt: Agents haben gegenseitig ihre Arbeit überschrieben, sind in Schleifen am selben Bug hängengeblieben und haben funktionierende Features kaputt gemacht, während sie neue eingebaut haben.

Aber: Das passiert in menschlichen Teams genauso. Wer das anders sieht, hat noch nie an einem Großprojekt gearbeitet.

Der Unterschied ist nicht, dass Agents perfekt sind. Der Unterschied ist vielmehr, dass Agents schnell sind. Wenn ein Agent in die falsche Richtung läuft, hat man Stunden verloren, vielleicht einen Tag. Wenn dagegen ein Team in die falsche Richtung läuft, hat man Wochen oder Monate verloren — plus die Moral-Kosten, wenn man den Leuten sagt, dass ihre Arbeit nochmal gemacht werden muss.

Der Vorteil von Coding Agents ist nicht Qualität — sondern Relevanz

Selbst mit Budget ist es langsam, ein starkes Engineering-Team aufzubauen. Man muss Talente finden, interviewen, einstellen und Kündigungsfristen abwarten. Danach folgt die Einarbeitung, die Integration ins bestehende Team, und schließlich die Frage, wer passt und wer nicht.

Das dauert Monate. Oft sogar Jahre, bis ein Team volle Geschwindigkeit erreicht.

Coding Agents — richtig eingesetzt, mit ordentlicher Infrastruktur, Test-Harness und Engineering-Disziplin — können diese Lücke überbrücken. Nicht die Lücke zwischen guter und schlechter Qualität, sondern zwischen Unternehmen, die Zugang zu großen Engineering-Pools haben, und denen, die ihn nicht haben.

Und hier kommt der Punkt, der mich nicht loslässt: Qualität ist wichtig. War sie immer. Wird sie immer sein. Aber perfekt gebaute Software, die sechs Monate zu spät in einen Markt kommt, der schon weitergezogen ist, ist dennoch wertlos. Das Risiko für die meisten Unternehmen heute ist nämlich nicht, etwas Unperfektes zu liefern. Es ist, etwas Irrelevantes zu liefern.

In einer Welt, die sich exponentiell schneller bewegt, ist Time-to-Market kein Nice-to-have. Es ist Überleben.

Was das für Unternehmen bedeutet — Coding Agents sind keine IDE-Plugins

Hört auf, Coding Agents wie ein Tool-Abonnement zu behandeln, und hört auf, ihren Wert daran zu messen, ob einzelne Entwickler sich 10 % produktiver fühlen.

Fangt stattdessen an, sie wie Infrastruktur zu behandeln. Wie ein neues Rechenzentrum. Wie die Art von Investition, die eine Strategie braucht, ein Team das sie betreibt, echtes Experimentieren um herauszufinden was funktioniert, und ein Budget das dem potenziellen Impact entspricht.

Das Anthropic-Beispiel ist kein Zaubertrick. Es ist vielmehr ein Proof of Concept für eine neue Art, Software zu bauen — eine, die genauso viel Engineering-Disziplin braucht wie klassische Entwicklung, aber Zeiträume komprimiert, die durch reines Hiring niemals erreichbar wären.

Die Unternehmen, die herausfinden, wie man hier richtig investiert, werden deshalb einen strukturellen Vorteil haben. Nicht weil ihr Code besser ist. Sondern weil ihr Code existiert, während alle anderen noch Stellen ausschreiben.