Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Ich schreibe diese Zeilen nicht als aktiver Entwickler.
Ich habe lange in der Welt des Codes gearbeitet, dann bin ich auf die andere Seite gewechselt, zum Product Management. Ich arbeite noch immer mit Entwicklern, sehe ihre Einschränkungen, ihre Tools, ihre Abwägungen, auch ihre Erschöpfung. Und auch wenn Entwicklung nicht mehr mein Hauptberuf ist, kann ich nicht umhin, mich zu fragen, wie sich die Softwareberufe mit KI verändern werden.
Dieser Text ist also keine endgültige Wahrheit. Er ist der Standpunkt eines neugierigen, etwas besorgten Beobachters, der den Code gut genug kennt, um bestimmte schwache Signale zu spüren, und der die Softwareproduktion jetzt von der Produktseite aus betrachtet. Ein Product Manager, der aufhört, neugierig auf die Art und Weise zu sein, wie Produkte hergestellt werden, hört wahrscheinlich auf, seinen Job richtig zu machen.
Seit einiger Zeit spiele ich mit Entwicklungsassistenten. Ich habe Skripte generiert, kleine Projekte vorangetrieben, dann ernsthafter an einer Anwendung gearbeitet. Und das Ergebnis ist sowohl beeindruckend als auch beunruhigend: KI kann enorm viel in sehr kurzer Zeit produzieren. In wenigen Tagen kann man etwas bekommen, das wie eine echte Anwendung aussieht.
Aber während dieser ganzen Zeit habe ich auch erhebliche Energie darauf verwendet, sie zu korrigieren.
Nicht nur bei Details. Bei Grundlagen. Dateien, die zu groß werden. Fehlende Tests. Fachlogik in den APIs. Zu komplexe Architekturentscheidungen für den Bedarf. Lösungen, die jetzt funktionieren, aber morgen fragil werden könnten. Das Merkwürdigste ist, dass die KI, wenn ich sie explizit bitte, anders vorzugehen, dazu in der Lage ist. Sie kann Tests schreiben. Sie kann die Fachdomäne von der Betriebsschicht trennen. Sie kann eine einfachere Lösung vorschlagen. Sie kann anerkennen, dass eine bessere Option existiert.
Sie weiß es. Aber sie tut es nicht immer spontan.
Und da wird das Thema interessant.
KI hat die Schwächen der Software nicht erfunden
Man muss fair beginnen: KI hat technische Schulden nicht erfunden. Sie hat Über-Engineering nicht erfunden. Sie hat widersprüchliche Architekturen, vergessene Tests, implizite Entscheidungen, schlecht gerahmte Produkte oder zu lange hinausgezögerte Refactorings nicht erfunden.
All das gab es schon.
Manche Entwickler konnten schon immer eine Kathedrale bauen, um ein Regal aufzuhängen. Manche Teams konnten schon immer langsam gegen die Wand fahren. Manche Unternehmen konnten schon immer Liefergeschwindigkeit mit echtem Wert verwechseln. Das Problem der Software war nie nur, Code zu schreiben. Es war immer, etwas zu produzieren, das hält, verständlich ist, wartbar ist, sich weiterentwickelt und einem echten Bedarf dient.
KI schafft also kein völlig neues Problem. Sie verändert seinen Maßstab.
Sie beschleunigt, was ohnehin schon zu schnell ging. Sie macht weniger sichtbar, was ohnehin schon schlecht verstanden war. Sie ermöglicht es, schneller Entscheidungen aufeinanderzustapeln, die niemand wirklich getroffen hat. Sie verleiht Systemen eine Art scheinbare Reife, die die normalen Reifungsstufen noch nicht durchlaufen haben.
Die Gefahr besteht nicht darin, dass KI Code schreibt. Die Gefahr besteht darin, dass sie es ermöglicht, Systeme zu produzieren, die wie Prototypen gewartet werden, von Personen, die nicht immer die nötige Erfahrung erworben haben, um zu wissen, wo diese Systeme brechen werden.
Die Reifungsillusion
Vibe coding vermittelt ein berauschendes Gefühl: Man fragt, der Code erscheint, die Anwendung schreitet voran. Wo es mehrere Tage, manchmal Wochen dauerte, genügen jetzt einige Stunden. Der psychologische Effekt ist sehr stark. Man sieht Bildschirme. Man klickt. Es reagiert. Eine Datenbank existiert. Eine API läuft. Funktionen erscheinen.
Das Produkt scheint zu reifen.
Aber was wirklich reift, ist manchmal vor allem die Oberfläche.
Eine Anwendung kann funktionieren, ohne wirklich verstanden zu werden. Sie kann einige glückliche Szenarien bestehen, ohne robust zu sein. Sie kann auf eine Demo reagieren, ohne produktionsreif zu sein. Sie kann Hunderte technischer Entscheidungen enthalten, die niemand erklären kann, weil sie generiert, akzeptiert, gepatcht und dann vergessen wurden.
Vor der KI existierte ein Teil dieser Fragilität bereits. 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 man weitermachte.
Mit KI fällt diese Grenze weg.
Man kann viel schneller voranschreiten als das eigene Verständnis. Das ist nützlich zum Erkunden. Es ist gefährlich, wenn man beginnt, Erkundung und Produktion zu verwechseln.
Wenn der Fehler zu spät kommt, lehrt er nichts mehr
Ein großer Teil der technischen Erfahrung entsteht im Fehler.
Nicht in irgendeinem Fehler, natürlich. Man kann lange leiden, ohne etwas zu lernen. Schmerz allein formt nicht. Aber in der Entwicklung kommt tiefes Lernen oft aus einer sehr konkreten Schleife: Man versucht, irrt sich, sucht, versteht, korrigiert, und behält dann etwas von dieser Korrektur.
Manchmal blockiert man eine halbe Stunde. Manchmal einen Tag. Manchmal findet man nicht am selben Tag, man kommt am nächsten Tag 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 widersteht und verstanden werden will.
KI kann diese Schleife zerbrechen.
Wenn ein Problem auftaucht, kann man ihr sagen: Kümmere dich darum, find mir eine Lösung. Sie wird etwas finden. Vielleicht eine gute Lösung. Vielleicht eine schreckliche, aber funktionierende Lösung. In beiden Fällen, wenn man sich nicht die Zeit nimmt zu verstehen, geht man voran ohne zu lernen.
Das Risiko ist nicht nur, dass der Fehler verzögert wird. Es ist, dass er in einem Ausmaß auftritt, wo er nicht mehr analysierbar ist. Das System ist gewachsen. Die Schichten haben sich gestapelt. Die Entscheidungen sind implizit. Die Tests, wenn sie existieren, validieren vielleicht ein falsches Verständnis des Bedarfs. Und wenn alles zusammenbricht, weiß man nicht mehr wirklich warum.
Also patcht man.
Man versteht es nicht besser. Man setzt nur einen weiteren Flicken auf eine Architektur, in der man nie wirklich heimisch war.
Der Kern des Problems: das Verschwinden der ersten Sprosse
Das ist wahrscheinlich der Punkt, der mich am meisten besorgt.
Es geht nicht nur darum zu wissen, ob KI Junior-Entwickler ersetzen wird. Diese Frage ist wichtig, aber sie verbirgt eine andere, tiefere: Was passiert, wenn KI die Aufgaben ersetzt, die die Junioren formten?
In vielen Teams erfolgte das Lernen durch Abstufung. Es gab einen Lead, erfahrene Entwickler, mittlere Profile, dann Junioren. Man vertraute einem Junior nicht sofort die vollständige Architektur eines kritischen Produkts an. 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 zu erledigende Arbeit. Sie waren die ersten Sprossen der Leiter.
Sie ermöglichten es, sich die Zähne auszubeißen, ohne das gesamte System zu gefährden. Sie ermöglichten es zu lernen, vorhandenen Code zu lesen, ein Ticket zu verstehen, um Hilfe zu bitten, ein Review zu empfangen, zu entdecken, dass eine lokale Änderung anderswo Auswirkungen haben kann. Sie ermöglichten einen progressiven Einstieg in den Beruf.
Und das sind genau die Aufgaben, die KI am besten automatisiert.
Den Boilerplate, die kleinen Skripte, die einfachen Korrekturen, die Standardtests, die offensichtlichen Integrationen: all das kann sehr schnell generiert werden. Aus Sicht der unmittelbaren Produktivität ist das eine ausgezeichnete Nachricht. Aus Sicht der Ausbildung ist das viel zweideutiger.
Wenn die ersten Sprossen verschwinden, wie wird man dann Senior?
Man kann antworten, dass die Junioren anders lernen werden, mit KI als sokratischem Tutor. Das ist möglich. Ein guter Einsatz von KI kann helfen zu erklären, zu vergleichen, zu verbalisieren, Übungen zu generieren, ein Code-Review zu simulieren. Aber diese Möglichkeit erfordert eine Disziplin, eine Neugier und einen Rahmen. Sie erfordert auch, dass das Unternehmen bereit ist, Lernzeit zu bezahlen.
Und dort wird die wirtschaftliche Frage brutal.
Wenn ein durch KI augmentierter Senior zehnmal mehr produziert, wie viele Unternehmen werden noch akzeptieren, dass ein Junior zehnmal langsamer geht, weil er lernen muss? Wie viele werden akzeptieren, dass jemand einen Tag mit einem Problem verbringt, das die KI in wenigen Minuten umgehen kann? Wie viele werden die für die Ausbildung notwendige Langsamkeit bewahren, während der Markt dazu drängt, immer schneller zu liefern?
Das Risiko besteht darin, den Reproduktionszyklus des Berufs zu zerbrechen.
Softwareunternehmen brauchen nicht nur Code. Sie brauchen Personen, die diagnostizieren, vereinfachen, warten, absichern, abwägen und erfinden können. Diese Personen entstehen aber nicht durch das einfache Steuern eines Assistenten. Sie werden durch Jahre der Praxis, der Fehler, der Reviews, der schwierigen Entscheidungen und der Rückmeldungen aus der Realität geformt.
Wenn KI die bestehenden Seniors augmentiert, aber die Ausbildung der Junioren schwächt, bedroht sie nicht nur einige Einstiegspositionen. Sie bedroht die zukünftige Fähigkeit der Softwareunternehmen, qualitativ hochwertige Software zu produzieren.
Wer wird die nächsten bewährten Praktiken erfinden?
Man spricht oft von bewährten Praktiken, als bildeten sie einen stabilen Bestand. Man müsste sie nur dokumentieren, in Direktivendateien für die KI einfügen und dann die Assistenten bitten, sie anzuwenden.
Aber bewährte Praktiken sind nicht unveränderlich.
Sie entstehen, wenn sich das Terrain verändert. Die klassischen Design-Patterns haben auf eine bestimmte Softwarewelt reagiert. Dann haben Cloud, verteilte Systeme, Asynchronität, Microservices, ereignisbasierte Architekturen andere Probleme entstehen lassen. Man musste neue Denkweisen erfinden: Idempotenz, Retries, Circuit Breaker, Sagas, Observierbarkeit, verteilte Resilienz.
Diese Praktiken sind nicht entstanden, weil jemand sie einfach von einem Tool angefordert hat. Sie sind aus echten Systemen, aus Ausfällen, Vorfällen, schwierigen Migrationen, Betriebszwängen und schmerzhaften Kompromissen entstanden.
KI wird wahrscheinlich helfen können, die nächsten Patterns zu formulieren. Sie wird Lösungen vergleichen, Wiederkehrendes 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?
Das bezweifle ich.
Um eine bewährte Praxis zu erfinden, reicht es nicht, die alten zu kennen. Man muss spüren, warum sie nicht mehr ausreichen. Man muss dem Widerstand der Realität ausgesetzt gewesen sein. Man muss wissen, wann ein Pattern eine elegante Antwort ist und wann er nur unnötige Komplexität ist.
Einfachheit selbst ist eine Senior-Kompetenz.
Eine KI kann eine zu komplexe Lösung vorschlagen, dann sofort anerkennen, dass eine einfachere Lösung besser ist, wenn man sie darauf hinweist. Aber dazu braucht es jemanden, der es sieht. Jemanden, der sagt: Dieses Problem verdient diese Architektur nicht. Jemanden, der eine weniger brillante, aber treffendere Lösung bevorzugt.
Mehr produzieren, wozu?
Die Generierungsgeschwindigkeit ist nicht die Liefergeschwindigkeit.
Ein Team kann Dutzende Pull Requests haben, die in der Nacht von KI erstellt wurden. Aber wer liest sie? Wer überprüft die Auswirkungen? Wer versteht die Entscheidungen? Wer testet die Randfälle? Wer entscheidet, was wirklich in die Produktion gehen soll? Wer stellt sicher, dass der Nutzer diese Komplexität absorbieren kann?
Mehr Code zu produzieren bedeutet nicht unbedingt, mehr Wert zu produzieren.
Es gibt eine offensichtliche Wettbewerbsversuchung. Wenn ein Konkurrent eine Funktion in drei Tagen herausbringt, wie kann man akzeptieren, dass ein Team drei Monate braucht? Wenn ein generierter Prototyp schnell zu Produktionscode werden kann, wer wird den Mut haben zu sagen: Halten wir inne, das ist noch nicht sauber genug?
Aber Software ist nicht nur ein Mengenwettbewerb. Ein Produkt wird schnell unlesbar — für seine Nutzer wie für seine Teams —, wenn man Funktionen schneller hinzufügt, als man ihren Einsatz versteht. Die Komplexität misst sich nicht nur im Code. Sie misst sich auch in der Adoption, dem Support, der Dokumentation, der Kohärenz der Erfahrung, der Fähigkeit der Organisation zu erklären, was sie herstellt.
KI verschiebt also die Engpässe.
Der Code wird schneller. Aber Review, Sicherheit, funktionale Rahmung, Integration, Verständnis und menschliche Absorption bleiben begrenzt. Vielleicht werden sie sogar kritischer.
Rekonstruierbarkeit als Qualitätskriterium
In meinem jüngsten eigenen Einsatz hat mich nicht nur beruhigt, eine Anwendung produziert zu haben. Es hat mich beruhigt, Ankerpunkte gesetzt zu haben.
Ich habe auf Verträgen zwischen APIs bestanden. Ich habe die KI dazu gebracht, die Testmengen, dann die Testpyramide zu produzieren, bevor sie entwickelte. Ich habe versucht, eine klare Trennung zwischen der Fachdomäne und der Betriebsschicht zu bewahren. Ich bin nicht bis zu einem vollständigen DDD-Ansatz gegangen, weil das Projekt das nicht rechtfertigte, aber ich habe abgelehnt, dass die Fachlogik einfach in den Endpunkten verteilt wird.
Warum?
Weil ein wirklich verstandenes System ein System ist, das man neu aufbauen könnte.
Wenn ich morgen diese Anwendung auf eine andere Technologie übertragen muss, weiß ich, wo die Verträge sind, wo die Fachregeln sind, wo die Tests sind, die das erwartete Verhalten beschreiben. Nicht alles ist perfekt, aber das System ist nicht nur ein Haufen generierter Code. Es enthält Griffe. Orientierungspunkte. Trennungslinien.
Das ist vielleicht ein zentrales Kriterium für KI-gestützte Entwicklung: nicht nur fragen „Funktioniert das?", sondern „Würde ich es neu aufbauen können?"
Wenn die Antwort Nein lautet, fehlt etwas.
Schwierigkeit bewusst einführen
Man muss nicht nur lernen, mit KI zu entwickeln. Man muss auch manchmal ohne sie lernen.
Nicht aus Nostalgie. Nicht um eine heroische Sicht des Entwicklers zu verteidigen, der leiden muss, um seinen Beruf zu verdienen. Sondern weil eine Kompetenz, die niemals auf Schwierigkeit trifft, fragil wird.
Man akzeptiert diese Idee anderswo sehr gut. In der Mathematik ist der Taschenrechner nützlich, aber ohne jemals selbst eine Operation zu rechnen macht man sich abhängig. Im Sport fügt man bewusst Einschränkungen, Gewicht, Widerstand hinzu, weil dieser Widerstand die Muskeln entwickelt.
Entwicklung wird dieselbe Logik brauchen.
Dojos ohne KI. Übungen mit eingeschränkter KI. Reviews, bei denen man den Code erklären muss, ohne den Assistenten darum zu bitten, es für einen zu tun. Momente, in denen man bewusst die Zeit nimmt zu lesen, zu verstehen, zu vereinfachen.
Das Ziel ist nicht, überall zu verlangsamen. Das Ziel ist, am richtigen Punkt zu verlangsamen.
Vielleicht müssen die Teams von morgen ein hybrides Tempo annehmen: einen Teil der Zeit sehr schnell produzieren, aber Zeit für das Verstehen dessen schützen, was produziert wurde. Einen Tag kontinuierlicher Verbesserung. Momente allein vor dem Code. Architektur-Reviews. ADRs. Langsame Refactorings. Post-Mortems von fehlgeschlagener Generierung.
Vor der KI fehlte diese lange Zeit ohnehin schon zu oft. Viele Entwickler blieben mit der Nase im Tagesgeschäft, produzierten ohne genug Abstand zu nehmen, um Kompetenz aufzubauen. KI kann dieses Problem verschlimmern, wenn sie nur dazu dient, den gewonnenen Raum mit noch mehr Produktion zu füllen. Aber sie kann auch zu einer Chance werden, wenn sie uns zwingt, die Zeit des Tuns und die Zeit des Verstehens besser zu unterscheiden.
Einige einfache Regeln, um die Kontrolle zu behalten
Wenn Teams KI nutzen wollen, ohne ihre Tiefe zu verlieren, werden sie wahrscheinlich eine explizite Disziplin erfinden müssen. Keine Bürokratie. Eine Verständnishygiene.
Einige Regeln scheinen mir bereits nützlich.
Zunächst: keinen Code mergen, den niemand erklären kann. Das ist einfach, fast brutal, aber wesentlich. Wenn ein Team unverstandenen Code akzeptiert, akzeptiert es eine Verständnisschuld.
Dann: ein kleines Verständnisbudget pro Funktion vorsehen — den Vertrag, die Tests, die Architekturentscheidung, die bekannten Grenzen. Keine endlose Dokumentation. Nur genug, damit das Denken menschlich übermittelbar bleibt.
Man muss auch die Tests mit dem Funktionalen verbinden. Ein generierter Test kann sehr sauber sein und ein falsches Verständnis des Bedarfs validieren. Die Schleife sollte sein: Funktional, Tests, Code, zurück zum Funktionalen. Je mehr Tests wirklich den erwarteten Einsatz ausdrücken, desto mehr Chancen hat der Code, nah am Wert zu bleiben.
Man muss eine Übersicht der vom Team erlaubten Patterns pflegen. Wie macht man eine API? Wie werden Fehler behandelt? Wie schreibt man einen asynchronen Job? Wie testet man einen externen Aufruf? Ohne das riskiert jede generierte Funktion, ihre eigene Vorgehensweise zu erfinden, und das Team wartet mehrere Architekturen ohne Grund.
Schließlich muss man die Fehler der KI analysieren. Wenn sie eine zu komplexe Lösung produziert, Tests vergisst oder die Fachlogik an der falschen Stelle platziert, sollte man nicht nur korrigieren. Man sollte das fehlende Signal verstehen, die Direktiven anpassen, die Praktiken bereichern.
KI kann Code schreiben. Aber das Team muss Eigentümer des Denkens bleiben.
Zehnmal besser verstehen
Ich glaube nicht, dass die Softwareentwicklung durch KI untergeht.
Ich glaube jedoch, dass manche Teams in Code ertrinken werden, den sie nicht gut genug verstehen. Sie werden schnell produziert haben. Sie werden sichtbare Dinge geliefert haben. Sie werden ihren Markt vielleicht eine Zeit lang beeindruckt haben. Dann werden sie entdecken, dass Geschwindigkeit Architektur nicht ersetzt, dass Tests nur dann etwas wert sind, wenn sie den richtigen Bedarf ausdrücken, dass Sicherheit in den Randfällen lebt, dass Legacy ein historisches Verständnis erfordert, und dass Seniors nicht gebildet werden, indem man die Aufgaben abschafft, die Junioren formten.
Der eigentliche Einsatz ist also nicht, KI abzulehnen. Das wäre absurd. Sie ist zu nützlich, zu mächtig, zu präsent bereits.
Der eigentliche Einsatz liegt darin, ihr nicht die Mechanismen zu überlassen, die Kompetenz produzieren.
Wenn KI uns ermöglicht, zehnmal schneller zu produzieren, sollte sie uns auch zwingen, Zeit dafür zu reservieren, zehnmal besser zu verstehen, was wir produzieren. Sonst haben wir nicht nur die Softwareentwicklung beschleunigt. Wir haben das Vergessen dessen beschleunigt, was es ermöglicht, gut zu entwickeln.
Weiterführendes
Code centric Qualität gehört denen, die liefern Zero Bugs: Hör auf, Defekt-Bestände zu verwalten