Neun ingenieurtechnische Gewohnheiten für den Einsatz Ihres ersten KI-Agenten

In Kreisen der Agentenentwicklung kursiert eine Geschichte über eine Rechnung in Höhe von 47.000 Dollar. Sie wird ohne viele Details erzählt, daher sollte man sie als Beispiele und nicht als überprüften Fall betrachten. Ein Agent verhielt sich in jeder Demonstration fehlerfrei. Dann wurde er auf einen echten Kundenworkflow angewendet, geriet in einen Rückzahlungskreislauf und führte sechs Stunden lang immer wieder dieselbe Aktion aus, ohne dass jemand zusah. Das Modell war nicht besonders dumm – die Leute, die das System entwickelt hatten, hatten alles weggelassen, was dem Modell mitteilt, wann es aufhören soll.

Das ist die unangenehme Wahrheit bei der Entwicklung von Ingenieurslösungen für KI-Systeme. Selbst wenn man Python, RAG, Agenten, Vektordatenbanken, Prompting-Techniken sowie alle aktuellen Modellversionen kennt, kann man dennoch nicht bereit für die Produktion sein. Die Fähigkeiten, die einem nach dem Scheitern einer Demo helfen, kommen in Tutorials nur selten vor. Sie sind langweilig und leicht zu überspringen – doch sie unterscheiden ein beeindruckend aussehendes System von einem, dem man vertrauen kann. Hier sind neun Arbeitsgewohnheiten, die sinnvoll sind, bevor man etwas Autonomes veröffentlicht.

Warum mehr Wissen einen nicht zum Senior macht

Einige Zahlen zeigen, wie oft Projekte zwischen Demo und Implementierung stecken bleiben. Sie stammen aus zweiter Hand und die Methoden variieren, daher sollten sie als grobe Orientierung verstanden werden:

• Laut einer Prognose von Gartner Mitte 2025 würden über 40 Prozent der agilen KI-Projekte vor Ende 2027 abgebrochen, was auf steigende Kosten, unklare Nutzenwirkungen und schwache Risikokontrollen hindeutet.

Laut einer Umfrage von S&P Global Market Intelligence aus dem Jahr 2025 geben Unternehmen etwa 46 % ihrer KI-Proof-of-Concepts vor der Produktion auf.

Die NANDA-Initiative des MIT, die mehr als 300 Implementierungen untersucht hat, soll ergeben haben, dass nur etwa 5 % eine messbare finanzielle Wirkung zeigten.

Kein Modell verschlechterte plötzlich um 40 % seine Fähigkeit zum Schlussfolgern. Zwischen der Demo und dem Verkaufsstart geht etwas schief. Die gängige Theorie besagt, dass Produktionsfehler oft durch das um das Modell herumliegende System verursacht oder verschärft werden und nicht allein durch die Ausgabe des Modells: fehlende Schutzmechanismen, schlechte Daten, schwache Validierung, mangelhafte Überwachbarkeit und unkontrollierte Ausgaben.

Ein Benchmark zeigt in dieselbe Richtung, beweist aber nicht die Ursache. Bei tau-bench, der Tool-nutzende Agenten bei Aufgaben wie Flugbuchungen und Bearbeitung von Support-Anfragen testet, hieß es in einer Zusammenfassung, dass selbst die besten Modelle weniger als die Hälfte dieser Aufgaben bewältigten und dass bei Wiederholung einer Aufgabe die Konstanz auf etwa ein Viertel zurückging. Das misst lediglich die Fähigkeit und diagnostiziert nichts. Es besagt, dass Agenten unzuverlässig sind – nicht warum.

Bleiben Sie bei einem Unterschied, denn er prägt alle folgenden Gewohnheiten: Die obige Schleife war keine falsche Antwort. Nichts hielt sie auf. Die Lücke zwischen der Ausgabe eines Modells und dem, was das System mit dieser Ausgabe zulässt, ist der Ort, an dem die meisten dieser Gewohnheiten liegen.

1. Schreiben Sie die Bewertung vor der Funktionalität

Anfänger schreiben einen Prompt, testen ihn einige Male, überprüfen das Ergebnis und veröffentlichen es. Erfahrene Entwickler notieren zunächst, was „richtig“ bedeutet, indem sie eine Reihe von Testfällen erstellen, und greifen erst danach zur Umsetzung der Funktion.

