Zum Inhalt springen
SwankyForge
SwankyForge
Alle Insights
Artikel9 Min. Lesezeit

KI hat das Schreiben von Code billiger gemacht. Softwareprojekte sind dadurch nicht automatisch billiger.

Kontrollierte Messungen zeigen geringe oder sogar negative Beschleunigung durch KI-Coding-Tools, und Programmieren macht nur einen kleinen Teil der Projektzeit aus. Ein ehrlicher KI-Rabatt ist deshalb klein und lässt sich Phase für Phase zuordnen.

Im Juli 2025 veröffentlichte die gemeinnützige Forschungsorganisation METR eine randomisierte Studie zu KI-Coding-Tools bei realer Arbeit. Sechzehn erfahrene Open-Source-Entwickler bearbeiteten 246 Aufgaben in ihren eigenen Repositories, und jede Aufgabe wurde zufällig der Gruppe „KI erlaubt“ oder „KI nicht erlaubt“ zugeteilt. Mit KI dauerten die Aufgaben 19% länger. Vor der Studie erwarteten dieselben Entwickler, dass KI sie um 24% beschleunigen würde. Danach glaubten sie immer noch, etwa 20% schneller gewesen zu sein.

Diese Lücke zwischen gefühlter und gemessener Geschwindigkeit ist der nützliche Teil für alle, die Software einkaufen. Anbieter werben inzwischen mit KI-beschleunigter Lieferung und preisen sie ein. Ein Teil der Ersparnis ist real. Der größte Teil der Behauptung betrifft das Tippen und wird auf ein Budget angewendet, das überwiegend nicht aus Tippen besteht.

Diese Notiz behandelt, was die Daten aus 2025 sagen, wohin die Stunden in einem Machine-Learning-Projekt gehen und was Sie einen Anbieter fragen sollten, der Ihnen einen KI-Rabatt anbietet.

Was die Daten aus 2025 sagen

Vier Quellen, vier Methoden. Keine davon stützt die Vorstellung, dass ein Projekt halb so viel kostet, weil der Code mit einem Assistenten geschrieben wurde.

Quelle Methode Ergebnis
METR, Juli 2025 Randomisierte Studie: 16 Entwickler, 246 Aufgaben, Repositories mit durchschnittlich 22k+ Sternen und 1M+ Codezeilen Mit KI 19% langsamer; die Entwickler glaubten, etwa 20% schneller zu sein
Stack Overflow Developer Survey, Juli 2025 Umfrage, 26k–34k Antworten pro Frage 84% nutzen KI-Tools oder planen es; 46% misstrauen ihrer Genauigkeit, 33% vertrauen ihr; 66% nennen „fast richtig, aber nicht ganz“ als größtes Ärgernis
Google DORA Report, September 2025 Umfrage unter fast 5.000 Technologie-Fachleuten 90% nutzen KI bei der Arbeit; KI-Einsatz geht mit höherem Liefer-Durchsatz einher und trotzdem mit geringerer Lieferstabilität
Bain Technology Report, September 2025 Branchenforschung Teams mit Assistenten sehen 10–15% Produktivitätsgewinn; Schreiben und Testen von Code macht 25–35% der Zeit von der Idee bis zum Launch aus

Das METR-Ergebnis hat Grenzen, die die Autoren offen benennen: eine kleine Stichprobe, erfahrene Entwickler in großen Codebasen, die sie bereits kannten, und Tools vom Anfang 2025 (Cursor Pro mit Claude 3.5 und 3.7 Sonnet). Es zeigt nicht, dass KI alle verlangsamt. Es zeigt zwei engere Dinge. Selbst berichtete Beschleunigung ist kein Beleg. Und bei ausgereiftem, komplexem Code kann die Zeit für Prompten, Warten, Prüfen und Korrigieren die beim Schreiben gesparte Zeit aufheben.

Die Umfragen zeigen aus einem anderen Blickwinkel in dieselbe Richtung. Die Nutzung ist Routine: 51% der professionellen Entwickler in der Stack-Overflow-Umfrage nutzen KI-Tools täglich, und die Befragten von DORA verbringen im Median zwei Stunden am Tag damit. Das Vertrauen ist es nicht: 45% der Stack-Overflow-Befragten sagen, dass das Debuggen von KI-generiertem Code mehr Zeit kostet, und 30% der DORA-Befragten haben wenig oder kein Vertrauen in KI-generierten Code. DORA fasst zusammen, dass KI verstärkt, was ein Team bereits ist. Starke Teams werden schneller. Teams mit schwachen Tests und langsamem Feedback liefern mehr Änderungen aus und machen mehr davon kaputt.

Warum billigeres Tippen kein billigeres Projekt bedeutet

