ki-buch/frontmatter/einleitung.md

Einleitung

Vom Chatbot zum steuerbaren Coding Agenten

Lernziele

Nach dieser Einleitung kannst du:

• Chatbot, Tool-Assistent und Software-Agent operational unterscheiden,
• den Engpass Kontext × Tools × Prozess benennen (nicht nur „größeres Modell“),
• den roten Faden des Buches skizzieren: Context Engineering · Harness · portable Capabilities (MCP),
• deinen Lesepfad wählen und wissen, was du nicht lesen musst.

---

1. Drei Stufen – die dritte braucht Architektur

Stufe	Was passiert	Wer integriert?
Chatbot	Text rein, Vorschlag raus	du (Clipboard, Ausführung, Verify)
Tool-Assistent	deklarierte Functions (Datei, Suche, Lint)	Host, oft proprietär
Software-Agent	Ziel über viele Schritte: planen, handeln, beobachten, stoppen	Harness + Policies + Tools/Kontext-Schicht

Konzept-Plate: Evolutionsstufen Chatbot → Tool-Assistent → Agent

{ width=100% }

Zwischen „klugem Chat“ und „vertrauenswürdiger Entwicklungsarbeit“ liegt selten nur ein stärkeres Frontier-Modell. Es liegt Zugang zu Weltzustand, begrenzte Privilegien und Verifikation.

Analogie: Stufe 1 – Auskunft ohne Akten. Stufe 2 – drei genehmigte Nebenstellen. Stufe 3 – Sachbearbeitung mit Akte, Frist, Eskalation und auditierbaren Schnittstellen.

---

2. Der Engpass ist systemisch

In der Praxis scheitern Coding Agents häufiger an falschem, veraltetem, fehlendem oder überladenem Kontext und an unklaren Tools/Prozessen als an „zu wenig IQ“.

Symptom	Systemursache
Halluzinierte interne API	fehlender/aktueller Repo-Kontext
Überzeugender Falsch-Fix	Branch/CI/Logs nicht im Working Set
Endlosschleife	Tool-Results schlecht zurückgeführt, kein Stopp-Kriterium
Teure Latenz	Context Stuffing statt Selektion
Sicherheitsvorfall	zu mächtige Tools, Injection über Outputs

Das Context Window ist Arbeitsspeicher, keine Festplatte. Diese Metapher gilt im Buch als kanonisch – später verweisen wir, statt sie neu zu predigen (Kap. 2.3).

Leitformel:

Agentenqualität = Modellqualität × Kontextqualität × Toolqualität × Prozessqualität.

---

3. Drei Hebel – der rote Faden

Context Engineering

Nicht „schöner prompten“, sondern Betriebslogik:

Selektion · Beschaffung · Repräsentation · Aktualität · Token-Budget · Schutz · Feedback/Memory.

Konzept-Plate: Context Engineering Flow mit MCP

{ width=100% }

Agent Harness

Alles ums Modell: Loop, State, Permissions, Sandbox, Verify, Traces, UX.
Agent = Model + Harness – wer nur das Modell tauscht, optimiert oft die falsche Schicht.

Portable Capabilities (häufig MCP)

Wenn N Hosts und M Systeme ohne Standard integriert werden, wächst der Aufwand mit N×M. MCP zielt auf N+M: Server exponieren Capabilities einmal; Hosts sprechen eine Protokollsprache (Tools, Resources, Prompts).

Konzept-Plate: N×M-Integrationen vs. MCP

{ width=100% }

Wichtig von Anfang an: MCP ist die richtige Wahl für portablen Capability-Zugriff – nicht für Editor-Pixel, nicht automatisch für Agent-zu-Agent-Orchestrierung, nicht als Ersatz für Threat Models. Die Entscheidungstabelle steht in Kapitel 4.7.5; die Architektur-Landkarte in Kapitel 4.0.

Der technische Deep-Dive zu Host–Client–Server folgt in Kapitel 4.7 – nicht doppelt in den LLM-Grundlagen.

---

4. Was die vier Teile liefern

Teil	Inhalt	Für dich relevant, wenn …
I	LLM-Realität, Grenzen, Context Engineering	du Erwartungen und CE-Policies schärfen willst
II	Harness, MCP, Skills, Framework-Wahl	du Architektur und Integration entscheidest
III	SDLC, Multi-Agent, Hosts, Hands-on, Security	du liefern und absichern musst
IV	Strategie, Rollen, evidenter Branchenblick	du 12-Monats-Wetten und Org-Design steuerst

Schwerpunkte dieses Buches: Kapitel 4–5 (Kernarchitektur), 10 (bauen), 11 (Risiko/Governance).
Optional: Kapitel 1–2, wenn die LLM-Grundlagen sitzen.

---

5. Voraussetzungen

• eine moderne Sprache (Beispiele: Python; Companion ist Python-first),
• Git und grobes CI-Verständnis,
• Bereitschaft zu CLI, JSON, APIs,
• ethischer Anspruch: keine blinden Agenten auf Produktionsgeheimnissen.

Arbeitsmodus: skizziere eure Host–Server-Landschaft, starte die Demo in code/, führe ein kurzes Context Journal (Top-5-Agent-Tasks → wirklich benötigte Quellen).

---

6. Leitmotive (kompakt – im Buch nicht jedes Kapitel neu aufwärmen)

1. Kontext ist Infrastruktur, nicht Prompt-Folklore.
2. Standards schlagen Eigenbau, sobald mehr als ein Host oder Team andockt – wenn Portabilität der Nutzen ist.
3. Weniger Kontext kann mehr sein.
4. Tools sind Privilegien.
5. Menschen bleiben für Ziele, Merge und Produktion verantwortlich.
6. „Wann nicht“ ist eine Architekturentscheidung, kein Anhang.

---

7. Code und Volatilität

Dieses Buch ist kein SDK-Handbuch. Zuerst das stabile Muster, dann zeitgebundene Illustration (Stand Juli 2026), lauffähig im Companion code/ (Tags book-2026-07 / latest, siehe code/COMPATIBILITY.md).

Wer baut: starte mit Kap. 10.0 (5-Minuten-Pfad) vor den Server-Details in 10.7 — First Success vor Framework-Tiefe.

Wenn sich FastMCP oder Host-JSON ändern, bleibt die Lehrabsicht: Capabilities portabel machen, Kontext disziplinieren, Tools als Privilegien behandeln.

Zur Spec-Revision 2026-07-28 (stateless): siehe Kapitel 4.8. Buch und Companion bleiben auf 2025-11-25 gepinnt.

Schicht	Bedeutung
Stabil	Protokoll & Architektur
Mittelstabil	methodische Muster
Volatil	konkrete SDK-/Host-Beispiele (siehe auch Anhang D)

---

Key Takeaways

• Die dritte Evolutionsstufe braucht Harness + Kontextpolitik + Capability-Schicht, nicht nur Chat.
• Qualität multipliziert sich über Modell, Kontext, Tools und Prozess.
• MCP löst Integrationsportabilität – nicht Orchestrierung, Security oder kluge Defaults.
• Dieses Buch optimiert auf Entscheidungen und Produktionsreife, nicht auf Vollständigkeit jeder Framework-API.

---

Was als Nächstes kommt

Kapitel 1–2 (optional): knappe Einordnung, wie aus Completion-APIs Tool- und Agent-Systeme wurden – und was am Context Window technisch hart ist.
Kapitel 3 (empfohlen): Fähigkeiten, Grenzen und Context Engineering als Disziplin.
Kapitel 4 (Kern): Agent, Harness, MCP – inklusive wann nicht.