Mad Max als Vorbild für Softwareentwicklung? Das neue Framework Gas Town des Entwicklers und Bloggers Steve Yegge orchestriert mehr als zehn Coding-Agenten gleichzeitig mit einer Architektur, die von der postapokalyptischen Filmreihe inspiriert ist. Der Ansatz: nicht perfekte Einzelagenten, sondern kontrolliertes Chaos mit Agenten-Rollen wie Bürgermeister, Wächter und Raffinerie, die alle an die Mad-Max-Filme angelehnt sind (siehe Tabelle am Ende des Artikels). Gas Town ist dabei nichts für schwache Nerven oder einen kleinen Geldbeutel.

Yegge betont, dass sich das System noch im Alpha-Stadium befindet und erhebliche Vorkenntnisse zu Coding-Agenten voraussetzt, um mit dem Chaos in der Stadt der Coding-Agenten umgehen zu können. Zudem benötigt man durch die starke Skalierung schnell ein zweites oder drittes Claude-Max-Abonnement von Anthropic, das je nach Variante 100 oder 200 US-Dollar pro Monat kostet.

Gas Town zählt zu einer ganzen Gruppe an Anwendungen, die von der Community derzeit heiß diskutiert werden und deren Ziel es ist, Coding-Agenten zu koordinieren. Zu diesen Orchestratoren gehören zum Beispiel Ralph, Loom oder AutoClaude. Yegge hat das Framework am 1. Januar 2026 veröffentlicht, nach nur siebzehn Tagen Entwicklungszeit. Allerdings steckt im Konzept die Erfahrung von über einem Jahr an Experimenten. Er hat es mithilfe von KI-Agenten in Go geschrieben.

Vom Chaos zur Ordnung

Yegge geht von dem Gedanken aus, dass es schon immer die Aufgabe von Ingenieuren gewesen ist, komplexes Chaos in beherrschbare Strukturen zu verwandeln. Das Tool geht dabei einen Failure Mode nach dem anderen mit unterschiedlichen Konzepten an. Der Autor spricht von nichtdeterministischer Idempotenz, zwei Begriffen, die sich auf den ersten Blick ausschließen, aber durch die Kontrollstrukturen des Frameworks zusammenfinden. Die parallele Arbeit von drei bis fünf Coding- und anderen KI-Agenten kann zu chaotischen Systemzuständen führen. Was passiert beispielsweise, wenn mehrere Agenten an gleichen oder ähnlichen Aufgaben arbeiten? Wer kümmert sich um Merge-Konflikte? Wie lässt sich doppelte Arbeit verhindern? Gas Town bedient sich unterschiedlichster Konzepte, um Ordnung in das Chaos zu bringen (siehe folgende Abbildung).

Ein Arbeitstag des Bürgermeisters in Gas Town

Ein typischer Tag in der Stadt Gas Town beginnt damit, dass der menschliche Entwickler (Overseer) gemeinsam mit dem Hauptagenten, dem Bürgermeister (Mayor), die Aufgaben für den Tag in natürlicher Sprache festlegt. Der Bürgermeister zerlegt diese Aufgaben in kleinere Teilaufgaben und speichert sie im Task-Manager (Beads). Sobald die Vorbereitungen fertig sind, bündelt er Aufgaben in einem Arbeitsauftrag, im Convoy, und schickt sie in eines der Repositories, Rigs. Wenn Gas Town Zugriff auf eine gültige GitHub-Authentifizierung hat, kann der Bürgermeister Repositories einfach klonen und für die Verwendung mit Gas Town initialisieren.

Das Aufteilen der Aufgaben begegnet dem Problem der nachlassenden Qualität der Antworten von Coding-Agenten, je weiter sich ihr Kontextfenster füllt. Bei den Claude-LLMs sind das aktuell 200.000 Token. Bei Erreichen des Limits komprimiert der Coding-Agent die Dialoge, um Platz zu schaffen. In der Praxis führt schon ein zu sechzig Prozent gefülltes Kontextfenster zu einer merklichen Reduktion der Ausgabenqualität.

