The customer who became the tester
By Soumen Sarkar · October 2026
Story. When a change ships before a tester ever sees its plan, the customer runs the first real test. Publish the plan before the work starts, let the tester add the cases they know into it, and publish the test results as a page anyone can open.
What happens when the customer runs the first test?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's 8:50 on a Thursday, and I'm sitting on a spare chair beside Sam's desk. Sam leads a team of three engineers building a ticketing app for small theatres and music venues. Ines is the team's tester. Rachel runs support, and knows the regulars at every venue by name.
Sam's job today is a small one, or it looks small. Venues keep asking for it: let a customer move a booking to another night of the same show, without a refund and a new purchase. He gives his agent five lines and a link to the booking code.
I watch it work, and it's a pleasure. It reads the booking model and the seat map, and writes a tidy plan in Sam's session: release the old seats, hold the same number of seats on the new night, carry the payment across. It writes tests for each step, including the case where the new night is sold out. By eleven there's a pull request. Sam reads it carefully. It's clean.
"It's only a date change," Sam says. "No new screens." It goes out with the evening release.
Ines doesn't hear about it. Small changes don't go on her list.
On Saturday at 10:15, Rachel's phone buzzes. It's an email from Joan, who comes to almost every show at one of the venues, in her wheelchair. She moved her booking from Friday to Saturday, the night her sister could come. The new tickets put her and her sister in row F, up a flight of steps. Joan writes politely. She'd like to know if she should still come.
Rachel fixes it by hand within the hour. She calls the venue, finds the wheelchair space on Saturday still free, and books it. Then she writes to Joan, and apologises.
On Monday morning, Rachel walks the email over to Sam and Ines.
Ines reads it twice. "Accessible seats are their own kind of seat," she says. "They're held as a space with a companion seat beside it, not as a row and a number. It's the first case on my list for anything that touches bookings."
Sam looks at the plan, still open in his session. The agent wrote, plainly: "Hold the same number of seats on the new night." It did exactly that. Two seats. The one person who would have spotted it in a second never saw the plan, or the change, or the release.
The agent has the fix written before Sam finishes his coffee. But Joan was the first person to test the feature with a real wheelchair booking, and she did it on her sister's night out.
I come back the next Thursday.
The team has changed two things. Before a session builds anything that touches a booking, it publishes its plan as a page, and the link goes to Ines. And every plan has a short section at the bottom, "How we'll test it", that Ines can add to before any code is written.
At 9:05 Sam starts the next feature: let a customer add one more ticket to an existing booking, next to their seats. The agent is just as quick. Before it writes any code, it publishes the plan: five plain sentences, then the detail. At the top it lists one assumption: "Assuming the extra seat should be the nearest free seat in the same row." Under "How we'll test it" it lists four cases of its own.
At 9:20, between two test runs, Ines opens the link from the project's Activity. She reads it the way Joan would. She answers the assumption from its page in one line: "If the booking has a wheelchair space, offer the companion seat first, then the nearest step-free seat." Then she adds three cases to "How we'll test it": a wheelchair booking, a booking split across two rows, and a sold-out row. Last, she writes a note on the booking part of the product, where every agent that works there will read it: "Accessible seats are held as a space plus a companion seat. Any change to a booking must keep them together."
That's all. Six minutes, and her coffee is still warm.
At its next turn, the agent reads her answer and her cases. It changes the plan, publishes it to the same link, and writes a test for each of her seven cases before it writes the feature. By two there's a pull request, and every test passes.
Sam asks the session to publish the test results as a page, point first: "All seven booking cases pass, including wheelchair bookings." He drops the link in the team's chat. Rachel opens it on her phone and reads the first line. She knows what to tell the venues.
The feature ships on Friday. Ines spends Monday on the next plan, not on the last customer's email.
Here's what I want you to notice
The agent was brilliant both weeks. In the first week, it did everything it was asked, with tests, in two hours. What it didn't have was the one thing Ines knew, and nothing carried the plan to her.
Look at who did the testing in each week. In the first, Joan did, on a Saturday night that mattered to her. In the second, Ines did, on a Thursday morning, before any code existed. Same knowledge. Only the timing changed.
Stop deciding which changes are too small for your tester to see. With agents, nothing is small for long: a "date change" touched seats, money and a customer's evening out. And stop treating test results as something only engineers read. A page that starts with one plain sentence lets support, sales and the founder trust the work without opening the code.
And notice what it cost Ines: six minutes, from a link. Nobody added a meeting or a sign-off, and the agent never waited for her.
What's the proof?
- Testers belong at the start, not just the end. The Agile Alliance describes the Three Amigos as "the primary perspectives to examine an increment of work before, during, and after development". The testing view asks what could possibly happen.
- Early testing saves rework. One of ISTQB's seven testing principles is that "testing early in the software development lifecycle helps reduce or eliminate costly changes" (ASTQB, the seven testing principles).
- Faster building raises the stakes downstream. Google's DORA team, in its 2025 report, writes that AI "can expose weaknesses downstream", and that without controls like strong automated testing and fast feedback loops, "an increase in change volume leads to instability".
- The habit in this story works today. Campfyrr's
publish tool turns a plan or test results into a page with a link, point first (how publishing works). Published pages and open assumptions appear on the project's Activity, and each assumption has its own page where a teammate keeps it or corrects it. The agent reads the answer at its next turn.
What Campfyrr doesn't do: it doesn't run your tests, it isn't a test management tool, and it doesn't replace your CI or your tracker. The tests ran where they always run. Campfyrr got the plan to Ines while it could still change, and got the results to Rachel in words she could use.
What do I do on Monday?
- Pick the next change that touches a customer, however small it looks.
- Ask the session to publish its plan before it writes code.
- Add a "How we'll test it" section at the bottom of the plan.
- Send the plan's link to your tester.
- Ask the tester to add the cases they know and answer each assumption.
- Ask the agent to write a test for each case before the feature.
- Publish the test results as a page, with the point in the first line.
- Share that link with support and sales.
Then count how many problems your customers report first, and how many your tester catches in the plan.
For the problem in full, read review falls on the business and testers left out of planning. For a tester's first week, see Campfyrr for QA and testers. The same pattern seen from the tester's desk is the tester who saw it last, and the idea behind it is let the work speak.
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).