Senken AI Coding Agents wirklich die Entwicklungskosten? Code-Abschlussquote, manuelle Nacharbeit und tatsächliche Kosten pro Aufgabe

Ergebnis vorweg: Nur abgenommene Aufgaben zählen

Eine randomisierte Untersuchung mit erfahrenen Open-Source-Entwicklern berichtete, dass die untersuchten AI-Werkzeuge die Bearbeitung der ausgewählten Aufgaben im Mittel um 19 % verlangsamten; der Befund gilt für dieses Studiendesign und diese Aufgaben, nicht pauschal für jedes Team oder jeden Coding Agent (METR-Studie). Für die Entwicklungskosten eines AI Coding Agents folgt daraus eine klare Entscheidung: Ein Agent senkt die Kosten nur, wenn die eingesparte Engineering-Zeit und vermiedene Routinearbeit die Modell- und Umgebungskosten sowie Prüfung und Nacharbeit übersteigen. Vergleichen Sie deshalb gleichartige Aufgaben und rechnen Sie die Vollkosten je abgenommener Aufgabe aus. Codezeilen, ein erzeugter Pull Request oder eine überzeugende Demo belegen noch keinen wirtschaftlichen Nutzen.

Dieser Leitfaden richtet sich an Entwicklungsverantwortliche, die einen Coding Agent anhand von Vergleichsaufgaben bewerten möchten.
Er hilft Codeprüfenden, Korrekturen, Fehler und Prüfzeit einheitlich zu erfassen.
Technische Gründer erhalten eine Kostenlogik, die Modellnutzung, Laufzeitumgebung und Arbeitszeit gemeinsam betrachtet.

Zuerst festlegen, wann eine Aufgabe wirklich abgeschlossen ist

„Erledigt“ braucht eine überprüfbare Definition, bevor das Team Agent-Ergebnisse mit manueller Arbeit vergleicht. Eine geeignete Abnahmegrenze beschreibt das verlangte Verhalten, die betroffenen Komponenten, relevante Tests und erforderliche Sicherheits- oder Datenschutzprüfungen. Sie muss für den Agentenlauf und die Vergleichsarbeit identisch gelten.

Drei Ereignisse sollten getrennt erfasst werden:

• Aufgabe bearbeitet: Der Agent oder ein Entwickler hat eine Änderung vorgeschlagen.
• Code angenommen: Die Änderung wurde nach Prüfung in den gemeinsamen Entwicklungsstand übernommen.
• Wert geliefert: Die Änderung erfüllt die Abnahmekriterien und funktioniert im vorgesehenen Produktkontext.

Diese Begriffe sind nicht austauschbar. Eine Änderung kann formal angenommen worden sein und dennoch einen Fehler enthalten, der erst später auffällt. Umgekehrt kann ein Agent zwar keinen direkt übernehmbaren Code erzeugen, aber durch eine brauchbare Diagnose einen Teil der Recherche abnehmen. Für die Kostenrechnung zählt am Ende die vorher definierte Abnahme, nicht die Menge des generierten Codes.

Hinweis: Werden Agent und Vergleichsgruppe nach unterschiedlichen Maßstäben bewertet, misst das Team nicht Produktivität, sondern unterschiedliche Abnahmepraktiken. Halten Sie Kriterien und Testumgebung vor dem Start des Versuchs fest.

Dokumentieren Sie außerdem, welche Schritte im Versuch tatsächlich dem Agenten zugerechnet werden: Prompt-Erstellung, Einrichten des Kontexts, wiederholte Werkzeugaufrufe, lokale Testläufe und Übergabe an die Codeprüfung. Werden diese Tätigkeiten aus der Zeitmessung ausgeschlossen, erscheint die Agentenvariante künstlich günstiger.

Kleine, klar abgegrenzte Aufgaben als erste Vergleichsbasis

Für einen ersten Versuch eignen sich wiederkehrende Aufgaben mit sichtbaren Akzeptanzkriterien und begrenztem Änderungsumfang. Beispiele sind eine klar beschriebene Validierungsregel, eine kleine Anpassung an einer internen Schnittstelle oder ein Test für bereits verstandenes Verhalten. Das sind keine Erfolgsgarantien: Entscheidend ist, dass das Team dieselbe Art von Aufgabe mehrfach nach einem stabilen Verfahren bearbeiten kann.

Die folgende Tabelle hilft dabei, eine passende Vergleichsgruppe auszuwählen. „Ohne Agent“ bezeichnet den bestehenden Arbeitsablauf, nicht automatisch eine ideale oder fehlerfreie Referenz.

