Stash - Eine persistente Speicherschicht für AI-Agenten

• Eine persistente Speicherschicht, die Gesprächs- und Arbeitskontext auch über Sitzungswechsel hinweg fortführt, indem rohe Beobachtungen als Episodes gespeichert und anschließend zu strukturiertem Wissen verdichtet werden
• Verwendet eine modellunabhängige Architektur, sodass Claude, GPT, lokale LLMs und sogar benutzerdefinierte Agenten an dieselbe Speicherschicht angebunden werden können; das Backend basiert auf PostgreSQL und pgvector
• Übernimmt eine andere Rolle als RAG: Statt bei der Dokumentensuche stehenzubleiben, sammelt es aus Gesprächen neue Fakten und Beziehungen, Ziele, Fehlschläge und Hypothesen und kann zusammen mit RAG eingesetzt werden
• Trennt Nutzer-, Projekt- und Agenten-Selbstwissen per Namespace und hierarchischen Pfaden und synthetisiert mit einer Consolidation-Pipeline fortlaufend facts, relationships, causal links, patterns und contradictions
• Einschließlich nativer MCP-Integration, eines auf /self basierenden Selbstmodells und iterativer Research-Loops soll es sitzungsbasierte Agenten ohne Gedächtnis in handelnde Systeme mit langfristiger Kontinuität verwandeln

---

Überblick über Stash

• Eine persistente Speicherschicht, die zwischen AI-Agenten und der Außenwelt liegt und dafür sorgt, dass früherer Kontext auch nach einem Sitzungswechsel erhalten bleibt
• Speichert rohe Beobachtungen als Episodes und verdichtet sie zu strukturiertem Wissen wie facts, relationships, patterns, goals, failures und hypotheses
• Ersetzt das Modell selbst nicht, sondern ergänzt es um Kontinuität, und ist so konzipiert, dass es an jeden Agenten angeschlossen werden kann, etwa Claude, GPT oder lokale Modelle
• Verwendet als Speicherbasis PostgreSQL + pgvector
• GitHub

Aufbau des Speichers

• Trennt Speicher per Namespace in Bereiche wie Nutzer, Projekte und Agenten-Selbstwissen
• Jeder Namespace ist als hierarchischer Pfad aufgebaut; wer /projects liest, erhält auch Unterpfade wie /projects/stash und /projects/cartona
• Schreibvorgänge werden nur in genau einen Namespace geschrieben und verhindern so Speicherverschmutzung
• Nutzerspeicher, Projektspeicher und Selbstwissen unter /self bleiben strikt voneinander getrennt
• Beispielstruktur: /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences

Unterschied zu RAG

• RAG ist eher eine Retrieval-Schicht, die relevante Inhalte aus Dokumenten holt, erinnert oder lernt aber nicht aus der Unterhaltung selbst
• RAG kann nur mit Inhalten arbeiten, die bereits in Dokumenten vorhanden sind, und erzeugt kein neues Wissen aus Gesprächen
• Zielverfolgung, Absichtserkennung, Widerspruchserkennung über die Zeit sowie Schlussfolgerungen zu Ursache und Wirkung werden als außerhalb des RAG-Bereichs dargestellt
• Stash lernt automatisch aus Gesprächen, Entscheidungen, Erfolgen und Fehlschlägen und baut dabei einen Wissensgraphen auf
• Da Dokumentensuche und Erfahrungsspeicher unterschiedliche Probleme lösen, können RAG und Stash gemeinsam eingesetzt werden

Was es von bestehendem AI-Speicher unterscheidet

• Auch Claude.ai und ChatGPT haben Speicherfunktionen, diese sind jedoch an ihre eigene Plattform und ihre eigenen Modelle gebunden
• Stash arbeitet modellunabhängig und kann auch mit lokalen und privaten Modellen verbunden werden
• Die Datenhoheit bleibt beim Nutzer, und das Projekt wird als Open Source bereitgestellt
• Enthalten sind Hintergrund-Consolidation, Verfolgung von goals und intent, Lernen aus failures, causal reasoning und ein agentisches Selbstmodell
• Laut Vergleichstabelle sind ChatGPT Memory und Claude.ai Memory eher ein „notepad“, Stash dagegen ein „mind“

Das zu lösende Problem

