Vibe Coding hat ein Datenschutzproblem – zumindest bei Ressourcen

Klar, Vibe Coding ist ein echter Gamechanger. Beschreibst du, was du willst, baut der Agent es, die Tests werden grün, und du lieferst aus. Das fühlt sich an wie Magie – bis es das Gegenteil wird.

Dieses „bis" taucht meistens um 3 Uhr nachts auf. Deine App startet problemlos, verarbeitet ein paar Requests elegant, und wird dann unvermittelt vom OOM-Reaper abgeschossen. Oder sie öffnet zehntausend File-Descriptors und bricht zusammen. Oder sie läuft makellos mit deinen Beispieldaten – und geht in die Knie, als echte Nutzer auftauchen.

Der Code war korrekt. Er hat das Problem genau wie spezifiziert gelöst. Er ging nur stillschweigend von unendlich viel Speicher und unendlich vielen File-Handles aus – weil nichts in deinem Prompt etwas anderes sagte.

Der heimliche Killer: Unausgesprochene Annahmen

Das ist der fiese Teil am Vibe Coding, über den auf keiner Konferenz geredet wird. Wenn du selbst Code schreibst, trägst du implizite Modelle von Constraints überall mit. Du weißt, dass du auf einem Laptop mit 16 GB RAM arbeitest. Du weißt, dass der Production-Server Limits bei File-Descriptors hat. Du weißt, dass eine 400-GB-CSV-Datei nicht einfach komplett in den Speicher geladen werden kann.

Aber wenn eine KI deinen Code schreibt, existieren diese Constraints nicht. Die KI sieht „lade die Datei, sortiere sie, schreibe das Ergebnis" und denkt: super, ich lade alles. In der Testumgebung funktioniert das einwandfrei. Die Testdatei ist 50 KB groß.

Auch Code Reviews werden das nicht abfangen. Die problematischen Zeilen sehen völlig harmlos aus. Nichts schreit „Achtung, hier stimmt was nicht" – weil rein logisch gesehen alles stimmt. Der Fehler liegt nicht in der Logik; er liegt in der unsichtbaren Box, für die die Logik designed wurde.

Was wäre, wenn der Compiler Bescheid wüsste?

Hier wird es spannend. Ein Entwickler namens Nicolas Grislain experimentiert mit einer provokanten Idee: Was, wenn Ressourcen-Constraints Types wären, keine Kommentare?

Anstatt zu hoffen, dass dein KI-generierter Code sich an Speicherlimits hält – was, wenn der Compiler das Kompilieren schlicht verweigert, wenn dagegen verstoßen wird? Was, wenn „diese Funktion hält nie mehr als 100 Records im Speicher" und „dieses Programm hat nie mehr als 3 Dateien gleichzeitig offen" Fakten wären, die der Compiler verifiziert, statt Gebete, die man während des Reviews murmelt?

Das ist keine reine Theorie. Das Experiment nutzt Lean 4 – ja, das Lean, das in der formalen Mathematik für Furore sorgt – um Ressourcen-Budgets direkt in Function-Types zu codieren. Der Compiler wird zum Ressourcen-Prüfer, der automatisch verifiziert, dass dein Code innerhalb der Limits bleibt, bevor er überhaupt ausgeführt wird.

Ressourcen greifbar machen

Der Kern-Trick ist überraschend elegant: Ressourcen-Zähler werden durch das Type-System gefädelt. Statt „wie viele Dateien sind offen" als Runtime-Variable zu tracken, die vielleicht ignoriert wird, behandelt das Type-System es als phantom Parameter, der ausbalanciert sein muss.

Wenn du eine Datei öffnest, spiegelt die Type-Signatur das wider: Du betrittst die Funktion mit N offenen Dateien und verlässt sie mit N+1. Wenn du sie schließt, gehst du von N+1 zurück zu N. Der Compiler verfolgt das bei jedem Schritt, und du kannst buchstäblich keinen Code kompilieren, der eine Datei öffnet, ohne sie zu schließen – oder mehr Dateien öffnet als erlaubt.

