Gas City: in de software factory met 100 coding agents

Honderd coding agents in parallel, vijftig pull requests per dag, een miljard tokens per dag. Dat is geen denkbeeldige toekomst — dat draait nu op één server in Atlanta. Wat Gas City laat zien over multi-agent engineering is interessanter dan de toolkit zelf.

Van Gas Town naar Gas City

Begin dit jaar publiceerde Steve Yegge — een bekende veteraan uit de developer-tools wereld — een Medium-post over Gas Town, een open source orkestratielaag waarmee 20 tot 30 AI-coding agents tegelijk aan dezelfde codebase kunnen werken. De post ging viraal. Vorige week werd de opvolger Gas City aangekondigd, herbouwd als toolkit door Chris Sells (ex-Google, eerder Flutter naar 3 miljoen developers gegroeid) en Julian Knutsen (voorheen technical lead bij Block).

Knutsen draait Gas City in productie op één server in Atlanta met circa honderd agents, die samen ongeveer vijftig pull requests per dag mergen — de output van een klein team — en daarbij ruwweg een miljard tokens per dag verbranden. Dat is ongeveer een vijfde van het volledige Engelstalige Wikipedia-corpus. Per dag.

De inschatting van Mike Taylor (Every's head of tech consulting) na een workshop in New York: 🟨 — "Learn from the ideas. Skip the toolkit for now." Wat ons interesseert zijn die ideeën, want ze raken aan precies de architectuur-vragen waar wij met klanten tegenaan lopen zodra agents echt parallel gaan draaien.

Drie ideeën die je sowieso moet kennen

1. Dark factory vs. light factory

Splits je proces in twee zones. Light factory = de stappen waar mensen en agents samen aan tafel zitten: planning, design, eindreview. Daar moet alles zichtbaar en bestuurbaar zijn. Dark factory = de stappen waar de agent zelfstandig zijn werk doet, helemaal op de achtergrond, zonder dat een mens kijkt. Bug-triage, refactor-passes, test-generation, formatting, dependency-bumps.

De truc: je begint met bijna alles in het licht en verschuift naarmate je vertrouwen krijgt steeds meer naar het donker. Dit is dezelfde mindset als de transitie van handmatige naar geautomatiseerde tests, maar dan voor agent-acties. Voor onze klanten betekent het concreet: maak vooraf expliciet welke acties geen human-in-the-loop nodig hebben en welke wél — en herzie dat lijstje elke sprint.

2. One pet, many cattle (de "mayor" + "polecats")

Dit is het sterkste idee in Gas City. In plaats van honderd agents individueel te managen, praat je met één persistent supervisor-agent (Gas City noemt hem de mayor) die jouw intentie begrijpt en context vasthoudt. De mayor delegeert vervolgens naar anonieme, wegwerpbare workers (de polecats) die één klus doen en daarna afsluiten.

Waarom werkt dat? Omdat losse agents geen historie meeslepen en dus geen context vervuilen. En omdat jij als mens nooit honderd dingen tegelijk hoeft te volgen — je voert één gesprek met de mayor, niet honderd parallelle chats. Dezelfde patroon kom je inmiddels tegen in Claude Code's sub-agents, in Cursor's background agents en in OpenAI's recent uitgebrachte Symphony. Het wordt langzaam de standaard manier waarop multi-agent systemen worden gestructureerd.

3. Meerdere modellen voor één code review

Stuur dezelfde diff naar Claude, Codex én Kimi — tegelijk. Drie verschillende modellen vangen andere bugs dan één model dat je drie keer draait. Voor ons is dit een direct toepasbare tip: een review-stap waarin je een PR door twee tot drie verschillende modellen laat lezen, kost weinig extra in vergelijking met de developer-tijd die je terugkrijgt. We bouwen dit voor klanten al in een paar n8n-flows en in OpenClaw's PR-review chain.

Waar Gas City zelf nog niet klopt

De toolkit is nog rauw. Mike Taylor noteerde een paar concrete pijnpunten:

• Geen agent-geheugen tussen taken. Elke taak start een fresh sessie die niet weet wat eerdere agents hebben gedaan. Resultaat: agents lezen telkens opnieuw context die net door een collega-agent geproduceerd is. Verspilling, en je mist verbanden die een single-session wél zou pakken.
• Het kost wat het kost. Een zes-stappen klus betekent grofweg zes keer de kosten van één Claude-sessie. Bij een miljard tokens per dag praat je niet meer over koffiegeld.
• De setup is zwaar. Een zaal vol ervaren engineers had een hele dag nodig om het draaiend te krijgen, mét hulp van Sells en Knutsen.
• Beads (de taak-tracker) is agent-first, niet mens-first. Het draait als CLI, geen visueel dashboard. Daarom koppelen teams het in productie alsnog aan Jira of Linear — taken in twee plekken, dubbel werk.
• Het overschat hoeveel hand-holding moderne modellen nog nodig hebben. Veel review-loops en mid-task check-ins die Gas City inbouwt om drift te voorkomen, zijn met Claude 4.5 of GPT-5.2 niet meer nodig.
• Het jargon werkt tegen. Beads, polecats, refineries, mayor — leuk thematisch, maar nieuw teamlid begint met een woordenboek.

Wanneer is dit voor jou relevant?

Onze inschatting matcht die van Taylor: als je nu al meer dan 10 Claude Code-sessies tegelijk draait en de source code wil lezen, is Gas City het bekijken waard. Voor iedereen daaronder: neem de ideeën, sla de toolkit over.

Voor de meeste van onze klanten is OpenAI's Symphony of een eigen lichte orkestratielaag op Linear/Jira realistischer. Symphony is in essentie een set geschreven regels die jouw bestaande board verandert in het dashboard waarop de agents werken. Dat sluit aan op hoe engineers nu al werken en vraagt geen gedragsverandering.

Wat dit zegt over de richting van engineering

Drie patronen die we vasthouden, los van welke toolkit straks wint:

• Eén gesprek, veel uitvoerders. Het mayor/polecats-model is de manier om met meer dan vijf agents tegelijk te werken zonder de regie te verliezen. Wie nu een agent-architectuur opzet en alle agents als gelijken behandelt, gaat dat over een jaar opnieuw doen.
• Multi-model review is gratis kwaliteit. Het verschil tussen één model en drie modellen op dezelfde diff is groter dan het verschil tussen Sonnet 4.5 en Opus 4.5. Dit is laaghangend fruit waar we voor klanten nu al patches in PR-flows voor schrijven.
• Dark factory komt eraan. Een groeiend deel van software-engineering gebeurt zonder mens in de loop, en de bedrijven die het eerst expliciet maken welk werk in het donker mag, krijgen de grootste throughput-winst. Voor klanten die we begeleiden in agentic engineering is "wat verschuift naar dark" een vaste vraag in elke sprint review.

Gas City is niet het eindstation. Maar als snapshot van hoe een goed onderbouwde multi-agent setup eruitziet, is het een van de eerlijkste die nu publiek beschikbaar is. Honderd agents op één server is geen marketing — het is iemand die het probeert, het opschrijft, en de pijn deelt. Dat is meer dan je van de meeste vendor-demo's kunt zeggen.