Option	Geeignet, wenn …	Zu erfassende Zeiten	Zentrales Risiko
Bestehender Ablauf ohne Agent	ähnliche Aufgaben und ein eingespieltes Team verfügbar sind	Umsetzung, Selbstprüfung, Prüfung und Korrekturen	Unterschiede bei Erfahrung oder Aufgabenkomplexität verzerren den Vergleich
Agent mit menschlicher Prüfung	Anforderungen klar und Änderungen lokal begrenzt sind	Kontextaufbau, Agentenlauf, Fehlversuche, Prüfung und Nacharbeit	Ein scheinbar schneller Erstentwurf kann hohe Korrekturkosten verdecken
Kombination aus Agent und Entwickler	der Agent Recherche oder Teilaufgaben übernimmt, die Integration aber menschlich bleibt	Arbeitsanteile beider Seiten, Übergaben und zusätzliche Tests	Doppelarbeit, wenn beide Seiten dieselbe Lösung unabhängig erarbeiten

Für jeden Versuch sollte das Team Eingabe und Kontext, gewünschtes Ergebnis, tatsächlich abgenommenes Ergebnis, Wartezeit sowie aktive Arbeitszeit festhalten. Wartezeit ist nicht automatisch eingesparte Arbeitszeit: Ein Entwickler kann während eines Agentenlaufs parallel sinnvoll arbeiten, muss aber gegebenenfalls auf Ergebnisse warten oder anschließend den Kontext erneut aufnehmen. Halten Sie diese Fälle getrennt, statt jede Laufzeit pauschal als Produktivitätsgewinn zu verbuchen.

Auch die Zahl erfolgreicher Läufe braucht eine präzise Definition. Die Coding-Agent-Aufgabenabschlussquote sollte ausweisen, welcher Anteil der gestarteten Aufgaben die vereinbarte Abnahme erreicht. Ergänzend lohnt sich die Quote angenommener Codeänderungen; sie beantwortet eine andere Frage. Ein Benchmark kann etwa festgelegte Softwareaufgaben und deren Prüfkriterien untersuchen, aber seine Resultate lassen sich nicht ohne Weiteres auf interne Repositories, andere Agentenversionen oder abweichende Abnahmeprozesse übertragen. Die Beschreibung von SWE-bench Verified ist hilfreich, um zu sehen, warum Aufgabenbestand und Verifikation Teil der Interpretation sind.

Praktisch sollte ein Team nicht nur erfolgreiche Läufe sammeln. Abgebrochene Versuche, nicht reproduzierbare Änderungen, unpassende Lösungen und Aufgaben, die ein Mensch übernehmen musste, gehören in denselben Datensatz. Andernfalls wird die Erfolgsquote durch das Weglassen ungünstiger Fälle geschönt.

Bei regulärer Entwicklung die Nacharbeit sichtbar machen

Bei einer normalen Funktionserweiterung entstehen Kosten nicht allein beim Schreiben der Änderung. Das Team muss Anforderungen klären, vorhandenes Verhalten nachvollziehen, Tests ausführen und den Code prüfen. Ein Agent kann einen Teil der Implementierung übernehmen; die zusätzliche oder verbleibende Arbeit bleibt dennoch Aufwand. Deshalb sollte die manuelle Nacharbeit bei KI-Programmierung nicht als pauschaler Zuschlag geschätzt werden, sondern aus den tatsächlich protokollierten Arbeitsschritten hervorgehen.

Erfassen Sie je Aufgabe mindestens:

• aktive Zeit für Kontextaufbau, Anweisungen und notwendige Korrekturen am Agentenlauf;
• Zeit für Testausführung, Fehlerdiagnose und erneute Implementierungsversuche;
• Prüfzeit für Verständlichkeit, Architektur, Sicherheit und unerwünschte Nebenwirkungen;
• Zahl und Art der Änderungsrunden, ohne jede Runde automatisch als gleich teuer zu behandeln;
• spätere Fehler und Wartungsaufwand, sofern ein Zusammenhang mit der Änderung nachvollziehbar dokumentiert ist.

Unterscheiden Sie dabei einmalige Reparatur und laufende Wartung. Eine fehlerhafte Implementierung, die vor der Abnahme korrigiert wird, gehört in die Nacharbeitskosten dieser Aufgabe. Ein späterer Fehler kann der Aufgabe ebenfalls zugerechnet werden, wenn das Team den Zusammenhang belegen kann. Werden dagegen alle späteren Störungen pauschal dem Agenten zugeschrieben, wird der Vergleich verzerrt; werden sie grundsätzlich ausgeschlossen, bleibt ein Teil der Qualitätssicherung unsichtbar.

