---
titel: "Warum Architekturvorgaben in den Prompt gehören, nicht ins Wiki"
adresse: https://anvil-coder.tech/blog/architekturvorgaben-im-prompt
beschreibung: "Ein Architekturdokument, das beim Onboarding gelesen und danach vergessen wird, verhindert keine Abweichung — sie fällt erst im Review auf, wenn schon gebaut ist. Wie Guardrails eigene Vorgaben stattdessen zur Bedingung jedes einzelnen Arbeitsschritts machen, und wo diese Bedingung endet."
sprache: de
---

2026-07-27

# Warum Architekturvorgaben in den Prompt gehören, nicht ins Wiki

Die meisten Architekturvorgaben leben in einem Dokument. Es wird beim Onboarding gelesen, dann seltener, irgendwann nicht mehr — und die Abweichung fällt im Review auf, wenn der Code schon steht. Bei Anvil Coder läuft das umgekehrt: eine Vorgabe kann [Teil des Prompts sein, nicht nur des Wikis](https://anvil-coder.tech/fuer-produktteams#governance).

## Prüfen am Ende kommt zu spät

Der übliche Weg ist: erst generieren, dann prüfen — ein Linter, ein Scanner, ein Review, und was durchfällt, wird nachgebessert. Für eine einzelne Datei funktioniert das. Für ein Projekt, das aus [hunderten parallelen Arbeitsschritten](https://anvil-coder.tech/wie-es-funktioniert#achsen) entsteht, nicht mehr: Ein struktureller Fehler, der in Schritt 12 entsteht, hat sich bis Schritt 200 fortgepflanzt. Ihn dort zu finden ist kein Nachbessern mehr, sondern Umbauen — und der Kontext, in dem er entstand, ist längst weg. [Guardrails](https://anvil-coder.tech/guardrails#warum) drehen die Reihenfolge um: die Vorgabe steht vor dem Schritt, nicht nach ihm.

## Was standardmässig mitkommt

Als System-Prompt injiziert werden [fünf mitgelieferte Invarianten](https://anvil-coder.tech/guardrails#invarianten) — OWASP Top 10, SOLID, KISS, DRY, Clean Code. Sie stehen nicht in einer Dokumentation, die ein Modell gelesen haben könnte, sondern in jedem einzelnen Prompt, bei jedem Arbeitsschritt neu.

## Eigene Vorgaben werden zu Guardrails

Genau hier liegt der Unterschied zu einem Architekturdokument: eine Regel, die nur für ein bestimmtes Team gilt — eine bestimmte Schichtung, ein Namensschema, ein Verbot bestimmter Bibliotheken — lässt sich [als eigene Guardrail hinterlegen](https://anvil-coder.tech/guardrails#eigene) und wird genauso injiziert wie die mitgelieferten. Ein Unterschied bleibt: als blosse Prosa wirkt eine eigene Regel im Prompt, aber nicht in einer zusätzlichen maschinellen Validierung — dafür muss sie als maschinenlesbare Regel hinterlegt sein. Im laufenden Betrieb sammelt das System zusätzlich Vorschläge für neue Guardrails aus dem eigenen Verlauf; angewandt wird davon nichts automatisch, der einzige Weg in den Katalog führt über eine menschliche Freigabe.

## Wo die Bedingung endet

Ein Review ersetzt das nicht. Ein Schritt, der gegen dieselben Invarianten entsteht, wird konsistent — nicht zwangsläufig richtig. Ob die Anforderung selbst stimmt, ob der fachliche Zuschnitt trägt: das bleibt eine menschliche Entscheidung, und genau dafür ist die Vorgabe im Prompt kein Ersatz, sondern eine Vorstufe. Sie verschiebt, wo ein Fehler auffällt — vom Ende der Kette an ihren Anfang.

## Selbst ausprobieren?

Der freie Tarif steht ohne Gespräch offen — ein Projekt anlegen, ein Epic ziehen, das Ergebnis im eigenen Repository reviewen.

[Kostenlos starten](https://app.anvil-coder.tech/register)[Demo vereinbaren](https://anvil-coder.tech/demo)