ki-eit/02-mindset-und-mentales-modell.md

2. Mindset und mentales Modell: Produktive Arbeit mit Coding-Agents

Kern: Produktive Agent-Arbeit im Enterprise-Stack ist kein Prompt-Talent und kein Modell-Wechsel-Theater. Sie basiert auf einem klaren mentalen Modell — LLM + Harness, enger Context, prüfbare DoD, enge Slices — und auf der These-7-Inversion: Der Stack bleibt; Alignment, Verify und Review steigen.

Theorie und Systemtiefe stehen in Coding Agents in der Praxis (besonders Kap. 1–5, 7–8, 10, 12–14). Copilot-Produktiefe optional in Der Copilot-CLI-Harness. Die Auffrischung in Kap. 1.3 ist der Schnellstart ohne Schwestern; dieses Kapitel ist die operative Vertiefung für den Alltag mit Angular, Spring Boot (+ Quarkus) — handlungsorientiert und tool-unabhängig (Surfaces: Copilot, Claude Code, Codex, Grok Build u. a.; Mapping Anhang C).

Du brauchst hier kein zweites Theoriebuch. Du brauchst ein gemeinsames Bild im Team: Was ist der Agent? Warum wird die Session teuer? Wann ist „fertig“? Und was ändert sich, wenn der Stack nicht der Agent-Sweet-Spot ist? Die Antworten steuern Session-Start, Task-Schnitt, Review und die Pflege von Instructions — also genau die Stellen, an denen Enterprise-Teams sonst stillschweigend Nacharbeit budgetieren.

2.1 Die teure Session: dritter Fix, falsches Grün

Freitag, 16:40. Der Agent hat den dritten Fix-Versuch in derselben Session gemacht. Im Context stapeln sich:

• drei Stacktraces aus ./mvnw test, einer davon von Versuch eins, den längst kein Code mehr trifft,
• halb gelesene Angular-Dateien inklusive einer *.module.ts, die im Golden Path gar nicht mehr vorkommen soll,
• eine selbstbewusste Erklärung, warum Versuch zwei „eigentlich schon fast“ stimmte,
• und ein Diff, der Frontend-Spec, Controller und eine unbeteiligte Utility anfasst.

Die Unit-Tests im Frontend sind grün. Die API-Security-Tests nicht — die hat niemand in der DoD genannt. Der Reviewer braucht zwanzig Minuten, nur um zu verstehen, was der Auftrag war. Niemand will „noch ein stärkeres Modell“; alle wollen raus aus dem Context-Schlamm.

Das ist keine exotische Edge-Case-Story. Es ist der Normalfall, wenn drei Dinge fehlen: frischer Context, agent-prüfbare Fertigstellung und ein Schnitt, den Mensch und Agent im Kopf behalten.

Was du in genau dieser Lage tust

1. Session beenden oder hart compacten — nicht „noch einen Versuch“ auf altem Ballast.
2. DoD in einem Satz nachziehen: welcher Command muss grün sein, welcher Diff-Scope ist erlaubt.
3. Slice verkleinern: z. B. nur API-Endpoint + ein Test; UI im nächsten Slice.

{width=90%}

Wenn du nur eine Gewohnheit aus diesem Kapitel mitnimmst: stoppe teure Sessions früher. Der dritte Fix-Versuch auf vergiftetem Context ist fast immer teurer als fünf Minuten Handoff und ein sauberer Neustart — für Token, Review und Nerven.

2.2 Das mentale Modell in vier Bildern

Die Freitag-Session scheitert selten am „falschen Modell“. Sie scheitert an einem fehlenden gemeinsamen Bild: Was steuert der Agent wirklich? Was füllt den Context? Wann ist fertig? Die neun Thesen aus dem Theoriebuch sind dafür ein Betriebssystem, kein Zitatenschatz. Hier die Übersetzung für den Stack — Details und Begründungen bleiben in Coding Agents in der Praxis.

These (praxis)	Was du im Companion brauchst
1 LLM + Harness	Agent steuern: Tools, Permissions, Instructions — nicht nur „das Modell“
2–3 Context is King / U-Form	Session eng halten; mehr Log ≠ bessere Fixes
4 DoD agent-prüfbar	Commands in Instructions/AGENTS.md; Verify non-negotiable
5 Aufgabenform	Outcome + Nebenbedingungen + Ausschlüsse + messbare DoD
6 Slices / Komplexität	dünne UI↔API↔DB-Scheiben (Kap. 8)
7 Stack-Wahl	invers: Stack gesetzt → Alignment + Gates (Kap. 2.3)
8 Karpathy-Fokus	Think / Simplicity / Surgical / Goal-Driven als Haltung
9 Hygiene	eine Wahrheit; tote Rules = Context-Gift

