Agentischen Entscheidungsspielraum definieren

Agentischer Entscheidungsspielraum (agentic latitude) ist das Maß an Freiheit, das ein Product Engineer einem Coding-Agenten für Entscheidungen über ausdrücklich vorgegebene Details hinaus gewährt. Es ist kein globaler Berechtigungsschalter: Der Spielraum kann je Entscheidungsbereich, Inkrement, Projekt oder Kunde unterschiedlich sein.

Der Product Engineer bestimmt wo Freiheit willkommen ist, sodass Agenten ohne Detailvorgaben Vorschläge machen oder umsetzen dürfen, und wo Genauigkeit nötig ist, sodass Grenzen und Anforderungen nicht eigenständig erweitert, umgedeutet oder geändert werden dürfen.

Freiheit und Präzision ergänzen einander. Ein Projekt kann viel UX-Kreativität bei genau festgelegtem Funktionsumfang und Seiteninventar erlauben. Ein anderes lässt Funktionsvorschläge zu, verlangt aber ein festes visuelles System und eine genaue Inhaltspolitik.

Die vier Kategorien sind praktische Betrachtungsweisen, keine vollständig überschneidungsfreie Taxonomie.

Weitere Kategorien wie Integrations- oder Betriebsspielraum können nützlich sein, werden aber keine neue Pflichtbürokratie. Unternehmenssicherheit und freigegebene Architektur bleiben unabhängig vom Spielraum bindend.

Der Product Engineer definiert Freiheit und Präzision für das nächste Ergebnis. Ein Kunde kann breite UX-Erkundung wünschen und dennoch Seitenzahl und Funktionen festlegen; ein anderer lädt zu Funktionsvorschlägen ein, behält aber genaue visuelle und inhaltliche Regeln. Grenzen müssen ebenso deutlich sein wie die Einladung zur Kreativität.

Eine nicht genannte Kategorie erlaubt keine unbegrenzte Erweiterung. Es gelten aktuelle Anfrage, dauerhafte Projekt-/Unternehmensanweisungen und vernünftig implizierter Umfang. Wesentliche Ergänzungen separat vorschlagen und vor Umsetzung klären. Spielraum autorisiert weder erfundene Geschäftsrichtlinien noch zusätzliche Rechte, Abhängigkeiten oder irreversible Wirkungen außerhalb gewährter Befugnis.

SHAPE empfiehlt kleine, zusammenhängende Implementierungs- und Prüfschritte mit bewusst festgelegtem Spielraum je Inkrement. Das ist der empfohlene Standardweg, nicht nur eine gleichrangige Option.

Mit der kleinsten nützlichen Grundlage beginnen, eine verständliche Fähigkeit implementieren, das Ergebnis erproben, Absicht und Spielraum anpassen und erst dann erweitern. Kleine Inkremente bedeuten weder winzige Commits noch zwingend eine Ansicht pro Änderung. Der PE und relevante Stakeholder müssen die Folgen verstehen und beurteilen können.

Illustrative Website-Schritte könnten Layout/Navigation, visuelle Richtung, Authentifizierung, Kontoverwaltung und den ersten Geschäftsablauf umfassen. Bei einer ERP-Erweiterung könnten Integrationsgrenze/Datenmodell, ein Geschäftsvorgang, Berechtigungen/Validierung und weitere Abläufe folgen. Dies sind Beispiele, keine zusätzlichen oder universellen SHAPE-Phasen und kein Auftrag, dieser Website Kontofunktionen hinzuzufügen.

Eine große Ausgangsanfrage oder umfassende Spezifikation kann einen beeindruckenden Prototyp liefern und für begrenzte Experimente passen. Dabei sammeln sich aber leicht unbewusste Agentenentscheidungen: weitere Seiten, unbestellte Funktionen, erfundene Geschäftsregeln, umfangreiche Texte, Abhängigkeiten oder unerwünschte Organisation.

Das Ergebnis kann professionell aussehen und trotzdem über das hinausgehen, was der Eigentümer versteht oder veröffentlichen möchte. Der PE wechselt dann von vorausschauender Steuerung zu reaktiver Schadensbegrenzung: entdecken, was entstanden ist, Unerwünschtes entfernen und Annahmen rückgängig machen. Schnelle Rücknahme erleichtert Korrekturen, beseitigt aber nicht den Aufwand für Verstehen, Prüfen und Entflechten.

Nicht jeder breite Prompt scheitert, und Agentenprototypen sind nicht grundsätzlich schlecht. Breite Experimente bleiben möglich; kleine verständliche Inkremente bleiben dennoch die SHAPE-Empfehlung.