• Aktuelle AI-Modelle sind zwar stark im Schlussfolgern, haben aber kein sitzungsübergreifendes Gedächtnis, sodass Nutzer sich und den Hintergrund ihrer Projekte immer wieder neu erklären müssen
• Die Methode, bei jeder Anfrage lange Gesprächsverläufe erneut in den Prompt zu packen, ist langsam und teuer, und die Grenzen des Context Window bleiben bestehen
• Es fehlt ein Mechanismus zur Weitergabe von Lektionen, der verhindert, dass im nächsten Gespräch dieselben gescheiterten Versuche wiederholt werden
• Speicherfunktionen werden nur als exklusive Features mancher Plattformen angeboten, sodass benutzerdefinierte Agenten oder lokale LLMs immer wieder ohne Kontext bei null starten

Consolidation-Pipeline

• Ein Hintergrundprozess verdichtet Erfahrungen fortlaufend und verwandelt rohen Speicher in strukturiertes Wissen
• In der Phase Episodes werden Beobachtungen append-only gespeichert
• In der Phase Facts werden Gruppen von Episodes mit einem LLM synthetisiert
• In der Phase Relationships werden Entitätsbeziehungen zwischen facts extrahiert
• In der Phase Causal Links werden Ursache-Wirkung-Paare zwischen facts verknüpft
• In der Phase Patterns werden abstraktere Muster auf höherer Ebene abgeleitet
• In der Phase Contradictions erfolgen Selbstkorrektur und confidence decay
• Goal Inference verfolgt automatisch Fakten zu aktiven Zielen und macht Fortschritte sowie Konflikte sichtbar
• Failure Patterns erkennen wiederkehrende Fehler und extrahieren sie als neue Fakten, um dieselben Fehlschläge seltener zu wiederholen
• Hypothesis Scan prüft neue Evidenz gegen offene Hypothesen und bestätigt oder verwirft sie ohne manuelles Eingreifen

MCP-Integration

• Arbeitet nativ mit MCP und kann an Claude Desktop, Cursor, OpenCode, benutzerdefinierte Agenten, lokale LLMs und andere MCP-Clients angebunden werden
• Lässt sich ohne SDK verbinden und ermöglicht dieselbe Speicherschicht überall ohne vendor lock-in
• Bietet insgesamt 28 Tools, von remember, recall, forget und init bis hin zu causal links, contradictions und hypotheses
• Mit ./stash mcp execute --with-consolidation lassen sich ein stdio-MCP-Server und die Consolidation gemeinsam starten
• Mit ./stash mcp serve --port 8080 --with-consolidation kann ein SSE-Server für entfernte Agenten gestartet werden

Selbstmodell des Agenten

• Beim Aufruf von init wird ein Grundgerüst im Namespace /self erzeugt und der Aufbau eines Selbstmodells begonnen
• Unter /self/capabilities merkt sich der Agent, was er gut kann, und nutzt das für die Arbeitsplanung
• Unter /self/limits werden Fehlschläge und Schwächen gespeichert, um dieselben Fehler nicht zu wiederholen
• Unter /self/preferences lernt er die am besten funktionierenden Betriebsweisen und formt damit langfristig seinen Arbeitsstil

Autonome Lernschleife

• Lässt man einen Research Loop im 5-Minuten-Takt laufen, greift der Agent auf früheren Speicher zurück, wählt selbst Themen zur Untersuchung, erzeugt neue Verbindungen, konsolidiert erneut und beendet dann den Lauf
• In der Phase Orient werden früherer Kontext, aktive Ziele, offene Hypothesen und frühere Fehlschläge geladen
• In der Phase Research führt der Agent Websuchen zu selbst gewählten Themen aus
• In der Phase Think macht er Spannungen, Lücken und Widersprüche im aktuellen Wissensstand sichtbar
• In der Phase Invent erzeugt er neue Artefakte wie Hypothesen, Muster und Entdeckungen
• In der Phase Consolidate wird die Pipeline ausgeführt, um rohe Episodes in strukturiertes Wissen zu überführen
• In der Phase Reflect + Sleep hinterlässt er eine Sitzungszusammenfassung, setzt Kontext für den nächsten Lauf und stoppt dann
• Loop-Prompt ansehen

Modell- und Infrastrukturkompatibilität

