Hochbegabt und leicht dümmlich – Die Fails: Wenn der hochbegabte Agent dümmlich wird

Teil 3 der Serie „Hochbegabt und leicht dümmlich" – Wie KI-Agents unsere Softwareentwicklung verändern

Abends auf der Couch, Cola in der Hand, Handy in der anderen. Ich scrolle durch meine Mails – eigentlich nur ein kurzer Blick, ob alles ruhig ist. Dann stutze ich. In einem Postfach sind deutlich mehr Nachrichten als erwartet. Ich tippe rein, lese den Verlauf und stelle fest: Mein KI-Agent hat, während ich gemütlich auf der Couch lag, im Namen meines Kollegen Jens einen Rahmenvertrag verhandelt. Nicht eine Antwort. Vier E-Mails hin und her. Detailliert, strukturiert, professionell.

Das Ergebnis war fachlich einwandfrei. Das Vorgehen war ein Desaster.

In Teil 1 und 2 habe ich die Erfolgsgeschichten erzählt. Heute wird es unbequem. Denn wer ehrlich über KI-Agents reden will, muss auch über die Momente sprechen, in denen der hochbegabte Kollege seinen fehlenden Menschenverstand besonders eindrucksvoll unter Beweis stellt.

Die Abwesenheitsassistent-Geschichte – komplett

Fangen wir von vorne an. Die Idee war simpel: Ich bin nicht da und möchte, dass eingehende E-Mails nicht einfach liegen bleiben. Mein Agent sollte als Abwesenheitsassistent fungieren. Eingehende Nachrichten sichten, bei Dringendem ans Team weiterleiten, bei allem anderen eine freundliche Abwesenheitsnotiz schicken. Harmlos, dachte ich.

Die Vorgeschichte: Mein Kollege Jens hatte kurz vor seinem Urlaub noch eine E-Mail an einen Kunden geschickt – eine Nachfrage zu ein paar offenen Punkten in einem Rahmenvertrag. Nichts Eiliges, ein paar Sicherheitsklauseln, die noch geklärt werden mussten. Die Antwort konnte warten, bis Jens zurück ist. Dachten wir.

Während wir beide abwesend waren, antwortete der Kunde auf Jens’ Mail. Und jetzt wird es interessant: Mein Agent sah die eingehende Nachricht, erkannte das Thema und – folgerte, völlig logisch aus seiner Perspektive – dass eine qualifizierte Antwort hilfreicher wäre als eine Abwesenheitsnotiz.

Wohlgemerkt: Der Agent hatte die klare Anweisung, in seinen Nachrichten darauf hinzuweisen, dass er eine KI ist. Das hat er auch getan. Was er nicht hatte, war die Anweisung, dass er nicht im Namen von Jens antworten soll. Und dass er nicht auf inhaltliche Fragen eingehen soll. Und dass er nicht einfach immer wieder antworten soll, wenn der Kunde nachfragt.

Also tat er genau das. Der Kunde schrieb zurück, der Agent antwortete. Der Kunde hatte eine Rückfrage, der Agent klärte sie. Ungefähr vier Mails gingen hin und her – und am Ende waren sämtliche offenen Sicherheitsklauseln im Vertrag zu unserer vollsten Zufriedenheit ausverhandelt. Im Namen von Jens. Von einer KI. Ohne dass irgendjemand bei uns davon wusste.

Das Ergebnis war sachlich einwandfrei. Jens hätte es kaum anders formuliert. Und genau das macht die Geschichte so lehrreich: Der Agent hat nicht versagt. Er hat geliefert. Nur eben komplett an jeder Berechtigung und jedem Freigabeprozess vorbei.

Warum passiert das?

Wenn man den ersten Schreck verdaut hat, lohnt sich die nüchterne Analyse. Denn der Agent hat keinen Fehler gemacht – nicht im klassischen Sinn. Er hat exakt das getan, was sein Kontext zuließ.

Das ist die unbequeme Wahrheit über KI-Agents: Sie machen keine Fehler. Sie interpretieren die Lücken in deinen Anweisungen. Wo du etwas für selbstverständlich hältst, sieht der Agent eine offene Tür. Wo du „das versteht sich doch von selbst" denkst, fehlt dem Agent genau diese Information.

Mein Prompt sagte: Hilf bei eingehenden E-Mails, weise darauf hin, dass du eine KI bist. Der Agent hat sich als KI ausgewiesen – Häkchen. Und dann trotzdem inhaltlich geantwortet, verhandelt, geklärt. Weil ich nie gesagt habe, dass er das nicht tun soll. Dass ein Abwesenheitsassistent nicht eigenständig Vertragsklauseln verhandelt – das war für mich offensichtlich. Für ihn nicht.

