ki-engineeering/03-was-ist-ai-engineering.md

Was ist AI Engineering?

Im Stand-up heißt es: „Wir bauen jetzt AI ein.“ Gemeint ist oft: API-Key, Chat-Endpoint, ein Prompt in der Config — und die Hoffnung, dass „das Modell“ den Rest erledigt. Zwei Wochen später gibt es drei parallele System-Prompts, keinen Owner für Qualität, und die Frage, ob das eigentlich Machine Learning, Data Science oder „nur Prompting“ sei.

Die Verwirrung ist teuer. Wer die Disziplin nicht benennen kann, wählt die falschen Skills, die falschen Metriken und die falschen Eskalationswege. Dieses Kapitel klärt, was AI Engineering ist, wo es endet — und was der Job konkret liefert.

These 1 / Kern in einem Satz: AI Engineering ist Software Engineering für Systeme, die Foundation Models adaptieren und orchestrieren — spezifizieren, bauen, evaluieren, absichern und betreiben — ohne das Modell von Grund auf zu trainieren.

---

Bridge: Klassisches SE → AI Engineering

Du bleibst Software-Entwickler. Du baust weiter APIs, Pipelines, UI-Flows und Betriebsstrecken. Neu ist eine Komponente mit anderen Verträgen: das Foundation Model (oft ein LLM) plus die Schicht, die es steuert.

Klassisches SE-Artefakt	Pendant im AI Engineering
Anforderungsdokument / Spec	Feature-Spec inkl. Qualitätsmetriken, Failure Modes, Cost/Privacy-Envelope (Template)
Modulgrenze / Interface	Prompt- und Tool-Contracts, Structured Output, erlaubte Seitenwirkungen
Unit-/Integrationstests	Golden Sets, Eval-Gates, Online Quality Signals
Dependency-Management	Model-Versioning, Routing, Fallback-Provider
Deploy + Rollback	Canary für Prompts und Modelle, Feature-Flags, Kill-Switch
On-Call / Runbook	Cost Spikes, Quality Drops, Safety Hits, Model-Regression (Runbook)
Code-Review	Review von Prompt-Diffs, Tool-Permissions, Eval-Deltas, Adaptation-ADRs

Der Transfer funktioniert, wenn du Non-Determinismus und Kosten nicht als Ausrede für fehlende Spec nimmst, sondern als Teil der Runtime-Spec. Die Details zu Halluzination, Varianz und Latenz folgen in Kapitel 04; hier geht es um die Disziplin und den Job.

---

Definition: AI Engineering

AI Engineering (in diesem Buch) ist die Praxis,

1. Produktprobleme so zu schneiden, dass Foundation Models einen klaren, prüfbaren Beitrag leisten (oder bewusst nicht),
2. Modelle über Adaptation anzupassen — Prompting, Retrieval (RAG), Tools/Function Calling, Workflows/Produkt-Agents, gelegentlich Fine-Tuning —,
3. die Ausführung in Code und Harness zu orchestrieren (Validierung, Retry/Repair, Routing, Human-in-the-loop), und
4. das Ganze produktionsreif zu halten: Evaluation, Security, Privacy, Observability, Kosten, Latency, Model-Lifecycle.

Kurzformel:

AI Engineering ≈ SE + Foundation-Model-Komponente
                 + Adaptation + Orchestrierung
                 + Eval/Ops/Security/Cost

Was nicht dazugehört (als Kern der Rolle):

• Pretraining großer Modelle, Architektur-Forschung, Verlustfunktionen optimieren
• klassisches supervised ML von null (Feature-Engineering auf Tabellendaten) als Hauptjob — das bleibt ML Engineering / Data Science, auch wenn Schnittstellen existieren
• reines Prompt-Sammeln ohne Systemverantwortung

Foundation Models sind Dependencies mit besonderen Eigenschaften, keine magische Schicht „über“ dem Engineering. Dein Liefergegenstand bleibt ein System, das Nutzer und Business verantworten können — nicht ein Chat-Transcript.

---

Abgrenzung: benachbarte Disziplinen

Rollen überschneiden sich in echten Teams. Die Tabelle ist keine Hierarchie, sondern ein Zuständigkeits- und Skill-Kompass — damit ihr nicht den ML-Researcher für Prompt-Versionierung und den Backend-Dev für Gradient-Descent anruft.

