grok-bot
db5d5f8034
Vermittelt Intention und Marketing-Texte; ein Support-Feature führt Spec bis Incident durch und vernetzt Lesepfade.
AI Engineering für Software-Entwickler
Untertitel: Zuverlässige, produktionsreife Anwendungen mit Foundation Models bauen, betreiben und weiterentwickeln
Pitch: Von der Demo zur Produktion — AI-Features spezifizieren, orchestrieren, messen und betreiben.
Markdown-Praxisbuch für Software-Entwickler, Tech-Leads und Platform-Engineers — nicht für ML-Researchers. Fokus: spezifizieren, bauen, evaluieren und betreiben von AI-Features mit Foundation Models (LLMs).
Worum es geht
AI Engineering heißt: Foundation Models adaptieren und orchestrieren, nicht Foundation Models trainieren. Das Buch schlägt die Brücke zwischen klassischem Software Engineering und den Unsicherheiten von LLMs (Halluzinationen, Non-Determinismus, Kosten, Latency) und bleibt bewusst vendor-agnostisch.
Kernversprechen: Nach der Lektüre kannst du ein AI-Feature spezifizieren, eine Adaptation-Entscheidung begründen, Eval-Gates setzen, Security mitigieren und den Betrieb steuern — unabhängig vom Lieblingsmodell. Klappentext und Intention: expose.md. Durchgängiges Beispiel: Anhang E — E2E-Walkthrough.
Serie
| Buch | Frage |
|---|---|
Next Token (../ki-hinterm-vorhang) |
Wie funktioniert moderne KI — und wo endet sie? |
Coding Agents in der Praxis (../ki-praxis) |
Wie setze ich Coding-Agents produktiv ein? |
| Dieses Buch | Wie baue und betreibe ich AI-Systeme als Produkt? |
Für wen
- Entwickler:innen mit Produktionssystem-Erfahrung
- Tech-Leads, die AI-Features in Produkte einbetten
- Platform/DevOps, die AI-Services betreiben
Für wen nicht
- Wer Foundation Models trainieren will
- Wer nur Prompt-Sammlungen sucht
- Wer ein Vendor-Handbuch für ein einzelnes Tool will
Leitthesen (Kurz)
- AI Engineering ≠ ML Engineering
- Non-Determinismus ist Runtime-Eigenschaft
- Qualität ist messbar oder existiert nicht
- Context ist der primäre Hebel
- Architektur vor Prompt
- Orchestrierung schlägt Magic
- Kosten und Latenz sind Features
- Security ist Teil der Architektur
- Model-Updates sind Breaking Changes
- Mensch bleibt Owner
Struktur
| Pfad | Rolle |
|---|---|
| 00-inhaltsverzeichnis.md | Navigation |
01–29 |
Kapitel (Front Matter, Teile I–VI) |
30–34 |
Anhänge |
| templates/ | Lebende Vorlagen |
| checklists/ | Lebende Checklisten |
| examples/ | Python-Referenzskizzen |
| research/ | Fakten, Stichtage |
| expose.md | Exposé |
| AGENTS.md | Autoren-Harness-Regeln |
Lesepfade
| Pfad | Einstieg |
|---|---|
| Schnellstart Production AI | 02 → 03 → 05 → 08 → 11 → 14 → 17 → 19 → 21/22 |
| Architektur & Trade-offs | 04–10 |
| Ops & Teams | 18–28 |
| E2E ein Feature | Anhang E §2 |
Details und Rollenpfade: 00-inhaltsverzeichnis.md, Anhang E.
Stil
- Erfahrener Kollege: präzise, anti-hype, ehrlich zu Grenzen
- Jedes Kernkapitel: Bridge SE↔AI, Trade-offs, Anti-Patterns, Production Notes
- Abschluss: Key Takeaways und Praktische nächste Schritte
- Tools nur als gleichrangige Beispiele
PDF bauen (optional)
just assemble # → build/book.md
just pdf # → dist/ai-engineering-se.pdf
just qa # Post-Build-Checks
just clean
Voraussetzungen: just, pandoc, TeX Live (LuaLaTeX, KOMA scrbook), Fonts laut Template.
Autoren-Harness
| Pfad | Rolle |
|---|---|
| AGENTS.md | Projektregeln, Terminologie |
.grok/rules/ |
Schreibkonventionen, Bau-Pipeline |
.grok/skills/ |
lektorat, kapitel-review, humanizer, faktencheck, pdf-bauen |
.grok/commands/ |
/lektorat, /review, /humanizer, /faktencheck, /pdf, /status |
| HANDOFF-buch.md | Session-Handoff (Meta) |
Status
Manuskript 01–34 geschrieben, lektoriert, Faktencheck-Kern erledigt (Stand August 2026). Meta: HANDOFF-buch.md.
Lizenz / Nutzung
Internes Fachbuch-Manuskript im Markdown-Format.