Es lebt!

Letzte Woche hatte mein Router ein Problem. Die Verbindung brach ab, alle zehn Minuten. Ich habe das gemacht, was wir alle machen: Neustart. Kabel prüfen. Provider anrufen. Warten. Nochmal neustarten. Drei Stunden meines Lebens für ein Problem, das der Router eigentlich selbst hätte lösen können?

Und genau da fängt diese Geschichte an. Denn was, wenn der Router bemerkt hätte, dass sein DNS-Cache überläuft? Wenn er das Problem erkannt, analysiert, gelöst und mir eine kurze Nachricht geschickt hätte: “Hey, ich hatte ein Problem mit dem DNS-Cache. Ist behoben. Ich habe außerdem bemerkt, dass das bei deiner Konfiguration öfter passieren könnte, und habe die Cache-Größe angepasst.” Drei Stunden gespart. Und beim nächsten Mal passiert es gar nicht erst. Klingt nach Zukunftsmusik? Es ist näher als du denkst.

Software wird lebendig. Nicht als Science Fiction, sondern als Architekturprinzip. Wenn KI-gestützte Agentenframeworks auf Unternehmens-Codebases treffen, entsteht etwas Neues: Software, die sich selbst testet, selbst heilt und durch Fehler besser wird. Antifragile Software-Organismen, die wie Myzel in Organisationen hineinwachsen. ich beleuchte hier, was das für IT-Teams, Führungskräfte, Geschäftsmodelle und die Zukunft der Agilität bedeutet.

Der tote Code

Software, wie wir sie kennen, ist tot. Nicht im Sinne von veraltet oder nutzlos. Tot im biologischen Sinne. Ein ERP-System, eine Banking-App, ein CRM… sie alle teilen eine Eigenschaft mit einem Stein: Sie verändern sich nicht von selbst. Jemand muss kommen, den Stein aufheben, woanders hinlegen, ihn bearbeiten. Ohne menschlichen Eingriff passiert nichts.

Das war jahrzehntelang kein Problem. Es war sogar gewünscht. Determinismus war das höchste Gut der Softwareentwicklung. Gleicher Input, gleicher Output. Immer, bBerechenbar., kontrollierbar und sicher.

Aber die Welt, in der diese Software arbeitet, ist nicht deterministisch. Datenformate ändern sich, Schnittstellen werden aktualisiert, neue Gesetze treten in Kraft und Nutzer verhalten sich anders als gedacht. Und bei jeder Änderung steht ein Mensch auf, öffnet eine Programmierumgebung, schreibt Code, testet, deployed. Und beim nächsten Mal wieder. Und wieder.

Wir haben uns so sehr an dieses Muster gewöhnt, dass wir gar nicht mehr merken, wie absurd es ist. Jedes lebende System auf diesem Planeten kann sich anpassen. Jede Amöbe, jeder Pilz, jede Pflanze… unsere Software braucht einen Chirurgen für jeden Schnupfen.

Ich habe als CTO, Software-Entwickler und als agiler Coach gearbeitet. Ich kenne die Realität in IT-Abteilungen: Montag morgens, das Ticketsystem quillt über. Die Hälfte der Tickets sind Variationen desselben Problems. Eine Schnittstelle hat ihr Datenformat geändert, und zwölf nachgelagerte Systeme kommen damit nicht klar. Zwölf Tickets, zwölf Mal das gleiche Muster, zwölf Mal ein Mensch, der im Code nachschaut, den Parser anpasst, testet, deployed. Und in drei Monaten ändert sich das Format wieder, und das Spiel beginnt von vorn.

Das ist nicht effizient. Das ist nicht agil. Das ist ein Ritual. Und wie viele Rituale hat es mehr mit Gewohnheit zu tun als mit Notwendigkeit.

Vom Samen zum Software-Organismus

Gerade jetzt, wo du diesen Artikel ließt, genau jetzt passiert etwas Neues. Und es passiert schneller, als die meisten ahnen.

