In einem Webseitenprojekt sollte ein Agent vorhandene Seiten prüfen, Fehler beheben und seine Änderungen testen. Die Arbeit sah zunächst produktiv aus. Dateien änderten sich, Erklärungen kamen schnell und einzelne Fehler verschwanden.
Dann tauchten ähnliche Probleme erneut auf. Stilregeln fehlten im Arbeitskontext, frühere Entscheidungen waren in neuen Sitzungen nicht mehr präsent und der Agent meldete Ergebnisse, bevor der gesamte Veröffentlichungsweg geprüft war.
Das Modell arbeitete. Dem Projekt fehlte ein belastbares Gedächtnis.
Aktivität ohne Projektkontext
Ein Modell kennt nur den Kontext, den es im aktuellen Lauf tatsächlich erhält. Firmenfarben, Schriftarten, technische Nichtziele, Testkommandos und frühere Entscheidungen sind kein dauerhaftes Wissen. Nach einer neuen Sitzung oder einer gekürzten Unterhaltung können sie fehlen.
Dann ergänzt das Modell die Lücken mit plausiblen Annahmen. Es wählt eine passende Schrift, erweitert den Scope oder erklärt einen Teiltest zum Abschluss. Das ist kein Beweis für mangelnde Modellleistung. Es zeigt, dass der Arbeitsauftrag mehr voraussetzt, als der Lauf enthält.
Der gefährliche Zustand ist plausibler Fortschritt ohne vollständigen Nachweis. Eine sichtbare Änderung kann korrekt sein, während Navigation, Metadaten oder ein anderer abhängiger Stand veraltet bleiben.
Aus dem Fehler wurde ein Betriebsmodell
Die Gegenmaßnahme war kein längerer Universalprompt. Das Projekt brauchte feste Dateien und einen klaren Arbeitsweg. Scope, Stil, Agentenregeln, Tests und Entscheidungen mussten dort liegen, wo jeder neue Lauf sie lesen kann.
SCOPE.md begrenzt Ziel und Nichtziele. STYLE.md hält die sichtbaren Regeln fest. AGENTS.md beschreibt erlaubte Werkzeuge und Arbeitsgrenzen. TESTING.md nennt die Nachweise. DECISIONS.md bewahrt Entscheidungen, die nicht bei jeder Sitzung neu getroffen werden sollen.
Diese Dateien ersetzen kein Review. Sie verhindern aber, dass jeder Lauf das Projekt neu erfinden muss. Folge 6 enthält dazu eine kurze Praxis-Checkliste.
Die Arbeit endet am realen Zustand
Zu diesem Betriebsmodell gehört eine einfache Reihenfolge. Erst den Projektkontext lesen, dann einen begrenzten Auftrag bearbeiten, anschließend die betroffenen Abhängigkeiten prüfen und zuletzt den realen Zielzustand zurücklesen.
Ein grüner Test belegt nur, was er tatsächlich geprüft hat. Bei einer Webseite gehören deshalb auch Navigation, Serienmetadaten, interne Links und veröffentlichte Fassungen zum Arbeitsgegenstand, wenn sie vom Auftrag berührt werden.
Die METR-Studie zu erfahrenen Open-Source-Entwicklern zeigte für ihr untersuchtes Setting, dass KI-Werkzeuge Arbeit nicht automatisch beschleunigten. Daraus folgt keine allgemeine Quote. Es stützt aber die nüchterne Beobachtung, dass Nacharbeit und Prüfung Teil der Produktivitätsrechnung bleiben.
Kurz gesagt
Vibe Coding scheitert oft nicht zuerst am Modell. Es scheitert daran, dass ein flüchtiger Lauf die Verantwortung für Scope, Gedächtnis und Abnahme übernehmen soll. Ein tragfähiger Prozess legt diesen Kontext im Projekt ab und prüft am Ende mehr als den sichtbaren Patch.
Quellen
Claude Code Docs: Memory und CLAUDE.md
METR: Early-2025 AI and experienced open-source developer study
Gregor Lyttek ist Security Architect & AI Strategist und Threat Hunter im Versicherungsumfeld.