ki-engineeering/04-was-sich-aendert.md

Was sich ändert

Du hast denselben Endpoint zweimal mit demselben Payload aufgerufen. Einmal war die Antwort brauchbar, einmal höflich falsch. Der Unit-Test von gestern ist grün — und sagt nichts über heute. Die Rechnung am Monatsende erklärt, warum „einfach das starke Modell“ keine Architektur war.

Was sich ändert, ist nicht, dass Software plötzlich „intelligent“ wird. Es ändert sich die Laufzeitcharakteristik einer zentralen Komponente — und damit Spec, Tests, Review, Kostenrechnung und die Rolle des Entwicklers.

These 2 / Kern in einem Satz: Non-Determinismus, Halluzination, tokenbasierte Kosten und Latency sind Runtime-Eigenschaften des Foundation-Model-Pfads — sie gehören ins Design (Validierung, Eval, Budget, Orchestrierung), nicht in die Kategorie „komisches Modellverhalten, ticket schließen“.

---

Bridge: Klassisches SE → AI Engineering

Annahme im klassischen SE	Was sich mit Foundation Models ändert
Gleiche Inputs → gleiche Outputs (im Rahmen von Spec)	Gleiche Inputs → Verteilung von Outputs; Seed/Temperature ändern die Breite
Korrektheit lässt sich im Test nachweisen (im definierten Scope)	Qualität wird geschätzt (Eval, Stichproben, Online-Signale) und regressiert still
Bugs sind reproduzierbar und diffbar	Fehler sind oft überzeugend und inkonsistent; Root Cause sitzt in Context, Retrieval, Tool-Pfad
Kosten ≈ Compute/Infra der eigenen Services	Zusätzlich variable Kosten pro Request (Tokens, Tools, Retries)
Latency ≈ Code + DB + Netz	Zusätzlich Generierungs- und Roundtrip-Zeit; Streaming täuscht über Budget hinweg
Entwickler schreibt die Logik	Entwickler orchestriert Modell, Tools, Regeln und Menschen; Logik sitzt in mehreren Schichten
Dependency-Update mit Changelog und SemVer-Erwartung	Model-/Prompt-Change kann die Antwortverteilung ohne deinen Diff verschieben (T9)

Die Disziplin bleibt SE (Kapitel 03). Die Hebel verschieben sich: Context (T4), Contracts, Eval (T3), Routing und Guardrails statt „noch ein if in der Business-Logik“.

---

Fünf Runtime-Eigenschaften, die alles mitziehen

1. Halluzination: überzeugend ≠ wahr

Halluzination meint hier: das System erzeugt Inhalte, die im gegebenen Auftrag falsch, unbelegt oder erfunden sind — oft in flüssigem, selbstsicherem Ton. Mechanisch ist das keine „Lüge mit Absicht“, sondern Fortsetzung unter Unsicherheit und unzureichendem Grounding. Tiefe: Next Token.

Engineering-Folgen:

Wenn Halluzination …	dann brauchst du …
Fakten erfindet	Grounding (RAG, Tools, kanonische APIs), Zitate/Belege, Ablehnung bei fehlender Evidenz
Actions „plant“, die so nicht existieren	Structured Output + Schema-Validierung; erlaubte Tool-Liste hart im Code
in Support/Recht/Medizin riskant wird	Human-in-the-loop, harte Policy-Gates, ggf. kein freies Generieren
im UI als Wahrheit gelesen wird	UX-Framing: Vorschlag, Quelle, Unsicherheit — nicht Orakel

Anti-Illusion: „Sei ehrlich und erfinde nichts“ im System-Prompt ist ein Guardrail-Appell, kein Ersatz für Architektur. Brauchbare Systeme koppeln Generation an prüfbare Fakten oder an kontrollierte Aktionen — oder sie lassen den Schritt.

2. Non-Determinismus: Varianz ist normal

