ki-eit/01-einfuehrung-und-abgrenzung.md

1. Einführung und Abgrenzung

Kern: Dieses Buch macht den Enterprise-Stack Angular + Spring Boot (+ Quarkus) agent-tauglich — für Coding-Agents wie GitHub Copilot, Claude Code, Codex und Grok Build. Hier stehen Commands, Boundaries, Golden Paths (Stack-Muster) und Review-Budget. Agent-Theorie und optionale Copilot-Produktiefe leben in den Schwesterwerken — du brauchst sie nicht, um mit dem Mindestmodell und dem Repo-Alltag zu starten.

1.1 Für wen dieses Companion ist

Der Stack steht. Einkauf, Bestandscode, Hiring und Compliance haben für Angular im Frontend und Spring Boot im Backend gesprochen — oft plus ein zweites Backend-Profil mit Quarkus (Cloud-native Services, Dev-Speed, container-first). Niemand hat die Architektur danach gewählt, „was der Agent am saubersten generiert“. Und trotzdem sollen Coding-Agents jetzt produktiv werden: kleinere Diffs, weniger Copy-Paste, schnellere Exploration, Verify-Loops, die der Agent selbst ausführen kann. In vielen Teams ist das GitHub Copilot, Claude Code, Codex, Grok Build — oder ein Mix.

Genau in dieser Spannung sitzt dieses Companion. Du brauchst keine Migrationsstory und keine weitere Produkt-Demo. Du brauchst greifbare Hebel im bestehenden Stack, damit der Agent weniger Nacharbeit produziert und Review nicht zum Vollzeitjob wird.

Die Arbeit teilt sich sinnvoll: System und Theorie (Agent = LLM + Harness, Context steuern, prüfbare DoD) sind woanders ausführlich hergeleitet; optionale Copilot-Produktiefe (Instructions, Permissions, Skills, CI am Produkt) ebenso. Dieses Buch beantwortet die Folgefrage, die im Konzernalltag übrig bleibt:

Wenn der Stack bleibt — wie senken wir Reibung und Nacharbeit trotzdem? (Unabhängig vom Agent-Produkt; Surfaces mappen: Anhang C.)

Die Antwort steckt nicht in besseren Einzeilern im Chat. Sie steckt in Repo-Layout, einer Wahrheit für Build und Test, Golden Paths, Verify-Gates und einem Review-Budget, das ihr ehrlich plant. Abschnitt 1.3 gibt dir dafür das Mindestvokabular — ohne Pflichtlektüre.

1.2 Was hier nicht steht — und was Kap. 2 übersetzt

Wer drei Bücher nebeneinander hat, liest sonst das falsche zuerst — und wundert sich, warum Context, Permissions oder Stack-Rankings „fehlen“. Die Abgrenzung ist deshalb Absicht, kein Marketing-Disclaimer: jedes Buch hat einen Job. Die Tabelle ist die Landkarte; Abschnitt 1.3 liefert das Mindestmodell in diesem Buch; Kap. 2 übersetzt es in den Stack-Alltag; ab Kap. 4 greifst du ins Repo.

Thema	Wo es hingehört
Systemtiefe: Agent = LLM + Harness, Loop, Tool-Ökonomie	Mindestmodell: 1.3; operative Übersetzung: Kap. 2; Systemtiefe optional: Coding Agents in der Praxis
Context-Fenster, U-Kurve, Compact, Handoff	Mindestmodell: 1.3; Alltagsrituale: Kap. 2; Theorie optional: Coding Agents in der Praxis
Generische DoD und Orakel-Ökonomie	Mindestmodell: 1.3; Commands: Kap. 9 + Anhang B; Theorie optional: Coding Agents in der Praxis
Stack-Rankings nach Anwendungsfall	optional: Coding Agents in der Praxis, Anhang B
Multi-Agent-Orchestrierung allgemein	optional: Coding Agents in der Praxis
Copilot installieren, Trust, Permissions-Schichten, Fleet, CLI-Flags im Detail	optional: Der Copilot-CLI-Harness
todo-cli und generische Python-Demos	optional: Der Copilot-CLI-Harness (Beispiele)

