Wird KI wie ChatGPT je Entwickler ersetzen? Die Sicht eines Entwicklers, mit den Belegen

Die kurze Antwort: ein Assistent, kein Ersatz

Kaum eine Frage höre ich öfter. Werden Tools wie ChatGPT Entwickler ersetzen? Meine Antwort als jemand, der vom Programmieren lebt, hat sich nicht geändert, seit ich diesen Text zum ersten Mal geschrieben habe: KI ist für Entwickler ein unschätzbar wertvoller Assistent, aber sie ersetzt nicht die menschliche Erfahrung, die gutes Programmieren braucht. Sie erfasst die Feinheiten eines Problems nicht wirklich so, wie es ein Entwickler tut.

Genau diese Meinung würdest du von einem Entwickler erwarten. Deshalb stelle ich sie neben die besten Belege, die es gibt: nicht das Marketing der Anbieter, sondern kontrollierte Studien, in denen eine Gruppe von Entwicklern das KI Tool bekommt, eine vergleichbare Gruppe nicht, und jemand den Unterschied misst.

Manche dieser Studien zeigen, dass Entwickler mit KI deutlich schneller fertig werden. Eine sorgfältige Studie zeigte erfahrene Entwickler, die langsamer wurden und sich dabei schneller fühlten. Beides kann stimmen, und der Grund dafür ist das Nützlichste, was du als Unternehmerin oder Unternehmer darüber lernen kannst, wie man Arbeit an diese Tools abgibt.

Eine verwandte Frage wiederhole ich hier nicht: Wenn KI den Code schreibt, wer steht dafür gerade, wenn er bricht? Das behandle ich, mit der Sicherheitsforschung und den Gefahren in der Reihenfolge, in der sie teuer werden, in KI schreibt den Code. Wer ist dafür verantwortlich?

Durch den ganzen Artikel begleitet uns ein erfundenes Unternehmen. Die Elbkammer ist ein kleiner Onlineshop für Feinkost in Hamburg. Jana führt ihn und verkauft Käse, Wurstspezialitäten und Geschenkboxen über elbkammer.example. Niemand davon ist echt, jede Zahl ist ausgedacht, damit ich jeden Schritt zeigen kann.

Wie eine kontrollierte Studie Produktivität misst

Bevor die Zahlen kommen, lohnt sich ein Blick darauf, wie sie entstehen. Die Methode entscheidet, was eine Zahl bedeutet.

In einer randomisierten kontrollierten Studie werden Entwickler (oder Aufgaben) per Zufall auf zwei Gruppen verteilt. Die eine Gruppe darf das KI Tool nutzen, die andere nicht. Weil der Zufall die Gruppen bildet, sind beide im Schnitt bei Können, Erfahrung und Glück gleich, und ein Unterschied im Ergebnis lässt sich dem Tool zuschreiben. Gemessen wird meist die Zeit bis zur fertigen Aufgabe oder die Zahl der erledigten Aufgaben pro Woche.

Bei jeder solchen Studie lohnen sich zwei Fragen. Was war die Aufgabe? Eine kleine, klar beschriebene Übung ist etwas ganz anderes als eine Änderung an einer großen Codebasis, die jemand seit Jahren pflegt. Und was wurde gemessen? Tempo ist nicht dasselbe wie Korrektheit, und mehr erledigte Aufgaben heißt nicht, dass sie gut erledigt sind.

Beispiel: das GitHub Copilot Experiment lesen

Die bekannteste frühe Studie stammt von Forschenden bei Microsoft Research, GitHub und dem MIT aus dem Jahr 2023. Sie gewannen 95 professionelle Entwickler über eine Onlineplattform für Aufträge und teilten sie per Zufall auf: 45 durften GitHub Copilot nutzen, ein KI Tool, das beim Tippen Code vorschlägt, 50 durften es nicht. Die Kontrollgruppe konnte aber frei im Web und auf Stack Overflow suchen. Alle mussten dasselbe bauen: einen kleinen Webserver in JavaScript, so schnell wie möglich, geprüft von einer Testsuite mit 12 Prüfungen.¹

Unter denen, die fertig wurden, brauchte die Gruppe mit Copilot im Schnitt 71,17 Minuten, die Kontrollgruppe 160,89 Minuten. Die Zeitersparnis ist eins minus das Verhältnis der beiden Werte:

$$1 - \frac{71{,}17}{160{,}89} = 1 - 0{,}442 = 0{,}558$$

