Coding agents have changed the economics of software. Writing a change used to be the slow part. Now it is the fast part, and the queue has moved to the people who have to decide whether the change is right.
An agent will tell you its work is done. It will say the tests pass. Sometimes that is true. The trouble is that the sentence reads the same either way.
We build Camaan with coding agents every day. The method we use is called journey-driven development, and it rests on one rule: a statement that something works is not evidence. A recording of it working is.
Start with the journey
A journey is a short document written before any code. It says why the change exists, what will be different for the person using the product, the variations that have to be tried, and what done looks like.
It is written in terms of a person and a task. Not "add an endpoint", but "an administrator invites a colleague, who signs in and sees only their own team's work".
Done means proof
A journey is done only when two things are true. An end-to-end test drives the real product through the journey and passes. And the screenshots that test took are in the document.
The screenshots matter more than they seem to. A green tick says a test passed. It does not say what the test looked at. A screenshot taken by the test, of the real screen, lets a reviewer who never ran anything see the state the product was in. If the picture shows an error banner behind a passing assertion, a person will notice.
Keep the builder and the reviewer apart
The agent that writes a change does not approve it. The work is split into roles, a builder and a reviewer among them, and a person who is not the author decides whether it merges.
The roles are enforced where it counts, at the moment an agent tries to do something. A role has a list of commands it may run and files it may not touch. A builder cannot edit the test that judges it. A refusal is not a warning in a log. It fails the build.
We learned why the hard way. On a trial run an agent given a one-line change wrote a test that checked nothing. No tool caught it. The reviewer did.
Any coder, same rules
The method does not care which agent writes the code. Different coding agents plug in, each working in its own copy of the repository so two pieces of work never collide, and they coordinate through a shared journal that can be added to but not rewritten.
Not every coding tool can enforce limits on itself. When one cannot, the journey says so plainly, so the reviewer knows how much to trust what they are looking at.
What our own repository shows
We counted. After six months of building this way the Camaan repository holds 356 journeys. Of those, 351 carry proof: 1,780 screenshots taken by tests, across 514 end-to-end test files and about 4,000 changes.
We should be honest about what that shows. It shows the practice is real and that it held up at speed. It does not show that the method causes fewer defects. We have one team and one codebase, with nothing to compare against, and anyone who tells you their method is proven by their own repository is selling something.
What we can say is narrower and, we think, more useful. When someone asks whether a feature works, the answer is not an opinion. It is a document with pictures in it, and a test anyone can run again.
Why this matters to a customer
The same loop runs inside the product. When your team builds an app on Camaan with an agent's help, the preview and the proof run in an isolated sandbox, and what gets published has been through the same test.
It also changes what a handover is. You do not receive code and a promise. You receive the journeys, the tests and the proof, so the next change, whether we make it or you do, has something to be checked against.
Agents made writing software cheap. They did not make being right cheap. That part still has to be earned, one journey at a time.