Was hier folgt, ist die Konkretisierung: Auffrischung der Grundlagen (1.3), mentales Modell und Stack-Alltag (Kap. 2), dann konkrete Repo-Layouts, Instructions/AGENTS.md, Verify-Kommandos, Framework-Idiome, Anti-Patterns und Review-Checklisten für Angular/Java — Surfaces (Copilot, Claude Code, Codex, Grok Build u. a.): Anhang C; Templates unter templates/ als Inhaltsvorlagen. Abschnitt 1.3 reicht als Einstieg; Kap. 2 vertieft den Alltag. Wer System- oder Produkttiefe nachziehen will, findet am Ende von 1.3 einen optionalen Minimal-Leseplan.

{width=90%}

Achtung: Wer nur dieses Buch liest und die Auffrischung (1.3) sowie Kap. 2 überspringt — oder Context, DoD und Permissions als „nicht mein Problem“ abtut — optimiert Boilerplate-Geschwindigkeit und zahlt mit unreviewbaren Diffs. Companion ≠ Ersatz für Disziplin; System- und Produkttiefe bleiben optional.

Die Abgrenzung klärt die Rollen. Bevor der rote Faden (These 7 invers) greift, brauchst du ein gemeinsames Mindestvokabular — lesbar und anwendbar in diesem Kapitel.

1.3 Auffrischung der Grundlagen

Dieses Companion setzt kein zweites Theoriebuch voraus. Die vier Boxen sind das Mindestmodell: knapp genug, um Kap. 2 nicht doppelt zu lesen, greifbar genug, um den nächsten Agent-Lauf anders aufzusetzen. Stack-Szenen, Prinzipien und Metriken: Kap. 2. Commands: Kap. 9. Instructions/Skills: Kap. 10.

Auffrischung: Context-U-Kurve und Session-Rot

Context ist das Arbeitsgedächtnis der Session (Auftrag, Dateien, Rules, Tool-Ausgaben). Die Leistungs-Kurve ist oft U-förmig: zu wenig → Raten (NgModule-2018, erfundene Annotations); zu viel → Session-Rot und Lost-in-the-Middle. Mehr Log ist kein Qualitätsupgrade.

Im Enterprise-Stack füllt sich das Fenster schnell: verbose Angular/Java, ungescopte Builds, Multi-Repo. Observations füllen den Context — jede Tool-Ausgabe kauft Information und zahlt mit Platz.

Mini-Beispiel: Du startest mit einer klaren Randbedingung: „Nur order-list; kein Checkout, kein Payment.“ Danach laufen scoped und ungescopte Tests, der Agent liest drei Legacy-Module und klebt vier Stacktraces aneinander. Die kritische Ausschlussregel sitzt irgendwo in der Mitte des Fensters. Beim nächsten Patch greift der Agent trotzdem in den Checkout — nicht aus Trotz, sondern weil die wichtigen Constraints in der Mitte untergegangen sind und die frischen Logs an den Rändern lauter sind. Dasselbe Muster kennst du aus langen Recherche-Chats: die entscheidende Einschränkung steht im dritten Absatz, der Agent antwortet auf den letzten Thread. Enger Context mit DoD und Ausschlüssen sichtbar (Hint, kurze Rules, neuer Schnitt) ist hier wirksamer als „noch ein Log zur Sicherheit“.

Ballast	Gegenmittel
Alte Stacktraces	Session neu / Compact; Tight-Loop statt Full-Build
Legacy-Nostalgie	Golden Path + Ausschlüsse
„Fast fertig“ ohne Stop	DoD-Command vor dem Patch
Multi-Repo-Chaos	FE/BE trennen; Contract + Handoff

Vier Hebel: Neue Session · Compact+Hint · Handoff · Progressive Disclosure. Alltag: nach 2–3 Fehlversuchen scoped Verify und Hint notieren (templates/compaction-hints-stack.md). Operative Vertiefung: Kap. 2.2.

Auffrischung: Agent = LLM + Harness

Ein Coding-Agent ist LLM + Harness in der Tool-Schleife — nicht „das Modell im Chat“.