Diese leichte Methode unterstützt Discovery, Implementierung und Erweiterungen; sie ist keine neue Governance-Phase.

1. Nächstes Ergebnis definieren. Den kleinsten zusammenhängenden nutzbaren Stand benennen, den es sich zu prüfen lohnt; Nutzer und demonstrierbares Verhalten nennen. Beispiel: Eine angemeldete Person kann auf ihrer Kontoseite Profildaten sehen und ihr Passwort ändern. Nicht das gesamte künftige Produkt beschreiben.
2. Umfang begrenzen. Einschluss, Ausschluss und vorher abzustimmende Ergänzungen nennen, insbesondere zusätzliche Seiten, Regeln, Integrationen und große Textmengen. Beispiel: keine Profilfotos, Abonnements, weiteren Einstellungen oder Navigationsbereiche; hilfreiche Ideen separat vorschlagen.
3. Spielraum je Kategorie festlegen. Bei relevantem Risiko Kategorien bedenken und formulieren, ohne für jede Kleinigkeit eine Matrix zu verlangen. Beispiel: UX moderat im Designsystem; Struktur gering, Routen bleiben; Funktionen nur die genannten Kontoaktionen; Inhalte knapp, keine erfundenen Hilfeseiten.
4. Unveränderliche oder freigabepflichtige Grenzen nennen. Sicherheitskontrollen, freigegebene Stacks, Designbausteine und geschützte Regeln bleiben bindend. Geschäftsrichtlinien, Löschung, Berechtigungen und externe Wirkungen brauchen zuständige menschliche Entscheidungen.
5. Ein zusammenhängendes Inkrement implementieren. Freigegebene Bausteine verwenden und nur das begrenzte Ergebnis umsetzen. Zusätzliche Möglichkeiten separat zur Entscheidung vorlegen, statt Umfang still zu erweitern.
6. Das funktionierende Produkt prüfen. Ergebnis selbst nutzen: Was wurde gebaut, angenommen oder zusätzlich eingeführt, was ist falsch? Seiten, Abläufe, Vorgänge oder API-Verhalten prüfen, nicht nur Zusammenfassungen lesen. Die Prüflast muss beherrschbar bleiben.
7. Anpassen und wiederholen. Mit direktem Feedback Produkt und nächsten Spielraum korrigieren. Agenten pflegen Sollverhalten für Folgearbeit und unabhängige Verifikation. Weitergehen, wenn das Ergebnis für die aktuelle Phase passt, nicht nach ritueller Textfreigabe.

Dies ist ein optionales Promptmuster, kein Pflichtformat, zusätzliches Artefakt oder Freigaberitual. Nur die für das Inkrement nötigen Details verwenden; Grenzen können gesprochen, geschrieben oder im Projektkontext stehen.

## Nächstes Inkrement
[Welches funktionierende Ergebnis soll entstehen?]

## Umfang
Enthalten: [nötiges Verhalten und Inhalt]
Ausgeschlossen: [nicht hinzuzufügende Funktionen, Seiten, Abläufe oder Texte]

## Agentischer Entscheidungsspielraum
- Kreativ / UX: [Freiheit und Grenzen]
- Strukturell: [änderbare Organisation]
- Funktional: [ob zusätzliches Verhalten vorgeschlagen oder umgesetzt werden darf]
- Inhaltlich: [was entworfen oder erfunden werden darf]

## Freigabepflichtige Entscheidungen
[Geschäftsregeln, Abhängigkeiten, wesentliche Erweiterungen oder andere Eskalationen]

## Prüfziel
[Was wird der Product Engineer nutzen, prüfen oder vorführen?]

Eine nicht genannte Kategorie erlaubt keine unbegrenzte Erweiterung. Nützliche Vorschläge bleiben von der tatsächlichen Umsetzung getrennt.

Diese drei Szenarien sind illustrativ und hypothetisch, keine realen Kundenprojekte.

Dokumentationswebsite: breite UX-Freiheit, enger Umfang und Inhalt

Absicht: Erste Framework-Website mit ausdrücklich erlaubten Bereichen. Kreativ/UX: breite Darstellungsspielräume im Designsystem. Strukturell: Organisation innerhalb genehmigter Seiten, keine neuen Hauptseiten oder Inhaltsbereiche ohne Zustimmung. Funktional: nur verlangte Website-Fähigkeiten; zusätzliche Werkzeuge vorschlagen. Inhaltlich: bereitgestellte Fakten und Entscheidungen verwenden, keine erfundenen Fälle oder Methoden als freigegeben veröffentlichen. Inkrement: Navigation, Startseite und eine repräsentative Inhaltsseite, dann Prüfung.

