Ein Tag mit KI-Agenten: Was nachts fertig wird und was liegen bleibt

Heute Morgen um 7:40 lagen sechs fertige Änderungsvorschläge zur Prüfung bereit. Vier habe ich freigegeben, einen zurückgeschickt, einen gelöscht.

Wir betreiben bei Flowhouse ein eigenes System, in dem KI-Agenten nachts Aufgaben abarbeiten. Ein Agent ist dabei ein Programm, das eine Aufgabe eigenständig in Schritte zerlegt und abarbeitet. Was so ein System überhaupt ist, steht in Was ist ein KI-Agent. Dieser Artikel beschreibt einen Tag damit, keine Bauanleitung.

Ich schreibe ihn, weil die Erwartung an solche Systeme meistens in zwei Extremen liegt. Entweder es baut die Firma über Nacht, oder es ist Spielerei. Der Alltag liegt woanders.

17 Uhr: Aufgaben vorbereiten

Der wichtigste Teil des Tages passiert, bevor irgendein Agent startet. Ich schreibe die Aufgaben.

Eine gute Aufgabe für einen Agenten sieht bei uns so aus: Sie hat ein klares Ziel in zwei Sätzen. Sie nennt die Stelle, an der gearbeitet wird. Sie sagt, woran man erkennt, dass sie erledigt ist. Und sie ist klein genug, dass ein Mensch sie in unter zwei Stunden schaffen würde.

Aufgaben, die diese vier Punkte nicht erfüllen, kommen als halbfertiger Vorschlag zurück. Das ist die verlässlichste Regel, die ich zu diesem Thema habe. Die Qualität am Morgen hängt fast vollständig an der Formulierung am Vorabend.

Das Vorbereiten kostet mich 20 bis 40 Minuten pro Abend für vier bis acht Aufgaben. Diese Zeit ist der eigentliche Preis des Systems.

22 Uhr: die Agenten laufen los

Ab dann passiert nichts, was ich beobachte. Jeder Agent bekommt eine Aufgabe, eine eigene Arbeitskopie und ein Zeitlimit. Er darf lesen, schreiben und Tests laufen lassen.

Am Ende legt er einen Änderungsvorschlag zur Freigabe vor. Er darf nichts selbst übernehmen. Diese Grenze ist die wichtigste Sicherung im ganzen System, und sie ist bewusst nicht verhandelbar. Warum wir solche Freigabepunkte grundsätzlich setzen, steht in Human in the Loop.

Zwei weitere Regeln gelten. Erstens: Wenn die Tests rot sind, gibt es keinen Vorschlag. Zweitens: Wenn der Agent nach einer festgelegten Zeit nicht fertig ist, bricht er ab und schreibt auf, wo er hängen geblieben ist. Ein Agent, der zwei Stunden im Kreis läuft, kostet Geld und liefert nichts.

Eine Nacht produziert bei uns vier bis acht Vorschläge. Mehr wäre technisch möglich. Es scheitert nicht an den Agenten, es scheitert an meiner Prüfzeit am Morgen.

7:40 Uhr: prüfen und freigeben

Hier ist der Teil, über den selten jemand spricht. Prüfen kostet echte Zeit.

Ein Vorschlag mittlerer Größe braucht 5 bis 15 Minuten. Bei sechs Vorschlägen sind das rund eine Stunde am Morgen. Diese Stunde verschwindet nicht, egal wie gut das System wird. Ich verschiebe Arbeit vom Schreiben zum Beurteilen.

Was ich beim Prüfen ansehe, in dieser Reihenfolge:

• Löst es die gestellte Aufgabe? Überraschend oft löst der Vorschlag eine ähnliche, aber andere Aufgabe.
• Was hat er sonst noch angefasst? Änderungen an Stellen, die in der Aufgabe nicht vorkamen, sind das häufigste Warnsignal.
• Sind die Tests echt? Ein Test, der nur prüft, dass die Funktion nicht abstürzt, sieht grün aus und misst nichts.
• Verstehe ich es in einer Minute? Wenn nein, geht es zurück. Code, den niemand versteht, ist eine Schuld auf morgen.

Von sechs Vorschlägen gehen bei uns im Schnitt drei bis vier durch, einer geht mit einer Korrekturanweisung zurück, einer wird verworfen.

Was regelmäßig gut klappt

Nach einigen Monaten sehe ich ein klares Muster, welche Aufgaben nachts sauber durchlaufen.

Der gemeinsame Nenner: Es gibt eine eindeutige Rückmeldung, ob die Arbeit richtig war. Wo ein Test oder ein Fehlertext die Antwort liefert, arbeitet ein Agent zuverlässig und ohne Ermüdung. Genau das ist der Grund, warum wir überhaupt eigene Tools bauen.