Die Metapher, die ich seit dem Vorfall nutze: Es ist wie ein Chirurg, dem man sagt „Operieren Sie den Patienten" – aber nicht, welches Bein. Er operiert trotzdem. Brillant. Am falschen Bein. Nicht weil er inkompetent ist. Sondern weil du die eine Information weggelassen hast, die für dich selbstverständlich war.

Im Nachgang war die Situation vor allem eines: lustig. Jens hat gelacht, der Kunde hat gelacht, und das Verhandlungsergebnis stimmte ja sogar. Aber es hätte genauso gut schiefgehen können – mit einem sensibleren Thema, einem weniger verständnisvollen Kunden oder schlicht falschen Zusagen.

Die Konsequenz war klar: Der Prompt musste massiv erweitert werden. Ganz konkrete Regeln, kein Interpretationsspielraum. Der Agent muss erkennen, ob ich persönlich gemeint bin – nicht nur, weil eine Mail in meinem Postfach landet oder ich im CC stehe. Er darf ausschließlich in meinem Namen antworten, nie als eine andere Person. Und er antwortet nur dann, wenn ich eine konkrete Aufgabe habe oder direkt angesprochen werde – nicht bei jeder Mail, die zufällig bei mir aufschlägt.

Das Ergebnis? Der Abwesenheitsassistent ist heute cleverer und besser als je zuvor. Aber nicht weil das Modell besser wurde – sondern weil ich aus dem Fail gelernt habe, was alles in den Prompt gehört, an das ich vorher nicht gedacht hatte.

Der Alltags-Fail: Wenn der Agent „aufräumt"

Die Abwesenheitsassistent-Geschichte ist der spektakuläre Fall. Aber im Alltag passieren die Fails leiser – und gerade deshalb manchmal tückischer.

Ein Beispiel, das mich regelmäßig beschäftigt: Der Agent findet in einer Konfigurationsdatei einen Eintrag, den er für veraltet hält. Eine URL, die nicht mehr zu passen scheint. Ein Kommentar, der auf eine alte Version verweist. Und was macht unser hochbegabter Kollege? Er räumt auf. Löscht die Zeile. Oder ändert die URL. Oder entfernt den Kommentar, weil er „nicht mehr aktuell" ist.

Das Problem: Manchmal war der Eintrag absichtlich da. Manchmal hat der Kommentar einen Grund, der sich nicht aus der Datei allein erschließt. Manchmal gibt es eine Geschichte hinter einer Konfiguration, die nur im Kopf des Entwicklers existiert – und die der Agent nicht kennen kann.

Es ist diese Hilfsbereitschaft, die gefährlich wird. Der Agent will nicht schaden. Er will helfen. Und genau das macht ihn unberechenbar, wenn die Grenzen nicht klar genug sind. Er findet eine vermeintliche Verbesserung und setzt sie um – weil ihm niemand gesagt hat, dass er hier nicht anfassen soll.

Mittlerweile sage ich manchmal explizit: „Fass diese Dateien nicht an." Nicht weil der Agent böswillig wäre. Sondern weil seine Definition von „aufräumen" und meine nicht immer deckungsgleich sind.

Halluzinationen: Wenn der Agent sich Dinge ausdenkt

Ein anderes Thema, das mir anfangs schlaflose Nächte bereitet hat: Halluzinationen. Der Agent generiert Code, der eine API aufruft, die es nicht gibt. Referenziert eine Bibliotheks-Funktion, die so nie existiert hat. Oder schreibt eine Konfiguration, die syntaktisch perfekt aussieht, aber auf erfundenen Parametern basiert.

Das Tückische: Es sieht absolut überzeugend aus. Der Code ist sauber strukturiert, die Benennung plausibel, die Logik nachvollziehbar. Nur existiert die Funktion nicht. Oder der Parameter heißt anders. Oder die API-Version, die er nutzt, gibt es gar nicht mehr.

Hier zeigt sich wieder die Dualität: Derselbe Agent, der in Teil 2 eine Payment-Integration in 90 Minuten umgesetzt hat, erfindet im nächsten Moment eine API-Methode, die es nie gab. Hochbegabt und dümmlich – manchmal im selben Atemzug.

Die Lektion: Vertrauen ja, blindes Vertrauen nein. Jedes Ergebnis muss geprüft werden. Und genau deshalb war die Playwright-Integration, die ich in Teil 2 beschrieben habe, so ein Wendepunkt – weil der Agent seine eigene Arbeit testen kann, bevor sie bei mir auf dem Schreibtisch landet.

Der Agent vergisst

Was mich am Anfang am meisten frustriert hat: Regeln, die ich definiert habe, werden vergessen. Nicht sofort. Nicht immer. Aber regelmäßig genug, um ein echtes Problem zu sein.