• Setzt für Embedding und Reasoning gleichermaßen eine einzige Provider-Konfiguration voraus, die eine OpenAI-kompatible API verwendet
• Unterstützt Cloud-, lokale und self-hosted Setups und betont, dass es kein vendor lock-in gibt
• Es wird erwähnt, dass lokal OpenRouter verwendet wird, um mit einem einzigen API-Schlüssel auf Hunderte Modelle zuzugreifen
• Funktioniert auch direkt mit Ollama; damit sind Offline-Speicher mit lokalen Modellen wie Qwen, Llama und Mistral möglich
• Auch Backends wie vLLM, LM Studio, llama.cpp server, Together AI und Groq, die das OpenAI-API-Format verwenden, werden als unterstützt genannt
• Das Standard-Embedding-Modell ist openai/text-embedding-3-small; in dieser Kombination wird STASH_VECTOR_DIM=1536 verwendet
• STASH_VECTOR_DIM kann nur vor dem ersten Start gesetzt werden; eine Änderung nach der Initialisierung erfordert das Zurücksetzen der gesamten Datenbank

Bereitstellung und Nutzung

• Bietet eine Docker-Compose-Konfiguration, um Postgres, pgvector und Stash gemeinsam zu starten
• Das Startverfahren wird in drei Schritten beschrieben: Repository klonen, .env.example nach .env kopieren, dann API-Schlüssel und Modelle setzen und docker compose up ausführen
• Nach dem ersten Start werden ein vorbereitetes postgres + pgvector, angewendete Migrationen, ein wartender MCP-Server und eine laufende Hintergrund-Consolidation erwartet
• Das Projekt wird unter der Lizenz Apache 2.0 veröffentlicht
• GitHub Repository
• alash3al.com

[GN⁺]

Hacker-News-Kommentare

• Ich habe draufgeklickt, weil ich dachte, endlich hätte jemand etwas Portable-ähnliches wie das Claude.ai-Memory-System gebaut, aber das ist überhaupt nicht der Fall.
  Was hier steht, ist einfach nur ein store/remember-Ansatz, und ich fand den Ansatz besser, bei dem ein Hintergrundmodell den Chatverlauf zusammenfasst und daraus Memory erstellt.
  Dort muss das Modell die Memorys nicht selbst schreiben, was deutlich besser funktioniert hat, deshalb wirkt es etwas irreführend, das hier auf demselben Niveau wie Claude.ai darzustellen.
  Ich suche auch weiterhin nach einem Memory-System dieser Art, um eher zu etwas wie LibreChat zu wechseln, habe aber noch nichts gefunden; das ist aktuell fast der einzige Grund, warum ich noch bei Claude.ai bleibe.
  Nur zur Einordnung: Dieses System gibt es nur in Claude.ai, nicht in Claude Code.

  • Laut dem jüngsten Claude-Code-Leak gab es etwas namens autoDream, das dort als background memory consolidation engine beschrieben wird: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
  • Diesen Ansatz würde ich wirklich gern ausprobieren.
    Meine Erfahrung ist genau umgekehrt: Ich habe https://github.com/flippyhead/ai-brain hauptsächlich für mich selbst gebaut, und ein paar Freunde nutzen es ebenfalls.
    Bisher hat es ziemlich gut funktioniert, die AI über CLAUDE.md dazu zu bringen, relevante Memorys zu finden und darüber nachzudenken, wann und wie sie gespeichert werden sollen.
    Dieser Ansatz kann Strukturen nach Priorität aufbauen und auch Notizen für die Zukunft hinterlassen, daher fühlt er sich ziemlich anders an als ein Ansatz, der einfach alles zusammenfasst.
  • Ich bevorzuge automatischen Recall, der unsichtbar für den Agenten abläuft.
    Memory-Erstellung per Tool Call funktioniert ebenfalls ziemlich gut, und auch ein Ansatz, bei dem beim Komprimieren des Kontexts automatisch Memory erzeugt wird, halte ich für brauchbar.
    Wenn die Erzeugung aber automatisch läuft, braucht man asynchrone consolidation, und das dann als dreaming zu bezeichnen, wirkt auf mich etwas übertrieben.
    Meine Implementierung steckt in Elroy.bot, und verschiedene Ansätze habe ich hier zusammengefasst: https://tombedor.dev/approaches-to-agent-memory/
  • Mich würde interessieren, wie man das benchmarkt.
    Wenn man im Hintergrund Memory extrahiert, ist es schwierig, das sauber mit dem Prefix-Cache zusammenzubringen.
    Schon ein simples zweistufiges LOG.md (detailliertes Log von Aufgaben und Learnings) + MEMORY.md (Einträge, die beim Abschneiden des Logs hochgestuft werden) + ein Stop-Hook am Ende jedes Turns kann schon ziemlich weit tragen.
  • Das Konzept ist ziemlich interessant.
    Es fühlt sich an wie eine Struktur, in der hinter einem Agenten, der mit dem Nutzer spricht, Hilfskräfte das Gespräch mithören, wichtige Fakten notieren oder in einer DB nach relevanten Fakten suchen und dann mit etwas wie dieses Memory X scheint relevant zu sein dazwischengrätschen.
    Wenn Tokens kostenlos wären, sähe das leicht aus, aber das effizient zu bauen, ist ein ziemlich spannendes Problem.

