Steve Yegge’s Gas Town dropped last week - an orchestration system for running 20-30 agentic AI workers in parallel. Reading through his 25-page manifesto, I kept getting this feeling of deja vu.
Almost 20 years ago, fresh out of college, I landed my first software job at Moodle. I barely knew how to use git. Definitely didn’t know Jira. What I did learn was a development workflow that, looking back, rhymes with what Yegge is building today.
The Integration Workflow
Moodle’s development process has been refined over two decades. The core insight:
“We use a workflow that ensures that new code receives multiple reviews by different people before it is included into the core Moodle code.”
Our team was maybe 15-20 developers. Throughout the week, we’d work on our tasks independently - writing code, getting peer reviews, making sure our branches could apply cleanly to master.
The real gatekeeping happened at integration review.
Monday to Thursday, the integration team - a small group of senior developers - would conduct code-level review of everything in the integration queue. One issue at a time. Carefully. Problems meant rejection, back to the developer for more work.
Only after passing integration review did code move to the testing queue, where dedicated testers would verify each fix actually solved what it claimed to solve. Thursday and Friday were for this - both manual QA and automated tests.
If everything passed, production maintainers would merge the tested code into the production repository on Thursday. If not, back to the developer.
At the time, I thought this was just how software development worked. I didn’t appreciate what problem this multi-stage pipeline was solving.
Being the Refinery
Years later, I found myself on the other side of that bottleneck.
In 2018, I worked on the Lupin the Third XR Ride for Universal Studios Japan - a VR experience overlaid on the Space Fantasy roller coaster, part of their seasonal Cool Japan promotion. Last hurrah for their Samsung GearVR headsets. Mixed team: game developers, film animators, artists from different disciplines who didn’t always speak the same technical language.
As the real-time specialist on the project, I ended up being a one-man integration team. Everything had to converge into a single Unity project running at 60fps on mobile VR hardware strapped to a roller coaster. Someone had to understand all the pieces well enough to merge them without breaking the frame budget or the art direction.
That was me.
No formal process like Moodle’s. No tracker tickets or Thursday release schedules. But the same pattern emerged organically: parallel workers producing assets independently, and a serialized integration point where someone with cross-domain knowledge reviewed everything carefully before it went into the build.
I didn’t have the vocabulary for it then, but I was playing the role of Yegge’s Refinery.
The Merge Queue Problem
Parallel work gets messy at integration time.
Ten developers working independently will produce changes that conflict. Not always in the git sense - sometimes the code merges cleanly but the functionality clashes. Developer A refactored the authentication module. Developer B added a feature depending on the old structure. Both changes fine in isolation. Together, broken.
On the Lupin project, same dynamic. Everything might work in isolation, but together it can be a mess.
Yegge describes something similar in Gas Town:
“As soon as you start swarming workers, you run into the Merge Queue (MQ) problem. Your workers get into a monkey knife fight over rebasing/merging and it can get ugly.”
His solution is the Refinery - a dedicated agent whose job is processing the merge queue, one change at a time, resolving conflicts or escalating when it can’t.
That rang a bell.
Rhymes Across Decades
The Moodle integration team plays a similar role to Gas Town’s Refinery. Senior developers who understand the codebase deeply enough to catch semantic conflicts, not just textual ones. Who can look at two changes and say “these both work, but they can’t coexist.”
Moodle also has Component Leads - developers responsible for particular modules who “should be called upon to complete peer reviews for code in their components.” Gas Town has the Witness - an agent that monitors workers, detects when they’re stuck, nudges them back on track. Different mechanisms, similar function: experienced oversight catching problems before they compound.
The Deacon in Gas Town runs patrols, manages agent lifecycles, keeps the system humming. At Moodle, that’s the release process itself - the steady Thursday rhythm of production maintainers merging what passed, the automated CI pipeline, the scheduled point releases every two months.
Not claiming these are identical systems. Human teams and AI swarms operate differently in important ways. But the shapes rhyme.
Patterns That Persist
Yegge arrived at this architecture through experimentation with agentic AI - his fourth orchestrator of 2025, he says. Moodle’s process evolved over two decades through hard-won experience with distributed open-source development. I stumbled into the same pattern on a theme park VR ride, just trying to ship something that worked.
All three landed on similar structures:
- Parallel workers producing changes independently
- Peer review as a first filter
- A serialized integration point where experienced reviewers check everything carefully
- A testing phase before changes hit production
- Monitoring to catch stuck or struggling work
Maybe these patterns emerge naturally whenever you have multiple autonomous agents - human or otherwise - producing work that needs to converge. The Moodle development process might be a kind of proto-orchestration system, refined by years of “what went wrong last time.”
Reading about Gas Town’s Refinery and Witness and Deacon felt oddly familiar.
But wait Jetha, don’t you work for Google?
At Google, I don’t write production code. I’m on our AI Developer Experience team. I write samples and proofs of concept when I write code at all - usually quite far from our internal tools.
I’m sure if you looked at our tools for changelists and managing code merges, you’d see quite a lot that rhymes.
-J