Jenseits des Playbooks: Was Open Source uns über die Softwareentwicklung mit KI-Agenten lehrt
🇬🇧 Read in English~14 min read
ai-agentsagileopen-sourcesoftware-developmentmethodology
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowSave products you love by clicking the heart icon.
Im Mai 2026 veröffentlichte Microsoft Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts) — ein durchdachter, gut begründeter Beitrag, der darlegt, dass prompt-gesteuerte Entwicklung in größerem Maßstab zusammenbricht und dass die Formalisierung der Agenten-Zusammenarbeit durch Spezifikationen, Backlogs und Governance die Lösung ist. Sie stellten ein Template-Repository (MIT-Lizenz) mit CLAUDE.md, STYLE.md, Issue-Vorlagen und einem Fünf-Werte-Manifest open source.
Der Artikel hat mit der Problembeschreibung recht. Prompt-gesteuerte Entwicklung produziert tatsächlich Code, der isoliert funktioniert und bei der Integration bricht. Verhalten driftet tatsächlich über Sitzungen hinweg. Fehler gelangen tatsächlich in die Produktion, wenn es kein Review-Gate gibt.
Doch die Antwort, die Microsoft vorschlägt — eine kodifizierte Methodik mit Templates, Zeremonien und einem Manifest — fühlt sich wie eine Wiederholung von 2001 an. Das ursprüngliche Agile Manifest war ein Aufstand gegen schwergewichtige Prozesse. Agentic-Agile läuft, bei aller echten Einsicht, Gefahr, genau das zu werden, wogegen Agile einst rebellierte: eine als Lösung verkaufte, als Religion übernommene und unabhängig vom Kontext angewandte Methodik.
Die Open-Source-Community, wie üblich, führt längst ein völlig anderes Experiment. Nicht eine Methodik, sondern Dutzende. Nicht ein Template, sondern einen Werkzeugkasten. Nicht Top-down-Adoption, sondern Bottom-up-Evolution. Und während Agentic-Agile noch über seine Werte debattiert, liefert die OSS-Welt seit über einem Jahr Produktionscode mit KI-Agenten aus.
Hier ist, was das Open-Source-Ökosystem tatsächlich über die Softwareentwicklung mit Agenten offenbart — und warum die Unternehmenswelt gut beraten wäre, genau hinzusehen.
Wir wollen anerkennen, wo es gebührt. Die Kern-Diagnose ist solide:
"Der Zusammenbruch passiert, wenn der Scope wächst. Ein Multi-Modul-System. Eine Integrationsschicht mit externen Abhängigkeiten. Ein Feature, das Dateien, Schemas und Verhaltensverträge überspannt."
Die Symptome, die Microsoft aufzählt — kein Backlog, kein Konzept von "Done", keine phasenweise Auslieferung, keine Governance — sind real. Jeder, der versucht hat, etwas Nicht-Triviales mit KI-Agenten zu bauen, erkennt sie sofort. Und das Fazit des Artikels — "Das ist kein Modell-Problem; es ist ein Prozess-Problem" — ist die wichtigste Erkenntnis des gesamten Beitrags.
Wo der Artikel und ich auseinandergehen, ist die Frage, was zu tun ist. Microsoft schlägt eine Methodik vor (Agentic-Agile), ein Template (das GitHub-Repository) und ein Manifest (fünf Werte, dreizehn Prinzipien). Es ist ein sauberes, kohärentes Paket — genau die Art von Ding, die Unternehmen lieben, weil es mandatiert, gemessen und abgegrenzt werden kann.
Aber Softwareentwicklung — insbesondere agenten-unterstützte Entwicklung — funktioniert nicht so. Sie ist unübersichtlich, kontextabhängig und entwickelt sich schneller weiter, als jedes Template mithalten kann.
Während Microsoft sein Manifest verfeinerte, baute die Open-Source-Community. Bis Mitte 2026 war ein reichhaltiges Ökosystem agentischer Entwicklungs-Frameworks entstanden — jedes repräsentiert eine andere Hypothese darüber, wie Menschen und Agenten zusammenarbeiten sollten.
BMAD-METHOD (Breakthrough Method for Agile AI Driven Development, 35k+ GitHub-Sterne) verfolgt einen beaufsichtigten, menschengeführten Ansatz. Es trennt Planung von Ausführung: dedizierte Planungs-Agenten (Analyst, PM, Architect) arbeiten mit dem Menschen zusammen, um detaillierte PRDs und Architektur-Dokumente zu erzeugen. Ein Scrum-Master-Agent verwandelt diese Pläne dann in hyper-detaillierte Development-Stories, die alles enthalten, was der Dev-Agent braucht — voller Kontext, Implementierungsdetails, architektonische Leitlinien — direkt in die Story-Dateien eingebettet. Der Mensch bleibt in jeder Phase in der Schleife. BMADs Erkenntnis: Kontextverlust tötet Agenten-Qualität, also baue Kontext in die Artefakte hinein, nicht um sie herum.
Sprint (von Damien Lainé) verfolgt einen radikal anderen Ansatz. Es läuft als Claude-Code-Plugin — eine spezifikationsgetriebene, selbst-iterierende Zustandsmaschine. Man schreibt Spezifikationen, führt /sprint aus, und der Orchestrator dispatcht spezialisierte Agenten (Architect, Implementation, Testing) durch definierte Phasen und looped autonom, bis die Arbeit erledigt ist oder die Validierung fehlschlägt. Die zentrale Innovation ist das, was der Erfinder "konvergentes Multi-Pass" nennt: Jede Iteration reduziert Rauschen und schärft die Lösung, wie ein Diffusionsprozess. Specs schrumpfen, während die Arbeit fortschreitet. Fehler werden gelöscht. Funktionierender Code bleibt unberührt. Die meisten Sprints konvergieren in unter 5 Iterationen. Sprint ist technologie-agnostisch — während es mit Python/FastAPI- und Next.js-Agenten ausgeliefert wird, passt sich ein allpurpose-agent an jeden Stack an.
AI-Scrum (von Michael Bleterman) mappt Scrum-Rollen auf Google-ADK-Agenten. Ein PM-Agent übersetzt menschliche Eingaben in Sprint-Dateien. Ein Orchestrator-Agent weist Aufgaben nach Rolle zu. Backend/Frontend/DevOps-Agenten führen parallel aus. Ein QA-Agent validiert Outputs in einer Defect-Detection-Schleife. Learnings persistieren zwischen Sprints in einem ChromaDB-Vector-Store — das KI-Äquivalent zu tribalem Wissen. Frühe Ergebnisse zeigen echte Reduktion der Taktzeit bei gut abgegrenzten parallelen Aufgaben, offenbaren aber auch brute Umgebungs-Overhead-Kosten, die auf kleinen Sprints die Token-Budgets dominieren.
AgenticScrum (von safer-strategy) mappt Scrum ebenfalls auf Rollen — ProductOwnerAgent, ScrumMasterAgent, DeveloperAgent, QAAgent, SecurityAuditAgent — hebt sich aber durch "Persona Engineering" ab. Jeder Agent erhält detaillierte Konfiguration: Rolle, Ziel, Backstory, LLM-Konfiguration, Fähigkeiten, Regeln und Wissensquellen. Das Framework enthält eine Setup-CLI, die die gesamte Projektstruktur scaffoldet und grundlegende Regeln sowie Persona-Definitionen generiert. Ein checklisten-getriebener Qualitätsansatz (Definition of Done, Code-Review-Checklisten) sichert Gründlichkeit.
Agentic-PDLC (von Rafael Costa) automatisiert den vollständigen Product Development LifeCycle, sowohl upstream (Ideation) als auch downstream (Delivery), mittels eines Kanban-Boards, das sich selbst bewegt. Wenn du eine Spec freigibst, rückt die Karte vor. Wenn ein Agent einen PR öffnet, rückt die Karte vor. Du musst nur freigeben oder ablehnen. Das Framework stellt ein geteiltes Regelwerk (AGENTS.md) bereit, das jeder Agent liest — Claude, Jules, Gemini — alle ziehen in dieselbe Richtung, ohne Kontext zwischen Tools zu kopieren. Ein CI-Auditor prüft jeden PR auf Architektur-Verletzungen, bevor etwas main erreicht.
AgileCoder (vom FPT-Software-AI4Code-Lab) wählt den akademisch rigorosesten Ansatz. Es "ahmt die reale Softwareentwicklung nach, indem es ein Backlog von Aufgaben erstellt und den Entwicklungsprozess in Sprints unterteilt, wobei das Backlog in jedem Sprint dynamisch aktualisiert wird." Die zentrale Innovation ist Aufgaben-Orientierung statt fester Rollen-Zuweisung — das Gegenteil dessen, wie die meisten Agenten-Frameworks arbeiten. AgileCoder nutzt einen neuen Datensatz namens ProjectDev zur Evaluierung komplexer, realer Software-Anforderungen.
Es gibt mehr. Wilson Kichois agentic_development_workflow definiert ein Fünf-Phasen-Framework (Research → Specification → Task Breakdown → Execution → Verification) mit menschlichen Gates in jeder Phase und persistenten Dokumenten, die über Sitzungen hinweg überleben. Das Agentic Trio (von INNOQs Daniel Westheide) argumentiert, dass kleine Teams aus Product Manager, UX-Designer und Engineer — augmentiert durch Agenten — nun sowohl Discovery als auch Delivery bewältigen können, wobei die Schlüsselrolle des Engineers von der des Produzenten zum "Guardian" wandert, der das Agenten-Harness baut.
Das Bemerkenswerte an all diesen Frameworks ist nicht ihre individuelle Qualität (auch wenn einige wirklich beeindruckend sind). Bemerkenswert ist, dass sich keine von ihnen über Grundlagen einig ist:
Wer nach "dem richtigen Weg" für agentische Entwicklung sucht, wird ihn nicht finden. Was man findet, sind ein Dutzend verschiedener Antworten, jede für einen anderen Kontext optimiert.
Microsofts Agentic-Agile-Template schlägt einen Satz von Dateien (CLAUDE.md, STYLE.md, CONTRIBUTING.md, Issue-Vorlagen) als kodifizierte Methodik vor. Die Open-Source-Community kam unabhängig zu denselben Dateien — aber als Konventionen, nicht als Mandate.
CLAUDE.md entstand als Claude-Code-Konvention. Es verbreitete sich, weil es funktionierte, nicht weil es jemand dekretiert hätte. Dasselbe geschah mit AGENTS.md (von Agentic-PDLC), .claude/project-map.md (von Sprint) und den "Prompt-Dateien", die verschiedene Frameworks autogenerieren. Diese Dateien entstanden organisch, weil Entwickler eine Möglichkeit brauchten, Agenten Projekt-Kontext zu geben, der Sitzungsgrenzen überlebte.
So hat Open Source schon immer funktioniert: Eine Praxis erweist sich in einem Projekt als nützlich, wird von einem anderen kopiert und wird schließlich zur Konvention. Der Unterschied zwischen einer Konvention und einer Methodik ist, dass Konventionen sich weiterentwickeln. Sie werden geforkt. Sie werden adaptiert. Ein CLAUDE.md in einem JavaScript-Monorepo sieht völlig anders aus als in einem Go-Microservice. Das ist ein Feature, kein Bug.
Jedes Framework im Ökosystem bestätigt Microsofts These, dass Specs vor Prompts kommen müssen. Aber keines von ihnen behandelt das Schreiben von Specs als formelle Zeremonie. BMAD baut Specs durch Multi-Agent-Kollaboration. Sprint liest Specs als Markdown-Dateien und iteriert über sie. Wilson Kichois Workflow generiert SPEC.md als persistentes Output-Dokument.
Die Open-Source-Erkenntnis: Specs sind Engineering-Artefakte, keine administrativen Dokumente. Sie leben im Repo, entwickeln sich mit dem Code weiter und sind für dasselbe Publikum geschrieben wie der Code selbst. In dem Moment, in dem das Schreiben von Specs zu einem "Prozess" mit Pflichtfeldern, Review-Gates und Freigaben wird, hört es auf, nützlich zu sein.
Microsoft argumentiert, Agenten sollten als Contributors behandelt werden. Jedes funktionierende Open-Source-Framework tut das standardmäßig — nicht aus Philosophie, sondern weil Agenten als Werkzeuge zu behandeln schlechtere Ergebnisse liefert.
Aber "Agent als Contributor" bedeutet in verschiedenen Kontexten Verschiedenes. In Sprint schreibt der Architect-Agent project-map.md und pflegt es. In BMAD produzieren Planungs-Agenten PRDs, die den gesamten Entwicklungszyklus strukturieren. In AgenticScrum hat jeder Agent eine "Backstory" — einen narrativen Kontext, der sein Verhalten prägt. Die Erkenntnis: Agenten produzieren besseren Output, wenn sie Ownership, Kontext und eine klare Identität haben. Das ist keine Sentimentalität; es ist ein Design-Prinzip, das durch empirische Beobachtung gestützt wird.
Gibt es einen Befund, auf den sich jedes Framework einigt, dann dieser: Agenten-Durchsatz übersteigt die menschliche Review-Kapazität um einen Faktor, der dein Team brechen kann.
Die ZenDevy-2026-Feldeinschätzung sagt es unverblümt: "Wenn die Agenten-Output-Geschwindigkeit die menschliche Review-Geschwindigkeit übersteigt, akkumuliert ungeprüfter Code und wird zu technischen Schulden." Das AI-gile Manifest (ein rollendes Dokument von Elite Software Engineer) warnt: "Ein Team aus einem Menschen und fünf Agenten ohne WIP-Limit bei 'awaiting review' ist ein Team, das technische Schulden in Maschinengeschwindigkeit baut."
Die praktischen Lösungen, die entstanden sind, zielen nicht darauf ab, weniger zu prüfen, sondern die Review-Pipeline zu automatisieren:
Microsoft sagt: "Setze Governance von Tag eins an ins Backlog." Das Open-Source-Ökosystem hat eine nuanciertere Sicht. Governance ist essenziell, muss aber proportional zum Risiko und evolvierbar mit der Reife des Projekts sein.
Agentic-PDLC wählt den explizitesten Ansatz: Sein CI-Auditor prüft jeden PR auf Architektur-Verletzungen. Aber es stellt auch ein "Maturity Model" bereit — Teams starten mit minimalen Gates und fügen mehr hinzu, je mehr sie lernen, wo Agenten gefährlichen Output produzieren.
Die zentrale Erkenntnis: Governance, die blockt, ist destruktiv. Governance, die auffängt und sichtbar macht, ist produktiv. Ein CI-Gate, das einen PR wegen eines Formatierungs-Verstoßes ablehnt, ist keine Governance; es ist Ärgernis. Ein CI-Gate, das sagt "dieser PR führt eine neue Dependency mit bekannter Vulnerability ein — hier ist die Risikobewertung", ist Governance.
Microsofts Agentic-Agile-Template ist gut gemacht. Aber in dem Moment, in dem eine Methodik zu einem Template wird, passieren zwei Dinge. Erstens: Teams übernehmen das Template, ohne zu verstehen, warum es so strukturiert ist. Zweitens: Das Template widersetzt sich der Adaptation — es zu modifizieren fühlt sich wie Abweichen vom "offiziellen" Ansatz an.
Das Open-Source-Ökosystem hingegen baut Frameworks, die zum Forken, Erweitern und Ersetzen gedacht sind. Sprint ermutigt zur Erstellung custom Agenten für deinen Tech-Stack. BMAD bietet Expansion Packs für verschiedene Domänen. Keines von ihnen gibt sich als "der" richtige Weg aus.
Microsofts Methodik ist für Teams konzipiert — mehrere Menschen, mehrere Agenten, parallele Ausführung, Review-Gates. Das ist die richtige Annahme für Enterprise-Entwicklung. Aber ein erheblicher Teil agentischer Entwicklung wird von Solos oder sehr kleinen Teams geleistet.
Für einen Solo-Entwickler sind viele von Agentic-Agiles Empfehlungen (Epic-Decomposition, Wave Planning, Retrospektive Analyse mit Agenten) überkonstruiert. Was sie brauchen, ist einfacher: ein CLAUDE.md, das funktioniert, ein Prozess zum Schreiben von Specs vor Prompts und eine Review-Schleife, die nicht voraussetzt, dass ein weiterer Mensch verfügbar ist.
Die Open-Source-Frameworks erkennen diese Diversität. BMAD umarmt den menschen-beaufsichtigten Solo-Workflow. Sprint automatisiert, was BMAD anleitet. AgenticScrum lässt dich deine Rollen wählen. Diese Flexibilität ist kein Bug des Ökosystems; sie ist der ganze Punkt.
Microsofts Agentic-Agile ist prinzipiell plattform-agnostisch, aber in der Praxis setzt es GitHub, GitHub Issues und GitHub Copilot voraus. Die Issue-Vorlagen zielen auf GitHub. Die copilot-instructions.md-Datei ist GitHub-spezifisch. Der Beispiel-Workflow setzt das PR-Modell von GitHub voraus.
Das ist kein Zynismus — es ist eine echte Blindstelle, die daher rührt, dass man Methodik innerhalb eines Plattform-Unternehmens baut. Das Open-Source-Ökosystem kann diese Annahme definitionsgemäß nicht treffen. Sprint funktioniert in jeder Claude-Code-Umgebung. AGENTS.md ist tool-agnostisch. Die Frameworks, die am besten funktionieren, sind diejenigen, die überall funktionieren.
So gut wie keine der Methodiken — weder Microsofts noch die Open-Source-Varianten — befasst sich ernsthaft mit der Ökonomie agentischer Entwicklung. Die eine Ausnahme ist AI-Scrum, das explizit die brutalen Kosten des Environment-Setups dokumentiert (Paketinstallationen, Playwright-Konfiguration, Pfadauflösung), die auf kleinen Sprints die Token-Budgets dominieren können.
Das ist eine Lücke, die dringlicher wird, nicht weniger. Während stärkere Modelle die Kosten pro Token treiben und Teams ihren Agenten-Einsatz skalieren, wird die Frage, ob ein Framework ökonomisch nachhaltig ist, genauso wichtig wie die, ob es guten Code produziert.
Das Open-Source-Ökosystem hat, ihm zugute gerechnet, begonnen, das anzugehen. Sprints konvergentes Multi-Pass-Modell ist explizit darauf ausgelegt, verschwendete Token zu reduzieren — jede Iteration entfernt Rauschen statt es hinzuzufügen. Wilson Kichois Fünf-Phasen-Workflow segmentiert Kosten über Phasen, sodass du teure Model-Calls nur für die Teile ausgibst, die sie brauchen. Aber das bleibt eine unterschätzte Dimension des Problems.
Wenn man von den einzelnen Frameworks zurücktritt und das Ökosystem als Ganzes betrachtet, emerges ein konsistentes Muster:
Specs vor Prompts — Jeder effektive Workflow beginnt mit geschriebenen Spezifikationen. Nicht um einen Prozess zu befriedigen, sondern weil Agenten besseren Output produzieren, wenn man ihnen strukturierte Verträge gibt.
Kontext-Dateien funktionieren — CLAUDE.md, AGENTS.md und ihre Varianten sind kein Overhead. Sie sind die einzelne Investition mit dem höchsten Hebel, die ein Team machen kann. Sie reduzieren Kontext-Bloat, ermöglichen Session-Kontinuität und lassen Agenten sich verankern, ohne den gesamten Codebase zu scannen.
Review ist der neue Flaschenhals — Agenten-Durchsatz wird menschliche Review immer überholen. Die Lösung ist nicht, schneller zu prüfen, sondern automatisierte Validierungs-Pipelines zu bauen, die das algorithmisch Auffangbare auffangen, damit Menschen das Prüfen können, was zählt.
Einmal passt nicht allen — Solo-Entwickler brauchen andere Prozesse als Enterprise-Teams. Greenfield-Projekte brauchen andere Prozesse als Maintenance. Die Frameworks, die erfolgreich sind, sind diejenigen, die sich an den Kontext anpassen, nicht diejenigen, die ihn vorschreiben.
Die Methodik ist nicht das Produkt — Die Teams, die den besten Code mit KI-Agenten ausliefern, sind nicht die mit den ausgefeiltesten Methodik-Dokumenten. Es sind die, die ein halbes Dutzend Prinzipien verinnerlicht haben (Spec first, Review automatisieren, Kontext erhalten) und sie an ihre spezifischen Constraints adaptiert haben.
Microsofts Agentic-Agile-Artikel ist ein nützlicher Beitrag zu einem wichtigen Gespräch. Er identifiziert korrekt die Failure Modes der prompt-gesteuerten Entwicklung und macht einen überzeugenden Fall für strukturierte Kollaboration. Das Template-Repository ist gut ausgeführt.
Aber der Artikel präsentiert Agentic-Agile als die Antwort, wo das Open-Source-Ökosystem zeigt, dass es keine einzelne Antwort gibt — nur eine Landschaft von Ansätzen, jeder für unterschiedliche Kontexte, Teams und Probleme optimiert.
Das Experiment der Open-Source-Community mit agentischer Entwicklung geht nicht darum, die eine wahre Methodik zu finden. Es geht darum, einen Werkzeugkasten diversifiziert genug zu bauen, dass jedes Team findet, was für es funktioniert, und flexibel genug, dass das Funktionierende sich ändern kann, wenn sich die Technologie weiterentwickelt.
Würde ich das Manifest schreiben, wäre es kürzer als Microsofts fünf Werte und dreizehn Prinzipien. Es käme näher an die vier Werte des AI-gile Manifests — Intent, Validation, Collaboration, Reversibility — oder noch kürzer:
Die Zeremonien, Templates und Frameworks, die diese Prinzipien umgeben, sind Dekoration. Sie helfen, aber sie sind nicht der Punkt. Der Punkt ist, dass die Softwareentwicklung mit KI-Agenten neue Disziplinen erfordert — Disziplinen, die die Open-Source-Community in Echtzeit entdeckt, teilt und weiterentwickelt.
Das Beste, was Microsoft als Nächstes tun könnte, ist nicht, seine Methodik zu verfeinern. Es ist, aus dem Weg zu gehen und genau zuzuhören, was das Ökosystem uns bereits lehrt.
Dieser Artikel ist Teil einer laufenden Serie über KI-gestützte Softwareentwicklung. Die genannten Frameworks sind zur Referenz unten verlinkt: