Lebendige Anwendungen und Ergebnisverträge

Bisher war ein großer Teil der digitalen Welt um die Vorstellung einer relativ festen Anwendung organisiert: spezifiziert, gebaut, ausgeliefert, gepflegt, gepatcht und gelegentlich neu gestaltet. Selbst wenn sie sich kontinuierlich weiterentwickelt, bleibt der begriffliche Schwerpunkt oft eine Codebasis, die Menschen durch regelmäßige Eingriffe verwalten.

Eine neue Klasse von Software könnte sich weniger wie ein fertiges Artefakt und mehr wie ein angeleitetes Lebewesen verhalten. Der Ausgangspunkt ist nicht mehr nur eine statische Produktspezifikation. Es kann ein von Menschen verfasster Ergebnisvertrag sein: Was muss das System erreichen, welche Einschränkungen muss es einhalten, welche Qualitätsschwelle muss es halten und innerhalb welcher Grenzen ist es befugt zu handeln?

Das schafft Softwareentwicklung nicht ab, verändert aber, wo sie ihren Schwerpunkt setzt.

#Der Ergebnisvertrag als operativer Ursprung

Der Ergebnisvertrag formalisiert die Absicht auf der Ebene, die tatsächlich zählt: Ergebnisse, Einschränkungen, Autorität und Bewertung. Statt jeden kleinen Implementierungsweg manuell vorzuschreiben, legt der Mensch fest, was die Anwendung weiterhin erfüllen muss.

Ein agentisches System kann dann auf dieses Ergebnis hin Gerüste bauen, iterieren, testen, vergleichen, überarbeiten und veröffentlichen, sofern es die nötigen Berechtigungen, die Beobachtbarkeit und die Rückmeldekanäle hat. In diesem Modell wird die Anwendung nicht bloß gebaut und gelegentlich gewartet. Sie wird fortlaufend auf die Erfüllung ihres Vertrags hin bewegt.

Das ist eine der Stellen, an denen die agentische Zukunft am deutlichsten über die Vorstellung von KI als reinem Gesprächsassistenten hinausgeht. Hier werden Agenten zu operativen Pflegern, Erbauern, Korrektoren und sich entwickelnden Vermittlern innerhalb der Software selbst.

#Ein konkreter Fall: Die Rechnung, die gültig bleiben muss

Nehmen wir ein kleines Rechnungswerkzeug, das von französischen Selbstständigen genutzt wird. Sein Vertrag passt in einen Satz: Jede von ihm erzeugte Rechnung muss von den staatlich zertifizierten Plattformen akzeptiert werden, über die französische Rechnungen inzwischen laufen müssen. Seit dem 1. September 2026 muss jedes Unternehmen in Frankreich elektronische Rechnungen empfangen können, und ab dem 1. September 2027 müssen auch kleine Unternehmen und Kleinstunternehmen sie ausstellen — in strukturierten oder hybriden Formaten wie Factur-X. Die Nutzenden dieses Werkzeugs sind genau die Menschen, die diese Pflicht spät entdecken werden.

Die Regeln werden nicht unverändert bleiben. Die Verwaltung veröffentlicht Klarstellungen, die Formatspezifikationen erhalten neue Versionen, die Plattformen verschärfen ihre Validierung, und die bei der Einführung angekündigte Toleranzfrist wird irgendwann enden. Im klassischen Modell bemerkt schließlich jemand im Team, dass sich etwas geändert hat, schreibt ein Ticket, und die Korrektur wird mit dem nächsten Release ausgeliefert. Zwischen Änderung und Release werden Rechnungen abgelehnt, und die Nutzenden erfahren es zuerst.

Im Vertragsmodell beobachtet die agentische Schicht die Quellen, die Gültigkeit definieren: die offiziellen Texte, die Formatspezifikationen und die von den Plattformen zurückgesendeten Ablehnungsnachrichten. Eine Rechnung, die aus einem dem System bisher unbekannten Grund abgelehnt wird, ist Drift — eine Lücke zwischen Vertrag und Wirklichkeit. Der Agent verfolgt sie bis zum betroffenen Feld oder zur betroffenen Regel zurück, prüft, welche Rechnungsflüsse betroffen sind, schreibt die Korrektur, führt sie gegen den offiziellen Validator und gegen jede Rechnungsvorlage aus, auf die die Nutzenden angewiesen sind, und öffnet die Änderung zur Prüfung. Ein Mensch genehmigt sie, weil der Vertrag besagt, dass jede Änderung an Steuerregeln eine menschliche Signatur erfordert. Die nächste Rechnung geht durch.

Nichts an dieser Schleife ist exotisch. Neu ist, wo sie beginnt: nicht bei einem Ticket, das jemand geschrieben hat, sondern bei der Distanz zwischen dem, was das System garantieren sollte, und dem, was es tatsächlich getan hat.

Stand der Dinge (Herbst 2026)

Jedes einzelne Element dieser Schleife existiert. Keines davon ist bisher um einen Vertrag herum geschlossen.

Auf der Build-Seite kann seit März 2026 ein Jira-Ticket dem Coding-Agent von GitHub Copilot zugewiesen werden (öffentliche Vorschau): Er liest das Ticket und seine Kommentare, stellt bei Bedarf in Jira Rückfragen und liefert einen Entwurf für einen Pull Request zurück, der die bestehenden Review-Regeln des Teams durchläuft. Auf der Betriebsseite untersucht Datadogs Bits AI SRE Vorfälle selbstständig, bildet Hypothesen zu den Grundursachen und prüft sie anhand von Metriken, Logs und Traces. Automatisierte Abhilfe, etwa ein Rollback oder eine Änderung eines Feature-Flags, ist innerhalb der vom Kunden definierten Leitplanken möglich, obwohl Datadog selbst empfiehlt, dass der Agent im Finanzbereich vorschlägt und der Mensch entscheidet.

