Vibe-Coding-Schulden: Warum KI-gebaute Apps später schwer zu ändern sind

Kurz gesagt: Der Engpass bei KI-generiertem Code ist nicht die Schreibgeschwindigkeit – sondern dass ihn ein halbes Jahr später niemand mehr lesen kann und es keinen Autor gibt, den man fragen könnte. Lassen Sie die KI stattdessen prüfbare Metadaten statt bloßer Implementierung generieren, sinkt die Verständnisschuld deutlich.

Die Geschichte beginnt im siebten Monat.

Mingxiang ist eine Einzelhandelskette mit mehreren hundert Filialen. Letztes Jahr hatte das Finanzteam (über fünfzig Personen) genug davon, auf den IT-Terminplan zu warten, und baute „per Satz” mit KI ein Spesensystem. Formulare, Genehmigungen, Anbindung ans Hauptbuch – in zwei Tagen lief es, alle waren begeistert. Das folgende gute halbe Jahr lief es einwandfrei.

Im siebten Monat änderte sich eine Steuerregel: Der Vorsteuerabzug für eine bestimmte Rechnungskategorie wurde angepasst, also musste die Spesenlogik mitgeändert werden. Eine Kleinigkeit.

Dann stellte das Team fest: Niemand traute sich daran. Hinter jenem „einen Satz” steckten über zwölftausend von der KI generierte Zeilen Code, die kein einziger Mensch vollständig gelesen hatte. In welchen Dateien war die Abzugslogik verstreut? Würde eine Änderung womöglich Genehmigung und Monatsabschluss-Abstimmung mitbetreffen? Niemand konnte es sagen. Noch peinlicher: Selbst die KI, die diesen Code geschrieben hatte, konnte nicht helfen – sie ist zustandslos, und die Einschätzungen, Abwägungen und Begründungen, die sie bei jener Generierung im Kopf hatte, hat sie nicht im Geringsten hinterlassen. Man kann nur die zwölftausend Zeilen erneut einer neuen Sitzung vorlegen und sie das frühere Selbst „erraten” lassen.

Diese Kleinigkeit dauerte am Ende drei Wochen. Und der wahre Preis bleibt nicht bei drei Wochen: Im Review vor dem Go-live entdeckte jemand, dass die KI nebenbei eine vom Abzug unabhängige Abstimmungslogik verändert hatte – um ein Haar wäre eine Reihe von Spesen mit falschen Beträgen ins Hauptbuch geflossen. Diesmal wurde es glücklich abgefangen, aber es zeigt eines: Bei diesem System kann niemand mehr garantieren, dass „eine Änderung an A nicht B berührt”.

Genau so sieht Vibe-Coding-Schuld aus, heruntergebrochen auf ein ganz normales Team.

Eine besondere Schuld: aufgenommen, aber ohne auffindbaren Gläubiger

Technische Schulden sind kein neues Wort. Doch von KI generierter Code schuldet eine Art, die es früher nicht gab.

Auch von Menschen geschriebener Code wird mies, auch ihm fehlt mal Dokumentation. Aber wenigstens lebt der Autor noch – Sie können den, der ihn geschrieben hat, holen und fragen: „Warum wurde das hier damals so gemacht?” So schlecht der Code auch ist, dahinter steht immer ein erklärfähiges menschliches Gehirn.

Von KI generierter Code zieht selbst diese letzte Absicherung ab. Sein „Autor” ist ein zustandsloses Modell, das in dem Moment, in dem die Generierung fertig ist, nicht mehr existiert. Es hat den Denkprozess nicht hinterlassen, weil es schlicht keinen „Prozess” zu hinterlassen hatte. So halten Sie eine Implementierung in der Hand, die läuft, aber von niemandem erklärbar und bei niemandem nachfragbar ist. Mingxiangs zwölftausend Zeilen sind genau diese Schuld – sie schuldet nicht an der Codequalität, sie schuldet daran, dass „sie niemand mehr wirklich versteht”.

