The feature nobody reviewed until the customer did
By Soumen Sarkar · October 2026
Story. When a feature is built and shipped in a day, the first person with the customer's context to see it is often the customer. Show the plan and a sample output to the person who knows the customers before it ships, and send them the agent's assumptions to answer in a line.
What happens when the customer is the first reviewer?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's 9am on a Thursday, and I'm sitting on a stool beside Tom's desk. Tom leads a team of four engineers building booking software for small studios: yoga, pilates, a climbing gym. Across the room, Nadia runs customer success. She knows every studio owner by first name.
Tom's first job of the day is one the studios have asked for all month: automatic payment reminders. When a member's invoice is still unpaid after seven days, send them a friendly email. Tom writes three lines for his agent and lets it go.
I watch it work, and it's a pleasure. It reads the billing code, finds where invoices are marked paid, and writes a clear plan. It builds the reminder, writes the email, schedules the job and covers it with tests. Before eleven it opens a pull request. In the description it says, plainly: "Assuming an invoice is unpaid when no card payment is recorded against it."
At half past eleven, Sam reviews the change. He's careful. He checks the scheduling, the database query and the tests, and he leaves one sensible comment about time zones. The agent fixes it in two minutes. Sam reads the assumption, and it sounds right to him. He approves.
At five, the change ships. Tom posts a cheerful line in the team's chat: "Payment reminders are live." Nadia gives it a thumbs-up on her way out. It's a good day, and everyone goes home pleased.
I'm back at eight the next morning, and Nadia is already at her desk with her coat still on. An email has come in from Ruth, who owns the climbing gym. Twelve of Ruth's members got a reminder overnight saying their invoice was overdue. Every one of them had paid. They pay by bank transfer, the way half the studios' members do, and Ruth marks those payments by hand at the end of the month.
Nadia reads the email twice. Then she walks over to Tom's desk, and I watch his face as she reads it out. She knew about the bank transfers. She's known for two years. Nobody asked her, because nobody thought of it as a question for her. It was in a pull request she'd never open, written in words she'd never been shown.
The agent did exactly what it was asked, and did it well. It even said out loud what it was assuming. Sam did exactly what a code reviewer does, and did it well. The only person who could have seen the problem was ten metres away, and the work never reached her. So the first real review of the feature was done by Ruth, and by twelve of her members, at breakfast.
The morning goes on apologies. Nadia writes to Ruth. Tom turns the reminders off. Ruth is kind about it, but I can hear in Nadia's voice that she's spending something she'd rather keep.
I come back the next Thursday.
The team has changed one thing. Before anything ships that a customer will see, the session publishes its plan and a sample of what the customer will get, as a page with a link. Each assumption the agent makes goes to the person who'd know the answer, not just to the reviewer.
At nine, Tom starts the next feature the studios want: a renewal notice, a week before a member's plan renews. The agent works just as well as last week. By half past ten it has a plan. Then, before it opens a pull request, it publishes a short page: the plan in four plain sentences, and three sample emails, one each for a monthly member, an annual member and a member who pays by bank transfer. At the top, it lists two assumptions. "Assuming members want the notice seven days before renewal." "Assuming annual members see the monthly price, as the plans page does."
The second assumption is sent to Nadia. Her phone buzzes at 10:40, and I watch her open the link while she finishes a call. She doesn't read code. She doesn't need to. She reads the three emails the way a member would.
The first is fine. She stops on the second. "An annual member would think we'd changed their price," she says, to nobody in particular. She corrects the assumption from the link in one line: "Annual members see the annual price." Then she looks at the third email and adds a note to the billing part of the product: "Half our members pay by bank transfer, marked at month end. Never tell them they're late before the 5th."
That's all. Two minutes, between two calls.
At its next turn, the agent reads her answer and her note. I watch it change the annual email and add a line to the bank transfer one: "If you've already paid by transfer, you can ignore this." It publishes the new samples to the same link. Nadia opens it again, nods and goes to lunch.
At half past eleven, Sam reviews the code, exactly as carefully as last week. This time he can see who confirmed the assumptions, and why. He approves.
At four, the renewal notice ships. Tom posts it in the team's chat, and this time Nadia doesn't just give it a thumbs-up. She writes to Ruth: "You'll like this one. I've seen what your members will get."
The next morning, Ruth's members get their notices. Nobody writes in.
Here's what I want you to notice
The agent was brilliant both weeks. In the first week, it did the most useful thing an agent can do: it said what it was assuming. The assumption just went to the wrong person. Sam could judge whether the code was sound. Only Nadia could judge whether it was true for the customers.
Look at what review actually is now. Code review still matters, and it still happens. But it answers "is this built well?", not "is this what our customers need?" When a feature goes from idea to live in a day, nobody with the customer's context gets a natural moment to look at it. So the review doesn't disappear. It moves downstream, to support, to the founder, and in the end to the customer.
Stop sending your business teammates finished features. Send them what the customer will see, before the customer sees it. A sample email, a screenshot or a new error message is something anyone can judge in a minute. A diff is something only engineers can judge at all.
And notice what it cost Nadia: two minutes, on her phone, between calls. Nobody added a meeting or a sign-off step. The work came to her, in her language, at the one moment her answer was cheap.
What's the proof?
- Faster building pushes problems downstream. Google's DORA team, in its 2025 report on AI-assisted software development, says "AI accelerates software development, but that acceleration can expose weaknesses downstream." It adds that without fast feedback loops, "an increase in change volume leads to instability."
- Review isn't keeping pace with output. Faros AI's AI Productivity Paradox report found that developers on teams with high AI adoption merged nearly twice as many pull requests, while the time spent reviewing them nearly doubled too. More gets built than anyone can check.
- Showing the work is already possible today. Campfyrr's
publish tool turns a plan, test results or a sample output into a page with a link that anyone on the team can open. An assumption goes to the person who should confirm it, and they answer from its own link. The agent reads the answer at its next turn. See publishing from Claude Code.
What Campfyrr doesn't do: it doesn't run your tests, replace your tracker or replace CI, and it doesn't block a release. The judgment still belongs to Nadia. Campfyrr just gets the work to her in time.
What do I do on Monday?
- Pick one feature this week that a customer will see.
- Ask the session to publish its plan and a sample output before it opens a pull request.
- Include one sample for each kind of customer it affects.
- Send the link to the person who talks to those customers.
- Ask the agent to state its assumptions, and route each one to the person who knows.
- Ask that person to answer in one line from the link.
- Keep code review as it is.
Then count how many problems your business teammates catch before ship, and how many your customers catch after.
For the problem in full, read when building is easy, review falls on the business and showing the work. The idea behind it is let the work speak, and agents that state assumptions shows how to set your sessions up for it.
The problem this answers: Review falls on the business: "Building is so easy that reviewing the output has fallen on our customers and business teams."
The principle behind this: Let the work speak: Our work explains itself, so nobody ever has to come and ask us.
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).