KI-Systeme sind bereits heute keine deterministischen Programme mehr. Ein Large Language Model gibt auf die gleiche Frage nicht zweimal die exakt gleiche Antwort. Das ist kein Bug. Das ist eine Eigenschaft, die wir in der Softwarewelt bisher nicht kannten: Variabilität als Designprinzip. Nicht Zufall, nicht Fehler, sondern eine produktive Unschärfe, die Anpassung erst möglich macht.

Und wenn wir diese Eigenschaft mit Agentenframeworks kombinieren… dann entsteht etwas, das ich Software-Organismus nenne.

Die Idee funktioniert so: Ein Softwarehersteller liefert nicht mehr ein fertiges Produkt aus. Er liefert einen Samen. Ein Agentenframework mit einer Codebasis, das auf die Grundfunktionen trainiert ist. Beim Kunden wird dieser Samen eingepflanzt, und dann passiert etwas, das es in der Softwaregeschichte noch nie gab: Das System bekommt die Daten des Unternehmens, seine Schnittstellen, seine Prozesse… und beginnt zu wachsen.

Nicht im Sinne von “es konfiguriert sich selbst”. Das gibt es schon. Sondern im Sinne von: Es lernt, es testet sich selbst, es heilt sich selbst, und es entwickelt sich weiter. Jeden Tag ein bisschen anders. Jeden Tag ein bisschen angepasster an genau dieses Unternehmen.

Wie sieht das praktisch aus? Ein Softwarehersteller… sagen wir Salesforce, SAP, oder ein mittelständischer Anbieter… liefert das Agentenframework mit der Kernfunktionalität aus. Buchhaltung, Lagerverwaltung, Kundendatenbank, was auch immer. Beim Kunden wird der Samen eingepflanzt, und jetzt beginnt die Keimung: Die Unternehmensdaten fließen hinein. Schnittstellen werden angebunden. Importformate definiert. Das System bekommt seinen Boden und beginnt Wurzeln zu schlagen und verdaut die Informationen.

Aber es bleibt nicht bei der ersten Mahlzeit. Ab jetzt beobachtet der Organismus, wie die Mitarbeiter mit ihm arbeiten. Er merkt, welche Berichte jeden Montag gezogen werden. Er erkennt, dass die Buchhaltung im Quartalsabschluss andere Daten braucht als im Tagesgeschäft. Er lernt, dass Frau Müller aus dem Einkauf ihre Bestellungen immer auf eine bestimmte Weise anlegt, die vom Standard abweicht, aber trotzdem funktioniert. Und er passt sich an. Nicht weil jemand ein Customizing-Ticket aufmacht, sondern weil er es beobachtet hat.

Antifragil, nicht nur robust

Hier ist ein entscheidender Unterschied, den viele übersehen.

Robuste Software hält Störungen aus. Sie crasht nicht sofort, wenn etwas Unerwartetes passiert. Das ist nett, aber nicht viel.

Resiliente Software steckt eine Störung weg und kehrt zum Ausgangszustand zurück. Besser, aber immer noch reaktiv.

Antifragile Software… die wird durch Störungen besser. Nassim Taleb hat diesen Begriff für Systeme geprägt, die von Chaos profitieren. Muskeln funktionieren so. Du belastest sie, sie reißen mikroskopisch ein, und sie wachsen stärker nach. Knochen verdichten sich unter Last. Das Immunsystem braucht Krankheitserreger, um zu lernen.

Ein Software-Organismus mit antifragilen Eigenschaften behandelt jeden Bug als Trainingsreiz. Wenn ein Datenformat sich ändert und ein Import fehlschlägt, dann überspringt das System nicht nur den Import. Es erkennt das Muster. Es fragt sich: Wo könnte das gleiche Problem noch auftreten? Welche anderen Schnittstellen nutzen ähnliche Formate? Und es härtet sich präventiv ab.

