15 Punkte von sharpscar 2026-03-18 | 3 Kommentare | Auf WhatsApp teilen

Problem

Wenn man ein Projekt mit Vibe Coding beginnt, fühlen sich die ersten Stunden wie eine neue Welt an. Man wirft einen Prompt hinein, Code kommt heraus, irgendetwas scheint zu laufen, und es kommt der Moment, in dem man denkt: „Baue ich das gerade wirklich?“

Dann treten die Fehler auf.

Wenn man um eine Korrektur bittet, geht an anderer Stelle etwas kaputt, nach 30 Minuten hat die AI vergessen, was sie zuvor gesagt hat, und nach einer Stunde bin auch ich mir nicht mehr sicher, was ich eigentlich bauen wollte. Öffnet man das Projekt am nächsten Tag wieder, ist alles wie ein leeres Blatt. Am Ende dreht man sich nur im Kreis.

Wenn mehrere Projekte gleichzeitig laufen, wird es noch schlimmer. Will man etwas, das man am Montag gemacht hat, am Donnerstag fortsetzen, muss man den gesamten Kontext wieder von vorne aufsetzen.

Ursache

Der Engpass lag nicht im Code. Er lag im Gedächtnis.

Die AI vergisst nach dem Ende einer Session, und ich selbst vergesse nach ein paar Tagen ebenfalls. Doch weil niemand etwas festhält, wird das Projekt immer wieder auf null zurückgesetzt.

Was ich ausprobiert habe

Ich habe angefangen, Obsidian als langfristigen Speicher für das Projektgedächtnis zu nutzen.

  • Obsidian — verwaltet Planung, Design, Session-Logs und Fehlerprotokolle vollständig in Markdown
  • Claude Desktop + MCP — übernimmt die Rolle des „Dirigenten“, der Obsidian-Notizen direkt liest und das Design bespricht
  • Claude Code + MCP — übernimmt die Rolle des „Ausführenden“, der fertig geplante Aufgaben tatsächlich implementiert

Das Problem des Kontextverlusts in Claude Desktop habe ich gelöst, indem ich die Übergabe zwischen Sessions in einer Datei namens 날짜_handoff.md dokumentiere. Wenn man beim Start einer neuen Session nur diese Datei liest, ist der Zusammenhang sofort wiederhergestellt.

Der Kern war, den Zyklus „Dokumentieren → Entwerfen → Implementieren → Dokumentieren“ zu wiederholen.

Ergebnis

Früher habe ich immer wieder ein Toy-Projekt begonnen und drei Tage später den Ordner gelöscht. Seit ich auf diese Methode umgestellt habe, kommen Projekte, die ich nie fertigstellen konnte, nach und nach in einen Zyklus aus erster Fertigstellung → Deployment → Review → Korrektur. Aktuell verwalte ich mehr als 10 Projekte gleichzeitig auf einem Obsidian-Canvas.

Vor Kurzem hat Claude Code die Funktion Auto Memory bekommen. Das sind Notizen, die die AI für die AI schreibt; die oben beschriebene Methode sind Aufzeichnungen, die Menschen für Menschen machen. Ich denke, beide ergänzen sich gegenseitig.

Zusammenfassung

Ich habe diesen Workflow geordnet und als Buch auf Wikidocs veröffentlicht. Der vollständige Inhalt ist kostenlos.

„Warum Vibe Coding scheitert — Ein Leitfaden für die Zusammenarbeit mit AI“ https://wikidocs.net/book/19307

Es enthält den Prolog bis Ch.22 sowie einen Anhang. Wenn Sie Feedback haben, hinterlassen Sie es bitte in den Kommentaren auf den einzelnen Seiten; ich übernehme es dann direkt. Auch eine knackige Kritik ist willkommen.

3 Kommentare

 
runableapp 2026-03-19

Da ich Cursor nutze, habe ich solche Fälle (dass etwas „vergessen“ wird) nicht erlebt, deshalb finde ich es manchmal merkwürdig, wenn ich so etwas über Claude lese. Es gab Fälle wegen niedriger Qualität oder weil etwas nicht genau genug beschrieben war, aber nicht, dass etwas vergessen wurde. Und Fälle, in denen es wegen Fehlern an anderer Stelle problematisch wurde, hatte ich in der Anfangszeit des Cursor-Produkts ein paar Mal, aber inzwischen nicht mehr. Liegt das vielleicht daran, dass mein Projekt nicht groß genug ist?

Ich gehe so vor:

  • Ich schreibe ein etwa 10–20 Zeilen langes Dokument mit der groben Idee, der Vorgehensweise und, falls es etwas Ähnliches gibt, auch damit.
  • Ich lasse es das lesen und bitte darum, die Idee, Architektur, Tests und den Plan ausführlich als Dokument auszuarbeiten. Ich sage auch, dass es Fragen stellen soll, falls es welche an mich hat. (Dann stellt es mir häufig Fragen in Form einer nummerierten Auswahl.) Darüber diskutiere ich dann und arbeite es zu Ende aus. Zusätzlich spreche ich separat mit Gemini, um mehr zu recherchieren, und bespreche das dann ebenfalls gemeinsam.
  • Danach reviewe ich das fertige Dokument, überarbeite es im weiteren Gespräch Schritt für Schritt und gebe dann den Auftrag, es zu bauen. Währenddessen soll es abgeschlossene Teile als erledigt markieren und das Dokument beim Fortschritt aktualisieren. Und wenn etwas so groß oder komplex ist, dass es lange dauert, lasse ich es in den Cursor Rules zusätzlich in einem anderen Dokument festhalten, was jeden Tag gemacht wurde.

Da sich die Dokumente im Projekt befinden, muss ich sie nicht separat besonders verwalten. Und Cursor arbeitet nicht einfach immer weiter. Egal wie sehr man sagt, es solle bis zum Ende weitermachen, es stoppt unterwegs immer wieder (angeblich ist das eine Sicherheitsmaßnahme, damit es nicht in seltsame Loops gerät, aber dass ich dabei keine Wahl habe, stört mich). Dadurch wird ein Gespräch erzwungen. Das ist aber auch hilfreich. Es verhindert auch, dass nach ein paar Stunden plötzlich etwas völlig in die falsche Richtung gebaut wurde.

Da alles in einer einzigen IDE erledigt wird, muss man keine weiteren Services anhängen. Bei Claude habe ich die LLM-Funktionen nur per API genutzt, daher weiß ich nicht, wie gut es beim Coding ist, obwohl viele Leute sagen, dass es gut sei — wenn ich aber gelegentlich Beiträge darüber sehe, dass etwas vergessen wird oder Fehler auftreten, denke ich auch manchmal: Liegt das daran, dass mein Projekt eher klein ist ...

Im Ergebnis gehe ich also so vor wie bei der Verwaltung von Projekten und Teams in einer Firma – also genauso wie bei der Zusammenarbeit mit Menschen: Dokumentation und Protokollierung, Gespräche, Entscheidungen ... Es ist kein neuer Workflow. Gerade deshalb bin ich sehr neugierig auf die Workflows, mit denen Leute mit Claude etwas „vollautomatisch“ gemacht haben, und selbst wenn es nicht vollautomatisch ist, überlege ich, wie man die häufigen "Meetings" reduzieren kann (auch bei Teams aus Menschen versucht man ja, häufige Meetings zu verringern).

 
pari0130 2026-03-19

Wenn man qmd verwendet, wird lokal eine Datenbank für die Verwaltung früherer Sitzungen gepflegt!

 
sharpscar 2026-03-19

Vielen Dank für die guten Informationen.