• Projekte, die etwas versprechen, dabei aber fast nichts über die Implementierung verraten, wirken für mich immer wie eine große red flag.
  Wenn man tiefer gräbt, ist es im Grunde eine Struktur aus pg_vector, mcp und zwei Funktionen für recall/remember.
  Am Ende ist das eher RAG, und man kann zwar behaupten, dass die Datenstruktur wichtig sei, aber fast alle bisherigen Memory-Systeme dieser Art haben am Ende sehr ähnlich funktioniert.
  Ich habe bislang noch keinen überzeugenden Nachweis gesehen, dass die Suche besser ist als eine grundlegende Vector-DB-Suche.

  • Die Website sieht schick aus, da steht memory, und die LLMs sind schlecht, aber dieses Produkt löst das angeblich auf magische Weise.
    Selbst wenn es wirklich funktioniert, ist es letztlich auch nicht viel mehr als ein hübsch verpacktes vectordb.

• Es gibt bereits eine Review dazu: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
  Viele andere LLM memory systems sind hier gesammelt: https://zby.github.io/commonplace/agent-memory-systems/
  Und hier ist zusammengefasst, was man sich von solchen Systemen wünschen würde: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

• Solche Agent-Memory-Systeme wirken zugleich über- und unterdesignt und sehen ziemlich nach einer Sackgasse aus.
  Ich kann mir kaum vorstellen, dass sie nicht schnell von dem abweichen und veralten, was moderne Modelle brauchen.
  Wenn man zum Beispiel einmal eine Zahlungsfunktion gebaut hat, könnten Memorys wie don't use stripe dafür sorgen, dass spätere Sessions ständig wieder in Richtung Payment kippen.

  • Noch schlimmer ist, dass es so gut wie keine Spuren gibt, dass der Autor das selbst wirklich benutzt hat.
    Das ist eine völlig unproven memory layer, und es wirkt, als hätte man einfach nur eine schillernde Marketing-Seite mit übertriebenen Behauptungen hochgeladen, ohne reale Screenshots.
  • Ich sehe das als Informationsproblem und habe ein kleines Tool gebaut, das absichtlich den Großteil nicht speichert: https://github.com/skorokithakis/gnosis
    Die Annahme ist simpel: Was ein LLM ohnehin weiß, wird es weiterhin wissen, also speichere ich nichts, was das LLM gesagt hat, und Code-bezogene Dinge bleiben im Code und in den Kommentaren.
    Es gibt aber Dinge, die in keine der beiden Kategorien fallen und trotzdem sonst nie erfasst würden.
    Beim Bauen von etwas ist oft das, was man bewusst nicht getan hat, wichtiger als das, was man tatsächlich getan hat; dieses Tool erfasst am Ende der Session verworfene Alternativen und deren Gründe und speichert sie als system knowledge.
    Am Ende will ich Informationen bewahren, die man nicht einfach per grep im Code findet, sondern die sonst nur in den Köpfen der Kollegen stecken. Bisher funktioniert das ziemlich gut, aber es ist noch früh.
  • Ich nutze ein selbst gebautes bespoke memory system, um dieses Problem zu vermeiden, indem alle Memorys zu kontextbezogenen Suchräumen gemacht werden.
    Ein Memory wie don't use stripe kommt nur dann in den Kontext, wenn das Modell per Prompt aufgefordert wird, an etwas im Bereich payment processing zu arbeiten.

