A solo spec setup breaks because the thing that made it good never leaves the author's machine. The files, the state, the reasoning, and the rhythm with the model all live in one editor and one person's head. The moment a second person needs in, they get the text and none of the context, and the setup that felt like magic for one stops working for two.
The current state of the art in AI-assisted spec work is a single skilled person in their editor. Someone builds a genuinely impressive workflow inside Cursor or VS Code, a folder of local files, a private cadence with the model, and it produces real quality. It works beautifully right up until the point where it has to stop being one person's setup and become a team's shared way of working, and that is exactly where it falls apart.
Why do solo spec workflows work so well for one person?
Because everything the workflow depends on is in one place, available instantly, never explained because it never has to be. The author knows why each spec exists, what state it is in, what changed since yesterday, and what the model tends to get wrong, all without writing any of it down, because they are the only one who needs it. The context lives in their head and their working directory, and for an audience of one that is enough.
This is real productivity, not an illusion. A single person with a good spec setup genuinely ships faster and cleaner than they did before. The trap is that all of the value is bound to that one person. The setup is fast precisely because it skips everything that would let anyone else use it, and that shortcut is invisible until someone else shows up.
What breaks the moment a second person needs the spec?
The handoff, because what made the spec good was never in the spec. A teammate, a reviewer, or the next person on shift opens it and gets the text without the reasoning behind it, the current state without the history that produced it, the what without the why. They inherit a document and none of the understanding that made it work.
- It is trapped on one machine. The spec lives in someone's working directory and someone's session. Nobody else can see it, act on it, or build on it without a copy-paste or a screen-share.
- The state is invisible. Whether a spec is a rough draft or an approved, ready-to-build contract is something only the author knows, so the second person cannot tell what is safe to act on.
- The reasoning is gone. The decisions that shaped the spec happened in the author's head and their chat with the model, and none of that travels with the file.
- There is no shared lifecycle. A spec is a living thing that moves from draft to approved to building to shipped, but a file in one editor freezes at whatever state its author last touched, and then it rots.
The result is not collaboration. It is serialised individual effort, two people taking turns owning a file and hoping they merged correctly, with the team stitched together by Slack messages and stale copies.
Why doesn't sharing the files fix it?
Because the files were never the valuable part. Copying the folder into a shared drive or a repo moves the text and leaves behind everything that made the text mean something. The second person now has the same words the author had and none of the state, the history, or the reasoning, so they are reading a transcript of a conversation they were not in.
Worse, the moment there are two copies there is no longer one truth. Each person edits their version, the two drift apart, and reconciling them becomes its own job. Shared files give a team N copies of a document slowly disagreeing with each other, which is a different problem from the one a team actually needs solved: one living spec everyone is genuinely working on at once.
Does this get worse as the team or the agent count grows?
It gets worse fast. Ten developers each running their own isolated spec setup will produce more total code than a team with no specs at all, and more conflicts, more duplication, and more architectural drift along with it. Every individual gain gets eaten by the coordination overhead of stitching ten private workflows into one product, because nothing connects them and no one can see across them.
Adding more agents multiplies the same problem. Each agent builds against whatever spec its operator is holding, with no shared picture of what the others are doing, so the duplication and the drift compound. The single-player setup does not just fail to scale. It actively generates work as the team grows, because every private thread of effort has to be reconciled with every other one by hand.
What does a spec setup need to survive a handoff?
It needs the spec to stop being a file someone owns and become a shared object the whole team and its agents work against together. That means one spec rather than many copies, reachable by everyone who should have it, carrying its own state and its own history so that opening it gives the next person everything: the intent, where it is in its lifecycle, what is still unresolved, what changed and who changed it. The context that made it good has to travel with the work instead of dying in the author's head.
This is the wall the builders we work with keep hitting. They have built genuinely brilliant spec setups of their own, and they lose the thread the instant the work moves or a second person needs in. The setup is impressive and it is single-player, and it evaporates exactly when it is needed most, the moment the work stops being one person's and starts being a team's.
| When a second person needs in | A solo spec setup (local files in Cursor, VS Code) | A Canery spec |
|---|---|---|
| Reachable by the whole team? | No, it lives on one machine | Yes |
| Survives a handoff? | The context leaves with the author | It stays with the work |
| One source of truth? | N copies, slowly disagreeing | Yes |
| A lifecycle the team shares? | Frozen wherever the author left it | Yes |
Canery is built so the spec is shared by construction instead of owned by one person. It holds the spec against the codebase it describes, the work as it changes, and the team building from it, so there is one living spec the whole team and its agents work on, its state is something everyone can see, and the reasoning behind it does not walk out the door when one person does. The brilliance of a good spec setup stops being trapped in one editor and starts compounding across the team that actually ships the product.
If this is how you want to work
If you want a spec setup that does not die when a second person shows up, one shared living spec the whole team and its agents work against, with the reasoning and the state travelling with the work, Canery is being built for exactly that. Join the waitlist at canery.ai and be among the first to use it.