Development is fast; deciding what to build, clearly, is the slow part
By Soumen Sarkar · October 2026
Problem. "Development is fast now. Deciding what to build, clearly, is the slow part."
When an agent builds a feature in an afternoon, a vague spec turns into the wrong feature by lunch. Product teams keep up by writing each decision down with its reason, putting what the business knows on the part of the product it affects, and reading the plan before anything is built.
Why does deciding feel slower than building now?
Because building stopped being the slow part. An agent reads a spec and builds it the same afternoon, exactly as written. A gap in the spec stays in the product. A phrase like "make the export better" becomes whatever the agent thinks better means.
Nothing is wrong with the agent. It does what it is told, fast and well. What breaks is between people: the product manager knows which customer asked, the founder knows the pricing call, support knows what users complain about. None of that is in the spec, so none of it is in the build.
What makes a decision clear enough to build from?
Three things, and none of them is a longer document.
- The call and its reason, in a sentence. From our own record: "Campfyrr never takes code or diffs," because the first thing teams ask is "Will it store our code?" The reason lets an agent handle the cases the sentence doesn't name.
- The business context, on the part of the product it affects. A customer's words, a pricing call or a deadline, attached to the area where the work happens, not buried in a chat thread.
- A plan someone reads before the build. A short plan costs a minute to read and saves an afternoon of building the wrong thing.
Tools for agents point the same way. Claude Code's plan mode reads files and proposes a plan, and it makes no edits until you approve. GitHub's Spec Kit puts it as "define what and why before deciding how to build it." Both are good at the single session. The harder part is the team: the reason has to reach every session that touches the same ground, including ones started next week by someone else.
What does a clear decision look like in practice?
Here is a real one from our own record. A competitor review found that the name of our product's feed, "the Lore", clashed with other tools:
Rename "the Lore". Lore.link, SpecStory's /lore skill, buchbend/lore,
BYK/loreai, Alpharages/lore and loremem all use the word.
It will confuse buyers and dilute search. Suggested: "the Record".
That is the call, the reason and the suggested answer, in three lines. The rename went through the page, the agent tool, the briefs and the updates in one pass. Without the reason, a later session could reasonably "fix" the name back.
What does Campfyrr do about it, and what doesn't it do?
Campfyrr is shared team memory for Claude Code. For deciding what to build, it does four things today:
- Decisions with reasons, recorded as they're made and given to every session that works in that area. See where decisions should live.
- Business context on an area. Anyone on the team adds a customer's words, a pricing call or a deadline to a part of the product. Agents working there see it in their brief under "From the business". See how customer requests reach agents.
- Plans published as links, so a product manager reads the plan before the build. See publishing a plan from Claude Code.
- Assumptions instead of questions. When the spec is silent, the agent states what it assumed and keeps going. The right person confirms or corrects it from a link.
It doesn't write your specs or decide for you. It doesn't replace your tracker or your roadmap. Settling a decision from a shared link isn't there yet; answering an assumption from one is.
Where should a product team start?
- Write the next decision as one sentence with a "because".
- Attach one customer's words to the part of the product they affect.
- Ask for the plan before the build, and read it.
- Answer the first assumption an agent states, from its link.
For the habit behind this, read decide by doing and recording decisions as agents work.
Everything on this problem
- For you: For product managers: deciding clearly when agents build in hours: When agents build a feature in hours, a product manager's job is to decide clearly and early. Campfyrr lets you answer an agent's product assumptions from a link, put what you know on the part of the product it affects, and see what's being built in plain words, on a free seat.
- Story: The spec that got built exactly as written: An agent builds a one-line spec exactly as written, fast and well, and it still isn't what the product manager meant, because what she meant never left her head. Write the decision down with its reason, put the customer's words where the agent reads them, and read the plan before anything is built.
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).