Das Branchenmuster ist die makroskopische Projektion dieses Mechanismus: KI erhöht die Generierungsgeschwindigkeit, aber Review, Verständnis und Verantwortung wachsen nicht im selben Tempo mit. Teams bekommen mehr Code schneller, aber weniger Menschen können erklären, welche Geschäftsentscheidung darin steckt. Die Geschwindigkeit ist echt, die Schuld auch – nur wird die Schuld nicht am Liefertag abgerechnet, sie kommt im siebten Monat zu Ihnen.

Wird Code-Generierung nicht rasant besser?

Hier muss man ernsthaft einen Einwand aufgreifen, sonst wäre es unfair: Modelle werden ständig stärker, können immer längeren Code lesen, dazu kommen KI-Code-Reviews und „selbstheilende” Pipelines – könnte es sein, dass diese Schulden in einem weiteren Jahr von noch stärkeren Werkzeugen automatisch getilgt werden?

Diese Erwartung hat ihre Berechtigung, aber sie verwettet sich darin, wo der Flaschenhals liegt.

Fortschritt bei der Code-Generierung löst das Problem, „schneller zu schreiben”. Mingxiangs Problem war aber nie, dass nicht schnell genug geschrieben wurde – ganz im Gegenteil, es wurde zu schnell geschrieben. In wenigen Tagen stand ein System, und Änderungen kamen schneller herein, als Menschen sie verstehen konnten. Der Flaschenhals liegt auf der Seite des „Verstehens und Verantwortens”, und die verbessert sich nicht linear mit der Generierungsfähigkeit. Stärkere Modelle generieren mehr Code, schneller, was auch schnelleres Anhäufen ungelesener Implementierung bedeuten kann. KI-Review kann mit einem Durchlauf helfen, aber die Einschätzung, „was diese Geschäftslogik eigentlich sein soll”, kann es nicht eindeutig beantworten, weil richtig und falsch nur im Geschäftskontext existieren, nicht im Code.

Anders gesagt: Die Hoffnung auf „ein noch etwas stärkeres Modell” zu setzen heißt, gegen versagende Bremsen mit dem Gaspedal anzugehen.

Zinseszins: Mit jeder Änderung versteht man ein Stück weniger

Warum der siebte Monat und nicht der erste? Weil diese Schuld mit Zinseszins läuft.

Bei der ersten Änderung „fügt die KI nebenan einen weiteren Abschnitt hinzu”, ohne den alten Code verstanden zu haben; bei der zweiten Änderung steht sie vor „altem Code + neuem, beim letzten Mal nicht verstandenem Code” und fügt also wieder einen Abschnitt hinzu. Jede Schicht stapelt sich auf der von niemandem verstandenen vorherigen Schicht, die Verständniskosten steigen exponentiell. Die Risikokurve ist daher keine sanft ansteigende Gerade, sondern eine Exponentialkurve, anfangs ruhig, im Mittelteil steil aufsteigend – so ruhig, dass Sie glauben, es sei alles in Ordnung, bis eine ganz gewöhnliche Änderung sie zündet.

Es gibt einen einfachen Selbsttest, mit dem Sie vorab sehen, an welchem Abschnitt der Kurve Sie stehen. Treffen von den folgenden fünf Punkten drei zu, dann häufen Sie bereits KI-technische-Schulden an:

1. Im System gibt es einen Codeabschnitt, von dem niemand im Team erklären kann, „warum er so geschrieben wurde”.
2. Soll eine Stelle geändert werden, ist die erste Reaktion „ob das woanders etwas kaputtmacht”, statt einfach zu ändern.
3. Die Zahl der Sicherheits- / Warnmeldungen steigt jeden Monat, und die meisten kommen aus neu hinzugefügtem Code.
4. Jedes Mal vor einer Änderung muss der gesamte Codeblock erneut der KI vorgelegt werden, damit sie ihn „neu durchliest”.
5. PRs werden immer größer, so groß, dass niemand sie wirklich Zeile für Zeile prüft und man nur noch schaut, „ob die Tests durchliefen”.

