ki-eit/03-enterprise-stack-und-agent-realitaet.md

3. Enterprise-Stack und Agent-Realität

Kern: Angular + Spring Boot (+ Quarkus) sind enterprise-tragfähig — und agentschwächer als der TypeScript-/Python-Sweet-Spot. Plant Reibung: Boilerplate, DI, Annotations, RxJS/Signals-Mix, lange Build-Zyklen.

Mentales Modell und These-7-Inversion: Kapitel 2. Hier die Reibungskarte und das Review-Budget im Alltag — ohne die Hoffnung, dass „nächstes Modell“ euren Bestandscode wegmigriert.

3.1 Warum der Stack bleibt

Montag, Planning. Jemand schlägt vor, das nächste Service „doch lieber in TypeScript“ zu bauen, „weil Agents da besser sind“. Der Einwand ist nicht dumm — er trifft nur den falschen Hebel. Der Rest des Portfolios bleibt Angular und Spring. Hiring, Compliance, Lizenzen, Plattform-Standards und zehn Jahre Domänenwissen verschwinden nicht, weil ein Diff in einem anderen Stack glatter aussieht.

Der Stack bleibt. Das ist oft legitim, manchmal schmerzhaft — und für dieses Buch die Prämisse, nicht das Problem, das wir „lösen“, indem wir Migration predigen.

Was Agents ändern, ist die Arbeitsweise: wie ihr schneidet, was ihr in Instructions schreibt, welche Commands die DoD sind, wie viel Review ihr budgetiert. Was sie nicht automatisch ändern, ist der Einkauf und die Architekturentscheidung von vor drei Jahren. Wer die beiden Ebenen vermischt, führt Debatten über Framework-Wechsel und verschiebt die billigere Arbeit: Alignment im bestehenden Repo.

Kapitel 2 hat die Inversion im Kopf verankert. Dieses Kapitel macht sie konkret: wo reibt der Agent genau an Angular, Spring und Quarkus — und welche Kosten müsst ihr ehrlich auf den Tisch legen, bevor Kap. 4 das Zielbild im Repo baut.

3.2 Wo Agents typisch reiben

Du merkst Stack-Reibung selten als abstrakte „Trainingsdaten-Lücke“. Du merkst sie im Review: NgModule-Code in einem Standalone-Repo, ein Service, der drei Layer überspringt, ein Security-Default, den niemand so meinte, und ein Full-Build, den der Agent nach jedem Einzeiler angestoßen hat. Der typische Fehler entsteht, weil Teams das als „der Agent ist dumm“ verbuchen — statt als vorhersehbare Reibung an einem convention-reichen Stack.

{width=90%}

Die erste Karte ist absichtlich grob — Retro und Onboarding, nicht jede Framework-Edge-Case. Die Heatmap darunter bleibt qualitativ (Bereiche × Reibungsarten, Kosten und Gegenmaßnahmen); sie ersetzt die grobe Übersicht nicht, sondern vertieft sie. Die quantifizierten Alltagskosten stehen in der Tabelle darunter — nicht in der Grafik.

{width=90%}

Die Tabelle übersetzt dasselbe Muster in Alltagssprache und ergänzt illustrative Häufigkeits- und Kostenkorridore. Die Framework-Kapitel (5–7) und die Verify-Matrix (Kap. 9) gehen in die Tiefe; hier zählt: verbose + viele gültige Wege = mehr Nacharbeit, wenn die eine Wahrheit im Repo fehlt.

Zur Lesart der Zahlen: Die Angaben zu Häufigkeit und Kosten sind typische / illustrative Werte aus Enterprise-Teams 2025/26 (Angular + Spring Boot/Quarkus), kalibriert an den Composite-Fallstudien in Kap. 2.7. Keine Peer-Review-Primärstudie, keine exakte Prognose für euer Repo. Richtung und Größenordnung zählen; eure eigene Stichprobe (20–40 Agent-PRs) schlägt unsere Illustration.

