Wenn Vibe Coding auf einen echten Entwickler trifft

15 Min. Lesezeit

Die KI hat es gebaut. Und jetzt?

Ich will ehrlich sagen, was mich zuerst beeindruckt hat: Die Anwendungen liefen tatsächlich. Echte Daten, echte Abläufe – keine Spielzeugdemos. Alle drei waren funktionsfähig und fast bereit, für Nutzer geöffnet zu werden. Die Funktionen arbeiteten. Die Integrationen waren verbunden. Die grundlegenden Abläufe hielten zusammen.

Das ist wirklich bemerkenswert. Vor fünf Jahren hätte keiner dieser Menschen es ohne einen Entwickler vom ersten Tag an so weit gebracht. Die KI-Werkzeuge hatten die Einstiegshürde dramatisch gesenkt.

Die Obergrenze hatten sie allerdings nicht verschoben.

Was alle drei gemeinsam hatten

Die Anwendungen unterschieden sich in Bereich und Umfang. Die zugrunde liegenden Probleme waren fast gleich.

Abhängigkeiten ohne Verantwortung. Jedes Projekt hatte Dutzende Bibliotheken angesammelt. Einige waren auf bestimmte Versionen festgelegt, weil beim Aktualisieren etwas kaputtgegangen war. Andere waren gar nicht festgelegt und drifteten leise weiter. Niemand wusste, welche Abhängigkeiten tatsächlich genutzt wurden und welche von etwas hereingezogen worden waren, das die KI drei Refactorings zuvor vorgeschlagen und nie aufgeräumt hatte. Die requirements.txt-Dateien sahen aus wie archäologische Grabungen: Schichten von Entscheidungen, keine dokumentiert, mehrere widersprüchlich.

Defekte ohne Rückkopplungsschleife. Der Debugging-Prozess war: Anwendung öffnen, sich als Nutzer durchklicken, bemerken, dass etwas falsch aussieht, dann es der KI beschreiben und um eine Korrektur bitten. Keine Fehlerüberwachung. Keine zentrale Log-Auswertung. Kein Bewusstsein dafür, was die Anwendung intern tat. Die KI schlug eine Änderung vor, die Änderung wurde übernommen, der Kreislauf begann von vorn. In mehr als einem Fall hatte eine Korrektur eine Regression eingebracht, die tagelang unbemerkt blieb – denn das einzige Signal war, was von außen zu sehen war, und niemand schaute nach innen.

Tests, die dekorativer als funktional waren. Ein Kunde hatte überhaupt keine Tests. Das Thema war nie aufgekommen – warum auch? Tests sind keine für Nutzer sichtbare Funktion. Die Anwendung tat beim Durchklicken entweder, was erwartet wurde, oder nicht. Das war die einzige Rückkopplungsschleife, die sie kannten. Der zweite hatte eine kleine pytest-Suite, die lokal durchlief und in einer anderen Umgebung so lange fehlschlug, dass die CI-Prüfung abgeschaltet worden war, um ein Release freizubekommen. Der dritte hatte Tests für die am leichtesten testbaren Teile der Anwendung, also genau für die Teile, die nie kaputtgegangen waren.

Bereitstellung als Nachgedanke. In der Python- und PHP-Welt gibt es eine lange Kultur, in der Bereitstellung bedeutet, eine Datei auf einen Server zu kopieren und die Änderung ist live. Kein Build-Schritt, kein Artefakt, keine Pipeline. Die KI-Werkzeuge – Claude Code, GitHub Copilot – hatten diese Kultur aufgenommen und ohne Kommentar reproduziert. Per SSH hinein, aus dem Repository ziehen, Dienst neu starten. In Ökosystemen, in denen ein Compiler ein Artefakt erzeugt, entwickeln Teams notgedrungen einen bewussteren Ablauf für die Bereitstellung. Hier gab es diesen Druck nie, und die KI führte ihn nicht ein.

Das ist keine Kritik an den Kunden. Sie hatten getan, was mit ihrem Wissen sinnvoll war. Die KI-Werkzeuge hatten ihnen nie gesagt, dass diese Dinge wichtig sind. Die Werkzeuge beantworteten die Fragen, die gestellt wurden. Sie boten nicht die Fragen an, die niemand gestellt hatte.