Warum: Eine riesige Spezifikation kann viele plausible Seiten und Fallstudien erzeugen, deren Aussagen der Eigentümer noch nicht kennt, selbst wenn die Qualität hoch ist.

ERP-Ablauf: enger funktionaler Spielraum

Absicht: Ein neuer Genehmigungsvorgang in einem bestehenden System. Kreativ/UX: bestehende Muster für Klarheit nutzen. Strukturell: Modulgrenzen und Erweiterungspunkte beachten. Funktional: keine neuen Zustände, Buchungseffekte, Berechtigungen oder Integrationen ohne Zustimmung. Inhaltlich: vorhandene Fachbegriffe und Richtlinien. Inkrement: einen vollständigen Vorgang mit Autorisierung und Validierung liefern und prüfen, dann weitere Abläufe.

Warum: Ein plausibler zusätzlicher Ablauf kann echte Geschäfts- und Datenfolgen haben, obwohl seine UI nützlich wirkt.

Interner Erkundungsprototyp: bewusst breiter Spielraum

Absicht: Alternativen für ein begrenztes Problem erkunden, ohne Produktionsveröffentlichung oder irreversible Wirkung. Kreativ/UX: breit. Strukturell: breit innerhalb der Prototypgrenze. Funktional: Vorschläge und wegwerfbare Implementierungen erlaubt. Inhaltlich: klar gekennzeichnete synthetische Beispiele erlaubt. Inkrement: trotzdem mit kleinem vorführbarem Stand beginnen und nach Prüfung erweitern.

Warum: Breite Freiheit kann bei expliziter Erkundung und hoher Umkehrbarkeit nützlich sein. Sie muss absichtlich gewährt werden, nicht versehentlich aus einer unklaren Anfrage entstehen.

Agentische Abdrift bedeutet Erweiterung oder Umlenkung des Produkts durch Agentenentscheidungen außerhalb der beabsichtigten oder autorisierten Grenzen. Eine unerwartete Idee ist nicht allein deshalb Abdrift. Problematisch wird ihre Umsetzung, wenn sie den Spielraum überschreitet, Grenzen verletzt oder als ungeklärte Entscheidung eingeführt wird.

Anzeichen sind unbestellte Seiten, Module, Funktionen, Integrationen oder komplexe Texte; erfundene Fachregeln, Validierung, Rechte oder Kriterien; neue Abhängigkeiten trotz freigegebener Bausteine; ein für den PE unüberschaubarer Produktumfang; Zusammenfassungen über erzeugte Menge statt geprüfte Ergebnisse; und wiederholtes Aufräumen nach großen Läufen.

Die Gegenmaßnahme verbietet nicht Kreativität: nächstes Inkrement begrenzen, Entscheidungsfreiheit bestimmen, Ergebnis prüfen und bewusst erweitern. So bleibt Steuerung vorausschauend statt reaktiver Schadensbegrenzung.

Product Engineer: bestimmt Ergebnis, Umfang und Spielraum, benennt zuständige Entscheidungen, nutzt das Produkt, lenkt um und hält Inkremente prüfbar. Das braucht keine aufwendige Dokumentation oder formale Textfreigabe.

Coding-Agent: nutzt nur gewährte Freiheit innerhalb von Projekt-/Unternehmensregeln, erweitert nicht still, schlägt wesentliche Ergänzungen vor und pflegt Sollverhaltenskontext.

Architekt / Senior Engineer: bestimmt technische Grenzen und prüft wesentliche Abweichungen und Implementierung an bestehenden Kontrollpunkten. Keine weitere Architektenfreigabe entsteht.

UX-Designer: bestimmt bei Bedarf UX-Grenzen und prüft Ergebnisse; kann bewusst Kreativität innerhalb eines Systems erlauben. Kein vollständiger Vorabentwurf wird verlangt.

Fachliche Stakeholder: entscheiden wesentliche Geschäftsregeln und akzeptieren das funktionierende Produkt in Prüfung/UAT. Verantwortung geht nicht auf Agenten über.

Ergebnisorientierte Entwicklung bleibt erhalten: Absicht kann im Gespräch entstehen; Agenten pflegen Spezifikationen als Arbeitskontext für spätere Änderungen und unabhängige Prüfungen. Menschen nehmen das Produkt, nicht das Spezifikationsdokument ab. Eine kurze genaue Aussage über erlaubte Entscheidungen und feste Grenzen ist oft hilfreicher als umfangreiche Vorabprosa.