Dabei ist $71{,}17$ die durchschnittliche Zeit mit dem Tool in Minuten, $160{,}89$ die durchschnittliche Zeit ohne, und $0{,}558$ der Anteil der eingesparten Zeit, also 55,8 %. Die Studie nennt ein 95 % Konfidenzintervall von 21 % bis 89 %. Die tatsächliche Ersparnis in diesem Umfeld könnte also plausibel irgendwo in dieser breiten Spanne liegen. Dieselbe Studie fand, dass weniger erfahrene Entwickler am meisten profitierten.¹ Wie man so ein Intervall liest, erkläre ich in Grundlagen: Konfidenzintervalle.

Für Jana heißt das: Bei einer kleinen, klar beschriebenen Aufgabe, die bei null anfängt, hat das Tool die Zeit ungefähr halbiert. Über eine Änderung am Checkout eines Feinkostladens, der seit sechs Jahren verkauft, sagt es nichts. Mehrere Autoren arbeiteten für das Unternehmen hinter dem Tool, auch das ist gut zu wissen.

Die Feldexperimente: mehr erledigte Aufgaben, gemessen in echten Unternehmen

Eine zweite, viel größere Studie verließ das Labor. Forschende aus Princeton, vom MIT, von Wharton und von Microsoft werteten drei randomisierte Versuche aus, die Microsoft, Accenture und ein ungenannter Elektronikhersteller aus den Fortune 100 im normalen Geschäftsbetrieb durchgeführt hatten. Ein zufällig gewählter Teil der Entwickler bekam Zugang zu einem KI Assistenten fürs Programmieren, und die Versuche liefen zwischen zwei und acht Monaten, bevor alle ihn bekamen.²

Über alle 4.867 Entwickler zusammen schätzen die Autoren ein Plus von 26,08 % bei den erledigten Aufgaben pro Woche unter denen, die das Tool nutzten, mit einem Standardfehler von 10,3 %. Jedes Experiment für sich allein war verrauscht. Weniger erfahrene Entwickler nutzten das Tool häufiger und gewannen mehr.²

Als "erledigte Aufgabe" zählte der Pull Request, also das Paket aus Code, das ein Entwickler zur Prüfung durch eine Kollegin oder einen Kollegen einreicht. Das misst Output. Ob der Code richtig war, misst es nicht, und das räumen die Autoren selbst ein: Wenn Entwickler Vorschläge ungeprüft übernehmen, könnte die Qualität sinken.²

Beispiel: was 26 % mehr Pull Requests für Jana bedeuten würden

Angenommen, Janas Entwickler schließt in einem normalen Monat 10 Pull Requests ab. Ein Plus von 26 % brächte ihn auf

$$10 \times 1{,}26 = 12{,}6$$

Dabei ist $10$ die Zahl der Pull Requests pro Monat ohne das Tool, $1{,}26$ ist eins plus das geschätzte Plus von 26 %, und $12{,}6$ ist die erwartete Zahl der Pull Requests pro Monat mit dem Tool. Der Standardfehler von rund 10 Punkten heißt, dass der wahre Effekt leicht nur halb so groß oder spürbar größer sein könnte. Warum, erkläre ich in Grundlagen: Stichproben.

Zwei oder drei zusätzliche Arbeitspakete im Monat sind echt. Von "du brauchst keinen Entwickler mehr" sind sie weit entfernt. Jedes davon geht weiterhin durch die Prüfung eines Menschen.

Die Studie, in der erfahrene Entwickler langsamer wurden

Im Juli 2025 veröffentlichte METR, eine Forschungsorganisation, die die Fähigkeiten von KI untersucht, das Ergebnis, das fast alle überraschte. METR führte eine randomisierte Studie mit 16 erfahrenen Open Source Entwicklern durch, die an 246 echten Aufgaben in ausgereiften Projekten arbeiteten, die sie gut kannten. Jede Aufgabe wurde per Zufall "KI erlaubt" oder "KI nicht erlaubt" zugeteilt. Genutzt wurden die Tools, die zwischen Februar und Juni 2025 verfügbar waren.³

Mit erlaubter KI dauerten die Aufgaben 19 % länger.³ Ein späterer Beitrag von METR nennt als Konfidenzintervall 2 % bis 39 % länger.⁴ Das waren Leute, die ihre eigene Codebasis in und auswendig kannten. Genau dort hat ein allgemeines Tool am wenigsten beizutragen und am meisten, was es unauffällig falsch machen kann.

Beispiel: eine Aufgabe von zehn Stunden, dreimal betrachtet