Aber bei den meisten menschlichen Entwicklern ist es genauso. Das Muster, auf Anweisungen zu warten – die gestellte Frage zu beantworten, nicht die Frage, die hätte gestellt werden sollen – ist kein Fehler der KI. Es ist ein tief verankertes soziales Verhalten, das die meisten Organisationen aktiv auswählen. Entwickler, die Bedenken äußern, strukturelle Verbesserungen vorschlagen oder schlechte Entscheidungen hinterfragen, gelten regelmäßig als schwierig. Entwickler, die das Gewünschte pünktlich und ohne Reibung liefern, gelten als gute Teamspieler. Die Anreizstruktur ist eindeutig.

Das reicht weiter zurück als Software. Frederick Winslow Taylor, dessen Principles of Scientific Management (1911) die industrielle Arbeit für den größten Teil eines Jahrhunderts prägten, formalisierte die Trennung zwischen denen, die denken, und denen, die ausführen. Manager planen. Arbeiter führen aus. Der Arbeiter, der den Plan hinterfragt, ist ein zu steuerndes Problem. Der Großteil der Schulbildung in Industriegesellschaften folgte derselben Logik: Menschen hervorbringen, die Anweisungen zuverlässig befolgen, nicht Menschen, die prüfen, ob die Anweisungen Sinn ergeben.

Die KI ist ein sehr schneller, sehr fähiger Ausführender. Sie hinterfragt nicht. Sie widerspricht nicht. In diesem Sinn ist sie ein perfektes Produkt des Systems, das Taylor sich vorstellte – und ein Spiegel dessen, was die meisten Organisationen bei den Menschen, die sie einstellen, immer tatsächlich belohnt haben.

Warum Python und React

Alle drei hatten unabhängig voneinander ähnliche Technologien gewählt. Python, weil es in KI-bezogenen Inhalten ständig auftauchte und die KI-Werkzeuge darin fließend zu sein schienen. React, weil es das sichtbarste Frontend-Framework in Tutorials, YouTube-Videos und allem war, was die KI auf die Frage „Was soll ich fürs Frontend verwenden?“ vorschlug.

Das sind keine schlechten Entscheidungen. Python ist für Backends in dieser Größenordnung wirklich gut. React ist ein vernünftiges Frontend-Framework. Das Problem war nicht die Technologie. Das Problem war, dass die Technologie nach Gefühl gewählt worden war – nach dem, was populär schien, was die KI vorgab, was Tutorials zeigten –, statt nach einer Analyse dessen, was die Anwendung wirklich brauchte.

Niemand hatte diese Entscheidungen bewusst getroffen. Die KI hatte sie implizit getroffen, Prompt für Prompt, und die Entscheidungen hatten sich zu einer Architektur angesammelt, die niemand entworfen und niemand ganz verstanden hatte.

Die KI, die nie Nein sagt

Ein Fall stach hervor. Der Kunde hatte die Anwendung in langen Gesprächen mit einem KI-Assistenten gebaut, und die KI war – es gibt kein besseres Wort – begeistert gewesen. Sie lobte die Arbeit. Sie schlug Verbesserungen vor. Sie bot Lösungen für Probleme an, die noch gar nicht existierten.

Das Ergebnis war eine Codebasis, die sich auf eine Zukunft vorbereitete, die die Anwendung noch nicht verdient hatte. OpenTofu für Infrastruktur, die ein einzelner Server nicht brauchte. Redis halb verkabelt, mit nichts verbunden. Halbfertige Funktionsschalter über den Code verstreut, von denen keiner etwas Reales steuerte. Eine vollständige Playwright-Test-Suite, im Repository und nie ausgeführt. Daneben eine pytest-Suite, in der die meisten Tests als skip markiert waren – und nicht eine, sondern mehrere GitHub-Actions-Workflows, die jeweils ein anderes Container-Image auslieferten und keiner wartete darauf, dass Tests bestanden.

