A coding agent that finishes a task often writes "Fixed". That is where the danger lies. If the agent has not been given the tools to check its own work, that sentence is often wrong. It leads to fixes that fix nothing, and sometimes to serious incidents in production.
So we require every agent to attach proof it obtained itself. Without it, the task is not done. This rule decides what we hand to AI, what the team reviews and what you receive with each delivery.
No proof, no "done"
A language model writes the most likely continuation of a text. After a fix, the most likely continuation is "fixed", whether the fix works or not. Only observing the result settles it. A Cursor engineer made this a principle of his method, 
pstack · Prove it works: "it compiles" proves nothing, the agent has to observe the real result.
So every agent attaches proof of what it reports: the test that used to fail and now passes, screenshots of the page on mobile and desktop. When it could not check, it writes "not verified".
What an agent must be able to check alone
Demanding proof achieves nothing if the agent cannot obtain it. So we give it the means to check its own work.
- The current documentation of the tools it uses, so it checks that a function exists instead of remembering it.
- A map of the code's dependencies, so it knows what a change may break before making it.
- A browser and simulators, to open every page on mobile, tablet and desktop.
- Journey tests, where an agent pursues a goal such as "upgrade to the Pro plan" and an exact check verifies the result on screen.
When an agent reports a defect, it must reproduce it with a test before we act on it. That test then stays in the product and replays the scenario with every change.
What we hand to an agent
Our criterion is one question. Can the result be checked without reading all the code? Erik Schluntz, an engineer at Anthropic, compares an application to a tree in his talk 
Vibe coding in prod. We use that image to decide where human review goes.
Where human review goes
Leaves
A report screen, an export, an admin page.
Handed to an agent, judged on their tested results.
Branches
A booking flow, a shared form.
Contracts under test. Any contract change is reviewed.
Trunk
Data, access rights, payments.
Understood and reviewed by the team at every change.
Leaves are the features nothing depends on. When their inputs and outputs are tested, their result is enough to judge them. The trunk carries data, access rights and payments. The team understands it and reviews it, because everything else depends on it and no test measures technical debt.
Every test we add makes one more part verifiable, and therefore something an agent can take on. That is why almost a third of the code we write serves to check the rest.
What the team decides
The agent executes fast. Deciding what to execute, and how to know it is right, remains the team's work.
The right questions, before the first line of code. What happens if a payment fails halfway? Who can see another customer's data? What does the app do offline? An agent does not ask these questions on its own. Knowing how to ask them comes from shipped projects and fixed outages. Erik Schluntz makes the same point: without the right questions, you do not steer an agent, you put up with it.
The architecture. The boundaries between modules, the shared data and what must be able to evolve form the trunk of the application. An agent copies the structure it finds, good or bad. So the team has to design it.
The definition of "done". Before each task, the team writes down what must be true for it to be finished: the cases to cover, the expected results, the screens to check. A test can pass with a wrong result if the expected result is wrong. The amount of a refund, a cancellation rule or a user's rights are therefore decided with you, then written into the tests. The agent then writes the code that meets them.
Production-ready code
Each change arrives tested, checked on mobile and desktop, with the address of the version to approve. You check the result yourself before it goes live.
Four questions to ask your developers
- How do your agents prove what they report?
- Which parts of my product does a person review, and why those?
- Who sets the expected results in the tests?
- What will I receive to approve a change?
Do you want to take over an existing application or build one with this method? Let's talk.
SaaS
Swiss Made Software