Eine Bewertung kann einfach gehalten werden: Sammeln Sie 20 bis 30 reale Beispiele aus der tatsächlichen Nutzung, jeweils mit dem erwarteten Ergebnis, und prüfen Sie Ihren Prompt bei jeder Änderung gegen alle davon. Wenn Sie ohne genaue Betrachtung der Ausgaben und Raten nicht erkennen können, ob eine Änderung hilfreich war, handelt es sich um ein Gefühl und nicht um eine echte Bewertung. Diese eine Gewohnheit ist der schnellste Weg, um das Veröffentlichen von Regressionen zu verhindern, die man nicht sehen kann.

2. Geben Sie Kontext wie Geld aus

Die übliche Angewohnheit von Anfängern ist es, alles hineinzupacken: den gesamten Dokumententext, das ganze Chatverhältnis, fünf Beispiele „für alle Fälle“. Mehr Kontext scheint sicherer zu sein – ist es aber in der Regel nicht. Jedes zusätzliche Element konkurriert um die Aufmerksamkeit des Modells und gibt ihm einen weiteren falschen Hinweis, auf den es sich konzentrieren muss. Betrachten Sie das Fenster als Budget:

• Kürzen Sie die heruntergeladenen Dokumente auf die relevanten Teile.
• Zusammenfassen Sie ältere Gesprächspunkte und spielen Sie sie nicht vollständig ab.
• Entfernen Sie Beispiele, die keinen Nutzen bringen.

Falls Sie nicht wissen, was das Fenster füllt, drucken Sie den gesamten Prompt, den Sie senden, aus und lesen Sie ihn durch. Viele Menschen sind überrascht, wie viel darin unnötiger Ballast ist.

3. Setzen Sie vor dem Einsatz Grenzen für die Autonomie

Dies ist die Gewohnheit, die den Kreislauf der Rückerstattungen gestoppt hätte. Eine Untersuchung teurer Fehler von Agenten durch eine Gruppe namens Operator Collective ordnete die Fälle in fünf Kategorien ein: Keine Beschränkungen für autonome Aktionen, veraltete oder fehlerhafte Daten, Vertrauen auf Ausgaben ohne Überprüfung, Sicherheit als Nachgedanke sowie Fehler, die niemand bemerkte, weil nichts überwacht wurde. Keine dieser fünf Kategorien lautet „das Modell hat falsch argumentiert“. Es handelt sich dabei um eine einzige Untersuchung und nicht um ein Naturgesetz, doch sie weist auf etwas Reales hin. Eine falsche Ausgabe schadet selten allein – der Schaden entsteht, wenn nichts danach sie auffängt, begrenzt oder verhindert, dass sie sich wiederholt.

Die Rechnung macht das unverhandelbar. Wenn jeder Schritt in einem Workflow eines Agenten zu 95 Prozent erfolgreich ist und die Aufgabe 20 Schritte umfasst, wird das Ganze nicht zu 95 Prozent korrekt abgeschlossen, weil sich die Chancen addieren. Bei 90 Prozent Erfolgsrate pro Schritt hat eine 20-Schritte-Kette nur zu etwa 12 Prozent Erfolg. Eine Demo, die drei Schritte reibungslos ausführt, sagt fast nichts über einen Produktivfluss mit zwanzig Schritten aus.

Vor dem Einsatz eines autonomen Systems sollte man ihm eine Schrittbegrenzung, eine Kostenobergrenze, eine Zeitbeschränkung sowie eine Möglichkeit zum Selbststopp geben. Der Grund dafür ist nicht, dass dem Modell nicht vertraut werden kann, sondern weil die Wahrscheinlichkeit niemals verliert.

4. Protokollieren, als würde man mitten in der Nacht um 2 Uhr blind debuggen.

Der gefährlichste Fehler verursacht keinen lauten Absturz. Der Agent ergreift die falsche Maßnahme, meldet Erfolg, das Dashboard bleibt grün – und ein Kunde verliert Geld oder erhält schlechte Ratschläge, bevor jemand etwas bemerkt.

