The spec that got built exactly as written
By Soumen Sarkar · October 2026
Story. 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.
What happens when a spec is built exactly as written?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's ten past nine on a Tuesday, and I'm sitting across the table from Lena. She's the product manager for a small invoicing app used by design studios and freelancers.
Near the top of her list is a request she's heard three times in a fortnight: "Can we export our invoices?" Two of the people asking are accountants who look after several studios each. Lena talked to both last week.
She writes the ticket in one line: "Add CSV export to the invoices page." She tags Omar, who owns billing, and goes to her ten o'clock.
At half past nine, Omar gives the ticket to his agent, word for word, and it's a pleasure to watch. It reads the invoices page, finds the query behind the list, and writes a short plan. It adds an "Export CSV" button above the table. It writes one row per invoice, with every column the table shows. It handles empty fields and odd characters, and writes tests for each. Omar nods and lets it build.
By a quarter to twelve there's a clean pull request, and the tests pass. Omar reviews it carefully and merges it before lunch. He posts in the team's chat: "CSV export is live on invoices."
At three, Lena tries it before she tells the accountants. A file arrives at once, and I watch her scroll.
One row per invoice. The total in one column, tax folded inside it. Every invoice the studio has ever sent, from the first one, four years ago.
She sits back. "That's what I asked for," she says quietly. "It isn't what I meant."
What she meant was this. The accountants close each studio's books at month end. They need that month's invoices only, one row per line item, with tax in its own column, because that's how their bookkeeping software takes the file in. One of them told Lena so on a call. None of it was in the ticket, or anywhere the agent could read.
The agent did exactly what the ticket said, and did it well. Omar reviewed it well. What went wrong happened before either started: the decision was made on a call and in Lena's head, and only one line of it travelled.
The agent will rebuild it in an hour. But the accountants won't get their file this week, and Lena has to write and explain why.
I come back the next Tuesday.
The team has changed two things. Before a session builds anything a customer will use, it publishes its plan as a page with a link, and someone who knows the customer reads it first. And when Lena makes a product call, she writes it down with its reason, on the part of the product it affects, where the agents working there will see it.
At nine, Lena writes the next ticket. The accountants have asked for something else: a way to mark several invoices as paid at once. She still writes the ticket in one line. But first she records a decision on billing: "Bulk actions are for month-end bookkeeping, because the accountants who asked close several studios' books at once." Under it, she adds what one accountant said on the call: "I mark forty invoices paid on the last day of the month, one at a time." It takes four minutes.
At half past nine, Omar's agent starts. Its brief for billing already shows Lena's decision and, under "From the business", the accountant's words. It plans a checkbox on each row, a "Mark as paid" action for the selection, and a filter by month so the accountant can pick the whole month in two clicks.
Then, before it writes any code, it publishes the plan: five plain sentences and a sketch of the screen, as a page with a link. At the top it lists one assumption: "Assuming the paid date is today's date for every selected invoice."
At 9:52, on her way to the kitchen, Lena opens the project's Activity feed on her phone. The plan is there with its link, and the open assumption links to its own page. She reads the plan in a minute, the way an accountant would. She stops on the assumption. "No," she says. "They mark them paid on the day the money arrived." She corrects it from the link in one line: "Ask for the paid date once, and apply it to every selected invoice."
That's all. Under two minutes, with the kettle on.
At its next turn, the agent reads her correction, changes the plan and publishes it to the same link.
At half past eleven, Omar reviews the code, with the decision, the accountant's words and Lena's correction beside it. He merges it. At two, Lena picks a month, ticks forty invoices and sets one date. It's what she meant.
She writes to the accountants before three, and the next feature is already on her list.
Here's what I want you to notice
The agent was brilliant both weeks. In the first week, it built precisely what it was told, with tests, in two hours. That isn't a fault. The instruction just wasn't the decision.
Look at where the decision really lived: on a call with an accountant, and in Lena's memory of it. When the build is done by lunch, a detail that isn't written down never gets in.
Stop writing tickets as if a person will fill the gaps. Write the call, with its "because", where the agent reads it, next to the customer's own words. Then read the plan before anyone builds. A plan takes a minute to judge; a finished feature takes an afternoon to undo.
And notice what it cost Lena: four minutes to write the decision, and two to correct one assumption. Nobody added a meeting or a sign-off, and the agents never waited for her.
What's the proof?
- Agents do what the words say. Anthropic's prompting guide says "Claude responds well to clear, explicit instructions." It adds: "If you want 'above and beyond' behavior, explicitly request it rather than relying on the model to infer this from vague prompts." It asks you to think of Claude "as a brilliant but new employee who lacks context on your norms and workflows."
- Reading the plan first is a built-in habit. In Claude Code's plan mode, "Claude reads files and proposes a plan but makes no edits until you approve."
- Spec tools put the "why" first. GitHub's Spec Kit puts it as: "Define what to build and why, then turn the specification into a plan, tasks, and working code."
- The team part is possible today. In Campfyrr, a decision is recorded with its reason and given to every session that works in that area; see where decisions should live. Business context on an area appears in the agent's brief under "From the business"; see how customer requests reach agents. A session publishes its plan as a page with a link. An open assumption shows in the project's read-only Activity feed and links to its own page, where people keep, correct or pass it.
What Campfyrr doesn't do: it doesn't write your specs, make the product call or replace your tracker. The judgment still belongs to Lena. Campfyrr puts it where the agents read it, before they build.
What do I do on Monday?
- Pick the next feature a customer will use.
- Write the product call as one sentence with a "because".
- Record it on the part of the product it affects.
- Add one customer's own words beside it.
- Ask the session to publish its plan before it writes code.
- Read the plan as the customer would.
- Correct each assumption from its link in one line.
Then compare two things: how often a feature is right the first time, and how often it's rebuilt after you see it.
For the problem in full, read deciding what to build and Campfyrr for product managers. The same pattern from the business side is the feature nobody reviewed. The idea behind it is decide by doing.
The problem this answers: Deciding what to build: "Development is fast now. Deciding what to build, clearly, is the slow part."
The principle behind this: Decide by doing: Our decisions live in what we do, not in what we say.
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).