Ein Beispiel: Ein Lieferant ändert das Format seiner elektronischen Rechnungen (z.B. von XML auf JSON). Im klassischen Szenario bemerkt das jemand am Montagmorgen, wenn der Import fehlschlägt. Ticket wird aufgemacht, Entwickler schaut rein, passt den Parser an, testet, deployed. Zwei Tage Durchlaufzeit, wenn es gut läuft. Im antifragilen Software-Organismus erkennt der Import-Agent den Formatwechsel in Echtzeit. Er analysiert die Struktur des neuen Formats, passt seinen Parser an und importiert die Rechnung. Dann geht er einen Schritt weiter: Er prüft, welche anderen Lieferanten ähnliche Formate verwenden. Und er legt die Erfahrung in seinem Gedächtnis ab, sodass er beim nächsten Formatwechsel noch schneller reagiert und ein Support-Agent dem Nutzer Fragen beantworten kann. Der Montagmorgen? Läuft dann einfach.

Das dreht die gesamte Fehlerkultur um. In der klassischen Softwareentwicklung ist ein Fehler ein Problem. In einem antifragilen Software-Organismus ist ein Fehler Nahrung.

Das Nervensystem

Aber wie funktioniert das konkret? Hier kommen Systeme wie OpenClaw oder Paperclip ins Spiel. Open-Source-Frameworks, die Agenten orchestrieren wie eine Firma ihre Mitarbeiter. Mit Organigramm, Rollen, Budgets und Governance.

Solch ein Software-Organismus besteht nicht aus einem monolithischen KI-Block. Es besteht aus spezialisierten Agenten. Ein CEO-Agent, der Strategie und Prioritäten steuert. Ein Coding-Agent, der Änderungen implementiert. Ein Test-Agent, der alles prüft. Ein Compliance-Agent, der jede Änderung gegen Datenschutzregeln, Tarifverträge und gesetzliche Anforderungen abgleicht. Ein Support-Agent, der mit den Nutzern kommuniziert.

Und jetzt denk das als Nervensystem. Ein Nutzer meldet ein Problem. Der Schmerzreiz kommt rein. Bevor überhaupt ein menschlicher Entwickler davon erfährt, passiert Folgendes:

Der Support-Agent nimmt das Ticket auf. Er prüft: Ist das ein echtes Problem oder ein Bedienungsfehler? Dafür spricht er mit dem Test-Agent, der einen automatischen Selbsttest durchführt:

• Das System funktioniert einwandfrei, der Nutzer hat nur nicht gewusst, wie die Funktion arbeitet. Der Support-Agent antwortet dem Nutzer, erklärt den Weg, begleitet ihn sogar durch den Prozess. Problem gelöst, kein Entwickler nötig.
• Der Test-Agent findet tatsächlich einen Fehler. Der Coding-Agent bekommt ein Ticket, implementiert einen Fix, der Compliance-Agent prüft, ob der Fix keine Regeln verletzt, der Test-Agent verifiziert. Deploy. Alles protokolliert, alles transparent nachvollziehbar, alles in Tickets und Logdateien dokumentiert.

Das passiert reflexartig, genau so als ob du auf eine heiße Herdplatte fasst und die Hand wegziehst, bevor dein Gehirn registriert hat, was passiert ist. Nur dass dieser Reflex gleichzeitig ein Protokoll schreibt.

Und hier kommt eine Ebene dazu, die über reine Selbstheilung hinausgeht: Der Software-Organismus wird lehrend. Wenn der Support-Agent dem Nutzer erklärt, wie eine Funktion funktioniert, und ihn sogar durch den Prozess begleitet, dann repariert das System nicht nur sich selbst. Es bildet seine Umwelt aus. Es bildet seine Nutzer weiter.

Das klingt vielleicht bevormundend. Aber denk an die Alternative: Heute schreibt ein Nutzer ein Ticket, wartet Tage auf Antwort, bekommt eine Standardmail mit einem Link zur Dokumentation und ruft am Ende doch genervt den Helpdesk an. Der Software-Organismus antwortet sofort, versteht den Kontext, kennt die individuelle Nutzungshistorie und kann sagen: “Du hast letzten Mittwoch die gleiche Funktion erfolgreich benutzt, aber mit einem anderen Parameter. Versuch es mal so.” Das ist kein Helpdesk. Das ist ein Kollege, der neben dir sitzt und mitdenkt.