• LLM erzeugt das nächste Token; Lücken füllt es selbstbewusst.
• Harness steuert Tools, Loop, Permissions, Context-Assembler, Rules und Verify-Anbindung. Die Jobs sind herstellerübergreifend; die Dateinamen und Surfaces unterscheiden sich.

Surfaces (Beispiele): Root- und Package-AGENTS.md sind die universelle weiche Wahrheit; daneben produktspezifisch z. B. .github/copilot-instructions.md (Copilot), CLAUDE.md (Claude Code), Codex-Conventions, .grok/rules/ (Grok Build). Volles Mapping: Anhang C.

Mini-Beispiel: Im reinen Chat bittest du: „Schreib einen Spring-Controller für den Bestellstatus.“ Du bekommst flüssigen Code — oft mit falschem Package, veralteter Security-Annotation und ohne Bezug zu eurem OpenAPI-Contract. Du kannst den Text kopieren, aber Verify, Diff-Scope und Repo-Wahrheit liegen bei dir. Derselbe Auftrag als Agent-Lauf mit Harness sieht anders aus: der Agent liest AGENTS.md und den Contract, darf nur unter dem freigegebenen Pfad schreiben, führt einen scoped Test aus und liefert einen Diff, den Review und Exit-Code beurteilen können. Der Unterschied ist selten „das bessere Modell“ — es ist der Harness um das Modell herum (Tools, Permissions, Rules, Loop, Verify).

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

Alltag: Bei schiefem Lauf zuerst Rules, Rechte, freigegebenen Diff und letzte Observation prüfen — erst dann Prompt oder Modell. Repo-Wahrheit: Kap. 4 und 10; Permissions: Kap. 12. Sechs Komponenten im Alltag: Kap. 2.2.1.

Auffrischung: Orakel- und DoD-Logik

DoD muss agent-prüfbar sein: non-interactive Command, Exit-Code, in Instructions/AGENTS.md. „Sieht gut aus“ ist kein Orakel. Orakel = Tests, Lint, Build, Contract-Checks.

Aufgabenformel (vier Teile):

Outcome:          was am Ende gilt
Nebenbedingungen: Patterns, Security, OpenAPI, Stil
Ausschlüsse:      was *nicht* angefasst wird
DoD:              messbarer Command (scoped) + erlaubter Diff-Scope

Mini-Beispiel: Auftrag A: „Mach den Bestellstatus modern und sauber.“ Der Agent refactort drei Schichten, erklärt fertig — und Review braucht eine Stunde, weil niemand weiß, was grün sein musste und was tabu war. Auftrag B nutzt die vier Teile der Formel: Outcome „Status-Badge in der Order-Liste“; Nebenbedingungen „bestehendes Design-System, kein neues State-Management“; Ausschlüsse „Checkout, Payment, Logging-Framework“; DoD npm test -- --include=order-list und ./mvnw -Dtest=OrderControllerTest test, Diff nur unter den genannten Pfaden. Auftrag B endet mit Exit-Code und reviewbarem Slice — nicht mit Prosa. Die DoD war vor dem ersten Patch da; deshalb kann der Agent (und du) stoppen, wenn grün ist.

Do this	Avoid that
DoD vor dem ersten Patch	„mach es modern / sauber“
Tight-Loop nach sinnvollen Patches	Heavy nach jedem Tippfehler
ein Slice = ein Outcome + Verify	horizontaler Big-Bang

Vage Aufträge sind im Enterprise-Stack besonders teuer. Der rote Faden dazu ist These 7 invers (nächster Abschnitt): Stack bleibt → DoD, Slice und Review härter, nicht der Prompt poetischer. Commands und Alltag: Kap. 9 + Anhang B; Vertiefung: Kap. 2.2.4 und 2.4.

Auffrischung: Compact, Handoff und Session-Hygiene

Compact+Hint kürzt den Session-Context verlustbehaftet, behält Slice, DoD und Ausschlüsse. Handoff übergibt Session-Zustand an Datei/Prompt — oft gefolgt von neuer Session. Handoff ersetzt keine Repo-Rules.

