Warum AI Coding noch kein Software Engineering ist

„In fünf Jahren schreibt KI die Software selbst.“ Der Satz klingt gewagt, ist aber vor allem ungenau: Er setzt Code schreiben mit Software entwickeln gleich. Wer den Entwicklungsprozess einmal in seine Tätigkeiten zerlegt, sieht schnell, welcher Anteil tatsächlich betroffen ist – und welcher durch KI eher zunimmt.

1. Die These und ihr Fehler

Codegenerierung ist eine Tätigkeit. Software Engineering ist die Disziplin, innerhalb derer diese Tätigkeit stattfindet: Anforderungen klären, Struktur festlegen, Schnittstellen vereinbaren, implementieren, prüfen, ausliefern, betreiben, ändern. Ein Modell, das Implementierung übernimmt, verändert einen Schritt dieser Kette sehr stark – und lässt die anderen weitgehend unberührt.

Das ist kein Argument gegen KI. Es ist ein Argument gegen die falsche Erwartung, aus der falsche Planung folgt: zu optimistische Angebote, zu dünn besetzte Reviews, zu späte Architekturarbeit.

2. Der Prozess in acht Tätigkeiten

Die folgende Aufstellung ist bewusst grob. Sie reicht aber, um die Frage beantwortbar zu machen, welche Anteile ein Coding Agent wirklich adressiert:

3. Was sich tatsächlich verschiebt

Der interessante Effekt steht nicht in der Zeile „Implementieren“, sondern zwei Zeilen darunter. Wenn Implementierung billiger wird, steigt das Prüfvolumen – und Prüfen ist die einzige Tätigkeit in der Tabelle, die sich kaum automatisieren lässt, ohne genau das Vertrauen zu untergraben, das sie herstellen soll.

Der Engpass verschwindet also nicht, er wandert: von der Tastatur zum Review, von der Umsetzung zur Entscheidung. Teams, die das erkennen, investieren früh in automatische Quality Gates und in kleinere, prüfbare Änderungssätze. Teams, die es nicht erkennen, erleben nach wenigen Monaten eine paradoxe Situation: mehr Output, langsamere Auslieferung.

4. Die Rechnung, die selten aufgeht

Ein einfaches Rechenbeispiel macht das greifbar. Angenommen, Implementierung macht 30 % des Gesamtaufwands aus und wird um 60 % schneller. Der Nettoeffekt auf das Projekt liegt bei 18 %. Steigt gleichzeitig der Review-Aufwand von 10 % auf 15 %, bleiben rund 13 %. Das ist ein guter Wert – aber es ist nicht die Halbierung, mit der mancher kalkuliert.

Die Zahlen sind illustrativ und ersetzen keine eigene Messung. Entscheidend ist die Struktur der Rechnung: Der Effekt hängt am Anteil der Implementierung, nicht an der Geschwindigkeit des Modells. Wer den Effekt vergrößern will, muss deshalb am Anteil arbeiten – etwa indem wiederkehrende Basisarbeit gar nicht erst pro Projekt entsteht.

5. Verantwortung lässt sich nicht generieren

Software Engineering ist auch eine Zurechnungsfrage: Jemand steht dafür ein, dass ein System das tut, was zugesagt wurde. Ein Modell kann diese Zurechnung nicht übernehmen – nicht aus technischer Unzulänglichkeit, sondern weil Zurechnung eine soziale und vertragliche Kategorie ist.

Daraus folgen drei Konsequenzen für den Alltag:

• Wer einen Änderungssatz einreicht, verantwortet ihn vollständig – unabhängig davon, wie viel davon getippt wurde.
• „Das Modell hat es so vorgeschlagen“ ist keine Begründung, sondern eine Beschreibung des Vorgangs.
• Prüfschritte gehören nicht abgeschwächt, weil generierter Code plausibel aussieht. Plausibilität ist genau die Eigenschaft, die diese Modelle optimieren.

6. Was das für Teams bedeutet

Die naheliegende Schlussfolgerung – „wir brauchen weniger Junioren“ – ist gefährlich. Denn die Tätigkeiten, die bleiben, setzen genau die Erfahrung voraus, die man durch Implementieren erwirbt. Wer die Einstiegsstufe streicht, hat in fünf Jahren niemanden, der Architekturentscheidungen treffen und generierten Code fundiert prüfen kann.

Realistischer ist eine Verschiebung des Lernpfads: weniger Zeit mit Boilerplate, mehr Zeit mit Lesen, Prüfen, Modellieren und Debuggen. Das ist anspruchsvoller – und braucht bewusste Anleitung statt der impliziten Übung von früher.

7. Wann AI Coding wirklich reicht

Es gibt Fälle, in denen Codegenerierung tatsächlich fast den ganzen Prozess ersetzt – und es lohnt sich, sie zu benennen, statt sie zu bestreiten:

• Wegwerf-Werkzeuge: ein Skript, das einmal eine Datei umbaut und danach gelöscht wird.
• Prototypen zur Entscheidungsfindung, die nachweislich nicht in Produktion gehen – und auch nicht heimlich doch.
• Explorationen: „Wie würde das mit dieser Bibliothek aussehen?“ als Denkhilfe, nicht als Lieferung.

Der Unterschied ist nicht die Codequalität, sondern die Lebensdauer und die Zurechnung. Sobald jemand die Software betreibt, ändert oder darauf vertraut, greift der volle Prozess.

Typische Fehler

• Produktivitätsgewinn auf das Gesamtprojekt hochrechnen, statt auf den Implementierungsanteil.
• Review als Formalie behandeln, obwohl das Volumen gestiegen ist.
• Architekturarbeit nach hinten schieben, weil „der Code ja schon da ist“.
• Prototypen produktiv setzen, ohne den ausgelassenen Prozess nachzuholen.
• Einstiegspositionen streichen und damit die eigene Prüfkompetenz von morgen.

Checkliste: Erwartungen realistisch halten

Fazit

AI Coding ist ein sehr guter Werkzeugfortschritt und kein Ersatz für Engineering. Der Unterschied ist keine Frage der Modellqualität, sondern des Umfangs: Ein Modell erzeugt Lösungen für formulierte Probleme. Software Engineering beginnt davor – beim Formulieren – und endet lange danach, beim Betreiben und Ändern.

Für die Praxis heißt das: Nutzen Sie KI dort, wo sie stark ist, und investieren Sie den gewonnenen Aufwand genau dort, wo sie nichts beiträgt. Das ist die unspektakuläre, aber verlässliche Variante des Produktivitätsgewinns.