Erfahre, wie KI vage Prompts in produktionsreife Architekturen verwandelt: Anforderungen formulieren, Annahmen sichtbar machen, Kompromisse abwägen und Designs validieren.
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.
Produktionsreif ist nicht „hat Diagramme“. Es bedeutet, dass das Design explizit adressiert:
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.
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.
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.
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.
Mache „gut" messbar. Bevorzuge eine Mischung aus Produkt- und Betriebskennzahlen.
Wähle eine kleine Menge (3–5). Zu viele Metriken erzeugen Verwirrung; zu wenige verbergen Risiken.
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.
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.
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.
Ziehe konkrete Verhaltensweisen und die betroffenen Teile heraus:
Ein guter Check: Kannst du für jede Anforderung auf einen Screen, Endpoint oder Hintergrundjob zeigen?
Diese formen die Architektur stärker, als die meisten erwarten. Übersetze vage Worte in messbare Ziele:
Halte Grenzen früh fest, damit du kein ideales System entwirfst, das niemand liefern kann:
Schreibe ein paar „Done means…"-Aussagen, die jeder verifizieren kann, z. B.:
Diese Anforderungen und Beschränkungen werden die Eingabe für die Kandidatenarchitekturen, die du als Nächstes vergleichst.
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.
Schreibe die Defaults auf, die Menschen üblicherweise implizieren:
Diese Annahmen prägen Entscheidungen wie Caching, Queues, Storage, Monitoring und Kosten stark.
Bitte die KI, eine einfache Tabelle oder drei kurze Listen zu erstellen:
Das verhindert, dass die KI (und das Team) Mutmaßungen als Fakten behandelt.
Nützliche Fragen sind z. B.:
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.
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.
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.
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.
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.
Nenne die Unterschiede explizit:
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.
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.
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:
KI ist nützlich, um ein Anfangs-Domainmodell aus dem Prompt vorzuschlagen; du bestätigst dann, was real vs. impliziert ist.
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.
Skizziere den Pfad, den Daten durch das System nehmen:
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.
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.
Ziele: eine kleine Menge Komponenten mit klarer Ownership. Ein guter Check: „Wenn das kaputtgeht, wer repariert es und was ändert sich?" Beispiele:
Wähle eine Standard-Kommunikationsart und begründe Ausnahmen:
Die KI kann helfen, jeden Use Case der einfachsten Schnittstelle zuzuordnen, die Latenz- und Zuverlässigkeitsanforderungen erfüllt.
Liste Drittanbieter und entscheide, was passiert, wenn sie ausfallen:
Schreibe eine kompakte Integrationsübersicht:
Diese Karte wird zum Rückgrat für Implementierungs-Tickets und Review-Diskussionen.
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.
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).
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.
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.
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.
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.
| Option | Kosten | Geschwindigkeit zum Launch | Einfachheit | Skalierungs-Spielraum | Notizen / Wann erneut prüfen |
|---|---|---|---|---|---|
| Managed Services (DB, Queues, Auth) | Mittel–Hoch | Hoch | Hoch | Hoch | Überprüfen, wenn Vendor-Limits/Features problematisch werden |
| Self-hosted Kernkomponenten | Niedrig–Mittel | Niedrig–Mittel | Niedrig | Mittel–Hoch | Überprüfen, wenn Ops-Burden Team überlastet |
| Monolith zuerst | Niedrig | Hoch | Hoch | Mittel | Aufsplitten bei Bedarf an Deploy-Frequenz/Teamgröße |
| Microservices früh | Mittel–Hoch | Niedrig | Niedrig | Hoch | Nur bei sofortigem Bedarf an unabhängiger Skalierung |
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.
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.
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.
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.
Erstelle für jede Schlüsselentscheidung ein Architecture Decision Record (ADR) mit kurzem, konsistentem Format:
KI ist nützlich, um Optionen zusammenzufassen, Tradeoffs aus Diskussionen zu extrahieren und ADR-Entwürfe zu erstellen, die du dann prüfst.
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:
Das macht künftige Änderungen zu geplanten Schritten, nicht zu Feuerübungen.
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.
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.
Nutze eine kurze Checkliste, um wichtige Fragen früh zu stellen:
Halte das Ergebnis konkret: „Was tun wir?" und „Wer ist verantwortlich?" statt allgemeiner Absichten.
Statt eines einzelnen Durchsatzschätzwerts liefere Last- und Kostenbereiche, die Unsicherheit widerspiegeln:
Fordere die KI auf, ihre Rechnungen und Annahmen zu zeigen und prüfe sie gegen aktuelle Analytics oder vergleichbare Systeme.
Liste kritische Abhängigkeiten (LLM-Provider, Vector-DB, Queue, Auth-Service). Für jede Frage:
Mache Reviews explizit:
Bei offenen Meinungsverschiedenheiten protokolliere sie als ausstehende Entscheidungen mit Owners und Terminen — und fahre dann mit Klarheit fort.
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.
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.
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.
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.)
Fordere einen ersten Entwurf an und bitte dann sofort um Kritik:
Das verhindert, dass das Modell zu früh an einer einzigen Lösung kleben bleibt.
KI kann selbstbewusst klingen und trotzdem falsch liegen. Häufige Probleme:
Wenn du willst, kannst du Ausgaben als leichte ADRs erfassen und sie neben dem Repo ablegen (siehe /blog/architecture-decision-records).
Ein vager Prompt: „Baue ein System, das Kunden benachrichtigt, wenn eine Lieferung verspätet ist."
KI hilft, das in konkrete Bedürfnisse zu übersetzen:
Zwei Frühe Fragen drehen das Design oft um:
Diese Annahmen niederzuschreiben verhindert, dass du schnell das Falsche baust.
KI schlägt Kandidaten vor:
Option 1: Synchronous API: Carrier-Webhook → Delay-Scoring-Service → Notification-Service
Option 2: Queue-basiert: Webhook → Event in Queue → Worker scoriert Verzögerungen → Notifications
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.
Liefergegenstände, damit es baubar wird:
"Prompt to architecture" ist der Ablauf, der eine Absicht (z. B. „ein Kundenportal bauen") in einen umsetzbaren Plan übersetzt: Anforderungen, Annahmen, Kandidatenoptionen, explizite Entscheidungen und eine End-to-End-Sicht auf Komponenten und Datenflüsse.
Behandle KI-Ausgaben als Vorschläge, die du testen und anpassen musst — nicht als endgültige Antworten.
Produktionsreif bedeutet, dass das Design explizit folgende Punkte abdeckt:
Diagramme helfen, sind aber nicht die Definition.
Formuliere 1–2 Sätze, die folgendes angeben:
Wenn der Prompt keinen realen Nutzer oder keine Dringlichkeit nennt, frag danach — sonst kannst du später keine Prioritäten für Tradeoffs setzen.
Wähle 3–5 messbare Metriken, die Produkt- und Betriebsziele mischen, z. B.:
Zu viele Metriken verwässern Prioritäten; zu wenige verbergen Risiken.
Liste frühe, meist unausgesprochene Defaults auf (Traffic, Datenqualität, Nutzerakzeptanz von Verzögerungen, On-Call-Abdeckung) und unterteile dann in:
Dokumentiere Annahmen explizit (wer/wann bestätigt), damit sie später hinterfragt werden können.
Vergleiche mehrere praktikable Optionen und wähle eine Default mit klaren Wechselbedingungen, z. B.:
Ziel: nachvollziehbare Tradeoffs, nicht die eine perfekte Lösung.
Benenne Kern-Domain-Objekte (Nomen wie User, Order, Ticket, Event) und definiere für jedes:
Für jede Abhängigkeit (Zahlungen, Messaging, LLMs, interne APIs) definiere:
Geh davon aus, dass Rate-Limits existieren, und baue Backpressure, damit Spikes nicht in Kaskadenausfälle führen.
Nutze ADRs (Architecture Decision Records), um zu dokumentieren:
Füge „Exit Ramps“ mit Triggern hinzu (z. B. „bei > X RPS: Read-Replicas einführen“) und versioniere ADRs; eine Vorlage kann unter einer relativen URL wie /blog/adr-template liegen.
Gib der KI eine enge Box: Ziel, Nutzer, Skalierung, Constraints (Budget, Deadlines, Compliance, Stack) und fordere sie auf, zuerst:
Führe dann „kritisiere und verfeinere“-Schleifen durch. Achte auf selbstbewusste, nicht überprüfbare Aussagen und fordere explizite Unsicherheiten ein.
Stimme Speicherung auf Zugriffsmuster ab (OLTP vs. Analytics) und skizziere den End-to-End-Datenfluss (Ingestion → Validierung/Anreicherung → Aufbewahrung/Löschung).