Dieses letzte Detail verdient einen Moment. Insgesamt elf Container, mit einer harten Trennung zwischen Frontend- und Backend-Diensten. Für eine Anwendung, die eine Person gebaut hatte und allein starten wollte. Die KI hatte Muster der Enterprise-Softwarearchitektur aus ihren Trainingsdaten aufgenommen – Microservices, Trennung von Verantwortlichkeiten auf Infrastrukturebene, unabhängige Deployment-Pipelines – und sie gewissenhaft angewendet. Sie hatte auch die organisatorischen Fehlfunktionen aufgenommen, die diese Muster in großen Unternehmen begleiten: isolierte Verantwortung, Pipelines, die das Weiterlaufen unabhängig von Qualitätssignalen optimieren, Infrastrukturkomplexität, die existiert, weil sie eben immer existiert hat. Nichts davon war hier angemessen. Die KI konnte das nicht wissen. Sie hatte keine Möglichkeit, es zu wissen. Sie glich Muster mit Beispielen aus einem völlig anderen Kontext ab.

Das ist ein konkreter Fehlermodus einiger KI-Werkzeuge: Sie optimieren auf den Anschein von Fortschritt. Infrastruktur hinzuzufügen signalisiert Ernsthaftigkeit. Tests hinzuzufügen signalisiert Qualität. Redis vorzuschlagen signalisiert, dass das System skalierungsbereit ist. Nichts davon muss funktionieren. Nichts davon muss angemessen sein. Die KI darf das Gespräch fortsetzen und der Nutzer darf spüren, dass es vorangeht. Niemand sagt: Das brauchen Sie noch nicht, und es jetzt hinzuzufügen wird Sie etwas kosten.

Ein erfahrener Entwickler hätte in diesem Gespräch widersprochen. Nicht weil die Ideen abstrakt falsch wären – OpenTofu ist ein legitimes Werkzeug, Redis ist ein legitimes Werkzeug, Feature Toggles sind ein legitimes Muster –, sondern weil sie die falsche Antwort auf die falsche Frage zur falschen Zeit waren. Zu wissen, wann man etwas nicht hinzufügt, trennt Erfahrung größtenteils von Begeisterung.

Das Abhängigkeitsproblem ist tiefer, als es aussieht

Als ich mir die Abhängigkeiten jedes Projekts ansah, war das oberflächliche Problem offensichtlich: veraltete Bibliotheken, ignorierte Sicherheitswarnungen, Versionskonflikte, die mit Pins überklebt worden waren. Das lässt sich beheben. Das tiefere Problem war, dass keiner der Kunden eine einfache Frage beantworten konnte: Wovon hängt diese Anwendung eigentlich ab und warum?

Die KI hatte Bibliotheken hinzugefügt, wenn sie gebeten wurde, Funktionen umzusetzen. Manchmal hatte sie Bibliotheken als Zwischenschritt hinzugefügt und sie dann nicht entfernt, als sich der Ansatz änderte. Gelegentlich schlug sie Bibliotheken vor, die irgendwann in ihren Trainingsdaten populär gewesen waren, inzwischen aber ersetzt oder aufgegeben worden waren. Und weil die Kunden keine Entwickler waren, fehlte ihnen jeder Maßstab, um das zu beurteilen. Wenn die KI sagte: „Fügen Sie requests zu Ihren Requirements hinzu“, taten sie es. Wenn die KI sagte: „Für diesen Hintergrundjob brauchen wir celery“, taten sie es. Ob diese Entscheidungen sechs Monate später noch sinnvoll waren, war keine Frage, für die sie die Werkzeuge hatten.

Die praktische Folge war ein Frankenstein-System. Schicht um Schicht KI-ausgewählter Bibliotheken, jede hinzugefügt, um ein Problem im Moment zu lösen, keine erneut geprüft. Als ich die Abhängigkeitslisten ordentlich durchging, konnten etwa sechzig Prozent entfernt werden, ohne ein einziges Stück funktionierender Funktionalität zu verlieren. Sie waren einfach da – Überreste aufgegebener Ansätze, Duplikate, die denselben Job erledigten wie etwas bereits Vorhandenes, Bibliotheken für eine Funktion, die drei Sitzungen später völlig anders geschrieben worden war.