Anfänger fügen Logging hinzu, nachdem etwas kaputtgegangen ist. Erfahrene Ingenieure erstellen von Anfang an strukturierte Trace-Daten: Jeder Eingabewert, jede Toolaufruf und jeder Zwischenschritt der Logik werden mit Zeitstempel versehen und suchbar gemacht. Nach drei Wochen möchten Sie genau das wiedergeben, was der Agent gesehen und entschieden hat, anstatt sich das aus dem Gedächtnis zusammenzureimen. Wenn Ihre derzeitige Einrichtung dazu führt, dass Sie mitten in der Nacht raten müssen, schließen Sie zunächst diese Lücke.

5. Die Leiter hinaufklettern: Prompt erstellen, Daten abrufen und anschließend feinabstimmen

Wenn die Genauigkeit enttäuscht, wenden sich Anfänger oft direkt an das Feintunen, weil es wie „echte“ Ingenieurarbeit erscheint. Das ist in der Regel der falsche erste Schritt – ein bekanntes Beispiel zeigt, warum. Microsoft-Forscher nahmen GPT-4, fügten eine Reihe von Prompting-Techniken namens Medprompt hinzu und verglichen es mit Med-PaLM 2, Googles medizinischem Spezialisten, der anhand klinischer Daten feingetuned wurde und mit von Experten verfassten Prompts kombiniert wurde. Bei der Messung mit MedQA erzielte das feingetunete Med-PaLM 2 86,5 % und GPT-4 mit nur Prompting und Medprompt 90,2 %. Das bedeutet eine Reduzierung der Fehlerrate um 27 % sowie deutlich weniger Modellaufrufe im Vergleich zum Weg des Feintunens.

Die sinnvolle Reihenfolge geht von günstig und rückgängig machbar bis hin zu teuer und langsam:

Prompting        Retrieval (RAG)      Fine-tuning
(cheap, fast,  →  (add missing    →   (expensive, slow,
reversible)        knowledge)          last resort)

Bessern Sie zunächst den Prompt und messen Sie ihn. Wenn dem Modell Fakten fehlen, fügen Sie eine Informationsbeschaffungsfunktion hinzu. Feinabstimmen sollten Sie nur dann durchführen, wenn Sie über einen großen, sauberen Datensatz sowie ein spezifisches Verhalten verfügen, das durch den Prompt tatsächlich nicht erzeugt werden kann. Die meisten Teams müssen dies nie tun, da die früheren Schritte das Problem bereits lösen.

6. Trennen Sie den Verstand von den Händen

Ein Agent für Anfänger besteht oft aus einem einzigen großen Prompt, der planen, entscheiden und ausführen muss – alles auf einmal. Wenn er versagt, gibt es keine Trennung zwischen „das Modell hat falsch gedacht“ und „der Code hat etwas Falsches getan“, weil alles miteinander verknüpft ist.

Erfahrene Entwickler teilen das System in zwei Teile auf. Ein Teil, das Modell, fungiert als „Gehirn“ und wählt den nächsten Schritt aus. Ein anderer Teil, reiner deterministischer Code, der als „Antrieb“ dient, führt diesen Schritt aus: Er ruft die API auf, überprüft die Antwort, versucht es innerhalb bestimmter Grenzen erneut und achtet auf die Beschränkungen aus Regel drei. Genau diese Trennung macht ein System debugfähig – man kann sofort erkennen, ob das Modell die falsche Aktion gewählt hat oder der Ausführungscode eine richtige Aktion falsch umgesetzt hat; es handelt sich dabei um unterschiedliche Fehler mit unterschiedlichen Lösungen.

7. Behandeln Sie Anfragen wie Code und versionieren Sie sie

Ein Prompt, der vier Überarbeiten erforderte, ist Beispieldaten für die Produktionslogik. Behandeln Sie ihn wie Notizzettel – sonst verlieren Sie die funktionierende Version, sobald jemand sie „verbessert“. Halten Sie Prompts wie alle anderen Dateien unter Versionskontrolle, führen Sie Ihre Bewertungssätze nach Regel eins bei jeder Änderung durch, bevor diese eingefügt wird, und führen Sie ein kurzes Changelog darüber auf, was geändert wurde und warum. Es klingt zu grundlegend, um darauf einzugehen – genau deshalb überspringen es die meisten Teams, bis eine Regression im Prompt in die Produktion gelangt und niemand mehr sagen kann, was sich geändert hat.

