Das Wochenende, an dem ein autonomer Agent zehn Subsysteme auslieferte

Eine Engine, die von Anfang an VON Agenten gebaut wird, kommt in einer anderen Form heraus als eine, der KI nachträglich angeflanscht wurde. Genau diese Form braucht eine Runtime, wenn KI ein Grundbaustein ist – kein Feature daneben.

Samstagmorgen den Laptop aufgeklappt. Das Runtime-Repository hatte über Nacht 139 Commits aufgenommen. Die meisten davon landeten durch einen autonomen Coding-Agenten, der gegen eine Warteschlange von Issues arbeitete, die ich letztes Wochenende angelegt hatte. Zehn Pull Requests in Subsystem-Größe, alle bereit für das Review.

Wenn Leute mich fragen, wie es tatsächlich aussieht, eine 3D-Runtime mit KI-Agenten im Team zu bauen, nehmen sie meistens eines von zwei Dingen an. Entweder sind die Agenten Autovervollständigung mit einem Chat-Panel aufgehübscht, oder sie sind ein Feature, das man später hinzufügt, nachdem die „echte” Engine von Menschen gebaut wurde.

Keins von beidem ist die Version, in der ich dieses Wochenende sitze.

Über Samstag und Sonntag hinweg nahm das Runtime-Repository 139 Commits auf. 110 davon wurden von einem autonomen Agenten verfasst. 20 liefen unter dem Account BladeWireless aus der Gründungszeit. 10 waren von mir. Über diese 139 Commits hinweg landeten zehn Subsystem-Pull-Requests:

• Skelett-Animationssystem
• Runtime-Szenenbearbeitungs-API
• Szenen-Serialisierung
• Occlusion Culling
• Level-Streaming
• Prefab-System
• GPU-Partikelsysteme
• Fortgeschrittenes Rendering
• Terrain- und Umgebungssysteme
• Post-Processing-Pipeline

Keines dieser Subsysteme ist KI. Es sind die langweiligen, tragenden Teile, die eine 3D-Runtime braucht, um eine 3D-Runtime zu sein. Und sie wurden über ein Wochenende hinweg in parallelen Branches ausgeliefert, größtenteils von einem Agenten verfasst, der autonom lief, während ich rahmte, reviewte und mergte.

Das ist der Beitrag darüber, was es bedeutet, dass das Fundament VON Agenten gebaut wird, nicht FÜR Agenten.

Der Unterschied steckt in jeder architektonischen Entscheidung

Es gibt eine Version dieser Geschichte, in der man eine „normale” Engine so baut, wie Engines schon immer gebaut wurden, und dann KI obendrauf hinzufügt. Die KI landet als Feature. Sie wird angeflanscht. Sie lebt außerhalb der Engine, weil die Engine nicht dafür entworfen wurde, sie zu beherbergen. Das ist gerade das dominierende Muster in der Branche, und es ist kein falsches Muster. Es ist nur das Muster, das entsteht, wenn man entscheidet, wie die Engine aussehen soll, bevor KI im Entwicklerteam ist.

Wenn KI-Agenten von Anfang an im Team sind, kommt die Form der Engine anders heraus. Drei Dinge ändern sich.

Erstens: Jedes Subsystem geht durch Code-Review. Weil Agenten am Review-Kreislauf teilnehmen müssen, muss der Kreislauf von Agenten verfasste Diffs akzeptieren. Jeder PR. Jeder Diff. Jeder Merge. Diese Disziplin ermöglicht nicht nur Agenten. Es stellt sich auch heraus, dass es genau die Disziplin ist, die man braucht, wenn KI jemals ein Runtime-Grundbaustein statt eines Editor-Features werden soll. Dieselbe Review-Pipeline, die den Tippfehler eines Agenten in einem Culling-Header abfängt, fängt auch den Tippfehler des Agenten in einem Verhaltensbaum ab. Der Pipeline ist es egal, in welcher Schicht des Stacks das passiert.

Zweitens: Jedes Subsystem hat saubere öffentliche Schnittstellen. Mehrere Agenten, die parallel an mehreren Subsystemen arbeiten, erzeugen unmergebare Konflikte, sobald die Grenzen unscharf sind. Das Mittel dagegen ist, die Grenzen hart zu ziehen, bevor überhaupt jemand Code schreibt. Sobald die Grenzen hart sind, werden die Subsysteme von überall ansprechbar – genau das, was man braucht, wenn die Engine KI-Verhalten beherbergen soll, das ohne Kopplung in den Rest der Runtime hineinrufen kann.

Drittens: Jedes Subsystem ist unabhängig testbar. Ein Samstag mit 139 Commits kann nicht von Hand QA’d werden. Die Tests müssen mit dem Diff mitgeliefert werden, sonst landet der Diff nicht. So vertraut der Mensch im Kreislauf dem Diff überhaupt. Der Nebeneffekt ist eine Testfläche, die es erlaubt, Implementierungen auszutauschen, ohne Aufrufer umzuschreiben – genau die Disziplin, die eine Engine braucht, um sich überhaupt weiterzuentwickeln.

