KI-News · Einführung

Was bringt ein KI-Coding-Assistent?
Ein Business Case ohne Wunschzahlen.

31. August 2026 · Lesezeit ca. 12 Minuten

Wer den Nutzen eines Coding-Assistenten mit „30 Prozent schneller“ ansetzt, hat noch keinen Business Case. Er hat eine fremde Zahl in eine Tabelle kopiert. Ein brauchbarer Pilot misst Zeit bis zur fertigen Änderung, Nacharbeit und Lieferfähigkeit am eigenen Backlog.

Die Frage aus der Geschäftsführung klingt vernünftig: Was bekommen wir für Lizenzen, Einführung und Schulung zurück? Eine Antwort auf Basis veröffentlichter Studien ist verlockend. Leider messen die Studien sehr verschiedene Dinge. Eine kurze Laboraufgabe ist etwas anderes als eine Änderung in einem Repository, das seit zehn Jahren gewachsen ist. Mehr Pull Requests sind etwas anderes als kürzere Durchlaufzeit. Akzeptierte Codezeilen sagen noch nichts über spätere Nacharbeit.

Drei Studien, drei Antworten

Im Experiment von Peng und Kollegen erledigte die Copilot-Gruppe eine abgegrenzte JavaScript-Aufgabe 55,8 Prozent schneller. Die Aufgabe war kurz, allein zu bearbeiten und automatisch prüfbar. Das ist ein sauberer Test für diesen Fall, aber keine Abbildung eines normalen Sprints.

Cui und Kollegen bündelten drei randomisierte Feldexperimente bei Microsoft, Accenture und einem Fortune-100-Unternehmen. Insgesamt nahmen 4.867 Entwickler teil. Mit Zugriff auf den Assistenten wurden 26,08 Prozent mehr Aufgaben abgeschlossen. Der Messwert ist näher am Unternehmensalltag, lässt jedoch offen, wie groß die Aufgaben waren und wie sich langfristige Qualität und Wartung entwickelten.

METR wählte einen anderen Aufbau: 16 erfahrene Open-Source-Entwickler bearbeiteten 246 reale Issues in ihnen seit Jahren vertrauten Repositories. Mit erlaubter KI-Nutzung brauchten sie im Mittel 19 Prozent länger. Vorher hatten sie 24 Prozent Zeitersparnis erwartet, nachher glaubten sie noch immer, 20 Prozent gespart zu haben. Die Stichprobe ist klein und speziell. Gerade deshalb ist der Befund nützlich: Das eigene Gefühl taugt nicht als Messung.

Keine der drei Zahlen ist die richtige Zahl für Ihr Team. Zusammen sagen sie etwas Konkreteres: Aufgabe, Erfahrung, Repository und Messmethode verändern das Ergebnis stark.

Die Rechnung beginnt mit den Vollkosten

Der Lizenzpreis ist gewöhnlich der kleinste und sichtbarste Posten. Für einen Pilot gehören mindestens diese Kosten in die Rechnung:

• Lizenzen und nutzungsabhängige Gebühren für Modelle, Agentenläufe und zusätzliche Infrastruktur.
• Einrichtung: Richtlinien, Berechtigungen, Repository-Anweisungen, Hooks und freigegebene Integrationen.
• Einarbeitung: Schulung sowie Arbeitszeit für Übungen und Rückfragen.
• Nutzung: Zeit für Prompts, Warten, Prüfen und Korrigieren.
• Nacharbeit: zusätzliche Reviews, zurückgewiesene Änderungen, Fehlerbehebung und spätere Wartung.

Ein Rechenbeispiel für acht Entwickler

Angenommen, ein vierwöchiger Pilot kostet 40 € je Lizenz und Monat. Hinzu kommen ein Schulungstag für 1.900 € und acht interne Stunden für Einrichtung und Abstimmung. Die kalkulatorische Entwicklerstunde setzen wir mit 90 € an.

Der Pilot muss somit rund 33 Stunden nutzbare Arbeitszeit einsparen, etwa 4,1 Stunden je Entwickler. Diese Rechnung enthält noch keinen zusätzlichen Review-Aufwand und keine späteren Fehlerkosten. Beides muss aus den Pilotdaten ergänzt werden. Für eine Fortführung im zweiten Monat fällt die einmalige Einführung aus der Rechnung; dann liegt die Gewinnschwelle deutlich niedriger.

