Ich schreibe diese Zeilen nicht als aktiver Entwickler.

Ich habe lange in der Welt des Codes gearbeitet und bin dann auf die andere Seite gewechselt, ins Product Management. Ich arbeite weiterhin mit Entwicklern, ich sehe ihre Zwänge, ihre Werkzeuge, ihre Abwägungen und auch ihre Müdigkeit. Und obwohl Entwicklung nicht mehr mein Hauptberuf ist, komme ich nicht umhin, mich zu fragen, wie sich die Softwareberufe mit KI verändern werden.

Dieser Text ist deshalb keine endgültige Wahrheit. Er ist die Sicht eines neugierigen, etwas beunruhigten Beobachters, der genug Code gesehen hat, um bestimmte schwache Signale zu spüren, und der die Softwareproduktion heute vom Produkt her betrachtet. Ein Product Manager, der die Neugier darauf verliert, wie Produkte entstehen, macht seinen Beruf wahrscheinlich nicht mehr richtig.

Seit einiger Zeit spiele ich mit Entwicklungsassistenten herum. Ich habe Skripte generiert, kleine Projekte vorangebracht und dann ernsthafter an einer Anwendung gearbeitet. Der Befund ist beeindruckend und beunruhigend zugleich: KI kann enorm viel produzieren, und das sehr schnell. In wenigen Tagen entsteht etwas, das wie eine echte Anwendung aussieht.

Aber die ganze Zeit über habe ich auch erhebliche Energie darauf verwendet, sie zu korrigieren.

Nicht nur in Details. In Grundlagen. Dateien, die zu groß werden. Fehlende Tests. Fachlogik, die in den APIs liegt. Architekturentscheidungen, die für den Bedarf zu kompliziert sind. Lösungen, die heute funktionieren, morgen aber brüchig werden können. Das Merkwürdigste daran: Wenn ich sie ausdrücklich bitte, es anders zu machen, kann sie es. Sie kann Tests schreiben. Sie kann die Fachdomäne von der technischen Infrastruktur trennen. Sie kann eine einfachere Lösung vorschlagen. Sie kann einräumen, dass es eine bessere Möglichkeit gibt.

Sie weiß es. Aber sie tut es nicht immer von selbst.

Und genau da wird die Sache interessant.

KI hat die Fehlentwicklungen der Software nicht erfunden

Fangen wir fair an: Die KI hat die technischen Schulden nicht erfunden. Sie hat das Over-Engineering nicht erfunden. Sie hat weder widersprüchliche Architekturen erfunden noch vergessene Tests, implizite Entscheidungen, schlecht abgesteckte Produkte oder Neuentwicklungen, die man zu lange vor sich herschiebt.

All das gab es längst.

Manche Entwickler konnten schon vorher eine Kathedrale bauen, um ein Regal anzubringen. Manche Teams konnten schon vorher langsam gegen die Wand fahren. Manche Unternehmen konnten schon vorher Delivery-Geschwindigkeit mit echtem Wert verwechseln. Das Problem der Software bestand nie nur darin, Code zu schreiben. Es bestand immer darin, etwas herzustellen, das hält, das sich verstehen lässt, das sich warten lässt, das sich weiterentwickelt und einer echten Nutzung dient.

Die KI schafft also kein völlig neues Problem. Sie verändert seinen Maßstab.

Sie beschleunigt, was ohnehin schon zu schnell lief. Sie macht unsichtbarer, was ohnehin schon schlecht verstanden war. Sie erlaubt es, schneller Entscheidungen aufeinanderzustapeln, die niemand wirklich getroffen hat. Sie verleiht Systemen eine Art äußerliche Reife, obwohl diese die normalen Reifungsschritte noch gar nicht durchlaufen haben.

Die Gefahr liegt nicht darin, dass KI Code schreibt. Die Gefahr liegt darin, dass sie es erlaubt, Systeme zu produzieren, die wie Prototypen gepflegt werden — von Menschen, die nicht immer die Erfahrung gesammelt haben, um zu wissen, wo diese Systeme brechen werden.

Die Illusion von Reife

Vibe coding erzeugt ein berauschendes Gefühl: Man fragt, der Code erscheint, die Anwendung kommt voran. Wo es früher mehrere Tage dauerte, manchmal mehrere Wochen, genügen jetzt ein paar Stunden. Der psychologische Effekt ist sehr stark. Man sieht Bildschirme. Man klickt. Es antwortet. Eine Datenbank ist da. Eine API läuft. Funktionen tauchen auf.