Was fehlt, ist der Schritt vor dem Ticket. In beiden Fällen entscheidet noch ein Mensch, dass etwas zu tun ist. Der Agent führt die Arbeit aus; er leitet sie noch nicht aus einem dauerhaft geltenden Ziel ab.

Quellen: GitHub Changelog, „GitHub Copilot coding agent for Jira is now in public preview“, 5. März 2026; Datadog, Ankündigungen auf der DASH 2026 (Bits AI SRE).

#Anatomie einer lebendigen Anwendung

Was braucht der Agent dafür tatsächlich? Weniger, als es scheint. Man gibt ihm fünf Dinge: die Webanwendung selbst, eine E-Mail-Adresse, einen Elastic-Server, Zugriff auf das GitHub-Repository und das Recht, das Modell im Kern der Anwendung neu zu trainieren. Das reicht aus, damit sich die Anwendung unter Aufsicht durch drei Schleifen selbst weiterentwickelt.

Die erste Schleife ist technisch und läuft über Elastic. Jede Anfrage, jeder Fehler, jeder Latenzsprung und jede abgelehnte Rechnung landet in den Logs. Der Agent liest sie kontinuierlich, so wie es eine Bereitschaftsingenieurin oder ein Bereitschaftsingenieur tun würde, wenn die Person niemals schlafen müsste. Er bemerkt, dass die Ablehnungen bei einer Plattform nach einem Format-Update zugenommen haben, dass eine Seite nach dem letzten Deployment langsamer geworden ist oder dass ein Fehler nur bei Nutzenden eines bestimmten Browsers auftritt. Jede Anomalie wird zu einer Hypothese, und jede bestätigte Hypothese wird zu einem Issue im Repository.

Die zweite Schleife läuft über die Nutzenden, über GitHub-Issues und vor allem über E-Mail. Einige Nutzende eröffnen Issues. Die meisten schreiben einfach an die Support-Adresse, in ihren eigenen Worten, oft verärgert und selten präzise. Der Agent antwortet, stellt die fehlende Frage und verwandelt die E-Mail in ein strukturiertes Issue: Was hat die Person versucht, was ist geschehen, um welche Rechnung ging es? Anfragen, die im Grunde dieselbe Beschwerde sind, werden zusammengeführt, sodass ein von vierzig Selbstständigen in vierzig verschiedenen Formulierungen gewünschtes Feature zu einem Issue mit vierzig Stimmen dahinter wird.

Beide Schleifen enden am selben Ort: bei einem Issue, dann bei einem Branch, einer Korrektur, Tests, einem Pull Request und einem Deployment, sofern der Vertrag dies zulässt. Elastic zeigt anschließend, ob die Korrektur tatsächlich funktioniert hat, und schließt damit die Schleife.

Die dritte Schleife geht tiefer. Das Werkzeug nutzt ein Modell, um zu lesen, was eine selbstständige Person tatsächlich tut, und zu entscheiden, welche Mehrwertsteuerregelung gilt und welche Angaben die Rechnung enthalten muss. Jedes Mal, wenn eine nutzende Person eine dieser Entscheidungen per E-Mail oder direkt in der Oberfläche korrigiert, wird die Korrektur zu Trainingsdaten. Sobald genügend davon zusammengekommen sind, trainiert der Agent das Modell neu, bewertet die neue Version anhand eines zurückgehaltenen Satzes verifizierter Rechnungen und schlägt sie nur dann für die Produktion vor, wenn sie besser abschneidet, ohne das bereits Funktionierende zu beschädigen. Die Anwendung verändert dann nicht nur ihren Code, sondern auch die Art, wie sie ihre eigene Domäne versteht. An diesem Punkt ist das Modell keine von außen eingesteckte Ware mehr; es ist selbst Teil der Geschäftslogik geworden. Und es ist der eine Teil, den ein Konkurrent nicht durch Lesen des Codes kopieren kann: Wie bei den Präsenzen im ersten Teil kann man eine Fähigkeit herunterladen, aber keine Gewichte.

Auch hier setzt der Vertrag die Grenzen: Welche Änderungen dürfen selbstständig ausgeliefert werden, welche benötigen eine menschliche Signatur und welche Modellversion darf die Produktion erreichen?

Deshalb ist das ältere Vokabular der „selbstheilenden App“ zu eng. Es geht nicht nur darum, dass Software sich nach einem Defekt selbst repariert. Es geht darum, dass sie fortlaufend aufgebaut, korrigiert, neu ausgerichtet und auf ein von Menschen gesetztes Ziel hin vorangebracht werden kann.

#Die Zukunft der Software als beaufsichtigte Anpassung

Aus all dem ergibt sich ein anderes Bild von Software: ein beaufsichtigter Anpassungsprozess, der sich unter Einschränkungen auf von Menschen festgelegte Ergebnisse zubewegt, ähnlich wie man heute KI-Modelle „heranwachsen“ lässt.

Das könnte eine der tiefsten Folgen des agentischen Übergangs werden. Die Anwendung wird fortlaufend von agentischen Prozessen unter Governance gewartet, korrigiert und weiterentwickelt.

Wer diesen Vertrag schreibt, bleibt offen: ein Unternehmen, ein Team oder, wie das nächste Kapitel nahelegt, die Inhaber eines Tokens.