Kein Hype, keine Panik: Ein ehrlicher Blick auf den Stand der Technik. Wo Agents Entwickler-Teams zehnmal schneller machen, wo sie zuverlässig versagen — und warum das entscheidend von der Aufgabenstruktur abhängt.
Ein Entwicklungsteam einer deutschen Großbank stand vor einer überschaubaren Aufgabe: Hunderttausende Dateien eines proprietären ETL-Frameworks mussten auf einen moderneren Standard migriert werden. Die Arbeit war mechanisch, vorhersehbar, gut dokumentiert. Ein menschlicher Entwickler brauchte dafür dreißig bis vierzig Stunden pro Datei. Der Coding Agent erledigte dieselbe Aufgabe in drei bis vier. Zehnmal schneller.
Dann kam die nächste Frage: Welches Framework sollte das Migrationsziel sein? Welche Architektur trägt die nächsten zehn Jahre? Was bedeutet die Entscheidung für die Abhängigkeiten zwischen Systemen, die seit zwei Jahrzehnten organisch gewachsen sind? Der Agent produzierte Antworten — technisch kohärente, keine davon eindeutig falsch. Aber keine davon war wirklich richtig, denn Richtigkeit hängt hier von Teamgröße, Budget, Unternehmenskultur und strategischen Prioritäten ab. Von Dingen, die nicht im Code stehen.
Diese Differenz — der Zehnfaktor bei der Migrationsmechanik und das vollständige Versagen bei der Richtungsfrage — beschreibt ziemlich genau, was Coding Agents Anfang 2026 leisten können und was nicht.
Starke Leistung in engen Grenzen
Klingt interessant?
Die ehrlichste Bestandsaufnahme kommt von Cognition, dem Unternehmen hinter dem Coding Agent Devin, das nach achtzehn Monaten Produktiveinsatz eine interne Leistungsbewertung veröffentlichte. Ihr Urteil: Devin ist auf Senior-Niveau beim Verständnis von Codebases, aber auf Junior-Niveau bei der Ausführung. Ein unendlich parallelisierbarer Junior-Entwickler, der nie schläft.
Was bedeutet das konkret? Beim oben genannten ETL-Projekt — reale Produktionsdaten aus dem Bankenumfeld — erledigte der Agent jede Datei in drei bis vier Stunden statt dreißig bis vierzig. Bei der Behebung von Sicherheitslücken, die statische Analysewerkzeuge wie SonarQube aufdeckten, brauchte ein menschlicher Entwickler durchschnittlich dreißig Minuten pro Schwachstelle; Devin durchschnittlich anderthalb Minuten. Testabdeckungen stiegen regelmäßig von fünfzig bis sechzig auf achtzig bis neunzig Prozent, sobald Agents systematisch für die Testgenerierung eingesetzt wurden.
Der gemeinsame Nenner ist die Aufgabenstruktur. Agents liefern dann zuverlässig, wenn Anforderungen konkret sind und Ergebnisse überprüfbar: Endpoints definieren, Datenbankzugriffe schreiben, Dateien nach dokumentierten Transformationsregeln migrieren, Unit-Tests für bestehende Funktionen generieren. Diese Aufgaben haben richtige Antworten — oder zumindest klar erkennbar falsche. Der Agent kann sein eigenes Ergebnis validieren.
Auf dem SWE-bench-Benchmark, der misst, wie gut Agenten-Systeme echte GitHub-Issues aus populären Open-Source-Projekten lösen können, erreichte die Kombination aus Claude 3.5 Sonnet und einem optimierten Agenten-Scaffolding 49 Prozent auf dem verifizierten Datensatz. Im Juli 2025 erzielte das Open-Source-System mini-SWE-agent 65 Prozent. Die Kurve zeigt steil nach oben. Aber 65 Prozent bedeuten eben auch: jede dritte Aufgabe scheitert — und in der Produktion kündigen Fehler sich nicht an.
Wo der Kontext ausläuft
Das Problem ist nicht mangelnde Intelligenz. Es ist der fehlende Kontext.
Ein typisches Enterprise-Monorepo umfasst Tausende von Dateien und mehrere Millionen Tokens — weit mehr, als jedes Sprachmodell auf einmal verarbeiten kann. Factory.ai, ein auf Agent-Infrastruktur spezialisiertes Unternehmen, beschreibt die Konsequenz: Wenn Entwicklern wichtige Kontextinformationen fehlen — historische Entscheidungen, Teamkonventionen, organisatorische Zwänge — verschlechtert sich die Qualität ihrer Arbeit dramatisch. Bei Agents gilt dasselbe. Der Unterschied: Menschen fragen nach, wenn sie unsicher sind. Agents tun das zu selten und bemerken zu spät, dass ihnen etwas Wesentliches fehlt.
Das zeigt sich am deutlichsten bei Legacy-Code, der nie dokumentiert wurde. Systeme, die über Jahrzehnte gewachsen sind und deren Geschäftslogik ausschließlich im impliziten Wissen der Fachabteilung lebt, sind für Agents weitgehend undurchdringlich. Der generierte Code mag syntaktisch korrekt sein, die Tests bestehen — und trotzdem nicht das tun, was das Unternehmen wirklich braucht, weil niemand je aufgeschrieben hat, was das Unternehmen wirklich braucht.
Sicherheitskritische Bereiche sind aus einem anderen Grund problematisch. Kryptographie, Authentifizierungsflows, Timing-Attacken: Hier genügt Mustererkennung nicht. Sicherheit erfordert adversariales Denken — vorauszusehen, was ein Angreifer tut, nicht was die meisten Entwickler tun. Ein Modell, das auf das statistisch Wahrscheinlichste optimiert, ist für Szenarien strukturell ungeeignet, die gerade wegen ihrer Seltenheit gefährlich sind.
Und Architekturentscheidungen — welche Bounded Contexts wie geschnitten werden, welcher Service welche Verantwortung trägt, wie das System bei dreifachem Traffic skaliert — haben keine saubere optimierbare Antwort. Sie hängen von Faktoren ab, die außerhalb jedes Coderepos liegen.
Was die Pipeline leistet
Das eigentliche Problem beim Einsatz von Coding Agents in Unternehmen ist selten die Leistung der Agents selbst — es ist die Aufgabenstruktur, in die sie eingebettet werden.
Gibt man einem Agent eine klar definierte Migrationsaufgabe, entsteht der Zehnfaktor. Setzt man ihn auf eine Architekturentscheidung ohne eindeutige Antwort an, bekommt man klang konfidentes Rauschen. Der Unterschied liegt nicht im Agent — er liegt im Design der Aufgabe.
Die entscheidende Frage ist deshalb nicht: „Kann ein Agent das lösen?" Sondern: „Haben wir diese Aufgabe so strukturiert, dass ein Agent sie zuverlässig lösen kann?" Das erfordert eine andere Perspektive auf Softwareprojekte: Welche Teile sind wirklich mechanisch? Welche benötigen implizites Domänenwissen? Wo verläuft die Grenze? Das ist eine Architekturentscheidung — über die Arbeitsstruktur, nicht über den Code.
Genau das ist der Kern dessen, was nopex aufbaut: keine Schlagwortstrategie, sondern eine klare Pipeline, die agent-geeignete und mensch-geeignete Aufgaben systematisch trennt. Migrations- und Boilerplate-Arbeit, Testgenerierung, API-Endpoints, Dokumentation — das ist das Terrain des Agents. Architekturentscheidungen, Sicherheitsreviews, Domänenlogik mit implizitem Geschäftswissen, strategische Technikentscheidungen — das bleibt beim Menschen.
Diese Trennung klingt selbstverständlich. In der Praxis ist sie es selten. Die meisten Teams setzen Agents entweder zu zaghaft ein und schöpfen den möglichen Geschwindigkeitsgewinn nicht aus — oder zu unstrukturiert und wundern sich, warum die Ergebnisse unzuverlässig sind. Eine durchdachte Pipeline, die Aufgaben konsequent nach ihrer Eignung sortiert, ist der Unterschied zwischen einem produktiven Werkzeug und einem teuren Experiment.
Agent-Einsatz, der wirklich funktioniert, ist kein Zufall. Er ist Architektur.
