Wie KI vage Prompts in produktionsreife Architekturen verwandelt

Was „Prompt to Architecture" wirklich bedeutet

Ein „vager Prompt" ist der normale Startpunkt: die meisten Ideen beginnen als Absicht, nicht als Spezifikation: „Bau ein Kundenportal“, „Füge KI-Suche hinzu“ oder „Stream Events in Echtzeit“. Menschen kennen das gewünschte Ergebnis, aber noch nicht die Grenzen, Risiken oder technischen Entscheidungen, die es produktionsfähig machen.

„Prompt to architecture" ist der Workflow, der diese Absicht in einen kohärenten Plan übersetzt: was gebaut wird, wie die Teile zusammenpassen, wo Daten fließen und was wahr sein muss, damit es in Produktion funktioniert.

Was „produktionsreife Architektur" bedeutet

Produktionsreif ist nicht „hat Diagramme“. Es bedeutet, dass das Design explizit adressiert:

• Zuverlässigkeit: was kaputtgehen kann, wie es sich erholt und was unter Last passiert
• Sicherheit: wie Zugriff kontrolliert wird, wie Secrets gespeichert werden und wie Bedrohungen gemindert werden
• Kosten: was die Ausgaben antreibt und wie sie überwacht/gestoppt werden
• Betriebsfähigkeit: Monitoring, Backups, Deployments und wie du Fehler um 2 Uhr morgens debuggen kannst

Wo KI hilft — und wo sie irreführen kann

KI ist stark darin, frühes Denken zu beschleunigen: Kandidatenarchitekturen zu generieren, gängige Muster vorzuschlagen (Queues, Caches, Service-Grenzen), fehlende nicht-funktionale Anforderungen aufzuspüren und Schnittstellenverträge oder Checklisten zu entwerfen.

KI kann irreführen, wenn sie über Details selbstbewusst spricht, die sie nicht verifizieren kann: Technologien ohne Kontext auswählt, operative Komplexität unterschätzt oder Beschränkungen überspringt, die nur eure Organisation kennt (Compliance, vorhandene Plattformen, Teamfähigkeiten). Behandle Ausgaben als Vorschläge, die herausgefordert werden müssen, nicht als fertige Antworten.

Was dieser Beitrag abdeckt — und was nicht

Dieser Beitrag beschreibt einen praktischen, wiederholbaren Workflow vom Prompt → Anforderungen → Annahmen → Optionen → Entscheidungen, mit nachvollziehbaren Tradeoffs.

Er ersetzt nicht domänenspezifisches Fachwissen, detaillierte Sizing-Übungen oder ein Security-Review — und er behauptet nicht, es gäbe eine einzige „richtige" Architektur für jeden Prompt.

Schritt 1: Den Prompt in eine klare Problemstellung überführen