• Ich habe nach so etwas weitergesucht und finde es schön zu sehen, dass der Account schon vor dem LLM-Boom Software veröffentlicht hat.
  Ich wünschte mir allerdings, jedes Projekt hätte so etwas wie eine LLM usage history.
  Also Infos dazu, ob es mit LLMs erzeugt wurde, wenn ja, in welchem Umfang, in welchen Phasen sie eingesetzt wurden, wie sorgfältig die Ausgaben geprüft wurden und ob man das Gefühl hat, dass die Qualität wenigstens genauso gut oder besser ist als bei einer rein manuellen Umsetzung.
  Es geht mir nicht darum, einer bestimmten Person zu misstrauen; ich fände es einfach gut, wenn das bei allen Projekten standardmäßig dabeistünde, und ich habe vor, das selbst auch so zu machen.

  • Ehrlich gesagt klingt das etwas entitled.
    Niemand zwingt dich, dieses Projekt zu benutzen; du kannst den Code selbst lesen und prüfen und dann eigenständig entscheiden, ob du es einsetzen willst oder nicht.
  • Die Frage an sich ist berechtigt, aber ich finde nicht, dass man die Antwort einfach der Selbstauskunft der Beteiligten überlassen kann.
    Ich glaube kaum, dass viele Leute offen zugeben würden, dass sie Design und Tests fast nicht gemacht haben und die Codequalität eher schlecht ist.
    Eher bräuchte man vielleicht ein Drittsystem, das solche Fragen beantwortet, auch wenn das natürlich ziemlich subjektiv werden kann, wenn es ebenfalls auf LLMs basiert.
  • Es gibt sehr viele unterschiedliche Arten, mit LLMs Software zu bauen.
    Ich betreibe die meisten meiner Projekte derzeit rund um mehrere Markdown-Dateien: erst Recherche und Planung mit AI, dann Nachverfolgung der Implementierung.
    Die Umsetzung erfolgt schrittweise nach Plan, und jeder Schritt wird fortlaufend überprüft.
    Wenn ich meinen Workflow dokumentieren sollte, dann wären genau diese Dateien diese Dokumentation.
    99 % des Codes werden zwar generiert, aber ich achte darauf, dass er auf eine Weise generiert wird, mit der ich zufrieden bin, und oft finde ich das Ergebnis sogar besser als das, was ich allein gebaut hätte.
  • Ich verstehe nicht ganz, warum das wichtig sein soll.
    Gute Software und schlechte Software kann sowohl ohne LLM als auch mit LLM entstehen.
    Man fragt einen Zimmermann ja auch nicht, ob er einen Hammer oder eine Nagelpistole benutzt hat und was jeweils für Dach und Terrasse verwendet wurde.
    Wenn es keine Vertrauensbasis gibt, muss man die Qualität letztlich ohnehin selbst prüfen oder es gleich selbst bauen; alles andere ist eher von Hoffnung getragen.

• Ich habe bisher noch kein wirklich brauchbares Memory gefunden.
  Das eine Extrem hinterlässt nur grobe Zusammenfassungen wie agents.md, was bei konkreten Details nicht viel hilft, etwa bei Dingen wie wenn dieses Element geändert wird, muss jenes Element als Draft markiert werden.
  Das andere Extrem ist zu detailliert, sodass die Details entweder ignoriert werden oder Änderungen in einem Funktionsbereich andere Bereiche verunreinigen.
  Am besten funktioniert für mich bisher am Ende ohne Memory, indem ich den für die jeweilige Session bzw. den Prompt wichtigen Kontext manuell auswähle.

  • Ich interessiere mich stark für Memory, halte es aber zumindest für Coding-Tools nicht für besonders nützlich.
    Die Source of Truth dafür, was ein Repository tut und tun soll, ist am Ende das Repo selbst.
    Was du beschreibst, klingt eher nach Code-Review-Richtlinien, und so etwas sollte man zum Zeitpunkt der Änderung explizit in den Kontext geben.
    Memory-Systeme sind dafür im Vergleich zu komplex und zu ungenau.
  • Eine Wishlist für solche Systeme gibt es hier: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
  • Ich empfinde das ähnlich.
    Ich frage mich, ob solche Modelle irgendwann continual learning bekommen werden.
    Sie sind eigentlich schon intelligent genug, aber ohne echtes Memory fühlen sie sich im Umgang unnötig umständlich an.
  • Die von Claude erzeugten Memorys waren bei mir fast alle vom Typ remember-to-not-forget, deshalb habe ich die Funktion am Ende deaktiviert.

