In einem Prototyp ist ein Prompt eine Zeichenfolge, die Sie an einem Nachmittag geschrieben haben. Im Produktivbetrieb scheitert dieser Ansatz meist bereits im ersten Monat.
Sie möchten einen Teil der Anweisungen ändern, ohne andere anzutasten. Sie benötigen unterschiedliches Verhalten für verschiedene Kundentarife, möchten Versionen per A/B-Test vergleichen und bei Fehlern ein Rollback durchführen. Zudem müssen Sie wissen, wann und warum sich ein Prompt zuletzt geändert hat.
Ein Produktionsprompt-System verwaltet all dies. Es ist nicht „eine Zeichenfolge schreiben“. Es ist eine Architektur.
Dieser Artikel beschreibt diese Architektur: drei Ebenen, konsequentes Templating, Versionsverwaltung, Evals und betriebliche Praktiken, die Prompts von einzelnen Artefakten zu Infrastruktur machen.
Produktionsprompts bestehen aus zwei getrennten Artefakten: wiederverwendbaren Vorlagen und Daten je Anfrage. Versionieren Sie Vorlagen wie Code. Behandeln Sie gerenderte Prompts und Modellantworten als sensible Logs, sobald sie Nutzer-, Kunden- oder interne Daten enthalten.
Die drei Ebenen
Produktionsprompts bestehen aus drei klar getrennten Ebenen mit jeweils eigenen Zuständigkeiten:
Systemebene. Stabiles Verhalten, Identität, Einschränkungen. Änderungen sind selten. Wird von dem Team verwaltet, das das KI-Verhalten entwirft.
Entwicklerebene. Funktionsspezifische Anweisungen, Toolbeschreibungen und Anforderungen an das Ausgabeformat. Sie ändert sich mit dem Feature und wird vom zuständigen Feature-Team verwaltet.
Nutzerebene. Die konkrete Anfrage des Nutzers sowie dynamischer Kontext (Nutzerdaten, Gesprächsverlauf, abgerufenes Wissen). Sie unterscheidet sich bei jedem Aufruf.
Das Vermischen dieser Ebenen ist der häufigste Fehler bei Produktionsprompts. Ein Systemprompt wächst auf 5.000 Wörter und vereint Identität, Feature-Anweisungen und dynamischen Kontext; anschließend beschädigt eine einzelne Änderung andere Bereiche.
Die Trennung ist grundlegend:
┌─────────────────────────────────────┐
│ System prompt (stable) │ Identity, behavior, hard constraints
├─────────────────────────────────────┤
│ Developer prompt (per-feature) │ Feature instructions, tools, format
├─────────────────────────────────────┤
│ User prompt (per-call) │ User query, context, conversation
└─────────────────────────────────────┘
Die Modell-APIs unterstützen dies explizit:
- OpenAI: die Rollen
system,developerunduser. - Anthropic:
system, danachmessagesmit den Rollenuserundassistant. Toolbeschreibungen werden über einen separaten Parameter übergeben. - Gemini:
systemInstruction, danncontentsmit Rollen.
Verwenden Sie diese Unterschiede bewusst.
Ebene 1: Der Systemprompt
Der Systemprompt definiert, wer die KI ist und wie sie sich verhält. Er ändert sich selten.
Ein guter Systemprompt umfasst:
Identität. Wer die KI ist. „Du bist ein KI-Assistent für [Unternehmen], der sich auf [Bereich] spezialisiert.“
Stimme und Stil. Wie sie klingen soll. Spezifische Merkmale, nicht vage Beschreibungen.
Harte Einschränkungen. Dinge, die sie niemals tun darf – etwa bestimmte Inhalte ausgeben, bestimmte Entscheidungen treffen oder bestimmte Anweisungen ignorieren.
Verhaltensmuster. Wie sie übliche Situationen behandelt. Ablehnungen, Eskalationen, Unsicherheit.
Sicherheit und Compliance. Erforderliche Offenlegungen, regulatorische Regeln, Inhaltsrichtlinien.
Was er nicht enthalten sollte:
- Funktionsspezifische Anweisungen („für Verkaufs-E-Mails, mache X“).
- Dynamischen Kontext („die Bestellgeschichte des Nutzers ist…“).
- Tool-Beschreibungen (diese gehen anderswo hin).
- Dinge, die häufig geändert werden.
Ein guter Systemprompt umfasst 300–1000 Wörter. Bei größerem Umfang wird er schwer verwaltbar; bei geringerem ist das Verhalten möglicherweise nicht ausreichend spezifiziert.
Ein funktionierendes Template:
You are [name], an AI assistant for [company / context].
## Your role
[2-3 sentences on what you do]
## Voice and style
- [Specific trait 1]
- [Specific trait 2]
- [Specific trait 3]
- Do not [anti-pattern 1]
- Do not [anti-pattern 2]
## Hard constraints
- Never [hard rule 1]
- Never [hard rule 2]
- Always [hard rule 3]
## How to handle uncertainty
- If you don't know something factual: say so explicitly.
- If a user asks for something outside scope: offer what you can help with.
- If a request might cause harm: refuse and explain why.
## Format expectations
- Plain text by default
- Use markdown when displaying code or structured data
- Be concise; do not pad responses with filler
Dies ist der Kern. Jede Interaktion geht durch ihn. Änderungen sind bewusst und selten.
Ebene 2: Der Entwicklerprompt
Der Entwicklerprompt ist funktionspezifisch. Unterschiedliche Funktionen haben unterschiedliche Entwicklerprompts.
Ein Entwicklerprompt für eine Zusammenfassungsfunktion:
Task: produce a summary of the document below.
Requirements:
- 3-5 bullet points
- Each bullet is one complete sentence
- Focus on facts and concrete claims, not impressions
- If the document contains numbers, include the most important ones
- Do not include marketing language or speculation
- If the document is ambiguous about something important, note it
Format: plain markdown bullets, no preamble.
Ein Entwicklerprompt für eine Code-Überprüfungsfunktion:
Task: review the code diff below.
Output a JSON object with:
- summary: 1-2 sentence overview of the change
- concerns: array of specific issues (each: file, line, severity, description)
- suggestions: array of improvements (each: file, line, suggestion)
- approved: boolean (true if no blocking concerns)
Severity levels:
- "blocker": must be fixed before merge
- "warning": should be addressed but not blocking
- "nit": stylistic, optional
Focus on:
- Logic errors
- Security issues
- Performance issues
- Missing test coverage
- Unclear naming or structure
Skip:
- Formatting (handled by formatter)
- Subjective style preferences
Jede Funktion hat ihren eigenen Entwicklerprompt. Sie werden getrennt gespeichert, getrennt versioniert und getrennt bewertet.
Ebene 3: Der Nutzerprompt
Die Nutzerebene ist dynamisch. Sie enthält typischerweise:
Die tatsächliche Anfrage des Nutzers. „Fassen Sie dieses Dokument für mich zusammen.“
Der vom System abgerufene Kontext. Dokumente aus RAG, Kundenhistorie und Gesprächsverlauf.
Variablen je Aufruf. Nutzername, Zeitzone, Sprachpräferenz und Kontotarif.
Diese Ebene wird programmatisch zum Zeitpunkt des Aufrufs konstruiert. Die Struktur sieht in der Regel so aus:
{conversation_history_summary}
{retrieved_context}
User's request: {user_query}
Additional context:
- User name: {name}
- User timezone: {timezone}
- User tier: {tier}
Die genaue Struktur hängt von der Funktion ab. Das Prinzip: Daten kommen hierhin, nicht in den System- oder Entwicklerprompt.
Konsequentes Templating
Prompts im Produktivbetrieb werden aus Vorlagen erzeugt. Inline verkettete Zeichenfolgen sind ein Prototypmuster und skalieren nicht.
Ein einfaches Vorlagen-System:
from string import Template
SUMMARIZE_TEMPLATE = Template("""
$conversation_summary
Document to summarize:
$document
User's specific instructions: $user_instructions
""")
prompt = SUMMARIZE_TEMPLATE.substitute(
conversation_summary=summarize_conversation(history),
document=document_text,
user_instructions=user_query,
)
Für komplexere Fälle eignet sich eine Template-Bibliothek wie Jinja2 oder Handlebars mit Bedingungen und Teilvorlagen.
{% if user_tier == "enterprise" %}
You have access to advanced analysis features.
{% endif %}
{% if retrieved_context %}
Relevant context from your knowledge base:
{{ retrieved_context }}
{% endif %}
User's request: {{ user_query }}
Vorlagen helfen, Prompt Injection über Variablen zu verhindern – maskieren Sie Nutzereingaben, wo dies erforderlich ist –, ermöglichen bedingte Logik und halten die Promptstruktur konsistent.
Versionsverwaltung
Prompts sind Code. Speichern Sie sie in der Versionsverwaltung.
Ein funktionierendes Muster: ein prompts/-Verzeichnis in Ihrem Repository, mit einer Datei pro Prompt:
prompts/
system/
main.txt
customer-support.txt
code-assistant.txt
features/
summarize.txt
classify-ticket.txt
generate-email.txt
templates/
base.j2
Jede Datei enthält einen eigenständigen Prompt mit eigener Commit-Historie. Änderungen werden über Pull Requests geprüft; Produktiv-Deployments referenzieren konkrete Versionen.
Warum das wichtig ist:
- Diff-Sichtbarkeit. Wenn ein Prompt geändert wird, ist der Diff in der PR. Prüfer können genau sehen, was geändert wurde.
- Rollback. Wenn eine Änderung einen Fehler verursacht, können Sie zur vorherigen Version zurückkehren.
- Historie. „Wann haben wir die Rückerstattungsrichtlinie im Prompt geändert?“ „Warum ist dieser Absatz hier?“ – beides lässt sich mit
git blamebeantworten. - Tools. Linter, Validatoren, Eval-Suiten integrieren sich mit dateibasierten Prompts.
Vermeiden Sie Prompts als Zeichenfolgen im Code (schwer auffindbar und vergleichbar), ausschließlich in einem UI-Tool gespeicherte Prompts (die Versionshistorie gehört dem Tool, nicht Ihnen) sowie aus persönlichen Chatfenstern kopierte Prompts (nicht nachverfolgbar und nicht testbar).
Committen Sie keine Produktivgespräche, Kundendatensätze, Supporttickets, internen Dokumente oder gerenderten Prompts mit sensiblen Variablen. Die Versionsverwaltung ist für wiederverwendbare Vorlagen, Fixtures und bereinigte Eval-Beispiele bestimmt. Reale Traces gehören in ein Observability-System mit Aufbewahrungsregeln, Zugriffskontrolle und Schwärzung.
Prompts als Daten: externe Speicherung
Für häufig geänderte Prompts – A/B-Tests, Varianten nach Nutzertarif oder lokalisierte Prompts – ist eine rein dateibasierte Versionsverwaltung zu langsam.
Ein bewährtes Muster ist eine Datenbank oder ein Service, der Promptversionen samt Metadaten speichert.
prompt = prompt_service.get(
name="summarize",
version="v3",
locale="en",
user_tier="enterprise",
)
Der Dienst verwaltet:
- Aktuelle und historische Versionen jedes Prompts.
- Metadaten: wann hinzugefügt, von wem, warum.
- Eval-Scores, die jeder Version zugeordnet sind.
- Rollback-Funktion.
Tools: PromptLayer, Helicone oder eine interne Lösung. Für die meisten Teams genügt ein internes System mit einem einfachen Datenbankschema.
Die Oberfläche ist entscheidend. Sowohl Engineers als auch Fachbereiche wie Produkt und Content sollten Prompts bearbeiten können. Änderungen müssen jedoch vor der Freigabe geprüft werden und die Evals bestehen.
Durch Evals abgesicherte Änderungen
Jede Promptänderung durchläuft vor der Bereitstellung Evals. Für ernsthafte Produktivsysteme ist dies nicht verhandelbar.
Der Ablauf:
- Ein Engineer oder ein Fachanwender entwirft eine Promptänderung.
- Die Änderung wird gegen die Eval-Suite getestet.
- Eval-Ergebnisse werden zusammen mit der Änderung geprüft.
- Wenn die Evals bestehen – ohne Regressionen und idealerweise mit Verbesserungen –, kann die Änderung genehmigt werden.
- Genehmigte Änderungen werden deployed.
- Nach der Bereitstellung erfasst das Monitoring Probleme, die von den Evals übersehen wurden.
In der Praxis bedeutet dies, dass jeder Prompt eine Eval-Suite hat, und die Suite in der CI bei Promptänderungen läuft.
Ohne dieses Gate können Promptänderungen das System auf unvorhersehbare Weise beschädigen. Mit ihm können Sie schnell und kontrolliert vorgehen.
Eine praktische Freigabecheckliste
Bevor eine Promptversion produktiv geht, sollte eine kurze Checkliste verbindlich sein:
| Prüfung | Anforderung |
|---|---|
| Verantwortlichkeit | Für den Prompt sind ein Verantwortlicher und ein Prüfer benannt. |
| Anweisungsebenen | System-, Entwickler- und Nutzer/Kontextdaten sind getrennt. |
| Schema | Strukturierte Ausgaben haben ein Schema und einen Fehlerpfad. |
| Schutz vor Prompt Injection | Vom Nutzer bereitgestellte Inhalte sind klar abgegrenzt und werden niemals als Anweisung behandelt. |
| Evals | Der Kandidatenprompt besteht den Regressionstest und die Sicherheitsfälle. |
| Logs | Vorlagenversion, Modell, Latenz, Kosten sowie geschwärzte Eingaben und Ausgaben sind beobachtbar. |
| Rollback | Die vorherige, nachweislich funktionierende Version kann ohne Eingriff in den Code wiederhergestellt werden. |
Die begleitende Checkliste, die von diesem Artikel verlinkt wird, verwandelt diese Prüfungen in eine wiederholbare Freigabeprüfung.
A/B-Tests in der Produktion
Bei neuen Prompts liefern A/B-Tests gegen die bestehende Version mit einem kleinen Anteil des Produktivverkehrs reale Signale, die über Evals hinausgehen.
Muster:
- 95 % des Datenverkehrs verwenden den produktiven Prompt v3.
- 5 % erhält den neuen Kandidaten v4.
- Gemessen werden Nutzerfeedback, nachgelagerte Kennzahlen und Eval-Werte aus realem Datenverkehr.
- Sobald ausreichend Daten vorliegen, entscheiden Sie, ob v4 auf 100 % ausgerollt oder v3 beibehalten wird.
Tools: Feature Flags (LaunchDarkly oder intern), Prompt-Versionierungsdienste (PromptLayer) und individuelles Routing.
Hinweise:
- A/B-Tests erfassen nur gemessene Signale. Ohne Nutzerfeedback oder nachgelagerte Konversionskennzahlen liefert ein A/B-Test wenig Erkenntnis.
- Statistische Signifikanz erfordert Volumen. Für Features mit geringem Datenverkehr sind A/B-Tests schwierig.
- Führen Sie nicht zu viele A/B-Tests gleichzeitig; Interaktionen werden verwirrend.
Observability für Prompts
Für jeden produktiven LLM-Aufruf sollten Sie Folgendes protokollieren:
- Welche Promptvorlage verwendet wurde (Name, Version).
- Welche Variablen eingesetzt wurden – mit Namen aus einer Positivliste und bei Bedarf geschwärzten Werten.
- Den vollständig gerenderten Prompt nur, wenn die Richtlinien dies erlauben; andernfalls eine geschwärzte, stichprobenweise erfasste oder gehashte Darstellung.
- Die Modellantwort, bei sensiblen Workflows geschwärzt oder nur stichprobenweise erfasst.
- Latenz, Token, Kosten.
- Nachgelagerte Signale (Nutzerfeedback, Erfolgskennzahlen).
Diese Daten benötigen Sie, um Fragen wie „Warum hat das Modell diesem Nutzer eine ungewöhnliche Antwort gegeben?“ zu untersuchen. Ohne sie können Sie nur raten.
Speichern Sie die Daten in einer Datenbanktabelle oder einem Observability-Tool. Wenn Sie alles protokollieren, entstehen reale Kosten (Aufrufvolumen × Tokenanzahl × Speicherbedarf) und reale Datenschutzrisiken. Legen Sie je Workflow fest, welche Felder sicher gespeichert werden dürfen. Schwärzen Sie Secrets und personenbezogene Daten standardmäßig und wählen Sie kurze Aufbewahrungsfristen, sofern keine Compliance-Vorgabe längere Traces verlangt. Einige Teams erfassen nur Stichproben.
Prüfen Sie regelmäßig – beispielsweise wöchentlich – eine Stichprobe realer Produktionsprompts und Antworten. So erkennen Sie Probleme, die Evals übersehen.
Prompt-Antimuster
Einige Muster zu vermeiden:
Antimuster 1: Der Mega-Prompt. Ein Systemprompt mit 10.000 Wörtern, der jede Situation abdecken soll. Er ist schwer zu ändern und zu debuggen; spätere Anweisungen werden vom Modell häufig übergangen.
Lösung: Trennen Sie ihn in mehrere Ebenen und fokussierte Prompts – einen je Feature.
Antimuster 2: Inline-Zeichenfolgenkonkatenation.
prompt = "You are helpful. " + (
"The user is a paid customer. " if user.tier == "paid" else ""
) + f"Their name is {user.name}. " + ...
Fragil, schwer lesbar und anfällig für Prompt Injection.
Lösung: Vorlagen-System.
Antimuster 3: Derselbe Prompt für zu viele Anwendungsfälle.
Ein einziger Prompt für einen „allgemeinen Assistenten“ wird für E-Mail-Entwürfe, Code-Reviews, Kundensupport und Recherche verwendet. Jede davon ist eine andere Aufgabe; ein gemeinsamer Prompt ist für keine optimal.
Lösung: funktionspezifische Entwicklerprompts über einem gemeinsamen Systemprompt.
Antimuster 4: Hart codierte Prompts.
response = openai.chat.completions.create(
messages=[
{"role": "system", "content": "You are a helpful assistant..."},
{"role": "user", "content": query}
]
)
Der Prompt ist im Code verborgen. Er lässt sich weder ohne Deployment bearbeiten noch per A/B-Test prüfen oder unabhängig versionieren.
Lösung: extrahieren Sie ihn in eine Promptdatei oder einen Dienst.
Antimuster 5: Keine Eval-Abdeckung.
Ein Feature wird mit einem Prompt ausgeliefert, der nie systematisch getestet wurde. Qualität wird nur nach Gefühl beurteilt; Drift bleibt unsichtbar.
Lösung: Jeder Prompt hat eine Eval-Suite.
Antimuster 6: Daten in den Systemprompt mischen.
You are an assistant for John, a premium customer who joined in 2023, lives in Tallinn, and has 47 open tickets.
Jetzt ändert sich der Systemprompt bei jedem Aufruf. Caching bricht zusammen. Verwirrung entsteht.
Lösung: Dynamische Daten gehören in die Nutzer- oder Kontextebene, nicht in den Systemprompt.
Antimuster 7: Anweisungen in der Mitte verstecken.
Help the user with their request. Be polite. Format output as JSON. Don't use markdown. The user is asking about pricing, so be careful about quoting numbers. Output should be 1-2 sentences. Now help them.
Wichtige Anweisungen werden verloren. Das Modell könnte sie übersehen.
Lösung: Strukturieren Sie den Prompt in klare Abschnitte und platzieren Sie kritische Anweisungen am Anfang und Ende; der Recency-Effekt hilft.
Spezifische Muster für gängige Funktionen
Einige funktionspezifische Muster:
Klassifizierung
Task: classify the following text into one of these categories:
- billing: payment, refund, subscription
- technical: bug, error, integration issue
- account: login, password, profile changes
- feature_request: new functionality requests
- complaint: general dissatisfaction without specific actionable issue
Output a JSON object: {"category": "<one of above>", "confidence": "<high|medium|low>", "reasoning": "<1 sentence>"}
Text to classify:
{text}
Muster: aufgelistete Kategorien mit Definitionen, strukturierte Ausgabe sowie Felder für Konfidenz und Begründung.
Extraktion
Task: extract structured data from the document below.
Schema:
- vendor_name: company that issued the invoice
- invoice_number: as printed on the document
- date: ISO 8601 format
- line_items: array of {description, quantity, unit_price, total}
- subtotal, tax, total: numbers
Rules:
- If a field is not present, use null
- Numbers should be numeric, not strings
- For ambiguous cases, set "needs_review": true and explain
Document:
{document}
Muster: explizites Schema, Typanforderungen, Umgang mit fehlenden Daten und Eskalation bei Mehrdeutigkeit.
Generierung mit Stil
Task: write a {format} on the topic of {topic}, targeting {audience}.
Style:
- {Specific style trait 1}
- {Specific style trait 2}
- Avoid: {anti-pattern 1}, {anti-pattern 2}
Constraints:
- Length: {N} words
- Include: {required elements}
- Exclude: {forbidden elements}
Voice reference:
[Provide a sample of the desired voice]
Output: the {format} only, with no preamble or post-script.
Muster: spezifische Stilmerkmale (nicht generisch), explizite Einschränkungen, Stimme mit Referenzbeispiel verankert.
Agenten-Schleife
You have access to the following tools:
{tool_descriptions}
For each turn:
1. Think about what you need to do.
2. Decide if you need a tool. If yes, call it.
3. After observing the result, decide if you need more tools or can answer.
4. When you have enough information, produce the final answer.
Constraints:
- Maximum 5 tool calls per request.
- If after 5 calls you can't complete, explain what's missing.
- Never invent tool names or arguments.
- Verify tool results before acting on them.
User request:
{user_query}
Muster: explizite Reasoning-Schritte, Toolbudget, Schutz vor Halluzinationen und Reflexion.
Zusammenarbeit im Team
Produktionsprompts betreffen in der Regel mehrere Personen:
- Engineers integrieren Prompts in das System, pflegen Vorlagen und verwalten Deployments.
- Produkt definiert, was die Prompts erreichen sollen.
- Content/Marketing verantwortet Stimme und Stilrichtlinien.
- Fachexperten kennen die korrekten Anforderungen spezifischer Anwendungsfälle, etwa juristische Formulierungen oder medizinische Begriffe.
Ein hilfreiches Muster ist ein Prompt-Review ähnlich einem Code-Review, mit den zuständigen Prüfern für jeden Bereich. Änderungen an Tonalität und Sprache prüft das Content-Team, Logikänderungen das Engineering und fachspezifische Inhalte der jeweilige Experte.
Für sensible juristische, medizinische oder finanzielle Anwendungsfälle können Prompts eine formale Prüfung und Freigabe erfordern. Gestalten Sie den Prozess entsprechend.
Ein 90-Tage-Plan für Prompt-Reife
Für Teams, die von „Prompts sind Zeichenfolgen in Code“ zu „Prompts sind verwaltete Infrastruktur“ wechseln:
Tage 1–30: Grundlagen.
- Extrahieren Sie alle Prompts in eigene Dateien in der Versionsverwaltung.
- Etablieren Sie das 3-Ebenen-Muster (System / Entwickler / Nutzer).
- Bauen Sie eine einfache Vorlagen-Schicht auf.
- Richten Sie eine grundlegende Protokollierung von Prompts und Antworten ein.
Tage 31–60: Bewertung.
- Bauen Sie Eval-Suiten für die Top 5 Prompts.
- Führen Sie Eval-Tests bei Promptänderungen durch (zuerst manuell).
- Richten Sie CI-Integration für Eval-Tests ein (automatisch bei PRs).
Tage 61–90: Betrieb.
- Implementieren Sie die Versionierung von Prompts in einer Datenbank oder einem Service.
- Ermöglichen Sie A/B-Tests für mindestens einen kritischen Prompt.
- Erstellen Sie Dashboards für die Qualität produktiver Prompts.
- Etablieren Sie einen Review-Prozess für Promptänderungen.
Nach 90 Tagen sind Prompts verwaltete Infrastruktur. Änderungen erfolgen bewusst und sind testbar, prüfbar sowie rückgängig zu machen. Qualität ist messbar und Drift erkennbar.
Prompts als Infrastruktur
Produktionsprompts sind keine bloßen Zeichenfolgen. Sie bilden ein mehrschichtiges System mit klaren Regeln für Versionierung, Templating, Evals und Observability.
Die Architektur aus drei Ebenen – System, Entwickler und Nutzer – trennt Zuständigkeiten und hält Prompts wartbar. Templates reduzieren Fragilität. Versionsverwaltung oder ein Prompt-Service liefert eine nachvollziehbare Historie. Evals sichern Änderungen ab; Observability erkennt, was Evals übersehen.
Für ernsthafte Produktivsysteme ist dies nicht optional. Teams, die diese Schritte auslassen, enden im Prompt-Chaos: im Code verstreute Zeichenfolgen, eine unbekannte Produktivversion, keine Qualitätsmessung und ständig unerklärliche Verhaltensänderungen.
Teams, die in Prompt-Infrastruktur investieren, erhalten ein steuerbares, messbares und verbesserbares KI-Verhalten. Das unterscheidet ein langlebiges Feature von einem, das zu technischen Schulden wird.
Beginnen Sie mit der Architektur. Alles andere wird einfacher.