Das Auffällige ist nicht nur die Verlangsamung. Vor der Studie erwarteten die Entwickler, dass KI ihre Bearbeitungszeit um 24 % senken würde. Danach schätzten sie, sie habe ihre Zeit um 20 % gesenkt.³ Nimm eine Aufgabe, die ohne KI 10 Stunden dauert:

$$\begin{aligned} \text{erwartet} &= 10 \times (1 - 0{,}24) = 7{,}6 \text{ Stunden} \\ \text{gefühlt} &= 10 \times (1 - 0{,}20) = 8{,}0 \text{ Stunden} \\ \text{gemessen} &= 10 \times (1 + 0{,}19) = 11{,}9 \text{ Stunden} \end{aligned}$$

In jeder Zeile ist $10$ die Zahl der Stunden ohne KI, $0{,}24$ und $0{,}20$ sind die erwartete und die gefühlte Senkung, und $0{,}19$ ist der gemessene Anstieg. Die Lücke zwischen Gefühl und Wirklichkeit beträgt $11{,}9 - 8{,}0 = 3{,}9$ Stunden bei einer einzigen Aufgabe. Prozentrechnung dieser Art erkläre ich in Grundlagen: Prozente.

Die waagrechte Achse zeigt vier Blicke auf dieselbe Arbeit: die Zeit ohne KI, was die Entwickler erwarteten, was sie danach glaubten und was gemessen wurde. Die senkrechte Achse ist die Zeit pro Aufgabe, wobei die Zeit ohne KI auf 100 gesetzt ist, niedriger heißt also schneller. Entscheidend ist der Abstand zwischen dem dritten und dem vierten Balken. Dein eigenes Gefühl, schneller zu sein, ist kein Beleg, und das deines Entwicklers auch nicht, meines eingeschlossen.

Die Belege ändern sich schnell, und die neuesten sind ehrlich über ihre Grenzen

Eine Studie aus dem frühen 2025 ist nicht das letzte Wort, und METR sagt das selbst. Am 24. Februar 2026 veröffentlichte METR ein Update zu einer größeren Folgestudie, die im August 2025 begonnen hatte: 57 Entwickler (10 wieder dabei, 47 neu), 143 Repositories und über 800 Aufgaben.⁴

Die rohen Schätzungen zeigten diesmal in die andere Richtung. Bei den wiederkehrenden Entwicklern dauerten die Aufgaben mit KI geschätzt 18 % kürzer, mit einem Intervall von 38 % kürzer bis 9 % länger. Bei den neuen Entwicklern waren es 4 % kürzer, von 15 % kürzer bis 9 % länger. Beide Intervalle schließen null ein.⁴

METR erklärte dann, warum es diesen Zahlen als saubere Schätzung nicht traut. Viele Entwickler lehnten die Teilnahme inzwischen ab oder reichten Aufgaben, die sie nicht ohne KI erledigen wollten, gar nicht erst ein. Damit war genau die Arbeit, die am besten zu KI passt, unterrepräsentiert. Die Zeiterfassung wurde unzuverlässig, sobald Leute mehrere KI Agenten gleichzeitig laufen ließen. METR kam zu dem Schluss, die zentrale Schätzung sei "wahrscheinlich ein schlechter Stellvertreter" (von mir übersetzt) für den echten Effekt, hält es aber für wahrscheinlich, dass Entwickler Anfang 2026 stärker beschleunigt waren als Anfang 2025.⁴

Beispiel: was Jana aus einem beweglichen Ziel mitnimmt

Jana hat vor sich: 56 % schneller bei einer kleinen neuen Aufgabe, 26 % mehr Pull Requests in großen Unternehmen, 19 % langsamer für Fachleute in ausgereiftem Code und ein Update von 2026, das zu schneller tendiert, dessen Autoren aber nicht hinter der Größe stehen. Einen Sieger braucht sie nicht. Sie braucht eine Regel: Die Antwort hängt von der Aufgabe ab. Neue, klar beschriebene Arbeit mit wenig auf dem Spiel ist der Bereich, in dem jede Studie findet, dass das Tool hilft. Änderungen tief in Code, der bereits funktioniert und in dem jede Zeile einen Grund hat, sind der Bereich, in dem die Gewinne am kleinsten und am unsichersten sind. Genau diese Aufteilung nutzt sie später, um zu entscheiden, was sie abgibt.

Was Entwickler selbst berichten

Kontrollierte Studien messen Zeit. Umfragen zeigen, wo die Zeit aus Sicht der Entwickler bleibt.