Auch bei scheinbar gleichen Inputs streuen Ausgaben. Sampling, Batching, Provider-seitige Änderungen und marginal anderer Context (Uhrzeit im Prompt, Retrieval-Reihenfolge, vorherige Tool-Results) verbreitern die Verteilung. Manche APIs erlauben temperatur- und seed-nahe Steuerung — Produktgarantien baust du trotzdem nicht auf „diesmal war temperature 0“.

Engineering-Folgen (T2):

• Contracts statt Prosa: JSON-Schema / structured outputs; Reject + Repair-Loop bei Verletzung
• Idempotenz an der Grenze: Tools und Side Effects so gestalten, dass doppelte Modellaufrufe nicht doppelte Schäden erzeugen
• Eval über Mengen: nicht ein goldenes Transcript, sondern ein Set mit erwarteten Eigenschaften
• Flaky ist Signal: hohe Varianz auf kritischen Cases → engere Orchestrierung oder anderes Pattern (Regeln, Template, Mensch)

Determinismus im Gesamtsystem erreichst du, indem du den unsicheren Kern einklammert: Modell schlägt vor, Code entscheidet und persistiert.

3. Kosten: variable Unit Economics

Jeder sinnvoll genutzte Request verbraucht Tokens (Input-Context + Output) und oft Tool-/Retrieval-Kosten. Retries, Agent-Loops und „leg einfach das ganze PDF in den Prompt“ multiplizieren.

Was sich gegenüber klassischem Request-Cost ändert:

• Kosten skaliert mit Context-Größe und Gesprächslänge, nicht nur mit RPS
• „Ein bisschen mehr Context“ ist eine Produktentscheidung mit Preisschild (T4 × T7)
• Das teuerste Model-Tier auf 100 % Traffic ist selten die optimale Architektur (Kapitel 09, 23)

Spec-Felder, die vorher optional wirkten, werden Pflicht: Budget pro Request / pro Nutzer / pro Monat, und was passiert bei Überschreitung (Queue, Downgrade, Ablehnung, Mensch).

4. Latency: Tokens und Roundtrips

Wahrgenommene und gemessene Latenz hängen ab von:

• Modell-Tier und Last beim Provider oder im eigenen Serving
• Input- und Output-Länge
• Anzahl der Tool-/Retrieval-Runden (besonders bei Produkt-Agents)
• Netz, Queues, Safety-Filtern

Streaming verbessert oft die UX („es tut sich was“), ändert aber weder die volle Time-to-complete noch die Tokenrechnung. Für SLOs brauchst du klare Definitionen: Time-to-first-token vs. Time-to-final; interaktiv vs. Batch.

Wenn p95 das UX-Budget sprengt, sind die Hebel selten „hoffe auf ein schnelleres Modell allein“: kürzerer Context, kleineres/passendes Tier, weniger Agent-Schleifen, paralleles Vorholen, Cache, asynchrone Jobs.

5. Context als primärer Hebel (Reprise T4)

Qualität hängt häufig stärker — und vor allem steuerbarer — am sichtbaren Context ab als an der nächsten Modellgeneration: Systeminstruktionen, User-Input, abgerufene Passagen, Memory, Tool-Results, Gesprächshistorie. Schlechter Context produziert überzeugend schlechte Arbeit — und verbrennt dabei Tokens.

Das verschiebt den Job: weniger „geniales Prompt-Worting“, mehr Context Engineering als Produktarchitektur (Kapitel 10–12).

---

Was sich nicht ändert (damit du nicht alles über Bord wirfst)

• Ownership und Verantwortung bleiben menschlich (T10).
• Security- und Privacy-Pflichten bleiben; sie bekommen neue Angriffsflächen (Injection, Tool Abuse, Log-Leakage) — sie verschwinden nicht.
• Review, CI, Deploy, Rollback bleiben sinnvoll; der Diff enthält Prompt-, Eval- und Policy-Artefakte.
• Klare Interfaces und Failure Modes bleiben der kürzeste Weg zu wartbaren Systemen.
• Nicht jedes Problem ist ein LLM-Problem — die Ampel kommt in Kapitel 05.

