Ich habe Monate damit verbracht, eine modellunabhängige Arbeitsumgebung zu entwickeln, um mit Programmieragenten echte Softwarearbeit zu leisten. Am Ende waren die Funktionen viel weniger wichtig als erwartet. Was wirklich zählte, war eine Handvoll Ideen, die meine Denkweise darüber verändert haben, wie man mit Agenten baut, anstatt sie nur zu prompten.
Das sind die Ideen, die am meisten Gewicht haben. Die ersten drei haben mein mentales Modell grundlegend verändert. Der Rest sind praktische Dinge, die du fast sofort anwenden kannst.
1. Friere die Akzeptanzkriterien ein, bevor der Agent beginnt
Und platziere sie an einem Ort, den er nicht bearbeiten kann.
Das ist wahrscheinlich die größte Veränderung für mich. Im Nachhinein klingt es offensichtlich, aber ich habe nicht wirklich erkannt, wie wichtig es war, bis ich es in Aktion gesehen habe.
Wenn sich Akzeptanzkriterien nach der Fertigstellung der Arbeit ändern können, verschieben sie sich langsam in Richtung des Erstellten. Der Agent ist nicht unehrlich, er bewertet die Arbeit einfach an einem Ziel, das sich noch bewegen kann. Wenn die Torpfosten beweglich sind, werden sie sich irgendwann bewegen.
Das ist kein Prompting-Problem, sondern ein strukturelles, also muss die Lösung auch strukturell sein.
Schreibe die Akzeptanzkriterien zuerst. Speichere sie außerhalb des bearbeitbaren Arbeitsbereichs und blockiere automatisch jeden Versuch, sie zu bearbeiten. Jetzt arbeitet der Agent auf einen Vertrag hin, den er nicht neu verhandeln kann. Die Aufgabe ist nicht erledigt, weil der Agent das sagt. Sie ist erledigt, weil sie den ursprünglichen Vertrag erfüllt.
2. Niemand sollte seine eigene Arbeit bewerten
Das Modell, das den Code geschrieben hat, ist der schlechtest mögliche Richter, um zu entscheiden, ob er korrekt ist. Sobald es fertig ist, hat es sich bereits davon überzeugt, dass die Lösung sinnvoll ist.
Also teile die Verantwortlichkeiten auf.
Lasse deterministische Skripte alles Mechanische überprüfen. Ein Skript kann keinen erfolgreichen Exit-Code erfinden. Behandle das Codierungsmodell als Ingenieur, nicht als Prüfer. Übergib das Ergebnis dann einem Prüfer mit frischem Kontext, der nie zugesehen hat, wie der Code geschrieben wurde, um Design, Absicht und Gesamtqualität zu beurteilen.
Diese einfache Trennung fängt weit mehr Probleme auf, als ich erwartet hatte, und sie ist überraschend günstig umzusetzen.
3. Durchsetzung ist einfach. Kalibrierung ist der schwierige Teil.
Diese Erkenntnis veränderte meine Sicht auf das gesamte Framework.
Die meisten Agentensysteme, einschließlich früherer Versionen von meinem, behandeln jede Aufgabe ungefähr gleich. Eine einzeilige Tippfehlerkorrektur durchläuft denselben Prozess wie eine große architektonische Neugestaltung. Das ist entweder Zeitverschwendung oder zu riskant.
Der Schlüssel ist proportionaler Aufwand.
Klassifiziere zuerst die Arbeit. Ist es eine kleine Änderung, von der nichts abhängt, oder Kerninfrastruktur, von der alles abhängt? Ist es Geschäftslogik oder generischer Hilfscode?
Lasse dann diese Klassifikation entscheiden, wie viel Überprüfung sie erhält, welches Modell sie bearbeiten soll und wie viel Autonomie erlaubt ist.
Die Durchsetzung zu etablieren ist einfach. Den Aufwand anzupassen ist der Punkt, an dem der Wert wirklich zu wachsen beginnt.
Die praktische Ebene
Sobald diese größeren Ideen etabliert waren, haben sich ein paar kleinere Praktiken fast sofort ausgezahlt.
- Lege deine Regeln im Framework fest, nicht im Prompt. Ein Prompt, der sagt „mache keine Änderungen im Hauptrepository", ist nur ein Ratschlag. Dieselbe Regel, die als blockierter Tool-Aufruf durchgesetzt wird, wird unmöglich zu ignorieren. Die wichtigen Regeln sollten nicht davon abhängen, dass das Modell sich entscheidet, sich zu verhalten.
- Halte den Zustand außerhalb der Konversation und verwende für jede Aufgabe einen neuen Worker. Speichere Aufgabenaufzeichnungen extern, verwende isolierte Worktrees und verarbeite Änderungen über eine Merge-Queue. Sobald der Zustand außerhalb des Chats liegt, sind Kontextbegrenzungen nicht mehr deine größte Einschränkung. Aufgaben werden parallel, fortsetzbar und viel einfacher zu durchdenken.
- Anbieterübergreifende Überprüfung schlägt anbieterinterne Überprüfung. Modelle können ihre eigene Arbeit eher nachsichtig bewerten als die eines anderen. Die Verwendung eines Modells von einem anderen Anbieter ist ein einfacher, effektiver Weg, diese Voreingenommenheit zu reduzieren.
Warum die Prinzipien funktionieren
Keine dieser Ideen hängt von einem bestimmten Modell ab. Sie drehen sich um Framework-Engineering. Protokolle, Verifikation, Überprüfungspipelines und Aufteilung von Verantwortlichkeiten.
Das Modell an der Spitze der Benchmarks wird sich ständig ändern.
Aber die Prinzipien wahrscheinlich nicht.
Der bleibende Wert liegt nicht im Modell und nicht in den Funktionen. Er liegt im Gerüst, das du um sie herum baust.
