Ein KI-Agent auf dem eigenen Server: was er kann und was er niemals dürfen sollte

Ein Agent, der Ihren Code liest, die Tests ausführt und Änderungen vorschlägt, ist ein guter Kollege. Er ist aber auch ein Programm mit einer Shell. So geben wir ihm das Erste, ohne dass das Zweite aus dem Ruder läuft.

Warum der eigene Server

Ein Coding-Agent braucht drei Dinge: den Code, eine Möglichkeit, ihn auszuführen, und einen Ort für seine Arbeit. All das können Sie bei einem Cloud-Dienst mieten, und für viele Teams ist das die richtige Wahl. Auf dem eigenen Server ist die Sache aber leichter zu überblicken:

• Ihr Code und Ihre Testdaten bleiben, wo sie schon sind;
• der Agent arbeitet nach Regeln, die Sie in einer Datei nachlesen können, nicht auf der Einstellungsseite eines anderen;
• alles, was er tut, hinterlässt Spuren: Dateien auf der Platte, Commits in Git, Zeilen im Log.

Der Server muss nicht groß sein. Das meiste schwere Denken passiert beim Modellanbieter; der Server führt die Werkzeuge, die Tests und Git aus. Eine kleine virtuelle Maschine mit ein paar Gigabyte Arbeitsspeicher reicht für ein Projekt völlig.

Was er gut kann

• Lesen. Er arbeitet sich durch eine große, unbekannte Codebasis und erklärt, was er gefunden hat, schneller, als ein Mensch die Dateien öffnen kann. Bei einem System ohne Dokumentation lohnt sich das Setup allein dafür.
• Die langweiligen Teile. Tests, Datenbankmigrationen, das fünfte Formular, das aussieht wie die anderen vier, die Übersetzungsdatei mit dreihundert Schlüsseln.
• Geduld. Er führt die Tests aus, liest den Fehler, ändert eine Zeile und versucht es erneut, so oft wie nötig, um drei Uhr morgens, ohne zu seufzen.
• Erste Entwürfe. Einen Refactoring-Plan, eine Liste von Risiken, eine Zusammenfassung dessen, was sich zwischen zwei Versionen geändert hat.

Was er niemals tun darf

Bei den folgenden Regeln geht es nicht darum, dass der Agent böswillig wäre. Es geht darum, dass er selbstsicher ist und sich gelegentlich irrt, und das ist in der Nähe von allem, was live ist, eine gefährliche Mischung.

• Produktionsgeheimnisse halten. Keine Passwörter der Live-Datenbank, keine Zahlungsschlüssel, keine Kundendaten. Geben Sie ihm eine Testkopie und einen anonymisierten Dump.
• In den Hauptzweig pushen, deployen oder etwas an Kunden schicken. Seine Arbeit endet bei einem Branch und einem Pull Request.
• Als root arbeiten, oder als der Benutzer, unter dem Ihre Live-Website läuft. Er bekommt einen eigenen Benutzer und kein sudo.
• Entscheiden, wann etwas fertig ist. Ein Mensch schreibt die Aufgabe, und ein Mensch nimmt das Ergebnis ab.

Der Agent schlägt vor. Ein Mensch liest die Änderung, führt sie aus und entscheidet.

Das Setup

Nichts Exotisches: ein eigener Benutzer, ein Projektordner, Git als Sicherheitsnetz.

# ein eigener Benutzer, ohne sudo
sudo useradd --create-home --shell /bin/bash agent

# das Projekt als Klon, den der Agent ändern darf
sudo -u agent git clone git@github.com:you/project.git ~agent/project

# jede Aufgabe auf einem eigenen Branch
git switch -c agent/fix-invoice-rounding

Schützen Sie beim Repository-Hoster den Hauptzweig: Änderungen kommen nur über einen Pull Request mit zustimmender Prüfung hinein. Geben Sie dem Schlüssel oder Token des Agenten das Recht, Branches zu pushen und Pull Requests zu öffnen, und nicht mehr. Wenn er nicht mergen kann, bleibt ein schlechter Nachmittag auf einem Branch.

Eine Regeldatei, die er zuerst liest

Die meisten Coding-Agenten lesen vor dem Start eine Datei im Repository: was das Projekt ist, wie man die Tests ausführt, welche Ordner tabu sind, wie Branches heißen. Halten Sie sie so kurz, dass auch ein Mensch sie liest. Eine gute passt auf einen Bildschirm:

# Projektregeln
- PHP 8.5, kein Composer. Tests: `php tools/run-tests.php`.
- Niemals `config/live.php` oder etwas in `uploads/` ändern.
- Eine Aufgabe, ein Branch, ein Pull Request. Die Änderung in einfachen Worten erklären.

Tests, die mit einem Befehl laufen

Ein Agent ist nur so gut wie die Rückmeldung, die er bekommt. Wenn das Prüfen der Arbeit einen Menschen eine halbe Stunde Klicken kostet, wird der Agent raten. Wenn es ein Befehl ist, prüft er, jedes Mal.

Ein normaler Tag

1. Ein Mensch schreibt die Aufgabe: was es gibt, was sich ändern soll, woran wir erkennen, dass es funktioniert. (Dazu gibt es einen eigenen Ratgeber: Eine Aufgabe so beschreiben, dass kein Entwickler sie missversteht.)
2. Der Agent arbeitet auf seinem Branch, führt die Tests aus und behebt, was sie finden.
3. Er öffnet einen Pull Request mit einer Zusammenfassung in einfachen Worten: was sich geändert hat, warum, und wo er unsicher war.
4. Ein Mensch liest den Diff, probiert ihn auf dem Testserver aus und mergt ihn, oder schickt ihn mit einem Kommentar zurück.

Auf den letzten Schritt kommt es an. Eine Änderung zu prüfen, die man nicht selbst geschrieben hat, ist eine Fähigkeit; sie ist auch der Grund, warum das Setup sicher ist.

Was es kostet, ehrlich gesagt

Der Modellanbieter rechnet nach Nutzung ab, eine volle Woche kostet also mehr als eine ruhige. Der Server kostet, was ein kleiner Server kostet. Der eigentliche Aufwand ist die Prüfung: Ein Mensch muss jede Änderung lesen. Das ist kein Overhead, den man wegoptimiert. Das ist die Arbeit.

Checkliste

• Ein eigener Benutzer ohne sudo und ohne Produktionsgeheimnisse.
• Nur Testdaten: eine Kopie oder ein anonymisierter Dump.
• Jede Aufgabe auf einem Branch; mergen darf nur ein Mensch, durchgesetzt vom Repository-Hoster.
• Tests, die mit einem Befehl laufen.
• Eine kurze Regeldatei im Repository, gelesen vom Agenten und von Menschen.
• Ein Mensch, der die Aufgabe schreibt und das Ergebnis abnimmt.

So arbeiten wir jeden Tag an unseren eigenen Projekten. Wenn Sie das auch auf Ihrem Server möchten, senden Sie uns eine Anfrage.