ki-engineeering/29-schluss-und-ausblick.md

Schluss und Ausblick

Am Anfang stand die Demo: ein Chat, der Tickets triagiert, E-Mails entwirft, aus Logzeilen „Root Causes“ formuliert. Am Ende dieses Buchs steht etwas Unspektakuläreres und Wichtigeres: Production Engineering für Foundation Models. Spec statt Bauchgefühl. Eval statt Applaus. Orchestrierung im Code statt Hoffnung im Prompt. Ownership mit Namen statt „die KI hat das so gemacht“.

Der Bogen war absichtlich der, den Teams in der Praxis oft zu spät gehen: Mental Model und Ampel → Spezifikation und Architektur → Bausteine (Prompt, RAG, Tools, Agents) → Qualität und Security → Betrieb, Kosten, Lifecycle, Incidents → Team und Reife. Wer die Kapitel linear gelesen hat, hat denselben Weg wie ein ernsthaftes Feature. Wer selektiv gelesen hat: die Thesen und Templates halten den Faden zusammen.

Kern in einem Satz: Tools, Modelle und Frameworks wechseln; Prinzipien, Spec, Eval, Context, Orchestrierung, Security-Architektur und Ownership bleiben — und der Mensch bleibt Owner messbarer Qualität.

(Prinzipien und Decision Frames: Stand August 2026. Produktnamen, Preise und Framework-Hypes ändern sich schneller — deshalb arbeiten wir mit Tiers und Checklisten, nicht mit Rankings.)

---

Bridge: Klassisches SE → AI Engineering

Was du schon konntest, gilt weiter. Was neu ist, ist die Laufzeitcharakteristik der Komponente „Foundation Model“ — und die Artefakte, die du deshalb ergänzt.

Was bleibt (SE-Disziplin)	Was bleibt neu / schärfer im AI Engineering
Spec, Interfaces, Failure Modes	Success Metrics, Cost-/Privacy-Envelope, Failure Modes inkl. Halluzination und Tool-Missbrauch (Kap. 06)
Tests und Regression	Golden Sets, Eval-Gates, Online Quality Signals (Kap. 17, 18)
Dependency-Management	Model-Pin, Canary, Rollback — Model-Updates als Breaking Changes (Kap. 24)
AuthZ, Threat Model, Secrets	Zusätzlich: Context-Fenster, Prompt Injection, Tool-Allowlist, Leakage in Logs (Kap. 19)
SLOs, Observability, On-Call	Token-/Cost-Accounting, Quality im SLO, AI-Incident-Typen (Kap. 22, 23, 25)
Code-Review und Ownership	Review von Prompt-Diffs, Tool-Permissions, Eval-Deltas; named Owner für Prompt/Eval/Model (Kap. 26)

Die Brücke war nie „wirf SE weg, lerne Prompting“. Es war: dieselbe Haltung, neue Hebel (Context, Adaptation Ladder, Guardrails, Model Routing).

---

Die zehn Thesen — was bleibt

Keine Zitate zum Auswendiglernen — eine operative Reprise. Pro These eine Praxis-Konsequenz. Vertiefung: Einführung.

#	These	Praxis-Konsequenz
T1	AI Engineering ≠ ML Engineering	Budget und Skills auf Adaptation, Harness und Ops legen — nicht auf Pretraining-Theater.
T2	Non-Determinismus ist Runtime-Eigenschaft	Schema, Validate/Repair/Fallback und Caps im Code designen, nicht nur „temperature senken“.
T3	Qualität ist messbar oder existiert nicht	Golden Set und Online-Signale vor dem Go-Live; „fühlt sich gut an“ ist kein Gate.
T4	Context ist der primäre Hebel	Prompt + Retrieval + Memory + Tool-Results als System designen; Context-Budget messen.
T5	Architektur vor Prompt	Control Flow, Boundaries und Adaptation-Stufe zuerst; Formulierung danach.
T6	Orchestrierung schlägt Magic	Thin orchestration: State, Timeouts, Allowlists und Fallbacks steuern das System.
T7	Kosten und Latenz sind Features	Unit Economics und p95 in die Spec; Routing, Cache und Caps sind Produktentscheidungen.
T8	Security ist Teil der Architektur	Injection, Tool Abuse und Leakage mitigieren an Boundaries — nicht nur im System-Prompt.
T9	Model-Updates sind Breaking Changes	Pin, Eval-Gate, Canary, Rollback; nie still auf latest fahren.
T10	Mensch bleibt Owner	Named Owner für Prompt, Eval, Model und On-Call; Freigabe und Eskalation bleiben menschlich.