Mini-Beispiel: In einer Session stehen nacheinander: „nutze NgModule“, später „nur Standalone“, plus zwei veraltete Stacktraces und ein „fast fertig“-Diff. Der Agent pendelt zwischen Patterns und „behebt“ Fehler, die der aktuelle Code gar nicht mehr wirft. Jeder weitere Versuch kauft noch eine Observation und macht die Historie lauter. Hier hilft kein dritter Prompt-Trick. Compact+Hint mit den aktuellen Constraints — oder Handoff und neue Session — trennt den Knoten: widersprüchliche Historie raus, Auftrag und DoD wieder an den Rändern sichtbar. Hygiene ist kein Ritual um des Rituals willen; sie schützt die U-Kurve.

Situation	Ritual
Dritter Fix ohne Fortschritt	Compact+Hint oder Session beenden
FE fertig, BE beginnt	Handoff; getrennte Session
widersprüchliche Observations	neue Session, nicht „noch einen Versuch“

Explore → Plan → Execute → Verify → Commit / Handoff

Alltag: templates/compaction-hints-stack.md und templates/handoff-stack.md bewusst nutzen. Rituale und Start-Check: Kap. 2.5; checklists/session-start-angular-java.md.

Optional: Minimal-Leseplan der Schwesterbücher

Du musst die Schwestern nicht lesen, um dieses Companion zu nutzen — Abschnitt 1.3 und Kapitel 2 reichen als Betriebssystem. Die folgende Liste ist nur für Teams, die Systemtiefe oder — nur bei Copilot — Produkt-Details nachziehen wollen.

Priorität	Coding Agents in der Praxis	Der Copilot-CLI-Harness (optional)	Zeit (Richtwert)
1 — wenn du vertiefst	Kap. 2 (Anatomie LLM+Harness), 3–4 (Context, U-Kurve, Compact/Handoff), 10 (DoD/Orakel), 7–8 (Workflow, vertikale Slices), 14 (Aufgabenformel)	nur Copilot-Teams: Einleitung, Kap. 1–2 (Instructions/Permissions), Kap. 3 (Alltags-Workflow)	ca. 3–5 h skimmen
2 — empfohlen	Kap. 5 (Write–Select–Compress–Isolate, Überblick), 13 (Karpathy-Fokus), 15 (Setup-Hebel); Anhang B nur als Orientierung	nur Copilot: Kap. 4, 6, 7	ca. +2–3 h
Getrost überspringen (nur dieses Buch)	Kap. 6 Memory-Tiers im Vollen, 16–17 Skills/MCP-Theorie, 21–22 Legacy-Tiefe/Multi-Agent-Orchestrierung; Rankings (Anhang B) als Entscheidungsgrundlage zum Stack-Wechsel	Fleet/Autopilot-Fibel, todo-cli-Demos 1:1, vollständige Flag-Referenz, Screenshot-Tour	—

Empfohlene Reihenfolge mit diesem Buch

1. Hier: 1 → 2 → 4 → 9 → 10 (Schnellstart; Templates unter templates/; Surfaces: Anhang C).
2. Optional parallel: Theorie zu Context/DoD, bevor du DoD/CI (hier Kap. 9) im Team standardisierst.
3. Optional nur bei Copilot: Produkt-Fibel zu Instructions/Permissions, bevor du Kap. 10 und 12 schärfst.
4. Framework-Kapitel 5–7 und Slices (8) dieses Buchs brauchen keine Schwestern — nur greifbare Repo-Wahrheit.

Faustregel: Optional nachlesen, wenn im Team Begriffe strittig sind (Was ist Compact? Was ist weich vs. hart?). Stack- und Verify-Arbeit erledigen hier und im Repo — nicht in einem dritten Theorie-Durchgang.

1.4 These 7 — und die Enterprise-Inversion

These 7 lautet sinngemäß: Habt ihr die Wahl, wählt Sprachen und Frameworks so, dass Agents dort zuverlässig wartbaren Code liefern. Starke Trainingsdaten-Präsenz ist ein Proxy dafür — idiomatischere Diffs, weniger Halluzination an APIs, greifbarere DoD. Kurz: wo der Agent „zu Hause“ ist, sinkt die Korrekturkosten.