Das Produkt scheint zu reifen.

Aber was wirklich reift, ist manchmal vor allem die Oberfläche.

Eine Anwendung kann funktionieren, ohne wirklich verstanden zu sein. Sie kann ein paar glückliche Pfade durchlaufen, ohne robust zu sein. Sie kann für eine Demo reichen, ohne produktionsreif zu sein. Sie kann Hunderte technischer Entscheidungen enthalten, die niemand erklären kann, weil sie generiert, übernommen, gepatcht und dann vergessen wurden.

Vor der KI gab es einen Teil dieser Brüchigkeit schon. Aber sie hatte oft eine natürliche Grenze: die Langsamkeit. Code zu produzieren kostete Zeit. Diese Langsamkeit erzwang manchmal Gespräche, Abwägungen, Reviews — Momente, in denen man verstehen musste, was man tat, bevor es weiterging.

Mit KI fällt diese Grenze weg.

Man kann sehr viel schneller vorankommen, als man versteht. Zum Erkunden ist das nützlich. Gefährlich wird es, sobald man Erkundung und Produktion verwechselt.

Wenn der Fehler zu spät kommt, lehrt er nichts mehr

Ein großer Teil der technischen Erfahrung entsteht im Fehler.

Nicht in jedem Fehler, natürlich. Man kann lange leiden, ohne etwas zu lernen. Schmerz allein bildet niemanden aus. Aber in der Entwicklung entsteht tiefes Lernen oft aus einer sehr konkreten Schleife: Man probiert, man irrt sich, man sucht, man versteht, man korrigiert — und behält etwas von dieser Korrektur.

Manchmal hängt man eine halbe Stunde fest. Manchmal einen Tag. Manchmal findet man die Lösung am selben Tag nicht, kommt am nächsten darauf zurück, und genau dieser Umweg schafft Erfahrung. Man lernt, schwache Signale im Code zu erkennen. Man lernt, dass eine zu einfache Lösung oft einen Preis verbirgt. Man lernt, dass ein Bug nicht nur ein Hindernis ist, sondern ein Stück des Systems, das sich sperrt und verstanden werden will.

Die KI kann diese Schleife durchbrechen.

Wenn ein Problem auftaucht, kann man ihr sagen: Sieh zu, wie du klarkommst, finde mir eine Lösung. Sie wird etwas finden. Vielleicht eine gute Lösung. Vielleicht eine schreckliche, aber funktionierende. In beiden Fällen gilt: Wer sich nicht die Zeit nimmt, es zu verstehen, kommt voran, ohne zu lernen.

Das Risiko besteht nicht nur darin, dass der Fehler sich verzögert. Es besteht darin, dass er in einer Größenordnung auftritt, in der er sich nicht mehr analysieren lässt. Das System ist gewachsen. Die Schichten haben sich gestapelt. Die Entscheidungen sind implizit. Die Tests bestätigen, wenn es sie gibt, vielleicht ein falsches Verständnis des Bedarfs. Und wenn alles zusammenbricht, weiß niemand mehr genau, warum.

Also patcht man.

Man versteht deshalb nicht besser. Man klebt nur einen weiteren Flicken auf eine Architektur, in der man nie wirklich zu Hause war.

Der Kern des Problems: Die erste Stufe verschwindet

Das ist wahrscheinlich der Punkt, der mich am meisten beunruhigt.

Es geht nicht nur um die Frage, ob die KI Junior-Entwickler ersetzen wird. Diese Frage ist wichtig, aber sie verdeckt eine tiefere: Was passiert, wenn die KI die Aufgaben ersetzt, die Junioren überhaupt erst hervorbrachten?

In vielen Teams verlief das Lernen in Abstufungen. Es gab einen Lead, erfahrene Entwickler, mittlere Profile und dann Junioren. Man übergab einem Junior nicht sofort die gesamte Architektur eines kritischen Produkts. Man gab ihm kleine Aufgaben. Einen begrenzten Bug. Einen einfachen Endpunkt. Ein Skript. Eine Korrektur. Einen Test. Ein bescheidenes Refactoring.

Diese Aufgaben waren nicht nur Arbeit, die zu erledigen war. Sie waren die ersten Stufen der Treppe.

An ihnen konnte man sich die Zähne ausbeißen, ohne das ganze System zu gefährden. An ihnen lernte man, vorhandenen Code zu lesen, ein Ticket zu verstehen, um Hilfe zu bitten, ein Review anzunehmen, zu entdecken, dass eine lokale Änderung anderswo Wirkung zeigt. Sie erlaubten es, Schritt für Schritt in den Beruf hineinzuwachsen.

