Seit einiger Zeit setze ich in mehreren meiner Projekte Coding-Agenten ein. Meistens war der Ablauf recht einfach: Ich beschrieb eine Aufgabe, ließ den Agenten daran arbeiten, sah mir die Änderungen an und entschied, wie es weiterging.
Bei Aufgaben mit einem klar erwarteten Ergebnis funktionierte das ziemlich gut.
Irgendwann fragte ich mich aber, wie viel ich einem Agenten eigentlich überlassen konnte, ohne dabei die Kontrolle über das Ergebnis zu verlieren. Nicht nur das Schreiben von Code, sondern auch das Überprüfen der Änderungen, das Finden von Problemen und die Entscheidung, ob sich eine kleine Korrektur lohnen könnte.
Ein kleines Puzzlespiel wurde zu einem guten Projekt, um das auszuprobieren.
Angefangen hat es mit einem kleinen Spiel
One Shot Chaos ist ein kleines Spiel mit einer einfachen Idee: Der Spieler hat einen Schuss, mit dem er eine Kettenreaktion auslösen und genügend Ziele treffen muss, um ein Level abzuschließen.
Das Projekt war etwas anders als meine übliche Arbeit mit .NET.
Natürlich gab es auch hier ganz normale Entwicklungsaufgaben: Anwendungszustand, Kollisionserkennung, Validierung und Tests. Aber das Ergebnis hing auch von Dingen ab, die sich deutlich schwerer automatisch überprüfen ließen.
Machte das Spiel Spaß? War der Bildschirm übersichtlich? Passte das visuelle Feedback zu den Aktionen des Spielers?
Ein Test konnte mir sagen, ob ein Projektil das erwartete Ziel getroffen hatte. Er konnte mir nicht sagen, ob sich dieser Treffer gut anfühlte.
Dieser Unterschied wurde wichtiger, als ich anfing, dem Agenten mehr Aufgaben zu überlassen.
Der Agent musste sehen können, was er verändert hatte
Am Anfang konnte der Agent das Spiel verändern und technische Prüfungen ausführen. Das visuelle Ergebnis musste ich mir aber weiterhin selbst ansehen.
Dabei fehlte etwas.
Der Code konnte funktionieren. Alle Prüfungen konnten erfolgreich sein. Trotzdem konnte eine Änderung an der Oberfläche oder an einer Animation im laufenden Spiel schlecht aussehen.
Ich wollte herausfinden, ob der Agent die tatsächlich laufende Anwendung beobachten konnte, statt sich nur auf den Code zu verlassen, den er gerade geschrieben hatte.
Der erste Versuch war bewusst klein gehalten.
Ich ergänzte eine Möglichkeit, einen bekannten Zustand des laufenden Spiels reproduzierbar als Screenshot festzuhalten. So konnte ich denselben Zustand bei verschiedenen Durchläufen aufnehmen und die Bilder miteinander vergleichen.
Das bedeutete nicht, dass der Agent plötzlich die visuelle Qualität beurteilen konnte. Aber er hatte jetzt etwas Konkretes, das er überprüfen konnte.
Beim nächsten Versuch ging ich einen kleinen Schritt weiter: ein bekanntes, lokales Problem in der Darstellung finden, korrigieren und das Ergebnis erneut beobachten.
Bei einer so kleinen Änderung musste ich das Spiel nicht mehr jedes Mal selbst starten, um das Ergebnis zu kontrollieren.
Ein bisschen mehr Verantwortung
Als das Beobachten der Ergebnisse funktionierte, wollte ich sehen, ob sich der Ansatz erweitern ließ.
Statt die genaue Korrektur immer selbst vorzugeben, wollte ich ausprobieren, ob der Agent einen kleinen Bereich untersuchen, mehrere mögliche Verbesserungen finden und eine davon für einen begrenzten Versuch auswählen konnte.
Der Spielraum blieb dabei bewusst klein.
Der Agent durfte ein lokales Darstellungsproblem untersuchen, eine einzelne Änderung vornehmen, die sich leicht rückgängig machen ließ, die passenden Prüfungen ausführen und das Ergebnis vergleichen.
Er durfte weder das Spiel neu gestalten noch die Spielregeln verändern. Und eine erfolgreiche technische Prüfung durfte er nicht als Beweis dafür betrachten, dass das Ergebnis auch gut aussah.
Mit der Zeit entstand ungefähr dieser Ablauf:
Untersuchen
↓
Vorschlagen
↓
Eine kleine Änderung ausprobieren
↓
Beobachten und überprüfen
↓
Beibehalten, überarbeiten oder stoppen
In späteren Versuchen erweiterte ich die Beobachtung auf verschiedene Spielzustände, darunter Zielen, Reaktionen, Spielfortschritt und den Abschluss eines Levels.
Dadurch wurde der Agent nützlicher. Gleichzeitig wurde mir aber auch klarer, was ich ihm überlassen konnte und was nicht.
Ein reproduzierbarer Screenshot konnte zeigen, dass zwei Durchläufe dasselbe Bild erzeugten. Er konnte mir nicht sagen, ob das Bild gut aussah oder ob ein Spieler Spaß daran haben würde.
Für solche Entscheidungen brauchte es weiterhin eine andere Art von Beurteilung.
Als weitere Verbesserungen nicht mehr ausreichten
Unabhängig davon lernte ich bei der visuellen Gestaltung von One Shot Chaos noch etwas anderes.
Mehrere frühe Versuche verbesserten einzelne Teile der Darstellung. Die Ziele wurden ausdrucksstärker, Reaktionen bekamen zusätzliche Effekte und die Oberfläche wirkte einheitlicher.
Die Änderungen funktionierten. Trotzdem war ich mit dem Gesamtbild noch nicht zufrieden.
Einzelne Elemente immer weiter zu verbessern schien mir nicht der richtige Weg zu sein, um die gewünschte Qualität zu erreichen.
Also probierte ich einen umfassenderen visuellen Ansatz für einen einzelnen, repräsentativen Bildschirm aus. Das machte einen deutlich größeren Unterschied. Trotzdem war das Ergebnis noch ein gutes Stück von dem entfernt, was ich mir vorgestellt hatte.
Erst ein anderer Ansatz mit illustrierten Rastergrafiken brachte eine wesentlich stärkere Verbesserung.
Wichtig war dabei nicht, dass der Agent endlich die richtige Lösung gefunden hatte.
Die Versuche halfen mir vielmehr zu erkennen, wann weitere Arbeit an einem Ansatz immer weniger brachte.
Nur weil sich etwas erfolgreich implementieren ließ, war das noch kein Grund, denselben Weg weiterzugehen.
Manchmal war das nützlichste Ergebnis eines Experiments die Entscheidung, damit aufzuhören.
Was ich weiterhin selbst entscheiden musste
Mit jedem weiteren Versuch fiel es mir leichter, kleinere Teile der Arbeit an den Agenten abzugeben.
Ich wollte ihm aber nicht einfach unbegrenzte Freiheit geben, nur weil er zuvor einige Aufgaben erfolgreich erledigt hatte.
Der Spielraum, den er sich erarbeitet hatte, war klar begrenzt.
Er durfte bekannte Spielzustände beobachten, ein lokales Problem untersuchen, eine kleine Korrektur vornehmen, die sich wieder rückgängig machen ließ, und überprüfen, ob das relevante Verhalten weiterhin funktionierte.
War das Problem unklar, schlug eine Prüfung fehl oder hätte eine Änderung die Spielmechanik oder die grundsätzliche visuelle Richtung beeinflusst, sollte der Agent anhalten und nachfragen.
Außerdem lernte ich, verschiedene Arten von erfolgreichen Ergebnissen auseinanderzuhalten.
Eine bestandene technische Prüfung war das eine.
Ein reproduzierbarer visueller Vergleich war etwas anderes.
Meine eigene Einschätzung, wie das Spiel aussah und sich anfühlte, war noch einmal etwas anderes.
Alle drei waren nützlich. Aber sie bedeuteten nicht dasselbe.
Diese Unterscheidung half mir zu entscheiden, was ich dem Agenten als Nächstes überlassen konnte, ohne jeden erfolgreichen Auftrag gleich als Beweis dafür zu nehmen, dass er schon für wesentlich größere Aufgaben bereit war.
Es ist weiterhin ein Experiment
One Shot Chaos befindet sich noch in der Entwicklung.
Ich habe nicht gezeigt, dass ein Agent selbstständig ein vollständiges Spiel entwerfen, entwickeln und veröffentlichen kann. Ich weiß auch nicht, ob dieser Ansatz in einem anderen Projekt genauso gut funktionieren würde.
Was ich bisher gesehen habe: Der Spielraum eines Agenten kann in kleinen Schritten wachsen, wenn sich die Ergebnisse überprüfen lassen.
Zuerst brauchte der Agent eine zuverlässige Möglichkeit, die Ergebnisse seiner Arbeit zu beobachten. Danach konnte er eine begrenzte Korrektur vornehmen und überprüfen. Erst dann war es sinnvoll, ihn zwischen kleinen Alternativen wählen zu lassen.
Ich denke inzwischen darüber als Autonomie, die sich ein Agent durch überprüfbare Ergebnisse verdient, statt sie von Anfang an zu bekommen.
Das hat mich nicht von der Verantwortung für das Ergebnis befreit. Es hat aber verändert, worauf ich einen Teil meiner Aufmerksamkeit richten kann.
Manchmal kann ich dem Agenten eine kleine, klar abgegrenzte Änderung überlassen und mich selbst auf die Entscheidungen konzentrieren, die die vorhandenen Prüfungen nicht für mich treffen können.
Ich lerne noch, wo genau diese Grenze liegen sollte.