Und das System lernt auch aus dem Support. Wenn fünf verschiedene Nutzer am gleichen Feature scheitern, erkennt der Organismus das Muster. Vielleicht ist nicht der Nutzer das Problem, sondern die Funktion. Dann löst das System kein Support-Ticket aus, sondern ein Verbesserungs-Ticket. Die Oberfläche wird angepasst, der Workflow vereinfacht. Nicht weil ein UX-Researcher eine Studie gemacht hat, sondern weil der Organismus den Schmerz seiner Nutzer gespürt hat.

Myzel

Kennst du Myzel? Das Pilzgeflecht unter dem Waldboden? Mykorrhiza-Pilze verbinden sich mit Baumwurzeln, tauschen Nährstoffe gegen Zucker, und bilden dabei weitläufige unterirdische Netzwerke. Forscher haben dafür den Begriff Wood Wide Web geprägt. Wie weit diese Netzwerke tatsächlich reichen und ob Bäume darüber gezielt Ressourcen teilen, wird in der Wissenschaft gerade intensiv debattiert. Aber eines ist unbestritten: Mykorrhiza-Pilze und Baumwurzeln bilden Symbiosen, die für beide Seiten lebensnotwendig sind. Und sie sind so tief in den Waldboden eingewoben, dass du das Pilzgeflecht nicht entfernen kannst, ohne das Ökosystem zu beschädigen.

Ein Software-Organismus, der zwei Jahre in einem Unternehmen gelebt hat, verhält sich genauso. Er hat sich durch die Abteilungen gearbeitet, die Datenflüsse kennengelernt, die Ausnahmeregeln verinnerlicht, die Workarounds verstanden, die informellen Prozesse abgebildet, die nirgendwo dokumentiert sind, von denen aber alles abhängt. Er ist in die Organisation hineingewachsen wie Wurzeln in Erdreich.

Und das hat eine Konsequenz, die viele noch nicht sehen: Zwei identische Samen, eingepflanzt in zwei verschiedene Unternehmen, sind nach einem Jahr zwei völlig verschiedene Gewächse. Gleicher Samen, anderer Boden, anderes Klima, andere Nährstoffe. Also andere Gestalt, andere Stärken, andere Eigenarten, Stärken und Schwächen.

Das bedeutet: Es gibt aber auch, dass es keine Best Practices mehr gibt. Kein Berater kann sagen “Bei Firma X hat das so funktioniert, machen wir bei euch auch so.” Jeder Software-Organismus ist ein Unikat. Gewachsen, nicht gebaut.

Das hat auch Konsequenzen für die Beratungsindustrie. Die großen Implementierungspartner, die heute davon leben, standardisierte Systeme auszurollen… ihr Geschäftsmodell basiert auf Wiederholbarkeit. Blaupause hier, Blaupause da, Skalierung über Standardisierung. Wenn jeder Software-Organismus ein Unikat ist, funktioniert das nicht mehr. Dann braucht man Begleiter, die den individuellen Organismus verstehen, seine spezifische Wachstumsgeschichte, seine Eigenarten, seine Stärken und Schwächen. Das ist eine andere Art von Beratung. Weniger Folienschlacht, mehr Feldforschung.

Und noch etwas: Myzel funktioniert als lebendes Archiv des Waldbodens. Es durchzieht den Boden über Jahre, passt sich an die lokalen Bedingungen an und trägt die Geschichte seiner Umgebung in seiner Struktur. Der Software-Organismus macht dasselbe. Er trägt die gesamte Organisationsgeschichte in sich. Jede Entscheidung, jedes Muster, jede Ausnahme. Das macht ihn wertvoll. Und es macht ihn unersetzlich. Denn wenn du den Organismus entfernst, entfernst du auch das Gedächtnis.

