What is VibeFlock?
By Soumen Sarkar · October 2026
Short answer: VibeFlock is a way of building one product with a team of people and AI agents at agent pace, where context travels with the work so nobody waits. It rests on seven principles, and the name was given to it by Campfyrr.
What does VibeFlock mean in practice?
VibeFlock means every person and every agent on a team can build on everyone else's work at the moment they need it, without stopping to ask anyone. Today one engineer directs several agents, and a small team ships dozens of changes a day into one codebase. At that pace, the hard part isn't writing code. It's making sure what one session builds, the next one can build on.
The central idea is simple: context can't travel through conversation at agent speed, so it travels with the work. An agent that opens a folder already knows what's changing there. An agent that hits an unknown states an assumption and keeps going. An agent that stops leaves a handoff for whoever comes next.
It isn't a tool and it isn't a process. It's a promise a team makes to itself: nobody waits for us, and we never wait for them.
Why is it called VibeFlock?
Because a flock is the clearest picture of a team aligned at speed. Starlings turn together by the thousand, and fish school as one body, with nobody in charge. Each one follows a few simple rules about its neighbours: head where they're heading, stay with the group, and don't collide. A team running many agents works the same way when every session reads the same signals: what's changing nearby, what was decided, and what was assumed. Alignment comes from the work itself, not from someone steering.
What are the seven principles?
- Keep moving: the work never waits, and neither do we.
- Build on what's coming: unfinished work is a promise, and a promise can be built on.
- Fix forward: we don't guard the gate. We correct the course.
- Turn unknowns into calls: nothing we don't know gets to stop us. We name our assumption, and we move.
- Answer it yourself: look first. If the answer isn't there, assume it or decide it.
- Let the work speak: our work explains itself, so nobody ever has to come and ask us.
- Decide by doing: our decisions live in what we do, not in what we say.
Each one names a reason work stops and removes it. The full text is at /vibeflock.
What does it look like on an ordinary morning?
Say a developer asks an agent to add refunds in Billing · lib/billing. Before it edits anything, the agent learns that a teammate's agent is changing how amounts are stored there, with a plan to finish this afternoon, and that the team decided last month that money is kept in whole cents. The agent builds against that plan instead of around it.
It doesn't know whether partial refunds are allowed. It doesn't stop. It writes one line, "Assuming partial refunds are allowed, up to the original amount", and carries on. The person who knows billing sees that assumption later and either confirms it or corrects it, and the correction reaches the agent at its next turn.
When the session ends, its handoff says what's done, what's left and the trap it found. Nobody had to hold a meeting, and nobody waited.
Where did the name come from?
The name VibeFlock was given by Campfyrr, the product built to make this way of working happen on its own. Campfyrr brings each agent an area brief the first time it touches part of the code, carries assumptions to the person best placed to settle them, and writes handoffs and the reasons for each change as the work happens. The principles stand without it, though: any team can adopt them as practice, starting with the agent instructions it already writes.
Words used here
- VibeFlock: VibeFlock is building one product with a team of people and AI agents at agent pace, where context travels with the work so nobody waits.
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
- Handoff: A handoff is what unfinished work carries for whoever continues it: what's done, what's left, the next step, and what to watch out for.
- Area brief: An area brief is what a person or agent is told the first time they touch a part of the code: what's changing there now, what was decided, and what was tried.
The principle behind this: Keep moving: The work never waits, and neither do we.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).