Gastown is awesome. Like really fucking awesome.

It’s 70% real, 70% performance art, and 70% a video game. It has vibes, characters, rituals, politics, and this ambient pressure that makes you feel like you’re participating in something bigger than “a tool that edits files.”

And it’s also a glimpse of where software is going.

I saw the memes, liked them, and made my own. Then I did the unthinkable: I spent a full day inside it, and my brain got rewired. It was a Quentin Tarantino movie — slow, then suddenly I’m watching the world of software development disappear, and then everything goes down in flames.

10/10. Mesmerizing. Because that whole experience is the point.

Gastown goes beyond being a cute agent demo. It’s a prototype of a new interface for software work. It’s almost there. And the gap between “almost there” and “actually there” is basically the next decade.

A day in the city

The first time you drop in, it feels like somebody turned half-formed future ideas into a living diorama. You don’t open an IDE. You don’t get a “Welcome! Choose a template!” screen. You get tmux, and that’s instantly the best decision anyone has ever made.

The UX is literally just… being in a terminal. A control room: little windows, and those windows contain agents doing things. And the wild part is: you can watch it. You can watch them talk. If you want to check on the Deacon, you can ask the Mayor, or just tmux over and look.

Message passing between agents is the most compelling “agent thing” I’ve seen in a long time. Not “AI wrote code faster.” Coordination. Distributed work.

It feels like autonomous little machines sending each other sticky notes at warp speed: negotiating tasks, updating each other, shuffling responsibilities like they’re running a tiny company inside your laptop. It’s hypnotic. Like watching ants build a bridge, except the ants are arguing about merge conflicts.

And yes: worktree management works. Parallelism without file-stomping is the difference between “agents are a party trick” and “agents are a strategy.”

On the best day, Gastown feels like: “Oh no. This is the interface.”** **And then…

The refinery crashed, and the mayor forgot his own name

After a full day, I hit the other side of the experience. The refinery crashed. The dogs went AWOL. The deacon died trying to fix it.

I’m not exaggerating. That’s what it felt like. Not “a process died,” but “the city’s power grid collapsed, and now half the institutions are lying about what’s real.”

I tried everything: uninstall, nuke, restart — the modern debugging ritual of “what if I just remove reality and re-add it?”

Nope. Right now, the refinery never comes up, and the mayor forgot he’s even in Gastown.

I’m sure it’s fixable. But I don’t want my workflow to depend on local daemons taking over my machine. And even if you move them to the cloud, the core design still isn’t what I want.

Because bugs aren’t the entire problem. It’s that the system is a chaotic vibe engine that sometimes moves in the right direction. I want more order to the chaos, and I don’t want my local filesystem to be the source of truth. I want the forge to be the source of truth.

When Gastown worked, it felt alive. When it broke, it felt like the concept of truth got corrupted.

The reason is simple: Gastown is local-first. Local-only, really. And local-first is charming right up until you remember what software actually is.

Software is a multi-human coordination problem. Teams don’t run on vibes. They run on shared truth: PRs, issues, history, CI results, approvals, audit logs. That’s where accountability lives. That’s where decisions are visible.

If the system’s state lives only inside my laptop, it’s not a city. It’s a snow globe.

Local state is fog. Remote state is a contract.

The good parts (aka: I am being seduced on purpose)

Let me be clear: I loved this thing. Even as it exploded.

tmux is the right UI. It’s not pretending to be a better IDE. It’s an orchestrator, and it looks like one.

Watching message passing is the new magic. It’s not “autocomplete but bigger.” It’s a new primitive.

Worktree management works. Foundational.

The bad parts (aka: reality is undefeated)

Git repo interaction is… insane

At some point I hit the classic problem every real project is built out of: Where is the actual code?

Not “haha I’m lost.” More like “my brain can’t form a consistent model of what the repo even is right now.”

Nested .gitignores. Weird assumptions. Paths that felt like a dream you have when you fall asleep reading a Bazel config. Repo mixed with Gastown config. Hundreds of CLAUDE.mds and settings files scattered everywhere.

And this matters, because agent tools have to master the real future: ancient monorepos, half-migrated build systems, 14-year-old shell scripts, and “temporary” hacks from 2019.

I also noticed the tell-tale red X next to the last commit merged to main. Maybe I’m OCD, but it’s hard to believe the future of software development is being built in a repo with failing CI. Honestly, I’d believe it more if it had no CI.

Beads

I’m sorry, Steve. I love you. But beads just aren’t for me. Maybe they’re brilliant. But right now, they feel like an opaque, weird filesystem on my laptop, powered by a daemon that keeps taking 70% of my CPU.