Was das für Menschen bedeutet

Die Antwort ist unbequem, aber auch befreiend: Die Rolle verschiebt sich vom Mechaniker zum Gärtner. Du reparierst nicht mehr. Du beobachtest, du pflegst, du schneidest zurück wenn nötig, du erkennst Muster. Du sorgst dafür, dass der Organismus gesund bleibt und in die richtige Richtung wächst.

Das verlangt ein fundamental anderes Kompetenzprofil. Heute bilden wir Leute aus, die Systeme bedienen und reparieren. Morgen brauchen wir Menschen, die Systeme erziehen. Menschen, die beobachten statt eingreifen. Die Muster erkennen statt Symptome behandeln. Die Ambiguität aushalten, statt nach dem einen richtigen Konfigurationsparameter zu suchen. Das erfordert eine Bereitschaft, die eigene Rolle neu zu denken. Und das ist selten bequem.

Ich erlebe das in meinen Workshops. Wenn ich mit IT-Teams über die Zukunft ihrer Arbeit spreche, gibt es zwei häufige Muster. Die einen leuchten auf: Endlich Schluss mit dem stumpfen Patchen, endlich nachdenken, gestalten, verstehen. Die anderen werden still. Denn das stumpfe Patchen war auch ein sicherer Hafen. Es war klar, es war messbar, es war jeden Abend erledigt. Einen Organismus zu beobachten und zu verstehen… das ist nie erledigt. Das ist wie Elternschaft. Es hört nicht auf.

Für Unternehmen bedeutet das: Weiterbildung muss sich fundamental verändern. Nicht mehr “Wie bediene ich das Programm” sondern “Wie erkenne ich, ob mein Software-Organismus gesund wächst?” Nicht mehr Zertifizierungen für Produktversionen, sondern Kompetenzen in Systembeobachtung, Mustererkennung und Entscheidung unter Unsicherheit. Weniger Ingenieursausbildung, mehr… ja, systemisches Coaching, wenn man so will.

Was das für Führungskräfte bedeutet

Für einen CIO oder eine Geschäftsführerin bedeutet der Software-Organismus: Du kaufst kein Produkt mehr. Du holst dir ein lebendes System ins Haus. Das ist eine völlig andere Entscheidung.

Die Frage ist nicht mehr “Was kann die Software?” sondern “Was könnte sie werden?” Und, wichtiger noch: “Kann ich damit leben, dass ich das nicht vollständig kontrolliere?”

Das verlangt genau den Wechsel, den viele Organisationen gerade mühsam üben: weg von Unsicherheitsvermeidung, hin zu Unsicherheitsengagement. Wer einen Software-Organismus einsetzt, muss akzeptieren, dass das System Dinge tun wird, die nicht im Pflichtenheft standen. Nicht weil es fehlerhaft ist, sondern weil es gewachsen ist.

Die Rolle der Führungskraft verschiebt sich vom Auftraggeber zum Aufsichtsrat. Du gibst nicht mehr vor, was die Software tun soll. Du setzt Rahmen. Du definierst Grenzen. Du entscheidest, welche Selbstheilung du zulässt und welche nicht. Denn nicht jede Anpassung ist erwünscht. Wenn sich der Organismus selbst optimiert und dabei eine Compliance-Regel verletzt, hast du ein Problem.

Aber auch hier gilt: Der Software-Organismus kann sich selbst überwachen. Ein Compliance-Agent, der jede Veränderung gegen die geltenden Regeln prüft. Automatisch, bei jeder Änderung, rund um die Uhr. Das ist sogar gründlicher als ein menschlicher Compliance-Beauftragter, der morgens Kaffee trinkt und freitags ab 14 Uhr gedanklich im Wochenende ist.