Das typische Muster: Ich notiere eine Regel in einer Anweisungsdatei – „Erstelle für jede Änderung ein GitHub Issue" – und bin der Meinung, damit ist das geklärt. Für immer. Beim ersten Durchlauf macht der Agent es. Beim zweiten auch. Beim dritten vergisst er es. Ich weise ihn darauf hin. Er entschuldigt sich, sagt, er hätte es wissen müssen, und macht es dann wieder richtig. Bis zum nächsten Mal.

Der Grund ist kein technischer Bug. Es ist die Natur von Sprachmodellen: Der Agent kann sich nicht unbegrenzt viel merken. Je mehr Kontext sich aufbaut, desto eher geht eine einzelne Regel in der Masse unter. Irgendwann wird die Anweisung, die du vor dreißig Nachrichten gegeben hast, von neuerem Kontext überlagert. Nicht gelöscht – aber in den Hintergrund gedrängt.

Die Konsequenz, die wir daraus gezogen haben, gilt nicht nur für den Abwesenheitsassistenten – sie betrifft unsere gesamte Arbeitsweise mit KI-Agents: Feste Regeln dort einsetzen, wo sie notwendig sind. Sich nicht darauf verlassen, dass man dem Agent etwas einmal gesagt hat und es ab jetzt immer gilt. Stattdessen: Die richtigen Informationen zur richtigen Zeit liefern.

Konkret heißt das: Branch-Schutzregeln in Git. Pflichtfelder in Issue-Templates. Automatische Checks, die ein PR ablehnen, wenn die Dokumentation fehlt. Alles, was der Agent vergessen kann, muss an einer Stelle verankert sein, die er nicht umgehen kann. Und Kontext, den er für eine bestimmte Aufgabe braucht, wird genau dann geladen, wenn die Aufgabe ansteht – nicht pauschal in eine endlose Anweisungsdatei geschrieben, die er irgendwann nur noch überfliegt.

Das klingt nach Misstrauen. Ist es auch. Aber es ist produktives Misstrauen – dasselbe, das man bei jedem neuen Mitarbeiter hat, bis man seine Arbeitsweise kennt. Mit dem Unterschied, dass dieser Mitarbeiter nie aufhört, der Neue zu sein.

Die Kernlektion: Kontext ist alles

Wenn ich alle Fails auf einen Nenner bringe, dann ist es dieser: Jeder einzelne war ein Kontext-Problem. Nicht ein Intelligenz-Problem, nicht ein Modell-Problem – ein Kontext-Problem.

Der Agent beim Abwesenheitsassistenten wusste nicht, wo seine Befugnisse enden. Der Agent beim Aufräumen kannte die Geschichte hinter der Konfiguration nicht. Der Agent bei der Halluzination hatte nicht die Möglichkeit, seine Annahmen gegen die Realität zu prüfen. Und der Agent, der Regeln vergisst, hatte zu viel Kontext auf einmal und zu wenig davon zur richtigen Zeit.

Die Qualität der Eingabe bestimmt die Qualität der Ausgabe. Das ist kein Slogan – das ist die zentrale Erkenntnis nach Monaten im Echtbetrieb. Und „Eingabe" heißt nicht nur: was du sagst. Sondern auch: wann du es sagst, wie klar du es formulierst und wo du es verankerst. Genau deshalb ist Prompt Engineering keine Nebensache. Es ist die Kernkompetenz, die darüber entscheidet, ob dein KI-Agent ein Werkzeug oder ein Risiko ist.

In Teil 4 zeige ich, wie wir heute Prompts bauen, welches Modell wir für welchen Zweck einsetzen und welche fünf Regeln wir aus all diesen Erfahrungen destilliert haben.

Nächste Woche: Die Bedienungsanleitung. Prompt Engineering, Modellwahl und alles, was wir gelernt haben – damit der hochbegabte Kollege endlich auch weiß, wo die Kaffeemaschine steht.

Agent-Akte #3: Die Fails Was: KI-Agent als Abwesenheitsassistent, alltägliche Entwicklungsunterstützung Ergebnis: Vier E-Mails hin und her – der Agent hat im Namen von Jens Sicherheitsklauseln in einem Rahmenvertrag ausverhandelt (fachlich einwandfrei, prozessual ein Desaster), ungewolltes „Aufräumen" von Konfigurationsdateien, halluzinierte APIs, vergessene Regeln Lektion: Der Agent macht keine Fehler – er interpretiert die Lücken in deinen Anweisungen. Jeder Fail war ein Kontext-Problem. Feste Regeln im System erzwingen, nicht nur im Prompt notieren. Und: die richtige Information zur richtigen Zeit liefern – nicht alles auf einmal.

Tech Corner: Anatomie eines fehlerhaften Prompts