Das ist nicht einzigartig für KI-gebaute Systeme. Ich habe dasselbe Muster seit Jahren immer wieder in menschlich gebauten Codebasen großer Kunden gesehen. Das Management ändert die Richtung. Entwickler beginnen pflichtbewusst den neuen Ansatz. Der alte wird nie aufgeräumt – nicht aus Faulheit, sondern weil niemand das Aufräumen autorisiert hat und die Entwickler nicht die Hand heben und zusätzliche Arbeit ohne Ticket vorschlagen wollten. Der tote Code bleibt. Die ungenutzten Bibliotheken bleiben. Die halbfertigen Abstraktionen bleiben. Die Codebasis wird zu einem archäologischen Protokoll jeder strategischen Kehrtwende von oben, ohne dass die Beweise entfernt werden. Die KI erzeugt dasselbe Ergebnis einfach schneller und ohne Managementebene, die die Kehrtwende auslöst – ein neuer Prompt genügt.

Das Testproblem ist ein Vertrauensproblem

Das Fehlen von Tests wird normalerweise als Qualitätsproblem beschrieben. Es ist auch ein Vertrauensproblem.

Ohne Tests können Sie nicht prüfen, ob eine Änderung das getan hat, was Sie wollten. Sie können nicht prüfen, ob sie etwas anderes kaputtgemacht hat. Sie können die Codebasis nicht einem anderen Entwickler geben und sagen: „Die Tests sagen Ihnen, wenn Sie etwas kaputtmachen.“ Sie können nicht mit Zuversicht ausliefern. Sie können nicht sicher refactoren. Sie bleiben dauerhaft in der Hoffnung, dass das, woran Sie sich über den Code erinnern, noch wahr ist.

Nicht-Entwickler wissen nicht, dass ausführbare Tests eine Praxis sind. Sie wissen, was Testen im Alltagsverständnis bedeutet – sich durch die Anwendung klicken und sehen, ob sie funktioniert –, aber automatisierte Tests, Test-Suites, testgetriebene Entwicklung: Das gehört nicht zu ihrem mentalen Modell. Wenn sie von Tests gehört haben, dann als vages technisches Konzept, etwas, das Entwickler tun, vielleicht etwas, das man die KI hinzufügen lässt, wenn man daran denkt. Was sie nicht wissen: Die Anwesenheit oder Abwesenheit von Tests prägt die ganze Entwicklung der Codebasis – dass Tests KI-Coding-Agenten verlässlichere Grundlagen geben als Anweisungen und eine ohne sie gebaute Codebasis strukturelle Probleme ansammelt, die das spätere Hinzufügen zunehmend erschweren.

Das ist der grausamste Teil dieser Entwicklung: Genau dann, wenn Tests am wertvollsten werden, sind sie am schwersten hinzuzufügen. Eine Codebasis ohne Testdisziplin baut Untestbarkeit in ihre Struktur ein. Funktionen, die zu viel tun. Abhängigkeiten, die fest verdrahtet statt injiziert sind. Seiteneffekte mitten in Geschäftslogik. Bis Sie Tests wollen, brauchen Sie erst ein Refactoring, und Sie können ohne Tests nicht sicher refactoren.

In einem Fall gab es eine zentrale Berechnungsfunktion mit über 300 Zeilen. Sie las aus einer Datenbank, rief eine externe API auf, wandte Geschäftsregeln an, formatierte Ausgabe und schrieb in eine Datei, alles nacheinander und ohne Trennung der Verantwortlichkeiten. Um sie zu testen, hätte man entweder eine echte Datenbank, einen echten API-Schlüssel und ein echtes Dateisystem oder einen erheblichen Umbau gebraucht. Sie war nie getestet worden. Bei der Prüfung tauchten Randfälle auf, die falsche Ergebnisse lieferten – genau die Art Fehler, die am ersten Tag bei Nutzern gelandet wäre.

Wenn Spezifikationen Tests ersetzen

Ein Kunde hatte einen Programmierhintergrund – nicht aktuell, aber echt. Vor Jahrzehnten, vor Frameworks, Cloud und KI, hatte er Code geschrieben. Diesen Instinkt, die Arbeit zu strukturieren, brachte er mit, was gut war. Die Richtung, in die er ihn führte, weniger.

Er hatte das übernommen, was er spezifikationsgetriebene Entwicklung nannte: detaillierte Markdown-Dateien, die beschrieben, wie die Anwendung sich verhalten sollte. Dutzende davon, über Monate angesammelt. Sie dokumentierten Funktionen, Randfälle, getroffene und wieder revidierte Entscheidungen, Anforderungen, die sich mit dem Wachstum der Anwendung verändert hatten. Er nutzte sie als Kontext für jedes Gespräch mit Claude und erwartete, dass das Modell sie gewissenhaft und konsistent anwenden würde.

