CostmarkCostmark

Insights

KI-Coding im Softwareeinkauf: Das Potenzial ist da, der Hebel fehlt

Lennart Stabenow

KI-gestützte Entwicklung ist in der Breite angekommen — bei den Lieferanten. Auf der Einkaufsseite fehlt meist die Grundlage, um das Potenzial zu benennen. Was die Studienlage hergibt, warum sie je Branche weit auseinanderliegt und an welcher Stelle eine eigene Spezifikation den Effekt sogar verhindert.

Macht KI-gestützte Entwicklung wirklich schneller?

Die Verbreitung ist keine offene Frage mehr. Der DORA-Report 2025 von Google Cloud kommt bei knapp 5.000 befragten Fachleuten auf 90 Prozent, die KI in ihren Arbeitsalltag eingebunden haben — im Median zwei Stunden täglich. Der Stack Overflow Developer Survey 2025 zählt 84 Prozent, die KI-Werkzeuge nutzen oder das planen, 51 Prozent der Berufsentwickler täglich. Ihr Lieferant arbeitet damit. Die Frage ist nicht, ob.

Wie groß der Effekt ausfällt, ist dagegen offen — und zwar auffällig offen. Drei kontrollierte Studien, drei Ergebnisse:

  • 55,8 Prozent schneller. Im Feldversuch von GitHub und Microsoft (Peng et al., 2023) bauten 95 Freelancer denselben HTTP-Server in JavaScript. Die Gruppe mit Copilot brauchte 1:11 Stunden statt 2:41 — eine klar abgegrenzte Aufgabe auf der grünen Wiese.
  • 26 Prozent mehr erledigte Aufgaben. Drei Feldexperimente mit 4.867 Entwicklerinnen und Entwicklern bei Microsoft, Accenture und einem Fortune-100-Unternehmen (Cui, Demirer et al., Management Science). Der Zuwachs war bei weniger erfahrenen Teilnehmern deutlich höher.
  • 19 Prozent langsamer. METR ließ 16 erfahrene Open-Source-Entwickler 246 Aufgaben in Repositories bearbeiten, die sie seit Jahren selbst pflegen. Mit KI-Werkzeugen dauerte es länger. Bemerkenswert ist der zweite Befund: Dieselben Teilnehmer glaubten danach, rund 20 Prozent schneller gewesen zu sein.

Das ist kein Widerspruch, sondern ein Muster. Der Effekt ist groß bei neuem, gut abgegrenztem Code und schrumpft — bis ins Negative —, je gewachsener die Codebasis, je höher die Qualitätslatte und je mehr Kontext eine Änderung voraussetzt. Wer über Einsparung durch KI spricht, muss deshalb sagen, worüber genau er spricht. Eine Prozentzahl für „die Softwareentwicklung“ gibt es nicht.

Warum liegt das KI-Coding-Potenzial je Branche so weit auseinander?

Balkendiagramm: Nutzbarkeit von KI-Coding nach Anwendungsfeld. Web- und App-Entwicklung sehr hoch, Unternehmens- und Backend-Software hoch, Steuerungs- und Embedded-Software mittel, sicherheitskritische Systeme gering, Verschlusssachen und Rüstung sehr gering.

Qualitative Einordnung nach Freigabewegen, Nachweispflicht und Hardwarebezug — keine Messwerte.

Am oberen Ende steht die Web- und App-Entwicklung. Für die Winter-Kohorte 2025 von Y Combinator sagte Managing Partner Jared Friedman in einem Videogespräch, ein Viertel der Startups habe Codebasen, die zu rund 95 Prozent von KI erzeugt seien — eine Einzelaussage aus dem Programm selbst, keine Erhebung, und damit nur als Größenordnung zu lesen. Es sind kleine, junge Systeme ohne Altlasten. Für große Konzern-Codebasen liegen die belastbaren Angaben niedriger: Satya Nadella nannte im April 2025 20 bis 30 Prozent des Codes in Microsoft-Repositories, Sundar Pichai für Google eine Größenordnung von 25 Prozent. Beide Zahlen sind Selbstauskünfte ohne offengelegte Messmethode — als Richtung brauchbar, als Kalkulationsgrundlage nicht.

Am unteren Ende steht die Rüstung. Der Grund ist nicht technischer, sondern regulatorischer Natur: Wer eingestufte oder exportkontrollierte Inhalte in ein kommerzielles Cloud-Modell gibt, verlässt den zugelassenen Bereich. Im US-Rahmenwerk ist das ausbuchstabiert — für die Verarbeitung von Controlled Unclassified Information verlangt CMMC eine FedRAMP-Autorisierung, die die verbreiteten Werkzeuge nicht haben (Washington Technology, April 2026). Übrig bleiben lokal betriebene Modelle mit Abstrichen bei Leistung und Werkzeugkette.

Dazwischen liegt die sicherheitskritische Entwicklung. Hier ist nicht die Erzeugung von Code das Nadelöhr, sondern der Nachweis. ISO 26262, DO-178C und IEC 62304 verlangen Rückverfolgbarkeit von der Anforderung bis zum verifizierten Ergebnis und Werkzeuge in qualifizierter Konfiguration; KI-erzeugte Artefakte sind nicht per se anerkannte Verifikationsevidenz. Genau deshalb liegt das Potenzial in unserem ausgewerteten Projektbeispiel für Steuerungs-, Embedded- und Systemsoftware niedriger als für reine Webentwicklung.