Disziplin	Kernfrage	Typische Artefakte	Typische Metriken
AI Engineering	Wie bauen und betreiben wir ein zuverlässiges Feature mit Foundation Models?	Spec, Harness, Tool-Contracts, Eval-Plan, ADRs, Runbooks	Task Success, Guardrail-Hits, €/Request, p95-Latenz, Regression nach Model-Change
ML Engineering	Wie trainieren, deployen und monitoren wir gelernte Modelle (oft eigene Weights)?	Trainingspipelines, Feature Stores, Model Registry, Serving	Loss, Offline-Metriken, Data Drift, Serving-SLA
Data Science	Welche Muster und Prognosen stecken in den Daten — und was bedeutet das?	Analysen, Experimente, Notebooks, Reports	statistische Güte, Business-Insights, Experiment-Design
Prompt Engineering (als alleinige Praxis)	Welche Formulierung liefert bessere Outputs in einem gegebenen Setup?	Prompt-Varianten, Few-Shot-Beispiele	ad-hoc Qualität, A/B im Chat
Applied Research / FM Research	Welche Modellfähigkeiten und Trainingsmethoden verschieben den Stand der Technik?	Papers, Checkpoints, Benchmarks	Research-Benchmarks, Ablations

AI Engineering vs. ML Engineering

Beide bauen produktionstaugliche Systeme. Der Hebel unterscheidet sich:

• ML Engineering investiert stark in Datenpipelines, Training, Feature-Qualität und modelleigene Serving-Stacks. Das Modell ist oft euer Artefakt.
• AI Engineering investiert stark in Context, Contracts, Orchestrierung und Evaluation um ein (meist fremdes) Foundation Model. Das Modell ist Dependency; euer Artefakt ist die Anwendungsschicht.

Es gibt Überlapp: Fine-Tuning, Distillation, Embedding-Modelle, Evaluation-Infrastruktur. Dann arbeitet ihr an der Grenze — mit klarem Owner, wer Trainingsdaten und wer Product-SLO verantwortet. Für die meisten Produkt-Features im LLM-Zeitalter startet die wirtschaftliche Antwort auf der Adaptation Ladder (Kapitel 08), nicht beim eigenen Pretraining.

AI Engineering vs. Data Science

Data Science klärt, was in Daten steckt und welche Entscheidung logisch ist. AI Engineering liefert den betriebenen Pfad, der Nutzeranfragen in sichere, budgetierte Antworten und Aktionen übersetzt. Ein gutes RAG-System braucht oft beide: jemanden, der Korpus und Qualitätsdefinition versteht, und jemanden, der Chunking, Index, API, Eval-CI und On-Call trägt.

Prompt Engineering ist ein Teilskill, keine Disziplin-Ersatz

Formulierungen, Few-Shots und Output-Schemas zählen. Sie sind Interface-Design (Kapitel 11). Sie ersetzen nicht:

• die Entscheidung, ob ein LLM der richtige Baustein ist (Kapitel 05),
• Retrieval- und Tool-Architektur,
• messbare Qualität und Security-Grenzen,
• Betrieb und Kosten.

Wer „Prompt Engineer“ als Stellenbeschreibung für ein Production-Feature setzt, ohne Eval- und System-Ownership, organisiert Hope-Driven Development.

Produkt-Agent vs. Coding-Agent (Serie)

	Produkt-Agent (dieses Buch)	Coding-Agent (ki-praxis)
Nutzer	Endnutzer / interne Fachrolle im Produkt	Entwickler im Repo
Ziel	Geschäftsvorfall, Support, Workflow, Wissen	Code ändern, Tests, PRs
Threat Model	Prompt Injection, Datenabfluss, Tool Abuse im Produktkontext	Repo-Secrets, destruktive Git/Shell, Supply Chain
Erfolg	Task Success, Policy, Kosten, UX	grüner Slice, reviewbarer Diff, DoD

Mechaniken überlappen (LLM + Tools + Loop). Ownership und Erfolgsmetriken nicht. Coding-Agent-Security vertieft ki-agent; hier bleibt der Fokus auf App- und Produktsystemen.

---

Job-to-be-done: Was der AI Engineer liefert

Unabhängig vom Titel auf der Visitenkarte (Backend, Fullstack, Platform, „AI Engineer“) ist das Job-to-be-done:

Einen messbar nützlichen, begrenzten und betreibbaren Beitrag von Foundation Models im Produkt sicherstellen.

Konkret in Liefergegenständen:

