KI hat Software Engineering nicht einfacher gemacht. Sie hat die schweren Teile schwerer gemacht.

Dieser Beitrag basiert auf dem Artikel „AI Didn’t Make Software Engineering Easier. It Made the Hard Parts Harder.” von Praveen Rajamani. Den Originalartikel findest du unter dev.to/iampraveen.

Praveen beschreibt eine Erfahrung, die ich aus meinem eigenen Alltag nur bestätigen kann. Die KI-Tools liefern echte Produktivitätsgewinne. Gleichzeitig steigt die kognitive Belastung auf ein Niveau, das auf Dauer nicht tragbar ist. Sein Text trifft einen Nerv, weil er das ausspricht, was viele von uns spüren, aber selten artikulieren.

Der Job war zu 80 Prozent Ausführung und zu 20 Prozent Denken

Über Jahrzehnte verteilte sich die Arbeit eines Softwareentwicklers in einem relativ stabilen Verhältnis. Rund 80 Prozent entfielen auf die Ausführungsebene. Boilerplate schreiben. Repetitive Bugs fixen. Tickets verschieben. Konfigurationen aufsetzen. Tests für bekanntes Verhalten verfassen. Diese Arbeit war notwendig, aber erlernbar. Sie war das Handwerk.

Die verbleibenden 20 Prozent waren die eigentlich anspruchsvolle Arbeit. Das tatsächliche Problem verstehen. Systeme unter realen Einschränkungen entwerfen. Edge Cases debuggen, die niemand vorhergesehen hat. Entscheidungen mit unvollständiger Informationslage treffen. Wissen, was man nicht bauen sollte.

In diesen 20 Prozent lag der Unterschied zwischen einem Junior und einem Senior Entwickler. Es ging nicht um Tippgeschwindigkeit. Es ging um Klarheit im Denken.

KI hat die 80 Prozent gefressen. Jetzt sind die 20 Prozent der ganze Job.

Tools wie Claude Code, Cursor und GitHub Copilot sind herausragend auf der Ausführungsebene. Boilerplate ist Geschichte. Standard-CRUD-Endpoints entstehen in Sekunden. Repetitive Tests generieren sich quasi von selbst. Die Narrative war entsprechend optimistisch: Entwickler werden von langweiliger Arbeit befreit und können sich endlich auf interessante Probleme konzentrieren.

In einem gewissen Sinne stimmt das auch. Aber was niemand laut ausgesprochen hat, ist der eigentliche Preis dieser Verschiebung.

Die 20 Prozent waren genau deshalb schwer, weil sie anhaltenden, tiefen Fokus erforderten. Jetzt wird von Entwicklern erwartet, dauerhaft in diesem Modus zu arbeiten. Das menschliche Gehirn ist dafür schlicht nicht gebaut.

Drei Stunden Boilerplate schreiben ist ermüdend. Aber das Gehirn erholt sich davon relativ schnell. Drei Stunden lang die Fehlermodi eines verteilten Systems durchdenken, architektonische Trade-offs abwägen und eine Race Condition debuggen, die nur unter spezifischer Last auftritt. Das ist eine völlig andere Art von Erschöpfung. KI reduziert nicht, wie oft man das tun muss. Sie erhöht es massiv.

Das menschliche Kontextfenster wächst nicht

In der KI-Welt dreht sich eine permanente Diskussion um Kontextfenster. Wie viele Tokens kann das Modell halten? Wie optimieren wir den Retrieval-Prozess? Wie stellen wir sicher, dass das Modell zur richtigen Zeit die richtigen Informationen hat?

Alles valide Engineering-Probleme. Aber es gibt ein Kontextfenster, über das niemand spricht.