Trotzdem bleibt eine unbequeme Frage: Wer prüft den Compliance-Agent? Wenn ein Coding-Agent eine Änderung macht und ein Compliance-Agent sie absegnet, und beide sind KI-gesteuert… wo ist dann der Mensch? Die Antwort liegt nicht im Kontrollieren jeder einzelnen Entscheidung. Das wäre weder möglich noch sinnvoll. Die Antwort liegt im Setzen von Leitplanken und im Verstehen des Gesamtverhaltens. Es ist der Unterschied zwischen einem Vorgesetzten, der jeden Brief seiner Mitarbeiter gegenliest, und einem, der die Kultur so geprägt hat, dass die Briefe in seinem Sinne geschrieben werden.

Und für Teams ändert sich noch etwas Grundlegendes: Die Grenze zwischen IT-Abteilung und Fachbereich löst sich weiter auf. Wenn der Software-Organismus sich selbst anpasst… wer definiert dann die Anforderungen? Wer testet? Wer nimmt ab? Die klassischen Rollen im Softwareprozess, Projektleitung, Product Owner, Scrum Master, Entwickler:in, Tester:in, verlieren ihre Trennschärfe. Was bleibt, sind Menschen, die den Organismus verstehen und seine Entwicklung in die richtige Richtung lenken. Das sind keine klassischen IT-Rollen mehr. Das sind Organisationsentwickler für digitale Ökosysteme.

Ko-Evolution

Die tiefste Veränderung ist die, über die am wenigsten gesprochen wird.

Bisher war die Beziehung zwischen Menschen und Software eine Einbahnstraße. Wir formen die Software, die Software tut was wir sagen. Punkt. Wenn die Software nicht passt, ändern wir sie. Wenn wir nicht zurechtkommen, gibt es eine Schulung.

Ein Software-Organismus schafft etwas Neues: eine Beziehung auf Gegenseitigkeit. Die Software passt sich an die Nutzungsmuster an. Die Nutzer passen sich an das Verhalten der Software an. Beide verändern sich. Beide lernen. Keiner hat die vollständige Kontrolle.

Das Myzel im Wald ist nicht parasitär. Es nimmt dem Baum nichts weg. Es ist auch nicht altruistisch. Es gibt nicht selbstlos. Die Beziehung ist mutualistisch. Beide Seiten profitieren, beide verändern sich, und nach einer Weile kann keine Seite ohne die andere.

Biologen nennen das Ko-Evolution. Wenn ich es durch die Brille meines Technogenese-Modells betrachte, sehe ich genau das: Die Technologie-Ecke des Dreiecks beginnt, eigenständig auf die Umfeld-Ecke zu reagieren, ohne den Umweg über den Menschen. Der Mensch wird vom Vermittler zum Beobachter einer direkten Kopplung. Das ist qualitativ etwas Neues.

Ein konkretes Beispiel. Eine Einkaufsabteilung nutzt den Software-Organismus seit einem Jahr. Der Organismus hat gelernt, dass Bestellungen bei bestimmten Lieferanten immer in einer bestimmten Reihenfolge abgewickelt werden. Er hat die saisonalen Muster erkannt, die Preisschwankungen, die Lieferzeiten. Jetzt beginnt er, Bestellvorschläge zu machen. Die Einkäuferin gewöhnt sich daran, diese Vorschläge zu prüfen statt selbst zu recherchieren. Ihr Arbeitstag verändert sich. Ihre Kompetenz verlagert sich vom Finden zum Bewerten. Und der Organismus lernt aus ihren Bewertungen und wird besser in seinen Vorschlägen.

Nach zwei Jahren kennt der Organismus den Einkauf dieses Unternehmens besser als jede einzelne Person in der Abteilung. Nicht weil er schlauer ist. Sondern weil er nichts vergisst, keine Urlaube hat und jede Transaktion seit seiner Keimung gesehen hat.

Die Provokation für Entscheider liegt auf der Hand: Du kaufst keine Software mehr. Du gehst eine Beziehung ein. Mit allem, was dazugehört. Vertrauen, Anpassung, gegenseitiges Lernen. Und ja, auch mit dem Risiko, dass sich diese Beziehung in eine Richtung entwickelt, die du nicht vorhergesehen hast. Genau wie bei jeder anderen Beziehung auch.

