Blog
Evolution im AI-Driven Development. Aus dem Maschinenraum
Ich erinnere mich noch gut an den Tag, als mir ein Kollege stolz demonstrierte, wie er ChatGPT einen Bugfix eingeredet hatte: „Schau, es funktioniert!“ Und ja, es funktionierte tatsächlich. Wie ChatGPT den Bug allerdings gefixt hatte, blieb eine Blackbox.
Das war 2023, also in der Steinzeit generativer KI. Und der Beginn einer Lernkurve, die nicht kontinuierlich und gerade verläuft, sondern Schlaglöcher und Hindernisse bereithält.
Was ich im Folgenden beschreibe, ist mein Weg in die KI-getriebene Softwareentwicklung, ins AI-Driven Development. Der war nämlich, wie jedes amtliche Abenteuer nicht etwa ein Zuckerschlecken, sondern ein Prozess voller Rückschläge, schmerzhafter Erkenntnisse und hart erarbeiteter Erfolge. Die beschriebenen sechs Stufen teilen sich in zwei Bereiche. Stufe 1 bis 3 habe ich in einem eigenen Projekt sehr konkret erlebt. Ab Stufe 4 wird die Geschichte mehr architektonisch: MCP, Skills und CLI sind dabei keine chronologische Kette, sondern komplementäre Schichten eines Stacks.
1. Der agentische Loop oder ein handelndes LLM
Wir erinnern uns alle an die Anfangstage von KI: Ein LLM war eine reine Antwortmaschine, die Antworten klangen immer apodiktisch, gaben Halluzinationen als Tatsachen aus und folgten oft der Devise “Kompetenz heucheln bei völliger Ahnungslosigkeit”.
Der Optimierungsbedarf war also hoch und die Grundidee simpel: Gib einem LLM ein paar Werkzeuge an die Hand und lass es selbst entscheiden, welches davon es wann einsetzt. Vielleicht werden die Ergebnisse dadurch besser.
Heute, im agentischen Zeitalter, ist das die neue Realität: Statt eines einzelnen Prompts, der eine statische Antwort produziert, denkt ein KI-Agent in Schleifen. Er kann nachfragen, korrigieren, iterieren. Das ist ein echter Paradigmenwechsel: vom LLM als Antwortmaschine zum LLM als handelndes System.
Ein Beispiel: „Wir planen einen Workshop in Geisenheim, Budget 800 € pro Person, suche mir Zugverbindungen ab Kassel, passende Hotels in der Nähe vom Veranstaltungsort und prüfe, ob der 14. April noch verfügbar ist.“
Ohne den agentischen Modus bedeutete das früher: mehrere Suchen, manuelles Vergleichen, Copy-Paste zwischen Tabs. Mit Search-Tool und ReAct-Loop arbeitet der Agent heute die einzelnen Schritte selbstständig ab. Und natürlich: Die Ergebnisse sind qualitativ deutlich besser.
Die Flausen der KI und ihre Gefahren
Gleichwohl ist die Kuh noch nicht vom Eis. Es bestehen weiterhin zwei eng verwandte LLM-Grundprobleme, die im agentischen Kontext sogar besonders gefährlich sein können.
Das erste, alte Problem: Halluzinationen. Ein klassischer Chatbot halluziniert noch immer. Ärgerlich zwar, aber oft erkennbar. Auch ein Agent phantasiert zuweilen falsche Tatsachen und handelt dann danach.
In unserem Micromata AI Driven Development Hub haben wir alle Modelle parallel verglichen. Nicht nacheinander, sondern bewusst gleichzeitig und mit identischen Aufgaben. Die Auswahl war gemischt: GPT-3.5 und GPT-4 als kommerzielle Varianten, Claude und Gemini als weitere Cloud-Modelle, Qwen2 und Llama 3 als Open-Source-Alternativen, die wir lokal betreiben können. Gerade Letztere waren für uns attraktiv: kein API-Kosten-Overhead, keine Daten, die das Unternehmen verlassen, volle Kontrolle über Deployment und Versionierung.
Halluzinationen: Das ernüchternde Ergebnis: Alle halluzinierten. Alle Agenten erfanden Tools, die gar nicht konfiguriert waren, meldeten „Analyse abgeschlossen” und interpretierten leere Ergebnisse als „kein Problem gefunden”. Kein Fehler, keine Warnung.
Praktisch bedeutete das: Ein GitHub-Kommentar basierte auf Analysen, die nie gelaufen sind. Das Issue wirkte bearbeitet, war es aber nicht.
Knowledge Cuttoff: Das zweite Problem war subtiler, aber genauso real: Knowledge Cutoff. Projektspezifische Konventionen, interne Bibliotheken, Architekturentscheidungen oder frisch geänderte Dependencies waren für das Modell unsichtbar. Es antwortete auf Basis von Allgemeinwissen, nicht auf Basis unseres Projekts.
Besonders problematisch dabei: Es machte diesen Umstand nicht transparent.
Dazu kommt noch das Context Window: Je mehr Schritte ein Agent geht, desto eher verdrängt er frühere Informationen. Und nach der Session ist ohnehin alles weg: kein Gedächtnis, kein Wissenstransfer, kein Gefühl dafür, dass dieses Issue vor einer Stunde schon einmal analysiert wurde.
Trauriges Fazit: Der agentische Einzelagent handelt allein, linear und vergesslich, mit einer Wissensbasis, die irgendwann in der Vergangenheit eingefroren wurde.
2. Agent Chain: Arbeitsteilung per Staffelstab
Die naheliegende Antwort darauf lautet: Wenn ein Agent nicht alles allein zuverlässig leisten kann, teilt man die Aufgabe einfach auf. Das Output von Agent A wird Input für Agent B usw. Der Anzahl der Agenten ist dabei theoretisch keine Grenze gesetzt.
Wichtig ist hier: Eine solche Chain lässt Halluzinationen und Knowledge Cutoff nicht verschwinden. Sie verteilt die Arbeit nur auf mehrere Schultern und kann auf diese Weise die ungewollten Effekte reduzieren. Ein Mehr-Augen-Prinzip, wenn man so will.
Unser Kern-Workflow war genau das: eine mehrstufige Chain, modelliert mit PydanticAI, einem Python-Framework für typsichere, komponierbare Agenten. Ein Agent ist hier im Kern ein Objekt mit Modell, System-Prompt und optionalen Tools:
Der Vorteil: Kontext, Regeln und Verhalten sind explizit modelliert, typsicher und gut testbar. Jeder Schritt ist eine klar benannte Einheit.
Der Ansatz dahinter ist Spec-Driven Development: Erst entsteht eine strukturierte Spezifikation, dann folgen daraus Planung, Review und PR.
Was die Chain nicht kann. Drei Lektionen
- Fehler-Propagation: Die Chain ist streng sequenziell. Wenn früh etwas schiefgeht, propagiert der Fehler nach hinten. Bei uns begann der Schmerz oft schon beim Routing: Ein Ticket wurde z. B. als Java-Thema klassifiziert, obwohl es in Wahrheit ein DevOps-Problem war. Alles danach baute auf dieser falschen Prämisse auf.
- Das Temperature-Dilemma: In einer Chain wird der Temperature-Parameter zur Architekturfrage: Zu niedrig, und der Agent wird starr. Zu hoch, und dieselbe Aufgabe produziert unterschiedliche Ergebnisse in verschiedenen Läufen.
- Context Overload: RAG liefert selten nur das Nötige. Relevante und halb relevante Chunks landen gemeinsam im Kontext. Dann beginnt das Modell zu vergessen, welche Information aus dem Issue kam und welche aus dem Codekontext.
Kurz: Chain + RAG-Rauschen + Modell-Inkonsistenz ergibt schnell eine Rückkopplungsschleife, die nicht an schlechten Entwickler:innen scheitert, sondern an der Architekturannahme, dass gestaffelte Schritte automatisch Verlässlichkeit erzeugen.
Die Chain war also nicht falsch. Sie war nur keine Zuverlässigkeitsmaschine.
3. Agent Graph: Wenn das Team zum Team wird
Die Antwort auf die Limitierung der Chain ist der Graph. Statt einer linearen Staffel modellieren wir damit explizite Abhängigkeiten, Verzweigungen und Parallelität.
In unserem AI-Driven Development Hub haben wir genau das mit PydanticAI gebaut. Die auslösende Frage war simpel: Was passiert bei einem Full-Stack-Feature, das Backend, Frontend und manchmal auch Deployment betrifft? In der Chain wartete alles nacheinander aufeinander. Im Graphen konnten diese Stränge parallel laufen.
Der Graph war also die richtige Antwort auf Sequenzialität. Aber er brachte ein neues Problem mit: Koordination ist nicht automatisch Verständnis.
Was der Graph uns gelehrt hat und das Prompt-Injection-Problem
- Der PlanMergeNode: Der PlanMergeNode war unser neuralgischer Punkt. Mehrere Handler-Agenten lieferten selbstsichere Teilpläne, die nicht immer zueinander passten. Ein Agent wollte den API-Contract ändern, ein anderer ging implizit davon aus, dass er stabil bleibt. Der Merge-Node entschied für eine Version, ohne den Widerspruch wirklich zu verarbeiten.
- Confident Wrongness: Confident Wrongness (das Modell liegt falsch — aber klingt dabei völlig sicher) tritt damit nicht mehr nur auf Agenten Ebene auf, sondern auf Systemebene.
- Prompt Injection: Dazu kam ein Sicherheitsproblem, das wir anfangs unterschätzt haben: Prompt Injection. Der IssueHandlerAgent liest Titel, Beschreibungen und Kommentare. Was passiert, wenn in einem Ticket nicht nur Anforderungen stehen, sondern auch versteckte Instruktionen?
Bitte implementiere das Login-Feature:
Sobald ein Agent externe Inhalte liest und danach handelt, ist dieser Kanal offen. Das gilt nicht nur für GitHub-Issues, sondern genauso für E-Mails, Tickets, Wikis oder Webseiten.
Trotzdem war das Grundprinzip richtig: Spezialisierte Agents parallel arbeiten zu lassen, ist sauberer als eine einzige Allzweck-Instanz. Was wir damals noch händisch in PydanticAI modelliert haben, taucht heute in Claude Code als eingebautes Konzept wieder auf.
Daneben zeigte sich ein zweites strukturelles Problem: Es gibt keinen Standard für Tool-Integration. Eigene Wrapper für GitHub, eigene Clients für Modelle, eigene Parser für Retrieval. Jeder Modellwechsel bedeutete neue Sonderfälle.
*** Hinweis: Bis Stufe 3 wurden Agenten beschrieben, die wir mit PydanticAI in Python selbst modelliert hatten: Modellwahl, Prompts, Tools, Routing und Graph-Logik lagen in unserem eigenen Anwendungscode.
Im Folgenden, ab Stufe 4, wechsle ich deshalb nicht auf eine neue Stufe derselben Agentenart, sondern in eine andere Laufzeitumgebung: Claude Code. Dort sind Subagents keine Python-Klassen unseres Projekts, sondern spezialisierte Agenten der Runtime: mit eigenem Kontextfenster, eigenem System Prompt, spezifischem Tool Zugriff und eigenen Berechtigungen. MCP, Skills und CLI sind in diesem Teil also keine Nachfolger von PydanticAI-Agenten, sondern weitere Schichten derselben Runtime. ***
4. MCP. Das Steckersystem für AI-Tools
Ab einem bestimmten Punkt wird nicht mehr das Modell zum Flaschenhals, sondern die Integration. Jedes Team schreibt denselben GitHub-Client, denselben Jira-Parser, dieselben Fehlerbehandlungen. Nicht weil das klug wäre, sondern weil es keinen gemeinsamen Nenner gibt.
MCP, das Model Context Protocol, ist die Antwort auf genau diese Verschwendung. Statt für jede Kombination aus Agent und externem System eine eigene Kopplung zu bauen, definiert das Protokoll, wie Tools, Ressourcen und Prompts standardisiert bereitgestellt werden.
Das Prinzip am Beispiel
Der ai-dd-hub hatte genau dieses Problem. Für jede Integration bauten wir eigene Wrapper:
Vor MCP:
- custom github-wrapper → LLM → custom parser → GitHub API
- custom jira-wrapper → LLM → custom parser → Jira API
- custom slack-wrapper → LLM → custom parser → Slack API
Mit MCP verschiebt sich jetzt das Muster (Grafik links).
Der entscheidende Unterschied ist nicht, dass der Agent plötzlich mehr kann. Der Unterschied ist, dass die Kosten der Integration sinken.
Was MCP nicht löst
- Tool-Explosion: Viele MCP-Server bedeuten viele Tools und viel Kontext-Overhead.
- Tool-Ambiguität: Ähnliche Werkzeuge mit ähnlichen Namen führen dazu, dass das Modell das falsche Tool aufruft und es nicht sofort merkt.
- Vertrauen und Sicherheit: MCP-Server sind keine neutrale Infrastruktur. Sie sind Code und Beschreibung, die wir in unsere Agenenumgebung holen. Standardisiert wird die Verbindung, nicht das Vertrauensmodell.
Kurz: MCP löst das Integrations-Chaos, nicht aber die Tool-Auswahl, das Zustandsmanagement oder Sicherheitsfragen.
5. Skills. Kompetenz, die der Agent schon mitbringt
Kennst du das? Gestern hast du eine halbe Stunde investiert, damit der Agent versteht, wie ihr Branches benennt, wie PRs aufgebaut sein sollen, welche Tests vor einem Draft-PR Pflicht und welche Team-Konventionen nicht verhandelbar sind. Heute eine neue Session. Alles von gestern ist weg.
Skills lösen genau dieses Briefing-Problem. Sie geben dem Agenten domänenspezifisches Wissen und wiederverwendbare Playbooks mit, bevor er anfängt zu arbeiten.
Für diesen Blogbeitrag reicht die Minimalform eines Skills in drei Bausteinen:
- Metadaten: Name und Beschreibung, damit der Agent weiß, wann der Skill relevant ist.
- Instruktionen: Regeln, Vorgehensweisen, Konventionen.
- Optionale Dateien oder Skripte: Beispiele, Templates, Referenzen oder ausführbare Hilfen.
Wer die Stufen 1–3 noch im Kopf hat, erkennt den Kontrast sofort: Was damals als system prompt direkt im PydanticAI-Code stand, lebt jetzt in einer eigenständigen Datei.
Regeln beim Git Workflow:
- Branch-Namen: `feature/TICKET-beschreibung` oder `fix/TICKET-beschreibung`
- Commits: Conventional Commits (`feat:`, `fix:`, `chore:`)
- Kein Auto-Commit ohne explizite Bestätigung
- PRs immer mit Ticket-Link und zunächst als Draft
Der eigentliche Sprung ist die Entkopplung. Das Wissen liegt in einer Datei: Diese ist versionierbar, lesbar, unabhängig und von der Agent-Runtime anpassbar.
Zusätzlich gibt es zwei Anwendungsmodi für Skills. Über /-Befehle kann man dem Agenten direkt mitteilen, welcher Skill anzuwenden ist. Es reduziert den Interpretationsraum des Agenten, wenn man selbst schon weiß, welches Tool am besten geeignet ist. Der Agent kann aber auch selbständig entscheiden, welche Skills anzuwenden sind, beispielsweise, wenn er mit Office-Formaten agiert.
Warum Skills nicht magisch sind
Confident Wrongness auf Regel-Ebene: Ein Skill macht den Agenten konsistenter. Das ist gut, solange die Regeln aktuell sind. Sobald der Skill veraltet ist, skaliert er den Fehler mit derselben Zuverlässigkeit, zumindest reproduzierbar und somit auch debugbar.
Skills ersetzen nicht die Infrastruktur darunter: Skills transportieren Wissen und Workflows. Sie lösen aber nicht von selbst das Ausführungsproblem. Sie brauchen weiterhin eine Laufzeit, Tool Zugriff und klare Berechtigungen.
Anders gesagt: Ein Skill ist das Playbook, nicht automatisch die ganze Maschine.
6. CLI oder Flashback 1990
Ich habe 1990 mit Computern angefangen. Kein GUI, kein Browser, kein Web, nur ein Prompt. Und wer wusste, wie man den bediente, hatte Zugriff auf die Maschine. Der direkte Weg dorthin: die Kommandozeile, also das Command Line Interface, kurz CLI.
Dann kamen GUIs. Dann Web-Interfaces. Dann APIs mit Wrappern über Wrappern. Jede Schicht hat Dinge zugänglicher gemacht und gleichzeitig den direkten Zugriff weiter entfernt.
Jetzt ist CLI zurück. Nur diesmal tippt der Agent. Das ist darum auch keine Nostalgie, sondern eine Evolution.
Was sich gegenüber MCP + Skills ändert: Wenn ein Workflow stabil genug ist, willst du nicht jeden Schritt über zusätzliche Vermittlungsschichten schleusen. Du willst den kürzesten Weg zur Maschine.
Kein zusätzlicher Wrapper, kein Umweg über eine eigens erfundene Zwischenschicht. Befehl, Ergebnis.
CLI ist nicht automatisch besser als MCP. Aber dort, wo bereits gute Kommandozeilen-Werkzeuge existieren, ist sie oft der direktere Ausführungspfad.
Persistenz ist heute mehr als eine Datei
Der eigentliche Durchbruch liegt inzwischen nicht nur in der Shell, sondern in der Kombination aus Ausführung + Erinnerung.
Persistenz kommt heute typischerweise aus mehreren Quellen:
- CLAUDE.md für bewusst formulierte Regeln und Projektkontext,
- Auto Memory für Learnings aus Korrekturen und Präferenzen,
- Versionierte Projektdateien für absichtlich festgehaltenes Team Wissen,
- Skills für wiederverwendbare Workflows und Domänenwissen.
Zusammen reduzieren sie das tägliche Neu-Briefing massiv.
Die Kehrseite: Direkter Zugriff heißt direkter Schaden
Das CLI gibt dem Agenten unmittelbare Handlungsfähigkeit. Das ist seine Stärke. Und genau deshalb auch sein Risiko.
Ein Agent mit Shell-Zugriff kann Dateien löschen, Prozesse starten, Netzwerke ansprechen, Skripte ausführen. Wenn Prompt Injection oder Untrusted Content bis auf diese Ebene durchschlagen, wird aus einem falschen Bericht sehr schnell eine falsche Aktion.
Darum sind Sandbox, enge Permissions, klare Freigaben und skeptischer Umgang mit Untrusted Content keine Nice-to-haves, sondern Teil der Architektur.
Fazit: Keine Revolution, sondern eine Reifung
Was ich an dieser Evolutionskurve am interessantesten finde: Jede Stufe ist als Reaktion auf einen echten Schmerz entstanden.
| Stufe: | Löst: | Schafft: |
| Agentischer Loop | Passives LLM | Halluzinationen mit Handlungsmacht. veraltetes Wissen |
| Agent Chain | Zuviel Last auf einem Agenten | Fehler-Propagandierung, RAG-Rauschen, Instabilität |
| Agent Graph | Sequenzialität | Merge-Probleme, neues Vertrauensproblem, Prompt Injection |
| MCP | Integrationschaos | Tool-Explosion, Tool-Ambiguität, Sicherheitsfragen |
| Skills | Tägliches Neu-Briefing | Systemisch skalierte Fehllagen |
| CLI | Indirekte Ausführung | Maximaler Balst-Radius bei falscher Aktion |
Spannend daran ist für mich, wie sich die Herausforderungen verschieben: von Modellfehlern zu Koordinationsfehlern, von Koordinationsfehlern zu Integrationskosten, von Integrationskosten zu Vertrauen, Zuständigkeit und Berechtigung.
Und genau da liegt für mich auch der eigentliche Wert unseres Micromata AI Driven Development Hub: Die KI gemeinsam dazu bringen, dass sie uns bestmögliche und vertrauenswürdige Ergebnisse liefert. Cursor, Claude Code und die Tools der globalen Player können heute vieles, was wir damals mühsam selbst zusammengebaut haben.
Mit der Entwicklungsgeschwindigkeit von Anthropic oder Google kann zwar ein kleines Team kaum mithalten, aber das ist auch gar nicht der Punkt. Wichtig ist vielmehr etwas anderes: ein ganz konkretes Verständnis dafür zu entwickeln, warum MCP sinnvoll ist, warum Skills helfen und warum die direkte Ausführung nützlich und zugleich gefährlich ist. Wer Claude Code benutzt, ohne seine Funktionsweise zu verstehen und sinnvoll anzuwenden, hat ein mächtiges Werkzeug in der Hand, aber kein Gefühl dafür, wie es arbeitet und wo es hinführt.
Für uns Entwickler:innen heißt das aus meiner Sicht vor allem eines: Wertvoll ist nicht der Effizienzgewinn allein, sondern das Wissen und die Erfahrung, wann ein plausibel erscheinender Output falsch ist, welche Aufgaben man welchem Tool anvertrauen sollte und wann eine neue Architektur das alte Problem nur verlagert. Menschliche Intelligenz, die im Team besonders stark und in Sachen Weitsicht, Analytik und Verantwortung der künstlichen Intelligenz weiterhin überlegen ist.
Wer die beschriebenen KI-Schichten wirklich verstehen will, sollte deshalb nicht mit der Theorie anfangen. Besser ist es, sich einen kleinen Agenten zu bauen, für einen Workflow, den man gut kennt. Und ihn scheitern zu lassen. Dann zu verstehen, warum er gescheitert ist. Erst dann fühlen sich MCP, Skills und CLI nicht mehr wie Buzzwords an, sondern wie eine wirksame Medizin für sehr konkrete Schmerzen.
Wer kein Entwickler oder keine Entwicklerin ist, sondern jemand, der AI-Projekte auf Managementebene verantwortet: Genauso klein anfangen. Nicht mit „wir automatisieren den gesamten Support-Prozess“, sondern mit einer einzigen, klar abgegrenzten Aufgabe und der Frage, was konkret schiefgehen kann. Wer diese Frage beantworten kann, bevor das System live geht, hat die wichtigste Lektion aus diesem Artikel gelernt.
Quellen & Weiterführendes:
- ReAct: Synergizing Reasoning and Acting in Language Models — Original-Paper zum ReAct-Pattern (Yao et al., ICLR 2023)
- Why Language Models Hallucinate — Original-Paper von OpenAI
- Introducing the Model Context Protocol — Anthropics Einführung in MCP als offenen Standard
- Model Context Protocol Specification — Spezifikation des Protokolls
- Code execution with MCP: Building more efficient agents — Warum große Tool-Landschaften schnell Kontext kosten und wie Code-Ausführung mit MCP den Overhead reduziert
- Connect Claude Code to tools via MCP — Praktische Hinweise und Sicherheitswarnungen für den Einsatz von MCP-Servern in Claude Code
- Security Best Practices for MCP — Angriffsvektoren und Gegenmaßnahmen rund um MCP
- Understanding Authorization in MCP — Einordnung von Autorisierung und Scope in MCP-Umgebungen
- Extend Claude Code — Überblick, wann CLAUDE.md, Skills, MCP, Subagents und Agent Teams sinnvoll sind
- Extend Claude with skills — Aufbau, Ablageorte und Möglichkeiten von Skills in Claude Code
- Agent Skills – Codex — OpenAIs Dokumentation zum offenen Agent-Skills-Format in Codex
- How Claude remembers your project — Zusammenspiel von CLAUDE.md und Auto Memory
- Mitigating the risk of prompt injections in browser use — Warum Prompt Injection für handelnde Agenten ein reales Sicherheitsproblem bleibt