Die Tabelle ist die Landkarte. Die nächsten vier Abschnitte sind die Orte, an denen Teams im Alltag am häufigsten den Faden verlieren: Harness unterschätzen, Observations horten, Context vergiften, DoD und Slice weglassen.

2.2.1 LLM vs. Harness

Das LLM sagt das nächste Token. Es hat kein zuverlässiges Langzeitgedächtnis über Sessions und kein treues Weltmodell deines Repos. Lücken füllt es selbstbewusst — deshalb klingen NgModule-Vorschläge 2018 und erfundene Spring-Annotations so überzeugend.

Der Harness macht aus Vorhersage einen Agenten. Die Jobs sind herstellerübergreifend — nur Dateinamen und Surfaces unterscheiden sich:

Harness-Komponente	Job (generisch)
Instructions / Conventions	weiches Memory: Mission, Stil, Commands, Immer/Nie
Tools & Permissions	was der Agent darf (hart: freigeben/blocken)
Context-Assembly	was in die Session kommt (Discovery, Ignore, Progressive Disclosure)
Agent-Loop	Plan → Tool → Observation → weiter
Memory / Handoff	episodisch über Sessions (Compact+Hint, Handoff-Datei)
Verify / DoD-Hooks	agent-prüfbare Fertigstellung (Commands, Skills, CI-Spiegel)

Surfaces (Beispiele — Pfade sind Muster, sie driften):

Agent	Typische Soft-Surfaces
GitHub Copilot	.github/copilot-instructions.md, path-instructions, Package-AGENTS.md, Skills, Tool-Approval
Claude Code	CLAUDE.md (+ path/local Rules laut Doku)
Codex	AGENTS.md / projektspezifische Conventions (laut aktueller Doku)
Grok Build	AGENTS.md, .grok/rules/, Skills/Slash-Commands

Volles Mapping und Transfer-Checkliste: Anhang C. Optionale Copilot-Produktiefe: Der Copilot-CLI-Harness.

These: Wer nur das Modell wechselt und Harness, Context und Aufgabe gleich lässt, greift am falschen Hebel.

Wenn der Agent „komisch“ wirkt, lohnt der erste Blick oft nicht dem Prompt, sondern dem Harness: Darf er schreiben? Welche Rules sieht er? Welchen Diff hast du wirklich freigegeben?

Do this	Avoid that
Instructions und Permissions pflegen wie Code	YOLO-Permissions „weil schneller“
Skills für wiederkehrende Prozeduren (Verify, Slice)	800-Zeilen-Essay in Root-Instructions
read vor write; Diff lesen	blindes Apply aller Agent-Patches

{width=90%}

Kurz: Modell-Wechsel-Theater bei unpflegtem Harness ist wie ein neuer Motor im Auto mit platten Reifen. Systemtiefe: Coding Agents in der Praxis, Kap. 2.

2.2.2 Der Loop und warum Observations den Context füllen

Agents arbeiten in einer Schleife: planen → Tool → Observation → weiter. Jede Observation — Test-Output, git status, Dateiinhalt, Fehlermeldung — landet im Context. Das ist nützlich und teuer zugleich: Jeder Tool-Lauf kauft Information und zahlt mit Platz im Arbeitsgedächtnis.

Im Angular/Java-Alltag eskaliert das schnell: volles mvn clean install nach jedem Einzeiler, ng test ohne Scope, „lies nochmal das ganze application.yml“. Nach dem dritten Fehlversuch ist der Context voller historischer Wahrheiten, die den vierten Versuch vergiften. Du merkst das daran, dass der Agent alte Stacktraces zitiert, die der Code längst nicht mehr wirft — und trotzdem „begründet“, warum sein nächster Patch passt.

{width=90%}

Deshalb trennt dieses Buch Tight-Loop (scoped, schnell, nach sinnvollen Patches) von Heavy (volle Suite / CI-nah, vor Merge). Details und Commands kommen in Kap. 9; hier zählt nur die Haltung:

Do this	Avoid that
Tight-Loop: scoped Test/Lint (Kap. 9)	Heavy nach jedem Tippfehler
Nach 2–3 gescheiterten Fixes: Context resetten	denselben Stacktrace dreimal „erklären lassen“
Observation bewusst wählen (eine Datei, ein Test)	Repo-Dump „zur Sicherheit“

Wer Observations spart, spart nicht an Gründlichkeit — er schützt den Context für den nächsten echten Fix.

2.2.3 Context als Arbeitsgedächtnis

Context is King: die Antwortqualität ist höchstens so gut wie der Context. Performance ist oft U-förmig — zu wenig Kontext rät; zu viel Kontext (Session-Rot, Lost-in-the-Middle) wird teurer und schlechter. Das ist Praxisheuristik, keine heilige Messkurve; Vertiefung in Coding Agents in der Praxis, Kap. 3–5.

