Produkt & Entwicklung

04 · Aus der Praxis

Drei Fälle aus dem eigenen Betrieb.

Eine Kennzahl fiel, niemand wusste warum.

Profilnamen ließen sich kaum noch ändern, ohne Fehlermeldung, ohne Ausfall. Der Agent schloss das letzte Release als Ursache aus, ein zweiter durchsuchte parallel die Support-Tickets. Die Ursache lag in einer Konfiguration: Im Verwaltungsbereich waren Sperrmuster mit einzelnen Buchstaben angelegt worden, und weil die Anwendung auf Teilzeichenketten prüft, blockierte ein einzelnes Muster fast jeden Namen. Zwei Stunden nach Beginn der Analyse lief der Dienst wieder, am selben Abend stand eine Sicherung gegen Wiederholung. Drei Agenten-Teams fanden die Ursache gemeinsam, ohne dass jemand ein Meeting einberufen musste.

Manchmal lautet die richtige Antwort: nicht entwickeln.

Nach einem Update häuften sich Fehler beim Bezahlvorgang. Der naheliegende Verdacht war die eigene neue Version. Der Agent schlüsselte die Betroffenen nach Gerät und Betriebssystem auf und fand: Der Großteil lief auf einer Vorabversion des Handy-Betriebssystems, die mit der Bezahl-Bibliothek des Plattformbetreibers nicht zusammenarbeitet. Kein Fehler im eigenen Code, durch eigene Entwicklung nicht behebbar. Ergebnis war kein Entwicklungsticket, sondern ein Antwortentwurf für den Support und die Freigabe, die neue Version vollständig auszurollen.

Ein Loch in der Zahlungsstrecke, das niemand gemeldet hatte.

Fiel bei einem Kunden die Zahlung über den Ausweich-Anbieter aus, blieb er dauerhaft dort hängen. Ein Weg zurück auf den funktionierenden Standardweg existierte nicht. Beschwerden gab es keine, die Betroffenen kauften einfach nicht mehr. Der Agent fand die Lücke beim Nachverfolgen des Zahlungsflusses im Quellcode und schrieb das Ticket bis auf die Umsetzungsebene: die Funktion, an der eingehängt wird, der vorhandene Helfer, der sich wiederverwenden lässt, das zu setzende Feld, die Kennzeichnung für die spätere Überwachung. Drei Entwurfsfragen, die er nicht entscheiden konnte, markierte er als offen. Die Änderung ist ausgeliefert.

06 · Wer entscheidet was

Wer entscheidet was.

Auffälligkeit finden → Ursache eingrenzen → Ticket mit Lösungsvorschlag anlegen → bewerten und priorisieren → Änderung einbauen → freigeben → testen → Wirkung nachmessen

Die hervorgehobenen Schritte liegen beim Menschen. Das ist keine Absichtserklärung, sondern über die vergebenen Rechte gesetzt: Jeder Agent bekommt genau die Rechte, die seine Aufgabe erfordert, und keine darüber hinaus. Wie weit er gehen darf, ist eine Stellschraube, die Sie setzen, pro System und pro Agent, jederzeit in beide Richtungen anpassbar.

Und weil Agenten-Teams sich irren wie Mitarbeitende sich irren, meist nicht im Code, sondern in der Auslegung von Zahlen, prüft eine eigene Instanz jedes Ergebnis gegen. Was dabei auffällt, wird als feste Regel hinterlegt.

08 · Grenzen

Was der Agent ausdrücklich nicht darf.

Er deployt nicht. Kein Zugriff auf Release- oder Konfigurationsvariablen der Produktion, die entsprechenden Aufrufe bekommen eine Zugriffsverweigerung zurück.

Er schreibt keinen Produktivcode ohne Freigabe. Bei uns steht die Stufe auf „bis zum ausgearbeiteten Lösungsvorschlag“. Der Schritt weiter, die Änderung als prüfbaren Merge-Request einzureichen, ist eine Einstellung, kein Projekt. Die Freigabe bleibt in jedem Zuschnitt im Review.

Er priorisiert nicht und entscheidet nicht über Geld oder Personal.

Jede Agenten-Aktion landet mit Zeitstempel im Aktivitätsprotokoll. Jedes maschinell erzeugte Ticket trägt eine Kopfzeile mit dem auslösenden Menschen, das ist im Werkzeug erzwungen.