Requirement oder Constraint: Warum unsere Agenten im Design aufgehört haben zu denken

Wir haben zuletzt einen Website-Relaunch agentisch gebaut. Rund 1.000 URLs im Bestand, das bisherige Content-System sollte zur reinen Datenbank werden, und ein Agent sollte den redaktionellen Betrieb übernehmen. Damit die Agenten wissen, was zu entwickeln ist, hatten wir das Projekt vorher weitgehend durchspezifiziert.

Das Ergebnis war sehr gute Ausführung und faktisch kein Design.

Die Agenten haben geliefert. Nur haben sie bei jeder Gestaltungsfrage nach oben gegriffen und sich auf das gestützt, was schon dastand: die Briefings, die funktionalen Anforderungen, die Modulliste, die Datenfelder. Es kam nichts zurück, das wir nicht vorher selbst hineingeschrieben hatten. Der kreative Prozess hat nicht stattgefunden. Er war wegspezifiziert.

Mein erster Reflex war, es sei zu viel Kontext gewesen. Das war zu unscharf.

Ein Constraint formt einen Lösungsraum, ein Requirement schließt einen Problemraum

Der Fehler war nicht die Menge. Der Fehler war der Status, den wir dem Kontext gegeben haben. Wir hatten die Designphase als Schritt in eine Roadmap eingegliedert, die ansonsten aus Anforderungen bestand. Damit war die Designphase eine Anforderung.

Es gibt dafür einen sehr sauberen Beleg, und er ist älter als jede Agenten-Debatte.

Rahul Mohanani, Paul Ralph und Ben Shreeve haben 2014 auf der International Conference on Software Engineering eine randomisierte Studie mit 42 Teilnehmenden vorgelegt. Beide Gruppen bekamen inhaltlich identische Vorgaben für dieselbe Designaufgabe. Bei der einen Gruppe hießen die Vorgaben „requirements", bei der anderen „ideas". Sonst war nichts anders.

Die Requirements-Gruppe produzierte signifikant weniger originelle Designs (Mann-Whitney U = 116,5, p = 0,004).

Nur das Wort. Die Autoren nennen den Effekt „requirement fixation".

Eine Folgearbeit derselben Gruppe, 2022 in den IEEE Transactions on Software Engineering, hat 42 Designer in 21 Paaren beim Arbeiten beobachtet. Wer Anforderungen in Vorlagenform bekommt, akzeptiert die eigene erste Lösungsidee unkritisch und kommt nie mehr zu ihr zurück. Die Empfehlung der Autoren steht wörtlich im Paper: Wenn Kreativität Priorität hat, vermeide Anforderungsvorlagen und das Überstrukturieren, Übersimplifizieren und Überrationalisieren von Problemstellungen.

Wir hatten alle drei gemacht, in derselben Datei.

• 42 Teilnehmende – Randomisierte Studie mit identischen Vorgaben
• Mann-Whitney U = 116,5, p = 0,004 – Signifikant weniger Originalität bei „requirements“
• 42 Designer in 21 Paaren – Anforderungsvorlagen fördern frühe Fixierung

Warum Agenten hier genauso scheitern wie Menschen

Design Fixation ist keine neue Beobachtung. Jansson und Smith haben sie 1991 in Design Studies beschrieben: Wer vor einer Designaufgabe ein Beispiel sieht, übernimmt dessen Merkmale, einschließlich der Fehler, die die Forschenden absichtlich eingebaut hatten. Gleiche Anzahl Entwürfe, weniger Flexibilität, weniger Originalität. Das galt auch für Berufsingenieure, nicht nur für Studierende.

Bei Agenten ist derselbe Effekt inzwischen messbar. Eine Arbeit von Sanjith Vigraham aus diesem Jahr untersucht genau unseren Fall, nämlich agentische Design-Exploration statt Implementierung, über mehr als 2.700 Durchläufe und sieben Kontextbedingungen. Zwei Befunde daraus sind praktisch relevant.

Erstens verbessert derselbe Artefakttyp die Exploration bei manchen Aufgaben deutlich und verschlechtert sie bei anderen um bis zu 46 Prozent. Bei mehreren Aufgaben schlägt ein irrelevantes Dokument jedes relevante.

Zweitens, und das erklärt unser Projekt: Enge, die aus den Trainingsdaten kommt, lässt sich durch Störimpulse aufbrechen. Enge, die aus einer expliziten Anweisung kommt, nicht mehr. Wer den Agenten per Briefing auf eine Lösung festnagelt, holt ihn mit keinem zusätzlichen Kontext wieder heraus.