Im Stack siehst du den rechten Schenkel der U-Kurve selten als abstrakte „Token-Zahl“. Du siehst ihn als Ballast:

Ballast	Typische Quelle
Alte Stacktraces	wiederholte Full-Builds ohne Scope
NgModule- / RxJS-Nostalgie	fehlender Golden Path in Instructions
Falsche Module gelesen	unklare Package-Grenzen, kein Ignore
„Fast fertig“-Prosa	keine Stop-Bedingung (DoD)
Multi-Repo-Chaos	Frontend- und Backend-Wahrheit in einer Session

{width=90%}

Gegen diesen Rot brauchst du keine längere System-Message. Du brauchst vier Hebel, die Teams bewusst und früh ziehen — nicht erst, wenn der Reviewer den Faden verloren hat:

1. Neue Session — frischer Start, wenn der Thread vergiftet ist.
2. Compact mit Hint — kürzen, aber die aktuellen Constraints behalten (templates/compaction-hints-stack.md).
3. Handoff — episodisch an Datei/Prompt übergeben (templates/handoff-stack.md, Skill handoff-stack).
4. Progressive Disclosure — Root-Instructions kurz; Details am Pfad und im Package (Kap. 4 und 10). Details on-demand laden statt alles permanent in den Context zu pressen.

{width=90%}

Do this	Avoid that
Hint: Slice, DoD-Command, Ausschlüsse	Compact ohne Orientierung → Agent vergisst den Auftrag
Handoff nach Slice-Grenze FE/BE	eine Session über Monorepo und drei Services
Ignore für dist/, target/, generierte Clients	Index-Müll als „Context gratis“

Compact ohne Hint ist wie ein Meeting-Protokoll, in dem die Beschlüsse fehlen: kürzer, aber nicht handlungsfähig. Handoff und Progressive Disclosure sind die Gegenmittel, wenn der Auftrag die Session-Grenze sprengt oder die Rules den Root-Context sprengen würden.

2.2.4 DoD und Slices als Betriebssystem

Ohne agent-prüfbare Definition of Done endet der Loop nie sauber: der Agent erklärt „fertig“, Tests sind grün auf dem falschen Slice, Security oder Contract fehlen. DoD heißt: ein Command (oder eine kurze Kette), den der Agent ausführen und am Exit-Code erkennen kann — non-interactive, in Instructions/AGENTS.md auffindbar. Orakel-Logik: praxis Kap. 10; Commands: dieses Buch Kap. 9 und Anhang B.

Vertikale Slices begrenzen Komplexität: eine dünne, nutzbare Scheibe UI ↔ API ↔ Persistenz statt „erst alle DTOs“. Komplexitätsbudget ist Review-Budget: was du im Diff nicht in endlicher Zeit verstehst, war zu groß. Mechanik: praxis Kap. 8; Stack-Übersetzung: Kap. 8 dieses Buchs.

{width=90%}

Do this	Avoid that
DoD vor dem ersten Patch nennen	„mach das Feature, ich schau später“
ein Slice = ein Outcome + Verify	horizontaler Big-Bang über Layer
Verify non-negotiable vor Commit	Commit auf Agent-Selbstaussage

Handlungsempfehlung nach dem Modell: Wenn die Session wehtut, frage in dieser Reihenfolge: Context vergiftet? DoD unklar? Slice zu groß? Meist reicht die erste ehrliche Antwort — und ein Reset. Alles andere ist Symptombehandlung am falschen Hebel.

Mini-Beispiel (Angular + Spring): Auftrag „Bestellstatus in der Liste anzeigen“. Explore findet List-Component, Order-DTO und GET /api/orders. Plan: nur Anzeige + Mapping, kein Checkout-Refactor. Execute: ein Component-Diff, ein Mapper, ein Controller-Feld. Verify: npm test -- --include=order-list und ./mvnw -Dtest=OrderControllerTest test. Commit. Was nicht in denselben Slice gehört: Payment, neue NgModules, „solange wir schon da sind“ Logging-Framework.

So sieht das mentale Modell aus, wenn es greift: enger Context, klare Stop-Bedingung, dünner Schnitt. Fehlt eines der drei, bist du wieder bei Freitag 16:40.

2.3 These 7 invers: fester Stack, härtere Disziplin

Bis hierher gilt das Modell stack-agnostisch. These 7 ändert die Kostenrechnung, wenn du den Stack nicht wählen darfst.

Im Theoriebuch lautet These 7 sinngemäß: wählt Sprachen und Frameworks so, dass Agents dort zuverlässig wartbaren Code liefern — wenn ihr die Wahl habt (Trainingsdaten-Präsenz als Proxy; Rankings in praxis Anhang B).

Enterprise invertiert die Prämisse oft:

1. Angular + Spring Boot (+ ggf. Quarkus) sind gesetzt (Compliance, Bestand, Hiring, Plattform).
2. Dann sinkt nicht die Ambition — es steigen Alignment, Slice-Enge, Verify-Härte, Review-Budget und Teach-back.