Kostenbestandteil	Erfassung im Agentenlauf	Vergleich im bestehenden Ablauf
Modell- und Werkzeugnutzung	tatsächlich abgerechnete Nutzung für die Aufgabe	keine Agentengebühr, sofern keine entsprechende Nutzung anfällt
Entwicklungsumgebung	zurechenbare Laufzeit-, Rechen- und Speicherressourcen	bestehende lokale oder bereitgestellte Umgebung nach gleicher Methode
Menschliche Umsetzung	Einrichten, Kontextarbeit, Eingriffe und Integration	Implementierung und Selbstprüfung
Review und Tests	Prüfzeit, Testläufe, Fehlersuche und notwendige Wiederholungen	dieselben Prüfschritte nach identischer Abnahme
Nacharbeit und spätere Korrekturen	dokumentierte Korrekturen vor und nach der Abnahme	dokumentierte Korrekturen auf vergleichbarer Basis

Für die Geldbewertung von Arbeitszeit verwenden Sie einen intern festgelegten Vollkostensatz, der zur betriebswirtschaftlichen Fragestellung passt. Ob das Unternehmen Gehalt, Arbeitgeberkosten oder einen umfassenderen internen Verrechnungssatz zugrunde legt, muss konsistent entschieden und dokumentiert werden. Eine Scheingenauigkeit entsteht, wenn unterschiedliche Personalkostenmodelle oder ungleiche Prüfschritte in dieselbe Rechnung eingehen.

Ein weiterer praktischer Punkt ist die Freigabe. Bei geschützten Entwicklungszweigen können zusätzliche Reviews und Statusprüfungen erforderlich sein; die Dokumentation zu geschützten Zweigen und erforderlichen Reviews beschreibt solche Kontrollmechanismen. Diese Regeln sind nicht bloß Formalität: Wenn ein Team sie für Agentenänderungen lockert, um Zeit zu sparen, muss es die zusätzliche Risiko- und Sicherheitsbewertung ausdrücklich berücksichtigen. Gerade bei vertraulichem Quellcode sind Datenzugriff, Protokollierung und Vorgaben der DSGVO vor einem breiteren Einsatz zu prüfen.

Komplexe Codebasen gesondert bewerten

In einer großen oder wenig dokumentierten Codebasis kann die Aufgabe bereits beim Aufbau des nötigen Kontexts teuer werden. Ein Agent kann eine relevante Abhängigkeit übersehen, mit unvollständiger Umgebung arbeiten oder bei einer langen Abfolge von Arbeitsschritten an einer Zwischenbedingung scheitern. Auch Werkzeugaufrufe können zusätzliche Überwachung und Eingriffe verlangen. Das sind Risiken, die ein Team für seine eigene Umgebung prüfen muss, keine universellen Eigenschaften jedes Agents.

Hier sind Aufgaben mit klaren Grenzen besonders wichtig. Wird ein mehrstufiger Umbau als ein einziger Versuch protokolliert, bleibt schwer erkennbar, ob Kosten durch Kontextsuche, Ausführung, Integration oder zusätzliche Prüfung entstanden sind. Zerlegen Sie die Aufgabe für die Analyse in beobachtbare Teilabschnitte, ohne die offizielle Abnahmegrenze nachträglich zu ändern.

Szenario	Möglicher Nutzen	Mögliche Zusatzkosten	Entscheidungskriterium
Begrenzte Routineänderung	weniger manuelle Wiederholungsarbeit	Review, Testkorrekturen und Kontextaufbau	Nettozeit je abgenommener Aufgabe vergleichen
Reguläre Funktionserweiterung	Unterstützung bei Teilimplementierung und Tests	Integrationsarbeit und zusätzliche Prüfschleifen	Nacharbeit und Fehlerquote zusammen mit Zeit bewerten
Mehrdeutiger Umbau in komplexer Codebasis	Unterstützung bei Recherche oder einzelnen Teilaufgaben	längere Kontextaufnahme, Unterbrechungen, Sicherheitsprüfung	bei unklarer Abnahme zuerst Eingrenzung verbessern, nicht den Agenteneinsatz ausweiten