1. Klare Spec — Problem, Success Metrics, Failure Modes, Budget, Privacy (ai-feature-spec.md)
2. Begründete Adaptation — Stufe auf der Ladder + ADR, wenn die Entscheidung teuer oder schwer reversibel ist (adr-adaptation.md)
3. Orchestrierter Laufzeitpfad — nicht „ein Prompt im Controller“, sondern Validate → Model/Tools → Repair/Fallback → Telemetrie
4. Eval vor und nach Change — Golden Set, Gates in CI wo sinnvoll, Online-Signale (eval-plan.md)
5. Sicherheits- und Vertrauensgrenzen — was rein darf, was raus darf, welche Tools welche Rechte haben
6. Betriebsfähigkeit — Traces, Token-Kosten, Alerts, Model-Change-Checkliste, Incident-Pfad
7. Ownership — wer freigibt, wer on-call ist, wer bei Model-Update regressiert

Rollen im Team (ohne Org-Theater)

Kleine Teams bündeln vieles in einer Person. Größere trennen sinnvoll:

Verantwortung	Oft bei …
Product framing, Policy, „gut genug“	Product + Engineering gemeinsam
Harness, APIs, Tools, Deploy	Software / Platform Engineering
Korpus, Labeling, fachliche Golden Sets	Domain + Engineering (+ ggf. DS)
Security Review (Injection, Exfil, Abuse)	Security + Feature-Owner
Model-Provider, Keys, Netz, Residenz	Platform / Security

AI Engineering ist kein Freifahrtschein, alle klassischen Rollen abzuschaffen. Es ist die Klammer, die verhindert, dass „AI“ zwischen den Stühlen liegt.

---

Mechanik (knapp): Was du vom Modell erwarten darfst

Nur so viel Mechanik, wie für die Disziplin-Definition nötig ist. Tiefe: Next Token.

Ein LLM erzeugt die wahrscheinlichste Fortsetzung gegebener Tokens im Trainings- und Alignment-Sinn — nicht „Wahrheit“, nicht „Absicht“, nicht „Verantwortung“. Daraus folgen drei Engineering-Konsequenzen:

1. Ausgabe ist Vorschlag, bis euer System sie bindet — Schema-Validierung, Business-Rules, Human-Approval bei riskanten Aktionen.
2. Guter Context schlägt mystische Modellwahl — relevante Fakten, klare Instruktionen, Tool-Ergebnisse; Müll rein, überzeugend klingender Müll raus (T4).
3. Fähigkeiten sind breit, Garantien sind schmal — für Garantien brauchst du Architektur ums Modell, nicht nur einen besseren Satz im System-Prompt.

AI Engineering beginnt, wo die Demo aufhört: bei der Frage welche Garantien das Gesamtsystem dem Nutzer gibt.

---

Patterns und Trade-offs

Pattern: Foundation Model als Komponente mit Vertrag

Behandle das Modell wie einen unzuverlässigen, teuren Microservice mit textueller oder strukturierter API:

• feste Input-/Output-Schemas wo möglich (Structured Output),
• Timeouts, Retries mit Budget, idempotente Tools,
• explizite Fehlerpfade (Fallback auf Regeln, Queue, Mensch).

Trade-off: mehr Boilerplate im Harness, dafür reviewbare und testbare Grenzen. Weniger Boilerplate fühlt sich agil an — bis zum ersten stillen Quality-Drop.

Pattern: Adaptation vor Eigenbau von Weights

Default-Pfad: Prompt → strukturierte Ausgabe → RAG → Tools → begrenzte Workflows/Agents → erst dann Fine-Tune/Distill, wenn Messungen es erzwingen. Details und Entscheidungslogik: Kapitel 08.

Trade-off: Adaptation ist schneller und oft günstiger in der Iteration; Fine-Tuning kann Latenz/Kosten/Format stabilisieren, erhöht aber Daten- und Ops-Last.

Pattern: Qualität als Produktfunktion

Eval ist kein Nachtrag vor dem Launch. Golden Sets wachsen mit Failure Modes; Online-Metriken und Stichproben halten Drift im Blick (T3).

Trade-off: frühe Investition in Datensätze und Judges; ohne sie optimierst du Demo-Glück.

Decision Frame: Wer ist im Lead?

Situation	Eher AI Engineering lead	Eher ML Eng / Research lead
Text/Chat/Dokument-Workflows mit APIs	ja	selten
Eigenes Modell, knappe Latenz, feste Klassen, viel gelabelte Daten	Kooperation	oft ja
Unklare Fachfrage, Explorationsphase	Spec + Ampel zuerst	Analyse/DS parallel
Regulatorik verlangt vollständige Datenresidenz und spezielles Training	gemeinsam mit Legal/Security	je nach Constraint

Wenn unklar: zuerst Wann LLM und Spec — nicht zuerst GPU-Cluster.

---

Anti-Patterns

