Ein AI Agent hat zwischen zwei Sitzungen kein eigenes Gedächtnis. Wir sichern das Projektgedächtnis dauerhaft durch Spezifikationen, Leitplanken und Skills.
Drei Monate nach Projektstart fand der Abnahmetest einer mit AI entwickelten Anwendung etwas Beunruhigendes: Wer die Rechnungsnummer in der URL änderte, sah die Rechnung eines fremden Kunden als PDF, samt Adresse und Zahlungsstatus. Wir suchten nach der Regel, die das hätte verhindern müssen. Irgendwo hätte stehen müssen: Ein Kunde darf ausschliesslich seine eigenen Rechnungen einsehen. Wir fragten den AI Agenten, der gerade an diesem Modul arbeitete. Er hatte keine Ahnung, konnte er auch gar nicht haben: Diese Sitzung wusste nichts von der letzten, geschweige denn von jener, die Monate zuvor diese Prüfung hätte vorschreiben sollen. Also suchten wir in der Spezifikation selbst. Die Regel war nicht da. Nicht gelöscht. Nie aufgeschrieben, weil sie allen zu selbstverständlich erschien, um sie eigens festzuhalten.
Damit das nicht mehr passiert, braucht jede Entscheidung einen Ort, an dem auch der nächste, ahnungslose AI-Agent sie noch lesen kann.
Die Spezifikation (Specification) – Was feststeht und was noch offen ist
Hier wird das fachliche Gebiet (Domain) eines Moduls definiert: seine Begriffe, Daten und Regeln. Dazu gehören auch die Anwendungsfälle (Use Cases) mit ihren Akzeptanzkriterien (Acceptance Criteria), die genau beschreiben, wie sich das System verhalten soll. Verantwortet wird das vom Business Analyst.
Jede Aussage darin lässt sich in zwei Kategorien einteilen:
- Invariante (Invariant): Eine feststehende Regel, gegen die eine Implementierung niemals verstossen darf.
- Offene Entscheidung (Open Decision): noch nicht getroffene Entscheidung, festgehalten mit einem sicheren Standardwert, damit niemand raten muss.
Die goldene Regel: Schreibe jede fachliche Regel und Invariante explizit auf, egal wie selbstverständlich sie erscheint. Was nicht in der Spezifikation steht, existiert für den AI-Agenten nicht.
AUSZUG: AUS DEM ORDER DOMAIN MODEL
Order
id: string
accountId: string (owning customer account)
status: placed | shipped | cancelled | refunded
INV-07: A customer may view only orders belonging to their own account.
OD-03: How long does a cancelled order stay visible in the account?
Default: 24 months, pending confirmation from Legal.
AUSZUG: USE CASE ORDER DETAIL
Scenario: Customer views their own order
Given an authenticated customer
When they request an order by id
Then the order is returned only if accountId matches the requester
# enforces INV-07
Scenario: Customer requests an order they do not own
Given an authenticated customer
When the requested order belongs to a different account
Then the response is 403 Forbidden
# enforces INV-07
Die Leitplanken (Harness) – Das Gedächtnis, das für alle gilt
Übergeordnet zur Spezifikation eines einzelnen Moduls stehen die Leitplanken. Sie bilden den gemeinsamen technischen Standard, dem jede Applikation im System folgt: Tech-Stack, Programmiersprache, API-Design, Security, Fehlerbehandlung und Logging.
Definiert wird dies vom Lösungs-Architekt. Dazu gehören auch Architektur-Entscheidungen (ADRs), kurze Einträge, die festhalten, warum eine bestimmte Option gewählt und eine Alternative verworfen wurde.
Die goldene Regel: Definiere technische Standards und Sicherheitsregeln einmal zentral für das gesamte System. Was in den Leitplanken verankert ist, gilt ausnahmslos, unabhängig davon, an was der Business Analyst im einzelnen Use Case gedacht hat.
AUSZUG: ARCHITECTURE DECISION RECORD
Title: Integration with SAP S/4HANA
Status: Accepted
Context: Multiple services need data from SAP. Direct point-to-point connections would mean many sets of credentials to rotate and no single place to audit access.
Decision: All integration with SAP S/4HANA goes through SAP Cloud Integration. No service connects to SAP directly.
Consequences: One integration surface to secure and monitor. Slightly higher latency accepted as tradeoff for a single audited path.
AUSZUG: DEFINITION STRUKTUR ABLAGE
pxp-portal-web (BFF)
├── app/ (Routes & Server Components call microservice directly)
├── app/api/ (Route Handlers, one per client-triggered write)
└── lib/api-client (Typed calls to the microservice)
order-service (Microservice)
├── src/handlers (HTTP routes)
├── src/services (Business logic)
└── src/models (Domain types)
Rule: The browser never calls a microservice directly.
Every client-triggered write goes through a same-origin Route Handler in the BFF.
Die UX – Was erlaubt ist vs. wie es aussehen soll
Ein visuelles Design trägt überhaupt kein Gedächtnis in sich. Ein Figma-Design zeigt nur einen Soll-Zustand, aber nie die Begründung oder die Geschäftslogik dahinter.
Die goldene Regel: Das Design zeigt das Wie, die Spezifikation entscheidet das Was. Wenn beide sich widersprechen, gewinnt immer die Spezifikation, weil sie die Einzige ist, die sich nachvollziehbar erklären lässt.
BEISPIEL: UX ORDER OVERVIEW
Die Hände (Skills) – Zwei Arten von Gedächtnis
Keine der drei menschlichen Rollen (Architekt, Business Analyst, UX Designer) schreibt den Code selbst. Das übernimmt eine Menge wiederholbarer Verfahren: die Skills.
Hier zeigt sich der Unterschied zwischen zwei Wissensarten:
- Deklaratives Wissen (Faktenwissen): Die Spezifikation und die Leitplanken halten fest, was entschieden wurde.
- Prozedurales Wissen (Verfahrenswissen): Die Skills halten fest, wie man aus diesen Vorgaben tatsächlich etwas baut.
Die goldene Regel: Definiere das Verfahrenswissen (Wie man baut) in wiederholbaren Skills, aber lass sie niemals das Faktenwissen (Was gebaut wird) erraten. Ein Skill führt Regeln strikt aus und stoppt sofort, wenn eine Spezifikation unvollständig ist.
AUSZUG: SKILL-DEFINITION IMPLEMENT-USE-CASE
name: implement-use-case
description: Turn an already written Use Case doc into working code against the harness.
instructions:
Before writing any code, trace every Open Decision and Invariant
the Use Case cites. If a citation points to an ID that does not
exist in the Domain Model doc, STOP and flag it rather than
guessing what it might have meant.
Was „STOP and flag“ in der Praxis bedeutet: Der Agent bricht die Session nicht ab, er pausiert sie. Die offene Frage geht als Rückfrage an die verantwortliche Rolle zurück, meist an den Business Analyst bei einer fehlenden Anforderung, an den Architekten bei einer Lücke in den Leitplanken. Bis die Antwort da ist, wird nichts geraten und nichts implementiert. Sobald die Entscheidung in Spezifikation oder Leitplanken eingetragen ist, nimmt der Agent die Session mit dem neuen Stand wieder auf.
Die Prüfung (Audit) – Wie wir die Lücke schlossen
Als das Team die Sicherheitslücke der Rechnungs-URL untersuchte, wurde klar: Sie war nie die Entscheidung eines einzelnen Moduls, sondern eine Regel, die alle für „selbstverständlich“ hielten.
Behoben wurde das Problem an zweierlei Stellen:
- Der Rechnungsabruf prüft nun die Eigentümerschaft.
- Die Regel wurde global in die Leitplanken aufgenommen.
AUSZUG: LEITPLANKEN (ERGÄNZUNG NACH DEM VORFALL)
Rule: Any endpoint returning an entity by ID MUST verify that the requester
owns it before the response is built. No exception—not even for internal tools.
Die Übersicht: Drei Rollen, ein geliehenes Gedächtnis
Ein AI-Agent vergisst alles. Jedes Mal. Damit KI im Unternehmen trotzdem verlässlich Software entwickelt, verschieben wir das Projektgedächtnis aus dem flüchtigen Chatfenster in strukturierte Artefakte.
Drei menschliche Rollen definieren das Faktenwissen (Was gebaut wird). Wiederholbare Skills liefern das Verfahrenswissen (Wie gebaut wird). Der Agent leiht sich dieses Wissen nur für die Dauer einer Arbeitssitzung aus.
Auf den Punkt gebracht
- Das geliehene Gedächtnis: Der AI-Agent besitzt kein eigenes Gedächtnis. Er liest Spezifikationen und Leitplanken beim Start der Session und vergisst sie beim Schliessen wieder.
- Die goldene Regel: Was nicht aufgeschrieben ist, existiert für die KI nicht. Selbstverständlichkeiten gibt es im KI-Engineering nicht.
- Engineering statt „Vibe Coding“: Der Unterschied zwischen Herumprobieren und professioneller KI-Entwicklung liegt nicht im Prompting, sondern in der Qualität der Spezifikationen und Leitplanken.
Wie Diselva hier unterstützt
Der Einstieg in KI-getriebene Software-Entwicklung ist ein Kultur- und Prozesswandel. Wir bei Diselva unterstützen Sie dabei, dieses Fundament aufzubauen:
Leitplanken verankern: Wir definieren mit Ihren Architekten die technischen Standards und Sicherheitsregeln (Harness).
Spezifikationen schärfen: Wir etablieren Strukturen für Use Cases und Invarianten, die KI-Agenten missverständnisfrei verstehen.
Custom AI Skills entwickeln: Wir bauen die passenden Verfahren, damit Ihre Agenten präzise nach Ihren Vorgaben coden.
Kontext-Kosten senken: Ein Gedächtnis, das bei jeder Sitzung komplett neu geladen wird, hat einen Preis. Wir strukturieren Leitplanken und Spezifikationen so, dass Agenten nur laden, was sie tatsächlich brauchen.
Machen Sie das Wissen Ihres Projekts unabhängig vom Kontextfenster einzelner Chats – sprechen Sie uns an.