Wir liefern keine Systeme, die sich selbst verändern
Ein Kunde wünschte sich einen Assistenten, der aus Korrekturen lernt und seine eigenen Anweisungen anpasst. Eine ansprechende Idee, wir haben eine Fassung davon gebaut, und wir liefern sie nicht aus — aus einem Grund, der nichts damit zu tun hat, ob sie funktioniert.
Die Anfrage und der Prototyp
Die Idee ist naheliegend. Korrigiert ein Prüfer eine Extraktion, wird die Korrektur zurückgespeist, damit sich die Anweisung verbessert — und über Monate passt sich das System den Dokumenten des Kunden besser an, ohne dass jemand einen Prompt pflegt.
Wir haben es gebaut. Es funktionierte in dem Sinne, dass die Genauigkeit auf neueren Dokumenten über sechs Wochen stieg. Wir haben es in einer Entwicklungsumgebung betrieben, sonst nirgends, und der Grund für den Stopp steht nicht in den Genauigkeitszahlen.
Die Frage, die es beendet
Welche Version läuft? Bei jedem anderen System ist die Antwort ein Commit-Hash. Bei einem selbstverändernden ist die Antwort die Beschreibung einer Historie — und die Beschreibung einer Historie kann ein Kunde nicht in einen Änderungsnachweis schreiben, ein Prüfer nicht einsehen und ein Entwickler nicht zurückrollen.
Alles Nachgelagerte setzt voraus, dass es eine Version gibt. Unsere Systemdokumente beschreiben Verhalten, unsere Bewertungen bescheinigen einen Zustand, unser Vorfallsprozess kehrt zu einem bekannten guten zurück. Ein System, das seine Anweisungen selbst umschreibt, entwertet alle drei still — ohne dass jemand entschieden hätte, sie aufzugeben.
Die Forschung dazu, wohin es driftet
Han und Kollegen veröffentlichten Ende 2025 eine Arbeit zu einem von ihnen so genannten Kipppunkt der Ausrichtung und untersuchen, wie Selbstentwicklung Agenten im Lauf des Betriebs von ihrem beabsichtigten Verhalten wegtreiben kann.
Das ist ein stärkerer Einwand als unserer und zeigt in dieselbe Richtung. Unsere Sorge ist verwaltungstechnisch und unmittelbar: Niemand kann sagen, was das System heute tut. Ihre ist, dass die Richtung der Drift nicht die beabsichtigte sein muss — dasselbe Problem mit längerer Zeitkonstante.
| Anpassungsmechanismus | Unsere Haltung |
|---|---|
| Prompt schreibt sich aus Korrekturen um | Nein. Keine benennbare Version |
| Korrekturen sammeln, Mensch wendet an | Ja. Das liefern wir aus |
| Retrieval-Index laufend aktualisiert | Ja. Daten, kein Verhalten |
| Vorlieben je Nutzer gespeichert | Ja, mit Grenzen, gesondert beschrieben |
Was wir stattdessen ausliefern
Die Sammelhälfte ohne die Anwendungshälfte. Korrekturen werden gesammelt, gruppiert und monatlich als vorgeschlagene Prompt-Änderung vorgelegt, mit den Fällen, die sie begründen. Eine Person liest, nimmt an oder ab, und die Änderung geht den normalen Deployment-Weg mit Bewertungslauf.
Das fängt den größten Teil des Werts ein. Das Lernen ist real, es landet nur als geprüfte Änderung statt als stille, und die Prüfung kostet rund eine Stunde im Monat. Zwei der letzten zwölf Vorschläge wurden abgelehnt, beide weil das Korrekturmuster die Vorliebe eines Prüfers abbildete und keine Dokumenteigenschaft.
Die Unterscheidung, auf die es ankommt
Dass sich Daten ändern, ist unproblematisch. Unsere Indizes werden laufend aktualisiert, Dokumente kommen hinzu und werden täglich abgelöst, und niemand hält das für ein Versionsproblem — denn das Verhalten liegt fest und die Eingaben schwanken.
Dass sich Verhalten ändert, ist die Grenze. Wenn das, was entscheidet, wie eine Eingabe zu deuten ist, sich von selbst ändert, hat das System keine stabile Beschreibung, und jedes Artefakt, das es beschreibt, wird zum historischen Dokument. Diese Unterscheidung nutzen wir in Entwurfsprüfungen, und sie war leicht anzuwenden.
Was wir Kunden sagen
Dass wir ihnen die Verbesserung ohne die Unvorhersehbarkeit geben können, dass der Preis eine Stunde Aufmerksamkeit im Monat ist, und dass das keine Vorsicht um ihrer selbst willen ist: Derselbe Kunde, der einen selbstverbessernden Assistenten will, ist meist der, dessen Prüfer fragen wird, was das System im März getan hat.
Diese Darstellung hat jeden Kunden überzeugt, der gefragt hat. Niemand will tatsächlich ein System, dessen Verhalten im letzten Quartal nicht rekonstruierbar ist; sie wollen die Verbesserung — und die gibt es mit einem Prüfschritt daran.
Wo wir umdenken würden
Wenn die Anpassung auf etwas beschränkt wäre, das eine Version hat. Eine gelernte Routing-Tabelle, die versioniert, bewertet und wie jedes andere Artefakt ausrollbar ist, ist keine Selbstveränderung in dem Sinne, der uns beunruhigt — auch wenn ihre Werte automatisch entstanden sind.
Die Eigenschaft, die wir brauchen, ist, dass ein Zustand benannt, gespeichert, bewertet und wiederhergestellt werden kann. Jeden Anpassungsmechanismus mit diesen vier Eigenschaften würden wir bauen. Wir lehnen die ab, bei denen der Zustand immer nur der aktuelle ist.
Was wir nicht behaupten
Wir behaupten nicht, selbstverbessernde Systeme könnten nicht funktionieren. Unseres funktionierte in der Entwicklung, und der Genauigkeitstrend war real; es gibt Umgebungen, besonders ohne Prüfpflichten und mit schneller Rückmeldung, in denen der Handel sinnvoll wäre.
Wir behaupten auch nicht, unsere monatliche Prüfung fange alles ein, was eine laufende Schleife fände. Sie ist langsamer und legt einen menschlichen Filter an, der manche echte Verbesserung ablehnt — ein Preis, den wir für ein beschreibbares System annehmen.