Im Stack Overflow Developer Survey 2025 gaben 84 % der Befragten an, KI Tools in ihrer Entwicklungsarbeit zu nutzen oder das vorzuhaben, und 50,6 % der professionellen Entwickler nutzten sie täglich. Trotzdem misstrauten mehr Befragte der Genauigkeit von KI Ergebnissen, als ihr vertrauten: 45,7 % gegen 32,7 %. Der häufigste Frust, genannt von 66 %, waren "KI Lösungen, die fast richtig sind, aber eben nicht ganz" (von mir übersetzt), und 45,2 % sagten, das Debuggen von KI generiertem Code koste mehr Zeit.⁵

Die Umfrage 2026 mit 30.903 Antworten stellte die Fragen anders, die Zahlen sind also nicht direkt vergleichbar. Über 70 % der Befragten nutzen KI inzwischen täglich. Das Vertrauen ist an Bedingungen geknüpft: 48 % sagen, sie vertrauen KI, wenn sie die Antworten leicht überprüfen können.⁶

Das deckt sich sehr genau mit meiner eigenen Erfahrung. Ich habe das selbst getestet, und manchmal habe ich mit KI mehr Zeit mit Debuggen und Umbauen von Code verbracht, als wenn ich ihn gleich selbst geschrieben hätte. Man dreht sich im Kreis. Die KI schlägt Änderungen vor, aber manchmal schaffen diese Änderungen neue Probleme oder übergehen Dinge, die gut funktioniert haben. "Fast richtig" ist die teuerste Art von falsch, weil es einen flüchtigen Blick übersteht. Was das kostet, wenn es in der Produktion landet, habe ich in das Geschäft mit dem Aufräumen nach KI Katastrophen beschrieben.

Beispiel: wenn leicht überprüfbar die ganze Frage ist

Hinter der Vertrauenszahl von 2026 steckt ein praktischer Test. Jana bittet um zwei Dinge. Erstens um eine Liste mit 40 Beispielprodukten, um ihren Testshop zu füllen. Das kann sie auf einen Blick prüfen: Sind es 40 Zeilen, sehen sie nach Feinkost aus. Zweitens um eine Änderung daran, wie die Preise von Geschenkboxen berechnet werden, wenn zwei Rabatte gleichzeitig gelten. Das kann sie nicht auf einen Blick prüfen, denn die Zahlen sehen in beiden Fällen plausibel aus. Das Erste ist leicht zu überprüfen, also ist KI dafür ein guter Autor. Das Zweite nicht, also muss wer auch immer es übernimmt, es Zeile für Zeile verstehen.

Wo KI ihr Geld wert ist

Ich bin kein Skeptiker, der die Tools verweigert. ChatGPT und Co. sind eine echte Hilfe, und nach meiner Erfahrung sind sie gut darin:

• sich wiederholenden Code zu erzeugen, etwa Seed Dateien für eine Datenbank oder Boilerplate
• Alternativen bei Syntax oder Bibliotheken vorzuschlagen
• Ideen für die Lösung gängiger Programmierprobleme zu liefern
• bei Dokumentation und Kommentaren zu helfen

Am meisten beschleunigen sie dort, wo du mit einer Syntax oder einer Bibliothek weniger vertraut bist, oder wenn du einen Ansatz für ein Feature in einem Framework suchst, das du nicht jeden Tag nutzt. Nach meiner Erfahrung bringt dich das ungefähr 80 % des Weges. Es ist, als hättest du einen Junior Entwickler oder einen Mentor neben dir, der Ideen und Ansätze mitbringt. Das passt sowohl zum Copilot Experiment als auch zu den Feldexperimenten, in denen weniger erfahrene Entwickler am meisten gewannen.¹²

Beispiel: Seed Daten für den Testshop der Elbkammer

Eine Seed Datei füllt eine Entwicklungsdatenbank mit erfundenen Datensätzen, damit sich der Shop ohne echte Kundschaft testen lässt. Sich wiederholend, wenig Risiko und leicht zu prüfen: die KI Aufgabe wie aus dem Lehrbuch. Janas Entwickler bittet um 40 Produkte und ein paar Testkunden und bekommt ungefähr das hier:

products = [ # db/seeds.rb, nur Testdaten, nie gegen die Produktion ausführen
  { name: "Altländer Weichkäse, 200g", price: 6.50, category: "Käse" },
  { name: "Geräucherte Coppa, 100g", price: 5.25, category: "Wurstspezialitäten" },
  { name: "Hamburger Geschenkbox", price: 45.00, category: "Geschenke" } # dazu 37 weitere, generiert
]
products.each { |attrs| Product.find_or_create_by!(attrs) }

