Airbuild 1.6: Dynamic Agentic Mode

In Version 1.5 ging es um die Entscheidungen rund um die Arbeit: wofür du gerade bezahlst, welche Endpunkte absichtlich offen sind, was ein Projekt über eure Standards weiß. In 1.6 geht es um die Arbeit selbst — wer sie macht, und wer sagen darf, dass sie fertig ist.

Bisher hat ein Gespräch alles erledigt, der Reihe nach. Ein detaillierter Plan mit zwanzig Schritten war zwanzig Schritte hintereinander, auch dort, wo die Hälfte davon nichts miteinander zu tun hatte. Dynamic Agentic Mode ändert das — und ändert, wer abnimmt.

Erst der Plan. Dann bauen die Agenten parallel.

Der Lead-Agent zerlegt die Arbeit in die Anzahl Phasen, die sie wirklich braucht, mit echten Abhängigkeiten dazwischen. Was alles andere trägt — das Datenmodell samt Migrationen, gemeinsame Typen und API-Verträge, das Grundgerüst der App — bleibt beim Lead und kommt zuerst. Erst danach bekommen die unabhängigen Teile ihre eigenen Agenten.

Jeder Agent steht mit seiner Aufgabe im Plan: welchen Bereich er verantwortet, auf welchem Modell er läuft, wie tief er denken soll. Bis zu fünf arbeiten gleichzeitig in einem Gespräch. Keine zwei teilen sich eine Aufgabe oder einen Bereich — es gibt also keine stille Überschneidung, die man später entdeckt.

Jeder Agent arbeitet in seiner eigenen Umgebung

Paralleles Arbeiten auf einem gemeinsamen Stand ist der sichere Weg zu vier Agenten, die sich gegenseitig die Dateien unter den Füßen wegziehen. Deshalb bekommt jeder Agent eine eigene Kopie des Projekts und eine eigene laufende Kopie der App — eigenes Backend, eigene Tests, eigene Logs. Er kann das, was er baut, auch starten und scheitern sehen.

Ins Projekt kommt die Arbeit erst beim Übernehmen, und dabei wird Zeile für Zeile zusammengeführt. Eine Datei, die sich nicht sauber zusammenführen lässt, geht mit markiertem Konflikt an den Agenten zurück, der sie geschrieben hat, statt als Durcheinander zu landen, das jemand anderer auflösen muss. Eine neue Datenbank-Migration, deren Nummer schon vergeben ist, wird umnummeriert; eine bereits gelaufene Migration wird nie angefasst.

Kein Agent nimmt seine eigene Arbeit ab

Das ist der Teil, nach dem das Release benannt ist. Ein Agent, der sich selbst prüft, ist ein Modell, das seine eigene Hausübung benotet — und es wird dir meistens sagen, dass alles passt.

Also startet die Plattform den Prüfer, sobald ein Agent fertig ist. Nicht das Modell: die Plattform. Ein frischer Agent mit eigener Kopie und eigenem Blick liest und testet genau den Stand, den der Builder abgegeben hat, und gibt ein Urteil ab — Tests, Review, Sicherheit oder alles drei. Bis dieses Urteil grün ist, lässt sich die Arbeit nicht übernehmen. Es gibt kein Übergehen.

Erzwungen wird das schon einen Schritt früher: Ein Plan, in dem ein Agent ungeprüft bliebe, wird dir gar nicht erst vorgelegt, sondern geht zum Nachbessern zurück. Und ein Prüfer kann nicht sich selbst zugeteilt werden.

Fällt eine Prüfung durch, gehen die Befunde an den Agenten zurück, der diese Stelle gebaut hat — nicht in eine allgemeine Warteschlange. Er bessert in seiner eigenen Kopie nach, und derselbe Prüfer sieht noch einmal hin.

Zum Schluss: end-to-end im echten Browser

Am Ende eines Plans steht keine Selbstauskunft. Der Plan legt vorher fest, welche Abläufe stimmen müssen — „eine Kollegin wird eingeladen und meldet sich an", „ein Leserecht darf nichts löschen" — und ein abschließender Prüfer klickt sie in einem echten Browser auf seiner eigenen Kopie der App durch.

Jeder Ablauf wird einzeln auf bestanden oder nicht bestanden gesetzt. Du kannst also Punkt für Punkt mitlesen, statt einem einzigen grünen „fertig" zu glauben. Und nach drei erfolglosen Runden hält das System an und fragt dich, statt weiterzumahlen.