Die Thesen greifen ineinander: Context ohne Eval wird teures Raten; Architektur ohne Orchestrierung wird Prompt-Spaghetti; Security und Kosten ohne Owner bleiben Appelle.

---

Was in zwei Jahren noch gilt

Stabil (mit hoher Wahrscheinlichkeit):

• Spec mit Success Metrics, Failure Modes, Cost- und Privacy-Envelope
• Eval als Dauerjob: Offline-Gates, Online-Signale, Human-Stichprobe für kritische Flows
• Context als primärer Qualitäts- und Kostenhebel
• Orchestrierung im Code: Caps, Validierung, Repair-Budgets, Fallbacks, Human-in-the-loop
• Security-Architektur: Trust Boundaries, Least Privilege für Tools, Guardrails, Redaction
• Cost and Latency as features: Tiers, Caching, Routing, Budget Caps, SLO inkl. Qualität
• Pinning und Lifecycle: versionierte Artefakte (Model, Prompt, Index, Policy), Canary, Rollback
• Ownership: klare Rollen, Review-Pfade, Incident-Runbooks

Veraltet (und soll veralten):

• Konkrete Model-Namen und „das beste Modell von …“-Rankings
• Preislisten und Token-Tarife ohne Stichtag
• Framework-Hype und Blogpost-Architekturen als Default
• Einzelne UI- oder Harness-Tutorials, die Produkt-Primärstellung vortäuschen

Deshalb: Decision Frames und Checklisten pflegen, nicht Screenshot-Galerien. Wenn du in zwei Jahren nur eines nachziehst: Eval- und Model-Change-Disziplin — der Rest der Landschaft kann sich drehen, die Abhängigkeit bleibt.

---

Serie-Brücken

Dieses Buch beantwortet: Wie baue und betreibe ich AI-Systeme als Produkt? Andere Bücher der Serie beantworten andere Fragen — verweisen, nicht doppeln.

Frage	Ort
Wie funktioniert Next-Token-Prediction — und wo endet sie?	Next Token (ki-hinterm-vorhang) — hier nur knappe Mechanik-Reprise
Wie setze ich Coding-Agents produktiv als Dev-Tool ein?	Coding Agents in der Praxis (ki-praxis)
Security und sichere Harnesses für Coding-Agents?	Secure Coding Agents (ki-agent)
Produkt-AI: Spec, Adaptation, Eval, Ops, Incidents?	dieses Buch

Produkt-Agent (LLM + Tools + Loop im Produkt) und Coding-Agent (Dev-Harness) teilen Mechaniken. Threat Model, Ownership und Erfolgsmetriken unterscheiden sich. Tool-Bücher zu einzelnen Harnesses bleiben orthogonal: hier nur gleichrangige Beispiele.

---

Häufige nächste Schritte nach dem Buch

Leser handeln typischerweise in einer dieser Reihenfolgen — wähle die, die zu deinem Engpass passt:

1. Ein Feature spezifizieren — nicht „AI einbauen“, sondern Job-to-be-done, Metriken, Failure Modes (templates/ai-feature-spec.md; Ampel: checklists/wann-llm.md).
2. Adaptation und Pattern festhalten — ADR auf der Ladder, dünnstes Pattern, das die Failure Modes löst (templates/adr-adaptation.md, Kap. 08).
3. Golden Set + Eval-Plan — 20–50 harte Fälle vor dem ersten Production-Traffic (templates/eval-plan.md, Kap. 17).
4. Production-Ready laufen — Ownership, Security, Observability, Caps, Runbook (templates/production-ready-checklist.md).
5. Einen Model-Change üben — Pin, Shadow/Canary, Rollback bevor der Provider den Default dreht (templates/model-change-checklist.md).
6. Reife und Team — Owner-Matrix, 90-Tage-Hebel, Onboarding (Kap. 26–28; checklists/team-onboarding-30-tage.md).