Und genau diese Aufgaben automatisiert die KI am besten.

Boilerplate, kleine Skripte, einfache Korrekturen, Standardtests, offensichtliche Integrationen: All das lässt sich sehr schnell generieren. Für die unmittelbare Produktivität ist das eine ausgezeichnete Nachricht. Für die Ausbildung ist es sehr viel zweideutiger.

Wenn die ersten Stufen verschwinden — wie wird man dann Senior?

Man kann antworten, dass Junioren eben anders lernen werden, mit der KI als sokratischem Tutor. Möglich. Ein guter Umgang mit KI kann helfen, zu erklären, zu vergleichen, zum Formulieren zu zwingen, Übungen zu generieren, ein Code-Review zu simulieren. Aber diese Möglichkeit verlangt Disziplin, Neugier und einen Rahmen. Sie verlangt außerdem, dass das Unternehmen bereit ist, Lernzeit zu bezahlen.

Und genau da wird die wirtschaftliche Frage brutal.

Wenn ein durch KI verstärkter Senior zehnmal mehr produziert: Wie viele Unternehmen werden noch hinnehmen, dass ein Junior zehnmal langsamer ist, weil er lernen muss? Wie viele werden hinnehmen, dass jemand einen Tag an einem Problem sitzt, das die KI in wenigen Minuten umgeht? Wie viele werden die Langsamkeit bewahren, die Ausbildung braucht, während der Markt zu immer schnellerer Auslieferung drängt?

Das Risiko ist, den Reproduktionszyklus des Handwerks zu durchbrechen.

Softwareunternehmen brauchen nicht nur Code. Sie brauchen Menschen, die diagnostizieren, vereinfachen, warten, absichern, abwägen und erfinden können. Solche Menschen entstehen aber nicht dadurch, dass man einen Assistenten steuert. Sie entstehen über Jahre der Praxis, der Fehler, der Reviews, der schwierigen Entscheidungen und der Rückmeldungen aus der Realität.

Wenn die KI die vorhandenen Seniors verstärkt, aber die Ausbildung der Junioren schwächt, bedroht sie nicht nur ein paar Einstiegsstellen. Sie bedroht die künftige Fähigkeit der Softwareunternehmen, gute Software herzustellen.

Wer wird die nächsten guten Praktiken erfinden?

Man redet über gute Praktiken oft so, als bildeten sie einen festen Bestand. Man müsste sie nur dokumentieren, in Direktivendateien für die KI legen und die Assistenten dann bitten, sie anzuwenden.

Aber gute Praktiken sind nichts Festes.

Sie entstehen, wenn sich das Terrain verändert. Die klassischen Design Patterns waren die Antwort auf eine bestimmte Softwarewelt. Dann brachten Cloud, verteilte Systeme, Asynchronität, Microservices und ereignisgetriebene Architekturen andere Probleme hervor. Man musste neue Denkweisen erfinden: Idempotenz, Retries, Circuit Breaker, Sagas, Observability, verteilte Resilienz.

Diese Praktiken sind nicht entstanden, weil jemand sie bei einem Werkzeug bestellt hätte. Sie sind aus realen Systemen entstanden, aus Ausfällen, aus Vorfällen, aus schwierigen Migrationen, aus Betriebszwängen, aus schmerzhaften Kompromissen.

Die KI wird wahrscheinlich helfen können, die nächsten Patterns zu formulieren. Sie wird Lösungen vergleichen, Wiederholungen erkennen und aufkommende Praktiken dokumentieren können. Aber wird sie sie allein erfinden können, bevor das Terrain sie notwendig und verständlich gemacht hat?

Ich bin mir nicht sicher.

Um eine gute Praxis zu erfinden, reicht es nicht, die alten zu kennen. Man muss spüren, warum sie nicht mehr genügen. Man muss dem Widerstand der Realität ausgesetzt gewesen sein. Man muss wissen, wann ein Pattern eine elegante Antwort ist und wann es nur unnötige Komplexität bedeutet.

Die Einfachheit selbst ist eine Senior-Kompetenz.

Eine KI kann eine zu komplexe Lösung vorschlagen und sofort einräumen, dass eine einfachere besser wäre, sobald man sie darauf hinweist. Aber dazu braucht es jemanden, der es sieht. Jemanden, der sagt: Dieses Problem rechtfertigt diese Architektur nicht. Jemanden, der die weniger brillante, aber passendere Lösung vorzieht.

