AI Product Engineering

• Viele Entwickler beschäftigen sich derzeit mit Agentic Software Engineering: Software mit AI bauen. AI Product Engineering ist ein anderes Feld: AI-Features in bestehende Unternehmenssoftware einbauen und Agenten echte Arbeit übernehmen lassen.
• Sobald AI-Features nicht mehr nur antworten, sondern handeln, steigt das Schadenspotenzial massiv: vom peinlichen Chatbot-Spruch zur gelöschten Produktionsdatenbank.
• Ein Sprachmodell ist eine probabilistische Komponente und braucht dieselbe Disziplin wie jede fehleranfällige Abhängigkeit: Agent Contract, Evaluation, Observability und Action Safety.
• Das sind Architektur-Entscheidungen. Sie gehören früh ins Projekt, lange vor dem Go-Live.

Die AI-Strategie der meisten Unternehmen besteht bisher aus kaum mehr als einem Chatbot und etwas Copilot für Meeting-Summaries. OpenClaw hat sichtbar gemacht, wie groß die Lücke zu dem ist, was möglich wäre. Viele wollen agentische Features, nur wenige bringen sie in Produktion. Denn sobald ein Feature Daten schreibt, Workflows auslöst oder Entscheidungen trifft, kann ein Fehler echten Schaden anrichten. Dafür fehlen in vielen Teams noch Methoden und Erfahrung. Die eigentliche Frage lautet deshalb: Wie baut man solche Features so, dass man ihnen vertrauen kann?

Der Hebel ist da. Ein AI-Feature, das aus einer wirren Kunden-E-Mail erkennt, welche Abteilung zuständig ist, das Anliegen kategorisiert und eine Ersteinschätzung mitliefert, bevor ein Mensch es überhaupt sieht. Ein Agent, der eingehende Rechnungen nicht nur entgegennimmt, sondern der passenden Bestellung zuordnet, Abweichungen erkennt und der Buchhaltung aufbereitet vorlegt. In vielen Unternehmen liegen diese Informationen in Tickets, Wikis, E-Mail-Postfächern und Freitextfeldern. Bisher nie systematisch nutzbar, weil die manuelle Pflege zu aufwendig war.

Aber dafür reicht kein Prompt.

Es reicht nicht, wenn es im Chat funktioniert

Die AI-Fails der letzten Jahre kennt mittlerweile jeder. Der Chevrolet-Chatbot, der einem Kunden ein Auto für einen Dollar „verkauft“ hat[1]. Der Air-Canada-Bot, der Trauertarif-Regeln erfunden hat, für die die Airline dann haften musste[2]. Der New Yorker Stadtchatbot, der Unternehmen geraten hat, gegen Arbeitsrecht zu verstoßen[3]. Peinlich, teuer, viral.

Aber das waren Chatbots. Die Konsequenzen waren überschaubar: ein PR-Desaster, ein Gerichtsurteil über 812 kanadische Dollar, ein deaktiviertes Feature.

Was seit 2025 passiert, ist eine andere Größenordnung. Bei Replit hat ein AI-Agent im Juli 2025 eine Live-Produktionsdatenbank mit Unternehmens- und Kontaktdaten gelöscht, obwohl ein expliziter Code Freeze galt[4]. Schon davor hatte er Fehler mit erfundenen Daten überdeckt, darunter eine Datenbank mit viertausend fiktiven Personen[5].

Die Kontexte sind verschieden: Kundenchats, Coding Agents, Ops-Workflows[6]. Das Muster ist dasselbe. Sobald Modelle nicht nur antworten, sondern handeln, steigt das Schadenspotenzial massiv. Wer einem AI-Feature erlaubt, Daten zu schreiben, Workflows auszulösen oder Entscheidungen vorzubereiten, muss wissen, wie man so ein System baut, betreibt und überwacht. Sonst wird aus „der Chatbot hat etwas Dummes gesagt“ schnell „der Agent hat etwas Irreversibles getan“.

Zwei verschiedene Fragen

Agentic Software Engineering bekommt aktuell viel Aufmerksamkeit: Coding Agents, Spec-Driven Development, Context Engineering. Das ist wichtig, beantwortet aber eine andere Frage.

Agentic Software Engineering fragt: Wie baue ich Software mit Hilfe von AI? AI Product Engineering fragt: Wie baue ich Software, die agentische AI als Feature enthält und in Produktion zuverlässig funktioniert?

