Lerne erprobte Prompting‑Muster, die die KI zu klareren Anforderungen, modularen Designs und testbarem Code führen — und so Refactorings und Neuimplementierungen reduzieren.
„Sauberere Architektur“ in diesem Beitrag meint nicht ein bestimmtes Framework oder ein perfektes Diagramm. Es bedeutet, dass du das System einfach erklären kannst, es ändern kannst, ohne unzusammenhängende Teile zu brechen, und Verhalten ohne heroische Tests verifizieren kannst.
Klarheit heißt, der Zweck und die Struktur des Systems sind aus einer kurzen Beschreibung ersichtlich: was es tut, wer es nutzt, welche Daten es verarbeitet und was es niemals tun darf. In KI-unterstützter Arbeit bedeutet Klarheit auch, dass das Modell Anforderungen so wiedergeben kann, dass du diese abnickst.
Modularität heißt, Verantwortlichkeiten haben klare Grenzen. Jedes Modul hat eine Aufgabe, Inputs/Outputs und minimale Kenntnis der Interna anderer Module. Wenn die KI Code generiert, verhindert Modularität, dass Geschäftsregeln wild über Controller, UI und Datenzugriff verteilt werden.
Testbarkeit bedeutet, die Architektur macht „beweise, dass es funktioniert“ günstig. Geschäftsregeln sind ohne komplettes System testbar, Integrationstests fokussieren auf wenige Verträge anstatt jeden Codepfad.
Überarbeitungen entstehen meist nicht durch „schlechten Code“ — sie entstehen durch fehlende Zwänge, vagen Umfang und versteckte Annahmen. Beispiele:
KI kann dieses Fehlermuster beschleunigen, weil sie überzeugende Ergebnisse schnell liefert — so baut man leicht auf wackeligen Grundlagen auf.
Die folgenden Muster sind Vorlagen zum Anpassen, keine Zaubersprüche. Ihr eigentliches Ziel ist, die richtigen Gespräche früh zu erzwingen: Zwänge klären, Optionen vergleichen, Annahmen dokumentieren und Verträge definieren. Wenn du dieses Nachdenken überspringst, füllt das Modell die Lücken gerne selbst — und du bezahlst später dafür.
Du nutzt sie über den gesamten Delivery-Zyklus hinweg:
Wenn du einen vibe-coding-Workflow verwendest (das System wird per Chat generiert und iteriert), sind diese Checkpoints noch wichtiger. Beispielsweise kannst du in Koder.ai einen „Planungsmodus“-Loop laufen lassen, um Anforderungen und Verträge zu fixieren, bevor du React/Go/PostgreSQL-Code generierst, und dann Snapshots/Rollbacks nutzen, um sicher zu iterieren, wenn sich Annahmen ändern — ohne jede Änderung zur Überarbeitung zu machen.
Prompting-Muster sind dann am wertvollsten, wenn sie Entscheidungschaos reduzieren. Der Trick ist, sie als kurze, wiederholbare Checkpoints zu verwenden — bevor du coden, während du designst und bei Reviews — sodass die KI Artefakte produziert, die du wiederverwenden kannst, und nicht extra Text, durch den du dich wühlen musst.
Vor dem Coden: einen „Alignment“-Loop durchführen, um Ziele, Nutzer, Zwänge und Erfolgskriterien zu bestätigen.
Während des Designs: Muster verwenden, die explizite Trade-offs erzwingen (z. B. Alternativen, Risiken, Datengrenzen) bevor implementiert wird.
Während der Review: eine Checklist-Anfrage nutzen, um Lücken zu finden (Edge Cases, Monitoring, Security, Performance), solange Änderungen noch günstig sind.
Du erhältst bessere Ergebnisse mit einem kleinen, konsistenten Input-Bündel:
Wenn du etwas nicht weißt, sag es explizit und bitte die KI, Annahmen aufzulisten.
Statt „erkläre das Design“ fordere Artefakte an, die du in Docs oder Tickets einfügen kannst:
Mache 10–15-Minuten-Loops: Prompt → Überfliegen → Nachschärfen. Enthalte immer Akzeptanzkriterien (was wahr sein muss, damit das Design akzeptabel ist) und lass die KI sich selbst daran prüfen. Das verhindert endlose Redesigns und macht die Muster in den nächsten Abschnitten schnell anwendbar.
Die meisten „Architektur-Überarbeitungen“ entstehen nicht durch schlechte Diagramme — sie entstehen, weil das Richtige für das falsche (oder unvollständige) Problem gebaut wurde. Wenn du ein LLM früh nutzt, fordere nicht zuerst eine Architektur an. Bitte es, Unklarheiten offenzulegen.
Nutze das Modell als Requirements-Interviewer. Ziel ist eine kurze, priorisierte Spezifikation, die du bestätigen kannst, bevor Komponenten entworfen, Datenbanken gewählt oder APIs festgelegt werden.
Hier ist eine Copy-Paste-Vorlage, die du wiederverwenden kannst:
You are my requirements analyst. Before proposing any architecture, do this:
1) Ask 10–15 clarifying questions about missing requirements and assumptions.
- Group questions by: users, workflows, data, integrations, security/compliance, scale, operations.
2) Produce a prioritized scope list:
- Must-have
- Nice-to-have
- Explicitly out-of-scope
3) List constraints I must confirm:
- Performance (latency/throughput targets)
- Cost limits
- Security/privacy
- Compliance (e.g., SOC2, HIPAA, GDPR)
- Timeline and team size
4) End with: “Restate the final spec in exactly 10 bullets for confirmation.”
Context:
- Product idea:
- Target users:
- Success metrics:
- Existing systems (if any):
Du willst Fragen, die Entscheidungen erzwingen (nicht generisches „erzähle mehr“), plus eine Must-Have-Liste, die tatsächlich innerhalb deines Zeitplans fertigstellbar ist.
Behandle die „10 Bullets“-Wiederholung als Vertrag: füge sie in dein Ticket/PRD ein, hol dir ein kurzes Ja/Nein von Stakeholdern und gehe erst dann zur Architektur über. Dieser Schritt verhindert die häufigste Ursache für späte Refactors: Funktionen zu bauen, die nie wirklich erforderlich waren.
Wenn du mit Tools beginnst („Sollten wir Event Sourcing verwenden?“), entwirfst du oft für die Architektur statt für den Nutzer. Ein schnellerer Weg zu sauberer Struktur ist, die KI zuerst die User Journeys in einfacher Sprache beschreiben zu lassen und erst danach diese Journeys in Komponenten, Daten und APIs zu übersetzen.
Benutze dies als Startvorlage:
Dann fordere:
“Beschreibe den Schritt-für-Schritt-Ablauf für jede Aktion in einfacher Sprache.”
“Gib eine einfache Zustandsdiagramm-Beschreibung oder Zustandsliste (z. B. Draft → Submitted → Approved → Archived).”
“Liste Non-Happy-Path-Szenarien: Timeouts, Retries, Duplicate Requests, Cancellations und invalid inputs.”
Wenn die Flows klar sind, lass die KI sie auf technische Entscheidungen abbilden:
Erst danach bitte um einen Architektur-Sketch (Services/Module, Grenzen und Verantwortlichkeiten), der direkt an die Flow-Schritte gebunden ist.
Lass die KI abschließend jede Journey in testbare Akzeptanzkriterien umwandeln:
Dieses Muster reduziert Überarbeitungen, weil die Architektur aus dem Nutzerverhalten wächst — nicht aus Annahmen über Technologie.
Die meisten Architektur-Überarbeitungen entstehen nicht durch „schlechtes Design“ — sie entstehen durch versteckte Annahmen, die sich als falsch herausstellen. Wenn du ein LLM nach einer Architektur fragst, füllt es oft Lücken mit plausiblen Vermutungen. Ein Annahmen-Log macht diese Vermutungen früh sichtbar, solange Änderungen noch günstig sind.
Ziel ist eine klare Trennung zwischen Fakten, die du geliefert hast und Annahmen, die es erfunden hat.
Nutze dieses Prompt-Muster:
Template prompt “Before proposing any solution: list your assumptions. Mark each as validated (explicitly stated by me) or unknown (you inferred it). For each unknown assumption, propose a fast way to validate it (question to ask, metric to check, or quick experiment). Then design based only on validated assumptions, and call out where unknowns could change the design.”
Halte es kurz, damit es tatsächlich genutzt wird:
Füge eine Zeile hinzu, die das Modell seine Kipppunkte nennen lässt:
Dieses Muster wandelt Architektur in eine Reihe konditionaler Entscheidungen: du erhältst nicht nur ein Diagramm, sondern eine Karte dessen, was bestätigt werden muss, bevor du dich festlegst.
KI-Tools sind gut darin, eine einzelne „beste“ Lösung zu produzieren — oft ist das nur die erste plausible Option. Eine sauberere Architektur entsteht, wenn du früh einen Vergleich erzwingst, solange Änderungen noch günstig sind.
Formuliere ein Prompt, das mehrere Architekturen und eine strukturierte Tradeoff-Tabelle verlangt:
Propose 2–3 viable architectures for this project.
Compare them in a table with criteria: complexity, reliability, time-to-ship, scalability, cost.
Then recommend one option for our constraints and explain why it wins.
Finally, list “what we are NOT building” in this iteration to keep scope stable.
Context:
- Users and key journeys:
- Constraints (team size, deadlines, budget, compliance):
- Expected load and growth:
- Current systems we must integrate with:
Ein Vergleich zwingt das Modell (und dich), versteckte Annahmen offenzulegen: wo State liegt, wie Services kommunizieren, was synchron sein muss und was verzögert werden kann.
Die Kriterien-Tabelle verhindert Debatten wie „Microservices vs Monolith“ auf rein Meinungsbasis. Sie verankert die Entscheidung an dem, was euch tatsächlich wichtig ist — schnell ausliefern, Betriebsaufwand reduzieren oder Zuverlässigkeit erhöhen.
Akzeptiere nicht „es kommt darauf an“. Fordere eine klare Empfehlung und die spezifischen Zwänge, die sie optimiert.
Bestehe außerdem auf „was wir nicht bauen“. Beispiele: „Kein Multi-Region Failover“, „Kein Plugin-System“, „Keine Echtzeit-Benachrichtigungen“. Das verhindert, dass Architektur stillschweigend wächst, um Features zu unterstützen, die ihr noch nicht committed habt — und vermeidet Überraschungs-Überarbeitungen, wenn sich der Umfang ändert.
Die meisten Überarbeitungen passieren, weil Grenzen vage sind: alles „berührt alles“ und eine kleine Änderung wirkt sich im ganzen Code aus. Dieses Muster zwingt mit Prompts zu klarer Modulverantwortung, bevor über Frameworks oder Klassendiagramme debattiert wird.
Bitte die KI, Module und Verantwortlichkeiten zu definieren und was ausdrücklich nicht dazugehört. Fordere danach Schnittstellen (Inputs/Outputs) und Abhängigkeitsregeln, nicht einen Bauplan oder Implementierungsdetails.
Verwende das, wenn du ein neues Feature skizzierst oder einen unordentlichen Bereich refaktorierst:
Liste Module mit:
Definiere für jedes Modul nur Schnittstellen:
Abhängigkeitsregeln:
Future change test: Gegeben diese wahrscheinlichen Änderungen: <liste 3>, zeige, welches einzelne Modul jede Änderung aufnehmen sollte und warum.
Ziel sind Module, die du einem Teamkollegen in unter einer Minute beschreiben kannst. Wenn die KI ein „Utils“-Modul vorschlägt oder Geschäftslogik in Controllern platziert, hake nach: „Verschiebe Entscheidungsfindung in ein Domain-Modul und halte Adapter dünn.“
Am Ende hast du Grenzen, die künftige Anforderungen überstehen — weil Änderungen ein klares Zuhause haben und Abhängigkeitsregeln versehentliche Kopplungen verhindern.
Integrationsüberarbeitungen entstehen selten durch „schlechten Code“ — meist durch unklare Verträge. Wenn Datenmodell und API-Formen spät entschieden werden, füllt jedes Team (oder Modul) Lücken unterschiedlich aus und die nächste Iteration besteht im Replizieren und Abgleichen.
Beginne damit, Verträge zu prompten, bevor du über Frameworks, Datenbanken oder Microservices sprichst. Ein klarer Vertrag wird zur gemeinsamen Referenz für UI, Backend und Datenpipelines.
Verwende diesen frühen Prompt mit deinem KI-Assistenten:
Folge sofort mit:
Du willst konkrete Artefakte, nicht bloße Prosa. Zum Beispiel:
Subscription
Und eine API-Skizze:
POST /v1/subscriptions
{
"customer_id": "cus_123",
"plan_id": "pro_monthly",
"start_date": "2026-01-01"
}
201 Created
{
"id": "sub_456",
"status": "active",
"current_period_end": "2026-02-01"
}
422 Unprocessable Entity
{
"error": {
"code": "VALIDATION_ERROR",
"message": "start_date must be today or later",
"fields": {"start_date": "in_past"}
}
}
Lass die KI Regeln formulieren wie: „Additive Felder sind ohne Version-Bump erlaubt; Umbenennungen erfordern /v2; Clients müssen unbekannte Felder ignorieren.“ Dieser Schritt verhindert stille Breaking-Changes — und die Überarbeitungen, die darauf folgen.
Architekturen werden umgeschrieben, wenn „Happy-Path“-Designs mit echtem Traffic, fehlerhaften Abhängigkeiten und unerwartetem Nutzerverhalten kollidieren. Dieses Muster macht Zuverlässigkeit zu einem expliziten Design-Output, nicht zu einer Nach-Live-Herausforderung.
Verwende dies mit deiner gewählten Architektur-Beschreibung:
List failure modes; propose mitigations; define observability signals.
Für jeden Failure Mode:
- Was löst ihn aus?
- Nutzerauswirkung (was erlebt der Nutzer)
- Minderung (Design + Betrieb)
- Retries, Idempotency, Rate Limits, Timeouts-Überlegungen
- Observability: Logs/Metriken/Traces + Alert-Grenzwerte
Nenne die Schnittstellen, die ausfallen können: externe APIs, DB, Queues, Auth-Provider und Background-Jobs. Dann verlange konkrete Entscheidungen:
Beende das Prompt mit: „Gib eine einfache Checkliste zurück, die wir in 2 Minuten prüfen können.“ Eine gute Checkliste enthält Punkte wie: Abhängigkeits-Timeouts gesetzt, Retries begrenzt, Idempotenz für Create-/Charge-Aktionen implementiert, Backpressure/Rate-Limiting vorhanden, definierter Pfad für Graceful Degradation.
Fordere Events um Nutzer-Momente (nicht nur Systeminterna): „user_signed_up“, „checkout_submitted“, „payment_confirmed“, „report_generated“. Für jedes Event bitte um:
Das macht Zuverlässigkeit zu einem Design-Artefakt, das du prüfen kannst, bevor Code existiert.
Eine verbreitete Art, wie KI-unterstütztes Design Überarbeitungen erzeugt, ist das frühe Fördern „vollständiger“ Architekturen. Die Lösung: zwinge den Plan, mit der kleinsten nutzbaren Scheibe zu starten — eine, die Wert liefert, das Design validiert und spätere Optionen offenhält.
Verwende das, wenn die Lösung schneller wächst als die Anforderungen:
Template: „Schlage die kleinste nutzbare Scheibe vor; definiere Erfolgsmessungen; liste Follow-ups.“
Lass das Modell antworten mit:
Füge hinzu: „Gib eine phasierte Roadmap: MVP → v1 → v2, und erkläre, welches Risiko jede Phase reduziert.“ So bleiben spätere Ideen sichtbar, ohne sie in die erste Version zu zwingen.
Beispielhafte Ergebnisse:
Die mächtigste Zeile in diesem Muster ist: „Liste, was explizit für das MVP out-of-scope ist.“ Ausschlüsse schützen Architekturentscheidungen vor verfrühter Komplexität.
Gute Ausschlüsse sehen so aus:
Abschließend: „Wandle das MVP in Tickets um, jedes mit Akzeptanzkriterien und Abhängigkeiten.“ Das erzwingt Klarheit und entlarvt versteckte Kopplungen.
Eine solide Ticket-Aufteilung enthält typischerweise:
Wenn gewünscht, lass das Modell in eurem Team-Format ausgeben (z. B. Jira-Felder) und halte spätere Phasen als separates Backlog.
Eine einfache Methode, Architektur-Abdrift zu stoppen, ist, Klarheit durch Tests bevor du ein Design anforderst, zu erzwingen. Wenn du ein LLM bittest, zuerst Akzeptanztests zu schreiben, muss es Verhalten, Inputs, Outputs und Randfälle benennen. Das legt fehlende Anforderungen offen und treibt die Implementierung zu sauberen Modulgrenzen.
Nutze dies als „Gate“-Prompt, wenn du kurz davor bist, eine Komponente zu designen:
Folge mit: „Gruppiere die Tests nach Modulverantwortung (API-Layer, Domain-Logik, Persistence, externe Integrationen). Für jede Gruppe spezifizieren, was gemockt und was echt ist.“
Das drängt das LLM weg von verworrenen Designs, in denen alles alles berührt. Wenn es nicht erklären kann, wo Integrationstests beginnen, ist deine Architektur wahrscheinlich noch nicht klar.
Fordere: „Schlage einen Testdaten-Plan vor: Fixtures vs Factories, wie Randfälle generiert werden und wie Tests deterministisch bleiben. Liste, welche Abhängigkeiten in-memory-Fakes nutzen können und welche einen echten Dienst in CI brauchen."
Oft entdeckst du, dass ein „einfaches“ Feature eigentlich einen Vertrag, Seed-Dataset oder stabile IDs braucht — besser, das jetzt zu finden als später während einer Überarbeitung.
Beende mit einer leichten Checkliste:
Design-Reviews sollten nicht erst nach existierendem Code stattfinden. Mit KI kannst du eine „Pre-Mortem-Review“ auf deinen Architektur-Entwurf durchführen (auch nur ein paar Absätze oder ein Diagramm-in-Worten) und eine konkrete Liste von Schwächen bekommen, bevor sie zu Überarbeitungen führen.
Beginne mit einer direkten Reviewer-Haltung und zwinge zur Spezifikation:
Prompt: „Agier als Reviewer; liste Risiken, Inkonsistenzen und fehlende Details in diesem Design. Sei konkret. Wenn du etwas nicht beurteilen kannst, sage, welche Information fehlt.“
Füge deine Design-Zusammenfassung, Zwänge (Budget, Timeline, Team-Skills) und nicht-funktionale Anforderungen (Latenz, Verfügbarkeit, Compliance) bei.
Reviews scheitern, wenn Feedback vage ist. Bitte um eine priorisierte Liste von Fixes:
Prompt: „Gib mir eine priorisierte Punch-Liste. Für jeden Punkt: Severity (Blocker/High/Medium/Low), warum es wichtig ist, vorgeschlagene Lösung und den kleinsten Validierungsschritt.“
Das erzeugt handlungsbereite Tasks statt Debatten.
Eine nützliche Forcierung ist eine einfache Bewertung:
Prompt: „Assign a rewrite risk score from 1–10. Explain the top 3 drivers. What would reduce the score by 2 points with minimal effort?"
Ziel ist nicht Präzision, sondern die Oberfläche der annähernd rewrite-anfälligsten Annahmen.
Vermeide, dass die Review Scope aufbläht:
Prompt: „Provide a diff plan: minimal changes needed to reach the target design. List what stays the same, what changes, and any breaking impacts."
Wenn du dieses Muster iterativ anwendest, entwickelt sich die Architektur in kleinen, reversiblen Schritten — während die großen Probleme früh entdeckt werden.
Nutze dieses Pack als leichtgewichtigen Workflow, den du bei jedem Feature wiederholen kannst. Die Idee ist, Prompts zu ketten, sodass jeder Schritt ein Artefakt erzeugt, das der nächste wiederverwenden kann — so geht weniger Kontext verloren und es entstehen weniger Überraschungs-Überarbeitungen.
In der Praxis implementieren Teams diese Kette oft als wiederholbares „Feature-Rezept“. Wenn du mit Koder.ai baust, lässt sich dieselbe Struktur sauber auf einen chatgetriebenen Build-Prozess abbilden: Sammle die Artefakte an einem Ort, generiere die erste funktionierende Scheibe und iteriere mit Snapshots, damit Experimente reversibel bleiben. Wenn das MVP bereit ist, kannst du Quellcode exportieren oder deployen/hosten mit einer Custom-Domain — praktisch, wenn du die Geschwindigkeit KI-gestützter Lieferung willst, ohne dich an eine einzige Umgebung zu binden.
SYSTEM (optional)
You are a software architecture assistant. Be practical and concise.
Guardrail: When you make a recommendation, cite the specific lines from *my input* you relied on by quoting them verbatim under “Input citations”. Do not cite external sources or general industry claims.
If something is unknown, ask targeted questions.
1) REQUIREMENTS CLARIFIER
Context: <product/system overview>
Feature: <feature name>
My notes: <paste bullets, tickets, constraints>
Task:
- Produce: (a) clarified requirements, (b) non-goals, (c) constraints, (d) open questions.
- Include “Input citations” quoting the exact parts of my notes you used.
2) ARCHITECTURE OPTIONS
Using the clarified requirements above, propose 3 architecture options.
For each: tradeoffs, complexity, risks, and when to choose it.
End with a recommendation + “Input citations”.
3) MODULAR BOUNDARIES
Chosen option: <option name>
Define modules/components and their responsibilities.
- What each module owns (and does NOT own)
- Key interfaces between modules
- “Input citations”
4) DATA & API CONTRACTS
For each interface, define a contract:
- Request/response schema (or events)
- Validation rules
- Versioning strategy
- Error shapes
- “Input citations”
5) TEST-FIRST ACCEPTANCE
Write:
- Acceptance criteria (Given/When/Then)
- 5–10 critical tests (unit/integration)
- What to mock vs not mock
- “Input citations”
6) RELIABILITY + DESIGN REVIEW
Create:
- Failure modes list (timeouts, partial failure, bad data, retries)
- Observability plan (logs/metrics/traces)
- Review checklist tailored to this feature
- “Input citations”
Wenn du eine tiefere Begleitung willst, siehe /blog/prompting-for-code-reviews. Wenn du Tools oder Team-Rollout evaluierst, ist /pricing ein praktischer nächster Schritt.
In KI-unterstützter Arbeit bedeutet das außerdem: das Modell kann Anforderungen so zusammenfassen, dass du dem zustimmen würdest.
KI kann schnell überzeugenden Code und Designs liefern, wodurch es leicht wird, auf unsichere Annahmen aufzubauen. Diese Geschwindigkeit verstärkt typische Ursachen für Überarbeitungen wie:
Die Lösung ist nicht „weniger KI“, sondern Prompts, die Zwänge, Verträge und Annahmen früh sichtbar machen.
Nutze die Muster als kurze Checkpoints, die wiederverwendbare Artefakte erzeugen (nicht mehr Text):
Halte Iterationen bei : prompt → überfliegen → verschlanken → gegen Akzeptanzkriterien selbst prüfen.
Wenn etwas unbekannt ist: sag es und lass das Modell Annahmen explizit auflisten statt still zu raten.
Fordere Artefakte, die du in Docs, Tickets und PRs einfügen kannst:
So bleibt die KI-Ausgabe handlungsfähig und reduziert Rework durch „verlorenen Kontext“.
Nutze das Modell als Anforderungs-Interviewer. Lass es:
Beginne mit Rollen und Aktionen, dann fordere:
Erst wenn die Flows klar sind, mappe sie auf Entscheidungen wie: wo beginnt Validation vs. Business-Logik, wo ist Idempotenz nötig, was muss gespeichert vs. abgeleitet werden. Konvertiere abschließend die Flows in testbare Given/When/Then-Akzeptanzkriterien.
LLMs füllen Lücken oft mit plausiblen Annahmen. Eine Annahmenliste zwingt zur Trennung zwischen:
Fordere ein Log, das für jeden Eintrag markiert: validated / unknown, warum es relevant ist, wie man es schnell validiert (Frage/Metrik/Spike) und was sich ändern würde, wenn es falsch ist. Ergänze „Was würde deine Antwort ändern?“-Trigger (z. B. Nutzeranzahl, Latenzziele, Compliance), damit Entscheidungen konditional bleiben.
Lass das Modell 2–3 mögliche Architekturen vorschlagen und vergleiche sie in einer Tabelle nach Kriterien: Komplexität, Zuverlässigkeit, Time-to-Ship, Skalierbarkeit, Kosten. Fordere:
Das verhindert, dass die erste plausible Option standardmäßig übernommen wird und reduziert stille Scope-Expansion (häufige Ursache für Überarbeitungen).
Ein kontraktorientierter Ansatz macht Datenformen und Kompatibilitätsregeln explizit:
Wenn UI, Backend und Integrationen dasselbe Vertragsartefakt teilen, entfällt später viel Abstimmungsaufwand.
Behandle diese 10 Bullet-Points als Vertrag und validiere sie mit Stakeholdern bevor das Design beginnt.