Stop vibing alone 🎧

Hey tech adventurers! 👋

Last year I did almost all my work in mobs or pairs. One screen, one keyboard passed around, and everyone knew what we were building and why.

That was how I liked to build software.

Somewhere this year it just stopped. Everyone had their own agent, their own setup, their own headphones on, and the mob calls quietly disappeared.

Everyone got faster. Alone. And I don't like it.

I don't want to go back to writing every line by hand. I want the team working together again, running agents collaboratively. Maybe we also get faster.

Solo agents made one person faster, not the team 🎒

An agent on your laptop is a superpower for you. It is a weak setup for a team.

You plan alone, write a prompt nobody else will see, and ship from a private pile of skills. Your teammate opens the same repo with a different tool and a different setup.

Shopify's CEO, Tobi Lütke, called that "split brain problems when different team members use different tools."

You also lose what pairing used to give us for free: shared context, and one finish line.

The individual got faster. The team got quieter.

The idea: run agents as a team 🤝

Stop whispering to a private assistant. Sit down as a team, decide the work, and write the instructions. Let several agents run at once on agreed slices, in the open. Then come back, review, and hand off.

The pairing I miss is with people. The team should still do the thinking together.

What it looks like in practice 👀

Collaborative agent work is mostly about visibility and handoff.

I've been thinking about this for months: how to get a team working on the same project together again. So I started building Paws, a Multiplayer Remote Agentic Software Environment, where the whole team and all our agents build side by side.

I've been using Paws over the last couple of weeks to work on Paws itself. I also started using it at work as a small test, and I hope to expand that to the full team soon.

In Paws, the team's context stays in Linear. Plans and decisions live there, so people and agents can reuse them later. I made a planning skill and checked it into the repo, so when we plan and split the work, everyone and every agent follows the same steps. For planning, I'd use something like Grok Bot or Muse. They'd plan the Linear issues and projects, and then we'd review them together in a sync implementation meeting before agents start building.

And now Cursor is shipping the same idea. They just made Projects multiplayer. The opening line could have been this post's thesis: "Multi-agent systems have so far served one person. Projects is a multi-agent system built for a whole team."

That's useful. Other people see the same problem.

They name the pain: "Today, agent context is siloed per person." A Project adds a shared context system for requirements docs, tech specs, and mockups. "A decision made in one chat is accessible to every agent in the Project."

A shared task board shows who's doing what, and what everyone's agents are working on. That's plan-and-split, in the open. Handoffs are first-class: Cursor describes an on-call rotation where "the new person's agent simply takes it on." And teammates' agents can talk to each other. If your feature reads from a database while a teammate is changing the schema, the agents agree on the order of work up front, instead of finding out in a merge conflict.

If your tool can't do all of this yet, start simpler. Share a screen, or open the branch early. Review together. Not a surprise PR from a prompt nobody else has seen.

What you do together 🧰

Three jobs stay with the team. Everything else can fan out.

1. Plan and split the work.
Look at the problem together. Cut it into slices an agent can finish: a clear boundary, a testable outcome. Agree who owns the merge, and what "done" means, before anyone hits enter.

2. Write the specs or prompts together.
The prompt is the work order. Write it so a teammate could run the same job tomorrow. Keep it short. Say the what and the why.

3. Improve the shared setup and tools together.
One instruction file in the repo. Shared skills and hooks. The lint and tests that mean "done." In my earlier post I argued that your coding agent doesn't need more docs. Same move for a team: encode the rules in CI and hooks everyone shares, not in a personal markdown file.

When an agent fails in a new way, don't just patch that PR. Patch the shared setup, so the next agent doesn't fail the same way. Then the agents run in parallel, and you come back to review.

Maybe we get faster. That's the hope ⚡

I don't have a study for this.

The hope is simple. Planning together means less rework. Parallel agents mean more than one slice moves at once. Visible work means the next ticket starts warmer, and anybody can pick it up.

The risk is also simple. Coordination costs time. Merges collide. Review becomes the bottleneck if five agents finish and only one human is looking.

Treat it as an experiment. If a week of this is slower than solo agents, you'll know. If it's faster and you get the team back, that's the win I'm after.

The honest pushback 🧪

A team running many agents still has to be careful about scope. Even one person hits a wall trying to keep every agent's work in their head. A team doesn't automatically fix that. If we just multiply private threads, the bottleneck gets worse. A shared board and shared context help cut that tax. They don't remove it. Go deep on a few agreed slices, and keep the work where everyone can see it.

Don't ban personal experiments. Spike alone if you want. Ship from the shared setup.

And if all you improve is the shared tooling, and nothing useful ships, you just maintained tools.

How to start this week ✅

1. Book one planning session. Split the work out loud. Write the prompts or specs together. Agree on done.
2. Check in the shared basics: one instruction file every tool can read, the checks that block a bad merge, a definition of done an agent can execute.
3. Make the work visible, then fire more than one agent on the slices you just agreed. If you have a shared Project, use it. Otherwise share the screen or the thread.
4. Review the output together. Hand the work off if someone has to drop. Patch the shared setup when something fails for a repeatable reason.
5. Keep a small sandbox for personal tools. Promote what survives a real PR. Delete the rest.

What you need is a decision: the team runs the agents, together.

I want the team back, and I want the speed too 👋

I miss building with people. Agents made it easy to disappear into a private workflow. I want the team back, with the work visible and the agents running in parallel.

So ask yourself one question.

This week, could your team plan one slice of work together, point two agents at it, and review the result in the same room?

If the answer is no, start there. Not with another personal skill. With the team. 👥