Mehr produzieren — wozu?

Generierungsgeschwindigkeit ist nicht Auslieferungsgeschwindigkeit.

Ein Team kann morgens Dutzende Pull Requests vorfinden, die die KI über Nacht erstellt hat. Aber wer liest sie durch? Wer prüft die Auswirkungen? Wer versteht die Entscheidungen? Wer testet die Grenzfälle? Wer entscheidet, was wirklich in Produktion gehen soll? Wer stellt sicher, dass die Nutzer diese Komplexität verkraften?

Mehr Code zu produzieren heißt nicht zwangsläufig, mehr Wert zu produzieren.

Die Versuchung des Wettbewerbs liegt auf der Hand. Wenn ein Konkurrent ein Feature in drei Tagen herausbringt — wie soll man hinnehmen, dass ein Team drei Monate braucht? Wenn ein generierter Entwurf schnell zu Produktionscode werden kann — wer hat dann den Mut zu sagen: Halt, das ist noch nicht sauber genug?

Aber Software ist nicht nur ein Wettlauf um Menge. Ein Produkt wird schnell unlesbar, für seine Nutzer wie für seine Teams, wenn man Funktionen schneller hinzufügt, als man versteht, wofür sie genutzt werden. Komplexität misst sich nicht nur im Code. Sie misst sich auch in der Adoption, im Support, in der Dokumentation, in der Stimmigkeit der Erfahrung, in der Fähigkeit der Organisation, zu erklären, was sie eigentlich baut.

Die KI verschiebt also die Engpässe.

Der Code wird schneller. Aber Review, Sicherheit, fachliche Rahmung, Integration, Verständnis und menschliche Aufnahmefähigkeit bleiben begrenzt. Vielleicht werden sie sogar kritischer.

Rekonstruierbarkeit als Qualitätskriterium

In meiner eigenen jüngsten Arbeit mit ihr hat mich nicht nur beruhigt, eine Anwendung produziert zu haben. Beruhigt hat mich, Ankerpunkte durchgesetzt zu haben.

Ich habe auf den Verträgen zwischen den APIs bestanden. Ich habe die KI dazu gedrängt, erst die Testfälle und dann die Testpyramide zu erstellen, bevor überhaupt entwickelt wurde. Ich habe versucht, eine klare Trennung zwischen der Fachdomäne und der technischen Infrastruktur zu halten. So weit wie ein vollständiges DDD-Vorgehen bin ich nicht gegangen, weil das Projekt es nicht rechtfertigte — aber ich habe mich geweigert, die Fachlogik einfach über die Endpunkte zu verstreuen.

Warum?

Weil ein wirklich verstandenes System ein System ist, das man neu aufbauen könnte.

Wenn ich diese Anwendung morgen in eine andere Technologie überführen muss, weiß ich, wo die Verträge liegen, wo die Fachregeln liegen, wo die Tests liegen, die das erwartete Verhalten beschreiben. Perfekt ist nicht alles, aber das System ist nicht bloß ein Haufen generierter Code. Es hat Griffe. Orientierungspunkte. Trennlinien.

Vielleicht ist das ein zentrales Kriterium für die KI-gestützte Entwicklung: nicht nur zu fragen „Funktioniert es?“, sondern „Könnte ich es neu aufbauen?“

Lautet die Antwort Nein, dann fehlt etwas.

Schwierigkeit bewusst wieder einbauen

Man muss nicht nur lernen, mit KI zu entwickeln. Man muss manchmal auch ohne sie lernen.

Nicht aus Nostalgie. Nicht um ein heroisches Bild des Entwicklers zu verteidigen, der leiden muss, um seinen Beruf zu verdienen. Sondern weil eine Kompetenz, die nie auf Schwierigkeit trifft, brüchig wird.

Anderswo akzeptieren wir diesen Gedanken ohne Weiteres. In der Mathematik ist der Taschenrechner nützlich, aber wer nie selbst eine Rechnung aufschreibt, macht sich abhängig. Im Sport fügt man bewusst Zwänge hinzu, Gewicht, Widerstand, weil es dieser Widerstand ist, der die Muskeln aufbaut.

Die Entwicklung wird dieselbe Logik brauchen.

Dojos ohne KI. Übungen mit gedrosselter KI. Reviews, in denen man den Code selbst erklären muss, statt den Assistenten darum zu bitten. Momente, in denen man sich bewusst die Zeit nimmt, zu lesen, zu verstehen, zu vereinfachen.