Was der Pilot messen sollte

Eine einzige Kennzahl wird dem Arbeitsablauf nicht gerecht. Das SPACE-Framework ordnet Entwicklerproduktivität in fünf Bereiche ein: Zufriedenheit, Leistung, Aktivität, Zusammenarbeit sowie Effizienz und Arbeitsfluss. Für einen kleinen Pilot reicht eine Auswahl aus drei Ebenen.

1. Zeit bis zur fertigen Änderung

• aktive Bearbeitungszeit vom Start bis zum prüfbaren Pull Request
• Wartezeit bis zum Review und Zeit für Korrekturschleifen
• gesamte Durchlaufzeit bis zum Merge oder Deployment

Die DORA-Metriken ergänzen die einzelne Aufgabe um Lieferfähigkeit: Durchlaufzeit von Änderungen, Deployment-Häufigkeit, Fehlerrate, Nacharbeitsrate und Erholungszeit nach fehlgeschlagenen Deployments. DORA warnt selbst davor, eine Metrik zum Ziel zu machen oder Teams über Rohwerte miteinander zu vergleichen.

2. Qualität und Nacharbeit

• Anteil der Änderungen, die CI und fachliche Abnahme beim ersten Versuch bestehen
• Review-Kommentare und Korrekturschleifen, nach Schwere statt nur nach Anzahl
• zurückgerollte Änderungen, Produktionsfehler und Nacharbeit innerhalb von 14 oder 30 Tagen
• Sicherheitsbefunde und Verstöße gegen Repository-Konventionen

Das gemeinsame Orientierungspapier von BSI und ANSSI nennt unter anderem unsicheren oder funktionsuntüchtigen Code, Abhängigkeiten und den Umgang mit vertraulichen Daten als Risiken. Der Pilot braucht deshalb dieselben Prüfungen wie der übrige Code. Eine hohe Akzeptanzrate der Vorschläge ersetzt sie nicht.

3. Arbeitsweise und Belastung

• Für welche Aufgabentypen wurde der Assistent genutzt oder bewusst ausgeschaltet?
• Wie viel Zeit ging für Prompting, Warten, Lesen und Korrigieren drauf?
• Hat sich die kognitive Belastung verändert?
• Fielen Kontextwechsel und blockierte Arbeit seltener an?

Diese Angaben sind subjektiv, aber nicht wertlos. Sie erklären Messwerte. Wenn eine Aufgabe schneller fertig wird, Entwickler den erzeugten Code aber kaum noch überblicken, hat die Zeitmessung allein ein Problem übersehen.

Ein vierwöchiger Pilot

1. Woche 0: Ausgangslage sichern. Wählen Sie zwei bis vier wiederkehrende Aufgabentypen. Erfassen Sie für vergleichbare erledigte Aufgaben Zeit, Review, Nacharbeit und Ergebnisqualität. Definieren Sie erlaubte Daten, Werkzeuge und Repositories.
2. Woche 1: Team arbeitsfähig machen. Schulen Sie Bedienung, Berechtigungen und Prüfung. Halten Sie gemeinsame Repository-Anweisungen fest. Das Team dokumentiert pro Aufgabe, ob und wofür der Assistent eingesetzt wurde.
3. Woche 2 und 3: vergleichbare Arbeit messen. Teilen Sie ähnliche Aufgaben nach Möglichkeit zwischen Arbeit mit und ohne Assistent auf. Wechseln Sie die Zuordnung, damit nicht nur einzelne Personen oder besonders einfache Tickets in einer Gruppe landen.
4. Woche 4: rechnen und entscheiden. Vergleichen Sie Aufgabentypen getrennt. Rechnen Sie zusätzliche Prüf- und Nacharbeitszeit ein. Dokumentieren Sie außerdem Fälle, in denen der Assistent ausgeschaltet wurde.

Ein perfektes randomisiertes Experiment ist im Alltag selten möglich. Ein Vorher-nachher-Vergleich ohne jede Kontrolle ist trotzdem zu schwach: Sprintinhalt, Erfahrung und Zeitdruck verändern das Ergebnis. Schon eine wechselnde Zuordnung ähnlicher Aufgaben ist besser als eine Umfrage am Monatsende.

Den Ausbau vor dem Start festlegen

Ein Pilot ohne vorher vereinbarte Schwellen endet oft mit einer Diskussion über einzelne Erfolgsgeschichten. Schreiben Sie deshalb vorab auf, welcher nächste Ausbauschritt zu welchem Ergebnis gehört.