Ein vager Prompt mischt oft Ziele („Dashboard bauen"), Lösungen („Microservices verwenden") und Meinungen („mache es schnell"). Bevor du Komponenten skizzierst, brauchst du eine Problemstellung, die spezifisch genug ist, um getestet und diskutiert zu werden.

Problemstellung (wer braucht was und warum jetzt)

Schreibe ein bis zwei Sätze, die den primären Nutzer, die Aufgabe und die Dringlichkeit nennen.

Beispiel: „Kunden-Support-Manager brauchen eine einzige Ansicht über offene Tickets und SLA-Risiken, damit sie täglich priorisieren und verpasste SLAs dieses Quartal reduzieren können."

Wenn der Prompt keinen realen Nutzer nennt, frag nach. Wenn kein Warum genannt wird, kannst du später Tradeoffs nicht sinnvoll gewichten.

Erfolgsmessgrößen (wie du weißt, dass es funktioniert)

Mache „gut" messbar. Bevorzuge eine Mischung aus Produkt- und Betriebskennzahlen.

• Produkt: Zeit zur Erledigung der Hauptaufgabe, Adoptionsrate, Fehlerquote, Conversion, NPS
• Betrieb: p95-Latenz, Uptime-Ziel, Kosten pro Anfrage, On-Call-Pages/Woche

Wähle eine kleine Menge (3–5). Zu viele Metriken erzeugen Verwirrung; zu wenige verbergen Risiken.

User Journeys und Schlüsselflüsse

Beschreibe den „Happy Path" in einfacher Sprache und liste dann Edge-Cases, die die Architektur formen.

Happy-Path-Beispiel: Nutzer meldet sich an → sucht einen Kunden → sieht aktuellen Status → aktualisiert ein Feld → Audit-Log wird geschrieben.

Frühe Edge-Cases: offline/schlechte Verbindung, partielle Berechtigungen, doppelte Datensätze, Massenimporte, Timeouts, Retries und Verhalten bei ausgefallener Abhängigkeit.

Out-of-scope (um Design-Creep zu verhindern)

Führe auf, was in dieser Version nicht gebaut wird: Integrationen, die du noch nicht unterstützt, erweiterte Analytics, Multi-Region, kundenspezifische Workflows oder vollständige Admin-Tools. Klare Grenzen schützen Termine und erleichtern spätere „Phase 2"-Gespräche.

Sobald diese vier Stücke geschrieben sind, wird der Prompt zu einem geteilten Vertrag. KI kann beim Verfeinern helfen, aber sie sollte ihn nicht erfinden.

Schritt 2: Anforderungen und Beschränkungen extrahieren

Ein vager Prompt vermischt oft Ziele („einfach machen"), Features („Benachrichtigungen senden") und Präferenzen („serverless verwenden"). Dieser Schritt trennt sie in eine Liste von Anforderungen, gegen die du entwerfen kannst.

Funktionale Anforderungen (was es tun muss)

Ziehe konkrete Verhaltensweisen und die betroffenen Teile heraus:

• Features: Nutzerregistrierung/Login, Suche, Checkout, Admin-Dashboard, Audit-Logs
• Daten: was du speicherst (Nutzer, Bestellungen, Events), wie lange, und wer Zugriff hat
• Integrationen: Payment-Provider, Email/SMS, CRM, Analytics, bestehende interne APIs

Ein guter Check: Kannst du für jede Anforderung auf einen Screen, Endpoint oder Hintergrundjob zeigen?

Nicht-funktionale Anforderungen (wie gut es das tun muss)

Diese formen die Architektur stärker, als die meisten erwarten. Übersetze vage Worte in messbare Ziele:

• Latenz: „Seiten laden schnell" → „95 % der Anfragen unter 300 ms."
• Uptime: „Immer verfügbar" → „99,9 % monatliche Verfügbarkeit."
• Privacy/Compliance: „EU-Kunden handhaben" → „GDPR-Basics: Löschanfragen, Datenexport, minimale Aufbewahrung."

Restriktionen (was du nicht ändern kannst)

Halte Grenzen früh fest, damit du kein ideales System entwirfst, das niemand liefern kann:

• Budget & Zeitrahmen: fixer Launch-Termin, Cloud-Spend-Limits
• Teamfähigkeiten: starkes Python, begrenzte Kubernetes-Erfahrung
• Bestehende Systeme: muss bestehende DB, SSO oder Message-Bus nutzen

Akzeptanzkriterien in Klartext

Schreibe ein paar „Done means…"-Aussagen, die jeder verifizieren kann, z. B.:

• „Ein neuer Nutzer kann sich registrieren, E-Mail bestätigen und sich innerhalb von 2 Minuten einloggen."
• „Support kann eine Rückerstattung durchführen und der Kunde erhält innerhalb 1 Minute eine Bestätigung."
• „Personenbezogene Daten können auf Anfrage gelöscht werden, inklusive Backups innerhalb von 30 Tagen."

Diese Anforderungen und Beschränkungen werden die Eingabe für die Kandidatenarchitekturen, die du als Nächstes vergleichst.

Schritt 3: Annahmen und Unbekanntes früh sichtbar machen

Ein vager Prompt scheitert selten, weil die Technik schwer ist — er scheitert, weil alle stillschweigend fehlende Details unterschiedlich ausfüllen. Bevor du eine Architektur vorschlägst, nutze KI, um diese stillen Annahmen ans Licht zu ziehen und das, was wahr ist, von dem zu trennen, was geraten ist.

Häufige versteckte Annahmen

Schreibe die Defaults auf, die Menschen üblicherweise implizieren:

• Traffic und Wachstum: bauen wir für 50 Nutzer/Tag oder für 50k gleichzeitige Nutzer? Ist die Nutzung spiky (z. B. Launches) oder stabil?
• Datenqualität: sind eingehende Daten sauber und strukturiert oder chaotisch mit Duplikaten und fehlenden Feldern?
• Nutzerverhalten: tolerieren Nutzer Verzögerungen? Wiederholen sie aggressive Retries? Erwarten sie Echtzeit-Updates?
• Operation: wer betreibt das System? Gibt es On-Call-Abdeckung? Sind Wochenend-Ausfälle akzeptabel?

Diese Annahmen prägen Entscheidungen wie Caching, Queues, Storage, Monitoring und Kosten stark.

„Bekannt" vs „Unbekannt" vs „Braucht Recherche" aufteilen

Bitte die KI, eine einfache Tabelle oder drei kurze Listen zu erstellen:

• Bekannt: Bestätigte Anforderungen aus Prompt/Stakeholdern
• Unbekannt: Fehlende Details, die sichere Entscheidungen verhindern
• Braucht Recherche: Fragen für Spikes, Vendor-Checks, Benchmarks, rechtliche Prüfung oder Nutzerforschung

Das verhindert, dass die KI (und das Team) Mutmaßungen als Fakten behandelt.

Fragen, die die KI stellen sollte, bevor sie sich auf ein Design festlegt

Nützliche Fragen sind z. B.:

• Was sind die Top-3 User Journeys und was bedeutet „schnell genug" für jede?
• Welche Daten müssen wie lange gespeichert werden und wer darf sie lesen?
• Welche Ausfallmodi sind akzeptabel (partieller Ausfall, verzögerte Verarbeitung, Read-Only-Modus)?
• Welche Integrationen existieren und wie sind deren Rate-Limits und Zuverlässigkeit?
• Welche Constraints sind fix: Budget, Deadline, Cloud/Provider, Compliance?

Annahmen dokumentieren, damit sie später angefochten werden können

Schreibe Annahmen explizit nieder („Annahme: Peak 2.000 requests/min", „Annahme: PII vorhanden"). Behandle sie als Entwurfs-Inputs, die du später erneut prüfst — idealerweise mit Angabe, wer wann bestätigt hat. Das erleichtert spätere Tradeoffs und Architekturänderungen zu erklären und rückgängig zu machen.

Schritt 4: Kandidatenarchitekturen vorschlagen, nicht nur eine Antwort

Ein vager Prompt impliziert selten eine einzige „richtige" Lösung. Der schnellste Weg zu einem produktionsreifen Plan ist, einige praktikable Optionen zu skizzieren, dann eine Default zu wählen und klar zu erklären, unter welchen Bedingungen du wechseln würdest.

Option A (Default zuerst): Einfacher Monolith + Managed Services

Für die meisten frühen Produkte: ein deploybares Backend (API + Business-Logik), eine einzelne Datenbank und ein kleiner Satz managed Services (Auth, Email, Objekt-Storage). Das hält Deploys, Debugging und Änderungen übersichtlich.

Wähle das, wenn: Team klein ist, Anforderungen noch in Bewegung sind und Traffic unsicher ist.

Option B: Standard modularer Monolith + Async-Jobs

Gleiches Deployable, aber mit expliziten internen Modulen (Billing, Users, Reporting) und einem Background-Worker für langsame Aufgaben (Importe, Notifications, KI-Aufrufe). Füge eine Queue und Retry-Policies hinzu.

Wähle das, wenn: du lang laufende Tasks, periodische Spitzen oder klarere Ownership willst — ohne in separate Services zu splitten.

Option C: Skalierbare Services (nur wenn die Anforderungen es verlangen)

Teile Komponenten in separate Services auf, wenn ein starker Treiber existiert: strikte Isolation (Compliance), unabhängiges Skalieren eines Hotspots (z. B. Media-Processing) oder separate Release-Zyklen.

Wähle das, wenn: du konkrete Lastmuster, Organisationsgrenzen oder Risikobeschränkungen benennen kannst, die den zusätzlichen Betriebsaufwand rechtfertigen.

Was sich zwischen den Optionen ändert

Nenne die Unterschiede explizit:

• Komponenten: Single API vs API + Worker vs mehrere Deployables
• Kosten: weniger Teile vs zusätzliche Queues, Monitoring und Service-zu-Service-Traffic
• Komplexität: einfachere lokale Entwicklung vs mehr Deployments, Versionierung und Ausfallmodi

Eine gute KI-gestützte Ausgabe ist eine kleine Entscheidungstabelle: „Default = A, wechsle zu B bei Background-Jobs, wechsle zu C wenn X Metrik/Constraint zutrifft." Das verhindert premature Microservices und hält die Architektur an realen Anforderungen fest.

Schritt 5: Daten und Grenzen modellieren

Viel Architektur dreht sich darum, was die Systemdaten sind, wo sie leben und wer sie ändern darf. Modellierst du das früh, werden Komponenten, Schnittstellen, Skalierung und Sicherheit weniger geraten.

Definiere die Kern-Domain-Objekte (und wer sie besitzt)

Nenne die paar Objekte, um die sich das System dreht — meist Nomen aus dem Prompt: User, Organization, Subscription, Order, Ticket, Document, Event. Für jedes Objekt halte fest:

• Source of truth: welches System darf schreiben?
• Leser: wer konsumiert es (andere Services, Analytics, Support)?
• Lifecycle: create/update/delete plus Soft-Delete-Regeln

KI ist nützlich, um ein Anfangs-Domainmodell aus dem Prompt vorzuschlagen; du bestätigst dann, was real vs. impliziert ist.

Wähle Speicherpattern passend zu Zugriffsmustern

Entscheide, ob ein Objekt primär transaktional (OLTP) — viele kleine Reads/Writes mit Konsistenzbedarf — oder analytisch ist (Aggregation, Trends, Reporting). Beides in einer DB zu mischen erzeugt oft Spannung.

Ein häufiges Pattern: OLTP-DB für die App und ein separates Analytics-Store, befüllt per Events oder Exports. Wichtig ist, Speicherung an Nutzung auszurichten, nicht an Intuition.

Plane den Datenfluss End-to-End

Skizziere den Pfad, den Daten durch das System nehmen:

• Ingestion: APIs, Uploads, Webhooks, Batch-Importe
• Transformation: Validierung, Anreicherung, Deduplikation
• Retention & Deletion: wie lange Daten bleiben und wie sie entfernt werden

Datenrisiken früh benennen

Nenne Risiken offen: PII-Handling, doppelte Datensätze, widersprüchliche Quellen (zwei Systeme beanspruchen Source-of-Truth), unklare Löschsemantik. Diese Risiken definieren Grenzen: was intern bleiben muss, was geteilt werden kann und was Audit-Trails/Access Controls braucht.

Schritt 6: Komponenten und Schnittstellen abbilden

Mit Grenzen und Daten klar, übersetze das in eine konkrete Komponentenkarte: was existiert, was besitzt es und wie spricht es mit anderen. Hier ist KI besonders nützlich als „Diagramm-Generator in Worten" — sie kann klare Trennungen vorschlagen und fehlende Schnittstellen aufspüren.

Module und Verantwortlichkeiten definieren

Ziele: eine kleine Menge Komponenten mit klarer Ownership. Ein guter Check: „Wenn das kaputtgeht, wer repariert es und was ändert sich?" Beispiele:

• API Gateway / BFF: Request-Routing, Auth-Enforcement, Rate-Limits
• Core Service(s): Geschäftsregeln und Workflows
• Data Store(s): Persistenz- und Query-Patterns (nicht nur „eine DB")
• Async Workers: lang laufende Tasks, Retries, Scheduled Jobs
• Observability: Logging, Metriken, Tracing (als erstklassige Komponenten)

Wie Komponenten kommunizieren (und warum)

Wähle eine Standard-Kommunikationsart und begründe Ausnahmen:

• REST/HTTP für einfache Request/Response und menschlich-debuggbare Flows
• Events / Pub-Sub wenn mehrere Konsumenten auf dieselbe Änderung reagieren
• Queues für Hintergrundarbeit, Glättung von Spitzen und zuverlässige Retries

Die KI kann helfen, jeden Use Case der einfachsten Schnittstelle zuzuordnen, die Latenz- und Zuverlässigkeitsanforderungen erfüllt.

Externe Abhängigkeiten und Ausfallverhalten

Liste Drittanbieter und entscheide, was passiert, wenn sie ausfallen:

• Timeouts, Retries mit Backoff und Circuit Breaker
• Degradierter Modus (Cache bedienen? Read-Only erlauben?)
• Klare Fehlerverträge (was Clients erwarten können)

Integrationskarte (Systeme, APIs, Auth)

Schreibe eine kompakte Integrationsübersicht:

• Payments → Provider-API (REST), OAuth2 client credentials, Idempotency-Keys
• Email/SMS → Messaging-API (REST), API-Key, Retry-Queue bei 5xx
• Analytics → Event-Stream, Service-Token, Drop-on-Overload-Policy

Diese Karte wird zum Rückgrat für Implementierungs-Tickets und Review-Diskussionen.

Schritt 7: Für Produktionsanforderungen designen (bevor du code schreibst)

Ein Design kann auf dem Whiteboard perfekt aussehen und am ersten Tag in Produktion scheitern. Mache vor dem Coden den „Produktionsvertrag" explizit: wie sich das System unter Last, bei Fehlern und unter Angriff verhält — und wie du das erkennen wirst.

Zuverlässigkeit: Ausfallpfade planen

Definiere, wie das System sich bei langsamen oder ausgefallenen Abhängigkeiten verhält. Füge Timeouts, Retries mit Jitter und klare Circuit-Breaker-Regeln hinzu. Mache Operationen idempotent (sicherer Retry) mittels Request-IDs oder Idempotency-Keys.

Wenn du Drittanbieter aufrufst, gehe von Rate-Limits aus und baue Backpressure: Queues, begrenzte Parallelität und Graceful Degradation (z. B. „später versuchen" statt Überlast).

Sicherheit: wer darf was

Spezifiziere Authentifizierung (wie sich Nutzer identifizieren) und Autorisierung (was sie dürfen). Schreibe die wichtigsten Bedrohungsszenarien nieder: gestohlene Tokens, Missbrauch öffentlicher Endpoints, Injection-Angriffe oder Privilegieneskalation.

Definiere auch den Umgang mit Secrets: wo sie leben, wer sie lesen kann, Rotationsrhythmus und Audit-Trails.

Performance: Ziele, keine Gefühlswerte

Setze Kapazitäts- und Latenzziele (auch grob). Wähle dann Taktiken: Caching (was, wo, TTL), Batching für chatty Calls, Async Work via Queues für lange Tasks und Limits zum Schutz gemeinsamer Ressourcen.

Observability: Du kannst nicht reparieren, was du nicht siehst

Entscheide dich für strukturierte Logs, Schlüsselmessgrößen (Latenz, Fehlerquote, Queue-Depth), verteilte Tracing-Grenzen und Basis-Alerts. Verknüpfe jedes Alert mit einer Aktion: wer reagiert, was zu prüfen ist und wie ein „Safe Mode" aussieht.

Behandle diese Entscheidungen als erstklassige Architektur-Elemente — sie formen das System genauso wie Endpunkte und Datenbanken.

Schritt 8: Tradeoffs explizit und nachvollziehbar machen

Architektur ist keine einzelne „beste" Antwort — es ist eine Sammlung von Entscheidungen unter Constraints. KI ist nützlich, weil sie Optionen schnell aufzählt, aber du brauchst ein klares Protokoll, warum du einen Weg wählst, was du aufgegeben hast und wann du später wechseln würdest.

Nutze eine einfache Tradeoff-Tabelle

Entscheide, wo du Risiko akzeptierst vs. in Schutzmaßnahmen investierst

Schreibe auf, welche Ausfälle akzeptabel sind (z. B. gelegentlich verzögerte E-Mails) und welche Bereiche „nicht ausfallen dürfen" (z. B. Zahlungen, Datenverlust). Platziere Safeguards dort, wo Fehler teuer sind: Backups, Idempotenz, Rate-Limits und klaren Rollback-Pfaden.

Operative Tradeoffs, die dein Team betreffen

Manche Designs erhöhen On-Call-Last und Debugging-Schwierigkeit (mehr Teile, mehr Retries, mehr verteilte Logs). Bevorzuge Entscheidungen, die zur Support-Reality passen: weniger Services, klarere Observability und vorhersehbare Ausfallmodi.

Technologische Tradeoffs: Managed vs Self-hosted

Mach Entscheidungskriterien explizit: Compliance, Anpassungsbedarf, Latenz, Staffing. Wenn du Self-hosted wegen Kosten wählst, notiere die versteckten Preise: Patchen, Upgrades, Kapazitätsplanung und Incident Response.

Schritt 9: Entscheidungen, Alternativen und Reversibilität erfassen

Gute Architekturen entstehen durch viele kleine Entscheidungen. Leben diese nur in Chats oder im Kopf, wiederholt das Team Debatten, liefert uneinheitlich und kämpft bei geänderten Anforderungen.

ADRs nutzen, um Entscheidungen durchsuchbar zu machen

Erstelle für jede Schlüsselentscheidung ein Architecture Decision Record (ADR) mit kurzem, konsistentem Format:

• Kontext: welches Problem und welche Constraints
• Entscheidung: was gewählt wurde
• Alternativen: 2–3 plausible Optionen
• Warum: Begründung und Tradeoffs
• Konsequenzen: was möglich wird und was limitiert ist

KI ist nützlich, um Optionen zusammenzufassen, Tradeoffs aus Diskussionen zu extrahieren und ADR-Entwürfe zu erstellen, die du dann prüfst.

„Exit Ramps" ins Design einbauen

Annahmen ändern sich: Traffic wächst schneller, Compliance wird strenger oder ein externer API-Anbieter wird unzuverlässig. Für jede große Annahme füge eine Exit Ramp hinzu:

• „Wenn wir X requests/sec überschreiten, wechsle von Single-DB zu Read-Replicas."
• „Wenn Vendor API SLA < Y, füge Queue + Retry-Worker hinzu."

Das macht künftige Änderungen zu geplanten Schritten, nicht zu Feuerübungen.

Proof Points und Versionierung von Entscheidungen

Hänge testbare Meilensteine an risikoreiche Entscheidungen: Spikes, Benchmarks, kleine Prototypen oder Load-Tests. Halte erwartete Ergebnisse und Erfolgskriterien fest.

Versioniere ADRs, wenn Anforderungen sich verändern. Überschreibe nicht die Historie — hänge Updates an, damit du nachvollziehen kannst, was wann und warum geändert wurde. Wenn du eine leichtgewichtige Struktur brauchst, verlinke z. B. /blog/adr-template.

Schritt 10: Architektur mit Reviews und Evidenz validieren

Ein Entwurfs-Diagramm ist nicht „fertig" — fertig ist, wenn diejenigen, die bauen, sichern, betreiben und bezahlen, zustimmen, dass es funktioniert — und wenn du für die kniffligen Teile Evidenz hast.

Führe ein fokussiertes Architecture Review durch

Nutze eine kurze Checkliste, um wichtige Fragen früh zu stellen:

• Sicherheit: Auth/Autz-Modell, Secrets-Handling, Least-Privilege, Audit-Logs
• Privatsphäre: Datenklassifizierung, Retention, Zugriffskontrollen, PII-Flow-Mapping, Löschanfragen
• Ausfallmodi: Degradiertes Verhalten, Retries/Backoff, Idempotenz, Dead-Letter-Queues, Rate-Limits
• Operative Bereitschaft: Monitoring, Alerting, Runbooks, On-Call-Ownership, Backup/Restore

Halte das Ergebnis konkret: „Was tun wir?" und „Wer ist verantwortlich?" statt allgemeiner Absichten.

Mit Zahlen validieren (Bereiche, keine Wunschwerte)

Statt eines einzelnen Durchsatzschätzwerts liefere Last- und Kostenbereiche, die Unsicherheit widerspiegeln:

• Traffic: P50 / P95 Anfragen pro Sekunde (z. B. 50–200 RPS typisch, 500–1.000 RPS Peak)
• Speicherwachstum: monatliche Range plus Retention-Annahmen
• Kosten-Treiber: API-Nutzung, Compute-Autoscaling, Data-Egress, Managed-DBs

Fordere die KI auf, ihre Rechnungen und Annahmen zu zeigen und prüfe sie gegen aktuelle Analytics oder vergleichbare Systeme.

Abhängigkeits- und Vendor-Risiko bewerten

Liste kritische Abhängigkeiten (LLM-Provider, Vector-DB, Queue, Auth-Service). Für jede Frage:

• Was bricht, wenn sie ausfällt?
• Wie schwer ist ein Providerwechsel?
• Gibt es vertragliche, regionale oder Compliance-Einschränkungen?

Menschliche Freigabe-Punkte definieren

Mache Reviews explizit:

• Produkt: User Flows, SLAs, Scope-Boundaries
• Security/Privacy: Threat-Model-Ergebnisse, Datenhandhabungsfreigaben
• Ops/SRE: Observability-Plan, Incident-Response, Kapazitätsannahmen
• Engineering: Schnittstellen, Milestones, Migrationsplan

Bei offenen Meinungsverschiedenheiten protokolliere sie als ausstehende Entscheidungen mit Owners und Terminen — und fahre dann mit Klarheit fort.

Wie man effektiv mit KI während des Designs zusammenarbeitet

KI kann ein starker Design-Partner sein, wenn du sie wie einen Junior-Architekten behandelst: schnell in der Optionserzeugung, aber bedarf klarer Kontexte, Prüfungen und Richtungen.

Prompts schreiben, die Annahmen und Constraints erzwingen

Beginne damit, der KI eine „Box" zu geben: Business-Ziel, Nutzer, Skalierung, Budget, Deadlines und Non-Negotiables (Stack, Compliance, Hosting, Latenz, Datenresidenz). Bitte sie dann, zuerst Annahmen und offene Fragen aufzulisten, bevor Lösungen vorgeschlagen werden.

Eine einfache Regel: Wenn eine Constraint wichtig ist, sag sie explizit — erwarte nicht, dass das Modell sie errät.

Wo eine „Vibe-Coding"-Plattform helfen kann

Wenn das Ziel ist, vom Architekturplan zum laufenden System zu kommen, ohne Entscheidungen in Handoffs zu verlieren, ist ein Workflow-Tool hilfreich. Plattformen wie Koder.ai können nützlich sein, weil derselbe Chat, der Anforderungen klärt, auch die Constraints in die Implementierung tragen kann: Planungsmodus, wiederholbare Iterationen und die Möglichkeit, Quellcode zu exportieren, wenn ihr bereit seid, die Pipeline zu übernehmen.

Das ersetzt nicht Architektur-Reviews — im Gegenteil: es erhöht die Anforderungen an Dokumentation von Annahmen und nicht-funktionalen Anforderungen, weil du schnell vom Vorschlag zur laufenden App wechseln kannst.

Wiederverwendbare Prompt-Templates

Verwende kurze Templates, die strukturierte Ausgaben liefern:

You are helping design a system.
Context: <1–3 paragraphs>
Constraints: <bullets>
Non-functional requirements: <latency, availability, security, cost>
Deliverables:
1) Assumptions + open questions
2) 2–3 candidate architectures with pros/cons
3) Key tradeoffs (what we gain/lose)
4) Draft ADRs (decision, alternatives, rationale, risks)