Das ist keine Kapitulation vor „schlechtem Stack“. Es ist die ehrliche Kostenrechnung: verbose Frameworks, reiche Conventions und gemischte Legacy-Muster erzeugen mehr Agent-Nacharbeit. Die Antwort ist nicht Prompt-Magie, sondern Repo-Wahrheit — und die Disziplin, Nacharbeit sichtbar zu machen, statt sie als „Agent-Pech“ abzubuchen.

Was die Inversion im Alltag heißt

Hebel	Konkret im Stack
Alignment	Golden Path: Standalone/Signals; Spring-Layer; Quarkus-Extensions — in Instructions, nicht nur im Wiki
Engere Slices	ein Endpoint + eine Liste/Detail-UI, nicht „Customer-Domain komplett“
Härtere Gates	scoped ng test / ./mvnw -Dtest=… / @QuarkusTest in der DoD; Security-Tests nicht optional
Review-Budget	Agent-PRs als Contractor-Diffs planen (Kap. 3 und 12)
Teach-back	dreimal derselbe Fehler → Rule/Skill/path-instruction, nicht nur Chat-Rüge
Eine Wahrheit	Runtime-Pin + dieselben Commands lokal und in CI (Kap. 4.1, 9.4)

Menschliche Korrektur ist Feature, nicht Bug. Agents beschleunigen Muster; Verantwortung für Merge und Produktion bleibt beim Team. Wer das ignoriert, bekommt Throughput-KPIs und stille Nachtschichten im Review.

{width=90%}

Do this	Avoid that
Nacharbeit tracken und in Rules zurückschreiben	„nächstes Modell löst Angular“
Quarkus als eigenes Idiom behandeln	Spring-Code 1:1 portieren lassen
Review-Zeit im Sprint explizit machen	Agent-Throughput als einzige KPI

Die Inversion ist der rote Faden des Buchs: Wenn der Stack bleibt, muss die Umgebung agent-fähig werden — nicht der Stack „agent-modern“ umetikettiert werden.

2.4 Operatives Mindset: acht Prinzipien

Sieben operative Hebel plus ein Ownership-Satz. Die Prinzipien sind absichtlich repetitiv. Teams vergessen sie genau dann, wenn der Agent „fast fertig“ wirkt — also in dem Moment, in dem Disziplin am teuersten ist und am meisten spart.

1. Context eng und frisch halten

Arbeite im Sweet Spot. Vergiftete Sessions sind billiger neu als teuer weiter. Das klingt trivial, bis der dritte Fix „schon fast“ sitzt und niemand den Thread beenden will.

Do this	Avoid that
Neue Session / Compact+Hint / Handoff als Ritual	„nur noch schnell“ auf 80 % vollem Context
Eine Aufgabe pro Session-Fokus	Feature + Refactor + Dependency-Bump gleichzeitig

2. DoD vor dem ersten Patch

Stop-Bedingung vor Schreibzugriff. Sonst optimiert der Agent auf Überzeugungsprosa — und du reviewst später, ob überhaupt etwas Fertiges gemeint war.

Do this	Avoid that
„Fertig = … grün und Diff nur unter …“	DoD nachschieben, wenn der Diff schon 40 Dateien hat

3. Vertikal schneiden

Dünnes end-to-end Outcome schlägt horizontale Layer-Monster. Ein greifbarer Use-Case von UI bis Persistenz ist reviewbar; „erst alle Entities“ ist es oft nicht. Siehe Kap. 8 und templates/skill-fullstack-slice/.

Do this	Avoid that
UI ↔ API ↔ DB für einen Use-Case	„erst alle Entities“

4. Aufgabe = Outcome + Nebenbedingungen + Ausschlüsse + DoD

These 5 aus der Praxis, stack-nah formuliert. Die vier Teile verhindern die typische Drift: der Agent „hilft mit“, indem er den Scope still erweitert.

Outcome: POST /api/orders legt Order an und UI zeigt Bestätigung
Nebenbedingungen: bestehendes Security-Pattern, OpenAPI anpassen
Ausschlüsse: kein Refactor von Payment, keine neuen NgModules
DoD: ./mvnw -Dtest=OrderControllerTest test && (cd apps/web && npm test -- --include=order)

{width=90%}

Vorlage: templates/task-prompt-fullstack-slice.md.

Do this	Avoid that
Ausschlüsse explizit	vages „wie die anderen Features“ ohne Beispielpfad

5. Karpathy-Fokus erzwingen (These 8)

Haltung, keine Religion und kein Pflicht-Skill-Dateiname — aber ohne diese vier Hebel driftet jeder Agent in „hilfreiche“ Nebenjobs:

• Think before coding — Plan in 5–10 Zeilen, dann patchen.
• Simplicity first — weniger Abstraktion als der Agent vorschlägt.
• Surgical changes — keine Drive-by-Formatierungen und Nachbar-Refactors.
• Goal-driven — am DoD-Command messen, nicht am Redefluss.

Do this	Avoid that
Diff-Review gegen den Auftrag	„der Agent hat schon aufgeräumt“ mitlieben

6. Eine Wahrheit und Hygiene (These 9)

Repo-Müll und widersprüchliche Rules sind Alignment-Gift: alte AGENTS.md, tote Skills, 2019- und 2026-Patterns nebeneinander, Runtime „irgendwie Node 18 lokal / 22 in CI“. Der Agent liest das nicht als „historische Schichten“, sondern als gleichrangige Wahrheit — und mischt.

Do this	Avoid that
Instructions und Commands gemeinsam reviewen	Wiki als einzige Build-Wahrheit
Tote Pfade löschen oder hard-deprecaten	„vielleicht braucht das noch jemand“ im Agent-Index

7. Prozess und Schnitt schlagen Prompt-Magie

Modell-Wechsel-Theater bei gleichem Context-Müll und unklarer DoD ändert wenig. Permissions enger als die menschliche Bequemlichkeit (Kap. 12); Templates und Rituale schlagen Helden-Prompts.

Do this	Avoid that
Explore → Plan → Execute → Verify → Commit	Skip-Verify weil „lokal schon mal grün war“
Team-Templates	private Prompt-Sammlung als Wissenssilo

8. Verantwortung bleibt menschlich

Review, Merge, Produktion: Agents sind beschleunigte Contractor, keine Accountable Owners. Ohne dieses achte Prinzip werden die sieben Hebel zu Geschwindigkeits-Theater.

Do this	Avoid that
Agent-PRs wie Contractor-Diffs reviewen	Auto-Merge auf Selbstaussage „fertig“
Ownership im Team benennen	„der Agent hat committed“ als Verantwortungsende

Was Teams oft falsch verstehen

Die Prinzipien klingen einleuchtend, bis sie im Stand-up gegen andere Erzählungen laufen. Diese fünf Fehlannahmen tauchen in Reviews und Retros am häufigsten auf:

Fehlannahme	Korrektur
„Bessere Prompts ersetzen fehlende Commands“	Ohne Verify im Repo bleibt DoD Theater
„Mehr Context-Dateien = sicherer“	Oft das Gegenteil: Rot und Lost-in-the-Middle
„Grün = fertig“	Grün auf welchem Slice? Security? Contract?
„These 7 heißt wir müssen den Stack wechseln“	Invers: Stack bleibt, Disziplin steigt
„Review ist Misstrauen gegenüber dem Agent“	Review ist Ownership — wie bei jedem Contractor-Diff

Wer diese Korrekturen im Team teilt, spart sich die nächste Debatte über „das Modell ist schlecht“ — und redet über Context, DoD und Schnitt.

2.5 Tages- und Session-Rhythmus

Prinzipien ohne Rhythmus bleiben Poster an der Wand. Der empfohlene Default-Workflow ist bewusst langweilig:

Explore → Plan → Execute → Verify → Commit

Explore: relevante Dateien und Golden Paths finden — nicht das halbe Monorepo.
Plan: Schnitt, Ausschlüsse, DoD-Commands; bei Unsicherheit nachfragen.
Execute: surgical patches im Slice.
Verify: non-interactive, scoped; non-negotiable. Tight-Loop während der Arbeit, Heavy vor Merge/CI (Kap. 9).
Commit: erst wenn DoD und Diff zum Auftrag passen — und nur mit Erlaubnis im Harness.

{width=90%}

{width=90%}

Der Happy Path bricht im Alltag nicht am Workflow-Namen — er bricht an Symptomen. Dann greifen die Context-Rituale neben dem Happy Path:

Symptom	Ritual
Dritter Fix ohne Fortschritt	neue Session oder Compact+Hint
FE fertig, BE beginnt	Handoff-Datei; getrennte Session
Instructions geändert	kurze neue Session, damit Rules greifen
Reviewer versteht Auftrag nicht	Task-Prompt war zu dünn — nachziehen, nicht „nochmal generieren“
CI ≠ lokal	Runtime/Commands drift (Kap. 4.1) — Fix der Wahrheit, nicht Prompt

Checklisten und Skills zum Mitnehmen: checklists/session-start-angular-java.md, templates/skill-verify-stack/, templates/skill-handoff-stack/, templates/compaction-hints-stack.md.

Zwei Session-Typen, die Teams oft vermischen

Typ	Ziel	Typischer Fehler
Liefer-Session	ein Slice grün und reviewbar	Exploration und Refactor mitliefern
Teach-back-Session	Instructions/Skills/Golden Path korrigieren	im Feature-Diff „nebenbei“ Rules anfassen

