Ein Absturz ist der beste Bug, den man sich wünschen kann. Er passiert direkt vor Ihren Augen, stoppt die App, und Sie beheben ihn noch am selben Nachmittag. Jeder, der mit KI-Generatoren baut, hat eine Geschichte über ein kaputtes Deployment oder einen leeren Bildschirm, und es ist fast immer eine Geschichte mit Happy End: gefunden, behoben, ausgeliefert.
Datenkorruption funktioniert nicht so. Sie stürzt nicht ab. Sie wirft keinen Fehler. Sie schreibt eine falsche Zahl in eine Datenbankspalte und macht einfach weiter, und die App läuft genau wie vorher. Der Bug, vor dem Sie sich wirklich fürchten sollten, ist der, der Ihnen nie sagt, dass er passiert ist.
Warum Abstürze das glückliche Szenario sind
Wenn etwas sichtbar kaputtgeht, bekommen Sie sofortiges Feedback und eine kurze Liste an Verdächtigen: den letzten Prompt, das letzte Deployment, die letzte Code-Änderung. Lovable, Bolt und ähnliche Generatoren scheitern ständig auf diese Weise, und das ist nervig, aber beherrschbar, weil der Fehler laut ist.
Stille Korruption dreht das ganze Problem um. Der Bug und seine Entdeckung können Monate auseinanderliegen, und in dieser Zeit häufen sich die beschädigten Daten weiter an: Sie werden in Berichte kopiert, in Summen eingerechnet, zur Berechnung einer Rechnung verwendet. Wenn jemand merkt, dass die Zahlen nicht stimmen, debuggen Sie nicht mehr einen einzelnen Fehler. Sie versuchen herauszufinden, welche von Tausenden Datensätzen seit dem Bug vertrauenswürdig sind und welche nicht, ohne ein Log, das den Unterschied markiert.
Die Randfälle, für die niemand promptet
KI-Modelle bauen für das Szenario, das Sie beschrieben haben. Ein Prompt wie “Nutzer sollen ihre Bestellmenge ändern können” liefert Ihnen einen funktionierenden Update-Button, getestet gegen exakt eine Sache: ein einzelner Nutzer, auf einer stabilen Verbindung, der einmal klickt. Reale Nutzung bleibt nicht in diesem Rahmen, und die Lücken zeigen sich in ein paar wiederkehrenden Mustern:
- Gleichzeitige Bearbeitungen. Zwei Personen öffnen denselben Datensatz und speichern Änderungen Sekunden auseinander. Ohne Sperr- oder Konfliktlösungsstrategie überschreibt derjenige, der zuletzt speichert, still die Änderungen der anderen Person, ohne dass irgendjemand gewarnt wird.
- Ein Netzwerkabbruch mitten im Formular. Eine Übermittlung wird abgeschickt, die Verbindung stockt kurz, und der Client kann nicht bestätigen, ob der Server sie erhalten hat. Der Nutzer sieht einen Ladekreis, nimmt an, es sei fehlgeschlagen, und sendet erneut ab. Ohne Deduplizierung gibt es jetzt zwei Datensätze, wo es einer sein sollte.
- Der doppelt geklickte Absende-Button. Die banalste Version desselben Problems. Eine langsame Antwort plus ein ungeduldiger Klick, und schon haben Sie eine doppelte Zahlung, eine doppelte Buchung oder eine doppelte Zeile erzeugt, die jede nachfolgende Zählung verzerrt.
- Unerwartete Eingaben. Ein Mengenfeld, das eine negative Zahl akzeptiert, ein Datumsfeld, das einen Wert in der Vergangenheit akzeptiert, ein Rabattfeld, das mehr als 100% akzeptiert. Keines davon lässt die App abstürzen. Sie erzeugen nur einen Datensatz, der mathematisch Unsinn ist, sobald ihn jemand mit der Realität abgleicht.
Keiner dieser Fälle ist exotisch. Es ist die ganz normale Reibung echter Menschen, die eine App über echte Netzwerke nutzen, und ein einzelner Prompt bittet die KI fast nie darum, sich dagegen zu wappnen, weil das Wappnen keinen sichtbaren Fortschritt in einer Demo bringt.
Wenn die Rechnung bei jeder einzelnen Transaktion falsch ist
Die zweite Variante dieses Problems ist noch leiser: ein Rundungs- oder Berechnungsfehler, der jedes Mal um einen Bruchteil eines Cents falsch ist, bei jeder Transaktion. Er läuft saubere durch. Er wirft nie eine Exception. Der Unit-Test, sofern es überhaupt einen gibt, prüft, dass die Berechnung eine Zahl zurückgibt, nicht, dass die Zahl bis zur letzten Dezimalstelle über zehntausend Durchläufe korrekt ist.
Genau hier wird der “es funktioniert”-Test, auf den Vibe Coding einen trainiert, gefährlich. Eine Preisberechnung, die um 0,3% daneben liegt, scheitert nicht in der Demo. Sie scheitert im Abgleichgespräch sechs Monate später, wenn das Finanzteam feststellt, dass die Summe aller Einzeltransaktionen nicht zur Gesamtumsatzzahl passt, und niemand sagen kann, warum, ohne Datensatz für Datensatz durchzugehen.
Diese Lücke zwischen “das Feature funktioniert” und “das Feature ist korrekt” ist genau das, was automatisierte Tests in der professionellen Softwareentwicklung abfangen sollen, und genau das, was fehlt, wenn ein nicht technischer Builder der Einzige ist, der das KI-Ergebnis prüft. Sie können visuell bestätigen, dass eine Seite lädt. Sie können nicht visuell bestätigen, dass eine sich verzinsende Berechnung über ein Jahr an Transaktionen bis auf den Cent stimmt.
Warum “sieht gut aus” der falsche Test für Datenintegrität ist
| Was Sie manuell testen können | Was tatsächlich Korruption verursacht |
|---|---|
| Wird das Formular erfolgreich abgeschickt? | Wird es genau einmal abgeschickt, auch bei wackliger Verbindung? |
| Zeigt das Dashboard eine Summe an? | Ist diese Summe nach 10.000 Zeilen noch korrekt, oder summiert sich ein Rundungsfehler auf? |
| Kann ein Nutzer einen Datensatz bearbeiten? | Was passiert, wenn zwei Nutzer ihn gleichzeitig bearbeiten? |
| Gibt der Rechner eine Zahl zurück? | Ist das die richtige Zahl, gegen eine unabhängige Quelle geprüft? |
Die linke Spalte ist das, was eine Demo und die meisten manuellen QA-Checks tatsächlich prüfen. Die rechte Spalte entscheidet, ob Ihre Abrechnung, Ihre Buchungen oder Ihre Berichte im sechsten Monat vertrauenswürdig sind. Vibe Coding optimiert stark auf die linke Spalte und hat keinen natürlichen Mechanismus für die rechte, weil die rechte Spalte verlangt, bewusst zu versuchen, den Idealweg zu brechen, statt ihn nur zu bestätigen.
Was das schlimmer macht als einen normalen Bug: Sie können nicht sagen, welche Datensätze falsch sind
Ein Absturz hat einen Wirkungsradius, den Sie sehen können. Beschädigte Daten haben einen Wirkungsradius, den Sie nur erraten können. Sobald ein Doppelübermittlungs-Bug oder ein Rundungsfehler monatelang live war, gibt es keine Markierung an den betroffenen Zeilen. Entweder Sie vertrauen dem gesamten Datensatz, von dem Sie jetzt wissen, dass er unzuverlässig ist, oder Sie prüfen ihn Datensatz für Datensatz, was jenseits einiger hundert Zeilen für ein kleines Team ohne dedizierte Entwicklungszeit nicht realistisch ist.
Das sind die wahren Kosten der “Vertrauenslücke”, die generierter Code mitbringt: Sie waren von Anfang an nicht in der Lage zu prüfen, ob die Logik wasserdicht war, also haben Sie, wenn sich herausstellt, dass sie es nicht war, keinen Ausgangspunkt für die Bereinigung. Den Bug zu entdecken ist nicht das Ende des Problems. Es ist der Anfang eines viel schwierigeren: herauszufinden, wie weit der Schaden zurückreicht.
So bauen, dass sich der Schaden nicht summiert
Sie können nicht jeden Randfall eliminieren, indem Sie bei Prompts vorsichtiger sind. Was Sie tun können, ist zu entscheiden, wo die Teile Ihrer App, die Geld, Mengen oder Buchungen verarbeiten, tatsächlich laufen.
Für Hobbyprojekte, interne Prototypen oder alles, wo eine falsche Zahl eine Unannehmlichkeit statt einer Haftung ist, sind generierter Code und manuelles Testen ein vernünftiger Tausch für Geschwindigkeit. Die Rechnung ändert sich in dem Moment, in dem die Zahlen in eine Kundenrechnung, einen Buchungskalender oder einen Bericht einfließen, den jemand abzeichnet. An diesem Punkt lautet die Frage nicht mehr “sah es beim Testen richtig aus”, sondern “wer prüft, dass es nach zehntausend Transaktionen immer noch richtig ist”.
Für diese Kategorie von Business-App strukturieren Sie den Schreibpfad so, dass er nicht davon abhängt, dass die KI Nebenläufigkeit und Rundung im ersten (oder fünften) Versuch richtig hinbekommt:
- Zentrale Schreibvorgänge auf getestete Infrastruktur verlagern, nicht auf frisch generierten Code. Softr wickelt das Erstellen und Aktualisieren von Datensätzen sowie Rollup-Berechnungen (Summen, Durchschnitte, Zählungen über verknüpfte Datensätze) über die eigene Datenbank-Engine ab, statt über App-spezifisch KI-generierte Logik. Ein Rollup, der Rechnungspositionen summiert, führt jedes Mal dieselbe getestete Berechnung aus, statt einer maßgeschneiderten Funktion, die eine KI einmal geschrieben und nie auf Rundungsdrift belastungsgetestet hat.
- Visuelle Berechtigungen statt handgeschriebener Nebenläufigkeitslogik verwenden. Softrs User Groups und Data Restrictions auf Datensatzebene regeln, wer was bearbeiten darf, was das Problem gleichzeitiger Bearbeitungen reduziert (wenn auch nicht eliminiert), indem der Zugriff auf Plattformebene kontrolliert wird, statt auf selbst codiertem Sperren zu setzen, an das eine KI vielleicht gedacht hat oder auch nicht.
- Unabhängig und regelmäßig abgleichen. Keine Plattform, No-Code oder nicht, ersetzt die Gewohnheit, Summen periodisch gegen eine externe Quelle zu prüfen: einen Kontoauszug, das Dashboard eines Zahlungsdienstleisters, eine manuelle Zählung. Das gilt unabhängig davon, ob Sie auf KI-generiertem Code aufgebaut haben, und es ist der einzige Weg, einen sich summierenden Fehler zu erkennen, bevor er ein Jahr alt ist.
- Wer im Code bleibt, sollte echte Zeit für adversariales Testen einplanen. Wenn Sie Entwickler sind und Cursor oder Replit nutzen, um eine individuelle App zu bauen oder zu erweitern, schreiben Sie explizit Tests für gleichzeitige Schreibvorgänge, doppelte Übermittlungen und Grenzwerte (negative Zahlen, Null, extreme Daten), denn die KI generiert sie nicht, wenn Sie nicht danach fragen, und “es hat kompiliert” sagt nichts darüber aus, ob es unter Last korrekt ist.
Nichts davon lässt das eigentliche Problem verschwinden. Software, die mit Geld oder Buchungen zu tun hat, wird immer jemanden brauchen, der die Rechnung mit der Realität abgleicht. Aber es gibt einen echten Unterschied zwischen einer App, deren Schreiblogik pro Projekt individuell generiert und nie belastungsgetestet wurde, und einer, bei der die zentralen Datenbankoperationen derselbe getestete Code-Pfad sind, auf den sich jedes Unternehmen auf der Plattform verlässt. Die erste gibt Ihnen bei jedem einzelnen Feature eine neue Chance, Nebenläufigkeit und Rundung falsch zu machen. Die zweite nimmt Ihnen nicht die Verantwortung für den Abgleich, aber sie nimmt Ihnen den täglichen Münzwurf, ob diese eine KI-generierte Schreibfunktion einen Doppelklick korrekt behandelt.
Die ehrliche Erkenntnis ist: Abstürze sind lästig, aber verzeihen einem. Stille Korruption ist geduldig. Sie wartet, bis das Datenvolumen hoch genug und die verstrichene Zeit lang genug ist, dass die Behebung weit mehr kostet, als Vorbeugung gekostet hätte.