The important audit at my company is conducted by the FDA.

I have a feeling when they ask what processes we followed to mitigate any user harm that could be caused by software changes that "I told an AI-mayor in the form of a cartoon fox what to do and he spit out a bunch of vibecode software written by AI-driven virtual cartoon characters" is not among the answers they want to hear.

Let's assume that managing context well is a problem and that this kind of orchestration solves it. But I see another problem with agents:

When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it's small, like the selection of a data structure. Eventually, though, you want to add a feature that clashes with that invariant. At that point there are usually three choices:

* Don't add the feature. The invariant is a useful simplifying principle and it's more important than the feature; it will pay dividends in other ways.

* Add the feature inelegantly or inefficiently on top of the invariant. Hey, not every feature has to be elegant or efficient.

* Go back and change the invariant. You've just learnt something new that you hadn't considered and puts things in a new light, and it turns out there's a better approach.

Often, only one of these is right. Usually, one of these is very, very wrong, and with bad consequences.

But picking among them isn't a matter of context. It's a matter of judgment and the models - not the harnesses - get this judgment wrong far too often (they go with what they know - the "average" of their training - or they just don't get it). So often, in fact, that mistakes quickly accumulate and compound, and after a few bad decisions like this the codebase is unsalvageable. Today's models are just not good enough (yet) to create a complete sustainable product on their own. You just can't trust them to make wise decisions. Study after study and experiement after experiment show this.

Now, perhaps we make better judgment calls because we have context that the agent doesn't. But we can't really dump everything we know, from facts to lessons, and that pertains to every abstraction layer of the software, into documents. Even if we could, today's models couldn't handle them. So even if it is a matter of context, it is not something that can be solved with better context management. Having an audit trail is nice, but not if it's a trail of one bad decision after another.

At this point it should be clear that Gas Town has done something we can evaluate the value of.

So I slapped together my own Beads implementation (https://codeberg.org/mutablecc/dingles) over a day or two. Probably has bugs, and I'm sure race conditions if you tried to use with Gas Town, and likely does not scale. But it has the minimum functionality needed to create and track issues and sync them (locally and remotely, either via normal merge, or a dedicated ticket branch). No SQL, no extra features, just JSONL and Git. Threw a whole large software project at it, and the AI took to it like a duck to water, used it to make epics for the whole project, methodically worked through them all, dependencies first, across multiple context sessions. The paradigm of making tools the AI wants to use is clearly a winner.

I wound up building my own with Claude, I made it SQLite first, syncs to GitHub, can pull down from GitHub, and I added "Gates" to stopgap Claude or whatever agent from marking things complete if they've not been: compiled, unit tests run, or simple human testing / confirmation. The Gates concept improved my experience with Claude, all too often it says it finished something, when in fact it did not. Every task must have a gate, and gates must pass before you can close a task. Gates can be reused across tasks, so if "Run unit tests" is one gate, you can reuse it for every task, when it passes, it passes for that one task <-> gate combination.

Anyway, I'm happy for Beads, Gas Town not so much my wheelhouse on the other hand.

So now you have agents of type mayor, polecats, witnesses, deacons, dogs etc plus a slew of Unneeded constructs with incomprehensible names.

In one of the blog post for gas town I remember reading something by the author along the lines of « it’s super inefficient, but because you burn so many tokens, you still get what you want at the end! » clearly this is also the design philosophy behind this project, just (get your ai to) throw more random abstractions and more agent types until you feel like it kinda works, don’t bother asking yourself if they actually contribute anything.

This gave me the very clear feeling that most of the complexity of gas town is absolutely not needed and probably detrimental.

Ended up building my own thing that is 10x simpler, just a simple main agent you talk to, that can dispatch subagents, they all communicate, wake each other up and keep track of work through a simple CLI. No « refinery » or « wasteland » or « molecule » or « convoys » or « deacons » or …

I think Yegge's instincts that making a programmable / editable coordination layer (he calls this gas city) is a great idea. Gas town early days was definitely a wild experience in terms of needing to watch carefully lest your system be destroyed, and then I put that energy into OpenClaw - I'll probably spin up Gas City and see what it can do soon though. Very cool.

I think he's boxed himself in by continually layering more complexity on his approach, rather than stepping back and questioning the fundamentals or the overall direction.

All of the steps Gas Town or Gas City etc are taking are towards reducing human oversight and control. This is profoundly misguided! In a world of infinite cheap software it is precisely this human decision making and control that matters.

> There will be nothing like it. You are going to want to use Gas City.

No. I do not want to talk to the mayor of my software factory, as its cartoonish minions build an infinite mountain of slop. Unreviewable, both in terms of code and the finished product.

Instead, I want to precisely capture human ideas, have those ideas questioned, challenged, improved, and then I want to bring those ideas to life, keeping the human in the loop whenever they want. Neither Beads, Gas Town, nor Gas City or anything like them are required for that.

Seems like I'm back to obscurity.

:)

But this is genuinely cutting-edge, new paradigm of building software. Something that will iron it's kinks out, and potentially be the way of developing software in the new Era. That's worth some curious and exploratory discussion, rather than more comments about not being the "true way of software development".

(Sorry, was put off by the crab-pulling down discussion.)

It is pretty magical to go from brainstorming an idea in the evening, having ChatGPT Pro spit out a long list of beads to implement it, leaving it running over night in a totally empty repo and waking up to a mostly-implemented project.

I tried tracking down where those numbers came from and the sources were a bit sketchy. Can anybody who has used Gas Town confirm those numbers, or report their personal numbers?

In the end, it didn't feel worth it mostly because of high token overhead (inter agent communications, agents re reading same code, etc...) and synchronization / cooperation issues (who should do what).

What actually works for me and provides good results: multi step workflows with clearly defined steps and strong guidance for the agent.

This is a desirable end state for highly social but perhaps slightly sociopathic extroverts who want to spend all day talking even though they aren't talking to a person.

For anyone else, it's hard to imagine considering that a desirable way to spend eight hours a day.

They have knowledge about how programs can be structured in ways that improve overall maintainability, but little room to exercise that knowledge over the course of fulfilling the user’s request to add X feature.

They can make changes which lead to an improvement to the code base itself (without adding features); they just need to be asked explicitly to do so.

I’d argue the training objective should be tweaked. Before implementing, stop to consider the absolutely best way to approach it - potentially making other refactors to accommodate the feature first.

Hang in there, there will be a lot of slop to fix in contract work...

No.

I see this sentiment often, repeated a couple times in here, but I don't understand why on earth that would be the case. Gas Town was released a little over three months ago. It's an ongoing open-source experiment at the bleeding edge of vendor-agnostic multi-agent orchestration.

I was using gastown for fire-and-forget prototyping of larger projects. It was flaky and scorches tokens but it was able to get larger prototypes done than I could with a single instance of my daily river (claude) alone.

Interesting:

> Kubernetes asks “Is it running?” Gas Town asks “Is it done?” Kubernetes optimizes for uptime. Gas Town optimizes for completion.

https://embracingenigmas.substack.com/p/exploring-gas-town

I am very confident in saying that most individuals successfully using multiple agents have done so by building their own harness.

How did you implement gates? Are they simply tasks Claude itself has to confirm it ran, or are they scripts that run to check that the thing in question actually happened, or do they spawn a separate AI agent to check that the thing happened, or what?

Although I think the post also self-diagnoses some factors that also help:

  With the Gas Town Mayor, you feel like you’re operating at a special level, a VIP, above all the workers. You are talking to someone important: the mayor of a factory the size of a town. You have access to someone with resources, someone who gets you, someone who appreciates how busy you are.

  Working with regular coding agents just doesn’t give you that special feeling.

I mostly agree with you other than this one sentence.

Let's say you're building the literal antithesis of Gastown: an AI agent software specifically designed to be human reviewed and monitored. How to you make this as efficient as possible? Well, it's by ensuring high quality results from human oversight and control while spending the least amount of time. Which to be precise, is still reducing human oversight and control per unit of useful work done.