Bereich	Typische Agent-Fallen	Was das im Alltag kostet	Typ. Häufigkeit / Kosten (illustrativ)
Angular	veraltete NgModule-Muster, falsche Change-Detection, Test-Setup raten, Style-Guide ignorieren, RxJS/Signals-Mix ohne Regel	Diff wirkt „fertig“, bricht am Build oder am Team-Style; Review wird Stil-Polizei	ca. 30–50 % der Agent-Diffs in Repos mit Mixed-History ohne Golden Path; oft +10–20 Review-Min und 0,7–1,5 Nacharbeits-Commits nur für Stil/Setup
Spring Boot	zu große Klassen, Layer-Shortcuts (Controller → Repository), Security-Defaults, Profile-Chaos, „hilfreiche“ Utility-Explosion	Sicherheits- und Architektur-Schulden im schnellen Patch; Test-Scope unklar	Layer-/Security-Shortcuts erhöhen spürbar die Wahrscheinlichkeit von Architektur-/Security-Nacharbeit; oft 1–2 Extra-Review-Runden; Ampel gelb/rot häufiger als bei UI-Nits
Quarkus	Spring-Idiome 1:1, Extension-Wildwuchs, Native-Build ohne Need, CDI vs. Spring-Denkweise	Zweite Wahrheit im Backend; Agent mischt Ökosysteme	Spring-1:1 in ca. jedem 2.–3. Agent-Backend-Diff ohne Quarkus-Golden-Path; Richtung Fall B (2.7): Nacharbeit ~2,6 → ~1,1 nach klarer Idiom-Linie
Build / Tests	interaktive CLI, volles mvn clean install / unscoped ng test nach jedem Edit, fehlende scoped Tests	Context-Rot (Kap. 2.2); Minutes pro Tight-Loop statt Sekunden	Context-Rot nach 2–4 unscoped Full-Builds/Heavy pro Session; Tight-Loop kostet Minuten statt Sekunden — Session stirbt oft vor dem Architektur-Review
Monorepo / Multi-Repo	Context über Repo-Grenzen, doppelte Rules, unklare Ownership, Contract-Drift	Session weiß nicht, was „wahr“ ist; FE und BE driften still	oft +15–30 Review-Min durch Ownership-/Contract-Klärung; First-Slice-Accept ohne Boundaries eher im unteren Composite-Band (~22–30 %)

Angular reibt, weil der Stack viele historisch gültige Antworten hat. Ohne Golden Path in Instructions (Standalone, Signals wo Team-Standard, Test-Runner und Pfade) greift der Agent auf das, was in Trainingsdaten am lautesten war — oft 2018. In Mixed-History-Reposen ohne feste Linie landet stilistische Nacharbeit illustrativ in 30–50 % der Agent-Diffs. Du gewinnst, wenn der Agent eure Patterns findet; du verlierst, wenn er „ein Angular-App“ erfindet.

Spring Boot reibt an Boilerplate, DI und Security. Der Agent kann schnell Code erzeugen, der aussieht wie Spring — und trotzdem Layer, Transaktionen oder AuthZ verletzt. Das ist teurer als ein Style-Nit: oft eine bis zwei zusätzliche Review-Runden und spürbar höhere Security-/Architektur-Nacharbeit. Verbose Frameworks belohnen den, der das Muster im Repo zeigt (Beispiel-Controller, Test-Slice, Security-Config), nicht den, der im Prompt „bitte clean architecture“ schreibt.

Quarkus reibt doppelt, wenn es neben Spring lebt: derselbe JVM-Alltag, anderes Idiom. 1:1-Portierung von Spring-Code ist die teuerste Illusion — und tritt ohne Golden Path illustrativ in jedem 2.–3. Backend-Agent-Diff auf. Extensions und Dev-Mode sind Stärke — und Falle, wenn der Agent „noch eine Extension“ vorschlägt, die niemand reviewt.