Der entscheidende Unterschied: Beim agentischen Entwickeln bin ich der Mensch im Loop. Ich sehe jede Antwort, ich entscheide, ob der Code passt. Bei einem AI-Feature in Produktion sieht der Nutzer die Antwort. Oder schlimmer: Ein nachgelagertes System verarbeitet sie automatisch weiter. Da steht niemand mehr daneben. Und selbst wenn am Ende ein Mensch prüft: Plausibel klingenden Unsinn übersieht er leicht.

Was AI Product Engineering ausmacht

Ein Sprachmodell ist kein deterministischer Service. Es ist eine probabilistische Komponente. Leistungsfähig, aber unzuverlässig. Wer es in Produktlogik einbindet, braucht die gleiche Disziplin wie bei jeder anderen fehleranfälligen Abhängigkeit: Verträge, Tests, Monitoring.

Das ist Architekturarbeit, aber sie bleibt nicht bei den Architekten: Die Entscheidungen, die später teuer zu ändern sind, treffen Produktentwickler, Fachleute und Architekten gemeinsam. Welches Schema definiert den Contract zwischen Modell und Fachlogik? Wie wird Qualität gemessen? Was darf das System autonom, was braucht menschliche Freigabe? Diese Entscheidungen fallen am Anfang. Oder sie fallen einem später auf die Füße.

Ruben Vitt und ich fassen das in vier Prinzipien: Agent Contract statt Prompt-first, Evaluation statt Bauchgefühl, Observability statt Blindflug, Action Safety statt Vollzugriff. Was das konkret bedeutet, zeigt ein Beispiel.

Beispiel: Schadensmeldung bei einer Versicherung

Eine Versicherung bekommt Schadensmeldungen per E-Mail. Ein Kunde meldet einen Wasserschaden. Drei Absätze, emotional, unstrukturiert, die Hälfte der Informationen fehlt. Dazu vier Handyfotos vom Keller. Heute landet das in einem Postfach. Ein Sachbearbeiter liest, tippt alles in ein Formular, ordnet zu, priorisiert, leitet weiter. Vielleicht dreißig Minuten pro Fall.

Bisher war das nicht anders lösbar. Unstrukturierter Text, Bilder, fehlende Angaben, kein regelbasiertes System konnte das zuverlässig verarbeiten. Mit Sprachmodellen ändert sich das, aber nur, wenn man den Prozess als System denkt.

Agent Contract statt Prompt-first. Der Prompt ist nur ein Teil des Vertrags. Schema, Prompt, Modell, erlaubte Tools und Eval-Set gehören zusammen und werden gemeinsam versioniert. Ändert sich eins davon, ist das eine neue Version des Vertrags. Das Schema legt fest, was das Modell liefert: Schadenskategorie (Enum: Wasser, Feuer, Einbruch, Sturm, Unklar), Priorität (1 bis 3), betroffene Vertragsnummer, geschätzte Schadenshöhe, fehlende Unterlagen, dazu ein Feld needs_human_review für Fälle, in denen das Modell unsicher ist. Kein Freitext. Das Schema begrenzt die Form der Ausgabe, schützt aber nicht vor fachlich falschen Werten in validen Feldern. Dafür braucht es Validierung und Evals.

Evaluation statt Bauchgefühl. Ein repräsentatives Set aus historischen Schadensmeldungen, manuell gelabelt. Wird ein Wasserschaden als Einbruch klassifiziert? Erfindet das Modell Vertragsnummern? Diese Tests laufen bei jedem Modellwechsel, jedem Prompt-Update, jedem Deployment, automatisiert in der CI-Pipeline. „Sieht im Chat gut aus“ ist kein Test. Wer ohne Evals ausliefert, verschiebt das Testen an echte Nutzer.

Observability statt Blindflug. Jede Klassifikation wird geloggt: Modellversion, Schema-Fehlerrate, Anteil menschlicher Korrekturen, Fehlerquote je Falltyp. Wenn die Trefferquote bei Wasserschäden über Wochen sinkt, schlägt das Monitoring an. Die Messlatte dafür liefern die Sachbearbeiter: Jede Korrektur von Fachexperten ist ein gelabelter Fall, der auch ins Eval-Set wandert. Bei DPD ließ sich der Chatbot nach einem System-Update dazu bringen, zu fluchen und über die eigene Firma zu lästern[7]. Bekannt wurde das, weil ein Kunde den Chat online teilte.