Was regelmäßig scheitert

Und hier das Gegenteil. Vier Sorten Aufgaben, die bei uns fast immer zurückkommen.

Alles, was eine Entscheidung enthält. Wenn die Aufgabe lautet "finde einen guten Weg, X zu lösen", liefert der Agent einen Weg. Meistens den erstbesten. Er wägt keine Alternativen ab, die er nicht kennt.

Alles, was mehrere Systeme gleichzeitig betrifft. Sobald eine Änderung an drei Stellen zusammenpassen muss, bricht die Trefferquote ein. Der Agent baut zwei Stellen sauber und vergisst die dritte.

Gestaltung. Eine Oberfläche, die funktioniert, entsteht. Eine, die sich richtig anfühlt, entsteht nicht. Abstände, Hierarchie und Ruhe fehlen fast immer.

Alles mit unausgesprochenem Kontext. "So wie wir das sonst machen" steht nirgendwo geschrieben. Was nicht aufgeschrieben ist, existiert für den Agenten nicht. Das ist gleichzeitig der stärkste Nebeneffekt des ganzen Systems: Es zwingt uns, Regeln aufzuschreiben, die vorher nur in Köpfen lagen.

Die Zahlen nach einem halben Jahr

Was das System bringt, lässt sich schwerer messen als bei einer Support-Automation. Trotzdem ein paar belastbare Größen aus unserem Betrieb.

• Die meisten vorgelegten Änderungen werden freigegeben, teils nach Korrektur.
• Der Zeitgewinn liegt bei Routinearbeit deutlich höher als bei neuen Funktionen.
• Meine Arbeit hat sich verschoben: weniger Tippen, mehr Aufgaben formulieren und beurteilen.
• Der Aufwand für Vorbereitung und Prüfung zusammen liegt bei ein bis zwei Stunden pro Tag.

Wichtig dabei: Diese Zahlen gelten für unser eigenes System, an unserem eigenen Code, mit Regeln, die wir über Monate geschrieben haben. Sie sind kein Versprechen für den ersten Monat.

Die Grenzen und die Fehler, die uns passiert sind

Drei Dinge sind schiefgegangen, die ich nicht vorhergesehen habe.

Zu viele Vorschläge auf einmal. In einer Phase liefen zwölf Aufgaben pro Nacht. Am Morgen lagen zehn Vorschläge da, und ich habe ab dem sechsten oberflächlich geprüft. Genau dann ist ein Fehler durchgerutscht. Seitdem gilt eine Obergrenze, die sich an meiner Prüfzeit orientiert und nicht an der Kapazität der Maschine.

Grüne Prüfungen ohne Aussagekraft. Wir hatten einen automatischen Test, der Verlinkungen prüfen sollte. Er lief monatelang grün und hat dabei null Links geprüft, weil er die Seite falsch geladen hat. Ein Test, der nichts findet, sieht genauso aus wie ein Test, der nichts zu finden hat. Beide sind grün.

Plausibel klingender Unsinn. Ein Agent kann eine Begründung schreiben, die stimmig klingt und faktisch falsch ist. Beim Code fällt das durch Tests auf. Bei Texten und Zusammenfassungen fällt es nur auf, wenn jemand es prüft. Warum das passiert, steht in KI-Halluzinationen vermeiden.

Dazu eine Einschränkung, die bleibt: Das System macht gute Entwickler schneller. Es macht niemanden zum Entwickler. Wer den Vorschlag nicht beurteilen kann, gibt ihn entweder blind frei oder gar nicht. Beides ist schlecht.

Fazit

Ein Tag mit KI-Agenten sieht unspektakulär aus. Abends 30 Minuten Aufgaben schreiben, morgens eine Stunde prüfen, dazwischen läuft Arbeit, die sonst tagsüber liegen bliebe.

Der Gewinn liegt in den Aufgaben, die vorher immer verschoben wurden. Tests, Aufräumarbeiten, Aktualisierungen. Nichts davon ist aufregend, und genau deshalb blieb es liegen.

Wenn du so etwas ausprobieren willst, fang bei den Aufgaben an, nicht beim Werkzeug. Schreib eine Woche lang jeden Abend drei Aufgaben so präzise auf, dass ein Fremder sie ohne Rückfrage bearbeiten könnte. Wenn dir das schwerfällt, ist das die eigentliche Baustelle. Wie ein solches Projekt bei uns abläuft, steht in Automatisierungsprojekt: der Ablauf.

Wenn du überlegst, wo KI-Agenten in deinem Betrieb wirklich tragen: Sprich mit uns bei Flowhouse. Wir sagen dir auch, wo ein einfacher Workflow die bessere Antwort ist.