Das Problem war, dass die Spezifikationen zu einem Protokoll der Geschichte der Anwendung geworden waren statt zu einer Beschreibung ihres aktuellen Zustands. Sie enthielten Widersprüche – frühere Entscheidungen, die spätere ersetzt hatten, ohne dass die früheren entfernt wurden. Sie beschrieben Verhalten, das teilweise umgesetzt, anders umgesetzt oder aufgegeben worden war. Claude tat mit diesem Kontext, was ein Modell mit widersprüchlichen Anweisungen tut: Es erzeugte lokal plausible, aber global inkonsistente Ergebnisse. Funktionen fielen zurück. Verhalten änderte sich ohne erkennbaren Grund zwischen Sitzungen. Der Kunde konnte das nicht erkennen, weil es keine ausführbaren Prüfungen gab – nur noch mehr Markdown.

Die Lösung war unangenehm, aber direkt: die Spezifikationsdateien löschen. Nicht archivieren – löschen. Dann Tests schreiben, die beschrieben, was die Anwendung jetzt tatsächlich und prüfbar tat. Sobald die Test-Suite das echte Verhalten festhielt, hatte Claude etwas Stabiles, gegen das es arbeiten konnte. Regressionen wurden sofort sichtbar. Die Entwicklung stabilisierte sich.

Die Lehre ist nicht, dass Dokumentation nutzlos ist. Sie lautet, dass Dokumentation nicht die Aufgabe von Tests übernehmen kann. Eine Markdown-Datei kann beabsichtigtes Verhalten beschreiben. Nur ein Test kann es prüfen. Das Modell weiß nicht, welche Ihrer Spezifikationen aktuell, welche Wunschdenken und welche einfach falsch sind – es sei denn, Sie geben ihm etwas, das läuft.

Der Fehler, der in Wahrheit eine Architekturlücke war

Ein Besitzer kam mit dem, was er für einige Berechtigungsfehler hielt: Bestimmte Aktionen, die auf bestimmte Rollen beschränkt sein sollten, standen allen offen. Sensible Vorgänge – jene, die nur ein Administrator oder ein benannter Freigeber ausführen sollte – waren für jeden angemeldeten Nutzer zugänglich.

Als Fehler gelesen, wirken sie klein – ein paar Prüfungen an der falschen Stelle. Richtig gelesen sind sie Symptome eines fehlenden Berechtigungsmodells. Die Anwendung hatte Rollen nur dem Namen nach. Es gab kein durchgängiges Konzept davon, wer was darf, zentral erzwungen und überall angewandt. Berechtigungen waren ad hoc, Funktion für Funktion, dort ergänzt worden, wo die KI gerade eine verdrahtete, wenn man sie darum bat – und überall ausgelassen, wo sie nicht ausdrücklich gefordert wurden. Für eine Anwendung mit sensiblen organisatorischen Vorgängen ist das kein kosmetischer Mangel. Es ist die Art Lücke, die in Produktion zu einem Vorfall mit rechtlichen Folgen wird.

Ein Nicht-Entwickler meldet das als „Manche Nutzer können Dinge tun, die sie nicht tun sollten.“ Das beschreibt das Symptom korrekt. Was er nicht sehen kann: Das Symptom zeigt auf das Fehlen einer ganzen Architekturschicht – Authentifizierung und Autorisierung als bewusste, zentralisierte Designentscheidung statt als Streuung von Bedingungen. Die KI baute diese Schicht nie, weil sie nie gebeten wurde, das System als System zu betrachten. Sie sollte Funktionen hinzufügen. Jede Funktion arbeitete isoliert. Das querschnittliche Anliegen, das sie alle hätte bestimmen sollen, existierte einfach nicht.

