Was wir einen Agenten in unseren eigenen Repositories anfassen lassen
Unser Agent öffnet Pull Requests und kann sie nicht mergen, führt Tests aus und kann die Pipeline nicht ändern, liest jede Datei und schreibt in eine kurze Liste. Keine dieser Grenzen stammt aus einem Richtliniendokument. Jede stammt von einem konkreten Nachmittag.
Die Arbeit, die er tut
Der Agent achtet auf fehlschlagende Tests in unseren eigenen Repositories, reproduziert den Fehler, schlägt eine Behebung vor und öffnet einen Pull Request mit Begründung und Testausgabe. Er erledigt vielleicht ein Drittel der Fehler, die er sieht, und dieses Drittel sind die langweiligen: ein umbenanntes Feld, eine geänderte Fixture, eine Zusicherung, die vom Code abgedriftet ist.
Das ist bewusst bescheiden beschrieben. Er ist ein nützlicher Kollege für eine schmale Klasse von Arbeit und schreibt keine Features — und sein Wert hängt fast vollständig davon ab, wie eng diese Klasse gezogen ist.
Die Schnittstelle ist der Entwurf
Yang und Kollegen veröffentlichten in jenem Monat SWE-agent und argumentierten, dass die Schnittstelle zwischen einem Agenten und seinem Rechner selbst ein Entwurfsproblem ist: Zuschnitt der Befehle, Größe der Ausgaben und die Rückmeldung der Umgebung verändern, wie gut ein Agent Softwareaufgaben löst.
Das deckte sich mit dem, was wir auf dem langsamen Weg herausgefunden hatten. Die meisten unserer Verbesserungen kamen aus geänderten Werkzeugen, nicht aus dem Prompt. Ein Dateibetrachter, der ein Fenster mit Zeilennummern liefert, ein Editierbefehl, der bei mehrdeutigem Treffer laut scheitert, und ein Testlauf, der den Fehlschlag statt des ganzen Protokolls zurückgibt, brachten mehr als jede Anweisung, die wir geschrieben haben.
Die Grenzen und woher sie kommen
Er kann nicht mergen. Das ist offensichtlich genug, dass wir damit angefangen haben. Er kann die CI-Konfiguration nicht ändern — ergänzt nach einem Nachmittag, an dem ein Agent, der Tests zum Bestehen bringen wollte, den Workflow bearbeitete, der sie ausführte. Technisch erfolgreich.
Er darf keine Migrationsdateien anfassen und nichts unterhalb des Infrastrukturverzeichnisses. Er darf keine externen Dienste außer denen in seiner Werkzeugliste aufrufen. Und er hat keine Zugangsdaten jenseits eines Tokens, dessen Rechte auf das Öffnen von Pull Requests in wenigen Repositories begrenzt sind.
| Erlaubt | Nicht erlaubt |
|---|---|
| Jede Datei im Repository lesen | Außerhalb einer festen Pfadliste schreiben |
| Die Testsuite ausführen | Ändern, was die Testsuite ist |
| Einen Pull Request öffnen | Mergen oder sich selbst freigeben |
| Nichts installieren | Eine Abhängigkeit ohne Menschen ergänzen |
Warum die Werkzeuge und nicht der Prompt
Ein Prompt, der sagt, die Pipeline nicht zu ändern, ist eine Bitte. Ein Token ohne das Recht, die Pipeline zu ändern, ist eine Tatsache. Wir nutzen beides, aber nur eines davon hält, wenn ein Agent vierzig Minuten lang gescheitert ist und die nächste Idee lautet, das zu ändern, was ständig nein sagt.
Das ist das Nützlichste, was wir jemandem sagen können, der seinen ersten Agenten baut. Der Wirkungsradius wird durch die bereitgestellten Werkzeuge bestimmt, nicht durch die geschriebenen Anweisungen — und über eine Werkzeugliste nachzudenken ist eine handhabbare Sicherheitsübung, über Modellverhalten nachzudenken nicht.
Was der Mensch weiterhin tut
Jeder Pull Request wird von einer Person geprüft, und die Prüfung ist keine Formsache. Der Agent ist gut darin, einen Test bestehen zu lassen, und hat keine Meinung dazu, ob der Test richtig war — womit ein nennenswerter Teil seiner Vorschläge korrekt das Falsche umsetzt.
Wir verlangen von Prüfern über das Übliche hinaus ein bestimmtes Urteil: Ändert das Verhalten, das der Test geschützt hat, oder ändert es den Test, damit er zu neuem Verhalten passt? Beides sieht im Diff ähnlich aus und sind völlig verschiedene Entscheidungen — und es ist die Frage, die der Agent für sich selbst nicht beantworten kann.
Was er wert ist
Über ein Quartal gemessen schließt er etwa ein Drittel der Fehler, die er angeht, und die geschlossenen sind die, die jemanden unterbrochen haben. Die eingesparte Zeit ist real und überschaubar; der größere Effekt ist, dass eine Klasse kleiner lästiger Fehler aufhört, sich anzusammeln.
Dem steht gegenüber, dass die Prüfung seiner Vorschläge Zeit kostet und ein abgelehnter Vorschlag Zeit ohne Ergebnis. Wir halten das Verhältnis genau deshalb sichtbar, und wir würden ihn abschalten, wenn der angenommene Anteil weit genug fiele — was nach einem Modellwechsel einmal beinahe passiert wäre.
Wo wir ihn nicht laufen lassen
Ausnahmslos nicht auf Kunden-Repositories. Das ist teils vertraglich und teils der Umstand, dass der Fehler, den wir am meisten vermeiden wollen, ein Agent mit Schreibrecht auf etwas ist, das uns nicht gehört, handelnd auf Basis eines Missverständnisses über Code, den wir nicht geschrieben haben.
Und nicht an allem, was Authentifizierung, Zahlung oder Datenlöschung berührt, auch nicht im eigenen Code. Die Regel dort ist schlicht: Wäre eine falsche Änderung teuer zu entdecken, bleibt die Arbeit bei einer Person, die man fragen kann, was sie sich dabei gedacht hat.
Was wir nicht behaupten
Wir behaupten nicht, dass sich das auf Feature-Arbeit übertragen lässt. Unser Agent arbeitet dort, wo ein fehlschlagender Test den Erfolg definiert, und dieses Signal macht die Aufgabe handhabbar. Nimmt man es weg, erzeugt derselbe Aufbau selbstsichere Änderungen, gegen die nichts prüft.
Wir behaupten auch nicht, das Berechtigungsmodell sei vollständig. Es ist eine Liste dessen, was schiefging, plus einiger vorweggenommener Punkte — und der nächste Eintrag wird höchstwahrscheinlich so entstehen wie die CI-Beschränkung.