Nichts davon sind KI-Features. Es sind Konsequenzen des Entwicklungsprozesses, die daher rühren, dass Agenten im Team sind. Der Entwicklungsprozess formt die Architektur.

Wie der Workflow tatsächlich aussieht

Das Muster, das dieses Wochenende hervorbrachte:

• Ich habe gerahmt, welche Subsysteme die Engine als Nächstes brauchte.
• Ein autonomer Agent lief parallel über zehn Branches, jeder implementierte ein Subsystem.
• Jeder Branch produzierte einen PR mit Implementierung, Tests und Dokumentation.
• Ich reviewte und mergte. Wo der Agent etwas falsch machte, schloss ich den PR oder bat um Änderungen.

Was mich beeindruckt, während ich hier am Ende des Wochenendes sitze, ist, wie viel davon bereits funktioniert. Der Entwicklungskreislauf ist der Entwicklungskreislauf. Der Agent macht die Arbeit, für die ich vor fünf Jahren zehn Leute eingestellt hätte. Ich treffe die architektonischen Urteile und die Merge-Entscheidungen. Es ist eine andere Art von langem Wochenende als die langen Wochenenden, die ich früher hatte.

Der autonome Agent an diesem konkreten Wochenende ist kein Multi-Vendor-Stack aus vier Assistenten. Es ist ein einzelner Agent (Copilots SWE-Agent), der über viele parallele Aufgaben läuft. Ich erwarte, dass das Multi-Assistenten-Muster kommt, und zwar schnell. Das Muster ist bereits in Einzel-Agenten-Form da.

Was schwer ist

Ehrlich darüber, denn es ist wirklich schwer.

Agenten sind nicht umsonst. Ein Wochenende mit 139 Commits hat Review-Kosten in Höhe von 139 Commits. Jeder PR braucht echte Aufmerksamkeit, weil die Subsysteme ungewohnt sind und ich sie nicht überfliegen kann. Ich bin müde. Die Erschöpfung ist real und es lohnt sich, sie einzuplanen.

Einem autonomen Agenten bei neuartiger Arbeit zu vertrauen ist eine Fähigkeit. Der Copilot-SWE-Agent, der die meisten Subsysteme dieses Wochenendes auslieferte, ist gut. Er ist nicht unfehlbar. Die Fähigkeit besteht darin, zu wissen, wann man schnell mergt, wann man langsamer macht, und wann man einen Entwurf verwirft. Ich habe bereits Dinge gemerged, die ich hätte neu würfeln sollen. Ich lerne, indem ich die Kosten trage.

Die Architektur muss skizziert werden, bevor die Agenten loslaufen. Gibt man einem Agenten den Prompt „bau mir einen Renderer”, bekommt man einen Renderer, der nicht zum Rest der Engine passt. Gibt man ihm „implementiere ein Occlusion-Culling-Subsystem, das diese C-API exportiert und sich über diese Handles in den Szenengraphen integriert”, bekommt man etwas, das sauber landet. Die Rahmenarbeit ist die Arbeit. Der Agent übernimmt das Tippen.

Tests sind nicht verhandelbar. Ich hätte beinahe einen der PRs dieses Wochenendes mit dünner Testabdeckung landen lassen. Das ist eine zukünftige Regression, die ich still und leise dabei bin einzugehen. Das Mittel dagegen ist, die Testanforderung von der ersten Zeile an zum Bestandteil des Prompts des Agenten zu machen.

Was ich vom Wochenende mitnehme

Zwei Beobachtungen.

Die Agenten werden offensichtlich weiter besser werden. Schneller, präziser, fähig, mehr von der Engine in einem Kopf zu halten. Das ist die leichte Vorhersage.

Die weniger leichte Vorhersage ist, was mit der menschlichen Rolle in diesem Workflow passiert. Es ist bereits nicht mehr die Rolle, für die ich als Senior Engineer ausgebildet wurde. Weniger Tippen, mehr Rahmen. Weniger Synthese, mehr Auswahl. Weniger „ich bin der Engpass bei dieser Codezeile” und mehr „ich bin der Engpass bei der architektonischen Entscheidung, die bestimmt, ob dieser Branch überhaupt lohnte, ausgeführt zu werden.”

Das ist ein anderer Job. Er beansprucht andere Muskeln. Ich glaube, die Muskeln, die er beansprucht, sind ungewöhnlich übertragbar über Domänen hinweg, und ich glaube, die Leute, die sie in den nächsten zwei Jahren entwickeln, werden auf den Rest der Branche so blicken, wie die Branche derzeit auf Leute blickt, die immer noch ohne Versionskontrolle bauen.

Das ist mehr als genug Denkarbeit für ein Wochenende.

Klappe den Laptop Sonntagabend zu. Nächsten Samstag geht es weiter.