Erfahrungshinweis: Wenn ein Agent bei komplexen Aufgaben mehrdeutige Anforderungen offenlässt, sollte das Team zuerst die Spezifikation und die benötigten Zugriffsrechte prüfen. Ein weiterer Lauf kann sonst zusätzliche Nutzungskosten erzeugen, ohne die Abnahme näherzubringen.

Bei Aufgaben mit Datenschutz- oder Sicherheitsbezug sollte außerdem nachvollziehbar sein, welche Repository-Inhalte an welches Modell oder Werkzeug übergeben werden und welche Kontrollen gelten. Solche Aufwände sind Teil der Einsatzbedingungen. Werden sie lediglich als allgemeine Teamarbeit verbucht, fehlt der Vergleich zwischen Agenten- und Nicht-Agentenprozess.

Vollkosten je abgenommener Aufgabe einheitlich berechnen

Die Rechnung sollte Agentenvariante und Vergleichsablauf auf dieselbe Abnahmegrenze beziehen. Eine einfache Form lautet:

Vollkosten je abgenommener Aufgabe = zurechenbare Modell- und Werkzeugkosten + Umgebungskosten + Personalkosten für Kontext, Umsetzung, Review, Tests und Nacharbeit + nachvollziehbar zurechenbare spätere Korrekturen.

Für den bestehenden Ablauf werden die gleichen Kategorien verwendet, soweit sie dort anfallen. Anschließend werden Kosten pro abgenommener Aufgabe und die dafür aufgewendete aktive Arbeitszeit gegenübergestellt. Die Formulierung „pro abgenommene Aufgabe“ verhindert, dass fehlgeschlagene oder abgebrochene Läufe aus dem Nenner verschwinden. Bei unterschiedlich großen Aufgaben sollten Ergebnisse zusätzlich nach Aufgabentyp gruppiert werden, statt einen einzelnen Mittelwert für alles zu veröffentlichen.

Modell- und Werkzeugkosten sind aus den tatsächlichen Verbrauchsdaten zu entnehmen. Die offizielle Preisübersicht für Modell-API-Aufrufe und eine weitere offizielle Preisübersicht für Modellnutzung zeigen, warum das Team für seine konkrete Auswahl jeweils aktuelle Tarife und Abrechnungseinheiten heranziehen muss. Für zusätzlich verwendete Funktionen oder Verbrauchskontingente kann auch die Dokumentation zur Abrechnung von Coding-Assistenten relevant sein. Aus allgemeinen Preisangaben allein lässt sich keine verlässliche Aufgabenrechnung ableiten: maßgeblich sind die eigene Nutzung, der konkrete Tarif und die tatsächlich zugeordneten Arbeitszeiten.

Vor dem ersten Versuch sollte die verantwortliche Person festlegen, wie gemeinsame Infrastrukturkosten zugeordnet werden. Ist eine Umgebung ohnehin vorhanden, kann das Team nur den zusätzlichen, durch den Agenten verursachten Aufwand ansetzen. Wird für den Versuch eine neue Umgebung bereitgestellt, gehören deren zurechenbare Kosten hinein. Eine Mischrechnung, die bestehende Infrastruktur beim Agenten als kostenlos und beim Vergleich als Vollkosten verbucht, macht die Entscheidung unbrauchbar.

Führen Sie den Vergleich in einer Tabelle oder einem Versuchsdokument mit Aufgabenkennung, Abnahmestatus, Arbeitszeiten, Nutzungskosten, Umgebung und späteren Korrekturen. So bleiben Rechnung und Ursprungsdaten prüfbar. Aussagen zu eingesparten Kosten oder schnellerer Lieferung sollten erst veröffentlicht werden, wenn diese Daten für den betrachteten Aufgabentyp vorliegen. Allgemeine Studienwerte sind keine Prognose für das eigene Team.

Den Versuch vom kleinen Test zum belastbaren Betrieb führen

Ein kontrollierter Ablauf macht die Ergebnisse nachvollziehbar, ohne eine bestimmte Wirkung vorwegzunehmen:

