Entwickler-Skills im KI-Zeitalter beschreibt die Frage, welches Wissen Softwareentwicklerinnen und -entwickler noch brauchen, wenn Vibe-Coding und KI-generierter Code klassische Programmierkenntnisse ersetzen. Wer Systeme weder versteht noch bewertet, kann nicht erkennen, wenn sie im realen Einsatz versagen. Gefragt ist breites Systemverständnis kombiniert mit tiefem Wissen in mehreren Bereichen.
Das Wichtigste in Kürze
- Die Mittelschicht der Entwickler wird durch KI-Automatisierung wegbrechen, weil nur noch wenige Experten mit tiefem Systemverständnis und Agent-Orchestratoren gebraucht werden.
- Vibe-Coding löst das grundlegende Problem nicht: Wer nicht versteht, in welcher Umgebung Code läuft, kann nicht beurteilen, ob er auch unter realen Feldbedingungen funktioniert.
- Intrinsische Neugier, also das Bedürfnis, Systeme von innen zu verstehen statt nur anzuwenden, entscheidet darüber, ob jemand auch in einer KI-geprägten Welt kompetent bleibt.
- Ein T-Shape-Profil reicht für Senior-Rollen nicht mehr aus; gebraucht wird ein Pi-Shape mit mindestens zwei Fachtiefgängen und breitem Überblick darüber hinaus.
Wer Software baut, muss verstehen, wo sie läuft
Code zu schreiben reicht nicht, wenn niemand mehr versteht, in welcher Umgebung er läuft. Genau hier zeigt sich die Lücke, die durch Vibe-Coding und KI-generierte Software größer wird.
Ein Beispiel aus der Praxis von Thomas Ronzon macht das greifbar: Eine Software wurde an 120 PCs ausgeliefert, lief überall, nur an einem einzigen Standort stürzte der Client immer wieder ab. Die Ursache lag in einem Bild, das in einer Schleife geladen wurde und an diesem einen Rechner mit besonders vielen Einträgen die File-Handles auslaufen ließ. Der verantwortliche Kollege wusste nicht, was File-Handles sind und wie das Betriebssystem damit umgeht.
Der Punkt dahinter: Wer in einer Virtual Machine entwickelt, öffnet und schließt Dateien, ohne zu wissen, was darunter passiert. Solange alles glatt läuft, fällt das nicht auf. Es fällt erst dann auf, wenn ein langlaufender Prozess auf eine Bedingung trifft, die im eigenen Testaufbau nie vorkam.
Warum Memory Leaks erst im Feld zum Problem werden
Ein Fehler im generierten Code wird oft nicht beim Schreiben sichtbar, sondern erst in der Umgebung, in der die Software dauerhaft läuft. Memory Leaks sind das klassische Beispiel.
Wird ein Prozess alle paar Sekunden neu gestartet, bleibt ein Memory Leak folgenlos. Läuft derselbe Prozess über Stunden oder Tage, kippt das System irgendwann. Die Frage ist also nicht nur, ob Code funktioniert, wenn man ihn einmal ausprobiert oder einen Test dazu schreibt. Die Frage ist, ob er unter realen Feldbedingungen weiterläuft.
Generierter Code verhält sich zunächst deterministisch. Das eigentliche Risiko ist die Umgebung, die sich ändert. Dasselbe Muster zeigt sich beim autonomen Fahren: Die Systeme fahren in vielen Situationen besser als jeder Mensch, und dann kommt eine Lage, mit der sie nicht klarkommen, und es knallt.
Vibe-Coding stellt die Testfrage auf den Kopf
Wer Code generieren lässt, steht vor einem Bewertungsproblem: Wie lässt sich beurteilen, ob der Code nicht nur einmal läuft, sondern auch im Feld bestehen wird?
Ein Test allein hilft nicht weiter, wenn unklar ist, was der Code eigentlich tun soll. Thomas Ronzon beschreibt einen Studenten, der auf die Frage, woher er die Korrektheit von KI-generiertem Code kenne, antwortete, er schreibe einen Test dazu. Die Rückfrage entlarvte das Problem: Was willst du testen, wenn du gar nicht weißt, was dieser Code macht?
Marc Bless denkt das Konzept konsequent zu Ende. Wenn Software durchgehend neu generiert, ausgeführt und deployed wird, ist Code keine statische Komponente mehr. Was bleibt, sind die Anforderungen, die hineingehen. Der Test wandert damit nach außen.
Wenn die KIs so gut sind, dass sie ein funktionierendes System ausliefern, das die Bedürfnisse des Kunden komplett abdeckt, dann ist mein Test Case ganz systemisch von außen betrachtet. Das ist ein Systemtest. Unit-Tests macht das System für sich selbst. — Marc Bless
Die Mittelschicht der Entwickler steht unter Druck
Die These ist scharf: Ein großer Teil der heutigen Entwicklerrollen wird wegbrechen, weil sie nicht mehr gebraucht werden. Übrig bleiben zwei Gruppen.
Auf der einen Seite die wenigen, die ganze Systeme überblicken und verstehen, warum Dinge so sind, wie sie sind. Auf der anderen Seite Leute, die Coding-Agenten orchestrieren, und auch das nur so lange, bis man auch sie nicht mehr braucht.
Das gleiche Muster zeigt sich in der Low-Code-Diskussion. Solange sich die Fachabteilung etwas zusammenklickt und alles läuft, scheint kein Entwickler nötig. In dem Moment, wo es knallt, braucht es wieder Leute, und zwar richtig gute.
Warum Enterprise-Organisationen am Tempo scheitern können
Je größer und regulierter eine Organisation, desto schwerer fällt ihr die Veränderung, die technologisch gerade nötig wäre. Das ist weniger ein Technik- als ein Struktur- und Tempoproblem.
Fixe Regularien lassen sich gut formulieren und automatisieren. Eine Software, die Steuern berechnet und auf Änderungen reagiert, braucht keine Heerscharen von Programmierern mehr. Das Problem liegt woanders.
Interessant wird es bei allem, was sich nicht sauber beschreiben lässt, und bei der Wahrscheinlichkeit. KI liefert keine 100 Prozent, sondern vielleicht 99,8 Prozent. Bei einem Bankkonto ist diese Lücke nicht akzeptabel, das ist ein valides Argument. Bei vielen anderen Business Cases ist sie es sehr wohl.
Thomas Ronzon nennt ein Beispiel aus der Logistik: Eine Bildklassifizierung sollte alterndes von nicht alterndem Material trennen, mit einer Trefferwahrscheinlichkeit von etwa 97 Prozent. Das Projekt scheiterte, weil die Qualitätssicherung das nicht akzeptierte, obwohl eine Fehlklassifikation in diesem Fall folgenlos geblieben wäre.
Dazu kommt die Trägheit der Freigabeprozesse. Wenn eine Fachabteilung ein neues KI-Tool heute Nachmittag einsetzen will, die nächste Vorstandssitzung aber erst in dreieinhalb Monaten stattfindet, entsteht Schatten-KI. Dinge werden gemacht, ohne dass die Organisation sie erlaubt hat. Oder andere ziehen vorbei.
Vertrauen in KI baut sich auf wie Vertrauen in Menschen
KI-Systemen zu vertrauen funktioniert nach demselben Mechanismus wie Vertrauen unter Menschen: Es gibt einen Vertrauensvorschuss, und das Vertrauen wächst mit der Erfahrung in der Beziehung.
Niemand vertraut blind jedem, der etwas will. Genauso braucht es Prüfmechanismen und Erfahrung mit einem System, bevor man ihm Aufgaben überlässt. Und wie bei Menschen wirst du auch von KI manchmal enttäuscht, mit dem Unterschied, dass die Auswirkungen ein eigenes Thema sind.
Hier liegt ein doppelter Maßstab offen. Tausende Verkehrstote durch menschliche Fahrer werden als gegeben hingenommen. Fährt ein autonomes Auto nach Millionen Fahrten einmal gegen einen Baum, gilt die ganze Technik sofort als No-Go. Daraus folgt eine Umkehrfrage: Können wir es uns leisten, dass es keine autonomen Autos gibt?
Für das Testen heißt das, an eine alte Erkenntnis anzuknüpfen. Testen dient nicht nur dem Finden von Fehlern oder dem Nachweis von Anforderungen, sondern dem Aufbau von Vertrauen ins System. Genau diese Aufgabe wird bei Vibe-codeten Systemen wieder wichtig.
Niemand versteht jede Zeile, und das war schon immer so
Die Vorstellung, jemand müsse den gesamten Code verstehen, ist eine Illusion, auch ohne KI. In einem Projekt mit über 100.000 Zeilen Code versteht kein einzelner Entwickler jede Zeile.
Das passiert längst, es wird nur nicht wahrgenommen. Die übliche Praxis ist, sich um ein Problem zu kümmern, wenn es operativ auftaucht, weil man dann weiß, dass etwas schiefgelaufen ist. Die Abwehrreaktion, man müsse doch alles verstehen, statt nur zu generieren, ist verständlich. Sie könnte sich aber als Übergangsphänomen erweisen.
Was junge Entwickler heute lernen sollten
Der wichtigste Rat lautet: Such dir ein Side-Project. Auch wenn du es selbst vibe-codest, machst du dabei Erfahrungen, die im Daily Business nicht entstehen, und hast nebenbei Spaß.
Eine praktische Warnung gehört dazu: nicht mit Smart Home anfangen. Wenn dort etwas schiefgeht, hast du den Zorn der ganzen Familie und wirst zum Administrator deines eigenen Haushalts.
Der entscheidende Unterschied zeigt sich an zwei Studenten. Der eine baute sich eine eigene Tastatur, entwarf Schaltpläne, suchte Controller zusammen und sammelte dabei Wissen über alle möglichen Schichten. Er war Administrator, Product Owner und Qualitätssicherung in einer Person. Der andere hatte kein technisches Hobby und fiel bei der Testfrage durch. Intrinsische Motivation schlägt formales Wissen.
Vom T-Shape zum P-Shape
Das alte Bild des Senior-Entwicklers war das T-Shape: ein Thema in der Tiefe, ein breites Spektrum darüber. Dieses Modell reicht nicht mehr.
Gefragt ist ein P-Shape: mehrere Standbeine, die tief gehen, kombiniert mit breitem Überblick. Es genügt nicht mehr, sich in ein einziges Gebiet zu vertiefen.
| Modell | Tiefe | Breite | Tauglichkeit heute |
|---|---|---|---|
| I-Shape | ein Thema, sehr tief | kaum | riskant, weil nur eine Person eine Schnittstelle bedienen kann |
| T-Shape | ein Thema tief | breit | das frühere Senior-Ideal |
| P-Shape | mehrere Themen tief | breit | das, was heute gebraucht wird |
Die Realität in vielen Organisationen sind weiterhin I-Shaped Leute. Dann konkurrieren drei von sieben Produktteams um eine einzige Person, weil nur sie eine bestimmte Schnittstelle bedienen kann. Das ist eine Engstelle, die sich rächt.
Wer breit und tief zugleich denkt, braucht Abstraktionsvermögen, um Architektur- und Systemverständnis im Kopf zu halten. Diese Fähigkeit lässt sich nicht durch ein Tool ersetzen.
Lernen läuft heute in beide Richtungen
Die jüngere Generation pauschal als faul abzustempeln, geht an der Sache vorbei. Sie ist gut, und sie ist die einzige Generation, die wir haben.
Das alte Meister-Geselle-Bild trägt weiter, aber mit einem Twist. Der Geselle oder Azubi findet heute regelmäßig etwas heraus, das der erfahrene Entwickler nicht weiß. Meister und Geselle kehren sich situativ um. Wer älter ist, ist nicht automatisch der Meister.
Der Respekt geht dabei in beide Richtungen. Die Menge an Technik-Stack, die heute beherrscht werden muss, übersteigt die frühere Welt der einfachen One-Tier-Architektur bei weitem. Damals reichte Basic und eine Diskette. Heute ist die Einstiegshürde ungleich höher.
Was es für die erfahrenen Entwickler braucht, ist Offenheit. Nicht der Anspruch, alles besser zu wissen, sondern die Bereitschaft, Erfahrung auf der einen Ebene einzubringen und auf anderen Ebenen mitzulernen.