Im Rig werden Arbeiter-Agenten (Polecats) aktiv, die mit der Abarbeitung von Aufgaben beginnen. Je mehr Aufgaben anliegen, desto mehr Polecats treten in Aktion. Sie schaffen sich mit Git-Worktrees ihre eigene Arbeitsumgebung und kümmern sich eigenständig um die Umsetzung.

Über Mailboxes und Handoffs können sie miteinander kommunizieren. Das Mailbox-System ist von Erlang inspiriert und dient der Kommunikation zwischen langlebigen Agenten, wie dem Bürgermeister und dem Wächter. Handoffs hingegen arbeiten synchron und dienen der Übergabe des Arbeitszustands an eine neue Arbeiter-Instanz, wenn der Kontext über die oben beschriebene kritische Füllmenge hinaus ansteigt.

Da in Gas Town immer mal etwas schiefläuft, beschäftigt der Bürgermeister den Wächter (Deacon), der das Gesamtsystem periodisch analysiert, Zombieprozesse aufräumt, festgefahrene Sessions wieder anstößt und die wichtigsten Systemfunktionen am Leben hält. Im Unterschied zum Wächter, der auf Systemebene patrouilliert, überwacht der Aufseher (Witness) innerhalb eines Rigs einzelne Agenten. Jeden Agenten, den er etwa beim Faulenzen erwischt, ermordet er eiskalt und ersetzt ihn.

Merge-Konflikte: Die Raffinerie sortiert

Mit mehreren Agenten kommt es zu vielen parallelen Änderungen, doppelter Arbeit und unzähligen Merge-Konflikten. Außerdem berichten mehr und mehr Entwicklerinnen und Entwickler, dass die Freude an ihrem Job abgenommen hat, seit sie nur noch Code von KI-Agenten reviewen.

Um diesen Problemen Herr zu werden, gibt es in Gas Town eine Raffinerie. Sie überprüft alle Arbeitsergebnisse der Agenten und räumt auf. Merge-Konflikte und schlechte Codequalität bekämpft sie mehrheitlich durch Qualitätskriterien, die sich über konfigurierbare Review-Presets und ein projektspezifisches CLAUDE.md anlegen lassen.

Nachdem alle Aufgaben abgeschlossen sind, meldet der Bürgermeister dem Entwickler stolz die erfolgreiche Abarbeitung der Convoy-Aufgabengruppe.

Agenten in Gas Town stellen austauschbare Instanzen dar, vergleichbar mit dem Konzept von Cattle statt Pets bei der Orchestrierung der Infrastruktur mit virtuellen Maschinen oder Containern, etwa mit Kubernetes. Auch darüber hinaus hat das Framework viel mit Kubernetes gemeinsam: Es gibt eine Control Plane (Bürgermeister und Wächter), die eine Data Plane (die Polecats und Aufseher) managen. Dabei sind die Arbeiter-Agenten (Polecats) austauschbar: Wenn sie den Dienst niederlegen oder stecken bleiben, werden sie durch eine neue Instanz ersetzt, ohne dass der Kontext aus der letzten Session verloren geht.

Sweeps: Garbage Collection für technische Schulden

Wenn Entwicklerinnen und Entwickler blind mit Agenten Code produzieren, akkumulieren sich auf Dauer die technischen Schulden. Die tauchen auch als Fehlannahmen (Heresies) im inneren Monolog der Agenten auf, und menschliche Entwickler können sie darüber aufspüren und nachvollziehen. Grund für die Fehler ist oft das eingeschränkte Kontextfenster, aufgrund dessen Agenten aus dem Blick verlieren, was in der letzten Session vorgefallen ist. Früher gewählte Ansätze geraten in Vergessenheit und Agenten wählen mitunter fremde Designmethoden, die die Architekturkonsistenz verletzen. In einer größeren Codebasis können beispielsweise drei bis vier unterschiedliche Logging Libraries auftauchen.

