The smallest experiment that settles it

Stop arguing, start testing

You think the overlap rule is broken. The model says it is not. Neither of you knows. The way out is an experiment small enough to run in a minute and specific enough that its result means one thing.

The method is four steps, and the third is the one people skip.

1. State the claim. “Booking 14:15 for a stylist who has 14:00–14:30 is refused.”
2. State what each outcome would mean. Refused: the rule works for overlaps starting inside an existing booking. Accepted: it does not.
3. Predict, out loud, before running it. Write down what you expect.
4. Run it once, changing one thing.

Step 3 costs nothing and is what turns a click into evidence. If you predicted correctly, you understand the system. If you did not, you have just learned something, and the surprise is the valuable part. Without a prediction, every result feels like it confirms whatever you already believed.

Change one thing

The fastest way to waste an hour is to change three things and see whether the problem goes away. It might, and you will not know which change did it, and one of the other two may have broken something you have not looked at yet.

One variable per run. If you must change two, run twice.

The controls that catch a fake pass

A test that passes tells you less than you think, because it may be passing for the wrong reason. Two cheap controls fix that.

The negative control. Deliberately do the thing that should fail. Book a slot that definitely overlaps and confirm it is refused. If a validation always says yes, an always-yes function passes every positive test.

The break test. Temporarily break the thing you believe is doing the work and confirm the behaviour changes. If you comment out the overlap check and bookings are still refused, something else is refusing them and your understanding is wrong.

That second one feels perverse and it is the single most reliable way to find out whether the code you are reading is the code that runs. Generated projects frequently contain two implementations, and you can spend an afternoon perfecting the one that nothing calls.

Six experiments worth running on any feature

• The second account. Log in as a different user and try to reach the first user’s data by changing an id in the URL.
• The empty case. A brand new account with no data at all.
• The double press. Submit twice, fast.
• The back button. Do the action, press back, look at what state the page is in.
• The refresh. Reload mid-flow. Does anything survive that should not, or vanish that should not?
• The wrong input. An apostrophe in a name, an emoji, 500 characters, a leading zero on a phone number.

Each takes under a minute. Together they find more real defects in generated code than reading the code does, because they exercise the paths nobody described in the prompt.

Write down what you did

One line per experiment, in a file in the repository.

2026-09-06 Overlap: 14:00-14:30 exists.
  14:15 → refused (expected refused) OK
  14:30 → accepted (expected accepted) OK
  13:45 for 45min → ACCEPTED (expected refused) BUG

That third line is a bug report, a reproduction and a test case in one, and it took eight seconds to write. Hand it to the model exactly as it is and you will get a far better fix than from any description of the problem.

When the experiment is expensive

Some things cannot be tested by clicking: a race between two simultaneous requests, a failure that only happens under load, a bug that appears once a week. For those, the equivalent move is logging: add enough output that when it next happens you can see what the state was. The next lesson is about exactly that.

What does not change is the discipline. One variable, a prediction first, and a negative control to prove your test can fail.