𝗖𝗼𝗱𝗲𝘅 𝗙𝗶𝘅𝗶𝗻𝗴 𝗖𝗼𝗱𝗲𝘅: 𝗘𝗶𝗻 𝗖𝗼𝗻𝘀𝗲𝗻𝘀𝘂𝘀-𝗟𝗼𝗼𝗽
Ich habe einen Agenten-Loop entwickelt, der mehr tut, als nur Code vorzuschlagen. Er schreibt Code, überprüft ihn und mergt seine eigenen Pull Requests.
Um ihn zu testen, habe ich den Loop auf einen Fork des codex CLI gerichtet. Ich habe die Agenten versuchen lassen, die Software selbst zu reparieren. Dies ist ein reines Experiment. Der Fork hat keine Nutzer und keine Stars. Es geht um den Mechanismus, nicht um ein Produkt.
So funktioniert der Loop:
- Intake: Ein Upstream-Bug wird zu einem Issue im Fork. Der Loop wählt nur kleine, mechanische Bugs aus, die er abschließen kann.
- Solvers streiten: Mehrere Agenten schlagen unterschiedliche Fixes vor. Ein Solver möchte die kleinste Änderung. Ein anderer möchte eine saubere Struktur. Ein dritter möchte Code löschen, anstatt ihn hinzuzufügen. Sie sind sich uneinig.
- Judge schlichtet: Ein Judge liest die Debatte. Wenn sich die Solver uneinig sind, schickt der Judge sie für weitere Runden zurück. Der Judge protokolliert auch, warum er bestimmte Ideen abgelehnt hat.
- Implementierung und Merge: Sobald sie einen Konsens erreichen, schreibt der Loop den Patch, führt Tests aus und öffnet einen PR. Wenn die Tests bestehen, mergt er sich selbst.
Das kann man in Issue #34 live sehen. Die Agenten debattierten über einen Concurrency-Bug. Sie durchliefen drei Runden der Schlichtung, bevor sie eine Entscheidung trafen. Der Loop erzeugte einen echten Fix und einen Regressionstest, ohne dass ein Mensch auch nur eine einzige Zeile Code tippen musste.
Ein interessantes Ergebnis gab es in PR #16. Der Loop konnte einen gemeldeten Bug nicht reproduzieren. Anstatt einen fingierten Fix zu erfinden, fügte er einfach einen Test hinzu, um das Verhalten zu fixieren, und stoppte dann. Ein Loop, der weiß, wann er nicht patchen sollte, ist nützlicher als einer, der ständig einen Diff erzeugt.
Der Loop hat bisher etwa 16 PRs gemergt. Er bewältigt kleine Aufgaben wie die UTF-8-Handhabung und Command-Fixes. Er pflegt keine ganze Codebasis, aber er schließt kleine, klar abgegrenzte Bugs von Anfang bis Ende.
Menschen legen immer noch die Regeln fest und überprüfen die Arbeit. Wir prüfen nach wie vor jeden PR. Der Code ist automatisiert, aber die Aufmerksamkeit ist menschlich.
Den gesamten Prozess können Sie auf GitHub sehen. Schauen Sie sich Issue #34 und PR #37 an, um die Debatte zu verfolgen.
Optionale Lern-Community: https://t.me/GyaanSetuAi