Die eine Regel, mit der ich AI Agents meine Side Projects anvertraue

An den meisten Abenden ist mein Teil an meinen Side Projects klein. Ein paar AI Agents planen und programmieren, ich gebe frei. Ich lese, was sie verschicken oder mergen wollen, und sage Ja oder Nein. Der Abend ist trotzdem voll.

Diese eine Regel ist der Grund, warum ich sie überhaupt an meine Side Projects lasse. Die andere Hälfte ist Routing. Den Großteil des Tages reichen sie sich die Arbeit ohne mich weiter, und bei mir landet nur, was eine Entscheidung braucht. Hier steht, wo mein Ja sitzt und warum.

Lesen ist frei

Meine Agents dürfen alles lesen, worauf ich ihnen Zugriff gebe. Kalender, Docs, meine X Timeline, Repos. Diese Seite der Regel halte ich so weit wie möglich. Ein Agent, der vor jedem Nachschlagen fragen muss, braucht einen Babysitter, und dann kann ich die Arbeit auch gleich selbst machen.

Lesen macht nichts kaputt, also müssen sie nicht fragen.

Alles, was draußen etwas verändert, wartet auf mich:

• Nichts wird gepostet oder verschickt, bevor ich Ja sage.
• Code landet in einem Pull Request, und auf Merge drücke ich.

Die Grenze lässt sich leicht prüfen. Wenn eine Aktion nur ändert, was der Agent weiß, läuft sie. Wenn sie ändert, was andere sehen, oder Geld betrifft, wartet sie auf mich. Das heißt auch, dass ein Fehler eines Agents bei mir bleibt. Fehlschläge sind der spannende Teil, aber ich finde sie lieber in meiner Freigabe als auf meiner Timeline.

Bisher bedeutet dieser Schritt vor allem kleine Änderungen. Ich passe ein Detail an und sage dann Ja. Einen Fall, in dem ich Nein gesagt habe und froh war, dass es nie rausging, hatte ich noch nicht. Die Vorschläge waren bisher immer gut genug. Den Schritt behalte ich trotzdem, für den Tag, an dem ich ihn brauche.

Logins liegen im Vault

Es liegt nahe, das Ja an die Login Seite zu setzen. Es fühlt sich sicher an, weil ohne einen nichts passiert. In der Praxis heißt das vor allem, dass ein Agent herumsitzt und wartet, während man mit etwas anderem beschäftigt ist.

Bevor es den Vault gab, haben meine Agents keine Logins genutzt. Wenn etwas einen brauchte, habe ich ihn selbst eingegeben. Für mich ist der Vault ein absolutes Quality Gate. Ohne so etwas würde ich Agents gar nicht an Logins lassen.

Meine Agents warten nicht bei jeder Login Seite auf mich. Seit Ende Oktober liegen die Logins in einem Vault, und ein Bot nimmt sie sich dort, wenn eine Aufgabe einen braucht.

Eingeloggt heißt nicht, dass er senden darf.

Zugang und Erlaubnis sind zwei verschiedene Fragen. Der Vault beantwortet die erste, die Regel ganz oben die zweite. Ein Agent kann sich einloggen und lesen, was dort liegt. Alles, was etwas verschicken würde, wartet trotzdem auf mich.

Feste Abläufe, wo es drauf ankommt

Ich baue beruflich Datenpipelines. Am meisten Angst machen mir die grünen Läufe, die still und leise null Datensätze verarbeitet haben. Deshalb mag ich es langweilig und vorhersehbar. Nach jedem Lauf schaue ich als Erstes, ob auf der anderen Seite überhaupt etwas angekommen ist. Eine Zeilenzahl beendet mehr Diskussionen als jedes Review.

Wenn Daten bereinigt werden müssen, stecken die Schritte in einer festen n8n Pipeline. Der Agent schreibt die Skripte zum Bereinigen. Die Pipeline führt sie jedes Mal gleich aus. Der typische Fall sind chaotische CSV Dateien. Der Agent schreibt das Skript, ich lese es durch, und n8n führt es an seiner festen Stelle aus.

Das klingt nach einem Widerspruch zu etwas, das ich vor Kurzem gelernt habe. Wenn ich meinen Agents sage, wie sie etwas machen sollen, klappt das schlechter, als wenn ich sage, was ich will. Schreibe ich die Schritte vor, halten sie sich daran, auch an die schlechten. Für mich stimmt beides. Bei offener Arbeit beschreibe ich das Ziel und lasse den Agent den Weg finden. Bei Daten will ich jedes Mal dieselben Schritte in derselben Reihenfolge, also steht die Reihenfolge in der Pipeline und nicht in einem Prompt. Die meisten Fehlschläge meiner Agents kamen bisher von schlechten Eingabedaten, die niemand geprüft hat. Ein größeres Modell ändert daran nichts. Es scheitert nur selbstbewusster.

Der Agent schreibt die Bausteine. Die Pipeline bestimmt die Reihenfolge.

Wer was an wen weitergibt

Meine Agents haben dasselbe Problem wie jedes Team, in dem ich je war. Die Arbeit wurde erledigt. Nur hat sie niemand richtig übergeben. Das Ergebnis war da, es kam bloß nie beim nächsten Schritt an.

Also habe ich das Team aufgeräumt. Jeder Agent hat eine klare Aufgabe, und es gibt deutlich weniger Regeln. Seitdem arbeiten sie besser. Ein Bot sortiert alles, was reinkommt, und gibt es an den weiter, der es erledigen soll.

Bei meinen Side Projects sind es jetzt zwei Schritte: Ein Agent plant, ein anderer baut. Den Planungsschritt gibt es aus demselben Grund wie bei Menschen. Ein bezahltes Team würde ich auch nie nur mit einer Idee losschicken. Tokens sind billiger als Gehälter, aber Agents bauen schneller, und schneller das Falsche zu bauen hilft niemandem.

Kleinere Aufgaben machen auch das Reparieren leichter. Wenn etwas kaputtgeht, ändere ich einen Agent und beobachte genau diesen einen. Das spart mir am nächsten Morgen viel Detektivarbeit.

Mein Ja sitzt an ein paar Türen. Alles dazwischen läuft von allein.

Wo dein Ja sitzt

Ich glaube nicht, dass mein Setup für alle passt. Lesen ist frei, und alles, was etwas verschickt, wartet auf mein Ja. Für eine Person funktioniert das. Wie es in einem Team aussieht, weiß ich noch nicht. Und ich finde gerade noch heraus, ob eine neue Regel meine Agents wirklich besser macht oder mir nur ein besseres Gefühl gibt.

Deshalb würde ich das gern vor Ort vergleichen. Meine Idee für Köln ist eine Build Night, zu der jeder eine langweilige Aufgabe mitbringt und mit einem Agent nach Hause geht, der sie erledigt. Bisher ist das nur eine Idee, es gibt noch kein Datum und keinen Ort. Dazu würde ich gern eine kleine Session über Freigaberegeln machen, in der wir uns anschauen, wo bei jedem das Ja sitzt. Wenn du mit Agents baust, meine DMs sind offen.

Was würdest du einen Agent nie machen lassen, ohne dass er dich vorher fragt?