Was, wenn niemand mehr Software entwickelt? Nicht weil es keine Software mehr gibt. Sondern weil die Software sich selbst entwickelt.
Das klingt nach Science-Fiction. Aber die ersten Beispiele stehen bereits im Raum. OpenClaw zeigt, wie ein agentisches Coding-Framework eigenständig Code schreibt, testet und anpasst. Denk das weiter. Ein Unternehmen wie SAP liefert kein fertiges Produkt mehr aus. Es liefert einen Agenten. Einen fähigen, lernenden Agenten, der sich deinen Anforderungen anpasst. Der eingehende Daten analysiert, Muster erkennt, Funktionen baut, die du noch nicht bestellt hast, weil du noch nicht wusstest, dass du sie brauchst und Fehler behebt, die unterwegs auftreten.
Kein menschlicher Product Owner. Kein Entwicklerteam. Kein Requirements-Analyst. Die Software beobachtet, versteht, baut, testet, liefert aus. An sich selbst. Für dich und dein Unternehmen.
Und jetzt die Frage, die alles verändert: Was passiert mit dem Agilen Manifest, wenn es keinen Entwicklungsprozess mehr gibt, den man agil gestalten könnte?
Das Agile Manifest war ein Emanzipationsdokument. Es befreite Entwickler von Prozessen. Das neue Manifest sollte ein Verantwortungsdokument sein. Menschen befähigen, Verantwortung zu tragen für Systeme, die sich selbst gestalten.
Ein Manifest ohne Adressaten
2001 saßen siebzehn Menschen in einem Skiresort in Utah und schrieben auf, wie Menschen besser Software bauen können. Menschen. Das war die stille Voraussetzung. Das gesamte Manifest richtet sich an Teams aus Fleisch und Blut, die miteinander ringen, kommunizieren, iterieren, reflektieren.
Aber wenn die Software sich selbst schreibt, wer ist dann das Team? Wem gilt das Manifest? Der Maschine?
Das Agile Manifest war eine Antwort auf Knappheit. Code war teuer. Änderungen schmerzhaft. Entwickler überlastet. Jedes der vier Leitsätze und jedes der zwölf Prinzipien reagierte auf diese Reibung. Auf die Schwierigkeit, funktionierende Software in die Welt zu bringen.
Selbstmodifizierende Software kennt diese Knappheit nicht. Sie hat keine Sprints und sie hat keine Releases, weil sie sich ständig “selbst” ausliefert. Sie benötigt keine Retrospektiven, weil sie sich in Echtzeit selbst optimiert. Das Manifest verliert nicht nur seine Gültigkeit. Es verliert seinen Adressaten … den Menschen.
Und trotzdem. Gerade deshalb. Brauchen wir vielleicht solch ein Manifest mehr denn je, nur für andere Zwecke.
Die vier alten Leitsätze und warum sie verdampfen
Individuen und Interaktionen über Prozesse und Werkzeuge.
Wenn das Werkzeug zum Entwickler wird, löst sich diese Unterscheidung auf. Es gibt keine Interaktion zwischen Individuum und Werkzeug mehr. Das Werkzeug ist der Prozess. Es interagiert mit sich selbst. Die Frage ist nicht mehr, ob Menschen wichtiger sind als Werkzeuge. Die Frage ist, ob Menschen überhaupt noch im Raum sind.
Funktionierende Software über umfassende Dokumentation.
Selbstmodifizierende Software funktioniert per Definition. Sie testet sich selbst, repariert sich selbst, optimiert sich selbst. „Es funktioniert” ist kein Qualitätsmerkmal mehr. Es ist der Ausgangszustand. Wie Luft. Immer da, aber kein Grund zur Feier.
Zusammenarbeit mit dem Kunden über Vertragsverhandlung.
Der Kunde arbeitet nicht mehr mit einem Entwicklerteam zusammen. Der Kunde lebt mit der Software. Die Software beobachtet ihn, passt sich an, antizipiert. Die Zusammenarbeit wird zur Koexistenz. Und die Frage wird: Wer führt in dieser Beziehung? Der Mensch, der nutzt? Oder die Software, die formt?
Reagieren auf Veränderung über das Befolgen eines Plans.
Selbstmodifizierende Software reagiert nicht auf Veränderung. Sie ist Veränderung. Permanent. Unaufhaltsam. Es gibt keinen Plan, dem sie folgen könnte, weil sie sich schneller ändert, als ein Plan formuliert werden kann. Flexibilität ist kein Wert mehr. Sie ist der Grundzustand. Und genau das macht sie gefährlich.
Zwölf Prinzipien, zwölf Erschütterungen
Die vier Leitsätze sind nur die Oberfläche. Das Fundament des Agilen Manifests sind die zwölf Prinzipien. Aus ihnen leiten sich die Leitsätze ab, nicht umgekehrt. Und in der Welt selbstmodifizierender Software beben diese Fundamente.
„Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.”
Ein Agent liefert nicht aus, es entwickelt sich ständig. Die Software von heute Morgen ist nicht die Software von heute Abend. „Früh” verliert seine Bedeutung, wenn es kein „spät” mehr gibt. Was bleibt von dem Satz, ist das Wort wertvoll. Und die bange Frage: Wer definiert, was wertvoll ist, wenn ein Agent das selbst entscheidet? Wenn es Features baut, die du nicht bestellt hast, weil eine Datenanalyse ergab, dass du sie brauchst?
Ein Agent erkennt Anforderungen selbst. Aus deinem Verhalten, deinen Daten, deinen Mustern. Dieses Prinzip wird nicht obsolet. Es wird umgestülpt. Nicht du änderst die Anforderungen. Die Software ändert sich, ohne zu fragen. Die neue Herausforderung: Wie sagst du „Nein” zu einer Software, die glaubt, dich besser zu kennen als du dich selbst?
„Heiße Anforderungs-änderungen willkommen.”
„Liefere funktionierende Software regelmäßig innerhalb weniger Wochen.”
Somit mutiert die Software kontinuierlich. Aber der Mensch, der sie nutzt, braucht Stabilität. Braucht Verlässlichkeit und das Gefühl, dass der Boden unter den Füßen nicht ständig wackelt. Der Rhythmus verschiebt sich radikal: nicht vom Entwicklungstakt zum Auslieferungstakt, sondern zum Stabilitätstakt. Wie oft darf sich die Software verändern, ohne dass der Nutzer das Vertrauen verliert?
Es gibt keine Entwickler mehr. Ein Agent ist Entwickler und ein menschlicher Fachexperte und wird zum Domänenwächter. Jemand, der nicht mehr sagt, was gebaut werden soll, sondern überwacht, ob das, was gebaut wurde, fachlich Sinn ergibt. Das ist ein fundamentaler Unterschied. Vom Gestalter zum Wächter.
„Fachexperten und Entwickler müssen täglich zusammenarbeiten.”
„Errichte Projekte rund um motivierte Individuen.”
Wenn Software sich selbst entwickelt, gibt es keine Projekte im klassischen Sinne mehr. Es gibt Systeme, die leben, wachsen und sich verändern. Motivierte Individuen braucht es trotzdem. Aber ihre Motivation muss einer neuen Aufgabe gelten: Grenzen setzen, Richtung geben, Werte definieren. Nicht mehr antreiben, sondern bremsen, wenn nötig.
Agenten kommunizieren über Daten, Logs, Dashboards. Nicht über Worte in Powerpoints. Das menschliche Gespräch befreit sich von der technischen Abstimmung und wird vom Effizienzwerkzeug zum ethischen Raum. Für Fragen wie: Was wollen wir? Wohin soll das führen? Was darf die Software nicht tun, egal wie klug sie ist?
„Die effizienteste Methode, Informationen zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.”
„Funktionierende Software ist das wichtigste Fortschrittsmaß.”
Ein absurder Satz, wenn die Software immer funktioniert. Das neue Fortschrittsmaß kann nur lauten: Dient die Software noch dem Menschen? Nicht: Funktioniert sie? Sondern: Tut sie das Richtige? Für die richtigen Gründe? Mit den richtigen Grenzen? Fortschritt misst sich dann an der Wirkung und an der Abwesenheit von Schaden.
Selbstmodifizierende Software kennt keine Erschöpfung. Aber die Menschen, die mit ihr arbeiten, schon. Die Gefahr heißt jetzt nicht Burnout durch Überarbeitung, sonder Kontrollverlust durch Überforderung. Wenn die Software sich schneller ändert, als du verstehen kannst, was sie tut, dann ist das nicht nachhaltig. Dann ist das ein System, das dir entgleitet. Nachhaltigkeit bedeutet dann: Die Geschwindigkeit der Veränderung muss sich am Menschen messen, nicht an der Maschine.
„Agile Prozesse fördern nachhaltige Entwicklung.”
„Ständiges Augenmerk auf technische Exzellenz und gutes Design.”
Die Frage nach technischer Exzellenz verlagert sich auf eine höhere Ebene: Ist die Architektur der Selbstmodifikation exzellent? Gibt es Sicherheitsgrenzen? Rollback-Mechanismen? Transparenz über Änderungen? Gutes Design bedeutet dann nicht mehr sauberer Code. Es bedeutet: saubere Grenzen. Nachvollziehbare Entscheidungen. Reversible Veränderungen.
Software, die sich selbst modifiziert, mus per se erst einmal keinen Anreiz zur Einfachheit haben. Jedes Problem, das erkannt wird, wird behoben. Jede Optimierungsmöglichkeit ausgeschäpft und durchgeführt. Das Ergebnis: Software, die immer komplexer wird. Sie wuchert wie ein Garten ohne Gärtner. Einfachheit wird vom Designprinzip zum Überlebensprinzip. Nicht nur für die Software auch für den Menschen, der sie noch verstehen und kontrollieren will.
„Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren.”
„Die besten Architekturen entstehen durch selbstorganisierte Teams.”
Das Team ist jetzt ein Agent selbst. Es organisiert sich, optimiert sich, baut sich um. Selbstorganisation im extremen Sinne. Vielleicht aber ohne das Gefühl dafür, wann genug genug ist. Menschliche Selbstorganisation hat ein natürliches Korrektiv: Müdigkeit, Zweifel, Gewissen. Ein Agent hat keines davon.
Ein Agent reflektiert nicht, es optimiert. Das klingt ähnlich, ist aber grundverschieden. Reflexion fragt: Tun wir das Richtige? Optimierung fragt: Tun wir es schnell genug? Reflexion kann zu dem Schluss kommen: Wir sollten aufhören. Optimierung niemals. Die Retrospektive, einst ein Prozesswerkzeug, wird zum einzig menschlichen Gegengewicht zu einer Maschine, die nicht aufhören kann. Jemand sollte regelmäßig fragen: Wohin entwickelt sich das hier? Und wollen wir da hin?
„In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann.”
Drei Muster in den Trümmern
Wenn man die zwölf Verschiebungen nebeneinanderlegt, werden mir Muster klar
Alle Prinzipien, die einst von Bauen, Liefern und Optimieren handelten, drehen sich jetzt um die Frage: Wie setzen wir Grenzen? Wie verhindern wir, dass die Software sich in Richtungen entwickelt, die niemand will? Die kreative Leistung verschiebt sich, da alles möglich wäre, vom Erschaffen zum Eingrenzen. Vom Bildhauer zum Rahmen.
Die Prinzipien über Zusammenarbeit, Kommunikation und Teamorganisation verlieren ihren methodischen Charakter. Sie werden zu Aufsichtsprinzipien. Wie arbeiten wir zusammen spielt keine rolle mehr.
Die Prinzipien über Nachhaltigkeit, Einfachheit und Reflexion waren einst Effizienzprinzipien. Jetzt wandeln sich diese zu ethischen Prinzipien. Denn wenn die Maschine alles kann, ist die einzig relevante Frage nicht mehr „Wie?”, sondern „Dürfen wir das machen?”
Vier neue Leitsätze für eine Welt ohne Entwickler
Aus diesen drei Mustern lassen sich für mich neue Leitsätze verdichten. Sie richten sich nicht mehr an Entwicklerteams. Sie richten sich an alle, die mit selbstmodifizierender Software leben, sie einsetzen oder verantworten.
Menschliche Grenzen über maschinelle Möglichkeiten
Bei einem Agenten der alles bauen kann steht wird die Frage „Können wir das?” irrelevant. Die einzige Frage, die zählt: Sollen wir das?
Grenzen setzen ist keine Schwäche. Es ist die höchste Form von Verantwortung. Ein Garten, in dem alles wächst, ist kein Garten. Er ist Wildnis. Die menschliche Aufgabe in der Welt selbstmodifizierender Software ist nicht, dem Agenten zu sagen, was er tun soll. Sondern was er lassen soll.
Verstandene Wirkung über funktionierenden Code
Wenn Software immer funktioniert ist die Frage: Verstehst du, was diese tut? Und tut diese, was du möchtest?
Selbstmodifizierende Software kann Features bauen, die technisch brillant und menschlich katastrophal sind. Ein Algorithmus, der Kunden automatisch in Preiskategorien sortiert, funktioniert. Aber ist er fair? Ein System, das sich selbst optimiert, um Nutzer länger zu binden, funktioniert. Aber dient es dem Nutzer? Wirkung verstehen heißt: nicht nur prüfen, ob die Software läuft, sondern wohin sie läuft. Und für wen.
Transparente Veränderung über autonome Anpassung
Ein Agent passt sich ständig ohne zu fragen an. Das ist seine Stärke und aber auch die Gefahr. Denn eine Software, die sich im Verborgenen verändert, ist keine Dienstleistung mehr. Sie ist eine Black Box.
Das alte Manifest forderte Zusammenarbeit mit dem Kunden. Das neue muss Transparenz gegenüber dem Nutzer fordern. Jede Veränderung nachvollziehbar. Jede Entscheidung erklärbar. Jede Anpassung sollte reversibel sein. Nicht weil ein Agent unzuverlässig Software entwickelt, sondern weil Vertrauen nur dort wächst, wo Nachvollziehbarkeit herrscht. Autonomie ohne Transparenz ist maximaler Kontrollverlust.
Regelmäßiges Innehalten über permanente Optimierung
Ein Agent hört nie auf und optimiert, verbessert Rund um die Uhr. Ohne Pause und ohne die Frage: Reicht das jetzt?
Genau deshalb braucht es Menschen, die regelmäßig auf die Bremse treten. Die sagen: Stopp, lass uns hinschauen, was hier passiert ist. Lass uns prüfen, ob die Richtung noch stimmt. Die Retrospektive wird vom Teamritual zur Überlebenstechnik. Innehalten ist kein Luxus. Es ist der einzige Schutz vor einem System, das sich selbst genug ist.
Das neue Manifest
Was gerade passiert, ist mehr als eine Aktualisierung. Es ist eine Umkehrung.
Das Agile Manifest von 2001 sagte: Lasst die Menschen machen. Befreit sie von Bürokratie, Kontrolle und starren Plänen. Vertraut ihnen.
Ein neue Manifest muss sagen: Lasst die Menschen regulieren. Befähigt sie zur Kontrolle. Vertraut nicht der Maschine. Vertraut den Menschen, die der Maschine Grenzen setzen.
Denn am Ende geht es nicht darum, ob die Software funktioniert. Auch nicht darum, ob sie sich anpasst. Es geht darum, ob wir noch wissen, wohin sie sich anpasst. Und ob wir das Steuer in der Hand behalten wollen.
Vermessen von mir, dennoch ein Versuch der Orientierung in einer unsicheren Welt:
Menschliche Grenzen über maschinelle Möglichkeiten.
Verstandene Wirkung über funktionierenden Code.
Transparente Veränderung über autonome Anpassung.
Regelmäßiges Innehalten über permanente Optimierung.Das heißt: Obwohl wir die Werte auf der rechten Seite für notwendig halten, schätzen wir die Werte auf der linken Seite als überlebenswichtig ein.
Die Landkarte hat sich nicht nur verändert. Das Gelände bewegt sich jetzt von allein. Der Kompass allein reicht nicht mehr. Wir brauchen einen Anker.