"Have someone review the AI's code" is advice written for companies that have engineers. If you run a 10-person business, you were never going to read the code. That was never your safety mechanism — so stop feeling bad about skipping it, and put something in its place that actually works.
The interesting part: the industry is converging on the same conclusion, for its own reasons. Verification researchers argue that generated code needs machine-checkable correctness, not human eyeballs. Platform vendors are adding deterministic intermediate layers between what an AI generates and what runs in production. And the hobbyists shipping real AI-built projects in public keep landing on the same pattern: write a precise spec, make the build prove it works, then stop fussing over the implementation.
Strip out the enterprise framing and you get something a non-technical owner can actually use. Call it the Spec Rule.
Before an AI builds any tool you intend to keep, write down four things: what goes in, what comes out, what happens when the input is wrong, and how you undo a bad result. No spec, no build. The spec — not code review — is your safety mechanism.
Why the spec beats the review
For a small business, the failure mode of an AI-built tool is rarely "the code is broken." Models write competent code for boring internal tools the way calculators do arithmetic. The failure mode is "the tool does exactly what you asked for, and what you asked for was wrong."
Vague intent is the bug. A spec forces you to fix the intent before the build, in plain language, where you're the expert. And it converts the acceptance question from "is this code good?" — a question you can't answer — to "does this behavior match what I wrote down?" — a question only you can answer.
That's the whole trick. You were never qualified to review code. You are the only person qualified to review intent.
The four fields
1. Inputs
What data the tool touches, where it comes from, and in what shape. "A CSV export from the scheduling system with columns A, B, C" — not "our scheduling data." If the input isn't concrete enough to write down, the tool isn't ready to be built. You're still in discovery, and discovery happens on paper, not in production.
2. Outputs
What comes out, field by field, format by format, and where it lands. Who sees it, when, and what decision it feeds. A tool whose output doesn't feed a decision is a toy — say so in the spec and build the toy on purpose, or change the spec.
3. Edge cases
What should happen when the input is empty, duplicated, absurd, or missing a field. This is where AI-built tools actually break — not on the happy path, but on Tuesday, when the export has a blank row. List at least five ways reality will corrupt your input. If the spec can't answer them, the build will improvise, and you'll find out from the output.
4. Rollback
What happens when the tool is wrong — and it will be, sometimes. How do you undo it? What's the blast radius? A tool whose worst failure costs you a re-export is a different animal from one whose worst failure mass-emails customers or corrupts a live record. If the rollback is ugly, that's not a reason to skip the tool; it's a reason to scope it smaller until the rollback is boring.
Then demand tests — and stop reading
Here's the part that feels illegal the first time you do it: after the build, ask the AI to generate tests that prove each line of the spec. Edge cases included. Then run them.
If the tests pass and the behavior matches the spec, accept the tool. Do not open the code. Do not "just take a quick look." You won't find anything, and even if something looked odd, you wouldn't know what to do about it. Your review happened before the build — that's what the spec was.
This isn't blind trust. It's checking the only artifact in the chain you're qualified to check. The spec is your review; the tests are the build's reply.
One honest caveat: an AI can satisfy a bad spec perfectly. The Spec Rule doesn't make you immune to mistakes — it moves failures from "the tool is broken" (mysterious, requires an engineer) to "my spec was incomplete" (visible, fixable in plain language tonight). That's the trade. You take responsibility for intent, and in exchange, every failure becomes one you can fix yourself.
What the Spec Rule does not cover
- Systems of record. The Spec Rule governs draft tools. The moment a tool becomes the place customer data lives, or something money moves through, or something the whole team runs on, it has graduated — add access control, backups, and a named owner, or rebuild it on a supported platform. Promotion from draft is a decision, not a drift.
- Customer-facing anything. Internal first, always.
- Judgment calls. If a step of the tool involves taste — pricing exceptions, customer language, anything with negotiation in it — the spec should route that step to a human, not to the model.
Tonight's version
Take the spreadsheet workflow you've been meaning to automate. Write the four-field spec: inputs, outputs, five edge cases, rollback. Twenty minutes, no build yet. Two things will happen: you'll find out whether you actually understand the process, and the tool you eventually get back will be the tool you meant.
That gap — between what you would have prompted and what you just specified — is the entire failure mode the Spec Rule exists to close.
Want the spec-writing frameworks and acceptance checklists that go with this? The AI Automation Starter Kit includes spec templates, test-generation prompts, and the guardrail checklists that keep AI-built tools from becoming liabilities.
Top comments (0)