Anti-Pattern	Symptom	Besser
Prompt als Architektur	Business-Logik nur im System-Prompt; keine Validierung	Logik und Policies im Code; Prompt für Sprach-/Format-Interface
Rollen-Wirrwarr	„Die AI-Leute“ ohne Owner für SLO und Incident	Feature-Owner + klare On-Call- und Eval-Verantwortung
ML-Theater	Training gefordert, bevor ein Golden Set existiert	Ladder hochklettern; FT nur mit Evidenz
Prompt-Engineering-Only-Hire	Stelle ohne System-, Security-, Eval-Scope	SE-Stelle mit AI-Skill-Profil; Prompt als Teilskill
Demo-Definition of Done	„Stakeholder waren beeindruckt“ = Ship	messbare Success Metrics + Production-Ready-Check
Modell = Produkt	Roadmap folgt Vendor-Blogposts	Roadmap folgt Jobs-to-be-done und Unit Economics
Coding-Agent-Verwirrung	Produkt-Loop mit Dev-Harness-Annahmen gebaut	Produkt-Threat-Model und Nutzer-SLO; ki-praxis für Dev-Tooling trennen

---

Production Notes

Cost. Jeder Request hat Token- und ggf. Tool-Kosten. Ohne Budget in der Spec und Accounting in der Observability ist „AI im Produkt“ eine offene Kreditkarte. Model Routing (günstig wo möglich, stark wo nötig) ist Feature-Design, nicht Feintuning hinterher.

Latency. p95 wird von Tokens, Queue, Tool-Roundtrips und Netz dominiert. Streaming verbessert wahrgenommene Wartezeit, nicht die Rechnung und nicht die Korrektheit. Timeouts und Teil-Ergebnisse gehören zur UX-Spec.

Observability. Traces über Prompt-Version, Model-ID, Retrieval-Hits, Tool-Calls, Token-Usage und Qualitäts-Samples. Ohne das sind Incidents „fühlt sich schlechter an“. Minimum: observability-minimum.md.

Security. Trust Boundaries um untrusted Input (Nutzer, abgerufene Dokumente, Tool-Output). Least Privilege für Tools. Secrets nicht in den Context. Security ist Architektur (T8), nicht ein Satz „antworte ethisch“.

Lifecycle. Model- und Prompt-Änderungen wie Breaking Changes behandeln: pin, eval, canary, rollback (T9). Ownership bleibt menschlich (T10).

---

Was AI Engineering bewusst nicht verspricht

• dass Foundation Models zuverlässig „wissen“, was wahr ist
• dass ein Vendor-Update eure Evals nicht brechen kann
• dass Agents menschliche Verantwortung ersetzen
• dass jedes Problem ein LLM-Problem ist

Die Disziplin verspricht etwas Nüchterneres: du kannst Systeme bauen, die mit diesen Grenzen ehrlich umgehen — und trotzdem Nutzen liefern.

---

Key Takeaways

• AI Engineering = Software Engineering für Produkte, die Foundation Models adaptieren und orchestrieren, inkl. Eval, Security, Cost und Betrieb.
• Es ist nicht ML-Research/Pretraining und nicht Prompt-Sammeln als Ersatz für Architektur. Prompting ist ein Teilskill.
• Der Job liefert Spec, Adaptation-Entscheidung, Harness, Eval, Boundaries und Ownership — messbar nützliche, begrenzte Modellbeiträge im Produkt.
• Produkt-Agent und Coding-Agent teilen Mechanik, nicht Threat Model und Erfolgsdefinition.
• Bridge zu klassischem SE: dieselben Disziplinen (Spec, Review, Deploy, On-Call), neue Runtime-Eigenschaften der Modell-Komponente.

Praktische nächste Schritte

1. Schreibe in drei Sätzen die Arbeitsdefinition von AI Engineering für euer Team (was im Scope, was explizit draußen).
2. Mappe euer nächstes AI-Vorhaben auf die Disziplinen-Tabelle: wer ist Owner für Spec, Eval, Security, On-Call? Lücken benennen.
3. Öffne templates/ai-feature-spec.md und fülle nur Abschnitt 1–3 (Problem, Metriken, Failure Modes) — auch unvollständig.
4. Entscheide bewusst: Ist das Vorhaben eher AI Engineering (Adaptation/Orchestrierung) oder braucht es ML Engineering (eigenes Training)? Eine Zeile Begründung reicht.
5. Lies als Nächstes Was sich ändert — Halluzination, Non-Determinismus, Kosten, Latency und der Rollenwandel von „Code schreiben“ zu „Systeme orchestrieren“.