Vibecoding und das fehlende Systemverständnis in der Praxis

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.

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.

Häufig gestellte Fragen

Warum fällt ein Memory Leak im Test oft nicht auf?

Ein Memory Leak bleibt folgenlos, solange der Prozess alle paar Sekunden neu startet. Erst wenn dieselbe Software über Stunden oder Tage durchläuft, kippt das System. Testaufbauten bilden solche Laufzeiten selten ab. Generierter Code verhält sich zunächst deterministisch, das eigentliche Risiko steckt in der Umgebung: Sie ändert sich und erzeugt Bedingungen, die im eigenen Aufbau nie vorkamen.

Warum sollten Entwickler wissen, wie das Betriebssystem Ressourcen verwaltet?

Weil Fehler sonst erst im Feld auftauchen. Eine Software lief an 120 PCs problemlos, an einem einzigen Standort stürzte der Client immer wieder ab. Die Ursache: Ein Bild wurde in einer Schleife geladen und ließ dort die File-Handles auslaufen. Der zuständige Kollege wusste nicht, was File-Handles sind. Wer in einer virtuellen Maschine entwickelt, sieht solche Grenzen nicht.

Wie lässt sich Code prüfen, den man nicht selbst geschrieben hat?

Ein Test hilft nur, wenn klar ist, was der Code leisten soll. Auf die Frage nach der Korrektheit von KI-generiertem Code antwortete ein Student, er schreibe einen Test dazu, konnte aber nicht sagen, was der Code überhaupt tut. Wird Software laufend neu generiert und deployed, wandert die Prüfung nach außen: Es bleibt der Systemtest gegen die Anforderungen, Unit-Tests erledigt das System für sich selbst.

Welche Entwicklerrollen sind durch KI-Automatisierung besonders gefährdet?

Unter Druck steht die Mittelschicht. Übrig bleiben zwei Gruppen: die wenigen, die ganze Systeme überblicken und verstehen, warum Dinge so sind, wie sie sind, und jene, die Coding-Agenten orchestrieren, das aber nur so lange, bis auch diese Rolle entfällt. Dasselbe Muster kennt die Low-Code-Diskussion: Solange alles läuft, scheint kein Entwickler nötig, beim ersten Knall braucht es sehr gute.

Warum scheitern KI-Projekte in großen Unternehmen häufig nicht an der Technik?

Meist blockieren Qualitätsansprüche und Freigabeprozesse. Eine Bildklassifizierung in der Logistik sollte alterndes von nicht alterndem Material trennen, mit rund 97 Prozent Trefferwahrscheinlichkeit. Das Projekt scheiterte an der Qualitätssicherung, obwohl eine Fehlklassifikation folgenlos geblieben wäre. Kommt hinzu: Will eine Fachabteilung sofort starten, die nächste Vorstandssitzung liegt aber dreieinhalb Monate entfernt, entsteht Schatten-KI.

Reicht eine Trefferquote von 99,8 Prozent für den produktiven Einsatz?

Das hängt vom Anwendungsfall ab. Bei einem Bankkonto ist die verbleibende Lücke nicht akzeptabel, dieses Argument ist valide. Bei vielen anderen Business Cases ist sie es sehr wohl, besonders dort, wo eine Fehlentscheidung ohne Folgen bleibt. Fix beschreibbare Regularien, etwa eine Steuerberechnung, lassen sich ohnehin automatisieren; schwierig wird alles, was sich nicht sauber beschreiben lässt.

Wie entsteht Vertrauen in ein KI-System?

Nach demselben Mechanismus wie Vertrauen unter Menschen: über einen Vertrauensvorschuss, Prüfmechanismen und Erfahrung in der Beziehung zum System. Enttäuschungen gehören dazu, nur sind die Auswirkungen ein eigenes Thema. Damit knüpft Testen an eine alte Erkenntnis an: Es dient nicht nur dem Finden von Fehlern oder dem Nachweis von Anforderungen, sondern dem Aufbau von Vertrauen ins System.

Warum sind hochspezialisierte Einzelexperten für ein Team ein Risiko?

I-Shaped Profile erzeugen Engstellen. Kann nur eine Person eine bestimmte Schnittstelle bedienen, konkurrieren schnell drei von sieben Produktteams um sie. Für Senior-Rollen genügt deshalb auch das T-Shape nicht mehr, also ein Thema in der Tiefe plus breiter Überblick. Gebraucht wird ein P-Shape mit mehreren tiefen Standbeinen, getragen von Abstraktionsvermögen für Architektur und Systemverständnis.