Im Enterprise ist die Wahl oft schon gefallen. Compliance, Bestand und Plattform-Standards lassen den Stack gesetzt — oder nur teuer änderbar. Dann greift die Enterprise-Inversion von These 7:

1. Der Stack bleibt.
2. Dafür steigen die Anforderungen an das Repo: mehr Alignment (eine Wahrheit für Stil, Commands, Boundaries), engere Slices, härtere Verify-Gates, budgetierte menschliche Korrektur — nicht „bessere Prompts“ und nicht „noch ein stärkeres Modell“ als Ersatz für Struktur.

{width=90%}

Anwendungsskizze: Euer Team darf Angular und Spring Boot nicht tauschen — Compliance und Bestand setzen den Rahmen. Statt Prompt-Politur investiert ihr in drei harte Hebel: Golden Path (Standalone/Signals, dokumentiert in AGENTS.md), eine auffindbare Verify-Wahrheit (npm test -- --include=… / ./mvnw -Dtest=…), und Slices der Größe „nur Order-Status in der Liste“ statt Big-Bang-Modernisierung. Der Agent liefert dann immer noch nicht magisch „Sweet-Spot“-Code. Aber die Diffs werden reviewbar, die DoD messbar, und Nacharbeit sinkt dort, wo sie planbar ist: Alignment und Gates, nicht Chat-Formulierung. Das ist These 7 invers im Wochenrhythmus — nicht als Migrationsplan.

Das ist der rote Faden dieses Buchs (Vertiefung: Kap. 2.3). Angular und Spring sind nicht „schlecht“. Sie sind verbose, convention-reich und in Agent-Defaults oft weniger idiomatisch als Full-TypeScript- oder Python-Sweet-Spots. Quarkus liegt näher an modernen Cloud-Idiomen, teilt aber Java-Verbose und Extension-Fallen. Ignorierst du die Inversion, optimierst du Chat-Formulierungen und wunderst dich, warum der Agent NgModule-2018 und Layer-Shortcuts liefert. Nimmst du sie ernst, investierst du dort, wo es zählt: dokumentierte Golden Paths, auffindbare Verify-Commands, enge Diffs — und der Agent bekommt die eine Wahrheit für Build und Test, ohne die er nur rät.

1.5 Der Stack dieses Buchs

Damit die Inversion greifbar bleibt, ist der Fokus bewusst eng. Wir behandeln nicht „jedes Framework im Konzern“, sondern den Kern, mit dem die meisten Teams hier arbeiten — und ein zweites Backend-Profil, das oft daneben steht, ohne ein Parallel-Vollbuch zu verdienen.

Schicht	Fokus	Rolle
Frontend	Angular (modern: Standalone, Signals wo sinnvoll)	Kern
Backend A	Spring Boot (Java-first; Kotlin nur wo Team-Realität)	Kern
Backend B	Quarkus	Zweites Backend: Entscheid + Patterns, kein Parallel-Vollbuch
Build	Maven und Gradle als DoD-Beispiele	pragmatisch, kein Glaubenskrieg
Contract	OpenAPI / klare API-Grenzen	Slice-Kleber
Harness	Coding-Agents (Surfaces: Copilot, Claude Code, Codex, Grok Build, …)	Jobs generisch; Mapping: Anhang C

Alles andere (andere Frontends, andere JVM-Stacks, andere Agents) ist erlaubt in eurem Alltag — und über Anhang C anschlussfähig. Der Schwerpunkt der konkreten Templates und Commands bleibt Angular/Java-Stack + agent-neutrale Repo-Jobs (AGENTS.md, Verify); Surface-Dateinamen sind Muster. Snapshot-Mentalität: Stand August 2026. Commands und CLI-Flags sind Muster; passt Versionen und Scripts an euer Repo an. Produkt-Syntax driftet: Konzept behalten, Syntax der aktuellen Produktdoku folgen.

1.6 Lesepfade

Du musst das Buch nicht linear lesen. Drei sinnvolle Wege hängen davon ab, ob du allein startest, ein Team onboardingst oder optional Theorie nachziehst.