Wem gehört der Software-Organismus?

Und jetzt die Frage, die zukünftige Rechtsabteilungen klären werden.

Der Softwarehersteller hat den Samen geliefert. Google, OpenAI, Alibaba oder Anthropic haben das Nervensystem bereitgestellt, die KI-Infrastruktur, die dem Organismus das Denken ermöglicht. Aber die Intelligenz, die Anpassungen, das gewachsene Wissen… das stammt aus den Daten und Prozessen des Kunden.

Wem gehört ein Kind? Den Eltern, die es gezeugt haben? Der Schule, die es gebildet hat? Dem Kind selbst?

Das klassische SaaS-Modell, monatliche Gebühr für Software-Zugang, funktioniert hier nicht mehr. Der Wert liegt nicht in der Software selbst, sondern in dem, was sie geworden ist. Und wenn du den Anbieter wechseln willst? Du kannst die Ursprungssoftware kündigen. Aber die zwei Jahre Lerngeschichte, die gewachsenen Strukturen, das tiefe Verständnis für genau dein Unternehmen… das migrierst du nicht mit einer Export-Funktion.

Das ist kein Vendor-Lock-in durch Technik. Das ist ein Co-Abhängigkeit durch Biografie. Und das ist ein völlig neues Problem, für das es noch keine Lösung gibt.

Und noch eine Ebene tiefer: Wenn der Software-Organismus antifragil ist und sich selbst weiterentwickelt, warum sollte er dauerhaft auf einen einzigen LLM-Anbieter angewiesen bleiben? Ein wirklich antifragiler Organismus erkennt auch seine eigene Abhängigkeit als Risiko. Heute nutzt er Claude für komplexe Analysen, morgen Gemini für multimodale Aufgaben, übermorgen ein lokales Open-Source-Modell für datenschutzkritische Prozesse. Der Organismus wählt selbst, welche Intelligenz es für welche Aufgabe anzapft.

Die großen KI-Anbieter werden in diesem Szenario zu dem, was Stromversorger für Fabriken sind: unverzichtbare Infrastruktur, aber austauschbar. OpenAI, Anthropic, Google… sie verdienen nicht mehr an einem Produkt, sondern daran, dass Millionen von Software-Organismen ihre API atmen. Token-basierte Abrechnung, multipliziert mit einem Ökosystem, das ständig denkt. Das ist ein gewaltiges Geschäft. Aber es ist kein Produkt-Geschäft mehr. Es ist ein Utility-Geschäft.

Agilität wird Biologie

Das Agile Manifest war für Menschen geschrieben. “Individuals and interactions over processes and tools.” Wunderschön. Aber der Software-Organismus ist agil, ohne ein Manifest zu brauchen. Er braucht keine Retrospektive, um zu reflektieren. Er reflektiert bei jedem Fehler. Er braucht kein Daily, um sich zu synchronisieren. Seine Agenten kommunizieren kontinuierlich. Anpassungsfähigkeit ist keine Haltung mehr. Sie ist Architektur.

Und die agilen Coaches? Deren Zukunft liegt vielleicht genau hier: nicht mehr Teams coachen, sondern Software-Organismen coachen. Systemische Beobachtung, Mustererkennung, Interventionen setzen. Der Klient hat sich verändert, aber die Kompetenz bleibt dieselbe.

Ich sage das als jemand, der wie gesagt beide Seiten kennt. Als jemand, der Software gebaut hat und als systemischer Coach der Organisationen begleitet. Die Fähigkeiten, die ich in der systemischen Arbeit gelernt habe… Beobachten ohne sofort einzugreifen, zirkuläre Fragen stellen, Muster statt Symptome adressieren, Hypothesen bilden statt Diagnosen stellen… das dürften genau die Fähigkeiten sein, die gebraucht werden, um einen Software-Organismus zu betreuen und zu unterstützen.

Und die Ironie ist fast zu schön: Die Softwarebranche hat jahrelang auf die “weichen” Kompetenzen herabgeschaut. Und jetzt könnte sich heraus stellen, dass genau diese Kompetenzen den Unterschied machen werden.