Trennen lohnt sich: erst liefern und mergen, dann in einer kurzen Session die Rule nachziehen — sonst reviewt niemand die Verhaltensänderung im Harness. Du merkst die Vermischung daran, dass der Feature-PR plötzlich auch Convention-Dateien (AGENTS.md, CLAUDE.md, copilot-instructions.md, …) anfasst und der Reviewer zwischen Domäne und Agent-Policy springen muss.

{width=90%}

2.6 Messgrößen und Review-Budget

„Der Agent hat 2 000 Zeilen geschrieben“ ist Throughput, kein Erfolg. Im Enterprise zählt, was Liefer- und Governance-Risiko senkt — und was du im Sprint ehrlich budgetieren kannst.

Dimension	Beispiel-Messgröße
Zuverlässigkeit	Anteil Tasks mit akzeptiertem erstem Slice
Reviewbarkeit	Median Review-Minuten; Diff-Dateizahl im Budget
Verifizierbarkeit	Zeit bis erstes sinnvolles Verify; DoD in PR beschrieben?
Kostenkontrolle	Nacharbeits-Commits pro Agent-PR; geplante Context-Resets
Team-Lernkurve	Teach-backs in Instructions/Skills pro Sprint

Messgrößen steuern Verhalten. Belohnst du Zeilen und Session-Anzahl, bekommst du laute Agents und stille Nacharbeit. Belohnst du First-Slice-Accept und Reviewbarkeit, steigen Schnitt und DoD-Qualität von allein.

Review-Budget (Faustregeln)

• Slice so schneiden, dass Review in einer Sitzung möglich ist.
• Überschreitet der Diff das Budget: zurück an den Agent mit „split“ — nicht „lgtm weil CI grün“.
• Security-, Daten- und Permission-Touchpoints immer manuell (Kap. 12).
• Ampel im Team vereinbaren: grün (Routine), gelb (Senior-Review), rot (HITL/Prod-nah).

Was ihr nicht tracken müsst: Token-Verbrauch als Heldentat, Zeilen pro Stunde, „Anzahl Agent-Sessions“ ohne Qualitätsbezug.

Anti-Hype: bessere Zahlen kommen von wahrer Repo-Infrastruktur und Disziplin, nicht von längeren System-Messages. Menschliche Verantwortung für Review, Merge und Produktion bleibt — Agents ersetzen sie nicht.

Die Dimensionen oben sind nutzlos, wenn niemand sie füllt. Der nächste Abschnitt liefert Branchen-Baselines und anonymisierte Vorher/Nachher-Verläufe — damit „Review-Budget“ und „First-Slice-Accept“ nicht als Sprüche im Retro enden.

2.7 Messbare Wirkung: Branchen-Baseline und Fallstudien

Die teure Session in 2.1 ist kein Einzelfall — und sie ist messbar. Branchenstudien 2025–2026 zeigen denselben Engpass: Agents erzeugen mehr Diffs, Review und Nacharbeit fressen den Gewinn auf. Teams, die Slices, DoD, Golden Paths, Review-Budget und Teach-back konsequent fahren, landen nicht im Wunderland — aber klar oberhalb der unkontrollierten Baseline.

Branchenkontext 2025–2026

Drei Referenzquellen, die unterschiedliche Größen messen und trotzdem in dieselbe Richtung zeigen (Snapshot der Primärquellen, Stand Mitte 2026):

Quelle	Was gemessen wurde	Kernzahlen (wie im Report)
LinearB 2026 (Software Engineering Benchmarks; >8,1 Mio. PRs, ~4 800 Teams)	u. a. AI- vs. unassisted PRs; Flow	30-Tage-Merge-Rate AI-PRs 32,7 % vs. unassisted 84,4 %; agentic PRs oft mehrfach längere Pickup-Zeit; Review trägt oft den größten Anteil der Cycle-Time; AI-PRs im P75 oft deutlich größer
Claude-Code-Studie (Watanabe et al., arXiv:2509.14745; 567 agentische PRs, 157 OSS-Projekte)	Acceptance und Human-Revision in OSS	Agentic-PRs akzeptiert 83,8 % (Human-PRs 91,0 %); von den gemergten Agentic-PRs 54,9 % ohne weitere Änderung → 45,1 % brauchen Human-Revisions
METR-RCT 2025 (Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity)	Task-Zeit mit vs. ohne AI-Tools (erfahrene OSS-Devs)	Mit AI ~19 % langsamer; Selbstschätzung danach ~20 % schneller — Wahrnehmung und Messung klaffen