Das Ziel ist nicht, überall langsamer zu werden. Das Ziel ist, an der richtigen Stelle langsamer zu werden.

Vielleicht müssen die Teams von morgen sich auf einen hybriden Rhythmus einlassen: einen Teil der Zeit sehr schnell produzieren, aber lange Zeitfenster dafür schützen, das Produzierte zu verstehen. Einen Tag für kontinuierliche Verbesserung. Momente allein vor dem Code. Architektur-Reviews. ADRs. Langsame Refactorings. Post-mortems einer misslungenen Generierung.

Schon vor der KI fehlte diese lange Zeit viel zu oft. Viele Entwickler waren im Tagesgeschäft gefangen und produzierten, ohne genug Abstand zu gewinnen, um dazuzulernen. Die KI kann das Problem verschärfen, wenn sie nur dazu dient, den gewonnenen Raum mit noch mehr Produktion zu füllen. Sie kann aber auch zur Chance werden, wenn sie uns zwingt, die Zeit des Machens und die Zeit des Verstehens klarer zu trennen.

Ein paar einfache Regeln, um die Kontrolle zu behalten

Wenn Teams KI nutzen wollen, ohne ihre Tiefe zu verlieren, werden sie wohl eine ausdrückliche Disziplin erfinden müssen. Keine Bürokratie. Eine Verständnishygiene.

Ein paar Regeln scheinen mir jetzt schon nützlich.

Erstens: keinen Code mergen, den niemand erklären kann. Das ist einfach, fast brutal, aber entscheidend. Wer unverstandenen Code annimmt, nimmt eine Verständnisschuld auf.

Zweitens: ein kleines Verständnisbudget pro Feature einplanen — den Vertrag, die Tests, die Architekturentscheidung, die bekannten Grenzen. Keine endlose Dokumentation. Gerade genug, damit die Überlegung von Mensch zu Mensch weitergegeben werden kann.

Außerdem muss man die Tests an die Fachlichkeit binden. Ein generierter Test kann sehr sauber sein und trotzdem ein falsches Verständnis des Bedarfs bestätigen. Die Schleife sollte lauten: Fachlichkeit, Tests, Code, zurück zur Fachlichkeit. Je genauer die Tests die erwartete Nutzung ausdrücken, desto größer die Chance, dass der Code nah am Wert bleibt.

Man muss eine Übersicht der vom Team zugelassenen Patterns pflegen. Wie baut man eine API? Wie behandelt man Fehler? Wie schreibt man einen asynchronen Job? Wie testet man einen externen Aufruf? Ohne das erfindet jedes generierte Feature seine eigene Vorgehensweise, und das Team wartet am Ende mehrere Architekturen ohne Grund.

Und schließlich muss man die Fehlschläge der KI auswerten. Wenn sie eine zu komplexe Lösung liefert, wenn sie die Tests vergisst, wenn sie Fachlogik an die falsche Stelle setzt, sollte man nicht nur korrigieren. Man sollte das verpasste Signal verstehen, die Direktiven nachschärfen, die Praktiken erweitern.

Die KI kann Code schreiben. Aber das Denken muss dem Team gehören.

Zehnmal besser verstehen

Ich glaube nicht, dass die Softwareentwicklung an der KI zugrunde geht.

Ich glaube aber, dass manche Teams in Code ertrinken werden, den sie nicht gut genug verstehen. Sie werden schnell produziert haben. Sie werden Sichtbares ausgeliefert haben. Sie werden ihren Markt vielleicht eine Zeit lang beeindruckt haben. Dann werden sie merken, dass Geschwindigkeit keine Architektur ersetzt, dass Tests nur etwas taugen, wenn sie den richtigen Bedarf ausdrücken, dass Sicherheit in den Grenzfällen wohnt, dass Legacy ein historisches Verständnis verlangt — und dass Seniors nicht entstehen, wenn man die Aufgaben abschafft, die Junioren hervorbrachten.

Es geht also nicht darum, die KI abzulehnen. Das wäre absurd. Sie ist zu nützlich, zu mächtig und längst zu präsent.

Es geht darum, ihr nicht die Mechanismen zu überlassen, die Kompetenz hervorbringen.

Wenn die KI uns erlaubt, zehnmal schneller zu produzieren, dann sollte sie uns auch zwingen, Zeit dafür freizuhalten, zehnmal besser zu verstehen, was wir produzieren. Sonst haben wir nicht nur die Softwareentwicklung beschleunigt. Wir haben auch das Vergessen dessen beschleunigt, was gutes Entwickeln möglich macht.