Build ist die Reibung, die Sessions tötet, bevor Architektur es tut. Interaktive Prompts, Heavy nach Tippfehlern, fehlende -Dtest=… / scoped Frontend-Tests: nach 2–4 unscoped Full-Läufen ist der Context oft schon vergiftet. Kap. 9 macht Tight-Loop · Slice-DoD · Heavy operational; hier reicht: ohne scoped Verify plant ihr Reibung und Context-Müll.

Repo-Grenzen reiben, weil der Agent keine Konzern-Landkarte im Kopf hat. Multi-Repo ohne Contract und Handoff; Monorepo ohne Hierarchy und Ignore — beides produziert „falsche Module gelesen“, doppelte Wahrheiten und oft +15–30 Review-Min nur für Ownership-Klärung. Kap. 4 und 8 bauen das Zielbild; die Kosten entstehen jetzt, wenn Ownership und Boundaries unklar sind.

Do this	Avoid that
Reibungspunkte als Team-Liste führen (Top 5 Nacharbeiten)	Jeden Fehlschlag dem „Modell“ zuschreiben
Pro Falle: Golden Path + Verify + ggf. path-instruction	Nur Chat-Rüge nach dem dritten gleichen Fehler
Stack-Idiome trennen (Angular ≠ „irgendein SPA“, Quarkus ≠ Spring)	Ein Prompt-Style für alle Packages
Eigene Stichprobe (20–40 Agent-PRs) gegen die illustrativen Korridore halten	Eine Prozentzahl aus dem Buch als KPI-Ziel festnageln

Wenn ihr die Tabelle ernst nehmt, ändert sich die Stand-up-Frage: nicht „war der Agent heute gut?“, sondern „welche Reibung haben wir noch nicht im Repo wahr gemacht — und wie oft kostet sie uns wirklich?“

3.3 Kostenbudget: Review und Teach-back

Messgrößen, Review-Budget und Branchen-Baseline stehen in Kap. 2.6–2.7. Hier die Stack-Übersetzung: warum These 7 invers im Enterprise-Alltag zwei Kostenarten braucht — und was passiert, wenn ihr sie weglasst.

These 7 invers heißt: menschliche Korrektur ist Feature, nicht Bug. Agents beschleunigen Muster; sie übernehmen nicht Ownership für Merge und Produktion. Wer Review als „Misstrauen gegenüber dem Tool“ framiert, spart die Linie im Sprint-Board — und zahlt sie in stillen Nachtschichten.

Plant zwei Kostenarten explizit (Definitionen und Tracking: Kap. 2.6):

1. Review von Agent-Diffs — wie Contractor-PRs: Auftrag matcht Diff? Scope? Security? Tests? Style des Repos?
2. Teach-back — wenn derselbe Fehler dreimal kommt: Rule, Skill oder path-instruction nachziehen, nicht nur im Chat meckern.

Ohne Budget: Agent-Throughput steigt, Review-Schlange wächst, niemand pflegt Instructions, die nächste Session wiederholt denselben NgModule-Fehler. Mit Budget sinkt die Wiederholrate — langsam, messbar, unspektakulär (Zahlen-Korridore: Kap. 2.7). Ohne Teach-back bleiben die Fallen aus 3.2 im hohen illustrativen Band: oft ~1,5–2,5 Nacharbeits-Commits pro Agent-PR und Review-Mediane über ~50 Min (Composite-„Vorher“ in 2.7) — Angular-Style und Spring-Layer zählen dann doppelt, weil sie sich jede Session wiederholen.

Stack-Alltag (knapp)

• Slice so schneiden, dass Review in einer Sitzung möglich ist (Kap. 2.6).
• Diff über Budget → zurück mit „split“, nicht „lgtm weil CI grün“.
• Security-, Daten- und Permission-Touchpoints immer manuell (Kap. 12).
• Ampel: grün (Routine), gelb (Senior-Blick), rot (HITL / prod-nah).
• Checkliste: checklists/review-agent-diff-enterprise.md.