Die Schwellen müssen zum Unternehmen passen. Ein Team mit hoher regulatorischer Last bewertet einen zusätzlichen Sicherheitsbefund anders als ein internes Prototyping-Team. Auch die Aufgabentypen bleiben getrennt: Testfälle brauchen oft einen wiederverwendbaren Skill, Änderungen an einer alten Kernkomponente eher gute Repository-Regeln und Zugriff auf die vorhandene Dokumentation.

Welche Zahl ich vor dem Pilot ansetze

Für die Planung rechne ich bei einem Entwicklungsteam mit 8 bis 15 Prozent weniger Zeit auf geeignete Aufgaben. Das ist keine Studienkennzahl und keine Zusage. Es ist mein Arbeitskorridor für einen eingerichteten Agentenbetrieb, in dem Schulung, Repository-Regeln, Hooks, Skills und benötigte MCP-Verbindungen zusammenkommen.

Die Bandbreite gilt nur für die Arbeitszeit, bei der der Assistent sinnvoll eingesetzt werden kann. Abstimmungen, fachliche Entscheidungen, Architekturarbeit und viele Reviews verschwinden dadurch nicht. Bei klar abgegrenzten Änderungen, Tests, Dokumentation, Migrationen und wiederkehrender Fehlersuche ist der Anteil gewöhnlich höher als bei neuen oder schlecht verstandenen Komponenten.

Was das bei acht Entwicklern bedeutet

Nehmen wir an, jeder der acht Entwickler verbringt pro Woche 20 Stunden mit Aufgaben, für die der Assistent infrage kommt. Über vier Wochen sind das 640 Stunden. Mein Planungskorridor ergibt folgende Erwartung:

Im mittleren Szenario spielt das Team die Kosten für Schulung, Einrichtung und den ersten Lizenzmonat innerhalb des ersten Monats ein. Ab dem zweiten Monat bleiben in diesem Beispiel vor allem Lizenzen, Pflege und die Zeit für neue Regeln übrig. Bei gleichem Arbeitsvolumen läge der monatliche Bruttowert weiter bei rund 6.900 €.

Was zehn gemeinsame Tage ändern

Ein Schulungstag bringt das Team auf einen gemeinsamen Stand und liefert die ersten Regeln. Für Hooks, Skills und MCP-Verbindungen bleibt dabei wenig Umsetzungszeit. Ein Programm über zehn Tage kann diese Arbeit bis in den Betrieb begleiten.

Zehn Tage Unterricht mit dem ganzen Team wären teuer. Acht Entwickler wären bei 90 Euro pro Stunde insgesamt 640 Stunden gebunden, allein diese Zeit hätte einen kalkulatorischen Wert von 57.600 €. Sinnvoller ist ein Programm, bei dem das ganze Team an zwei Tagen zusammenarbeitet. An den übrigen Tagen entstehen mit einzelnen Entwicklern oder eigenständig die Bausteine für das Repository.

Die Rechnung für das Zehn-Tage-Programm

Für ein solches Programm setze ich im Beispiel 16.900 € Projektpreis an. Zwei gemeinsame Teamtage binden bei acht Entwicklern weitere 128 Stunden beziehungsweise 11.520 € interne Arbeitszeit. Zusammen mit 320 Euro für den ersten Lizenzmonat liegt die anfängliche Investition bei 28.740 €. Die punktuelle Mitarbeit einzelner Entwickler an den Umsetzungstagen müsste das Unternehmen noch ergänzen.

Der einzelne Schulungstag zielt auf den Einstieg. Das Zehn-Tage-Programm zielt auf eine Arbeitsweise, die im Repository bleibt: gemeinsame Regeln, automatische Prüfungen, wiederverwendbare Skills und Zugriff auf die Systeme, die das Team täglich braucht. Der erwartete Zeitgewinn kommt aus diesem Zusammenspiel.

Hooks, Skills, MCP und Repository-Regeln addieren sich dabei nicht zu vier getrennten Prozentwerten. Sie greifen ineinander. Der Hook findet einen Fehler früh, die Repository-Regel verhindert ihn beim nächsten Auftrag, und ein Skill macht denselben Ablauf wiederholbar. Gemessen wird deshalb der gemeinsame Effekt auf fertige, geprüfte Arbeit.