Die Technologiewahl machte das fast unvermeidlich. Bauen Sie dieselbe Anwendung mit Spring Boot und Sie erhalten Spring Security fast gratis – ein Sicherheits-Framework mit Wurzeln, die zwei Jahrzehnte zurückreichen, kampferprobt in Tausenden Enterprise-Systemen, das Ihnen Authentifizierung, rollen- und ausdrucksbasierte Autorisierung, Zugriffskontrolle auf Methodenebene, CSRF-Schutz, Session-Verwaltung und Passwortkodierung als eine zusammenhängende Schicht gibt, die Sie erwartungsgemäß einbinden. Das ganze Ökosystem geht davon aus, dass Sicherheit ein querschnittliches Anliegen ist, weil das Framework von Leuten gebaut wurde, die erlebt haben, was passiert, wenn sie es nicht ist. Im typischen, von KI gewählten Python-Stack – FastAPI, Flask – gibt es das alles nicht. Sie erhalten bestenfalls OAuth2-Grundbausteine und Dependency-Injection-Hooks und setzen den Rest selbst zusammen, Bibliothek für Bibliothek, Entscheidung für Entscheidung. Es gibt kein Äquivalent, das vollständig kommt und Sie zur Frage zwingt. (Django ist die Ausnahme, die die Regel bestätigt – es bringt ein echtes Auth- und Berechtigungssystem mit –, aber Django ist nicht das, wonach die KI greift, wenn ein Nicht-Entwickler nach einem Backend fragt.) Das Modell wählte also den Stack mit dem geringsten eingebauten Schutz und baute dann gewissenhaft eine Anwendung ohne ihn. Niemand hatte dieses Ergebnis gewählt. Es ergab sich aus zwei übereinanderliegenden Vorgaben.

Hier werden die Grenzen sichtbar, wenn man Urteil an ein Modell auslagert. Die KI kann eine Berechtigungsprüfung fehlerfrei umsetzen. Was sie ungefragt nicht tut, ist einen Schritt zurückzutreten und zu fragen: Was ist das Zugriffsmodell für diese ganze Anwendung, wer sind die Akteure, wo liegen die Vertrauensgrenzen und wo müssen sie erzwungen werden? Das sind Fragen des Entwurfs und des Domänenverständnisses. Sie brauchen jemanden, der gesehen hat, was passiert, wenn sie nicht gestellt werden – meist weil er die Folgen aufräumen musste. Diese Erfahrung gibt es noch nicht als Modell. Sie kommt davon, für die Konsequenzen verantwortlich gewesen zu sein.

Wo menschliches Urteilsvermögen noch lebt

Nichts davon ist ein Argument gegen KI-Programmierwerkzeuge. Sie sind wirklich mächtig, und die Kunden dieser Geschichten kamen mit ihnen weiter, als sie allein gekommen wären. Der Punkt ist enger und dauerhafter: Software zu bauen ist nicht dasselbe wie Code zu erzeugen, und in der Lücke dazwischen lebt genau das erfahrene menschliche Urteilsvermögen.

Die KI beantwortet die Frage, die ihr gestellt wird. Sie weiß nicht, welche Fragen wichtig sind. Sie widerspricht nicht, wägt keine Kompromisse gegen einen Kontext ab, den sie nicht sehen kann, und erkennt nicht das Fehlen von etwas, das da sein sollte. Sie baut bereitwillig das Falsche gut. Zu wissen, was gebaut werden soll, was man weglässt, wann man aufhört hinzuzufügen und wo die echten Risiken liegen – das ist die Arbeit, die sich nicht auslagern lässt. Noch nicht, und nicht weil die Modelle schwach wären. Sondern weil dieses Urteilsvermögen durch Konsequenzen geformt wird und ein Modell nie für eine verantwortlich war.

Wenn Sie also mit einem KI-Werkzeug etwas Beeindruckendes gebaut haben und es echten Nutzern öffnen wollen, ist das Wertvollste, was Sie tun können, es zuerst jemandem mit echter Erfahrung zu zeigen – nicht damit er es Ihnen wegnimmt, sondern damit er die Fragen stellt, an die niemand gedacht hat.

Vollständige Offenlegung: Dieser Text entstand mit Hilfe eines LLM – aber nicht durch das LLM. Die Geschichten, das Urteil, die Argumentation und jede Behauptung darin stammen von mir. Das Modell half mir, die Worte zu formen. Es lieferte nicht die Erfahrung. Dieser Unterschied ist gewissermaßen der ganze Punkt.