Teach-back — Signal → Reaktion

Signal	Reaktion
Derselbe Stil-/Pattern-Fehler ≥ 3×	Golden Path in Instructions/AGENTS.md oder Skill schärfen
Immer wieder falscher Test-Command	Verify-Zeile in Root + Package angleichen (Kap. 4, 9)
Immer wieder Scope-Creep im Diff	Task-Template + Ausschlüsse (templates/task-prompt-fullstack-slice.md)
Immer wieder Security-Lücke am Endpoint	path-instruction / Skill Security; Review-Ampel gelb/rot

Teach-back gehört in eine eigene kurze Session (Kap. 2.5): erst Feature mergen, dann Rules anfassen. Sonst reviewt niemand die Verhaltensänderung im Harness, und der nächste Agent-Lauf mischt Feature und Policy.

Do this	Avoid that
Review-Minuten und Nacharbeits-Commits tracken (Kap. 2.6) — ideal pro Reibungsbereich (Angular vs. Build vs. Security)	Nur „Zeilen vom Agent“ als KPI
Teach-back im Sprint sichtbar machen	Wissenskorrektur nur mündlich im Pairing
Agent-PRs wie Contractor-Diffs behandeln	Auto-Merge auf Selbstaussage „fertig“

3.4 In-distribution vor Hausgebrauch

Agents treffen Standard-Layouts und gängige Docs besser als firmeninterne Framework-Wrappers ohne Beispiele. Das klingt nach Binsenweisheit — bis der Agent euer BaseEnterpriseResourceSupportFactory erfinden soll, das nur in einem Confluence-Export von 2019 existiert.

In-distribution heißt hier: Patterns, die dem Modell und dem Harness zugänglich sind — weil sie im Repo liegen, getestet sind und den üblichen Framework-Docs ähneln. Hausgebrauch ohne Repo-Wahrheit ist erlaubt im Konzernalltag, aber teurer: mehr Halluzination, mehr Review, mehr „fast richtig“. Typisch schlägt das in denselben illustrativen Kostenkorridor wie „fehlender Golden Path“ in 3.2: oft +10–20 Review-Min und spürbar mehr Nacharbeit — nicht weil der Wrapper „falsch“ ist, sondern weil der Agent ihn nicht sieht.

Golden Path in diesem Buch ist deshalb nicht „das Schöne im Architektur-Wiki“. Golden Path = das, was im Repo dokumentiert und getestet ist und was Instructions dem Agent als Default nennen. Was nur im Wiki von 2018 steht, ist für den Agent oft unsichtbar — oder schlimmer: widerspricht dem Code von 2026.

Situation	Besser für Agents	Teurer für Agents
Angular-Struktur	Standalone-Beispiel + Test im Repo, in Instructions verlinkt	„Macht wie Projekt X“ ohne Pfad
API-Layer	Ein klarer Controller + Service + Slice-Test als Muster	Interne Superklasse ohne Nutzungshinweis
Security	Bestehendes Pattern kopierbar (Filter/Resource/Annotation)	„Security macht die Platform“ ohne Beispiel
Build	./mvnw / npm-scripts non-interactive	Interaktiver Wizard als „offizieller“ Weg

Do this	Avoid that
Ein greifbares Referenz-Feature pro Layer pflegen	Nur Architektur-Poster ohne Code-Pfad
Hausgebrauch in Instructions explizit mit Beispielpfad	Annehmen, der Agent „kennt unsere Platform“
Tote Patterns hard-deprecaten	2019 und 2026 gleichrangig im Index

In-distribution ist kein Stil-Geschmack und kein Verbot von Eigenbau. Es ist die ehrliche Aussage: je weiter euer Stack von gängigen Mustern und von wahrer Repo-Doku entfernt ist, desto mehr müsst ihr in Alignment, Slices und Review investieren — genau die Hebel aus Kap. 2.3.