(Beachte: Codeblöcke in Backticks bleiben unverändert.)

Mit „kritik und verfeinern"-Schleifen iterieren

Fordere einen ersten Entwurf an und bitte dann sofort um Kritik:

• „Was ist in diesem Design brüchig oder riskant?"
• „Welche Anforderungen sind noch nicht erfüllt?"
• „Was würdest du vereinfachen, wenn wir nur die halbe Zeit hätten?"

Das verhindert, dass das Modell zu früh an einer einzigen Lösung kleben bleibt.

Auf häufige Fehlerarten achten

KI kann selbstbewusst klingen und trotzdem falsch liegen. Häufige Probleme:

• Halluzinierte Services/Features — fordere Links oder explizite Unsicherheit
• Ignorierte Constraints (Kosten, Datenresidenz, Teamfähigkeiten) — lass jede Designwahl auf Anforderungen zurückführen
• Überengineering — erzwinge eine „kleinstmögliche Architektur"-Option

Wenn du willst, kannst du Ausgaben als leichte ADRs erfassen und sie neben dem Repo ablegen (siehe /blog/architecture-decision-records).

Mini-Walkthrough: vom vagen Prompt zum bereit-bauplan

Ein vager Prompt: „Baue ein System, das Kunden benachrichtigt, wenn eine Lieferung verspätet ist."