Lesen der Zahlen: LinearB-Merge-Raten und OSS-Acceptance sind nicht dieselbe Metrik und nicht 1:1 auf euer Agent-Team übertragbar. LinearB misst Flow und AI-authored/assisted PRs im Enterprise-Sample; die Claude-Studie misst Maintainer-Acceptance in OSS; METR misst Task-Zeit in einem RCT. Enterprise-Teams mit Coding-Agents und Pflicht-Review liegen typisch dazwischen. Ohne Slice-Disziplin wandert der Engpass ins Review; mit Disziplin sinken Größe, Nacharbeit und Review-Minuten — nicht die Notwendigkeit menschlicher Ownership.

Was die Metriken in diesem Buch bedeuten

Metrik	Definition hier
Review-Minuten	Median der aktiven Review-Zeit pro Agent-PR (nicht Calendar-Wait bis Pickup)
Nacharbeits-Commits	Ø menschliche Folge-Commits im PR nach dem ersten Agent-Commit
First-Slice-Accept-Rate	Anteil Agent-PRs, die as-is oder almost-as-is gemerged werden (nur Nits, kein Scope-Rewrite) — breiter als „zero-edit merge“
Teach-back-Frequenz	strukturierte Teach-backs pro Sprint (eigene Session → Rule/Skill/path-instruction)

Ein Composite im Detail + Vergleich

Keine zitierfähigen Team-Ergebnisse — kalibrierte Richtkorridore (Composite-Szenarien) zur Größenordnung. Richtung belastbar: unkontrollierte Adoption ≈ LinearB-Reibung; enge Praktiken nähern sich besseren Acceptance-Mustern — ohne 90 %-Märchen und ohne Scheingenauigkeit auf eine Dezimalstelle.

Ausführlich: „Orders-B2B“ (Handel, ~12 Eng) — Composite

Multi-Repo Angular + Spring Boot; Agent-PRs und Review-Schlange wuchsen parallel. ~8 Wochen Intervention: Task-Formel, Tight/Slice-DoD/Heavy, Slices max. ein Outcome, Review-Budget „eine Sitzung“, Teach-back ≥3× Fehler in eigener Session.

Metrik (Richtkorridor)	Vorher (Composite)	Nachher (Composite)
Review-Minuten (Median)	60–80	25–35
Nacharbeits-Commits / Agent-PR	1,5–2,5	0,4–0,8
First-Slice-Accept	20–35 %	50–65 %
PR-Größe P75 (LoC)	300–450	140–190
Teach-back / Sprint	0	1–2

Hebel: kleinere Diffs + gleiche DoD-Namen für Agent und Reviewer — nicht „besseres Modell“.

Weitere Composites (Kern-Intervention, eine Zeile)

Team (Composite)	Situation	Kern-Intervention	Typischer Korridor Review-min → First-Slice
Claims (Versicherung, Quarkus)	Spring-Idiome im Quarkus-Service	Golden Path Jakarta/CDI/Panache + Ampel Security	80–90 → ~40 min; First-Slice oft unter 50 % (Domain/Compliance)
Admin-Portal (öff. Sektor)	strenge Freigaben, unkoordinierte Adoption	Review-Ampel, Diff-Budget, Verify in Root-Instructions	langsam: 85–95 → ~50–60 min; First-Slice ~40 % ohne Repo-Beispiele
Billing (SaaS, Monorepo)	chaotischer Start, dann Disziplin	eine Runtime-Wahrheit, Golden Paths, PR-Labels	50–60 → ~20–25 min; First-Slice ~55–65 % (as-is + almost-as-is ≠ zero-edit)
Checkout (FinTech-nah)	Disziplin ab Tag 1	enge Slices, DoD im Task, Teach-back am selben Tag	vs. Wildwuchs-Ref. 45–90 → ~20 min; First-Slice ~60 %
MES-Web (Industrie, Legacy)	NgModule-2018, Layer-Shortcuts	Golden Path nur neue Module, path-instructions, Scope-Ausschluss	60–75 → ~30 min; First-Slice ~50–55 %

Lesart: Schiefe Starts ähneln der LinearB-Richtung (große Diffs, teures Review) — nicht denselben Prozentpunkten. Happy-Paths: oft ~halbe Review-Minuten, First-Slice im 50–65 %-Band (almost-as-is), unter menschlicher OSS-Acceptance (~91 %). Domain, Compliance und fehlende Golden Paths begrenzen das Plateau.

Was Teams am einfachsten selbst tracken

Mindest-Set (vier Wochen reichen für eine erste Ampel):

1. Review-Minuten (Median) — Stoppuhr oder Reviewer-Schätzung im PR-Template.
2. Nacharbeits-Commits pro Agent-PR — aus Git-Historie zählbar.
3. First-Slice-Accept — Label oder Checkbox: agent-first-slice vs. needs-rework.
4. Teach-back — Label teach-back-done oder Zähler im Sprint-Board (Rule/Skill-PR zählt).