Ich sollte dazu sagen, wie belastbar das ist: Einzelautor, ein getestetes Modell, nicht peer-reviewed. Als Beleg für einen Mechanismus taugt es, als Naturgesetz nicht.

Flankierend passt eine größere Arbeit von Laban und Kollegen bei Microsoft und Salesforce, über 200.000 simulierte Konversationen. Der durchschnittliche Leistungsabfall über mehrere Gesprächsrunden liegt bei 39 Prozent gegenüber einer einzelnen Runde. Der Mechanismus ist wieder derselbe: Modelle treffen früh Annahmen, produzieren vorzeitig eine Endlösung, verlassen sich darauf, und wenn sie einmal falsch abgebogen sind, finden sie nicht zurück.

• 2.700 Durchläufe, 7 Kontextbedingungen – Agentische Design-Exploration untersucht
• bis zu 46 Prozent – Verschlechterung der Exploration je nach Artefakttyp
• 39 Prozent – Leistungsabfall über mehrere Gesprächsrunden

Kontext ist ein Budget, kein Vorrat

Die mechanische Erklärung liefert Anthropic in seiner eigenen Anleitung zum Context Engineering. Modelle haben ein „attention budget", und jedes zusätzliche Token zehrt daran. Der Grund liegt in der Architektur: n Tokens erzeugen n² Beziehungen, also gibt es eine natürliche Spannung zwischen Kontextgröße und Aufmerksamkeitsschärfe. Das Zielbild in ihren Worten ist die kleinstmögliche Menge an Tokens mit hohem Signalwert. Und explizit gegen unseren Fehler: Eine Wäscheliste von Sonderfällen in den Prompt zu stopfen, empfehlen sie ausdrücklich nicht.

Zwei Messungen dazu finde ich überzeugend.

Chroma hat 18 Modelle über knapp 195.000 Aufrufe getestet, wobei die Aufgabenschwere konstant blieb und nur die Eingabelänge variierte. Damit ist der Effekt der Menge isoliert. Der Vergleich, der hängen bleibt: 300 Token fokussierter Input schlagen 113.000 Token Volltext, und zwar bei allen getesteten Modellen.

Distyl AI hat 20 Modelle mit bis zu 500 gleichzeitigen Instruktionen belastet. Bei 500 erreicht das beste Frontier-Modell 68 Prozent Befolgungsgenauigkeit. Dazu ein Detail mit direkter Konsequenz für lange Spezifikationen: Es gibt einen systematischen Vorzug für frühe Instruktionen. Was hinten in deinem Dokument steht, wird schlechter befolgt als das, was vorne steht.

In unserem Projekt war das messbar, bevor es spürbar wurde. Vor der ersten inhaltlichen Frage kamen 1.500 bis 3.000 Zeilen vorbelasteter Kontext zusammen, plus zwei bis drei Minuten Wartezeit pro Abfrage.

• 18 Modelle, 195.000 Aufrufe – Effekt der Eingabelänge isoliert
• 300 Token vs. 113.000 Token – Fokussierter Input schlägt Volltext bei allen Modellen
• 20 Modelle, 500 Instruktionen – Bestes Modell mit 68 Prozent Befolgungsgenauigkeit
• 1.500–3.000 Zeilen + 2–3 Minuten – Vorbelasteter Kontext und Wartezeit pro Abfrage im Projekt

Die naheliegende Lösung ist derselbe Fehler in anderem Kostüm

Mein erster Reparaturgedanke war, die Designphase freizustellen und sie stattdessen mit Wunsch-Referenzen, Best Practices und visuellen Vorbildern zu füttern. Damit hätte ich den Fehler wiederholt.

Wadinambiarachchi und Kollegen haben das 2024 auf der CHI mit 60 Teilnehmenden getestet. Unterstützung durch einen KI-Bildgenerator während der Ideenfindung führte zu höherer Fixierung auf das erste Beispiel. Die Teilnehmenden produzierten weniger Ideen, mit geringerer Varianz und geringerer Originalität als die Vergleichsgruppe.

Referenzseiten am Anfang einer Designphase sind kein Freiheitsgrad. Sie sind der Anker, an dem alles hängen bleibt.

Was wir jetzt anders machen