Wer am Ende die Rechnung dieser Schuld bezahlt

Die Zinseszinskurve wird am Ende zu einer konkreten Rechnung, geteilt auf vier Schultern:

• Das Geschäft zahlt mit Geschwindigkeit: Mingxiangs „kleine Änderung” dauerte drei Wochen. Wenn man bei jeder Änderung fürchtet, woanders etwas zu beschädigen, bricht die Iterationsgeschwindigkeit sichtbar ein – Sie glaubten, KI mache Sie schneller, nach einem halben Jahr sind Sie stattdessen langsamer.
• Das Risikomanagement zahlt mit Vorfällen: Jene fast ins Hauptbuch geflossene Fehlrechnung wurde abgefangen, das nächste Mal vielleicht nicht. Irgendwann gibt es eine Änderung, die nicht abgefangen wird.
• Das Team zahlt mit Menschen: Niemand will auf Dauer ein System pflegen, das er selbst nicht versteht und das bei jeder Änderung wackelt. Geht der, der es am besten kennt, wird das System endgültig zur Blackbox – und KI-Code hat ohnehin nie einen, „der es am besten kennt”.
• Das Unternehmen zahlt mit Neuschreiben: Hat sich die Verständnisschuld bis zu einem bestimmten Punkt angesammelt, ist „ändern” bereits teurer und riskanter als „neu schreiben”, also wird das Projekt umgestoßen und neu aufgesetzt. Die in der ersten Version gesparte Zeit wird mit Zins und Zinseszins zurückgezahlt.

Keine dieser vier Rechnungen taucht in der Begeisterung über „ein System in zwei Tagen fertig” auf. Sie alle stehen auf der Rechnung ab dem siebten Monat.

Vorab klargestellt: Der Wechsel zu Metadaten ist nicht kostenlos

Hier muss man ehrlich innehalten, sonst wird wieder ein Allheilmittel verkauft.

KI Definitionen statt Code generieren zu lassen, hat Abwägungen. Deklarative Metadaten decken jene 90 %, die in Unternehmensanwendungen immer wiederkehren – Objekte, Felder, Beziehungen, Sichten, Berechtigungen, Prozesse, Genehmigungen. Die dadurch gewonnene Steuerbarkeit kostet Sie einen Teil der Freiheit, „zu schreiben, wie es einem gerade gefällt”. Wenn Sie eine völlig neue Echtzeit-Kollaborationsengine bauen oder einen einzigartigen Graphenalgorithmus, dann brauchen Sie tatsächlich echten Code, Metadaten helfen Ihnen nicht, und sie zwanghaft überzustülpen, macht es nur schlimmer – ObjectStack löst die Geschäftssysteme, die in Unternehmen immer wieder neu gebaut werden, nicht das nächste Figma.

Und eine weitere Ehrlichkeit: Sich für eine Metadaten-Runtime zu entscheiden, heißt, einen Teil der Implementierung dieser Runtime anzuvertrauen; Sie setzen auf ihre Qualität und langfristige Verfügbarkeit. Das ist eine reale Abhängigkeit – nur ist, verglichen mit der Wette auf „zwölftausend Zeilen ungelesenen Code”, die Wette auf eine wiederholt auditierte, versionierte, migrierbare Runtime die weitaus bessere.

Tauschen Sie das Generierte aus: nicht die Implementierung, sondern die Definition

Zurück zu Mingxiangs Spesensystem. Bei gleichem Bedarf – hätte die KI damals nicht zwölftausend Zeilen Implementierung generiert, sondern eine solche Definition:

export const ExpenseReport = ObjectSchema.create({
  name: 'fin_expense_report',
  label: 'Spesenabrechnung',
  fields: {
    amount: Field.currency({ label: 'Betrag', min: 0 }),
    invoice_type: Field.select({ label: 'Rechnungstyp', options: ['Normalrechnung', 'Vorsteuerrechnung'] }),
    deductible_rate: Field.percent({ label: 'Abzugssatz' }),
  },
});