---

Rollenwandel: von „Code schreiben“ zu „Systeme orchestrieren“

Früher lag die entscheidende Logik oft im von dir geschriebenen Codepfad. Mit Foundation Models verteilt sie sich:

Nutzer / Event
    → Guardrails (Input)
    → Context-Aufbau (Retrieval, Memory, State)
    → Modell (+ Tools in einer Schleife)
    → Validierung / Repair / Fallback
    → Guardrails (Output) + Side Effects
    → Telemetrie & Eval-Samples

Dein Hebel sitzt in Schnitt, Verträgen und Schleifen (T5, T6):

Früher im Fokus	Jetzt zusätzlich im Fokus
Algorithmus im Service	Adaptation-Stufe und Control Flow
Exakte Branch-Logik	Schema, Policy, erlaubte Tools
Test der reinen Funktion	Golden Sets + Online Quality
Infra-Kosten grob planbar	Token- und Loop-Budget
„Fertig“ = Feature merged	„Fertig“ = Spec + Eval-Gate + Betriebsstrecke

Das ist kein Abwerten von Handwerk. Es ist mehr Systemdenken: du schreibst weiter Code — der Code orchestriert Unsicherheit, statt sie zu leugnen.

Produkt-Agent verstärkt den Wandel

Sobald das Modell Tools in einer Schleife nutzt, multiplizieren sich Varianz, Kosten und Latency mit der Schrittzahl. Ohne harte Stopps, Berechtigungen und State-Machine rutscht „Agent“ in unkontrollierte Loops. Vertiefung: Kapitel 14; Readiness: checklists/agent-readiness.md. Coding-Agents als Dev-Tool bleiben orthogonal (ki-praxis).

---

Patterns und Trade-offs

Pattern: Einklammern (Validate → Generate → Validate)

Untrusted oder unsichere Schritte nie direkt Side Effects ausführen lassen. Schema prüfen, Business-Regeln anwenden, bei Repair-Bedarf mit begrenztem Retry; sonst Fallback.

Trade-off: mehr Pfade und Telemetrie; dafür kontrollierbare Failure Modes statt stiller Falschheit.

Pattern: Grounding vor Eloquenz

Lieber knappe Antwort mit Beleg/Tool-Fakt als eleganter Fließtext ohne Quelle — wo Fakten zählen.

Trade-off: RAG/Tools erhöhen Architektur- und Latency-Kosten; freie Generation ist billiger in der Demo und teurer im Incident.

Pattern: Tiered Models und Caches

Einfache/häufige Fälle → günstiges/schnelles Tier oder Cache/Template; schwere Fälle → stärkeres Modell oder Mensch.

Trade-off: Routing-Komplexität vs. lineare Kostenexplosion.

Decision Frame: Welche Eigenschaft dominiert dein Feature?

Dominante Sorge	Design-Priorität	Typische Mittel
Falschinformation	Grounding, Ablehnung, HITL	RAG, Tools, Citations, Policy
Varianz / Flakiness	Contracts, Repair, Eval-Menge	Structured Output, Golden Set
Kosten	Context-Diät, Routing, Loop-Caps	kleinere Contexts, cheap tier, Cache
Latency	Roundtrips & Output-Länge	weniger Agent-Schritte, Streaming+Budgets, async
Missbrauch / Injection	Trust Boundaries	Input-Isolation, least-privilege Tools