Bei Memory funktioniert es ähnlich, aber mit einem Twist. Records schweben nicht frei im Speicher – sie leben in einem begrenzten Pool mit einer festen Anzahl Slots. Du hältst kein Event-Objekt; du hältst eine Referenz in diesen Pool. Das Type-System trackt, wie viele lebende Referenzen zu jedem Zeitpunkt existieren, und Allokation erfordert den Beweis, dass noch Platz ist.

Die Magie passiert am Entry-Point: Das Programm muss mit null Ressourcen in Benutzung starten und mit null enden. Du kannst keine Handles oder Referenzen leaken. Du kannst Caps nicht überschreiten. Der Compiler lässt dich schlicht nicht.

Warum das für Vibe Coding relevant ist

Dieser Ansatz verändert, wie wir über Prompts für KI-Assistenten nachdenken. Heute schreibst du vielleicht einen Hinweis wie „sei vorsichtig mit Memory-Nutzung" oder „schließe alle File-Handles" – in der Hoffnung, dass die KI aufpasst. Mit ressourcen-bewussten Types definierst du Constraints formal, und die Implementation muss sich selbst reorganisieren, um sie zu erfüllen.

Die KI bekommt zuerst die unbeschränkte Version. Tests laufen durch. Dann aktivierst du die Limits. Der Compiler lehnt die Implementation sofort ab. Die KI muss ihren Ansatz umbauen – vielleicht die Datei stückchenweise verarbeiten statt alles auf einmal zu laden, oder einen Connection Pool nutzen statt Dateien direkt zu öffnen.

Die Implementation funktioniert nicht einfach zufällig; sie funktioniert nachweisbar innerhalb des Budgets.

Die praktische Realität

Klarstellung: Für die meisten Teams ist das noch kein produktionsreifes Tooling. Der Lean-4-Ansatz erfordert erheblichen Setup-Aufwand, und in indexed Types zu denken, hat Overhead. Aber die zugrundeliegende Idee ist unabhängig von der Implementierung wertvoll.

Beim Vibe Coding gibst du nicht nur das Code-Schreiben ab, sondern auch das mentale Modell deines Systems. Dein KI-Assistent kennt deine Produktionsumgebung nicht. Er weiß nicht, dass dein Container nur 512 MB RAM hat. Er weiß nicht, dass dein Linux-Kernel File-Descriptors auf 1024 capped.

Solange wir keine besseren Wege haben, diese Constraints zu encodieren, gibt es ein paar pragmatische Optionen:

1. Sei explizit in Prompts – „Die Input-Datei kann bis zu 10 Millionen Rows enthalten" schlägt „verarbeite große Dateien effizient" um Längen

2. Teste mit Produktions-nahen Daten – Wenn deine Trainingsdaten lächerlich klein sind, wird deine KI keine Ressourcen-Muster lernen

3. Nutze bounded APIs – Architektur, die Ressourcen-Nutzung natürlich begrenzt (Connection Pools, Streaming statt komplettes Laden), ist schwerer falsch zu nutzen

4. Beobachte ressourcen-bewusste Tools – Die Branche fängt an, Wege zu erkunden, Constraints in KI-generiertem Code explizit zu machen

Fazit

Vibe Codings schmutziges Geheimnis ist nicht, dass es fehlerhaften Code schreibt – es schreibt Code, der innerhalb eines unsichtbaren Constraint-Raums korrekt ist. Dieser Raum enthält zufälligerweise deinen Laptop, deine Testumgebung und vielleicht deine ersten tausend Nutzer. Enthält er definitiv nicht: „Produktion unter Last."

Ressourcen-bewusste Type-Systeme wie dieses Lean-4-Experiment zeigen in Richtung einer Zukunft, in der „korrekt" mehr bedeutet als „logisch richtig". Es bedeutet: „nachweislich innerhalb der tatsächlich existierenden Grenzen".

Das ist eine Zukunft, für die es sich zu bauen lohnt. Bis dahin: Halte deine Testdaten nah an der Produktionsgröße, und vielleicht noch eine Extra-Notiz in deinen Prompts über diese File-Descriptor-Limits.

Dein zukünftiges On-Call-Ich wird sich bedanken.