Blog  /  Fachbeitrag

Fachbeitrag · KI-Anweisungen und Betrieb

Prompting im Ingenieurbüro: Der Lebenszyklus von KI-Anweisungen in der Planung

Wer in einem Ingenieurbüro über Monate mit KI-Assistenten arbeitet, sammelt Regeln an. Die Annahme dahinter ist verständlich: Wer mehr vorgibt, behält mehr Kontrolle. Die Modellentwicklung legt derzeit das Gegenteil nahe. KI-Anweisungen sind keine einmalige Einrichtung, sondern haben einen Lebenszyklus: Sie entstehen, sie wirken, sie altern und sie müssen an einem bestimmten Punkt geprüft werden.

Besprechung im Ingenieurbüro vor einer Glaswand mit den Schritten Entstehen, Prüfen, Kürzen und Versionieren von KI-Anweisungen
Der Beitrag auf einen Blick
Thema
Entstehung, Alterung und Prüfung von KI-Anweisungen in Planungsbüros
System
Systemprompts, Skills, Konfigurationsdateien und Hooks in KI-Assistenten
Kernproblem
Modellführung und fachliche Festlegung stehen unsortiert in denselben Dateien
Regelwerksbezug
EU AI Act, DSGVO Art. 28, VgV, DIN 276, HOAI, VOB/B
Entscheidung
Welche Anweisung gestrichen wird und welche als Nachweis bestehen bleibt
Grundlage
Veröffentlichung von Anthropic vom 24. Juli 2026, Vortrag bei der Y Combinator Startup School vom 2. August 2026

Drei Wege, auf denen Anweisungen entstehen

Regelwerke in Planungsbüros wachsen selten geplant. Der erste Weg ist die Einzelkorrektur. Jemand ist mit einer Antwort unzufrieden, schreibt eine Regel dagegen und speichert sie ab. Solche Regeln sind an einen einzelnen Fall gebunden und werden nie wieder überprüft. Der zweite Weg ist die Übernahme aus einer fremden Quelle, etwa aus einer Vorlage, einem Forumsbeitrag oder einem Kurs. Sie bringt Anweisungen mit, die für ein anderes Modell und einen anderen Zweck geschrieben wurden. Der dritte Weg ist die bewusste Festlegung, also die Entscheidung einer fachlich zuständigen Person, dass ein Vorgang künftig in einer bestimmten Form abläuft.

In der Begleitung von Planungsbüros zeigt sich regelmäßig, dass die Mehrheit der Zeilen in einem gewachsenen Regelwerk aus den ersten beiden Wegen stammt, ohne dass dies jemandem bewusst wäre.

Nur der dritte Weg erzeugt Anweisungen, die eine erkennbare Herkunft haben. Die ersten beiden erzeugen den Bestand, der später als Ballast auffällt.

Ein belegter Befund aus der Modellentwicklung

Achtzig Prozent weniger Vorgaben

Anthropic hat im Juli 2026 offengelegt, dass für die Claude-5-Generation über achtzig Prozent des Systemprompts von Claude Code gestrichen wurden. Beschrieben wird der Schritt als Übergang von starren Regeln zu Urteilskraft, von vorab geladenem Kontext zu schrittweiser Offenlegung und von wiederholten Anweisungen zu präzise beschriebenen Werkzeugen. Ein genanntes Beispiel ist die frühere Vorgabe, niemals mehrabsätzige Dokumentationskommentare zu schreiben. Sie wurde ersatzlos durch die Erwartung ersetzt, dass sich der Kommentarstil am vorhandenen Code orientiert.

Der Systemprompt als Verbindlichkeit

Boris Cherny, der Claude Code bei Anthropic verantwortet, hat diesen Befund Anfang August 2026 bei der Y Combinator Startup School zugespitzt. Sein Rat lautet, alle sechs Monate die eigene Konfigurationsdatei, die eigenen Skills und die eigenen Hooks zu löschen und zu beobachten, was das Modell ohne sie tut. Sein Team behandelt den Systemprompt ausdrücklich als Verbindlichkeit und nicht als Vorteil. Bei jeder Modellversion wird der Prompt vollständig entfernt und Zeile für Zeile zurückgeführt, wobei jede Zeile ihre Wirkung nachweisen muss.

Die Voraussetzung der automatischen Prüfbarkeit

Der Befund ist ernst zu nehmen, weil er aus der Messung stammt und nicht aus einer Meinung. Er ist zugleich in einem bestimmten Umfeld entstanden, nämlich in der Softwareentwicklung mit automatischer Prüfbarkeit. Testsuiten und Bildvergleiche liefern dort nach jedem Durchlauf ein Urteil über die Qualität des Ergebnisses. Diese Voraussetzung ist der eigentliche Kern der Empfehlung und sie ist im Planungsalltag selten gegeben.

Zwei Arten von Anweisungen in einem Regelwerk