3.5 Was die Reibungskarte für den Rest des Buchs bedeutet

Kapitel 3 liefert keine neuen Tools. Es liefert die Landkarte der Kosten, damit Kap. 4–13 nicht wie Wunschdenken wirken.

Reibung (hier)	Antwort (später)
Unklare Runtime/Commands, Index-Müll	Kap. 4 — eine Wahrheit, Instructions, Boundaries
Angular-Fallen	Kap. 5 — Golden Path, Tests, Style
Spring-Fallen	Kap. 6 — Layer, Tests, Security-Muster
Quarkus neben Spring	Kap. 7 — eigenes Idiom, nicht 1:1
Zu große Änderungen	Kap. 8 — vertikale Slices
Build- und Test-Schmerz	Kap. 9 — Tight-Loop · Slice-DoD · Heavy, CI
Rules und Skills	Kap. 10 — Progressive Disclosure, MCP sparsam
Bestand und Migration	Kap. 11 — Strangler, Defaults
Secrets, Permissions, HITL	Kap. 12 — Governance
Rituale und Fallen	Kap. 13 — Checklisten, Anti-Patterns

Wer Kap. 3 überspringt, baut oft trotzdem Instructions — und wundert sich, warum das Team sie nicht ernst nimmt. Wer die Reibung zuerst sieht, versteht, warum schlanke Rules, scoped Verify und Review-Budget keine Hygiene-Theater sind, sondern die Antwort auf einen agentschwächeren Enterprise-Stack.

Key Takeaways

• Der Stack bleibt oft aus guten Gründen; Agents ändern die Arbeitsweise, nicht den Einkauf.
• Reibung ist vorhersehbar: Angular-Historie, Spring-Layer/Security, Quarkus-Idiom-Mix, schwere Builds, Repo-Grenzen — mit illustrativen Häufigkeits- und Kostenkorridoren in 3.2 (kalibriert an den Composites in 2.7; eure Stichprobe schlägt die Illustration).
• These 7 invers im Alltag: Review- und Teach-back-Budget sind Feature — nicht Zeichen, dass „Agents nicht funktionieren“. Ohne Teach-back bleiben die Fallen aus 3.2 im hohen Nacharbeitsband.
• In-distribution und echte Golden Paths (dokumentiert und getestet im Repo) schlagen Prompt-Tricks und Wiki-Archäologie — und senken denselben Kostenkorridor wie „fehlender Golden Path“.
• Die Reibungskarte steuert, wo Kap. 4–13 investieren: Alignment, Slices, Verify, Framework-Idiome, Governance.

Praktische nächste Schritte

1. Top-5 Agent-Nacharbeiten der letzten Wochen sammeln (Retro oder PR-Stichprobe) — ohne Schuldzuweisung an „das Modell“.
2. Pro Eintrag markieren: fehlt Verify, fehlt Docs/Golden Path im Repo, falsches Pattern, oder Scope zu groß? Grob Häufigkeit, Review-Minuten und Nacharbeits-Commits mitschätzen (auch grob reicht).
3. Eure Schätzungen mit den illustrativen Korridoren in 3.2 vergleichen — als Orientierung, nicht als KPI-Ziel.
4. Review-Budget und Ampel (grün/gelb/rot) im Team für die nächsten Agent-PRs festlegen; Checkliste checklists/review-agent-diff-enterprise.md legen.
5. Einen Reibungspunkt mit Teach-back schließen: eine Rule/path-instruction oder ein Referenz-Beispiel im Repo — in einer eigenen kurzen Session.
6. Danach Kap. 4 (Zielbild: Runtime, eine Wahrheit, Instructions) — Reibung ohne Repo-Infrastruktur bleibt nur Diagnose.

Dieses Kapitel benennt den Preis des Status quo. Das nächste baut die Infrastruktur, mit der ihr ihn senkt — ohne den Stack zu wechseln.