Um dem zu begegnen, erfordert es sorgfältige Reviews durch Menschen, was wiederum am Produktivitätsgewinn durch die multiplen Agenten nagt. Gas Town wählt eine andere Strategie, die auf Stichproben basiert, den Sweeps: systematische Korrekturwellen, die Architektur-Drift und schlechte Praktiken eindämmen, ohne dass Entwickler alle Fehlannahmen bedenken oder alle Codezeilen einzeln analysieren müssen. Ein sechzigminütiger Review-Sweep mündet in konkreten Aufgaben für das Task-Management (Beads), die so in den Kontext der beteiligten Agenten gelangen. Das lenkt künftige Entscheidungen in die Richtung, die die menschlichen Entwickler für richtig halten.

Um einen Sweep zu starten, lassen sich Entwickler vom Bürgermeister über einen persistenten Workspace (~/gas-town//crew//rig/) einen Git-Worktree erzeugen und sehen dort die Arbeitsergebnisse eines Convoys wie gewohnt in der IDE oder im Terminal. Anstatt selbst Änderungen vorzunehmen, beauftragen sie den Bürgermeister mit der Erstellung von Korrekturaufgaben. Diese ändern das Verhalten der Agenten und führen zu einer weiteren Erhöhung der Codequalität. Nach und nach steigert sich so das Vertrauen in die Agentenschar und der Aufwand für Sweeps reduziert sich. Sweeps stellen eine Art Garbage Collection für technische Schulden dar. Zusätzlich sollten Developer aber nicht auf die gängigen Kontrollmethoden wie Rule-Dateien (AGENT.md oder CLAUDE.md) und statische Quality Gates wie Fitness Functions oder statische Codeanalyse verzichten.

Von Vibe Coding spricht man, wenn ein großes Sprachmodell den Quellcode generiert und der menschliche Beitrag sich weitgehend auf das Formulieren von Anweisungen beschränkt. Entsprechend sind für Vibe Coding nicht zwingend Programmierkenntnisse erforderlich.

Der Programmierer und Computerbrillen-Enthusiast Jake Ledner demonstriert in einem Video, wie Vibe Coding auf Smart Glasses aussehen könnte. In dem Video spaziert er durch New York, während er dem KI-Agenten OpenClaw über sein Meta Ray-Ban Display und das darauf installierte WhatsApp Sprachanweisungen gibt. Der Chatverlauf erscheint direkt im Sichtfeld, sodass er den Fortschritt über von OpenClaw gesendete Screenshots verfolgen kann. Der KI-Agent läuft auf einem Mac Studio in Ledners Wohnung und nutzt OpenAIs Coding-Werkzeug Codex, um den Programmcode zu schreiben.

Im Video lässt Ledner OpenClaw seiner KI-Kalorienzähler-App „TrackGPT“ eine Speicherfunktion für häufige Mahlzeiten hinzufügen. Nach Freigabe spielt der Agent den Code automatisch ein und der neue „Speichern“-Button geht in der App live.

„Im Grunde kann heute jeder von überall aus Apps entwickeln, mit OpenClaw, OpenAI Codex und Meta Ray-Ban Smart-Glasses“, sagt Ledner im Video, das er zunächst auf X veröffentlichte, das mittlerweile aber auch auf LinkedIn verfügbar ist.

Sicherheitsrisiken und Plattformgrenzen bremsen Einsatz

Ganz so einfach, wie es Ledner suggeriert, ist es freilich noch nicht: OpenClaw birgt derzeit erhebliche Sicherheitsrisiken und setzt idealerweise eine dedizierte Recheneinheit voraus, was für viele Nutzer kaum praktikabel sein dürfte. Die Meta Ray-Ban Display ist zudem bislang nur in den USA erhältlich. Sie kam dort im September 2025 auf den Markt und kostet rund 800 US-Dollar. Ob und wann ein internationaler Marktstart erfolgt, ist offen. Möglicherweise wartet Meta auf die zweite Generation des Wearables, die laut einem aktuellen Bericht noch in diesem Jahr erscheinen könnte.

Eine weitere Einschränkung bei der Meta Ray-Ban Display ist, dass Drittentwickler derzeit keinen Zugriff auf das Display haben. Aus diesem Grund nutzt Ledner WhatsApp, um mit OpenClaw zu kommunizieren. Metas Messenger-Dienst ist eine der wenigen Apps, die die Smart Glasses aktuell unterstützen.

An der fehlenden Display-Berechtigung könnte sich allerdings schon bald etwas ändern: Oscar Falmer, der bei Meta die Entwicklerbetreuung im Wearables-Bereich verantwortet, reagierte auf das Video und stellte den Display-Zugriff für Drittentwickler für dieses Jahr in Aussicht. Damit könnten künftig Apps entstehen, die direkt auf OpenClaw oder eine vergleichbare, künftige KI-Funktion von OpenAI zugreifen. Dessen Schöpfer Peter Steinberger wurde gerade erst von dem Unternehmen verpflichtet.

Unabhängig von Meta werden künftig weitere Smart Glasses mit Display erscheinen, die ähnliche Eigenschaften wie die Meta Ray-Ban Display haben. Google plant beispielsweise, noch in diesem Jahr ein entsprechendes Produkt vorzustellen.

(tobe)

Wieder mal von den Dampfplauderern aus der anderen Abteilung ausgekontert worden, wieder mal im Meeting kaum zu Wort gekommen, wieder mal kein Gehör bei der Geschäftsführung für die technischen Argumente gefunden: Das sind Erfahrungen, die ITler mit introvertierter Persönlichkeit im Arbeitsleben häufig machen. Der ITler und Berater Peyman Pouryekta erklärt, was Führungskräfte machen können, um ihre stillen Schaffer besser glänzen zu lassen.

Der introvertierte Techie aus der IT ist ein verbreitetes Klischee. Wie häufig ist das wirklich noch in diesem Berufsfeld?

Früher war dieses Klischee des introvertierten Techies sicher zutreffender als heute. Menschen, die sehr tief in eine Materie eingetaucht sind, wirkten auf Außenstehende oft wie aus einer anderen Welt. Und wenn wir ehrlich sind, gibt es das natürlich immer noch, aber das Berufsfeld ist deutlich vielfältiger geworden – mit introvertierten und auch extrovertierten Persönlichkeiten.

Für viele Tech-Rollen und das tiefe sowie fokussierte Arbeiten braucht es eine ruhige Atmosphäre. Introvertierte schöpfen ihre Energie häufig genau aus so einem Umfeld, deswegen passt die Kombination sehr gut für sie. Gleichzeitig gibt es aber immer mehr Tech-Expertinnen und -Experten, die als CTOs, im Produktmanagement oder in der Softwareentwicklung aktiv Netzwerke aufbauen und ihre Arbeit wirklich sichtbar machen.

Entscheidend ist nicht, ob man introvertiert oder extrovertiert ist, sondern wie man seine Stärken einbringt. Viele introvertierte Techies kommunizieren lieber schriftlich oder in einer kleineren Runde. Das kann effektiver sein, bringt aber auch das Risiko mit sich, übersehen zu werden, vor allem, wenn man seine Ideen nicht klar vermitteln kann.

Vor welchen Herausforderungen steht man als Führungskraft introvertierter Angestellter?

Eine der größten Herausforderungen ist, dass das Wissen introvertierter Mitarbeitender nicht wahrgenommen wird, obwohl es für strategische Entscheidungen oft ausschlaggebend ist. Ich sehe, wie sich in vielen Unternehmen vor allem diejenigen durchsetzen, die laut und präsent sind. Wer sich lieber im Hintergrund hält, wird seltener wahrgenommen, selbst wenn er entscheidendes Wissen mitbringt.

Ich hatte mal einen Fall, in dem sich die Führung von IT und Produkt auf eine gemeinsame Linie einigen musste. Die IT-Führung war eher introvertiert, die Produktführung eher extrovertiert. Dreimal dürfen Sie raten, wer die Moderation übernommen hat – das Produkt-Team. Die IT-Themen wurden kaum berücksichtigt, das Team wurde mitten in seiner Präsentation unterbrochen und am Ende fehlte die IT-Perspektive auch in der Entscheidung. Später stellte sich auch heraus, dass wichtige technische Aspekte ignoriert worden waren – was das Unternehmen nicht nur Zeit, sondern auch eine Menge Geld kostete.

Ein Problem, das ich immer wieder beobachte, ist die Art und Weise, wie Meetings organisiert werden – oder besser gesagt: nicht organisiert werden. Oft laufen sie nach dem Prinzip „Wer was zu sagen hat, sagt es einfach“. Das kann offen und dynamisch wirken, führt aber dazu, dass vor allem extrovertierte Teilnehmende das Gespräch dominieren. Sie denken laut, reagieren spontan und setzen dadurch oft die Richtung der Diskussion und nehmen den Raum ein.

Introvertierte hingegen brauchen mehr Zeit zum Reflektieren und teilen ihre Gedanken lieber strukturierter. Ohne klare Moderation und Gesprächsregeln kann es leicht passieren, dass ihr Wissen im Hintergrund bleibt. Der Unterschied wird sofort spürbar, wenn Meetings mit einer festen Agenda und klaren Redezeiten gestaltet werden. Sobald jede Person einen definierten Zeitraum für ihre Inhalte bekommt, verändert sich die Dynamik: Plötzlich kommen auch die Stimmen zu Wort, die vorher untergegangen sind.

Noch entscheidender ist die neutrale Rolle der Moderation. Ein guter Moderator hält sich eher im Hintergrund und geht auf alle Teilnehmenden ein, stellt gezielt Fragen und sorgt dafür, dass nicht nur die Lautesten gehört werden. Ich habe erlebt, wie allein diese Anpassung dazu führte, dass strategische Entscheidungen fundierter getroffen wurden, weil plötzlich nicht nur Meinungen, sondern auch echte Expertise im Raum sichtbar wurden.

Was sollte man als Führungskraft unbedingt tun und was vermeiden gegenüber Introvertierten?

Man sollte unbedingt dafür sorgen, Meetings so zu strukturieren, dass alle zu Wort kommen. Introvertierte arbeiten besonders effektiv, wenn sie genug Zeit zur Vorbereitung haben. Außerdem lohnt es sich, als Führungskraft seinen Mitarbeitenden Möglichkeiten zur Weiterentwicklung anzubieten, um zum Beispiel Präsentationstechniken und Storytelling besser zu beherrschen.

Vermeiden sollte man, extrovertierte Verhaltensweisen als einzig richtig anzusehen und introvertiertes Verhalten als negativ darzustellen. Introvertierte in große, laute Gruppen zu setzen oder sie zu spontanen Präsentationen zu zwingen, kann sie eher ausbremsen, als ihr Potenzial zu fördern. Ein typisches Problem zeigt sich meist nach Meetings: Während extrovertierte Teilnehmende die Diskussion dominieren, analysieren introvertierte oft erst später, was im Meeting besprochen wurde und bringen meist erst dann wertvolle neue Perspektiven mit. Doch zu diesem Zeitpunkt ist die Entscheidung aus dem Meeting meist schon gefallen.

Eine einfache, aber effektive Lösung ist es, Feedback-Schleifen nach den Meetings einzuführen. Wer Zugang zu Meeting-Notizen hat und Kommentare oder Ergänzungen nachträglich einbringen kann, sorgt für fundiertere Entscheidungen. Auch asynchrone Kommunikation oder gezielte Follow-ups helfen, alle Perspektiven einzubeziehen. Eine gute Führungskraft erkennt diese Unterschiede und schafft Strukturen, in denen sowohl introvertierte als auch extrovertierte Persönlichkeiten wachsen und zum Erfolg beitragen können.

Herr Pouryekta, vielen Dank für das Interview!

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.

(axk)