5.times do |i|
  Customer.find_or_create_by!(email: "test-customer-#{i}@elbkammer.example")
end

Der Entwickler liest es trotzdem: nur Testdaten, eine reservierte Beispieldomain, damit nie ein echter Mensch eine Mail bekommt, und Datensätze, die nur angelegt werden, wenn sie fehlen. Diese Prüfung dauert eine Minute, weil der Code kurz und wenig auf dem Spiel ist.

Wo der Entwickler unverzichtbar bleibt: Randfälle

KI erfasst die Feinheiten eines Problems nicht wirklich. Wenn ich für einen Shop ein komplexes Feature baue, etwa einen eigenen Checkout mit verschiedenen bedingten Rabatten, erzeugt die KI die erste Funktion vielleicht gut. Aber sie übersieht oft Randfälle, zum Beispiel den Umgang mit fehlgeschlagenen Zahlungen oder die korrekte Berechnung von Rabatten über mehrere Produkte. Ein Entwickler hat das ganze Bild im Blick, die Randfälle und die Fehler, die später entstehen könnten.

Beispiel: der Rabatt, der richtig aussieht

Jana fährt zwei Aktionen gleichzeitig. Ein Code, HAMBURG5, zieht 5 € von der Bestellung ab. Und jede Bestellung über 50 € bekommt 10 % Rabatt. Ihre Regel, eine geschäftliche Entscheidung, die man auch anders hätte treffen können: Die 10 % werden auf die Waren vor dem Code berechnet, der Code wird am Ende abgezogen.

Eine Kundin kauft eine Käsebox für 30 € und eine Wurstbox für 25 €, also Waren für 55 €. Der richtige Betrag nach Janas Regel:

$$55 - (0{,}10 \times 55) - 5 = 55 - 5{,}50 - 5 = 44{,}50$$

Dabei ist $55$ der Warenwert in Euro, $0{,}10$ der Rabatt von 10 %, $5{,}50$ dieser Rabatt in Euro und $5$ der Code. Die Kundin zahlt 44,50 €.

Ein plausibler KI Entwurf zieht den Code von 5 € von jeder Position ab statt von der Bestellung und nimmt dann 10 % vom Rest:

$$55 - (2 \times 5) - 0{,}10 \times (55 - 10) = 55 - 10 - 4{,}50 = 40{,}50$$

Dabei ist $2 \times 5$ der Code, fälschlich auf beide Positionen angewendet, und $0{,}10 \times (55 - 10)$ der Prozentrabatt auf den bereits reduzierten Betrag. Die Kundin zahlt 40,50 €, und der Shop verliert 4 € an der Bestellung. Nichts stürzt ab. Keine Fehlermeldung erscheint. Bei 300 solchen Bestellungen im Monat sind das $300 \times 4 = 1.200$ Euro im Monat, entdeckt erst, wenn jemand die Einnahmen abgleicht.

Der Code sah richtig aus und hätte eine kurze Demo überstanden. Was ihn auffängt, ist ein Entwickler, der die Regel kennt und sie zuerst als Test aufschreibt.

Tests zuerst, weil sie zum Nachdenken zwingen

Was viele nicht wissen: Praktiken wie Test Driven Development (TDD), also testgetriebene Entwicklung, und Behaviour Driven Development (BDD), verhaltensgetriebene Entwicklung, sind entscheidend für guten, wartbaren Code. TDD heißt, den Test vor dem Code zu schreiben. Das zwingt dich zu überlegen, was das Feature können muss und was schiefgehen kann. BDD beschreibt Verhalten in einfacher Sprache, damit auch Menschen ohne Programmierhintergrund den Code verstehen und er zu den Zielen des Unternehmens passt.

Kann ChatGPT dabei helfen? Auf jeden Fall. Ich nutze es oft als Inspiration, wenn ich bei einem Test feststecke oder Ideen für die Abdeckung suche. Aber am Ende des Tages bin immer noch ich es, der den Test schreiben und den vollen Umfang des Features durchdenken muss. Den Test zu schreiben zwingt mich, über Fehlerbehandlung, Randfälle und Performance nachzudenken, und genau dieses Nachdenken ist der Teil, für den ich verantwortlich bin.

Beispiel: Janas Rabattregel festnageln

Der Entwickler schreibt das hier, bevor der Rabattcode überhaupt existiert:

RSpec.describe Checkout do
  it "nimmt 10 % von Waren über 50 €, dann den Code HAMBURG5 einmal pro Bestellung" do
    order = build_order(lines: [30.00, 25.00], code: "HAMBURG5")
    expect(Checkout.new(order).total).to eq(44.50)
  end

  it "behält den Warenkorb und zeigt eine Meldung, wenn die Zahlung fehlschlägt" do
    order = build_order(lines: [30.00], payment: :declined)
    result = Checkout.new(order).complete
    expect(result.status).to eq(:payment_failed)
    expect(order.reload.lines.count).to eq(1)
  end
end

Der erste Test hält Janas Regel mit dem genauen Betrag fest, 44,50 €. Der KI Entwurf, der 40,50 € berechnet hat, fällt sofort durch, bevor eine Kundin ihn je sieht. Der zweite deckt den Randfall ab, den eine Demo des glatten Ablaufs nie zeigt: Eine abgelehnte Karte darf den Warenkorb nicht leeren. Jetzt kann die KI die Umsetzung so oft entwerfen, wie sie will. Ob sie richtig ist, entscheiden die Tests, geschrieben von einem Menschen, der das Geschäft verstanden hat.

Das Problem der großen Codebasis

KI Tools helfen durchaus bei Codeschnipseln oder beim Debuggen kleiner Probleme. Aber um eine große Codebasis zu verstehen und ein neues Feature einzubauen, brauchst du gründliche Vertrautheit mit ihrer Syntax, ihrer Architektur und ihren Entwurfsmustern. Nichts ersetzt einen Entwickler, der sich kritisch mit dem Code auseinandersetzt und versteht, was jede Zeile tut.

Ohne dieses Verständnis führt KI Hilfe zu falschen Annahmen oder halbfertigen Lösungen: Ergebnisse, die an der Oberfläche richtig aussehen, und keine Möglichkeit festzustellen, warum sie im Zusammenspiel mit dem Rest des Projekts scheitern. Wer zum Beispiel einen Zahlungsanbieter anbindet, muss verstehen, wie die Anwendung mit dem Anbieter spricht, wie die Daten fließen und was das für die Sicherheit bedeutet. Die KI kann den Code erzeugen. Das Gespür für den Zusammenhang und die Weitsicht bei der Sicherheit bringt sie nicht mit.

Als ich diesen Artikel zum ersten Mal schrieb, war eine der größten Grenzen, die ich bei ChatGPT fand, dass es mit großen Codeblöcken schlecht zurechtkam: Lange Eingaben wurden abgeschnitten oder nicht richtig verarbeitet. Die Tools ändern sich schnell, diese konkrete Grenze würde ich ihnen heute also nicht mehr vorhalten. Die Lehre daraus hält länger. Genau das ist auch das Umfeld des METR Ergebnisses, erfahrene Entwickler in ausgereiftem Code, wo der gemessene Gewinn am kleinsten war.³ Wie schnell Code, der ohne dieses Verständnis entsteht, sich zu einer Architektur auftürmt, die niemand mehr ändern kann, beschreibe ich in Vibe Coding und seine versteckten Kosten.

Beispiel: eine Tabelle, zwei Features

Die Elbkammer speichert die Treuepunkte einer Kundin im selben Datensatz wie ihre Lieferadresse, eine alte Entscheidung, die damals einen guten Grund hatte. Jana wünscht sich ein Feature: Kundinnen und Kunden sollen eine Geschenkbox an eine Freundin oder einen Freund schicken können. Ein KI Entwurf ergänzt eine "Geschenkadresse", indem er für diese Bestellung die Lieferadresse überschreibt. In der Demo funktioniert das. In der Produktion geht die nächste normale Bestellung an die Freundin, und die Berechnung der Treuepunkte, die anhand der Adresse die Lieferzone bestimmt, vergibt jetzt Punkte zum falschen Satz. Ein Entwickler, der diese Tabelle kennt, hätte eine eigene Adresse für die Bestellung angelegt und den Kundendatensatz in Ruhe gelassen. In der Anfrage kamen Treuepunkte nicht vor. Nur das Wissen über die Codebasis wusste davon.

Ein Prüfprozess, der einen Menschen in der Verantwortung hält

Nichts davon heißt "nutze keine KI". Es heißt, dass jede Änderung einen Verantwortlichen hat, der sie versteht. Diesen Prozess würde ich für einen kleinen Shop wie den von Jana festlegen.