Coding was never the bottleneck. Now it definitely isn’t.

Gastown is a preview of agent programming, but the future isn’t “code gets written faster.” The future is: change gets shipped faster. And those are not the same thing.

Teams are trapped because CI takes forever, tests are flaky or missing, review cycles are slow, merge conflicts pile up, confidence is low, production is fragile, and there are “oh god please don’t touch that” zones nobody wants to own.

If this plays out the way I think it will, software engineering turns into CI engineering.

Code is cheap. Green CI is priceless.

In the agent era, your ability to generate change is basically unlimited. The limiting reagent is confidence.

The teams with the best, fastest, highest-confidence CI will be able to point swarms of agents at problems and just click merge — not because the agents are smarter, but because the rails are better.

Guardrails are becoming the new currency

Guardrails used to feel like bureaucracy: approvals, tests, security checks, linting, policy. Now, guardrails are the only thing that makes scale possible. Guardrails are the price of delegation.

Think of it like bowling:

Having no guardrails is like bowling in the dark with the bumpers removed.

Guardrails are bumpers: you bounce around, but you don’t instantly die.

Guiderails are when the bumpers move so close together that the ball can’t wander. It drops into one track and rolls downhill at full speed.

That’s the shift: constraints stop being “stuff that slows you down” and become geometry that makes speed possible. It’s not faster typing; it’s faster, safe movement.

What I want to see: remote-first Gastown (and why multiclaude exists)

Gastown is an insanely compelling local city. But it’s local-first in a way that makes it fragile and trapped. When it breaks, it doesn’t feel like “a bug.” It feels like the city lost consensus reality. And the deeper reason is: guiderails require hard surfaces. You can’t build rails on fog.

Local state is fog. Remote state is concrete.

PRs, checks, review policy, merge history, CI results, audit logs: that’s where teams already store truth. That’s the structure you can actually bolt an agent system onto.

That’s also why I built multiclaude. Multiclaude is my first step on the remote-first journey: keep the part that works (multiple agents coordinating), keep the ergonomics (terminal-first, multiplexed, legible), but orient it around shared reality rather than laptop vibes.

Not “a worldstate database implied by JSON and daemons.” Actual repo state. Actual PR state. Actual CI outcomes.

Because if the state lives only inside my laptop, it’s not a city. It’s a snow globe.

PRs as the unit of work

Tasks should be tracked in PRs (or chains of PRs), because that’s the unit of collaboration teams already understand.

PRs are visible. Durable. And most importantly: they don’t go in until CI is green.

The Refinery becomes a PR queue operator

In the future I want, the Refinery isn’t a local daemon that forgets its job. It’s a conductor. It watches the PR queue and keeps the train moving. It escalates stalled work, manages conflicts, and nudges things forward.

But with one absolute rule: CI is sacred.

The Refinery can never change CI. It can’t cheat. It can’t ship through failing tests. The future only works if the gates are real.

CI + gates + millions of tokens turns this from random thrashing into a Brownian ratchet: most PRs can be garbage, but the improvements accumulate, and the failures don’t.

The punchline: this is the interface… but CI is the reality

That’s why Gastown is so exciting. It feels like the first real attempt at an interface for agent work that’s fun, legible, and alive. It’s not “ChatGPT, write me a function”; it’s a world of coordination.

But the future won’t be won with a dozen Claudes on one laptop. It’ll be won by whoever connects this experience to the institutional machinery of software: CI, review, merge policy, durable state, shared truth.

The best teams won’t be the ones who write code the fastest. They’ll be the ones who can click merge with the most confidence.

And when code is cheap, guardrails are solid, and CI is sacred? Yeah. You really will be able to point a swarm of agents at a problem and just slide down the guiderails into shipping. That’s where software is going.

And Gastown is the first place I’ve been that feels like it’s already there—even while it’s still catching on fire in front of me.

Why I’m sharing this at Chainguard

This is the future of software development, and we’re not going to sit on the sidelines.

We’re going to be using agents internally everywhere: to generate changes, review them, keep PRs moving, unblock humans, and turn the boring parts of software into background radiation.

But we also care deeply about trust. Agents don’t get to be magic. They don’t get to be a black box that “just ships stuff.” If we’re going to scale change, we also have to scale confidence: shared truth, shared visibility, and a shared understanding of what’s happening and why.

So we’re being as transparent as possible. We’re showing the messy parts. The parts that feel like a playable demo of the future, and the parts that catch on fire. We’re building in public (at least internally), naming the sharp edges, and bringing everyone along on the ride.

Because if we’re going to build the next era of software, it should be legible. And it should be ours.

Multiclaude is available here:https://github.com/dlorenc/multiclaude