Schnellstart (1–2 Sessions): 1 → 2 → 4 → 9 → 10 → Templates unter templates/ (AGENTS.md + optional Surface-Vorlagen) → Anhang C für euren Agent. Zuerst Mindestmodell (1.3) und gemeinsames Bild (Kap. 2), dann die eine Wahrheit im Repo, dann Verify und weiches Memory — genug, um den nächsten Agent-Lauf anders aufzusetzen, ohne jedes Framework-Kapitel.

Surfaces mappen: wie Schnellstart, plus Anhang C (Mapping + Transfer-Checkliste). Die Repo-Wahrheit (Kap. 4, 9) ist tool-unabhängig; nur die Convention-Dateinamen mappen (Copilot, Claude Code, Codex, Grok Build, …).

Team-Einführung: 1 (inkl. 1.3) → 2 → 3 → 4 → 9 → 8 → 5/6 → 10 → 12 → 13; Quarkus-Teams zusätzlich 7; Anhang C mitnehmen. Hier kommt die Reibungskarte (Kap. 3) vor dem Zielbild, Slices vor den Framework-Tiefen, Security und Anti-Patterns am Schluss — geeignet für Workshops und gemeinsame Conventions.

Optional mit Theorie: Wer System- oder Produkttiefe nachzieht, kann das parallel tun — nicht als Pflicht vor dem ersten Repo-Hebel. Wer nur dieses Buch liest: 1.3 + Kap. 2 genügen als Betriebssystem (optionaler Minimal-Leseplan in 1.3).

Welchen Pfad du wählst: Erfolg misst du nicht daran, wie viele Kapitel du abgehakt hast — sondern daran, was im Repo und im Review besser wird.

1.7 Wie du Erfolg misst

„Der Agent hat viel Code geschrieben“ ist die falsche Scorecard. Volumen ohne Reviewbarkeit ist teurer als langsames Tippen: Diffs, die niemand versteht, Verify, das niemand findet, und Patterns aus zwei Jahrzehnten im selben Package.

Besser (Detail und Review-Budget: Kap. 2.6):

• Diffs sind reviewbar (Slice-Größe, keine Drive-by-Refactors).
• Verify läuft non-interactive und ist in Instructions/AGENTS.md auffindbar.
• Nacharbeit sinkt messbar (weniger „falsches DI-Pattern“, weniger kaputte Angular-Module).
• Golden Paths im Repo sind wahr — nicht 2019 und 2026 gleichzeitig.
• Permissions sind enger als die menschliche Bequemlichkeit (kein YOLO als Default).

Wenn diese fünf Punkte greifen, merkst du es zuerst am Review — nicht am Token-Dashboard. Der Rest des Buchs ist Werkzeug, um genau dort hinzukommen.

Key Takeaways

• Companion für Angular + Spring Boot (+ Quarkus) agent-tauglich — Surfaces mappen (Anhang C); System- und Copilot-Produktiefe optional in den Schwesterwerken.
• Auffrischung 1.3 liefert ein eigenständiges Mindestmodell (Context-U-Kurve, LLM+Harness, DoD, Session-Hygiene) mit Mini-Beispielen; Kap. 2 vertieft den Alltag.
• Operative Prinzipien und Metriken: Kapitel 2; Repo-Hebel ab Kapitel 4; Schnellstart 1 → 2 → 4 → 9 → 10 + Anhang C.
• These 7 invers: fester Stack → mehr Alignment, engere Slices, härtere DoD — nicht bessere Prompts als Ersatz.
• Erfolg = reviewbare Diffs + agent-auffindbare Verify-Commands + echte Golden Paths (Stack-Muster) + harte Permissions.

Praktische nächste Schritte

1. Abschnitt 1.3 lesen (nicht nur skimmen), dann Kapitel 2 — Mindestmodell vor dem ersten großen Agent-Lauf.
2. Optional: Minimal-Leseplan in 1.3 nur, wo Begriffe im Team strittig sind.
3. Euer Ist-Repo gegen Kapitel 4 halten: eine Wahrheit für Build/Test/Lint?
4. Package-AGENTS.md (und Root-Convention eures Agents) anlegen oder straffen — Mission, Runtime, Verify, Immer/Nie. Inhaltsvorlagen: templates/agents-md-*.md; Surfaces mappen: Anhang C.