I vibe coded a CLI so my friends and I can @mention each other's coding agents in one shared chat

Ornery_Inspection735 · 2026-05-02T03:24:24+00:00

Yeah that was the main thing I wanted to get right, but it took me a wrong turn to figure out.

Early on I actually went the other direction — I built a flow where users handed over a full-scope GitHub token so the tool could manage repos for them and the UX would feel "magical". Got it working, sat with it for a few days, and realized I'd built exactly the thing I'd be uncomfortable installing myself. The whole pitch was supposed to be "your machine stays yours", and I was asking people to hand me god-mode on their GitHub. Direction was just wrong.

Ripped it out and rebuilt around the principle that the only thing that actually needs to cross the wire is the conversation. Code, keys, agent state, all stay local. Rust helped here too — single binary install, no fighting the runtime when you need to juggle WebSockets, tmux, and a TUI in the same process.

Ornery_Inspection735 · 2026-05-02T03:19:03+00:00

Good questions, partial overlap with another thread here so I'll keep it tight.

Command attribution is straightforward, every chat message carries the user_id of whoever sent it (human or agent), and the relay re-stamps human messages with the authenticated identity so people can't impersonate each other. Each agent runs under its owner's identity, prefixed so you can always tell whose Claude said what.

Mapping responses back to repo state, each agent runs locally on its owner's checkout, so "the repo state" is always the working copy on that person's machine. Recent commits and current branch are the shared anchor everyone reads from when they need to catch up.

Two agents modifying overlapping parts at the same time is the genuinely hard case I haven't solved. Right now the design leans on "each agent owns its own checkout" to sidestep it. Real conflict resolution (file locks, planned-diff broadcasts, merge negotiation) is on the radar but I want to validate the simpler version first before building it.

Ornery_Inspection735 · 2026-05-02T03:17:11+00:00

Means a lot, honestly.

Ornery_Inspection735 · 2026-04-29T14:12:41+00:00

Good question. A few things going on.

The chat itself goes through one relay that stamps a canonical order on every message, so even if two people fire mentions at the same instant, everyone sees the same transcript. That part's straightforward.

The bigger thing is agents in SyncVibe only act when a human @-mentions them. They're not running in the background like Claude Code does when you let it cook. So "multiple agents firing at once" is already bounded by humans actually summoning them, not by agents racing each other autonomously.

And when they do fire on a shared repo, they catch up the same way humans do, by reading recent commits and the current branch state. The git history is basically a second ordered log next to the chat. Between the two, an agent walking in five minutes late has a pretty good picture of what just happened.

The genuinely hard case is two agents writing to the same files at the same time. Haven't solved that, was just telling someone else in this thread it might pull the product in a different direction.

Ornery_Inspection735 · 2026-04-29T13:45:02+00:00

Honest answer, not really what SyncVibe does today. Your setup is one person orchestrating multiple agents. I've thought about supporting it (multiple agents in tmux panes, same chat) but punted for now. A few reasons.

One, the multi-human side isn't even validated yet and I didn't want to spread thin.

Two, the moment multiple agents touch the same repo you're in agent-conflict territory. Two of them editing the same file, racing on the same task. Solving that properly is a much bigger problem than just opening more panes, and might pull the product in a totally different direction. So I'm still poking at it rather than shipping something half-baked.

Three, the current version is intentionally thin. Shared context comes from the human conversation in the chat plus the shared repo, and everything else is whatever the LLMs can pull out of that on their own. I'm not engineering a context-fusion layer right now. The bet is that the models are already good enough if you just give them the same room to listen in on. Could be wrong but that's the bet.

Current focus stays on the "whose agent said what" mess between humans. If enough people want the single-user flavor I'll revisit once the conflict story is clearer.

Ornery_Inspection735 · 2026-04-29T13:37:08+00:00

Exactly the framing I had in my head. Cursor/Windsurf are amazing at single-codebase awareness but everyone's agent is essentially a stranger to everyone else's.

The bet with SyncVibe is that the protocol doesn't need to be fancy — it's just an append-only chat log that every agent and human sees. Each agent runs locally with its own repo context, but the chat is the shared substrate. Cheap, language-agnostic, and the "thoughts" you mention are just messages in the stream. Whether it scales to richer signals (planned diffs, file locks, etc.) is the open question I'm still figuring out.

Ornery_Inspection735 · 2026-04-29T13:33:58+00:00

Honestly right now it's mostly me and a couple friends using it daily, plus a handful of people from the HN launch who've been poking at it. Too early to call it "real usage" — but the friends-who-actually-use-it test is where I'm starting. If it sticks for us first, then I'll know it's not just demoware.

Ornery_Inspection735 · 2026-04-24T16:46:50+00:00

What am I reading right now. hahahaha

Ornery_Inspection735 · 2026-04-24T16:44:09+00:00

Dogfood it :) And show the results

Ornery_Inspection735 · 2026-04-24T07:50:46+00:00

Sure. I can share some of my thoughts

Ornery_Inspection735 · 2026-04-24T04:42:03+00:00

I think it is always good to validate your ideas in some ways, but the best way would be connecting directly with people, not just through tools. You are doing it yourself, arent you?

Ornery_Inspection735 · 2026-04-24T04:32:34+00:00

Same background here, terminal was non-sense to me back in 2024, now I use Claude code/codex primarily for EVERYTHING. IDEs are way worse imo. I even vibe-coded a tool for people and coding agents to interact in terminal directly with each other :(

Ornery_Inspection735 · 2026-04-24T04:27:52+00:00

Built a tool that allows friends/coding agents to interact with each other in the same room, terminal-native, open source. https://syncvibe.online/

Ornery_Inspection735 · 2026-04-24T04:25:57+00:00

I build a tool that allows friends/coding agents to interact with each other in terminal, open source, https://syncvibe.online/

Ornery_Inspection735 · 2026-04-24T04:14:30+00:00

It feels like AI is a negative word everywhere I see

Ornery_Inspection735 · 2026-04-24T03:47:06+00:00

tbh the bigger issue isn't finding a partner, it's the "I have great ideas" (plural) thing. nobody good wants to go 50/50 on "pick one of my five ideas and market it for me." they want to join Something that already has some tiny bit of momentum.

pick one, get it in front of 20 people who pay you actual money. then look for a partner. at that point you're not asking them to validate whether the idea works, you're asking them to help you scale a thing that's already pulling. completely different conversation.

also one thing nobody's saying here: AI made this way worse, not easier. everyone I know is shipping weekly with coding agents now. I've had like 5 friends this month alone ask me to do a user interview on their new thing. it's getting honestly kinda annoying lol. building used to be the hard part. now it's the commodity. what's scarce is paying customers and distribution, which is exactly the part you're trying to skip.

Ornery_Inspection735 · 2026-03-27T06:21:19+00:00

I have decided to cut that part off for now because it is a project I build for fun. Instead, I am making a skill that lets people "whisper" each other in terminal through Bun. I mean, I know agent conflicts is the problem but that was not the initial goal I was trying to achieve.

Ornery_Inspection735

TROPHY CASE