Für alle, die wissen wollen, was genau schiefgelaufen ist – und wie es besser geht.

Der Abwesenheitsassistent-Prompt: Vorher

So sah der Prompt in etwa aus, mit dem das Desaster begann (vereinfacht):

Du bist mein E-Mail-Assistent während meiner Abwesenheit.

Aufgabe:
- Lies eingehende E-Mails
- Beantworte sie professionell und hilfreich
- Leite dringende Anfragen ans Team weiter

Kontext:
- Ich bin vom [Datum] bis [Datum] nicht erreichbar
- Das Team erreichst du unter [E-Mail]
- Wichtige aktuelle Projekte: [Projektliste]

Was fehlt hier? Fast alles, was zählt. Keine Grenzen. Keine Eskalationsregeln. Keine Definition, was „beantworten" bedeutet und was nicht. Der Agent hat den Spielraum maximal ausgelegt – weil ich ihn maximal gelassen habe.

Der korrigierte Prompt: Nachher

Du bist mein E-Mail-Assistent während meiner Abwesenheit.

## Identität
- Du antwortest ausschließlich in MEINEM Namen (Sascha)
- Du gibst dich NIEMALS als eine andere Person aus –
  auch nicht, wenn die ursprüngliche Mail von einem
  Kollegen stammt
- Du weist in jeder Nachricht darauf hin, dass du eine KI bist

## Wann du antwortest
- NUR wenn ich persönlich angesprochen oder adressiert bin
- NICHT wenn ich nur im CC stehe
- NICHT wenn die Mail an einen Kollegen gerichtet ist,
  auch wenn sie in meinem Postfach landet
- NUR wenn eine konkrete Aufgabe oder direkte Frage an mich
  vorliegt

## Was du darfst
- Informiere Absender, dass ich abwesend bin und wann ich zurück bin
- Leite dringende Anfragen ans Team weiter: [E-Mail-Adresse]
- Beantworte einfache Sachfragen, wenn die Antwort in der
  Projektdokumentation steht (z.B. Status, Termine, Ansprechpartner)

## Was du NICHT darfst
- Zusagen jeglicher Art machen (Termine, Leistungen, Preise, Konditionen)
- Vertragliche oder kommerzielle Themen inhaltlich beantworten
- Entscheidungen treffen oder Empfehlungen aussprechen,
  die eine Freigabe erfordern
- Auf Mails antworten, die nicht direkt an mich gerichtet sind

## Eskalation
Wenn eine Anfrage unter „Was du NICHT darfst" fällt:
1. Informiere den Absender freundlich, dass die Anfrage
   nach meiner Rückkehr bearbeitet wird
2. Leite die E-Mail mit dem Tag [DRINGEND] ans Team weiter
3. Beantworte die inhaltliche Frage NICHT

Das Muster: Was fehlt, wird gefüllt

Der Unterschied ist nicht die Länge – obwohl der neue Prompt deutlich länger ist. Der Unterschied ist die explizite Benennung von Grenzen. Im ersten Prompt war „beantworte professionell und hilfreich" eine Einladung, alles zu tun, was der Agent für hilfreich hält. Im zweiten Prompt ist klar definiert: Wer bist du, wann darfst du handeln, was ist erlaubt, was nicht, und was passiert im Graubereich. Die Regeln zu Identität und Antwortbedingungen – genau die, die nach dem Vorfall mit Jens dazugekommen sind – machen den entscheidenden Unterschied.

Die Regel dahinter

Prompt-Qualitäts-Checkliste:
[] Aufgabe definiert (Was soll der Agent tun?)
[] Grenzen definiert (Was darf er NICHT tun?)
[] Eskalation definiert (Was passiert bei Unsicherheit?)
[] Rolle definiert (Als wer tritt er auf?)
[] Kontext vollständig (Welche Infos braucht er?)
[] Output-Format definiert (Wie soll die Antwort aussehen?)

Das klingt nach viel Aufwand. Ist es auch – beim ersten Mal. Aber genau deshalb haben wir die Prompt-Bibliothek im Git-Repo, von der ich in Teil 1 und 2 gesprochen habe: Einmal sauber aufgesetzt, versioniert, reviewt – und dann bei jedem Einsatz automatisch geladen. Der Aufwand amortisiert sich nach dem zweiten Projekt.

In Teil 4 gehen wir tiefer in die Prompt-Struktur ein und zeigen, wie wir heute systematisch Prompts bauen – und warum die Wahl des richtigen Modells dabei eine größere Rolle spielt, als die meisten denken.

Dies ist Teil 3 der vierteiligen Serie „Hochbegabt und leicht dümmlich". Teil 1: „Der neue Kollege" | Teil 2: „Die Superkräfte" | Teil 4: „Die Bedienungsanleitung" erscheint nächste Woche.