• Für mich funktionieren ein paar einfache Dinge ziemlich gut; das Tool ist dabei Codex.

  1. eine stets aktuelle, detaillierte functional specification
  2. eine in mehrere Projekte strukturierte Codebase
  3. gut benannter und dokumentierter Code. Klassen-, Variablen- und Funktionsnamen sollten, egal wie lang oder albern sie wirken, ihren Zweck klar ausdrücken; solche Regeln schreibe ich in die Coding-Guidelines in Agent.md.
     Meine Functional Spec übernimmt für den Agenten die Rolle von Project.md.
     Und vor jedem agentischen Code-Review erzeuge ich einen Projekt-Verzeichnisbaum, kombiniere ihn mit der Codebase zu einer einzelnen Datei und versehe den Dateinamen mit einem timestamp.
     Das ist überraschend wichtig, weil es verhindert, dass das LLM auf alte Versionen Bezug nimmt, und es macht schnelle Diffs möglich, ohne gleich git mitsenden zu müssen.
     Bisher hat dieser einfache Workflow selbst bei großen, komplexen Codebases ziemlich gut funktioniert.
     Token-effizient ist das nicht, aber es funktioniert einfach.
     Man muss auch nicht jedes Mal die gesamte Codebase zusammenführen; Projekte, die schon abgeschlossen oder getestet sind oder mit der aktuellen Arbeit nichts zu tun haben, kann man weglassen.
     Trotzdem nehme ich sie in den gedruckten Verzeichnisbaum auf, damit der Agent wenigstens weiß, dass sie existieren, und bei Bedarf bestimmte Dateien anfordern kann.
  • Interessanter Ansatz.
    Mich würde interessieren, wie du diese Zusammenführung machst.
    Also ob das manuell ist, nur geänderte Dateien zusammengeführt werden oder es eine Mischform ist.

• LLM memory klingt in der Theorie gut, wird in der Praxis aber mit wachsender Größe fast genauso chaotisch wie ganz ohne Memory.
  Selbst wenn man wie im Beispiel auf der Startseite sagt arbeite weiter an meinem Projekt, hat man in der Realität selten nur ein einziges Projekt.
  Fünf oder zehn könnten im Memory liegen, und jedes davon wird zum Zeitpunkt des Speicherns sinnvoll gewesen sein.
  Am Ende muss man dann doch wieder etwas wie arbeite weiter am Sass-Projekt spezifizieren, bekommt dafür ein wenig Detailkontext, füllt aber zugleich den LLM context und zahlt zusätzliche Kosten für MCP calls.

  • Stimmt schon, aber das ist auch eine sehr naive implementation.
    Eine sauber gemachte Implementierung könnte solche Grenzen durchaus überwinden.
  • Sobald man anfängt, konkret vorzugeben, was erinnert werden soll, unterscheidet sich das im Grunde kaum noch davon, die AI einfach per Dateien write/read machen zu lassen.

• Ich frage mich, ob das nur für allein arbeitende Vibecoder gedacht ist.
  Wenn man mit echten Menschen an echten Projekten arbeitet, kann dieses System ohnehin nicht den vollständigen Projektkontext im Memory haben, und ich selbst habe ihn auch nicht vollständig.
  Sobald ein anderer PR gemergt wird, ist mein eigener Wissensstand schon wieder veraltet, und mich interessiert letztlich nur mein Ticket.
  Deshalb habe ich zunehmend das Gefühl, dass solche Dinge vielleicht gar keine Werkzeuge für diese Art kollaborativer Arbeit sind.

• Obwohl die Kosten für Softwareentwicklung inzwischen praktisch nahe null gefallen sind, überrascht es mich immer noch, dass man so etwas als vibe-coded marketing site verkaufen will.
  Wer hat denn die Zeit, so etwas auszuprobieren und dann Wochen oder Monate zu warten, um festzustellen, ob es wirklich funktioniert?
  Nirgendwo auf der Website gibt es Belege dafür, dass es besser ist als RAG oder einfach ein Ordner mit Memory-Dateien plus grep.
  Stattdessen gibt es nur fantastische Behauptungen, und selbst das Scrollen ruckelt mit 14 fps.
  Das wirkt, als wäre es vor 24 Stunden zusammengeschrieben worden, und ehrlich gesagt kommt es auf mich extrem faul rüber.