Die beiden Zahlen von Bain reichen, um die Obergrenze zu sehen. Wenn Schreiben und Testen von Code 30% der Zeit von der Idee bis zum Launch ausmachen und ein Assistent diesen Teil um 30% beschleunigt, wird das ganze Projekt um 9% schneller: 0,30 × 0,30 = 0,09. Selbst wenn Code kostenlos und sofort verfügbar wäre, blieben die anderen 65–75% der Arbeit. Ingenieure kennen das als Amdahlsches Gesetz: Die Beschleunigung einer Stufe einer Pipeline ist durch den Zeitanteil dieser Stufe begrenzt.

Der Rest eines Projekts besteht aus Spezifikation, Datenarbeit, Integration, Review, Tests, Evaluation, Deployment und Betrieb. Jeder dieser Teile hat seinen eigenen Grund, nicht im gleichen Maß zu schrumpfen.

  • Spezifikation ist ein Gespräch mit den Menschen, denen das Problem gehört. Ein Assistent kann das Dokument entwerfen. Er kann nicht entscheiden, dass die Kennzahl die Marge und nicht der Umsatz ist.
  • Datenarbeit besteht vor allem darin, herauszufinden, was eine Spalte bedeutet, wem die Tabelle gehört und warum manche Zeilen doppelt vorkommen. Das Schreiben des SQL war nie der langsame Teil.
  • Integration kostet Zeit durch die API eines anderen Teams, Zugangsdaten, Rate Limits und Release-Fenster.
  • Review wird aufwendiger. Mehr generierter Code pro Tag bedeutet mehr Code, der pro Tag gelesen werden muss, und fast richtiger Code ist am teuersten zu prüfen, weil er fertig aussieht.
  • Evaluation und Betrieb folgen dem Kalender. Man wartet auf eine Woche Traffic, einen Monatsabschluss oder darauf, dass eine Holdout-Gruppe genug Daten sammelt.

Der Stabilitätsbefund von DORA ist die gemessene Version des Review-Punkts. Teams liefern mehr Änderungen aus, und ohne starke automatisierte Tests und schnelle Feedbackschleifen schlagen mehr dieser Änderungen fehl.

Wohin die Stunden in einem ML-Projekt gehen

Die folgende Tabelle ist illustrativ. Sie zeigt unsere grobe Aufteilung für ein mittelgroßes Machine-Learning-Projekt, etwa ein Empfehlungs- oder Prognosesystem, das in ein bestehendes Produkt eingebunden wird, zusammen mit unseren Annahmen, wie viel KI-Unterstützung in jeder Phase spart. Die Prozentsätze sind Planungsannahmen, keine Messungen. Ersetzen Sie sie durch Ihre eigenen und rechnen Sie neu.

Phase Anteil der Stunden Stunden von 600 Angenommene KI-Ersparnis Gesparte Stunden
Discovery: Kennzahl, Baseline, Spezifikation 10% 60 0% 0
Datenzugang, Bereinigung, Feature-Pipelines 25% 150 15% 22,5
Modellierung und Experimente 15% 90 20% 18
Integration in Ihre Systeme 15% 90 20% 18
Tests, Evaluation, Code-Review 15% 90 0% 0
Deployment, Monitoring, Rollback 10% 60 10% 6
Demos, Abnahme, Übergabe 10% 60 0% 0
Summe 100% 600 64,5, etwa 11%

Die Begründung für jede Zeile:

  • Discovery spart nichts, weil ihr Ergebnis Entscheidungen sind, und Entscheidungen kommen aus dem Fachbereich.
  • Datenarbeit spart etwas. Assistenten schreiben Abfragen, Parser und Validierungsprüfungen schnell, aber die meisten Stunden gehen ins Warten auf Zugänge und ins Verstehen der Daten.
  • Modellierung und Integration sparen am meisten, weil sie den meisten Mustercode enthalten: Trainingsschleifen, API-Clients, Serialisierung, Konfiguration.
  • Tests und Review gleichen sich auf null aus. Assistenten schreiben Testgerüste schnell, und der zusätzliche generierte Code erhöht die Review-Zeit. Teams mit starken Test-Suites sehen hier vielleicht einen Gewinn, Teams ohne sie vielleicht einen Verlust.
  • Deployment spart ein wenig bei Konfigurationsvorlagen. Das Warten darauf, dass ein Canary-Release Traffic sammelt, wird nicht kürzer.

Bei unserem veröffentlichten Stundensatz für ML-Engineers von 50 € sind 600 Stunden 30.000 € und 64,5 Stunden etwa 3.200 €. Das ist die Größenordnung eines ehrlichen KI-Rabatts bei einem Projekt dieser Art: real, lohnend und weit entfernt von der Hälfte. Er liegt zufällig auch innerhalb von Bains Spanne von 10–15%, was eine Plausibilitätsprüfung ist und kein Beweis.

