KI-Assistenten schreiben Code schnell. Dass daraus automatisch schnellere Projekte werden, ist jedoch nicht ausgemacht. Eine von t3n aufgegriffene Harvard-Analyse kommt zu dem Schluss, dass der Produktivitätseffekt von KI-Werkzeugen in der Praxis weitgehend verpufft – und zwar nicht beim Generieren, sondern beim Überprüfen des Ergebnisses.

Die Argumentation ist für alle nachvollziehbar, die schon einmal fremden Code übernommen haben: Was eine Maschine in Sekunden produziert, muss weiterhin ein Mensch lesen, verstehen, testen und verantworten. Der Engpass verschiebt sich damit von der Produktion zur Prüfung.

Der Engpass wandert, er verschwindet nicht

In klassischen Entwicklungsprozessen ist das Schreiben von Code nur ein Teil der Arbeit. Dazu kommen Abstimmung, Architekturentscheidungen, Tests, Code-Review – also die kollegiale Durchsicht von Änderungen vor der Übernahme in die Hauptversion – sowie Deployment und Betrieb.

Wenn KI-Werkzeuge nun deutlich mehr Codevorschläge in kürzerer Zeit liefern, wächst das Volumen, das durch diesen Prüfpfad muss. Mehr Zeilen bedeuten mehr Review-Aufwand. Und Review lässt sich schlechter parallelisieren als Codegenerierung, weil dafür Kontextwissen über das Projekt nötig ist.

Hinzu kommt ein qualitativer Unterschied: Eigener Code wird beim Schreiben verstanden, generierter Code muss nachträglich erschlossen werden. Das kostet kognitive Arbeit, die in Aufwandsschätzungen oft nicht auftaucht, weil sie früher schlicht nicht existierte.

Was das für Projektbudgets heißt

Für Auftraggeberinnen und Auftraggeber ist die Konsequenz unbequem, aber nützlich: Ein Werkzeug allein senkt die Kosten nicht. Entscheidend ist, ob der umgebende Prozess den zusätzlichen Output verarbeiten kann.

Praktisch heißt das, bei der Projektplanung einige Fragen früh zu klären:

  • Wer prüft generierten Code, und mit welchem Zeitbudget?
  • Welche Testabdeckung existiert, damit Fehler automatisiert auffallen statt manuell?
  • Gibt es verbindliche Regeln, welche Codeteile überhaupt KI-gestützt entstehen dürfen – etwa nicht in sicherheitskritischen oder stark regulierten Bereichen?
  • Wie wird dokumentiert, welche Teile eines Systems wie entstanden sind?

Wo diese Fragen beantwortet sind, kann KI-Unterstützung Routinearbeit abnehmen. Wo sie offen bleiben, entsteht ein Rückstau: viel Material, wenig geprüfte Substanz.

Ein zweiter Blickwinkel: LLMs im Betrieb

Dass der Nutzen stark vom Einsatzszenario abhängt, zeigt ein Praxistest von Golem.de zum Thema Monitoring. Monitoring-Anbieter bewerben KI-gestützte Root-Cause-Analyse – also das automatische Auffinden der eigentlichen Fehlerursache hinter einer Störung – teilweise mit sehr großen Versprechen.

Der Test geht der Frage nach, wie weit man stattdessen selbst kommt, wenn man ein großes Sprachmodell (LLM) direkt mit Logauszügen verknüpft, also mit den Protokolldateien, die Systeme im Betrieb erzeugen. Der Ansatz ist bewusst bodenständig: kein Produktversprechen, sondern eine überprüfbare Anwendung an echten Daten.

Beide Quellen zeigen dasselbe Muster aus zwei Richtungen. Die Harvard-Analyse beschreibt, warum pauschale Produktivitätsversprechen beim Codeschreiben nicht aufgehen. Der Monitoring-Test prüft, wo ein konkret eingegrenzter Anwendungsfall tatsächlich trägt. Gemeinsam ist beiden die Skepsis gegenüber dem Automatismus, dass KI-Einsatz gleich Zeitgewinn sei.

Der Unterschied zwischen Generieren und Einordnen

Ein interessanter Punkt: Beim Troubleshooting ist die Aufgabe des Modells eine andere als beim Codeschreiben. Es produziert keinen Artefakt, der dauerhaft im System verbleibt und gewartet werden muss, sondern es hilft beim Sortieren und Interpretieren vorhandener Informationen.

Fehlinterpretationen fallen in diesem Szenario schneller auf, weil die Hypothese des Modells unmittelbar am laufenden System überprüft werden kann. Im Code dagegen können Mängel lange unentdeckt bleiben und erst im Betrieb oder bei der nächsten Änderung sichtbar werden.

Daraus lässt sich eine vorsichtige Faustregel ableiten: KI-Unterstützung wirkt dort am verlässlichsten, wo das Ergebnis sofort und günstig überprüfbar ist. Je teurer die Prüfung, desto geringer der Nettogewinn.

Empfehlungen für die Projektpraxis

Für laufende und geplante Vorhaben lassen sich daraus einige Schritte ableiten:

  1. KI-Einsatz nicht pauschal, sondern pro Aufgabentyp bewerten – Boilerplate, Tests und Analysearbeit verhalten sich anders als Kernlogik.
  2. Review-Kapazität mitplanen, statt sie als Restgröße zu behandeln.
  3. Automatisierte Tests und statische Codeanalyse ausbauen, damit Prüfung skaliert.
  4. Messen statt glauben: Durchlaufzeiten und Fehlerraten vor und nach Einführung vergleichen.
  5. Produktversprechen von Anbietern an eigenen Daten testen, bevor Lizenzbudgets gebunden werden.

Einordnung

Für Web- und Softwareprojekte heißt das: KI verändert die Verteilung der Arbeit, nicht ihre Gesamtmenge – zumindest nicht automatisch. Wer Budget sparen will, investiert zuerst in Qualitätssicherung, Testabdeckung und klare Review-Prozesse, denn genau dort entscheidet sich, ob schneller generierter Code auch schneller produktiv geht. Und wer KI-Funktionen von Anbietern einkauft, sollte sie an einem eigenen, abgegrenzten Anwendungsfall prüfen, bevor er sie zur Grundlage der Projektplanung macht.

Quellen