Last month we described the process we actually run — requirements, then architecture, then an agent writing the code. The question that follows is the one clients ask in the first meeting. Nobody typed that code. How do you know it is right?
The wrong answer is that we read it very carefully. When a week of work lands in an afternoon, "we reviewed every line" stops being a true sentence. What actually happens is that the trust moves somewhere else.
Right against what?
Verification is comparison, so before anything gets built we make the thing to compare against. That is the quieter job the requirements and architecture documents do. They are written with you, and they are what the finished work gets held against afterwards — by us, and by the agent.
Most of the the AI got it wrong stories we hear turn out to be nobody wrote down what right was. If the only record of what was wanted lives in someone's head, nobody can check the result — they can only look at it and feel that it seems about right.
We automate what is silent, and look at what is visible.
The division of labour runs the other way round from what you would guess. We do not write tests for a broken layout — anyone who opens the page sees that. We write them for the failures that look completely fine.
This site is a small example. Its security policy blocks inline scripts, and a violation produces no visible error: the page looks perfect while a piece of it quietly does not run. A post missing from the sitemap looks fine forever too — it is simply invisible to search. Neither announces itself, and each is a few lines of script to catch.
So we write a script that checks for them and wire it into the deploy, here and in the work we build for clients. A failure stops the release — which is the whole point, because a check that files a warning for somebody to read later is a check that eventually nobody reads. We run it against a local server that mirrors the real host, too: the convenient one-line preview server ignores response headers, so it would never enforce that security policy at all, and the silent failure would stroll straight past the check meant to catch it.
We make the checks fail on purpose.
A suite that has only ever passed tells you very little. It might be testing what we think it is, or nothing at all — from the outside, both are green.
So we break things on purpose. Here that means keeping deliberately broken copies of the site — one with an inline script, one with a post missing from the sitemap — and confirming the checks fail on each, with a message that names the problem. A gate that cannot fail is worse than no gate: it reads as assurance.
This matters more with generated code, not less. An agent asked to make the tests pass is remarkably good at making the tests pass. The tests have to be worth passing.
Where the automated part stops.
Some things no script will tell you, and we would rather name them than imply coverage. Whether the contrast is genuinely readable rather than technically compliant. Whether a form submission actually arrives in an inbox — the only way to know is to send one and watch it land. Anything whose truth lives in a hosting dashboard, where only a person can look. Those get a human, every time.
What that means for you.
You do not have to take our word for any of it, and that is deliberate. The documents that define what right means were written with you. The checks are ordinary code in the repository we hand over, so you can read them, run them, and watch them fail.
None of this is new or clever. It was good practice long before agents, and most studios skipped it because writing the code consumed the whole budget. That excuse is gone. The typing got cheap, so the checking is where our time goes now — speed nobody can verify is not worth paying for.