You can run a dozen coding agents. Your dev environment can only handle one.

The big promise of coding agents is that you can stop babysitting one of them and start running ten at once. I tried it, and the first thing I discovered was that my dev setup had absolutely no interest in cooperating.

The trouble is that everything downstream of the code assumes there's only one of you. Two agents on two branches both want to talk to Postgres, and there's only one Postgres sitting on port 5432. One of them runs a migration and the schema shifts under the other's feet. They're sharing the same containers, database and env file, so whatever one of them touches, the rest inherit whether they like it or not.

Try to run ten of them at once and they spend more time tripping over each other than getting anything done. So you give up and go back to one at a time, which defeats the object of having ten agents in the first place.

I got fed up of this, so I built something to fix it. It's called Steckling, the command is steck, and it does exactly one thing: it gives every branch its own isolated world, so an agent working on a branch isn't fighting anyone else for anything.

It's got three moving parts, but none of them are especially earth-shattering in and of themselves:

A folder per branch. steck new <branch> spins up a git worktree in its own directory, so there's no stashing and switching inside one shared checkout.
A private stack per branch. It brings up a separate Docker Compose project, with its own containers, volumes and network, on whatever ports happen to be free. Branch A's database and branch B's database are simply different databases on different ports, completely unaware of each other.
The environment, wired up for you. It writes that branch's own connection URLs into a gitignored env file and runs your usual dev command with them loaded. The app still runs natively on your machine, with only the services going in Docker.

It doesn't much care what you build with, either, because the engine only ever touches git, Docker, ports and environment variables. It has no opinion about your language or your framework, and it never needs one.

It's not only useful for stables of agents - anyone who has switched branch to look at a PR and found the database still full of the last branch's half-run migration knows the feeling. You can switch branches in a second, but the database can't. It's the same fix, whether the thing on the other branch is a person or an agent.

It's on Homebrew, and there's a plain install script if you'd rather:

brew install timd/steckling/steckling
curl -fsSL https://raw.githubusercontent.com/timd/steckling/main/install.sh | sh

All it wants is git and Docker, since the runtime is baked into the binary. The code is on GitHub at github.com/timd/steckling, and there's an MCP server built in, so if you want the agents to drive the whole thing themselves rather than you doing it for them, they can.

None of this is clever, and that's pretty much the entire point. The interesting problems with running a lot of agents turn out not to be about the models at all. They're about the plumbing - who gets port 5432 or which migration wins. Dull, solvable problems. So I solved one of them.