Anhänge und lebende Vorlagen: Anhang A, B, E; Quellen unter templates/ und checklists/.

---

Anti-Patterns des „danach“

Anti-Pattern	Was passiert	Besser
Tool-Hopping	Jede Woche neues Framework, kein stabiler Harness	Thin orchestration + Contracts; Framework nur wenn Caps/Telemetrie explizit werden
Eval nach dem Buch abstellen	Demo-Qualität kehrt zurück; stille Regression	Golden Set in CI; Online-Signale; Stichprobe im Kalender
latest und unpinned Prompts	Unerklärliche Incidents nach Provider-Change	Pin, Changelog-Owner, Model-Change-Checklist
Alles wird Agent	Kosten, Latency und Failure Modes explodieren	Pipeline default; Agent nur mit Caps und Agent-Readiness
Security nur im Prompt	Injection und Tool Abuse in Produktion	Boundaries, Allowlists, Guardrails, Review (checklists/security-review-ai.md)
Kein Owner	„Die KI“ als Verantwortlicher	Named Owner Prompt / Eval / Model / On-Call
Scope-Creep AGI-Roadmap	Spekulation statt Feature-Slice	Ein spezifiziertes Feature, messbar, rollbackbar

Katalog und Gegenmittel: Anhang B.

---

Production Notes — Betrieb bleibt Alltag

Das Buch endet. Der Betrieb nicht.

• Cost / Latency: Budgets und p95 bleiben Spec-Felder; Alerts vor der Finance-Mail.
• Observability: Trace-IDs, model_id, prompt_version, Outcome — redacted (checklists/observability-minimum.md).
• Security / Privacy: Threat Model und Retention mit dem Feature mitwachsen.
• Lifecycle: Jeder Model- und Prompt-Change ist ein Release mit Gate.
• Incidents: Runbook griffbereit (templates/incident-runbook-ai.md); Stabilisieren vor Spekulieren.

Produktionsreife ist kein Meilenstein-Badge. Sie ist die Summe aus Spec, Eval, Caps, Observability und Ownership — an jedem Release-Tag.

---

Key Takeaways

• Der Weg Demo → Production Engineering ist der rote Faden: spezifizieren, orchestrieren, messen, absichern, betreiben.
• Die zehn Thesen bleiben das Betriebssystem — Tools und Modelle sind austauschbar.
• Was in zwei Jahren gilt: Spec, Eval, Context, Orchestrierung, Security-Architektur, Cost as feature, Pinning, Ownership. Was veraltet: Namen, Preise, Hype.
• Serie: Mechanik → Next Token; Coding-Agents → ki-praxis; Dev-Agent-Security → ki-agent; hier Produkt-AI.
• Danach: ein Feature spezifizieren, Eval leben, Owner benennen, Model-Change üben — nicht Frameworks sammeln.
• Mensch bleibt Owner messbarer Qualität; der Loop ersetzt keinen Product Owner und keinen On-Call.

Praktische nächste Schritte

1. Wähle ein reales Feature und fülle templates/ai-feature-spec.md (Success Metrics, Failure Modes, Cost-/Privacy-Envelope).
2. Lege ein Golden Set an (hart, repräsentativ, versioniert) und skizziere den Eval-Plan mit CI-Gate.
3. Schreibe eine Ownership-Matrix: wer owns Prompt, Eval, Model-Pin, Index/Tools, On-Call — mit Vertretung.
4. Laufe templates/production-ready-checklist.md und markiere Blocker rot (Security, Observability, Fallback, Runbook).
5. Übe einen Model-Change im Shadow oder Staging: templates/model-change-checklist.md — inkl. Rollback-Pfad.
6. Optional: Reife-Check und 90-Tage-Hebel in Kapitel 28; Onboarding-Pfad checklists/team-onboarding-30-tage.md.

Wenn du das tust, hast du das Buch nicht „gelesen“. Du hast AI Engineering in Betrieb genommen.