Die Regel kommt zuerst, in einfachen Worten, damit der Test etwas hat, woran er prüfen kann. Bestandene Tests beweisen nur, was die Tests abfragen, also liest ein Entwickler trotzdem jede Zeile und muss sie erklären können. Alles, was Checkout, Zahlungen oder Kundendaten berührt, bekommt einen zweiten Blick und einen Lauf im Testshop und geht dann mit einem Namen dahinter live. Die Seite der Verantwortung, schriftlich und in Verträgen, steht im verwandten Artikel.

Wie viel sollte Jana an KI abgeben? Der Erwartungswert, durchgerechnet

Jana bezahlt ihren Entwickler nach Stunden und will Aufgabe für Aufgabe wissen, ob es Geld spart, die KI den Code entwerfen zu lassen, wenn man das Risiko eines Fehlers mitrechnet. Das Werkzeug dafür ist der Erwartungswert: Jedes Ergebnis wird mit seiner Wahrscheinlichkeit gewichtet, dann wird alles addiert.

$$E[C] = r \sum_{i} p_i \, h_i + q \, D$$

Dabei ist $E[C]$ die erwarteten Kosten, wenn du die Aufgabe auf eine bestimmte Art erledigst, $r$ der Stundensatz des Entwicklers, die Summe $\sum_i$ läuft über die möglichen Ergebnisse für die Dauer, $p_i$ ist die Wahrscheinlichkeit von Ergebnis $i$, $h_i$ die Stunden in diesem Ergebnis, $q$ die Wahrscheinlichkeit, dass ein Fehler bei der Kundschaft ankommt, und $D$ das, was so ein Fehler kostet. Die Wahrscheinlichkeiten $p_i$ ergeben zusammen 1. Die Idee erkläre ich von Grund auf in Grundlagen: der Erwartungswert.

Die Annahmen gehören zum Beispiel, sie sind keine Messungen. Der Stundensatz $r = 75$ Euro ist eine runde Zahl. Die Zeiten liegen innerhalb der Spanne, die die Studien berichten, mit besseren Chancen für Routinearbeit, bei der jede Studie die größten Gewinne findet.

Beispiel: Routinearbeit, die Seed Daten fürs Backend

Ohne KI dauert die Aufgabe 8 Stunden und hat eine Chance von 1 % auf einen Fehler, dessen Behebung 500 € kostet:

$$E[C_{\text{manuell}}] = 75 \times 8 + 0{,}01 \times 500 = 600 + 5 = 605$$

Dabei ist $75$ der Wert von $r$, $8$ die Stunden, $0{,}01$ der Wert von $q$ und $500$ der Wert von $D$. Erwartete Kosten: 605 €.

Wenn die KI entwirft und kurz geprüft wird, nimmt Jana an: 60 % Chance auf 4,8 Stunden, 30 % auf 8 und 10 % auf 9,6, wobei sich die Fehlerchance auf 2 % verdoppelt, weil die Prüfung leichter ausfällt:

$$E[C_{\text{KI}}] = 75 \times (0{,}6 \times 4{,}8 + 0{,}3 \times 8 + 0{,}1 \times 9{,}6) + 0{,}02 \times 500 = 75 \times 6{,}24 + 10 = 478$$

Dabei sind die Stunden die $h_i$ mit ihren Wahrscheinlichkeiten $p_i$, und $0{,}02 \times 500$ ist $q \times D$. Die KI spart bei dieser Aufgabe erwartete 127 €. Abgeben.

Beispiel: kritische Arbeit, die Rabattänderung im Checkout

Ohne KI dauert die Änderung 20 Stunden, und mit den Tests von oben bleibt eine Chance von 2 %, dass trotzdem ein Fehler bei der Kundschaft ankommt. Der kostet 6.000 € an entgangener Marge, Erstattungen und einem Wochenende voller Reparaturen:

$$E[C_{A}] = 75 \times 20 + 0{,}02 \times 6.000 = 1.500 + 120 = 1.620$$

Bei Option B entwirft die KI, und es gibt nur eine leichte Prüfung. Jana nimmt 40 % Chance auf 14 Stunden an, 35 % auf 20 und 25 % auf 24, mit erwarteten Stunden von $0{,}4 \times 14 + 0{,}35 \times 20 + 0{,}25 \times 24 = 18{,}6$. Aber "fast richtiger" Code im Checkout erhöht die Fehlerchance auf 6 %:

$$E[C_{B}] = 75 \times 18{,}6 + 0{,}06 \times 6.000 = 1.395 + 360 = 1.755$$