Die andere Zahl von Bain ist die interessantere. Unternehmen, die den gesamten Prozess um KI herum neu gestaltet haben, statt nur Assistenten zu verteilen, berichteten von 25–30% Gewinn. Diese Ersparnis entsteht durch Änderungen an dem, was zwischen den Codezeilen passiert: wie Spezifikationen geschrieben werden, wie Review funktioniert, wie Releases getestet werden. Das ist eine Prozessänderung, und sie kostet Aufwand, bevor sie sich auszahlt. Bain merkt außerdem an, dass drei von vier Unternehmen die Änderung der Arbeitsweise der Menschen als schwierigsten Teil nennen.

Wie sich die Arbeit von Entwicklern verändert hat

Die Arbeit hat sich vom Schreiben zum Spezifizieren und Prüfen verschoben. Ein Entwickler mit Assistent verbringt weniger Zeit mit der ersten Version und mehr Zeit mit drei Dingen.

  1. Präzise Anweisungen. Der Assistent tut, was in der Spezifikation steht, also erzeugt eine vage Spezifikation jetzt schneller plausiblen falschen Code.
  2. Lesen und Korrigieren der Ausgabe. Hier entsteht das Ärgernis „fast richtig“. Falscher Code, der laut scheitert, ist billig. Code, der den offensichtlichen Test besteht und am Randfall scheitert, ist teuer.
  3. Die Prüfungen, die Geschwindigkeit sicher machen. Tests, Evaluationssets, Typprüfungen, gestufte Rollouts.

Bei Machine-Learning-Arbeit trägt der dritte Punkt das meiste Gewicht. Eine Modelländerung, die im Notebook richtig aussieht, kann in Produktion eine Geschäftskennzahl senken. Ein Assistent kann das Evaluations-Harness schreiben. Er kann nicht entscheiden, was das Evaluationsset enthalten soll oder was eine Regression das Unternehmen kostet.

Wo sich die Ersparnis zeigt

Unsere Einschätzung, die eine Meinung und keine Messung ist: Assistenten sparen echte Zeit bei

  • Prototypen und Wegwerf-Analysen, bei denen fast richtig gut genug ist, um etwas zu lernen;
  • Code mit klarem Muster: API-Clients, Datenklassen, Konfiguration, Schemamigrationen;
  • unbekannten Bibliotheken, bei denen der Assistent eine Stunde Dokumentationslektüre ersetzt;
  • ersten Entwürfen von Tests und Dokumentation, die dann ein Mensch korrigiert.

Wenig sparen sie bei Entscheidungen, Wartezeiten, Abstimmung und Review. Ein glaubwürdiger KI-Rabatt sollte zu dieser Aufteilung passen.

Was Sie einen Anbieter fragen sollten, der einen KI-Rabatt verspricht

  • Wo genau hat KI Stunden eingespart? Fragen Sie nach der Schätzung pro Phase, mit und ohne Unterstützung. Ein Rabatt, der sich keiner Phase zuordnen lässt, ist ein Vertriebsrabatt. Das ist in Ordnung, aber er sollte auch so heißen.
  • Wer prüft KI-geschriebenen Code, und wie? Fragen Sie, ob ein Mensch jede Änderung prüft, was geprüft wird und ob die Review-Zeit in der Schätzung enthalten ist.
  • Wie wird Qualität gemessen? Tests auf den kritischen Pfaden, ein Evaluationsset für das Modellverhalten, eine Change Failure Rate. Lautet die Antwort, dass der Code funktioniert, fragen Sie, woher man das weiß.
  • Was passiert, wenn generierter Code in Produktion falsch ist? Monitoring, Rollback und eine verantwortliche Person in Rufbereitschaft gehören in den Plan, nicht in einen späteren Change Request.
  • Wo liegt das Repository? Liegt der Code bis zur Schlussrechnung im Account des Anbieters, können Sie nichts davon prüfen, solange es noch zählt.

Wie wir damit umgehen

Unsere Preisliste ist pro Rolle und pro Stunde veröffentlicht, sodass sich jede unserer Schätzungen als Stunden mal Satz prüfen lässt, Phase für Phase. Sie sehen jede Woche eine lauffähige Demo, das Repository liegt vom ersten Tag an in Ihrer Organisation, und jeder Meilenstein wird erst nach Ihrer Abnahme in Rechnung gestellt. Typische Projektspannen sind neben der Preisliste veröffentlicht, und ein Teardown bepreist Discovery, Proof of Concept und Produktion getrennt. Wenn KI-Unterstützung eine Phase schneller macht, zeigt sich das als weniger Stunden auf der Rechnung, nicht als Versprechen im Angebot.

Quellen

Haben Sie einen Prozess, der zu viel kostet?

Erzählen Sie uns davon. Das erste Gespräch ist kostenlos, und wenn KI nicht die Antwort ist, sagen wir das.

Aufgabe besprechen