Wer die Empfehlung auf ein Ingenieurbüro überträgt, muss zuerst trennen, was in den gewachsenen Dateien eigentlich steht. Die erste Art ist Modellführung. Dazu zählen Formatzwänge, die einmal nötig waren, weil ein älteres Modell zu ausschweifend antwortete, Verbotslisten gegen Formulierungen, die heute ohnehin nicht mehr auftreten, ausführliche Beispielsammlungen für einen Arbeitsschritt, den das Modell inzwischen von sich aus richtig ausführt, und Wiederholungen derselben Regel an drei Stellen, weil sie beim ersten Versuch nicht griff. Diese Anweisungen sind Reparaturen an Schwächen, die es so nicht mehr gibt.

Die zweite Art ist fachliche Festlegung. Dazu zählen der Nummernkreis, mit dem ein Büro seine Besprechungspunkte über Jahre fortschreibt, die Zuordnung von Kostengruppen nach DIN 276, die Abgrenzung der Leistungsbilder nach HOAI, die Fristenlogik aus der VOB/B, die Struktur eines behördlich einzureichenden Berichts, das Corporate-Format einer Rechnung und die Festlegung, welcher Prüfschritt fachlich zu verantworten ist und deshalb nicht maschinell vorbereitet wird. Diese Festlegungen altern nicht mit dem Modell. Sie altern mit dem Regelwerk, auf das sie sich beziehen, also mit einer Normfortschreibung, einer Gesetzesänderung oder einem internen Beschluss.

Ein Regelwerk, das beide Arten vermischt, lässt sich nicht als Ganzes löschen und auch nicht als Ganzes verteidigen. Darin liegt das eigentliche Problem der gewachsenen Konfigurationsdateien, nicht in ihrer Länge.

Der Nachweis als eigener Grund für Vorgaben

Ein Teil der fachlichen Festlegungen steht nicht im Regelwerk, weil das Modell ihn braucht, sondern weil jemand später erklären können muss, wie ein Ergebnis zustande kam. In einem Vergabeverfahren nach VgV ist die Nachvollziehbarkeit der Wertung Bestandteil der Dokumentation. In der Auftragsverarbeitung nach Art. 28 DSGVO ist festzuhalten, welche Daten zu welchem Zweck verarbeitet werden. Der EU AI Act verlangt seit Februar 2025 von Anbietern und Betreibern, für ausreichende KI-Kompetenz der mit den Systemen befassten Personen zu sorgen, und knüpft an bestimmte Anwendungen weitergehende Dokumentationspflichten. Die meisten Anwendungen in einem Planungsbüro fallen nach derzeitiger Einordnung nicht in die Hochrisikokategorie, was die Frage der internen Nachweisführung jedoch nicht erledigt.

Für solche Anweisungen gilt der Ablationstest nicht. Ob das Modell die Kostengruppenzuordnung auch ohne ausdrückliche Vorgabe trifft, ist für die Nachweisführung ohne Bedeutung. Entscheidend ist, dass die Zuordnung festgelegt, begründet und wiederauffindbar ist. Eine Vorgabe, die als Nachweis dient, wird nicht gestrichen, weil das Modell sie nicht mehr benötigt, sondern allenfalls gekürzt, damit sie präziser wird.

Die Darstellung ersetzt keine Rechtsberatung.

Vorgehen

Schritt 01

Inventur

Erfasst wird, welche Regelwerke überhaupt im Einsatz sind, wer sie zuletzt geändert hat und auf welchen Modellstand sie zurückgehen. Vielerorts existieren mehrere Fassungen derselben Vorgabe in verschiedenen Ablagen, was jede weitere Bewertung unbrauchbar macht, solange es nicht geklärt ist.

Schritt 02

Klassifikation

Jede Anweisung wird einer der beiden Arten zugeordnet, also Modellführung oder fachliche Festlegung. Bei der fachlichen Festlegung wird vermerkt, worauf sie sich stützt, also auf welche Norm, welche Rechtsgrundlage oder welchen internen Beschluss. Anweisungen ohne erkennbare Herkunft sind die erste Kandidatenmenge für die Streichung.

Schritt 03

Prüffälle vor dem Test

Bevor etwas entfernt wird, wird festgelegt, woran sich ein gutes Ergebnis erkennen lässt. Im Planungsbüro sind das in der Regel drei bis fünf abgeschlossene Vorgänge mit bekanntem Sollergebnis, etwa ein freigegebenes Protokoll, eine geprüfte Rechnung, ein eingereichter Bericht.

Schritt 04

Ablation in der Kopie

Die Modellführung wird in einer Testfassung entfernt, die fachlichen Festlegungen bleiben zunächst stehen. Die Prüffälle werden erneut durchlaufen und die Abweichungen werden benannt. Zurück kommt nur, was eine beobachtete Abweichung behebt, und zwar in der kürzesten Form, die wirkt.

Schritt 05

Freigabe und Versionierung