Dabei ist $18{,}6$ die erwartete Stundenzahl $\sum_i p_i h_i$ und $0{,}06$ das erhöhte $q$.

Bei Option C entwirft die KI, aber danach läuft der vollständige Prüfprozess von oben. Das kostet bei jedem Ergebnis 2 Stunden zusätzlich (erwartet 20,6 Stunden) und bringt die Fehlerchance zurück auf 2 %:

$$E[C_{C}] = 75 \times 20{,}6 + 0{,}02 \times 6.000 = 1.545 + 120 = 1.665$$

Dabei ist $20{,}6$ die erwartete Stundenzahl einschließlich Prüfung und $0{,}02$ das $q$, das Tests und Prüfung wiederhergestellt haben.

Die waagrechte Achse zeigt die drei Wege, die Änderung umzusetzen. Die senkrechte Achse sind die erwarteten Kosten in Euro, also die Zeit des Entwicklers plus die mit ihrer Wahrscheinlichkeit gewichteten Kosten eines Fehlers. Die Erkenntnis: Die Option mit der niedrigsten Stundenrechnung, KI mit leichter Prüfung, ist die teuerste, sobald das Risiko mitgezählt wird. Mit vollständiger Prüfung liegen KI und der Entwickler allein nur 45 € auseinander, weit innerhalb der Unsicherheit von Janas Schätzungen. Im Checkout frisst die Prüfung, die die KI braucht, die Ersparnis auf.

Der Erwartungswert verdeckt außerdem etwas. Ein Ausfall von 6.000 € in der Woche vor Weihnachten könnte etwas sein, das Jana nicht verkraften kann, egal wie wahrscheinlich er ist. Wenn ein einziges schlechtes Ergebnis dem Unternehmen ernsthaft schaden könnte, reicht der Durchschnitt nicht, wie ich in Entscheidungstheorie für Gründer erkläre.

Ihre Antwort ist also eine Aufteilung, kein Ja oder Nein: Die KI entwirft die Routinearbeit, die sich leicht prüfen lässt, und die kritischen Bereiche bleiben bei einem Entwickler, der die Tests zuerst schreibt, mit der KI höchstens als Ratgeberin.

Wo das den Entwickler lässt

Nach meiner Erfahrung sind ChatGPT und ähnliche Tools Assistenten, kein Ersatz. Sie machen sich wiederholende Aufgaben schneller und sind ein guter Sparringspartner, wenn du feststeckst. Die Belege sind sich über die Form einig, wenn auch nicht über die Größe: echte Gewinne bei neuer, klar beschriebener Arbeit und für Leute, die etwas lernen, kleine oder unsichere Gewinne für Fachleute in ausgereiftem Code, und eine Lücke zwischen sich schneller fühlen und schneller sein.

Was sich nicht verschiebt, ist die Verantwortung. Jemand muss entscheiden, was der Code tun soll, die Regel aufschreiben, den Fall erwischen, den niemand erwähnt hat, und die Änderung gut genug verstehen, um dafür geradezustehen. Guter Code braucht kritisches Denken, Planung und ein Verständnis dafür, wie sich eine Änderung in das größere System einfügt. Bis ein Tool das kann und dafür einsteht, bleiben Entwickler unverzichtbar.

Komplexen Code schreibe ich nach wie vor lieber selbst, weil ich meinen eigenen Denkprozess kenne und verstehe, warum jeder Teil funktioniert. KI darf helfen. Die eigentliche Arbeit machen weiterhin Entwickler, die Erfahrung, Wissen und Urteilsvermögen mitbringen.

Footnotes

1. Sida Peng, Eirini Kalliamvakou, Peter Cihon und Mert Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv:2302.06590, Februar 2023, https://arxiv.org/abs/2302.06590

2. Kevin Zheyuan Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng und Tobias Salz, The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers, Arbeitspapier, Februar 2025 (erschienen in Management Science), https://economics.mit.edu/sites/default/files/inline-files/draft_copilot_experiments.pdf

3. Joel Becker, Nate Rush, Elizabeth Barnes und David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, arXiv:2507.09089, Juli 2025, https://arxiv.org/abs/2507.09089

4. METR, We are Changing our Developer Productivity Experiment Design, 24. Februar 2026, https://metr.org/blog/2026-02-24-uplift-update/

5. Stack Overflow, 2025 Developer Survey, Abschnitt AI, 2025, https://survey.stackoverflow.co/2025/ai

6. Stack Overflow, 2026 Developer Survey, Abschnitt AI, 2026, https://survey.stackoverflow.co/2026/ai