1) In Anforderungen überführen

KI hilft, das in konkrete Bedürfnisse zu übersetzen:

• Nutzer: Operations-Team, Endkunden
• Kernfluss: Lieferstatus einlesen → Verzögerungsrisiko erkennen → benachrichtigen → Outcome nachverfolgen
• Nicht-funktional: Alerts innerhalb von 2 Minuten nach Statusänderung, 99,9 % Verfügbarkeit, Audit-Trail für Streitfälle

2) Annahmen, die die Architektur ändern

Zwei Frühe Fragen drehen das Design oft um:

• Annahme A: Statusupdates kommen in Echtzeit vom Carrier (Webhooks). Wenn ja, passt Event-Driven-Processing.
• Annahme B: Updates werden alle 15 Minuten gepollt. Dann brauchst du Scheduling, Rate-Limit-Handling und die 2-Minuten-SLA ist möglicherweise unmöglich ohne Input-Änderung.

Diese Annahmen niederzuschreiben verhindert, dass du schnell das Falsche baust.

3) Optionen → Tradeoff-Entscheidung

KI schlägt Kandidaten vor:

• Option 1: Synchronous API: Carrier-Webhook → Delay-Scoring-Service → Notification-Service

  • Pros: simpel, weniger Teile
  • Cons: Webhook-Timeouts können Updates verlieren; Spitzen können Scoring überlasten

• Option 2: Queue-basiert: Webhook → Event in Queue → Worker scoriert Verzögerungen → Notifications

  • Pros: puffert Spitzen, sichere Retries, bessere Observability
  • Cons: mehr Komponenten, eventual consistency

Tradeoff-Entscheidung: Wähle Queue-basiert, wenn Carrier-Zuverlässigkeit und Traffic-Spitzen Risiken darstellen; wähle synchron, wenn Volumen gering und Carrier-SLAs stark sind.

4) Finaler Plan und Deliverables

Liefergegenstände, damit es baubar wird:

• Kontext- und Sequenzdiagramme
• Datenmodell + Event-Schema
• ADRs, die Queue vs. Synchronous Entscheidung dokumentieren
• Runbooks (Ausfallmodi, Retries, On-Call-Checks)
• Backlog-Epics (Carrier-Integration, Scoring-Regeln, Notification-Templates, Monitoring)