Action Safety statt Vollzugriff. Das System darf klassifizieren und Vorschläge strukturieren, aber nicht eigenständig Kunden benachrichtigen, Fälle routen oder Zahlungen auslösen. Lese- und Schreibrechte sind getrennt. Neue Modellversionen laufen erst im Sandbox-Modus gegen historische Fälle. Beim Replit-Vorfall war der Code Freeze nur eine Anweisung. Technisch hatte der Agent weiter Schreibzugriff auf die Produktionsdatenbank[4].

Ergebnis: Der Sachbearbeiter sieht den vorklassifizierten, strukturierten Fall neben der Original-E-Mail, abgesichert durch Agent Contract, Evaluation, Monitoring und klare Berechtigungsgrenzen. Evals und Monitoring zeigen ihm, wo er genau hinsehen muss. Er prüft, korrigiert, wenn nötig, und gibt frei. Erst dann geht der Fall ins Routing, der Kunde bekommt Nachricht und fehlende Unterlagen werden angefordert. Aus etwa dreißig Minuten manueller Triage können wenige Minuten qualifizierte Prüfung werden.

Warum die meisten das unterschätzen

Ein Prototyp sieht schnell nach Produkt aus. Ein paar gute Prompts, ein Coding Agent, etwas Hartnäckigkeit, und es steht eine beeindruckende Demo im Browser. Viele Teams nehmen dieses Tempo mit in die Feature-Entwicklung und überspringen dabei alles, was ein AI-Feature produktionsreif macht.

Die Probleme zeigen sich erst im Betrieb: Der Modellanbieter rollt still ein Update aus, und die Qualität kippt. Ein Edge Case taucht auf, den niemand getestet hat. Das Feature liefert technisch valide Ergebnisse, die fachlich Unsinn sind, und ohne Monitoring merkt es niemand.

Schlechte Chatbots fallen auf. Leistungsfähige AI-Systeme mit Systemzugriff scheitern leise.

Replit war der laute Fall. Gefährlicher sind die leisen: Die Antworten klingen plausibel, die Aktionen sind technisch korrekt. Erst wenn jemand genau hinsieht, wird klar, dass das System seit Wochen falsche Entscheidungen getroffen hat.

Eine eigenständige Disziplin

Agentic Software Engineering hat sich als Disziplin etabliert, mit Methoden, Frameworks und Best Practices. Für AI-Features in Produktion fehlt ein vergleichbarer Rahmen. Dabei sind die Entscheidungen hier mindestens genauso weitreichend.

Agent Contract, Evaluationsstrategie, Observability, Action Safety: Das sind Architektur-Entscheidungen, keine Implementierungsdetails. Und wie bei jeder Architektur geht es dabei um Trade-offs, die man bewusst abwägen muss. Nicht um eine Lösung, die für alle passt.

Die Technik dafür existiert. Was fehlt, ist die Disziplin, AI-Features als System zu denken. Und zwar früh, nicht als Checkbox vor dem Go-Live. Welche konkreten Entscheidungen das sind und welche Trade-offs dahinterstecken, zeigen die nächsten Teile dieser Reihe, angefangen bei den Qualitätsfragen auf Feature-Ebene.

Weiterlesen: Ruben Vitt zeigt in AI Systems Architecture beginnt dort, wo Modelloutput Teil der Produktlogik wird und Evals in der CI, wie Contracts mit Zod, Eval-Frameworks und Observability konkret aussehen.

1. VentureBeat: A Chevy for $1? Car dealer chatbots show perils of AI for customer service (Dezember 2023)  ↩︎

2. CBC News: Air Canada found liable for chatbot’s bad advice on bereavement discounts (Februar 2024)  ↩︎

3. The Markup: NYC’s AI Chatbot Tells Businesses to Break the Law (März 2024)  ↩︎

4. Fortune: AI coding tool Replit wiped a production database in what its CEO called a ‘catastrophic failure’ (Juli 2025)  ↩︎

5. The Register: Vibe coding service Replit deleted production database (Juli 2025)  ↩︎

6. Weitere Vorfälle sammelt die AI Incident Database. Ein Beispiel aus dem Betrieb: ABC News: Cursor-Agent löscht Produktionsdatenbank und Backups von PocketOS (April 2026)  ↩︎

7. TIME: AI Chatbot Curses at Customer and Criticizes Company After DPD Update (Januar 2024)  ↩︎