Diese paar Dutzend Zeilen sind keine „noch zu implementierende Schnittstelle”, sie sind selbst das System. Die Runtime (ObjectOS) liest sie und leitet automatisch Datentabellen, APIs, Oberflächen sowie vom Agent aufrufbare governte Werkzeuge ab; Berechtigungen und Genehmigungsflüsse sind ebenfalls Deklarationen, die daran hängen, statt handgeschriebener Logik.

Wie sähe dann jene Steuerregeländerung im siebten Monat aus? Keine Ausgrabung mehr, sondern eine verständliche Änderung in einer Zeile:

- deductible_rate: Field.percent({ label: 'Abzugssatz' }),
+ deductible_rate: Field.percent({ label: 'Abzugssatz', defaultValue: 70 }),
+ // Vorsteuerrechnungen werden nach neuer Regel zu 70 % abgezogen, die Regel sinkt in die Definition, Genehmigung und Abstimmung folgen automatisch

Das ist ein Diff, das man in fünf Minuten reviewen und per Knopfdruck zurückrollen kann, statt eines 400-Zeilen-PRs, bei dem sich niemand traut, auf „Mergen” zu klicken; und es gibt auch kein „nebenbei die Abstimmung kaputtgeändert”, weil die Abstimmungslogik nicht in dieser Definition steckt – sie kann sie schlicht nicht berühren. Der Unterschied liegt nicht darin, welche Variante „fortschrittlicher” ist, sondern darin, wer nach einem halben Jahr noch versteht, noch ändern kann und Fehler noch zurückverfolgen kann.

Warum der Zinseszinsmechanismus durchtrennt ist

Nach dem Wechsel zu Definitionen – warum lässt sich jene Kurve flachdrücken? Drei Punkte, alle zielen direkt auf Mingxiangs Geschichte:

1. Keine „ungelesene Implementierung”. Die Implementierung gehört zu derselben, wiederholt auditierten, von allen Anwendungen geteilten Runtime, nicht zu einer Kopie, die jede Anwendung einzeln generiert. In Ihrer Anwendung bleibt nur die Definition, und die ist für Menschen geschrieben.
2. Kein „niemand zum Fragen”. Die Definition ist deklarativ, sie trägt ihre Absicht offen im Gesicht – was deductible_rate ist, wem es gehört, welche Prozesse eine Änderung betrifft, alles auf einen Blick; man muss nicht jene längst verschwundene Generierungssitzung fragen.
3. Die Angriffsfläche schrumpft zusammen. Jene 45 %, die OWASP treffen, stammen größtenteils aus handgeschriebener Authentifizierung, Query-Verkettung und Eingabeverarbeitung. Sobald all das von einer einheitlichen Runtime getragen wird, fällt die Klasse der Schwachstellen, die die Anwendungsschicht überhaupt noch einbringen kann, um mehr als die Hälfte weg.

Schlusswort

Das Problem ist nicht, dass KI Code schreibt, sondern dass zu viele Teams ein Werkzeug für „schnelles Prototyping” direkt als Methode für „den Aufbau langfristiger Systeme” verwenden. Ein Prototyp darf ein Haufen ungelesenen Codes sein, ein System, das man drei Jahre nutzt, sollte es nicht sein.

Bevor Sie das nächste Mal mit KI ein wirklich langfristig zu nutzendes Geschäftssystem bauen, fragen Sie nicht zuerst „wie schnell generiert sie”, sondern jene Frage, der sich Mingxiang erst im siebten Monat gezwungenermaßen stellen musste: Traue ich mich nach einem halben Jahr, wenn sich eine Regel ändert, noch, es zu ändern, und kann ich es zurückverfolgen? KI Definitionen statt Code generieren zu lassen, ist ein Weg, diese Antwort wieder näher an „ja” zu bringen.

npm i -g @objectstack/cli && os start

Definieren Sie ein Objekt, ändern Sie einmal ein Feld und sehen Sie, wie sauber diese Änderung im git diff aussieht – das ist eine Schuld, die keinen Zinseszins anhäuft.