1. Aufgabentyp auswählen: Beginnen Sie mit wiederkehrenden Aufgaben, deren Ergebnis unabhängig überprüfbar ist. Vermischen Sie keine Routineänderungen und Architekturarbeiten in einer einzigen Auswertung.
2. Abnahme dokumentieren: Halten Sie vor dem Lauf Verhalten, Tests, Qualitätsanforderungen und Sicherheitsbedingungen fest. Ändern Sie Kriterien nicht nach Kenntnis des Ergebnisses.
3. Vergleichsablauf festlegen: Nutzen Sie möglichst ähnliche Aufgaben aus dem bestehenden Prozess und erfassen Sie auch dessen Review- und Nacharbeitszeit.
4. Aufwand vollständig protokollieren: Erfassen Sie aktive Arbeitszeit, Wartezeit, Agentenläufe, Nutzung, Umgebung, Prüfungen und Korrekturen getrennt.
5. Ergebnisse nach Abnahme einordnen: Stellen Sie erfolgreiche, abgelehnte und abgebrochene Versuche dar. Berechnen Sie Kosten auf Basis der abgenommenen Arbeit und legen Sie offen, welche Fälle eingeschlossen sind.
6. Qualitätsgrenzen prüfen: Kontrollieren Sie spätere Fehler und Sicherheitsbefunde über einen für den Arbeitsablauf geeigneten Zeitraum. Fehlt diese Beobachtung, kennzeichnen Sie die Kostenrechnung als vorläufig.
7. Nur passende Aufgabentypen erweitern: Weiten Sie den Einsatz erst aus, wenn wiederholte vergleichbare Daten den Nettoaufwand und die Qualität für diesen Typ stützen.

Als internes Ergebnis genügt nicht die Aussage „der Agent spart Zeit“. Festzuhalten sind Aufgabenkategorie, Abnahmeregel, Vergleichsbasis, betrachtete Kosten, ausgeschlossene Faktoren und Grenzen der Aussage. So kann ein anderes Teammitglied nachvollziehen, ob das Ergebnis auf den eigenen Arbeitsablauf übertragbar ist.

Eine Ausbauentscheidung an beobachtbare Bedingungen knüpfen

Die Checkliste sollte vor dem Ausbau beantwortet werden:

• [ ] Sind Agentenaufgaben und Vergleichsaufgaben nach derselben Abnahmegrenze bewertet?
• [ ] Sind gescheiterte, abgebrochene und verworfene Versuche berücksichtigt?
• [ ] Sind Prüfung, Testläufe, Korrekturen und spätere Fehler nachvollziehbar erfasst?
• [ ] Beruht die Kostenrechnung auf tatsächlichen Nutzungskosten und einem konsistenten internen Arbeitskostensatz?
• [ ] Sind Datenschutz, Repository-Zugriff und erforderliche Freigaben geklärt?
• [ ] Ist der beobachtete Vorteil für einen klar abgegrenzten Aufgabentyp wiederholbar?

Sind die Antworten belastbar und liegen die Vollkosten je abgenommener Aufgabe unter dem vergleichbaren bisherigen Ablauf, kann ein begrenzter Ausbau für genau diesen Aufgabentyp sinnvoll sein. Ist der Abstand klein, die Aufgabenbasis ungleich oder die spätere Qualität noch ungeprüft, sollte das Team den Versuch fortführen, statt eine allgemeine Einsparung zu behaupten. Sind Review, Nacharbeit oder Umgebungskosten höher als die eingesparte Arbeitszeit, senkt der Agent die Entwicklungskosten in diesem Einsatz nicht.

Zur Einordnung von Umgebungsausgaben und parallelen Agentenläufen kann die Anleitung zu Kosten und Ressourcen bei mehreren gleichzeitig laufenden AI Agents die Budgetseite ergänzen. Für die Wahl einer Entwicklungsumgebung ist auch die Übersicht zum Mieten eines Mac mini relevant, sofern ein Mac in den Arbeitsablauf passt.

Der Wechsel von einem Agentenversuch zu einer breiteren Nutzung ist nicht automatisch günstiger als der bestehende Prozess. Eine reine lokale Lösung bindet eigenes Gerät und Wartungszeit; ein allgemeines Cloud-System kann zusätzliche Kosten für Laufzeit, Zugriffssteuerung und sichere Datenverarbeitung verursachen; eine ausgelastete bestehende Umgebung lässt sich nicht beliebig parallelisieren. Wenn ein Team dagegen zeitlich begrenzte Entwicklungs- oder Testumgebungen benötigt, kann das Mieten eines Mac über Zutcloud eine Alternative zum sofortigen Hardwarekauf sein. Für dauerhaft hohe Auslastung oder spezielle physische Schnittstellen kann ein eigener Rechner die passendere Wahl bleiben. Prüfen Sie für einen befristeten Versuch die Mac-mini-Mietoption von Zutcloud gemeinsam mit der obigen Vollkostenrechnung, statt Miet- und Kaufkosten isoliert zu vergleichen.