Die Werkstatt: Unser Kollege auf WhatsApp
Wir schicken eine Sprachnachricht, und ein Agent auf unserem eigenen Server versteht sie, legt ein Ticket an, schreibt den Code, testet, merged und rollt aus. Danach antwortet er, auf Wunsch ebenfalls per Sprache. Nicht für ein einzelnes Projekt, sondern für alle unsere Repositories. Der spannende Teil ist nicht, was er kann, sondern was er nicht darf.
Ein Kollege, der nie schläft
Viele Wünsche entstehen nicht am Schreibtisch, sondern unterwegs, auf dem Sofa oder beim Kochen: «Der Fenstersensor im Büro soll auch die Storen stoppen.» Früher landeten solche Ideen auf einem Zettel oder gingen vergessen. Heute sprechen wir sie ins Handy.
Dahinter steht Hermes, ein Open-Source-Agent, der auf einer eigenen virtuellen Maschine in unserem Netz läuft. Er hat einen eigenen Benutzer in unserem Git-Server, Zugriff auf Home Assistant und ist über WhatsApp erreichbar.
| Was er kann | Wie es sich anfühlt |
|---|---|
| Versteht Sprachnachrichten auf WhatsApp | Eine Idee in zehn Sekunden festhalten, ohne zu tippen |
| Antwortet auf Wunsch per Sprache | Wie ein kurzes Telefonat mit einem Kollegen |
| Legt Tickets im richtigen Repository an | Er findet das Projekt selbst und fragt nach, wenn es nicht eindeutig ist |
| Bearbeitet Tickets eigenständig | Wir weisen zu, er liefert: Code, Tests, Merge, Release, Deploy |
| Arbeitet in allen Repositories, in denen er Mitglied ist | Firmware, Integrationen, Dokumentation, nicht nur Home Assistant |
| Berichtet in genau einem Kommentar | Umgesetzt, oder eine konkrete Rückfrage |
Der Tag kann so aussehen: Morgens im Zug eine Sprachnachricht mit einer Idee. Hermes legt das Ticket an und bestätigt. Am Abend weisen wir es ihm mit einem Klick zu. Kurz darauf läuft die Änderung, und im Ticket steht, was er gemacht hat.
Wie ein Ticket seinen Weg findet
- SagenSprachnachricht auf WhatsApp, Hermes legt das Ticket an
- ZuweisenEin Klick: Ticket an Hermes
- ArbeitenAgent liest, legt Branch an, ändert Code
- TestenOhne grüne Tests kein Merge
- AusrollenMerge, Release, Deploy
- MeldenEin Kommentar, auf Wunsch Antwort per Sprache
- Wir weisen ein Ticket dem Benutzer
hermeszu. Das ist das Startsignal, sonst nichts. - Ein kleines Skript fragt alle fünf Minuten den Git-Server, ob etwas ansteht. Ohne Treffer endet es sofort.
- Gibt es ein Ticket, heftet das Skript es an, startet die Zeiterfassung und weckt den Agenten.
- Der Agent liest Ticket und Kommentare, legt einen Branch an, ändert den Code und lässt die Tests laufen.
- Sind die Tests grün und ist das Projekt dafür freigegeben, merged er, erstellt ein Release und rollt aus. Bei Home-Assistant-Projekten prüft Home Assistant danach die Konfiguration und startet neu.
- Er hinterlässt genau einen Kommentar: umgesetzt, oder eine konkrete Rückfrage.
- Das Skript stoppt die Zeit und weist das Ticket an uns zurück, auch wenn der Agent abgestürzt ist.
Tickets erfassen wir meist per WhatsApp, oft als Sprachnachricht: «Leg ein Ticket an für die Storen, Fenstersensor Büro.» Hermes löst den Projektnamen selbst auf und legt das Ticket an, aber bewusst ohne Zuweisung. Bearbeitet wird erst, wenn wir es freigeben. So wird aus einer halbfertigen Idee nie versehentlich ein Deploy.
In Repositories, die wir vollständig konfiguriert haben, geht er den ganzen Weg bis zum Ausrollen. In allen anderen, in denen er Mitglied ist, liefert er einen Branch mit einem Vorschlag, den wir selbst prüfen.
Was der Agent nicht darf
Hier steckt die eigentliche Arbeit. Fast jede Regel kam aus einem Fehler oder einem Gedankenexperiment, was schiefgehen könnte.
| Regel | Warum |
|---|---|
| Die Zuordnung von Ticket zu Projekt entscheidet die Shell, nicht das Modell | Was deterministisch sein muss, gehört nicht in eine Wahrscheinlichkeit |
| Merge, Release und Deploy nur in Projekten, die wir bewusst konfiguriert haben | In allen anderen liefert er nur einen Branch zur Prüfung |
| Ohne grüne Tests kein Merge und kein Deploy | Er rollt auf echte Installationen aus |
| Immer nur ein Agent gleichzeitig, ein Ticket pro Lauf | Zwischen zwei Deploys liegt eine Pause, in der auffällt, wenn etwas schiefging |
| Labels wie «wontfix» schlägt er vor, setzt sie aber nicht | Priorisieren ist eine menschliche Entscheidung |
| Das Repository mit seinen eigenen Regeln bearbeitet er nie | Sonst arbeitet er sich selbst unter den Füssen weg |
| Das Zurückweisen erledigt das Skript, nicht der Agent | Ein abgestürztes Ticket würde sonst alle fünf Minuten neu aufgegriffen |
Skills und wie sie synchron bleiben
Die Arbeitsweise des Agenten steht in sogenannten Skills, kurzen Anleitungen pro Projekt. Der Ticket-Ablauf ist dabei nur einmal beschrieben und wird von allen geteilt. Projektspezifisch sind nur zwei Dinge: die Code-Konventionen und das Ausrollen.
Die Konventionen selbst liegen nicht im Skill, sondern als AGENTS.md im jeweiligen Projekt, neben dem Code. Dort werden sie mitgepflegt und veralten nicht. Faustregel für den Inhalt: Hinein gehört, was man dem Code nicht ansieht und wessen Nichtwissen Schaden anrichtet.
Heikel wird es, weil der Agent seine Skills selbst verbessern kann, etwa nachdem er aus einem Fehler gelernt hat. Damit das nicht unbemerkt passiert, gibt es zwei Kontrollpunkte:
- Freigabe: Änderungen an Skills schlägt er vor und schreibt sie erst nach unserer Zustimmung.
- Eigener Branch: Die Maschine arbeitet auf einem eigenen Branch. Ein Skript committet alle 15 Minuten, was der Agent geändert hat, und holt unsere neuen Skills aus dem Hauptbranch herein. Was er an sich selbst geändert hat, sehen wir als Vergleich und übernehmen es oder verwerfen es.
Klemmt die Synchronisation, löst das Skript nichts unbeaufsichtigt auf. Es legt ein Ticket an, einmal pro Störung, und weist es uns zu. Bewusst nicht dem Agenten, sonst würde er seine eigene kaputte Synchronisation als Arbeitsauftrag aufgreifen.
Kosten
Ein Agent, der alle paar Minuten aufwacht, kostet auch dann, wenn nichts zu tun ist. Deshalb sucht das Skript mit einfachen Werkzeugen nach Tickets und weckt das Sprachmodell nur bei Bedarf. Leerläufe kosten nichts. Jeder echte Lauf schreibt Tokens und geschätzte Kosten mit, damit die Modellwahl auf Messwerten beruht statt auf Gefühl.
Was das mit Grossprojekten zu tun hat
Wer in einer Bank gearbeitet hat, erkennt das Muster: Vier-Augen-Prinzip, Change-Prozess, Freigaben, Nachvollziehbarkeit, und die Regel, dass Irreversibles nur in bewusst freigegebenen Bereichen passiert. Nichts davon ist neu. Neu ist, dass man es einer Maschine beibringen muss, und dass es dort genauso nötig ist wie bei Menschen.
Die Erkenntnis
Ein autonomer Agent ist so gut wie die Leitplanken um ihn herum. Die Intelligenz kommt vom Modell, die Verlässlichkeit vom Prozess. Und Prozesse sauber zu entwerfen, ist genau das, was man in zwanzig Jahren Grossprojekten lernt.