Wenn zwei Sorgen gleichzeitig „P0“ sind, ist das Feature oft zu breit geschnitten — spezifizieren und spalten (Kapitel 06).

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Determinismus-Leugnung	„Temperature 0, also stabil“ als Produktionsgarantie	Verteilung annehmen; Contracts + Eval
Transcript-Testing	Ein Happy-Path-Chat als „Testsuite“	Eigenschaften und Sets; Regression bei Prompt/Model-Change
Eloquenz-Optimierung	Team poliert Ton, während Fakten falsch bleiben	Grounding und Metriken vor Stil
Context-Maximalismus	Alles in den Prompt „nur zur Sicherheit“	Relevanz, Budget, stufenweises Nachladen
Agent aus Langeweile	Loop mit Tools, weil es modern wirkt	Pipeline/Regeln zuerst; Agent nur mit Stopps und Eval
Kosten hinterher	Erste Rechnung als Architektur-Review	Budget in Spec und Alerting von Tag 1
Streaming = fertig	UX fühlt sich schnell an, p95 und Qualität unklar	SLOs und Qualitätsproben explizit
Schuld beim Modell	Jeder Fehler → „neues Modell testen“	Context, Spec, Orchestrierung zuerst debuggen

---

Production Notes

Cost. Token Accounting pro Feature, pro Tenant wo nötig; Caps und Downgrade-Pfade. Retries und Agent-Schritte in derselben Kostenrechnung. Alerts auf €/Request und Monatsbudget, nicht nur auf 5xx.

Latency. SLOs trennen First-Token und Final; getrennte Budgets für interaktiv vs. Batch. Tool-Parallelität und Timeouts; keine unbegrenzten Loops.

Observability. Pro Trace: model id/version, prompt-version, token in/out, retrieval ids, tool names, repair count, guardrail hits, finale Disposition (success / fallback / human / reject). Quality Sampling anbinden (Kapitel 22).

Security. Untrusted Text (User, Web, Dokumente, andere Tickets) nie als „System-Wahrheit“ in denselben Topf ohne Isolation. Tool-Rechte minimal. Outputs, die Code oder SQL triggern, wie untrusted Input behandeln (Kapitel 19).

Lifecycle. Prompt- und Model-Änderungen erzeugen neue Verteilungen: Eval-Gate, Canary, Rollback. „Der Provider hat updated“ ist ein Deploy-Event, kein Schicksal (T9).

---

Kurze Mechanik-Reprise (nicht mehr)

Warum Modelle so wirken, wie sie wirken — Next-Token-Vorhersage, Alignment, Grenzen des „Wissens“ — gehört ins Schwesterbuch Next Token. Hier reicht die Engineering-Nutzlast:

Das Modell liefert plausible Fortsetzungen unter Context und Training. Garantien liefert euer System um das Modell herum.

---

Key Takeaways

• Halluzination, Non-Determinismus, tokenbasierte Kosten und Latency sind erwartbare Runtime-Eigenschaften — Design-Input, kein Betriebsunfall.
• Überzeugend ist kein Qualitätskriterium; Grounding, Schema und Eval sind es (T2, T3, T4).
• Variable Unit Economics und Roundtrips machen Budget und SLO zu Feature-Anforderungen (T7).
• Der Rollenwandel geht von reiner Branch-Logik zu Orchestrierung: Context, Tools, Validierung, Fallback, Telemetrie (T5, T6).
• Was bleibt: Ownership, Security-Pflicht, Review und die Freiheit zu sagen: hier kein LLM (Kapitel 05).

Praktische nächste Schritte

1. Nimm ein laufendes oder geplantes AI-Feature und markiere die dominante Runtime-Sorge (Falschinfo / Varianz / Kosten / Latency / Missbrauch).
2. Ergänze in der Spec (templates/ai-feature-spec.md) drei Zeilen: Failure Mode Halluzination, Kosten-Budget, Latency-Budget (auch grob).
3. Liste, welche Ausgaben heute ungeprüft Side Effects oder Nutzervertrauen auslösen — und wo Validate/Repair fehlt.
4. Schau in die letzte Wochen-Rechnung oder Trace-Stichprobe: was treibt Tokens (Context, Output, Loops)? Eine Hypothese genügt.
5. Lies als Nächstes Wann LLMs — und wann nicht — Ampel, bevor du die Runtime-Komplexität in Stein meißelst.