Ursprünglich auf Französisch verfasst. Von KI übersetzt — der Sinn wurde bewahrt, nicht der Stil.
Das Bedürfnis
Mit einem LLM an einem komplexen Thema zu arbeiten — einer Produktchance, einem strategischen Marktbeobachtung, einem Discovery-Prozess — geht schnell über die einfache Unterhaltung hinaus. Man sammelt Quellen, Entscheidungen, Hypothesen, Widersprüche. Man kommt am nächsten Tag zurück und der LLM hat alles vergessen. Man kopiert eine immer größer werdende context.md-Datei hinein, und irgendwann hält das nicht mehr.
Das Problem liegt nicht daran, dass dem LLM Intelligenz fehlt. Es fehlt ihm an strukturiertem Gedächtnis.
Wie ich dahin gekommen bin
Ich fing wie alle an. Auf ChatGPT, im Gespräch. Das Problem zeigte sich schnell: Bei jedem Austausch regenerierte die KI das gesamte Dokument neu. Oder nur einen Teil, aber ohne Zugriff auf das, was davor stand. Ich sagte ihr „zeig mir, was wir weiter oben gemacht haben", sie regenerierte alles, wir verloren enorm viel Zeit, und der Inhalt fing an zu divergieren.
Der nächste Schritt war der Wechsel zu Claude Code — ein Tool, das es erlaubt, mit einem LLM zu sprechen, während dieser direkt in eine Markdown-Datei schreibt. Manchmal bat ich ihn, zu restrukturieren, ich konnte leicht nachlesen oder den Text selbst anpassen. Das war besser. Aber eine lange Datei reichte immer noch nicht.
Und vor allem tauchte ein grundlegendes Problem auf: Die Datei ist entweder für den Menschen organisiert oder für die KI — nie für beide. Die KI braucht Orientierungspunkte, um eine Sitzung dort fortzusetzen, wo sie aufgehört hat, Entscheidungen zu merken, Quellen wiederzufinden. Der Mensch muss Informationen aggregieren, validieren, nach Thema oder Risiko aufteilen. Nicht dieselbe Struktur, nicht dieselben Bedürfnisse.
Also hatte ich zwei Dateien. Eine für die KI, eine für den Menschen. Das hielt eine Weile. Aber beide blähten sich auf, und es war alles durchgemischt — Quellen, Entscheidungen, Hypothesen, Direktiven, alles im selben Strom.
Ich begann aufzuteilen. Eine separate Direktiven-Datei, die nicht von einem Feature sprach, sondern davon, wie die KI arbeiten soll. Dann eine Definitionsdatei. Dann weitere. Und irgendwann der Klick: Es ging nicht mehr darum, in Dateien zu denken, sondern in einem Organisationssystem. Und da LLM vom menschlichen Gehirn inspiriert sind, sollte vielleicht auch ihr Gedächtnis so strukturiert sein.
Hier, in vereinfachter Form, wie ein strukturierter Kontext aussieht:
<contexte>/
├── 00_mission/
│ ├── mission.md ← warum wir hier sind
│ ├── directives.md ← wie die KI arbeiten soll
│ └── load_manifest.json ← was laden, in welcher Reihenfolge
├── 01_active/
│ ├── active.md ← aktueller Zustand + Plan
│ └── decisions.md ← getroffene Entscheidungen und warum
├── 02_checkpoints/ ← Momentaufnahmen des Kontexts
├── 03_sources/
│ └── source_catalog.md ← Index der Rohquellen
├── 04_notes/ ← atomare Notizen, miteinander verknüpft
├── 05_memory/
│ ├── journal/ ← was passiert ist (episodisch)
│ └── synthesis.md ← was wir daraus mitnehmen (Langzeit)
└── 07_outputs/ ← produzierte Lieferungen
Jeder Ordner hat eine genaue Rolle. Nichts ist durchmischt. Und vor allem: Man lädt nicht alles in jeder Sitzung — man lädt den Kern (00_mission + 01_active), den Rest bei Bedarf.
Was wirklich zählt, ist der Kontext
Bevor ich erkläre, warum diese Struktur funktioniert, muss eine grundlegendere Wahrheit ausgesprochen werden.
Was jemanden in einem Bereich hervorragen lässt, ist selten die Technik. Es ist die Tiefe des Kontexts, den man verinnerlicht hat.
Ein guter Verkäufer verkauft nicht besser, weil er ein Skript beherrscht. Er verkauft besser, weil er die Situation seines Kunden versteht — seine Rahmenbedingungen, seine Ängste, sein Vokabular, was er nicht sagt. Ein guter Product Manager macht nicht ein besseres Produkt, weil er die Frameworks kennt. Er macht es, weil er den Kontext des Nutzers begriffen hat — seine Gewohnheiten, seine Reibungspunkte, was er mangels einer besseren Lösung umgeht. Ein Soziologe versteht eine soziale Bewegung nicht durch das Lesen von Statistiken. Er versteht sie, indem er den gelebten Kontext einer Gruppe erfasst — ihre Codes, ihre internen Spannungen, ihr Verhältnis zur Welt.
Kontext ist das, was Information in Verständnis verwandelt. Der Rest — die Entscheidung, die Handlung, die Produktion — ergibt sich daraus fast mechanisch.
Und genau das fehlt, wenn man mit einem LLM an einem andauernden Thema arbeitet.
Man kann nicht alles in eine einzige Datei stecken
Ein menschliches Gehirn funktioniert nicht so, dass es in jedem Moment alles lädt, was es weiß. Es zerlegt. Es ordnet. Es trennt das Stabile vom Laufenden. Es unterscheidet eine Rohquelle von einer persönlichen Überzeugung. Es vergisst Details, um Muster zu behalten.
Ein LLM ist ähnlich — aber schlimmer. Sein Kontextfenster ist endlich. Und je mehr man es füllt, desto mehr lässt seine Aufmerksamkeit für das nach, was in der Mitte vergraben ist. Das ist keine Intuition: Forscher der Stanford University haben es in Lost in the Middle (Liu et al., 2024) nachgewiesen. Ihr Fazit: Ein LLM ruft eine Information, die am Anfang oder am Ende seines Kontexts steht, viel besser ab als eine, die in der Mitte vergraben ist. Eine 3000-zeilige Datei zu laden und zu erwarten, dass er „alles versteht", ist wie jemandem ein ganzes Buch laut vorzulesen und ihn zu bitten, jeden Satz zu behalten.
Was gebraucht wird, ist, nur das zu laden, was für die aktuelle Aufgabe relevant ist. Und dafür muss man das Wissen in navigierbare Stücke aufgeteilt haben.
Das Minimum laden, mit maximaler Wirkung
Wenn das Problem klar ist — man kann nicht alles laden — wird die Frage: Was laden, und wie?
Die Lösung ist, einen kompakten Kern zu haben, den man systematisch lädt: die Mission (warum wir hier sind), den aktuellen Zustand (wo wir stehen), den Plan (wohin wir gehen), die getroffenen Entscheidungen, die offenen Widersprüche und eine Wiederaufnahme-Notiz. Dieser Kern passt in ein paar kurze Dateien. Er gibt dem LLM alles, was er braucht, um sofort einsatzbereit zu sein, ohne Rauschen.
Dann, je nach Bedarf der Sitzung, lädt man bei Bedarf: eine bestimmte Quelle, die man analysieren möchte, eine Notiz, die man anreichern möchte, einen alten Checkpoint, den man vergleichen möchte. Der Rest — die Dutzenden von Quellen, die atomaren Notizen, die Sitzungstagebücher — bleibt auf der Festplatte, zugänglich, aber nicht im Kontextfenster.
Damit das funktioniert, braucht man einen Mechanismus, der der KI sagt, was sie laden soll, in welcher Reihenfolge und mit welcher Priorität. Das ist die Rolle eines Lademanifests — eine Art Kontext-Playlist. Zuerst: Mission und aktueller Zustand (der Kern, immer). Dann: die empfohlenen Dateien für die aktuelle Phase. Schließlich: verfügbare Dateien, die nur geladen werden, wenn die Sitzung es erfordert. Das ist wie das Tablett eines Chirurgen: Die wesentlichen Instrumente liegen bereits bereit, die anderen sind in Reichweite, aber man legt nicht alles auf den Tisch.
Genau das tut ein menschlicher Experte. Er liest nicht vor jeder Sitzung seine gesamte Akte durch. Er hat das Wesentliche verinnerlicht und sucht ein bestimmtes Dokument, wenn er es braucht. Der Unterschied ist, dass ein LLM nicht verinnerlichen kann — er hat nur das, was man ihm gibt. Daher die Wichtigkeit, ihm die richtige Teilmenge zu geben, nicht alles.
Quellen von dem trennen, was man produziert
Ein häufiger Fehler: alles vermischen. Das Transkript eines Interviews, die Hypothese, die man daraus ableitet, die Entscheidung, die man trifft, das Lieferergebnis, das man generiert — alles in derselben Datei, im selben Strom.
Das Problem ist die Nachvollziehbarkeit. Wenn alles vermischt ist, weiß man nicht mehr, was woher kommt. Man weiß nicht mehr, ob eine Aussage eine belegte Tatsache oder eine Interpretation ist. Man weiß nicht mehr, ob eine Entscheidung noch gültig ist oder ersetzt wurde.
Quellen (das Rohmaterial) von der Zusammenfassung (was man daraus mitnimmt) und den Outputs (was man liefert) zu trennen, ist keine Bürokratie. Es ist das, was erlaubt, über die Zeit ein zuverlässiges Denken beizubehalten.
Ein gut strukturierter Kontext produziert mehr als gefordert
Ein klassisches Problem im Product Management: Man schreibt viele Dokumente, findet aber nie das, was man sucht. Die Discovery-Notizen schlummern in einem Google Doc. Das Produkt-Brief ist in Notion. Das Protokoll des Strategiemeetings liegt irgendwo in Slack. Die Information existiert, ist aber zerstreut, unverbunden, unbrauchbar.
Wenn man einen Kontext rund um ein Thema strukturiert — indem man Quellen, Notizen, Entscheidungen und Zusammenfassungen trennt — passiert etwas Mächtiges. Dieser Kontext wird zu einer wiederverwendbaren Basis. Aus demselben Wissenskern lassen sich sehr unterschiedliche Lieferungen generieren: ein Release-Brief, User Stories, ein Kommunikationspaket (Zusammenfassung, Newsletter, LinkedIn-Post), eine Präsentation für das Lenkungskomitee.
Man schreibt nicht jedes Mal alles neu. Man kombiniert die richtigen Bausteine des Kontexts, um einem konkreten Bedarf zu entsprechen. Der LLM erfindet nichts — er assembliert, was bereits vorhanden ist, mit der richtigen Granularität und dem richtigen Blickwinkel. Das ist der Unterschied zwischen einem Dokument von Grund auf diktieren und einen Assistenten, der das gesamte Dossier bereits kennt, bitten, es in einem neuen Format aufzubereiten.
Hier geht die Strukturierung von „guter Praxis" zu echtem Vorteil: Ein gut organisierter Kontext ist nicht nur lesbar — er ist produktiv.
Das Ende des Sequenziellen
Das klassische Product Management funktioniert in Phasen: erst die Discovery, dann die Specs schreiben, dann liefern, dann kommunizieren. Jede Stufe wartet auf die vorherige. Das sieht auf einem Diagramm ordentlich aus, ist aber langsam — und spiegelt nicht die Realität im Alltag wider.
Mit einem Kontextsystem und einem LLM fällt diese Sequenzierung weg. Die Discovery endet nie wirklich. Man dialogisiert kontinuierlich mit der KI, um zu verfeinern, zu hinterfragen, zu reformulieren. Der Kontext reift dauerhaft, und die Lieferungen verbessern sich im Laufe dieser Reifung — nicht am Ende einer Phase, sondern mittendrin. Man kann schon in der zweiten Sitzung einen ersten Brief herausbringen, ihn weiterentwickeln, während der Kontext sich anreichert, und das finale Lieferergebnis ist nur die letzte Iteration eines Dokuments, das mit der Reflexion gewachsen ist.
Aber der interessanteste Effekt liegt woanders. Wenn man so arbeitet, öffnet man viele Kontexte. Produktchancen, Erkundungen, Marktbeobachtungen. Manche werden nie zu einem Feature. Sie „nutzen nichts" im klassischen Sinne. Außer dass diese Kontexte nicht isoliert sind. Sie sind verbunden. Eine Erkundung über industrielle Wartungsgewohnheiten nährt eine Reflexion über Anlagenmanagement. Eine Marktbeobachtung über SaaS-Preismodelle beleuchtet eine Chance zur Monetarisierung eines Moduls. Drei Kontexte, die unabhängig schienen, konvergieren eines Tages zu einem vierten, der ohne sie nie so reich gewesen wäre.
Das ist ein Positionswechsel. Man arbeitet nicht mehr im Modus „eine Idee → ein Lieferergebnis". Man kultiviert ein Netzwerk von Kontexten, die sich gegenseitig befruchten. Und wenn eines Tages eine Produktentscheidung getroffen werden muss, ist der Boden bereits bereitet.
Präzise Ideen, miteinander verknüpft
Dieses Netzwerk von Kontexten funktioniert im großen Maßstab. Aber innerhalb jedes Kontexts gilt dasselbe Prinzip auf der Ebene der Ideen.
Was Intelligenz ausmacht — menschliche oder künstliche — ist nicht das Ansammeln von Wissen. Es ist das Verknüpfen präziser Ideen miteinander. Und vor allem weit voneinander entfernter Ideen.
Ein Beispiel. Im Bereich der Zeitplanoptimierung — Räume, Ressourcen, Zeitfenster unter mehrfachen Einschränkungen zuweisen — heißt einer der effektivsten Ansätze Simulated Annealing. 1983 veröffentlichten Kirkpatrick, Gelatt und Vecchi in Science einen grundlegenden Artikel: Sie zeigten, dass ein metallurgischer Prozess — ein Metall erhitzen und langsam abkühlen lassen, damit seine Atome eine stabile Konfiguration finden — auf einen kombinatorischen Optimierungsalgorithmus übertragen werden kann. Kein offensichtlicher Zusammenhang zwischen einer Schmelzhütte und einem Raumplan — und dennoch hat diese Übertragung ein ganzes Forschungsfeld verändert. Die Verbindung existiert, wenn man sie erfasst hat.
Das ist genau das Versprechen des Zettelkasten — dieses Systems atomarer Notizen, das der deutsche Soziologe Niklas Luhmann erfand und der seine Zettelkiste als einen „Kommunikationspartner" beschrieb (Luhmann, 1981). Jede Idee ist isoliert, präzise und explizit mit anderen verknüpft. Man speichert keine Textblöcke. Man speichert Denkeinheiten, jede mit ihren Verbindungen. Und in diesen Verbindungen entsteht Intelligenz: wenn eine Notiz über ein physikalisches Phänomen eine Notiz über ein Planungsproblem kreuzt, wenn eine Feldbeobachtung eine theoretische Hypothese trifft, die sechs Monate zuvor gelesen wurde.
Auf ein Kontextsystem für LLM angewandt bedeutet das: keine langen monolithischen Synthesen schreiben, sondern kurze, gut betitelte, gut verknüpfte Notizen. Jede Notiz ist ein Punkt. Das Netzwerk der Verbindungen zwischen diesen Punkten ist die Karte. Und diese Karte erlaubt — einem Menschen wie einem LLM — Verbindungen herzustellen, die eine flache Datei nie erlauben würde.
Das ist auch die Intuition hinter A-MEM (Xu et al., 2025) — einem Gedächtnissystem für LLM-Agenten, das direkt vom Zettelkasten inspiriert ist. Strukturierte Notizen, dynamisch indexiert, miteinander verknüpft. Eine Architektur, die der KI die Mittel gibt, in ihrem eigenen Gedächtnis zu navigieren, anstatt alles auf einmal zu laden.
Kurzzeitgedächtnis, Langzeitgedächtnis und das Recht, den Faden wieder aufzunehmen
Ein menschliches Gehirn hat nicht ein einziges Gedächtnis. Es hat mehrere, die auf unterschiedlichen Zeitskalen funktionieren. Das haben Atkinson und Shiffrin bereits 1968 mit ihrem Multi-Speicher-Modell formalisiert: ein sensorisches Register, ein Kurzzeitgedächtnis, ein Langzeitgedächtnis. Endel Tulving verfeinerte die Unterscheidung 1972 weiter, indem er episodisches und semantisches Gedächtnis trennte. Konkret: Das Arbeitsgedächtnis behält, was gerade passiert — ein Gespräch, eine laufende Berechnung. Das episodische Gedächtnis speichert erlebte Ereignisse — was man am Dienstag getan hat, was der Kunde im Meeting gesagt hat. Und das Langzeitgedächtnis konsolidiert dauerhafte Wahrheiten — die Reflexe, die Überzeugungen, die Muster, die man durch Erfahrung verinnerlicht hat. Ein erfahrener Fahrer denkt nicht mehr daran, wie er schaltet. Ein erfahrener Product Manager entdeckt nicht bei jedem Projekt neu, dass Nutzer in Interviews lügen. Diese Kenntnisse sind zu Automatismen geworden.
Ein Kontextsystem für LLM reproduziert diese Architektur. Das Sitzungstagebuch ist das episodische Gedächtnis: was passiert ist, wann, in welcher Reihenfolge. Die konsolidierte Zusammenfassung ist das Langzeitgedächtnis: die stabilen Schlussfolgerungen, die validierten Entscheidungen, die aus Dutzenden von Sitzungen extrahierten Muster. Und die Checkpoints sind die Momentaufnahmen — der vollständige Zustand des Kontexts zu einem bestimmten Zeitpunkt.
Aber es gibt einen fundamentalen Unterschied zum menschlichen Gehirn. Ein Gehirn vergisst — das ist sogar seine Stärke, es verhindert, dass es übersättigt. Ein Dateisystem dagegen vergisst nichts. Und hier kommt die Auditierbarkeit ins Spiel. In einem gut strukturierten System kann jede verfeinerte Information — eine Produktüberzeugung, eine strategische Entscheidung, eine validierte Hypothese — zurückverfolgt werden. Von der Zusammenfassung steigt man zum Checkpoint auf, der sie produziert hat. Vom Checkpoint zu den Sitzungen. Von den Sitzungen zu den Rohquellen — das Interview, der Artikel, die Daten.
Das ist dasselbe Prinzip wie in der Wissenschaft: Eine Schlussfolgerung hat nur dann Wert, wenn man zur Methode und den Daten zurückgehen kann, die sie erzeugt haben. Wenn ein Stakeholder fragt „warum diese Entscheidung?", lautet die Antwort nicht „weil die KI es gesagt hat". Es ist: „Hier ist der Weg: Quelle → Analyse → Zusammenfassung → Entscheidung". Alles ist nachvollziehbar, alles ist überprüfbar. Das Gedächtnis ist keine Blackbox — es ist eine Beweiskette.
Was sich konkret ändert
Früher bestand mein Beruf als Product Manager zu einem großen Teil darin, Dokumente zu produzieren. Viel Dokumentation. Einige Stücke erforderten Expertise — strategische Rahmung, Architektur-Abwägungen, Priorisierung. Aber viele andere waren Inhaltsproduktion aus bereits vorhandenen Informationen: Support-Dokumentation, Blogartikel, Newsletter, Release-Notizen, interne Kommunikation. Notwendige Arbeit, aber weitgehend automatisierbar, wenn man über einen soliden Kontext verfügt.
Heute ist das im Begriff, automatisiert zu werden. Nicht weil die KI „magisch" ist, sondern weil ein starker, kohärenter und vollständiger Kontext ermöglicht, diese Lieferungen nahezu autonom zu generieren. Die Support-Dokumentation leitet sich aus den Entscheidungen und Specs ab. Der Newsletter wird aus den Release-Notizen und dem Produktkontext aufgebaut. Einige Lieferungen sind zu fast 100 % automatisiert. Andere — User Stories zum Beispiel — erfordern noch menschliche Überprüfung, aber der erste Entwurf ist bereits solide.
Die tiefgreifendste Veränderung liegt nicht in der Produktion. Sie liegt im Rohmaterial. Früher schrieb man Dokumente, um Produkte zu machen. Man verfasste Lieferungen, um Software ausliefern zu können. Es war das Lieferergebnis, das zählte — das finale, fixe, validierte Dokument.
Heute schreibt man Kontexte. Man spricht mit der KI — oft laut, vor dem Bildschirm — um Kontext zu erschaffen, anzureichern, zu verfeinern. Das Lieferergebnis ist nicht mehr der Ausgangspunkt der Arbeit, es ist ein Nebenprodukt. Was Wert hat, ist der Kontext selbst — und, wie wir gesehen haben, das Netzwerk verbundener Kontexte, die sich gegenseitig befruchten.
Wohin das führt
Was sich abzeichnet, ist ein Positionswechsel des Product Managers. Man geht von jemandem, der viele Dinge allein tut — Discovery, Specs, Kommunikation, Koordination — zu jemandem, der ein KI-Team managed. Man spricht, erklärt Kontext, hinterfragt Ergebnisse, wägt ab. Der Alltag ähnelt weniger dem Verfassen von Texten und mehr dem Management.
Und das ist eine anspruchsvolle Übung. Einer KI, die nichts weiß, einen Kontext zu erklären, zwingt einen zu prüfen, ob man ihn selbst versteht. Wieder erklären, reformulieren, präzisieren — das ist ein unbarmherziger Spiegel. Wenn der Kontext in deinem Kopf verschwommen ist, wird das Ergebnis verschwommen sein. Die KI kompensiert keine Ungenauigkeit — sie verstärkt sie.
Naval Ravikant spricht von specific knowledge — dieses Wissen, das sich nicht lehren lässt, das sich nicht auf einen Prozess reduzieren lässt. Buchführung lässt sich lehren. Man kann sie sogar automatisieren, einer KI anvertrauen. Aber es gibt Kompetenzen, die wir nicht formalisieren können. Warum ist eine bestimmte Person in einem Bereich exzellent, den wir nicht reproduzieren können? Das ist spezifisches Wissen — aufgebaut durch Erfahrung, Intuition, gelebten Kontext.
Ich glaube, das ist der Punkt, an dem der Mensch sich neu ausrichtet. Die KI übernimmt das Formalisierbare: die Inhaltsproduktion, die Aggregation, die Aufbereitung. Der Mensch behält das Nicht-Formalisierbare: die Meinung. Denn ein Produkt zu machen bedeutet, quantitative und qualitative Daten zu kreuzen, schwache Signale zusammenzuführen — aber am Ende eine Überzeugung zu haben. Und eine Überzeugung kann man nicht delegieren.
Eine Meinung zu haben bedeutet manchmal, unverhältnismäßige Risiken einzugehen. In einem Startup wählen manche 1 oder 2 % Chance, ein Unicorn zu werden — und 99 % Chance zu scheitern. Welche KI würde diese Entscheidung treffen? Risiken eingehen, klare Positionen halten, auf eine Vision setzen, die die Daten noch nicht bestätigen — eine KI kann das nicht. Nicht heute jedenfalls. Und genau das gibt einem Softwarehersteller seine Kultur, seine Farbe, seine DNA. Was ein Produkt unverwechselbar macht, auch wenn die Features sich ähneln. Das schafft nicht die KI — das schafft der Mensch dahinter.
Dieses Kontextsystem ist kein Selbstzweck. Es ist ein Werkzeug, damit der Mensch sich auf das konzentrieren kann, was er am besten kann — denken, entscheiden, einen Standpunkt haben — und den Rest einer KI überlässt, die endlich die Mittel hat, sich zu erinnern.
Dieses System verwaltet das Upstream — die Reflexion, die Strukturierung, die Entscheidung. Aber auf der Downstream-Seite vollzieht sich eine weitere Transformation.
Wir haben es alle erlebt: Eine Dokumentation wird zum Zeitpunkt der Spezifikation erstellt, dann schreitet die Entwicklung voran, Abwägungen werden getroffen, Anpassungen werden unterwegs vorgenommen — und niemand hat Zeit, jede Spec, jeden Changelog, jedes Support-Dokument zu aktualisieren. Das Ergebnis ist immer dasselbe: Dokumentation und Code divergieren. Je älter das Produkt, desto größer die Lücke.
Heute erlaubt die KI, diesen Strom umzukehren. Wenn der Code sauber genug und dokumentiert ist, kann er zur Quelle werden, aus der sich alles andere rekonstruiert: eine Support-Dokumentation nach einer Lieferung aktualisieren, einen zuverlässigeren Changelog generieren, oder eine funktionale Spezifikation aus dem tatsächlichen Zustand des Produkts statt aus einem alten Dokument rekonstruieren.
Das kann man als Code-centric-Ansatz bezeichnen. Der Code ist nicht mehr nur das finale Lieferergebnis — er wird zum zentralen Element, zur Quelle der Wahrheit, um die herum sich die anderen Produktartefakte gruppieren und regenerieren. Dieselbe Logik gilt für das Design: Wenn man in der Lage ist, ein Design-System aus dem tatsächlichen Code zu rekonstruieren und aktuell zu halten, ändert sich der Status des Mockups — es bleibt keine fixe Darstellung, es wird zu einer nutzbaren Basis.
Ich erforsche diese Idee ausführlicher in diesem Artikel.
Mehr dazu
Der PM als Kontext-Architekt Ein Sitzungsgedächtnis wie in OpenClaw einrichten