If you can say yes to a decision, a contract, a list of behaviours and a plan, you can run software that AI builds. Reading the code was never the control.
I build AI automations for small businesses: the booking that confirms itself, the enquiry that gets answered at 11 p.m., the reminder that goes out without anyone remembering to send it. The owners I work with want two things that used to pull against each other. They want it built quickly, and they want to stay in charge of what it does.
A few years ago “in charge” meant trusting the developer and hoping the demo matched the invoice. Now most of the code in a small automation is written by an AI agent in minutes, which makes the old answer worse, not better. Trusting the developer is not enough when the developer did not write it either. And reading the code is not a real option for an owner, nor a good use of an engineer’s day.
So I changed what the owner reviews. Not the code. Four documents, before any code exists, and the release after.
What I used to ask owners to review, and why it failed
The old rhythm was a demo at the end. The owner watched a screen, said “looks good”, and the surprises arrived in month two: the reminder that went to the wrong number, the form that accepted a booking the diary could not take, the report that counted something nobody had agreed to count.
Every one of those surprises was a decision that had been made silently, inside the code, by whoever wrote it. The demo could not show it, because a demo shows what happens, not what was promised. And by the time the owner saw it, changing it cost real money.
The fix is not to review harder at the end. It is to move the review to the only place it is cheap: before the build, on documents short enough to read over a coffee.
The four documents
1. The decision. One page. What changes, why, what we considered and rejected, and how we will know it worked. In my trade this is called an architecture decision record, but the name does not matter. What matters is that it is written in the owner’s language, and that the owner reads it first, because the contract and the scenarios follow from it.
2. The contract. A list of promises. What the system will accept, what it will return, and what it will send out to other systems and to people. For a booking reminder: which bookings qualify, what the message contains, what happens when a customer replies. Engineers write this in two standard formats, one for requests and one for events (OpenAPI and AsyncAPI, if you want the names). The owner reads it rendered as a document, not as a technical file, and it is written by hand before a single function exists. That order is the whole point. A contract written after the code merely describes what was built. A contract written before it is something you can disagree with.
3. The behaviour. A set of scenarios, each in a few lines the owner could have written:
Given a customer has a booking for Tuesday at 10:00, when it is 24 hours before, then they receive a text naming the business, the service and the time, and a reply of CANCEL cancels the booking and tells the owner.
Here is the part that makes this more than a nice document. Those scenarios are not a description of the tests. They are the tests. Each one starts marked “proposed”, and the build is not allowed to finish until every proposed scenario has been turned into a passing one. If the agent builds something that does not match the owner’s words, the build goes red. The owner’s sentence is the thing the machine is held to.
4. The plan. A board of small stories, each one a change the owner can see, each one naming the scenarios it will turn green. One story becomes one pull request. The owner looks at the board and sees, before any work starts, what will be built and in what order.
Then the build. An AI agent takes one story at a time. It may not change the contract or the wording of a scenario. If it finds that a story cannot be built as agreed, it stops and says so, and the change goes back to the owner as a one-line amendment, not as a surprise.
Then the release. Nothing reaches customers until the owner has read what changed and pressed approve. That is the second yes. The first covered all four documents in one sitting, and this one is shorter.
What the owner’s week actually looks like
Take the salon that wants appointment reminders by text.
The owner describes it in a paragraph. A scoped plan comes back the same day, written against the rules and the systems the business already has. The owner reads the one-page decision and the contract: which bookings, what the message says, what a reply does. They read the scenarios and fix one, because they know their customers and the engineer does not: “a reply of anything else gets a short answer with the salon’s number, not silence.” They look at the board.
Four readings, none of them long, all of them in words the owner already uses. Then the agents build, and the owner’s next job is to approve the release.
What the owner never does is open a code editor. What they can always do is point at a scenario and say “that is not what I meant”, and have the build stop until it is.
Where the documents live
A process like this only works if the documents are in one place, readable by the owner and by the AI agents that build from them. If the rules live in a wiki the agent never opens, the agent will cheerfully ignore them.
We built SystemDox to be that place. The business’s rules, decisions, contracts and scenarios are kept in version control and served to every agent at the moment it writes, so a standard changes once and every agent inherits it. Its plan page turns a plain description into a scoped, standards-aware plan, saves it as a draft, and populates the work board only when a person says so. Each change has one page there, where the owner reads the four documents rendered and sees how far the build has got. The agents read the same documents the owner reviewed, which is how “the owner’s sentence is what the machine is held to” stops being a slogan.
What I ask every owner now
Three questions, before any supplier (me included) writes a line:
- Can you say, on one page, what should change and why? If not, nobody should be building yet.
- What does the system promise? What it accepts, what it returns, what it sends. If the supplier cannot show you this before the build, you are buying a demo.
- How would you know it works? Write the scenarios in your own words. Insist that they become the tests.
If the answers exist, the AI can build fast and you stay in charge. If they do not, the AI will still build fast. That is the problem.
Monday
- If you buy software: ask for the four documents before the next build starts. A supplier who already works this way will have them. One who does not will learn quickly, because they are cheaper to produce than a surprise.
- If you build with AI yourself: write the scenarios before you write the prompt. Mark them proposed. Do not let the session end until they pass.
- If you run a team: put the documents where the agents read, not where the humans file things.
Interest declared: this is the process I run PuglieseWeb on, with a handful of AI agents building and one person saying yes. The place the documents live is SystemDox, which we sell and which starts free on one repository. If you want the process applied to your business, with the automations built to it, that is what I do.