A test is a sentence about behaviour

"The discount code isn't doing anything." A customer says that to you three weeks after launch, in passing, as though it hardly matters. You never reviewed the code that produced it, because you cannot read code. The AI wrote it, the screen looked right, and you shipped. It did nothing for anyone, on every order placed since launch day. Nobody caught it, because nothing in your process ever stated what the discount was supposed to do.

Code review is the normal answer here. You cannot do it, so concede that properly instead of working around it. You are not going to learn to read the implementation this month. Pretending otherwise is how people stay stuck in the same place for a year. So replace the thing you cannot do with a thing you can. A test suite is how a non-developer reviews code they cannot read. The review you cannot perform becomes a claim the machine performs for you.

A test is a sentence about behaviour. Something happens, then something should be true. That is the entire shape. You already talk like this when you complain about other people's software.

Writing the checking code is not your job. Reading it is. Those are different skills. The second one is small enough to learn in an afternoon. I have shipped 80+ web apps and 150+ AI agents into production. None of that depends on reading every line that goes out.

A test is not proof the app is good. Not a guarantee. Not documentation, not a substitute for looking at the thing, and not something you write once and never touch again. It is one claim, stated in advance, checked by a machine with no opinion about you.

The rules

Write the sentence in English before any tool is involved. One thing happens, one thing must then be true. If you cannot say it in a sentence, you do not understand the behaviour yet. No test is going to rescue that.

Name the behaviour, never the implementation. A £100 order with a ten percent code costs £90. That is a behaviour. How the discount actually gets calculated is not your business at all. It will change next month without warning.

Your job is reading the assertion, not writing the test. Have the AI write it. Then find the line stating the expected result and read it aloud. If that line does not match your sentence, the test is checking something else, and nobody will tell you.

A test you have never seen fail is not a test. It is a green light with no wire running behind it. Break the behaviour on purpose, watch the test go red, then put it back. Now you know the wire is connected.

One claim per test. A test that checks six things only tells you that something broke. A test that checks one thing tells you what.

Do it now

Pick one behaviour your app already has. Something small and load-bearing. Write the sentence on paper first.

Then give the AI exactly this.

Write one automated test for this behaviour, in the test setup this
project already uses.

BEHAVIOUR: "<your sentence, in plain English>"

Rules:
- One assertion. The expected value must appear literally in the test.
- No mocking of the thing being tested.
- Name the test with my sentence, word for word.
- After the code, write one line telling me which line is the assertion.

What comes back should read close to this shape.

test("a £100 order with code SAVE10 costs £90", () => {
  const total = priceOrder({ subtotal: 100, code: "SAVE10" });
  expect(total).toBe(90);
});

Read the second line, which sets up the order. Read the third, which says what must come out. If you can point at the 90 and say yes, that is what I meant, you have reviewed a test. That is the skill.

A worked example

Say you are the volunteer secretary of a community football club. You had an AI build the members' app for subs and fixtures, and you have never read a line of its code. The committee agreed a sibling rule. A second junior from the same family pays half the £120 junior sub.

BEHAVIOUR: "A second junior from the same family pays £60 subs"
Test name: a second junior from the same family pays £60 subs
Assertion: the AI points at line 3. The expected value there is 60.
Read aloud: 60. That is the committee's rule.
Broken on purpose: the sibling rule now returns the full £120
Suite run: FAIL  a second junior from the same family pays £60 subs
           Expected: 60   Received: 120
Put back, run again: PASS

The failure you will hit

The AI will hand you a test that passes whatever the app does. It will assert that a result exists, or that no error was thrown. Or it will quietly rewrite the expected value to match whatever came out. All three go green forever. The defence is the red step, every time, with no exceptions on busy days.

Not for you if

Nothing you ship is used by anyone but you, and a silent wrong number costs you nothing. Testing is pure overhead until somebody else is holding the bill.

One sentence, one test, red on demand and then green. The Vault is the paid library, and the price is on the page.