Das Kontextfenster des menschlichen Entwicklers wächst nicht. Es ist dasselbe Gehirn wie immer. Nur wird von ihm jetzt erwartet, mehr architektonische Komplexität zu halten, schnellere Entscheidungen unter Unsicherheit zu treffen und häufiger zwischen Systemen zu wechseln als je zuvor. Im Gegensatz zum Modell kann man beim menschlichen Gehirn kein Upgrade auf ein längeres Kontextfenster durchführen. Man kann dem präfrontalen Cortex kein zusätzliches RAM hinzufügen.

Praveen zitiert einen Google Staff Engineer, der viral ging, weil er das Unternehmen verließ. Nicht wegen Bezahlung oder Vergünstigungen. Sondern weil die Arbeit gehetzt und weniger sinnvoll geworden war. Er wurde um zwei Uhr nachts geweckt und konnte bis fünf oder sechs Uhr nicht mehr einschlafen. Das ist kein Produktivitätsproblem. Das ist ein Problem der kognitiven Belastung. Und es wird zur Norm statt zur Ausnahme.

Mehr Output bedeutet nicht weniger Arbeit

Praveen beschreibt die Situation aus eigener Erfahrung. Er arbeitet täglich mit KI-Tools über mehrere Projekte hinweg. Die Produktivitätsgewinne sind real. Er liefert schneller als je zuvor. Aber die kognitive Last ist ebenfalls höher als je zuvor.

Jede Stunde, die er bei der Ausführung einspart, fließt direkt zurück in härteres Denken. Er verbrachte kürzlich einen kompletten Nachmittag mit einer einzigen architektonischen Entscheidung. Es ging darum, wie Shared State über mehrere Produkte in einem Monorepo gehandhabt werden sollte. Diese Entscheidung hätte früher Tage gedauert, weil die umgebende Ausführungsarbeit natürliche Denkzeit erzeugte. Jetzt ist die Ausführung sofort erledigt. Die Denkzeit muss bewusst eingeplant werden oder sie findet schlicht nicht statt.

Er schreibt nicht weniger Code. Er trifft mehr Entscheidungen. Und Entscheidungen sind der teure Teil.

Ich erkenne mich darin vollständig wieder. Die alten Routineaufgaben waren nicht nur Arbeit. Sie waren unbewusste Erholungsphasen für das Gehirn. Ein Kontextwechsel von Systemdesign zu einer simplen Konfigurationsaufgabe war kognitive Regeneration in Verkleidung. Diese Regeneration ist jetzt verschwunden. Dieses Phänomen trägt dazu bei, dass sich unser kognitives Lernverhalten im Umgang mit KI verschlechtert, da wir der mentalen Anstrengung des Codens ausweichen.

Die versteckte Gefahr der Verständnisschuld

Praveen schildert ein konkretes Beispiel, das die Gefahr von blindem KI-Vertrauen verdeutlicht. Er ließ die KI eine komplette Data-Fetching-Schicht für eines seiner Produkte generieren. Der Code sah sauber aus. Er bestand die flüchtige Prüfung. Er wurde deployed.

Drei Wochen später traf er auf einen Caching-Bug, den er nicht debuggen konnte. Der Grund war einfach: Er hatte nie wirklich verstanden, wie diese Schicht funktionierte. Er verbrachte zwei Tage mit der Behebung eines Problems, das zwei Stunden gekostet hätte, wenn er den Code selbst geschrieben hätte.

Das ist das Konzept der Verständnisschuld. Sie ist das Gegenstück zur technischen Schuld. Technische Schuld betrifft den Code. Verständnisschuld betrifft den Entwickler. Und sie zeigt sich immer zum ungünstigsten Zeitpunkt. Die so entstehende Verständnisschuld ist das direkte Ergebnis der Falle des agentischen Codings, bei der man schleichend das tiefere Verständnis über das System verliert.

Dieses Muster beobachte ich auch in Gesprächen mit anderen Entwicklern. Wer generierten Code akzeptiert, ohne ihn tiefgehend zu verstehen, baut eine unsichtbare Zeitbombe in sein Projekt ein. Die Explosion kommt nicht bei der Implementierung. Sie kommt bei der ersten unerwarteten Situation.