Für jeden Teil das passende Modell

Nicht jeder Teil einer App braucht das stärkste Modell. Der Plan wählt pro Agent eines aus den vierzehn Modellen im Picker, über sechs Anbieter, dazu eine Denktiefe — ein schnelleres, günstigeres Modell für einen gut beschriebenen Teil, das stärkere nur dort, wo wirklich nachgedacht werden muss. Stärker als der Lead selbst wird ein Agent nie eingestellt, außer du nennst das Modell ausdrücklich.

Hinterher zeigt die Agentenliste, was das gekostet hat: pro Agent, welches Modell lief, wie lange, wie viele Tokens, welche Dateien sich geändert haben und um wie viele Zeilen. Schritt für Schritt, nachvollziehbar.

Der Plan entsteht vor deinen Augen

Bisher erschien ein Plan, wenn er fertig war — eine Wand Text, die auf einmal da stand. Jetzt öffnet er sich, sobald seine erste Datei zu streamen beginnt, und füllt sich Kapitel für Kapitel, die Leiste links wächst mit. Ein Hinweis am Ende sagt klar, dass die KI noch schreibt, damit niemand einen halbfertigen Plan für den ganzen hält.

Zustimmen oder ablehnen passiert in der Planansicht selbst statt im Chat: Die Entscheidung steht dort, wo das steht, worüber entschieden wird. Ein Plan lässt sich an Ort und Stelle ändern, statt neu angefordert zu werden, und jede Passage lässt sich in den Chat zitieren, um genau über diese Passage zu sprechen.

Das Design beschreibt er nicht mehr nur in Worten. Ein Plan trägt bis zu drei echte Entwürfe — Farben, Typografie und ein ausgearbeitetes Beispiel — in einem eigenen Kapitel „Look & Feel", und der gewählte ist der, dem der Build folgt. Bewusst höchstens drei: Eine Wand voller Varianten ist eine aufgeschobene Entscheidung, keine angebotene Wahl.

Support ist ein Fall geworden

Jede Support-Anfrage hat jetzt eine lesbare Fallnummer, einen sichtbaren Status und einen Verlauf, der die ganze Vorgeschichte hält. Dateien lassen sich von beiden Seiten anhängen, nicht nur beim Eröffnen. Du kannst deinen Fall selbst schließen und das zurücknehmen, wenn das Problem wiederkommt, und eine Antwort per E-Mail landet im selben Verlauf, statt ein zweites Gespräch über dieselbe Sache zu beginnen.

Ein abgeschlossener Fall stellt eine Frage: Hat das geholfen? Die Antwort kommt bei uns an, nicht im Nichts. Das Antwortfeld bleibt auch bei einem geschlossenen Fall — wer nachfragt, braucht kein neues Ticket und keine neue Nummer.

Alles Weitere

Dynamic Agentic Mode gehört zum Suite Builder. Die vollständigen Release Notes stehen auf der Seite zu Version 1.6.

• Jeder veröffentlichte Build trägt eine App-Version und eine Build-Nummer, gestempelt aus dem Commit, aus dem er gebaut wurde — „welcher Build läuft eigentlich" hat damit eine Antwort statt einer Vermutung.
• Das Monitoring hat eine Startseite bekommen, die die erste Frage beantwortet — läuft die App gesund — bevor du suchen gehst, mit einem Zeitraum, den alle Ansichten teilen und der in der Adresse steht.
• Eine App, die sich ihrer Grenze bei Speicher, Arbeitsspeicher oder Verbindungen nähert, warnt vorher, mit dem tatsächlichen Wert gegen die tatsächliche Grenze. Eine Neustartschleife wird als Neustartschleife gemeldet.
• Die Ressourcenansicht ist nicht mehr den größeren Plänen vorbehalten: Wer eine App veröffentlicht hat, sieht ihren Verbrauch.
• Eine Einladung hängt nicht mehr am Plan der eingeladenen Person — wer beitritt, arbeitet auf dem höchsten Plan im Team, und das Projekt sagt, welchen Plan es braucht.
• Ein Teammitglied kann das Hosting auf den eigenen Plan übernehmen: gleiche Adresse, gleiche Daten, kein Unterbruch. Eine App hängt damit nicht mehr an einem Konto, an das niemand herankommt.
• Fällt ein Modellanbieter kurz aus, zeigt der Chat einen Hinweis mit Countdown und versucht es von selbst noch einmal, statt den Zug mit einem roten Fehler zu beenden.