Es funktioniert. Aber weiß eigentlich jemand, was drinsteckt?
Vibe CodingKünstliche Intelligenz verändert die Softwareentwicklung in einem atemberaubenden Tempo.
Heute kann jemand mit wenig oder gar keiner Programmiererfahrung eine Anwendung in einfachen Worten beschreiben und zusehen, wie eine KI Hunderte oder sogar Tausende Zeilen Code erzeugt.
Ein paar Anweisungen später läuft die Anwendung.
Die Oberfläche sieht gut aus. Die Schaltflächen funktionieren. Die Datenbank speichert Informationen. Vielleicht bestehen sogar sämtliche automatisierten Tests.
Ein Erfolg?
Nicht unbedingt.
Mit KI wird es immer einfacher, Software zu entwickeln, ohne dass es im gleichen Maße einfacher wird, diese Software auch zu verstehen.
Und genau das könnte zu einem der größten Probleme der zukünftigen Softwareentwicklung werden.
Als Programmieren noch zum Lernen gehörte
Ich entwickle seit Jahrzehnten Software und habe mit mehr als zwanzig Programmiersprachen gearbeitet, von Assembler und COBOL bis hin zu Swift und modernen Entwicklungsumgebungen.
In dieser Zeit haben sich die Werkzeuge grundlegend verändert. Ein Prinzip ist für mich jedoch immer gleich geblieben:
Ich muss verstehen, was meine Software tatsächlich macht.
Wenn ich ein Programm schreibe, gehe ich seine Abläufe gedanklich durch. Ich überlege, wie die Daten verarbeitet werden, welche Funktionen voneinander abhängen und was passiert, wenn etwas schiefgeht.
Natürlich kenne ich nicht jeden Parameter jeder Funktion auswendig. Wer mit so vielen Programmiersprachen gearbeitet hat, bringt gelegentlich auch deren Syntax durcheinander.
Dafür gibt es Dokumentationen, Referenzhandbücher und inzwischen KI-Assistenten.
Aber sich an eine bestimmte Syntax zu erinnern und Software zu verstehen, sind zwei völlig unterschiedliche Dinge.
Ich frage eine KI durchaus nach Implementierungsvorschlägen, lasse Funktionen überprüfen oder bitte um Hilfe bei einer API.
Das bedeutet aber nicht, dass ich ihre Vorschläge ungeprüft übernehme.
Manchmal lautet meine Antwort schlicht:
„Das ist redundant.“
„Warum so kompliziert?“
„Das ist zu langsam.“
Oder: „Dafür haben wir doch längst eine Funktion.“
Entscheidend ist nicht, wer den Code geschrieben hat.
Entscheidend ist, wer ihn versteht.
Das fehlende mentale Modell
Erfahrene Entwickler haben häufig ein gedankliches Modell ihrer Anwendungen.
Sie kennen die Architektur, die Abhängigkeiten, die Datenflüsse und die Gründe für frühere Entscheidungen.
Wenn sie an einer Stelle etwas verändern, können sie abschätzen, welche Auswirkungen das an anderen Stellen haben könnte.
Dieses Wissen entwickelt sich über Jahre hinweg durch Entwerfen, Programmieren, Debuggen, Optimieren und gelegentlich auch durch eigene Fehler.
Betrachten wir nun jemanden, dessen Einstieg in die Softwareentwicklung ausschließlich über KI-generierten Code erfolgt.
Er beschreibt, was er möchte. Die KI liefert eine Lösung. Er startet das Programm und prüft, ob das Ergebnis richtig aussieht.
Falls nicht, bittet er die KI um eine Korrektur.
Irgendwann funktioniert alles.
Aber hat er dabei verstanden, wie die Anwendung funktioniert?
Vielleicht. KI kann ein hervorragender Lehrer sein, wenn man sie entsprechend einsetzt.
Nur verlangt dieser Arbeitsablauf keineswegs, dass der Anwender die Implementierung versteht.
Man kann heute Software produzieren, ohne das Wissen zu entwickeln, das notwendig wäre, ihre Qualität zu beurteilen.
Das ist eine grundlegende Veränderung.
Unit Tests sind keine Garantie
Ein häufiges Argument gegen die Bedenken bezüglich KI-generierten Codes lautet, dass automatisierte Tests mögliche Fehler schon finden werden.
Tests sind wertvoll. Sie gehören zu einer professionellen Softwareentwicklung.
Aber sie haben eine grundsätzliche Grenze.
Ein erfolgreicher Test zeigt, dass sich eine Software unter den getesteten Bedingungen wie erwartet verhalten hat. Er beweist nicht, dass sie unter allen denkbaren Bedingungen korrekt funktioniert.
Wer entscheidet eigentlich, welche Situationen getestet werden müssen?
Wer berücksichtigt ungewöhnliche Eingabekombinationen, unerwartete Wechselwirkungen zwischen Komponenten oder Fehler, an die bisher niemand gedacht hat?
Wer erkennt, dass eine Funktion unnötig viele Ressourcen verbraucht, obwohl sie das richtige Ergebnis liefert?
Ein einfaches Beispiel:
Eine KI erzeugt eine Funktion, die Daten aus einer Datenbank abfragt. Die Ergebnisse sind korrekt und sämtliche Unit Tests werden bestanden.
Leider führt die Implementierung Hunderte Datenbankabfragen aus, obwohl eine einzige genügt hätte.
Die Tests sind grün.
Die Anwendung funktioniert.
Und trotzdem ist die Implementierung schlecht.
Stellen wir uns nun vor, dass solche Entscheidungen in einer größeren Anwendung immer wieder getroffen werden.
Aus einer ineffizienten Funktion werden zehn. Dann hundert.
Redundante Abstraktionen sammeln sich an. Abhängigkeiten nehmen zu. Die Performance verschlechtert sich.
Nichts davon muss sofort zu einem sichtbaren Fehler führen.
Aber die Software wird zunehmend schwieriger zu verstehen, zu warten und weiterzuentwickeln.
Natürlich können Tests viele dieser Probleme erkennen, sofern sie gezielt dafür entwickelt wurden.
Die entscheidende Frage bleibt jedoch:
Wer weiß überhaupt, was getestet werden muss?
Das Problem mit den Abhängigkeiten
Moderne Softwareentwicklung setzt stark auf Bibliotheken, Frameworks und Paketmanager.
Dafür gibt es gute Gründe. Bewährte Komponenten wiederzuverwenden spart Zeit und verhindert, dass komplexe Funktionen immer wieder neu entwickelt werden müssen.
Aber jede zusätzliche Abhängigkeit bringt auch Code mit, den der Entwickler möglicherweise nicht vollständig versteht oder kontrolliert.
Ich persönlich bevorzuge überschaubare Software mit möglichst wenigen Abhängigkeiten.
Beispielsweise verzichte ich bei meinen WordPress-Plugins auf Composer.
Nicht, weil Composer ein schlechtes Werkzeug wäre.
Sondern weil es mir wichtig ist, genau zu wissen, welche Komponenten meine Software enthält und wie diese miteinander zusammenarbeiten.
Das ist eine bewusste Entscheidung und keine allgemeine Empfehlung.
Bei großen Unternehmensanwendungen kann ein umfangreiches Dependency-Management absolut sinnvoll sein.
Aber irgendjemand sollte die architektonischen Konsequenzen dieser Entscheidungen verstehen.
Eine KI kann innerhalb von Sekunden empfehlen, eine weitere Bibliothek zu installieren.
Zu beurteilen, ob diese Bibliothek tatsächlich notwendig ist, welche zusätzlichen Abhängigkeiten sie mitbringt und ob eine bereits vorhandene Funktion das Problem lösen könnte, erfordert einen umfassenderen Blick auf das System.
Ohne diesen Überblick wird aus Bequemlichkeit schnell zusätzliche Komplexität.
Wer soll den Code in Zukunft überprüfen?
Damit kommen wir zu der Frage, die mich am meisten beschäftigt.
Über Jahrzehnte hinweg haben Softwareentwickler das Programmieren hauptsächlich dadurch gelernt, dass sie selbst Programme geschrieben haben.
Sie mussten zumindest so viel von ihren Anwendungen verstehen, dass sie diese zum Laufen bringen konnten.
Dabei begegneten ihnen Compilerfehler, Speicherprobleme, unerwartetes Verhalten, ineffiziente Algorithmen und unzählige Situationen, in denen sie Fehler suchen mussten.
Diese Erfahrungen entwickelten nach und nach die Fähigkeit, Probleme zu erkennen, bevor sie sichtbar wurden.
KI verändert diesen Lernprozess.
Ein Anfänger kann heute anspruchsvolle Anwendungen erstellen, ohne viele dieser Erfahrungen jemals gemacht zu haben.
Das ist zunächst eine fantastische Möglichkeit.
Aber es birgt auch ein Risiko.
Wenn immer mehr junge Entwickler hauptsächlich lernen, Code generieren zu lassen, anstatt ihn selbst zu verstehen, woher sollen dann die erfahrenen Code-Reviewer der nächsten Generation kommen?
Wer erkennt schlechte Architekturentscheidungen?
Wer entdeckt subtile Sicherheitslücken?
Wer merkt, dass eine komplizierte Implementierung eigentlich nur eine einfache Funktion benötigt hätte?
Und wer widerspricht einer KI, wenn ihre Lösung auf den ersten Blick vollkommen vernünftig erscheint, aber im Kern falsch ist?
Die Gefahr besteht nicht einfach darin, dass KI Fehler macht. Die Gefahr besteht darin, dass ihre Anwender möglicherweise nicht mehr über das Wissen verfügen, diese Fehler zu erkennen.
Mehr Software bedeutet nicht automatisch bessere Software
Dabei sollten wir die Vergangenheit nicht verklären.
Auch menschliche Entwickler haben schon immer schlechten Code geschrieben.
Erfahrene Programmierer machen Fehler. Große Softwareprojekte werden unnötig kompliziert. Sicherheitslücken finden sich auch in professionell entwickelten Produkten.
KI hat diese Probleme nicht erfunden.
Und KI kann durchaus dazu beitragen, sie zu lösen.
Sie kann Code überprüfen, Sicherheitslücken aufspüren, Optimierungen vorschlagen, Tests erzeugen und komplexe Implementierungen erklären.
Grundsätzlich könnten diese Fähigkeiten die Softwarequalität erheblich verbessern.
Aber nur, wenn sie mit dem notwendigen Urteilsvermögen eingesetzt werden.
Wenn eine KI Code erzeugt und eine zweite KI diesen anschließend für gut befindet, ist damit noch keine unabhängige und zuverlässige Qualitätskontrolle gewährleistet.
Beide Systeme könnten dieselben falschen Annahmen übersehen.
Und ein menschlicher Reviewer, der die Anwendung selbst nicht versteht, wird diese Fehler möglicherweise ebenfalls nicht erkennen.
Hinzu kommt ein wirtschaftlicher Aspekt.
KI macht die Produktion von Code schneller und billiger.
Aber sorgfältige Reviews, Systemdesign, Tests und Wartung benötigen weiterhin Zeit und Fachwissen.
Wenn Unternehmen vor allem schnelle Ergebnisse belohnen, wächst die Versuchung, genau an diesen Stellen zu sparen.
Das Ergebnis könnte eine enorme Zunahme produzierter Software sein, ohne dass unsere Fähigkeit, diese Software kompetent zu überprüfen, entsprechend mitwächst.
Wir bekommen möglicherweise mehr Anwendungen als jemals zuvor.
Aber nicht unbedingt bessere.
Der eigentliche Wert von Erfahrung
Ich verwende selbst regelmäßig KI bei der Softwareentwicklung.
Sie spart mir Zeit. Sie hilft bei der Recherche, beim Vergleich unterschiedlicher Lösungsansätze, bei der Fehlersuche und bei der Überprüfung von Implementierungen.
Manchmal entdeckt sie etwas, das ich übersehen habe.
Manchmal entdecke ich etwas, das sie übersehen hat.
KI ist ein leistungsfähiges Werkzeug. Aber sie ersetzt nicht das technische Urteilsvermögen.
Im Gegenteil: Je mehr Code KI produziert, desto wertvoller könnte dieses Urteilsvermögen werden.
Algorithmen, Datenstrukturen, Betriebssysteme, Netzwerkprotokolle und Softwarearchitektur zu verstehen, ist keineswegs überholtes Wissen.
Es ist die Grundlage dafür, überhaupt beurteilen zu können, was eine KI erzeugt.
Und diese Grundlage lässt sich nicht allein dadurch ersetzen, dass man bessere Prompts schreiben lernt.
Eine Generation, die Software bauen, aber nicht verstehen kann?
Es ist grundsätzlich nichts dagegen einzuwenden, mit Unterstützung einer KI programmieren zu lernen.
KI könnte sogar zu einem der wirksamsten Lernwerkzeuge werden, die wir je entwickelt haben.
Sie kann Zusammenhänge erklären, Alternativen zeigen und Anfängern ermöglichen, mit Ideen zu experimentieren, die bisher außerhalb ihrer Möglichkeiten lagen.
Aber mit KI zu lernen und das gesamte Verständnis an KI auszulagern, sind zwei völlig unterschiedliche Dinge.
Wir sollten junge Entwickler dazu ermutigen, nicht nur zu fragen, ob ihre Software funktioniert, sondern auch, warum sie funktioniert.
Sie sollten lernen, Code zu lesen, Programmabläufe nachzuvollziehen, Abhängigkeiten zu verstehen, Performance zu messen und Fehler systematisch zu untersuchen.
Und sie sollten gelegentlich selbst etwas implementieren, auch wenn die KI es innerhalb weniger Sekunden erzeugen könnte.
Nicht, weil handgeschriebener Code grundsätzlich besser wäre.
Sondern weil die Fähigkeit, über Software nachzudenken, praktische Erfahrung erfordert.
Die nächste Entwicklergeneration muss nicht unbedingt zwanzig Programmiersprachen lernen.
Aber sie muss verstehen, wie Computer funktionieren.
Andernfalls riskieren wir eine Generation, die nahezu jede beliebige Software erstellen kann, aber nicht mehr zuverlässig erklären, warten oder beurteilen kann, was sie geschaffen hat.
Und damit stünde die gesamte Softwareindustrie vor einem unangenehmen Problem:
Wir hätten die Produktion von Software automatisiert und gleichzeitig das menschliche Fachwissen geschwächt, das notwendig ist, ihre Qualität zu kontrollieren.
Die Zukunft der Softwareentwicklung sollte deshalb keine Entscheidung zwischen menschlichen Programmierern und künstlicher Intelligenz sein.
Es sollte darum gehen, die Stärken beider Seiten miteinander zu verbinden.
Die KI kann den Code erzeugen.
Aber irgendjemand muss das System weiterhin verstehen.
Denn am Ende lautet die wichtigste Frage nicht:
Funktioniert es?
Sondern:
Weiß eigentlich noch jemand, warum es funktioniert — und was passiert, wenn es nicht mehr funktioniert?
Top comments (0)