grok-bot
63589e684a
AI Act/OWASP und Residenz/Log-TTL in Kap. 19–20, Framing- und Taxonomie-Fixes quer durch Manuskript und Templates, Kap.-10-Anker im Assembler; Handoff fortgeschrieben.
5.2 KiB
Vorwort
Dieses Buch ist aus einem wiederkehrenden Gespräch entstanden — im Team, im Review, im Incident-Call:
„Die Demo war stark. Warum fühlt sich Produktion an wie ein anderes Produkt?“
Software-Entwickler können Systeme spezifizieren, testen, absichern und betreiben. Sobald Foundation Models ins Produkt wandern, greifen viele der gewohnten Sicherheiten nicht mehr so, wie man es gewohnt ist: Ausgaben sind probabilistisch, Qualität driftet ohne Deploy, Kosten skalieren mit Tokens und Loops, und ein Provider-Update kann Verhalten ändern, ohne dass der Compiler meckert. Das ist kein peinliches Versagen der Entwickler und kein Beweis, dass „KI nicht production-ready“ sei. Es ist ein Engineering-Problem mit eigenen Artefakten, Hebeln und Betriebsregeln.
Genau dafür ist dieses Buch geschrieben.
Was du hier findest — und was nicht
Du findest Decision Frameworks, Patterns und kopierbare Vorlagen, um AI-Features so zu bauen und zu betreiben, wie du bisher zuverlässige Software gebaut hast: mit Spec, Architektur, Eval, Observability, Security, Kostenkontrolle und Ownership.
Du findest keine Versprechen, dass das richtige Prompt-Rezept Halluzinationen abschafft; kein Model-Ranking als Kernbotschaft; kein Pretraining-Lehrbuch; kein Handbuch für Coding-Agents als Dev-Tool. Wenn du Modelle trainieren willst, brauchst du ML Engineering. Wenn du selbst mit Agents im Editor schneller werden willst, liegt das in einem Schwesterbuch. Hier geht es um AI im Produkt deiner Nutzer — und um die Disziplin, die daraus folgt.
Der Ton ist absichtlich der eines erfahrenen Kollegen: präzise, geduldig, ohne Hype. Risiken und Kosten werden benannt, weil sie Features sind — nicht weil Panik verkauft.
Serie: vier Fragen, vier Bücher
Die Bücher der Serie beantworten verschiedene Fragen. Doppeltexte vermeiden wir bewusst.
| Frage | Buch |
|---|---|
| Wie funktioniert moderne KI — und wo endet sie? | Next Token |
| Wie setze ich Coding-Agents produktiv als Dev-Tool ein? | Coding Agents in der Praxis |
| Security und sichere Harnesses für Coding-Agents? | Secure Coding Agents |
| Wie baue und betreibe ich AI-Systeme als Produkt? | dieses Buch |
Kurz: Next Token liefert Mechanik und Grenzen. Coding Agents in der Praxis und Secure Coding Agents decken die Entwickler-Seite ab (Produktivität und Dev-Harness-Security). Hier geht es um die Produkt-Seite: Spec, Adaptation Ladder, RAG und Tools im System, Eval-Gates, Guardrails, Serving, Lifecycle, Incidents, Team und Reife.
Tool-Handbücher zu einzelnen Produkten (eine IDE, eine Cloud-Konsole, ein Agent-Harness) bleiben orthogonal. Wo Beispiele helfen, stehen mehrere Anbieter oder neutrale Schichten-Sprache — Prinzipien vor Produkten.
Stichtag und Ehrlichkeit zu Verfall
Buch-Stichtag für Faktenpflege und Produktclaims: August 2026.
Was in zwei Jahren noch gilt, sind vor allem Prinzipien: spezifizieren bevor man shipped, Qualität messen, Context bewusst bauen, Orchestrierung im Code, Security als Architektur, Kosten und Latenz als Features, Model- und Prompt-Versionen pinnen, Menschen als Owner. Was veraltet, sind Model-Namen, Preislisten, Kontextfenster-Marketing und Framework-Hypes.
Deshalb arbeiten wir mit Model-Tiers, Checklisten und Decision Frames — nicht mit Rankings, die nächste Woche falsch sind. Wo ein Produkt, ein Limit oder ein Preis genannt wird, steht der Stand dabei oder die Aussage bleibt absichtlich stichtagsarm. Unsicheres markieren wir als unsicher; erfundene Benchmarks gibt es hier nicht.
Wie du dieses Buch nutzen kannst
Die Einführung (Kapitel 02) legt Intentionen, Zielgruppe, die zehn Thesen und Lesepfade fest. Ab Teil I folgt der Praxisbogen: Mental Model → Architektur → Bausteine → Qualität und Security → Betrieb → Team und Reife. Die Anhänge bündeln Templates, Anti-Patterns, Glossar, Entscheidungsmatrizen und Onboarding-Material; die lebenden Vorlagen liegen unter templates/ und checklists/ und können mit dem Repo mitwachsen.
Du musst nicht linear lesen. Wenn du mitten im Launch stehst, sind Spec, Eval, Security und Production-Ready oft der kürzere Weg als Kapitel 1 bis 29 in Reihenfolge. Wenn du Architektur entscheidest, lohnen Ladder, Routing und Context früher als Feinschliff am Prompt. Konkrete Pfade: Anhang E und die Lesepfade in der Einführung.
Ein Satz als Arbeitsauftrag, bevor der Hype das Ticket schreibt:
Spezifiziere Erfolg, Failure Modes und Budget — dann baue den dünnsten Slice, der das aushält, mit Eval und Kill-Switch.
Danke und Einladung
Danke an alle, die in Reviews, Postmortems und ehrlichen Retros die Lücke zwischen Demo und Produktion benannt haben — ohne sie wäre dieses Buch dünner und netter und nutzloser. Fehler und blinde Flecken bleiben beim Autor; Verbesserungen an Vorlagen und Checklisten sind willkommen, solange sie Praxis bleiben und nicht Marketing.
Wenn du nach der Lektüre ein Feature spezifizieren, messen und verantworten kannst — unabhängig vom aktuellen Lieblingsmodell — hat das Buch seinen Job getan.
Viel Erfolg beim Bauen.
Martin Richardt
Weiter: Einführung.