The tester who saw it last
By Soumen Sarkar · October 2026
Story. When testers first see agent-built work as a finished build, they can only find bugs, not prevent them. Publish the plan before the work starts, send the agent's assumptions to the tester, and let them answer from a link while the plan is still cheap to change.
What happens when the tester sees the work last?
This story is a scene, built from how teams work with agents today. What comes after it is real.
It's 9:15 on a Monday, and I'm sitting at the end of Marco's desk. Marco leads a small team that builds the app for a recipe-box company: customers choose meals, and a box arrives on their doorstep every Wednesday. Two desks along, Lena is finishing last week's regression run. Lena is the team's tester, three years on this app.
Marco's job this week is one customers keep asking for: let people pause their deliveries for a week or two without cancelling. He gives his agent four lines.
I watch it work, and it's a joy to watch. It reads the subscription code, the billing job and the delivery schedule. Within twenty minutes it has written a clear plan in Marco's session. Line three says: "Pause applies to the next delivery that hasn't shipped." By lunch there's a working pause button, with tests. By Tuesday evening there's a pull request, and Priya on the team reviews it carefully. The code is clean. She approves it.
On Thursday afternoon the build reaches Lena. She goes straight for the edges.
At 3:40 she sets the test clock to Tuesday at 7pm, the evening before a delivery, and taps "Pause". The app says, cheerfully: "Paused. You won't be charged for Wednesday's box." Then she checks the warehouse. The packing list closed at 6pm, with the box on it. The charge goes through on Wednesday morning, and the box arrives anyway.
Lena sits back. She writes it up in the tracker, then walks over to Marco's desk. "Packing closes at 6pm the night before. Anything paused after that has already been packed. I could have told you on Monday."
She's right, and Marco knows it. The agent wrote down exactly what it was assuming, in plain words, on line three of its plan. It said "hasn't shipped". The real line is "hasn't been packed". Lena would have spotted the difference in a second. But the plan lived in Marco's session, where Lena can't see, and nobody thought to send it to her. The first thing she could open was a finished build.
The agent has the fix working in under an hour, once Marco explains the cutoff. But the change now needs another review, another build and another round of tests, and the Friday release slips to Monday.
I come back two weeks later, on a Monday again.
The team has changed one thing. Before an agent starts building, the session publishes its plan as a page with a link, and the link goes to Lena. Every assumption the agent makes goes to the person most likely to know the answer.
At 9:20 Marco starts the next feature: let customers skip a single meal from a box without changing the rest. The agent is just as good as before. This time, before writing any code, it publishes its plan: five plain sentences, then the detail. At the top it lists two assumptions. "Assuming a skipped meal is refunded to the card." "Assuming customers can skip a meal until the box ships."
The plan appears on the project's Activity, and Lena sees it between two test runs. She opens the second assumption from its own page. She reads it the way a warehouse would.
"Until it's packed," she says, to nobody in particular. She corrects the assumption from the link in one line: "Customers can skip a meal until 6pm the night before. After that the box is packed." Then she adds a note to the delivery part of the product, where every agent working there will read it: "Packing closes at 6pm the night before delivery. Anything that changes a box must respect that cutoff."
That's all. Three minutes, before her coffee is gone.
At its next turn, the agent reads her answer. I watch it change the plan: the skip button now closes at 6pm, with a line for the customer that says why. It publishes the new plan to the same link. Lena reads it again and adds one more case to her own test list: a customer in a different time zone from the warehouse.
On Wednesday the build reaches her. She sets the test clock to 7pm the night before and taps "Skip". The app says: "Your box is already packed. You can skip meals from next week's box." Nothing is charged that shouldn't be, and her time zone case passes. When she's done, Marco asks the session to publish the test results as a page, point first, and he shares the link in the team's chat.
The feature ships on Thursday, a day early. Lena spends Friday on the next plan, not the last build.
Here's what I want you to notice
The agent was brilliant both times. In the first week it did the most useful thing an agent can do: it wrote down what it was assuming, in plain words, before it built anything. The flaw was visible on day one. It just sat where the one person who could see it had no way in.
Look at what Lena could do in each week. In the first, she could only find the bug. In the second, she could prevent it. Same tester, same knowledge. Only the timing changed.
Stop handing testers finished builds as the first thing they see. A finished build lets a tester find bugs. A plan lets a tester shape the work, and with agents the plan is open for an hour, not a week. If the plan doesn't reach the tester in that hour, it doesn't reach them at all.
And notice what it cost Lena: three minutes, from a link, between two test runs. She answered one assumption and wrote one note, and every agent that touches deliveries now knows about the 6pm cutoff.
What's the proof?
- Testers asking "what could go wrong?" early is long-standing good practice. The Agile Alliance describes the Three Amigos as looking at each piece of work before, during and after development from three views: business, development and testing, where the testing view asks what could go wrong.
- Early testing saves rework. "Early testing saves time and money" is one of ISTQB's seven testing principles: testing early in the lifecycle helps reduce or remove costly changes (ASTQB, the seven testing principles). The ISTQB syllabus counts reviewing documents as testing too (imbus, on the syllabus).
- Faster building raises the stakes downstream. Google's DORA team, in its 2025 report, writes that "AI accelerates software development, but that acceleration can expose weaknesses downstream," and that without control systems 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 (how publishing works). Each project has one read-only Activity feed. An open assumption links to its own page, where a teammate keeps it, corrects it or passes it on. 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. Lena's tests ran where they always run. Campfyrr only got the plan to her while it could still change.
What do I do on Monday?
- Pick one change this week that a tester will check.
- Ask the session to publish its plan before it writes code.
- Ask the agent to list its assumptions at the top of the plan.
- Send the plan's link to your tester.
- Ask the tester to answer or correct each assumption from its page.
- Ask the tester to add what they know to that part of the product.
- Publish the test results as a page when the change is done.
Then compare what your tester finds in the plan with what they find in the build.
For the problem in full, read testers left out of planning. For a tester's first week with Campfyrr, see Campfyrr for QA and testers. The same pattern with a customer-facing teammate is in the feature nobody reviewed, and the idea behind it is turn unknowns into calls.
The problem this answers: Testing left out of planning: "Testing is critical, but the people who test are left out of planning and see the work last."
The principle behind this: Turn unknowns into calls: Nothing we don't know gets to stop us. We name our assumption, and we move.
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).