Hilfreiche PR-Labels: agent-assisted, agent-first-slice, needs-rework, teach-back-done, optional split-requested. Proxies (Pickup-Time, LoC, Cycle-Time, Share of cycle time in review, Rework ≤14 Tage) lohnen, sobald ein LinearB-/Jellyfish-ähnliches Tool oder CI-Telemetrie sie ohnehin liefert — nicht als Einstiegshürde.

Woher die Zahlen kommen können

Quelle	Geeignet für
Manuelles Sampling 4–8 Wochen (20–40 Agent-PRs)	First-Slice, Nacharbeit, Review-Minuten
PR-Labels + einfache Dashboards	Trend im Team ohne Plattform-Projekt
DORA-/Flow-Metrik-Tools (LinearB-, Jellyfish-ähnlich)	Pickup, Cycle-Time, Review-Share, Größen
Interne Git-/CI-Telemetrie	LoC, Follow-up-Commits, Rework-Fenster

Quellen der Branchen-Baseline (Primär, Snapshot 2025–2026): LinearB, 2026 Software Engineering Benchmarks Report (u. a. 32,7 % / 84,4 % 30-Tage-Merge); Watanabe et al., On the Use of Agentic Coding (arXiv:2509.14745; 83,8 % / 54,9 % zero-edit unter gemergten); METR / Becker et al., Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (RCT; ~19 % langsamer, arXiv:2507.09089). Die Team-Tabellen darüber sind Composites, keine Zitate dieser Reports.

---

Damit ist das mentale Modell vollständig genug für den Alltag: teure Sessions erkennen, Hebel kennen, Inversion akzeptieren, Prinzipien und Rhythmus leben, Erfolg am Risiko und an wenigen harten Metriken messen — nicht am Output-Volumen. Der Rest des Buchs macht daraus Repo-Infrastruktur.

Key Takeaways

• Agent = LLM + Harness; den Agenten steuern heißt Context, Tools, Permissions und Rules steuern — nicht nur chatten. Sechs Komponenten: Instructions, Permissions, Context-Assembly, Loop, Memory/Handoff, Verify.
• Context ist Arbeitsgedächtnis mit U-Risiko: Session-Rot und Observations sind teurer als ein sauberer Neustart.
• DoD und vertikale Slices sind das Betriebssystem; Verify ist non-negotiable.
• These 7 invers: fester Enterprise-Stack → mehr Alignment, engere Slices, härtere Gates, Review-Budget, Teach-back.
• Acht Prinzipien: Context, DoD-first, vertikal, klare Aufgabe, Fokus, Hygiene, Prozess > Prompt-Magie, menschliche Ownership.
• Erfolg = Zuverlässigkeit, Reviewbarkeit, Verifizierbarkeit, Kosten, Lernkurve — nicht Tokens oder Zeilen.
• Branchen-Baseline 2025–2026: Review ist der Flaschenhals; unkontrollierte Agent-PRs mergen seltener und sind oft größer — Wahrnehmung (METR) und Messung klaffen.
• Composite-Richtkorridore: enge Slices + DoD + Golden Path + Review-Budget + Teach-back senken Review-Minuten und Nacharbeit; First-Slice-Accept im 50–65 %-Band ist realistisch, keine 90 %-Märchen.
• Mindset wirkt nur, wenn Golden Paths, Commands und Rules im Repo wahr sind. Harness-Pfade mappen: Anhang C.

Praktische nächste Schritte

1. Nächste Agent-Session mit checklists/session-start-angular-java.md starten; DoD-Command vor dem ersten Patch notieren.
2. Eine reale Aufgabe in templates/task-prompt-fullstack-slice.md gießen (Outcome, Ausschlüsse, Verify).
3. Root-Instructions/AGENTS.md (Surfaces eures Agents) gegen Kap. 4 prüfen: Runtime + Tight-Loop-Commands wahr?
4. templates/compaction-hints-stack.md und templates/handoff-stack.md (oder Skill) ins Repo legen und einmal bewusst nutzen.
5. Im Team Review-Budget und drei Messgrößen festlegen: Review-Minuten, Nacharbeits-Commits, First-Slice-Accept — plus PR-Labels agent-first-slice / needs-rework / teach-back-done.
6. Vier Wochen Agent-PRs samplen (oder Telemetrie nutzen); Zahlen mit der Branchen-Baseline und den Composite-Korridoren in 2.7 vergleichen — dann eine Intervention schärfen (Slice, DoD oder Teach-back).
7. Danach Kap. 3 (Reibung) und Kap. 4 (Zielbild) bzw. Kap. 9 (DoD/Verify) — Mindset ohne Repo-Wahrheit verpufft.

Dieses Kapitel gibt das Betriebssystem im Kopf. Die folgenden Kapitel bauen die Infrastruktur im Repo — und nur beides zusammen macht Angular, Spring Boot und Quarkus mit Agents zuverlässig lieferbar (Surfaces mappen: Anhang C).