Zwei Gründe, warum das den Einkauf betrifft

1. Der Produktivitätsgewinn entsteht beim Lieferanten

Dass ein Lieferant einen erzielten Effizienzgewinn zunächst in der eigenen Marge behält, ist der betriebswirtschaftliche Normalfall und kein Fehlverhalten — er hat Werkzeuge, Schulung und Prozessumbau bezahlt. Weitergegeben wird, was verhandelt wird, und verhandelt wird, was benennbar ist.

Dass daraus ein Marktthema geworden ist, zeigt die Angebotsseite selbst. Große IT-Dienstleister sprechen offen von „AI deflation“: HCLTech rechnet für das kommende Jahr mit einem Umsatzeffekt von 3 bis 5 Prozent, Wettbewerber bestätigen den Druck (The Register, April 2026). Der Preisdruck ist also real — nur entsteht er heute vor allem im Standardgeschäft mit vergleichbaren Leistungen. Bei einem einmaligen Projekt ohne Vergleichsangebot fehlt dem Einkauf genau die Grundlage, um dieselbe Frage zu stellen. Wo er das Potenzial nicht beziffern kann, bleibt die Weitergabe eine Frage der Kulanz.

2. Die eigene Spezifikation kann das Potenzial sperren

Der zweite Grund wird seltener gesehen und kostet beide Seiten. Anforderungen an Werkzeugketten, Datenabfluss, Codestandards, Freigabewege und Nachweistiefe entscheiden mit darüber, ob der Lieferant KI-gestützt arbeiten darf. Eine Klausel, die jede Übertragung von Projektdaten an Dritte ausschließt, schließt die verbreiteten Cloud-Werkzeuge mit ein. Eine Nachweisforderung, die über den tatsächlich erforderlichen Sicherheitsgrad hinausgeht, verlängert genau die Phasen, in denen der Hebel sonst am größten wäre.

Beides kann im Einzelfall richtig und zwingend sein. Es sollte nur eine Entscheidung sein, deren Preis in Kosten und Durchlaufzeit bekannt ist — und nicht ein Nebeneffekt einer Formulierung, die aus dem letzten Lastenheft übernommen wurde.

Wo der Hebel am größten ist: Test und Dokumentation

Die Aufmerksamkeit liegt beim Schreiben von Code, der Hebel liegt daneben. Im Stack Overflow Survey 2025 ist Dokumentation die Tätigkeit mit dem höchsten KI-Anteil: 30,8 Prozent der Befragten erledigen das Dokumentieren von Code überwiegend mit KI — gegenüber 17,9 Prozent beim Testen und 16,9 Prozent beim Schreiben von Code selbst.

Für Tests gibt es zudem einen industriellen Beleg mit harter Prüfung. Metas TestGen-LLM erzeugte Unit-Tests, die vor der Übernahme mehrere Filter passieren mussten: 75 Prozent der erzeugten Testklassen bauten fehlerfrei, 57 Prozent liefen zuverlässig, 25 Prozent erhöhten die Testabdeckung messbar. 73 Prozent der Empfehlungen wurden von Meta-Ingenieuren für den Produktivbetrieb übernommen. Der entscheidende Punkt ist das Vorgehen: Der Nutzen wurde nachgewiesen, nicht unterstellt.

Bei komplexen Projekten sind Test-, Nachweis- und Dokumentationsanteile ein erheblicher Block der einmaligen Entwicklungs- und Engineeringkosten. Ein Potenzial, das dort gehoben wird, wirkt auf die Gesamtsumme deutlich stärker, als die reine Betrachtung der Implementierung vermuten lässt.

Was eine Analyse bis auf Arbeitspaketebene ändert

Alle Zahlen oben haben dieselbe Schwäche: Sie gelten für Aufgaben, nicht für Ihr Projekt. Nutzbar werden sie erst, wenn bekannt ist, aus welchen Arbeitspaketen das Projekt besteht, welchen Liefergegenstand jedes davon erzeugt und wie viel Aufwand darauf entfällt. Erst dann lässt sich sagen: In dieser Phase ist der Hebel groß, in jener praktisch null, und diese Anforderung kostet ihn.

Genau das ist die Grundlage, auf der wir arbeiten. Aus den vorhandenen Unterlagen entsteht ein vollständiges Projektbild bis auf Arbeitspaketebene; darauf wird das Potenzial phasenweise bewertet — als Bandbreite, nicht als zugesagte Einsparung. Die Werte, die wir dabei ansetzen, sind bewusst zurückhaltend, damit sie auch dann tragen, wenn nicht jede Voraussetzung ideal ist. Wie das in einem konkreten Vorhaben aussieht, zeigt das Projektbeispiel — je Projektphase beziffert.

Das Ergebnis lässt sich zweifach verwenden: intern, als Prüfmaßstab für die eigene Kalkulation und die Zielkosten — und gemeinsam mit dem Lieferanten, als Grundlage für eine Aufwandsoptimierung, von der beide Seiten etwas haben. Der zweite Weg ist in aller Regel der ergiebigere.

Und es bleibt nicht bei der Aussage: Was an Potenzial identifiziert ist, kann unser wissenschaftlicher Technologiepartner AlgebraX gemeinsam mit Ihnen und Ihrem Lieferanten umsetzen — von der Werkzeugkette bis zur Frage, welche Nachweise sich wie automatisieren lassen.

Quellen