1. Mission-Briefing statt Anforderungsliste. Zweck, Zielgruppe, Erfolgsdefinition. Bewusst ohne Modulliste.
2. Ein Lauf ohne jeden Kontext. Er zeigt, wie breit das System von sich aus geht. Das ist die billigste Diagnose im ganzen Prozess.
3. Divergenz mit möglichst wenig Vorbild. Wenn geöffnet werden muss, dann mit Anti-Mustern („so nicht, und zwar deshalb"), nicht mit Best Practices.
4. Anforderungen erst nach der Formentscheidung. Funktionsumfang, Datenfelder, Governance-Grenzen kommen danach, nicht parallel.
5. Leitplanken zuletzt. In der Ausführungsphase sind sie genau richtig, weil dort lange autonome Läufe der Punkt sind.

Heißt das, wir planen jetzt weniger?

Nein. Der Zusammenhang zwischen Vorgaben und Kreativität ist nicht linear, sondern umgekehrt U-förmig. Acar, Tarakci und van Knippenberg haben das 2019 im Journal of Management über viele Einzelstudien zusammengetragen: Zu wenige Vorgaben senken Kreativität genauso wie zu viele. Das mittlere Maß stimuliert sie.

In der agentischen Entwicklung läuft der aktuelle Reflex in die andere Richtung. Spec-Driven Development, also die vollständige Vorab-Spezifikation als führendes Artefakt, ist die Methode der Stunde. Colin Eberhardt von Scott Logic hat dasselbe Feature zweimal gebaut, einmal mit einem solchen Werkzeug und einmal ohne. Mit: 689 Zeilen Code, dafür 2.577 Zeilen Spezifikationstext und dreieinhalb Stunden Review, plus ein Fehler, den die Spezifikation nicht verhindert hat. Ohne: eine Viertelstunde Review, kein Fehler. Der Technology Radar von Thoughtworks hat die Methode im November nur auf „Assess" gesetzt, mit dem Satz, man lerne hier möglicherweise eine bittere Lektion neu, nämlich dass handgeschriebene Detailregeln für KI nicht skalieren.

• 2.577 Zeilen Spezifikation – Umfang im Spec-Ansatz
• 3,5 Stunden Review – Aufwand mit vollständiger Vorab-Spezifikation
• 15 Minuten Review – Aufwand ohne Spec-Tool
• 0 Fehler vs. 1 Fehler – Ergebnisqualität im Vergleich

Unsere Roadmap war nicht falsch. Sie hatte nur einen Modus, und der war Ausführung.

Häufige Fragen zu Requirement vs. Constraint im agentischen Design (FAQ)

Wie unterscheide ich in der Praxis zwischen Requirement und Constraint?

Requirements beschreiben, was ein System liefern muss, und schließen Optionen oft vorzeitig aus. Constraints stecken den Rahmen ab, in dem Lösungen gefunden werden dürfen. Für kreative Phasen sind knappe, sinnvolle Constraints hilfreicher als vollständige Anforderungskataloge. Die Reihenfolge zählt: erst Form und Richtung, dann Details.

Wie viel Kontext sollte ich Agenten geben?

Kontext ist ein knapper Aufmerksamkeitsetat, kein Speicher, den man einfach füllt. Starten Sie mit der kleinstmöglichen, hochrelevanten Menge und erweitern Sie nur gezielt. Lange, unscharfe Prompts mindern Fokus und Befolgung, besonders bei später platzierten Instruktionen. Messen Sie Wirkung statt Umfang: kurze, präzise Tokens schlagen Volltext.

Kann ich Beispiele nutzen, ohne Fixation zu fördern?

Ja, aber sparsam und eher als Negativbeispiele oder Kontrast. Frühe, starke Vorbilder verengen den Suchraum und verankern erste Lösungen. Nutzen Sie Beispiele erst nach einer initialen Divergenzphase oder markieren Sie explizit, was daran vermieden werden soll. So dienen sie als Orientierung, nicht als Schablone.

Was bedeutet das für Spezifikationen und Roadmaps?

Formalisieren Sie Anforderungen erst, nachdem die grobe Form entschieden ist. In der Ausführung sind Leitplanken und Detailregeln sinnvoll, in der Exploration bremsen sie. Trennen Sie explizit zwischen kreativer Divergenz und nachfolgender Konvergenz. Halten Sie Roadmaps mehrmodig: Entdecken, dann spezifizieren, dann liefern.

Wie erkenne ich früh, ob meine Agenten „festfahren“?

Planen Sie einen ersten Lauf ohne Kontext und vergleichen Sie Bandbreite, Varianz und Originalität. Sinkt die Vielfalt stark oder wiederholen sich frühe Annahmen, liegt Fixation nahe. Achten Sie auch auf wachsende Wartezeiten bei viel Vorabkontext und auf das Ausbleiben von Rücksprüngen zu früheren Alternativen. Setzen Sie Störimpulse erst, wenn Enge aus implizitem Wissen stammt, nicht aus harten Anweisungen.

Am Ende ist das dieselbe Frage, die auch ohne Agenten gilt. Wer in deinem Prozess darf noch etwas vorschlagen, das im Briefing nicht steht?