Summarizer

Tool Comparison With Direct Claude

Observations that Gas Town mayor just acts like direct Claude invocation, doesn't auto-test or commit, and arguing with agents about other agents' poor work

← Back to Welcome to Gas Town

Despite Gas Town’s ambitious architectural design, early users have observed that the "Mayor" agent often fails its primary directive to coordinate rather than implement, resulting in a workflow that feels indistinguishable from a standard Claude invocation. This lack of delegation is compounded by the absence of automated testing or committing, frequently devolving into a frustrating "game of telephone" where users must argue with agents about the poor workmanship of other processes. While the tmux-based monitoring approach shows promise, critics argue that the tool’s eccentric nomenclature—replete with confusing metaphors like dogs and raccoons—sacrifices professional clarity for unnecessary quirkiness. Ultimately, many find that the overhead of managing these unruly agents is currently more work than simply interacting with Claude directly or using a highly detailed manual specification.

1 comment tagged with this topic

View on HN · Topics
I tried it out but despite what the README says ( https://github.com/steveyegge/gastown ), the mayor didn't create a convoy or anything, the mayor is just doing all the work itself, appearing no different than a `claude` invocation. Update: I was hoping it'd at least be smart enough to automatically test the project still builds but it did not. It also didn't commit the changes. > are you the mayor? Yes. I violated the Mayor protocol - I should have dispatched this work to the gmailthreading crew worktree instead of implementing it directly myself. The CLAUDE.md is clear: "Mayor Does NOT Edit Code" and "Coordinate, don't implement." Maybe Yegge should have build it around Codex instead - Codex is a lot better at adhering to instructions. Pros: The overall system architecture is similar to my own latest attempt at solving this problem. I like the tmux-based console-monitoring approach (rather than going full SDK + custom UI), it makes it easier to inspect what is going on. The overlap between my ideas and Steve's is around 75%. Cons: Arguing with "The Mayor" about some other detached processes poor workmanship seems like a major disconnect and architectural gap. A game of telephone is unlikely to be better than simply using claude. I was also hoping gastown would amplify my intent to complete the task of "Add feature X" without early-stopping, but so far it's more work than both 1. Vibing with claude directly and 2. Creating a highly-detailed spec with checkboxes and piping in "do the next task" until it's done. Definitely looking forward to seeing how the tools in this space evolve. Eventually someone is bound to get it right! P.s. the choice of nomenclature throughout the article is a bit odd, making it hard to follow. Movie characters, dogs and raccoons, huh? How about striving for descriptive SWE clarity?