Die neue Fassung wird mit Datum, Modellstand und Begründung der Änderungen abgelegt und von einer benannten Person freigegeben. Ohne diesen Schritt entsteht innerhalb weniger Monate wieder derselbe Zustand, nur mit anderen Regeln.

Bedingungen

Drei Voraussetzungen entscheiden, ob das Ausmisten trägt

Einwände

Gegen das regelmäßige Löschen sprechen drei Einwände

Die Empfehlung aus der Modellentwicklung ist im Planungsbüro nicht ohne Weiteres anwendbar. Drei Gründe, die in der Debatte meist untergehen, sprechen gegen ein Löschen nach Gefühl.

Einzige schriftliche Fassung einer Konvention

Ein Regelwerk ist häufig die einzige schriftliche Fassung einer Konvention, die vorher nur in den Köpfen von zwei erfahrenen Mitarbeitenden existierte. Wird es gelöscht, verschwindet nicht eine überflüssige Anweisung, sondern eine Festlegung, die niemand mehr rekonstruieren kann.

Gleichförmigkeit gegenüber Prüfstellen

Ein Modell, das ohne Vorgabe nach eigenem Urteil formuliert, trifft in neun von zehn Fällen eine vertretbare Wahl. Wo Ergebnisse extern geprüft werden, etwa durch einen Auftraggeber der öffentlichen Hand, wiegt die Wiedererkennbarkeit eines Formats schwerer als der letzte Prozentpunkt an Formulierungsqualität.

Fehlende Kapazität für die Beurteilung

In der Softwareentwicklung übernimmt die Testsuite das Urteil über das Ergebnis. Im Planungsbüro übernimmt es eine fachlich qualifizierte Person, deren Zeit knapp ist. Wer ohne diese Kapazität löscht, tauscht ein bekanntes Problem gegen ein unbekanntes.

Häufige Fragen

Was Büroleitungen zum Umgang mit KI-Anweisungen fragen

Prompt-Bloat bezeichnet den Zustand, in dem Anweisungsdateien für KI-Assistenten über Monate zu umfangreichen Regelkatalogen anwachsen, ohne dass geprüft wird, ob die einzelnen Regeln noch wirken. Der Kontext wird dadurch belegt, der Entscheidungsspielraum des Modells verengt und die Ergebnisqualität kann sinken.

Ein vollständiges Löschen ohne Prüffälle ist im Planungsbüro nicht zu empfehlen, weil die automatische Erfolgskontrolle fehlt, die diesen Test in der Softwareentwicklung trägt. Sinnvoll ist ein regelmäßiger Durchgang, bei dem Anweisungen zur Modellführung testweise entfernt und fachliche Festlegungen bewusst erhalten werden.

Vor allem Formatzwänge, Verbotslisten gegen Formulierungen älterer Modellgenerationen, ausführliche Beispielsammlungen und mehrfach wiederholte Regeln. Sie wurden geschrieben, um Schwächen auszugleichen, die in neueren Modellen so nicht mehr auftreten.

Bezüge auf Normen und Rechtsgrundlagen wie DIN 276, HOAI oder VOB/B, interne Nummernkreise und Formatkonventionen, die Abgrenzung zwischen maschinell vorbereiteten und fachlich verantworteten Prüfschritten sowie alles, was der internen Nachweisführung dient. Diese Festlegungen ändern sich mit der Norm oder mit einem internen Beschluss, nicht mit dem Modell.

Durch eine versionierte Fassung des Regelwerks mit Datum, Modellstand, Begründung der Änderungen und einer benannten Person, die freigibt. Ohne Freigabe und Ablage entsteht innerhalb weniger Monate derselbe ungeordnete Zustand mit anderen Regeln.

Eine Frage der Betriebsfähigkeit, nicht des Aufräumens

Die Nachricht aus der Modellentwicklung ist keine Aufforderung zum Löschen, sondern eine Verschiebung der Beweislast. Bis vor Kurzem galt eine zusätzliche Regel als unschädlich und im Zweifel als nützlich. Inzwischen ist belegt, dass sie Kosten hat, und zwar bei jeder einzelnen Anfrage. Ein Regelwerk mit nachvollziehbarem Lebenszyklus lässt sich fortschreiben. Eines ohne lässt sich nur verwerfen oder weiter mitführen.

Nicht jedes Problem löst sich auf diesem Weg. Ein Büro, dessen Prüfwege fachlich ungeklärt sind, gewinnt durch ein kürzeres Regelwerk nichts, weil die fehlende Festlegung nicht im Prompt liegt, sondern in der Zuständigkeit. Dort ist zuerst zu klären, wer entscheidet, und erst danach, was aufgeschrieben werden muss.

Quellen
Anthropic, The new rules of context engineering for Claude 5 generation models, 24. Juli 2026.
Boris Cherny, Vortrag bei der Y Combinator Startup School vom 2. August 2026, Zusammenfassung des Vortrags.