Das Release, das heute Morgen ausgeliefert wurde, hat längst mitgeteilt, was damit nicht stimmt – den ganzen Tag schon, über mehrere Kanäle: in Logs, Traces, Session-Replays, Support-Tickets und Produktkennzahlen. Mit diesem Bild beginnt Boris Tane seinen Blogbeitrag vom 10. Oktober, und er zieht daraus eine zugespitzte Folgerung: Der einzige Grund, warum die Produktion noch immer Fehler hat, sei der Mensch, der diese Signale lesen, sortieren und an einen Coding-Agenten weiterreichen muss.
Tane kennt das Problem von innen. Er hat den größten Teil des vergangenen Jahrzehnts Observability-Werkzeuge gebaut und arbeitet heute an einem eigenen Produkt namens Polylane. Seine These: Selbstverbessernde Software ist unvermeidlich – Anwendungen, die ihre eigenen Signale lesen, entscheiden, was sich ändern soll, die Änderung ausliefern und prüfen, ob sie gewirkt hat. Zum ersten Mal, schreibt er, sei das nah genug, um es zu bauen.
Du erkennst die Kette wahrscheinlich wieder: Irgendwo fällt ein Fehler auf, irgendwer korreliert ihn mit anderen Beobachtungen, daraus wird ein Ticket, und am Ende promptet jemand einen Agenten, der daraus Code macht. Zwischen den Maschinen, die das Problem erzeugen, und den Maschinen, die es beheben könnten, steht ein Mensch als Übersetzer. Genau diese Rolle gerät jetzt unter Druck.
Der Feedback-Loop hat heute einen Menschen in der Mitte
Jede Signalquelle hat ihr eigenes Werkzeug und ihre eigene Zielgruppe. Ingenieure und SREs schauen in Observability-Plattformen wie Datadog, Produktmanager in Analytics-Tools wie Amplitude, Designer in Session-Replays wie FullStory, der Support in Zendesk. Wenn Nutzer in der Produktion auf Probleme stoßen, verteilt sich dieselbe Ursache über alle diese Systeme: Der Fehler landet im Tracing, der wütende Doppelklick im Replay, die Kennzahl sinkt im Dashboard, die Ticketzahl steigt im Helpdesk.
Niemand sieht das automatisch zusammen. Es braucht eine Person, die diese Beobachtungen bemerkt, sie gegeneinander legt, sie zu einer Beschreibung verdichtet und daraus eine Priorität ableitet. Erst danach beginnt die eigentliche Arbeit: Ein Ingenieur nimmt das Ticket, beschreibt das Problem einem Agenten und lässt sich den Fix generieren. Tane nennt das eine Umleitung, die keinen Sinn ergibt. Agenten lösen heute einige der schwersten Mathematikprobleme, vor denen die Menschheit je stand, aber das Sortieren von Fehlermeldungen hängt weiter an einem Menschen mit Zugriffsrechten auf fünf Dashboards.
Was ein „Meat Proxy“ ist
Für diese Zwischenrolle hat der Beitrag einen Begriff: Meat Proxy. Gemeint ist ein Mensch, dessen einzige Funktion darin besteht, Information zwischen zwei Maschinen zu tragen, die problemlos selbst miteinander reden könnten. Der Test ist einfach. Wenn du einen Screenshot von deinem Analytics-Dashboard machst, ihn in einen Coding-Agenten einfügst und schreibst, er soll untersuchen, warum diese Kurve fällt, und es beheben, dann bist du der Proxy. Das Dashboard hat die Daten, der Agent hat die Intelligenz, und du entscheidest, wann welcher Ausschnitt den Weg von A nach B nimmt.
MCP-Server und Connectors machen diesen Transport schneller, aber sie heben ihn nicht auf. Sie automatisieren das Kopieren, nicht das Auswählen. Welche Kennzahl überhaupt relevant ist, welcher Zeitraum betrachtet wird und wie das Problem in Worte gefasst wird — diese Entscheidungen bleiben beim Menschen. In dieser Auswahl steckt die eigentliche Arbeit, und genau dort geht Information verloren, weil niemand alle Signale gleichzeitig im Kopf halten kann.
Automatisierung kennt nur die Probleme, die schon jemand definiert hat
Der naheliegende Einwand lautet: Dann automatisiere den Proxy doch einfach. Tatsächlich gibt es reichlich Werkzeuge, die genau das versprechen, meist als Kombination aus Cronjob, Webhook und Prompt. Tane beschreibt, selbst so etwas gebaut zu haben: Jeder neue Fehler aus dem Error-Tracking wird untersucht und mündet in einen Pull Request, jede Warnung aus der Observability bekommt eine Analyse, bevor irgendwer seinen Laptop aufklappt. Das fühlt sich produktiv an, bis zu einem Punkt.
Denn solche Automatisierungen sehen nur, was jemand vorher für sehenswert erklärt hat. Sie erben sämtliche blinden Flecken des Systems, das sie auslöst. Irgendwer musste festlegen, auf welche Metrik alarmiert wird und welche Service-Level-Objectives gelten, und diese Festlegung ist zwangsläufig unvollständig. Das ist das Problem der unbekannten Unbekannten: Bekannte Fehler werden erkannt, weil jemand eine Regel dafür geschrieben hat. Unbekannte Fehler werden nie erkannt, weil nichts existiert, was sie erkennen könnte. Automatisierung in der Softwareentwicklung mit KI ist an dieser Stelle angekommen: Die Werkzeuge sind da, sie greifen nur zu kurz. Der Agent wird schnell darin, die Probleme zu beheben, die du ohnehin schon finden konntest. Die Probleme, die dich die meisten Kunden kosten, sind per Definition die anderen.
Software braucht Backpropagation
Hier hilft eine Analogie, die der Beitrag durchhält: Betrachte ein Stück Software wie ein neuronales Netz. Der Code sind die Gewichte und Schwellenwerte, jede Änderung daran ein Update dieser Gewichte. Nutzer interagieren damit, und was dabei entsteht — Traces, Klicks, Tickets, Kündigungen, Umsatz — ist die Ausgabe. Aus dieser Sicht zerfällt selbstverbessernde Software in zwei Phasen, und beide verhalten sich sehr unterschiedlich.
Die erste Phase ist der Vorwärtsdurchlauf: Absicht hinein, Code heraus. Diesen Teil haben Coding-Agenten weitgehend gelöst. Man kann heute eine recht komplexe Anwendung mit einem einzigen Prompt erzeugen, deployen und dabei Observability sowie Produkt-Tracking gleich mitverdrahten. Die zweite Phase ist die Backpropagation: die Ausgabe mit dem vergleichen, was man eigentlich wollte, die Lücke berechnen und sie durch das System zurückschieben, um die Gewichte anzupassen. Für eine Anwendung heißt das, alle Signale aus der Produktion zu lesen, sie auf den Code zu beziehen und diesen Code entsprechend zu ändern. Software, die sich selbst durch ihre eigenen Signale verbessert, entsteht genau hier.
Der Vorwärtsdurchlauf ist automatisiert, die Backpropagation läuft von Hand. Wöchentlich werden Dutzende Gewichts-Updates nach Produktion geschoben, aber der Gradient wird in einem Planungsmeeting berechnet — wenn es gut läuft wöchentlich, in manchen Unternehmen quartalsweise. Grundlage sind die Erinnerung der Produktmanager, eine Stichprobe von zwanzig Session-Aufzeichnungen und die drei lautesten Beschwerden. Würde man neuronale Netze so trainieren, käme nichts Brauchbares heraus.
Intelligenz ist billig, Fitness-Funktionen sind es nicht
Der Grund, warum die Backpropagation so lange manuell blieb, war ein Knappheitsproblem. Um einen Fehlerbericht zu lesen, die passenden Traces zu finden, sie mit Replays abzugleichen, die Wut eines Kunden zu verstehen und daraus eine Änderung abzuleiten, brauchte es Urteilsvermögen — und gutes Urteilsvermögen war teuer und rar. Diese Knappheit löst sich gerade auf. Intelligenz ist mittlerweile so billig, dass man sie nicht mehr abzählen muss: Sie kann jede Trace lesen, jede Sitzung ansehen, jedes Ticket und jedes Interviewtranskript auswerten und das alles in Minuten zusammenführen.
Was dadurch nicht billig wird, ist die Frage, woraufhin optimiert werden soll. Ein neuronales Netz ohne Verlustfunktion ist ein sehr teurer Zufallsgenerator. Die Backpropagation muss wissen, was „besser“ bedeutet, und diese Definition kann niemand an das System delegieren. Nach Einschätzung von Tane verschiebt sich die Aufgabe aller Beteiligten genau dorthin: Ingenieure, Produktmanager, Designer, Vertrieb und Support definieren die Fitness-Funktionen, gegen die das System optimiert. Der Beitrag ordnet das in einer Übersicht zu, die sich gut als Merkliste lesen lässt.
| Rolle | Worauf optimiert wird | Beispielhafte Fitness-Funktionen |
|---|---|---|
| Ingenieurwesen | die Gesundheit des Systems | p99-Latenz, Fehlerraten, Verfügbarkeit, Kosten pro Anfrage, Kaltstartzeiten |
| Produkt | das Verhalten der Nutzer | Conversion, Aktivierung, Retention, Time to Value, Feature-Adoption |
| Design | die Nutzererfahrung | Aufgabenabschluss, Zeit pro Aufgabe, Rage Clicks, Abbrüche, verworfene Formulare |
| Vertrieb | Umsatz | Wachstum, Gewinnquoten, Expansion, Deal-Geschwindigkeit, Churn |
| Support | wie stark das Produkt weh tut | Ticketvolumen, Zeit bis zur Lösung, CSAT, doppelte Tickets |
Die Schwierigkeit liegt weniger im Aufschreiben als im Abwägen. Diese Funktionen arbeiten gegeneinander: Ein schnellerer Checkout kann die Betrugserkennung schwächen, ein einfacheres Onboarding kann die Aktivierung von Power-Usern senken, ein Rabatt hebt den Umsatz und drückt die Marge. Zu entscheiden, wie stark jede Größe gewichtet wird, welche davon harte Nebenbedingungen sind und für welche Kunden man überhaupt optimiert, ist die eigentliche Arbeit. Im Kern ist es die Frage, was das Unternehmen erreichen will — präzise genug formuliert, dass eine Maschine darauf optimieren kann. Tane merkt an, dass genau das schon immer der schwierige Teil war.
Zwei Schleifen, ein Zeitplan
Was daraus konkret folgt, lässt sich in wenigen Zeilen beschreiben. Man gibt einem Cloud-Coding-Agenten Lesezugriff auf alle Signalquellen gleichzeitig — Observability, Produktanalytik, Session-Replays, Support-Tickets — und Schreibzugriff auf das Repository. Dann legt man das auf einen Zeitplan. Stündlich liest der Agent jeden neuen Fehler, jede Trace, jedes Replay und jedes Ticket der letzten Stunde, gruppiert, was nach demselben Problem aussieht, auch wenn es in verschiedenen Werkzeugen auftaucht, findet das Release, das es eingeführt hat, und öffnet einen Pull Request mit Fix und Belegen.
Täglich vergleicht derselbe Mechanismus den Vortag mit den vereinbarten Zielen: p99-Latenz im Checkout unter 300 Millisekunden, Fehlerrate unter 0,1 Prozent, Aktivierung über 25 Prozent, weniger als zwanzig Support-Tickets pro Tag. Für alles, was sich in die falsche Richtung bewegt, sucht er die Ursache im Code und öffnet einen Pull Request. Läuft alles im Rahmen, sucht er die Änderung, die diese Zahlen am wahrscheinlichsten als Nächstes bewegt — und öffnet auch dafür einen Pull Request. Observability und automatische Fehlerbehebung rücken damit so eng zusammen, dass die Grenze zwischen Beobachten und Handeln verschwindet.
Und sobald Software sich selbst verbessern kann, so Tane, kann sie auch die Maschinerie verbessern, die sie verbessert: bessere Observability, schärfere Erkennung, gründlichere Untersuchungen, bessere Fixes, jede Schleife zieht die nächste enger. Dafür müssten wir allerdings aufgeben, selbst das Steuer zu halten.
Das ist keine Zukunftsmusik, sondern eine Architektur, die sich mit heutigen Bausteinen zusammensetzen lässt. Tane baut mit Polylane genau daran, weil für ihn alle Software selbstverbessernd sein sollte. Für dich bedeutet das weniger, dass du morgen ersetzt wirst, und mehr, dass sich deine Arbeit verschiebt. Weniger Signale einsammeln, weniger Tickets sortieren, weniger Screenshots in Chatfenster kleben. Dafür mehr Klarheit darüber, was „besser“ überhaupt heißt, welche Nebenbedingungen unverhandelbar sind und welchen Teil des Systems du bewusst nicht optimieren lässt. Selbstverbessernde Software ist unvermeidlich — aber sie optimiert nur gegen das, was du ihr vorher gesagt hast.
Quelle: boristane.com