Der Stressor-Designer

Wenn antifragile Software Störungen als Nahrung braucht, dann entsteht eine völlig neue Rolle: der Stressor-Designer. Jemand, der weiß, welche Fehler die Software braucht, um besser zu werden. Jemand, der gezielt Chaos einführt, nicht um zu zerstören, sondern um zu stärken.

Netflix hat das Prinzip mit seinem “Chaos Monkey” schon vor Jahren angewandt: ein Open-Source-Tool, das absichtlich laufende Cloud-Instanzen terminiert, um die Resilienz des Gesamtsystems zu testen. Der Stressor-Designer geht weiter. Er testet nicht nur, ob das System überlebt. Er provoziert Situationen, die das System klüger machen.

Was passiert, wenn sich ein Datenformat ändert? Was passiert, wenn eine Schnittstelle für zwei Stunden nicht erreichbar ist? Was passiert, wenn tausend Nutzer gleichzeitig dieselbe Funktion aufrufen? Was passiert, wenn widersprüchliche Datensätze eingespeist werden? Jedes dieser Szenarien ist ein Trainingsreiz. Und der Stressor-Designer weiß, welche Trainingsreize den Organismus in welcher Wachstumsphase braucht. Zu viel Stress zu früh, und der Organismus kollabiert. Zu wenig, und er verkümmert.

Das erfordert ein tiefes Verständnis des Systems. Nicht im Sinne von “ich kenne den Code”. Sondern im Sinne von “ich verstehe den Organismus”. Sein Temperament, seine Schwachstellen, seine Wachstumsmuster. Das ist weniger Informatik und mehr Biologie. Weniger Engineering und mehr Ökologie.

Die Pointe: Der beste Softwareentwickler der Zukunft ist nicht der, der die wenigsten Fehler macht. Es ist der, der die besten Fehler provoziert.

Was bleibt?

Software wir “lebend”. Noch nicht überall, noch nicht vollständig, aber die Richtung ist klar. Wir bewegen uns von Kaufen zu Aufziehen. Von Installieren zu Einpflanzen. Von Konfigurieren zu Erziehen. Von Reparieren zu Pflegen.

Das klingt nach Science Fiction? Frameworks wie OpenClaw und Paperclip existieren heute und sind wegweisend. Open Source, MIT-lizenziert, ein Terminal-Befehl zum Starten. Die Agenten sind da. Die Orchestrierung ist da. Die KI-Modelle sind da. Die Frage ist nicht mehr ob, sondern wann. Und vor allem: Wer ist vorbereitet?

Nicht technisch…Technisch ist das lösbar. Was fehlt, ist das Bewusstsein, dass wir an einer Schwelle stehen. Die Schwelle, an der Software aufhört, ein Werkzeug zu sein, und anfängt, ein Gegenüber zu werden. Ein Gegenüber, das lernt, wächst, sich anpasst und irgendwann Dinge weiß, die wir ihm nie beigebracht haben. Weil es sie sich selbst beigebracht hat. Aus unseren Daten, unseren Prozessen, unseren Fehlern.

Die Unternehmen, die das früh verstehen, werden einen Vorteil haben, der sich nicht kopieren lässt. Weil ihr Software-Organismus ein Unikat ist, gewachsen aus genau ihrer Geschichte. Und die, die zu spät kommen? Die werden erleben, wie es sich anfühlt, gegen einen Wald anzutreten, während man selbst noch Setzlinge in Töpfen stehen hat.

Ob wir das wollen oder nicht: Die Evolution hat die Software erreicht. Der Wald wächst. Und das Myzel darunter verbindet schon längst Dinge, die wir für getrennt hielten.

Erste Erscheinungen von antifragilen Software-Organismen

Hier zwei (in 2026) aktuelle Frameworks, die als erste antifragile Software-Organismen angesehen werden könnten und sich hinsichtlich Nutzerverhalten anpassen können…