Was das praktisch bedeutet

Praveen formuliert vier konkrete Handlungsempfehlungen, die ich für essenziell halte.

Deep Work aktiver schützen als je zuvor. Wenn KI die oberflächliche Arbeit erledigt, werden oberflächliche Unterbrechungen proportional schädlicher. Eine Slack-Benachrichtigung, die vorher zehn Minuten gekostet hat, kostet jetzt eine architektonische Entscheidung. Praveen blockt jeden Morgen zwei Stunden, bevor er irgendein KI-Tool öffnet. Ich halte das für den wichtigsten Ratschlag in seinem gesamten Artikel.

Sich daran gewöhnen zu sagen: Ich muss darüber nachdenken. Die Geschwindigkeit der KI erzeugt Druck, schneller zu entscheiden. Dem muss man widerstehen. Die Aussage „Lass mich das in Ruhe durchdenken” als professionelle Antwort zu behandeln und nicht als Eingeständnis von Langsamkeit ist eine der am meisten unterschätzten Fähigkeiten derzeit.

Kognitive Erholung als Teil der Arbeit betrachten. Die alten 80 Prozent gaben dem Gehirn natürliche Pausen. Der Wechsel von Tiefenarbeit zu Routineausführung war versteckte Regeneration. Diese Ruhe ist weg. Bewusst nach intensiven Denksessions eine niedrigschwellige Aufgabe einzuplanen, macht einen echten Unterschied.

Wissen, wann man KI nicht benutzt. Manchmal ist langsames Coden genau das, was einem hilft, das System zu verstehen. Die Versuchung, alles generieren zu lassen, ist groß. Aber Verständnis entsteht durch eigenes Schreiben. Nicht durch Lesen von generiertem Code.

Die offene Frage für unsere Branche

KI ersetzt keine Ingenieure. Sie komprimiert die Timeline von allem, was ein Ingenieur tun muss. Ob das ein Geschenk oder eine Last ist, hängt vollständig davon ab, wie bewusst man mit dem umgeht, was übrig bleibt.

Die eigentlich kritische Frage betrifft die nächste Generation. Die 20 Prozent, die jetzt den ganzen Job ausmachen. Systemdesign, Trade-offs, Debugging unter Unsicherheit, das Wissen, was man nicht bauen sollte. All das brauchte bisher Jahre der Entwicklung. Junior Entwickler bauten diese Fähigkeiten schrittweise auf. Die Grundlage dafür lieferten genau jene 80 Prozent Ausführungsarbeit. Diese Grundlage verschwindet jetzt in rasantem Tempo.

Ich beobachte das in meinem eigenen Umfeld. Jüngere Entwickler produzieren beeindruckenden Output. Aber wenn etwas nicht funktioniert, fehlt ihnen oft das fundamentale Verständnis, das man nur durch eigenes Scheitern und eigenes Lösen entwickelt. Die KI kann ihnen zeigen, wie etwas gemacht wird. Sie kann ihnen nicht beibringen, warum.

Praveen stellt die richtige Frage: Ist die Arbeit seit der Ankunft der KI-Tools anspruchsvoller oder genuinely einfacher geworden? Und was passiert mit den Junior Entwicklern? Bekommen sie die Grundlagen, die sie brauchen? Oder werden sie ins tiefe Wasser geworfen, bevor sie schwimmen können?

Meine Antwort ist klar. Die Arbeit ist anspruchsvoller geworden. Deutlich anspruchsvoller. Und wir als Branche haben noch keine gute Lösung dafür, wie wir die nächste Generation unter diesen neuen Bedingungen ausbilden. Das ist die eigentliche Herausforderung, die KI dem Software Engineering gebracht hat. Nicht weniger Arbeit. Andere Arbeit. Härtere Arbeit. Und weniger Zeit, sich darauf vorzubereiten.