8. Preis das Feature zunächst fest

Hier ist ein konkretes Beispiel. Ein unbeschränkter Agent, der eine einzelne Softwareaufgabe ausführt, verbrauchte API-Gebühren in Höhe von 5 bis 8 Dollar, während ganze Produktionsphasen einschließlich Wiederholversuchen und Toolaufrufen Kosten von 10 bis 100 Dollar verursachten. Die Zahlen unterscheiden sich je nach Modell, Aufgabe und Optimierung, doch das Muster bleibt gleich. Eine Kostenbelastung, die pro Aufgabe unbedeutend erscheint, wirkt bei hohem Volumen nicht mehr so unbedeutend, und ein Pilotprojekt, das im Test kostengünstig schien, kann stillschweigend dazu führen, dass ein Projekt eingestellt wird.

Anfänger bauen zuerst und lesen die Rechnung später. Erfahrene Ingenieure schätzen die Kosten pro Aufgabe bereits vor dem Schreiben von Code ein: grobe Anzahl der benötigten Tokens, erwartete Anzahl der Aufrufe pro Aufgabe sowie das erwartete tägliche Volumen. Wenn die Zahlen bei zehn Nutzern bereits unpassend erscheinen, werden sie bei zehntausend Nutzern nicht besser aussehen. Kosten sind keine finanzielle Angelegenheit, die erst nach dem Start geklärt werden muss. Es handelt sich dabei um eine Architekturentscheidung, die bereits getroffen wurde – egal ob man es bemerkt hat oder nicht.

9. Diagnose vor dem Raten

Wenn etwas kaputtgeht, ist der Reflex von Anfängern, auf das Modell zu zeigen und ein größeres einzusetzen oder einen längeren Prompt zu schreiben. Tun Sie das nicht. Die Fehler in den Überprüfungen, die unter Gewohnheit drei erwähnt wurden, lagen an fehlenden Schutzmechanismen, schlechten Daten, unkontrollierter Vertrauensseligkeit, schwacher Sicherheit oder einem Fehler, den niemand bemerkt hatte – und nicht daran, dass das Modell von selbst Fehler machte. Das ist eine Beobachtung aus einer Reihe von Fällen und keine Garantie für Ihre Situation, aber es handelt sich um eine kostengünstige Überprüfung vor einer teuren. Bevor Sie den Prompt anfassen, fragen Sie sich, ob die abgerufenen Daten veraltet oder falsch waren, ob ein Toolaufruf stillschweigend fehlgeschlagen ist und ob es Limits für Wiederholungsversuche gibt. Die Lösung liegt oft im umgebenden System, und eine Überprüfung kostet fünf Minuten – im Vergleich zu einem Neuschreiben.

Wann die Hälfte davon weggelassen werden kann

Auch nur eine der neun Gewohnheiten ist kostenlos. Die Bewertungsmethoden erfordern Zeit zum Aufbau, die Schutzmechanismen fügen Code hinzu und das Kostenmodell frisst einen Nachmittag, den man lieber für die Entwicklung nutzen würde. Wenn Sie an einem Wochenende Prototypen erstellen und der einzige Nutzer sind, überspringen Sie den größten Teil davon. Bringen Sie erst die Bewertungssuite, Schutzmechanismen sowie versionierte Anweisungen ein, wenn andere Menschen von dem beginnen, was Sie erstellt haben – und nicht früher. Das Durchführen eines Ein-Personen-Experiments mit Produktionsritualen kostet Zeit, die besser dafür verwendet werden könnte, herauszufinden, was funktioniert. Die Disziplin lohnt sich dort, wo es um echte Nutzer, echtes Geld oder echte Entscheidungen geht.

Die Veränderung in einem Satz

Laut dieser Darstellung hat kein intelligenteres Modell den Teufelskreis beseitigt. Was ihn beendete, war eine Reihe schriftlicher Regeln: Obergrenzen für die Autonomie, Überprüfungen vor jeder Aktion sowie eine Person, die die Protokolle durchliest. Governance statt Intelligenz. Anfänger versuchen, Fehler mit einem besseren Modell zu überwinden. Erfahrene Ingenieure entwickeln ein System, das sicher versagt, wenn das Modell falsch ist – denn früher oder später wird es das sein.