Workshop #011 · Intermediate lids down — watch it go red

Riding the Fenceschecking work you cannot read

Your page is on the internet, which means for the first time it can break somewhere you are not looking. This is the dull round that stops that mattering.

By the end of today you will have a short list of things that must never quietly stop being true, and a machine that checks them every single time.

Presented by Emile du Toit
brainitconsulting.com

Where we got to

Here is an overview of the last two sessions in five lines.

You have a well — one place the information lives.
You have something on the internet at a real address, that works with your laptop shut.
Paddock, training ring, open road. Only the last one has the public on it.
And you can put yesterday's version back in about two seconds.
Which means it can now break where you cannot see it.

So today we go and look.

The fence you never rideThings break quietly. That is the problem.
Check the embarrassing thingsYou cannot check everything. Four will do.
Checking work you cannot readYou do not audit the soldering.
Making the machine ride the fenceBecause you will not, in November.
The round you still do yourselfFive minutes a month, and the homework.

Then the questions this always raises, the glossary so far, and the picture to photograph.

The fence you never ride

Things do not break loudly. That is the entire problem.

You brought one thing with you today: the bit of your page that would embarrass you most if it quietly stopped working. Hold on to it. It is the only thing on the syllabus.

Because here is how it actually goes wrong. Nothing catches fire. In March you asked for a small change to the wording, and somewhere in that change the phone number stopped being a link you can tap. It still looks like a phone number. It reads perfectly. It just does nothing on a phone, which is where every single one of your customers is.

You find out in July, from a man who says he tried to call you in April.

Fig. 1 — This is what a broken thing usually looks like. Not smoke and sirens — one rail down, a long way from the house.

That is the shape of nearly every real failure: quiet, slow, and found by a customer rather than by you. Nobody rode out to that corner of the fence for four months, because there was no reason to and nothing asked them to.

Three ways it happens, all of them ordinary

Somebody tidied. A line looked redundant, so it went. It was the line that said we do not price gas work.

Something underneath moved. You changed nothing. A service you depend on changed, and your thing quietly stopped agreeing with it.

A change fixed one thing and moved another. The commonest of the three, and it has a name: a regression. Something that used to work, and stopped.

You do not find out. A customer finds out, and does not always tell you.

Check the embarrassing things

You cannot check everything. You do not need to.

The reason most people never test anything is that testing sounds like a job with no end to it. It is not, because you are not trying to prove the thing is perfect. You are trying to make a short list of things that must never quietly become untrue.

Four or five. That is a good list. Ten is a suspiciously long list for a small business, and nought is where nearly everybody starts.

You have already written it

Go and find the map from session eight and look at heading four — how you will know it is right. Two or three concrete things that must be true, that somebody could check by looking. That was not a paperwork exercise. That list is what today turns into something a machine re-checks forever.

Dale's list, which he wrote in session eight without knowing what for

The three waiting jobs are all on the page. If one disappears, Dale does not call that customer back.

The gas job says we do not price gas. This is the one that is not about tidiness. Take that sentence off and the business is quoting for work it must not touch.

Nothing marked DRAFT ever reaches a customer.

There is no price anywhere on the list. Prices belong in the estimate, where they have been checked.

Notice what is not on it. Nothing about how it looks. Nothing about whether the wording is good. Nothing about speed. Those all matter and none of them belong here — the list is for things that are either true or false, and that you would be sorry to find out about in July.

The test to apply when you are deciding what goes on the list: if this quietly became untrue, would I want to know within the hour? If yes, it goes on. If it would only mildly annoy you, leave it off. A list of forty things nobody reads is worth less than a list of four that go red.

Not “is it perfect”. Just: what must never quietly stop being true?

Checking work you cannot read

It wrote two hundred lines. Pretending you reviewed them is worse than admitting you did not.

Here is the thing nobody in this line of work says out loud often enough. You have an assistant that can write more in ninety seconds than you could read in an hour, and you cannot check its work by reading it. Not now, and quite possibly not ever.

Some people deal with that by pretending. They scroll to the bottom, say “looks good”, and approve. Some deal with it by never letting it do anything meaningful. Both are worse than the third option, which is to stop checking the work and start checking what the work does.

You have been doing this your whole working life. You do not audit the plumber's soldering. You run the tap.

Three things to ask it, every time it builds something real

“What could this break that used to work?” Ask before it starts. The answer is usually short, specific, and something you would not have thought of.

“Show me it working.” Not a description — run it, and show me the output. If it cannot show you, that is worth knowing now.

“Write me the checks for this, in plain English first.” Read the sentences. If the sentences are right, the checks underneath are very likely right too, and you have just reviewed two hundred lines of work by reading four lines.

That third one is the whole trick of this session. You are not qualified to review the code and you do not need to be. You are extremely well qualified to read a sentence that says the gas job must always say we do not price gas and tell me whether that is true about your business.

And be honest about the limit. Checks tell you the things you thought of are still true. They will never tell you about the thing you did not think of. That is what the five-minute round in chapter five is for, and it is why it never quite goes away.

You do not audit the soldering. You run the tap.

Making the machine ride the fence

Because you will not do it in November, and you know it.

A test is nothing more than one of those sentences, written so a machine can check it. Not a document about testing. Not a methodology. One sentence, one check, and a plain answer.

Fig. 2 — Four sentences you wrote yourself, re-checked by a machine every time anything changes. The one in ember is what a caught mistake looks like.

All of them together are a test suite, and running them is the round. Dale's round is four checks and takes about a tenth of a second, which tells you something about the cost of this compared with the cost of the man who tried to call in April.

What you are about to see

1. Four checks, written as four English sentences. I read them out; nobody looks at the code underneath.

2. I run them. Four green.

3. I make an entirely reasonable edit — I tidy up a sentence that reads a bit oddly, the way anybody would on a Tuesday.

4. I run them again. Two red. And the reason is written in the same English I wrote: the gas warning has gone — that is the one that must never disappear.

5. Nobody had to notice. That is the point.

The failure message matters more than it looks. A check that fails with a page of machine noise gets ignored the second time it happens. A check that fails with a sentence you wrote yourself, about your own business, gets acted on — because you already agreed it mattered on the day you wrote it.

Where the round belongs

Fig. 3 — The round sits between the ring and the road. A change that fails a check does not reach a customer, and nobody had to remember to look.

Connect it once and it runs itself, on every marker, before anything reaches the open road. This is continuous integration — a heavy name for something small: somebody rides the fence every single time, without being asked.

You save a marker — session seven.
The round runs before the change becomes a preview.
All green, and it can go on to the open road when you promote it — session ten.
One red, and it stops there. Nothing reaches a customer, and you get told which sentence stopped being true.

Sessions seven, ten and eleven are one machine. That is why they came in this order.

The machine will do the round in November. You will not.

The round you still do yourself

Five minutes a month, and the things a machine will never notice.

Checks cover what you thought of. They are silent about everything else, and everything else is where the interesting failures live. So there is still a round you do on your own two feet, and it is genuinely five minutes.

The five-minute round, once a month

Open it on your phone. Not your laptop. Most of your customers will never see it any other way.

Tap the phone number and the email. Do they do the thing they look like they do?

Read it as a stranger. Does it still say what you do, or does it describe the business you had two years ago?

Check one number. A price, an hourly rate, an opening time. Is it still true?

Ask the assistant one question: “what on this page is most likely to be out of date?” It is surprisingly good at this, because it is the one job where being an outsider helps.

Put it in the calendar. First Monday of the month, five minutes, done. The month you skip it will not be the month it matters, and the month it matters you will be glad it is a habit rather than a decision.

Before the next session

Write your list. Four sentences, on paper, about the page you put live last session. Each one either true or false.
Start with the embarrassing one — the thing you brought with you today. That is check number one.
Give the list to the assistant and say: “write me checks for these four sentences, and keep my wording in the failure messages.” That last clause is the one that makes them useful in six months.
Run them. All green.
Now break your own page on purpose and run them again. If nothing goes red, the checks are decorative and you have learned something important early.
Put it back — session seven — and save a marker.
Then put the five-minute round in your calendar, monthly, starting next month.

If any of that goes sideways

Everything is at github.com/brainit-consulting/ai-workshops — pick end-of-011 from the dropdown for Dale's four checks, which you are welcome to copy the shape of.

And if wiring the round into your own project is where you stall: that is a twenty-minute job for somebody who has done it before, and an evening for somebody who has not. You know where I am.

Step five is the one everybody wants to skip and the one that tells you whether any of this was real.

Questions people actually ask

Six that come up every time this session is taught.

Is this not a job for a proper developer?

Anybody can see a rail is down. You do not have to be a fencer.

Writing the sentences is your job and nobody else can do it — you are the only one who knows which four things would actually hurt. Turning them into checks is thirty seconds of somebody else's work, and the assistant will do it while you watch.

How many should I have?

Ride the fence, not every blade of grass.

Four or five to start, and only add one when something has actually gone wrong — then write a check so that exact thing can never quietly happen again. A suite that grew that way is worth ten times one somebody wrote in an afternoon of enthusiasm.

What if a check fails and I do not understand why?

The gap tells you where to look, not how to mend it.

Paste it to the assistant and ask what broke and what it would do about it. That is a good use of it. What you must not do is switch the check off to make the red go away — that is taking the fence down because you are tired of mending it.

Do the checks slow everything down?

A tenth of a second, against four months.

Dale's four run in about a tenth of a second. Even a substantial round is under a minute, and it happens while you are doing something else. The slow thing is finding out in July.

Can it write the checks and the thing being checked?

The same hand that built the gate should not be the only one to test the latch.

It can, and mostly that is fine — but you must read the sentences. If it writes both the work and the checks and you read neither, you have a suite that proves the thing does what it does, which is worth nothing. Read the four sentences. That is your whole job.

What about the things I never thought of?

No round finds the gap you never rode out to.

Checks are honest about this: they only ever confirm what you already thought of. That is why chapter five exists, and why every genuine surprise should end with you writing one more sentence. The list grows out of things that actually happened, which is the only good reason to add to it.

Plain words

Everything the series has named so far. Today's are marked.

This list grows every session and always shows the lot, so you never need last week's handout to read this week's.

Large language model (LLM) 001: The engine that predicts the next word. The horse.
GPT 001: Generative — it makes new text rather than looking up a stored answer. Pre-trained — all its learning happened in advance. Transformer — the design of the machinery underneath. A breed name, not a job title.
Knowledge cutoff 001: The date its training stopped. It knows nothing after it, and doesn't know that it doesn't. The last day the horse was out in the world.
Prompt 001: What you type. A pull on the reins.
Chatbot 001: A model you can talk to, turn by turn. Horse plus bridle.
System prompt / instructions 001: Standing orders sent with every message, whether you type them or not. The saddle.
Context window 001: How much of the conversation it can hold at once. How far it can see on this ride.
Token 001: A chunk of a word — how length is counted, and how you're billed. Sugar cubes.
Hallucination 001: Making something up and sounding certain. Shying at a shed snakeskin.
Tool 002: A specific action it's allowed to take in the real world. A saddlebag.
MCP 002: An agreed standard for plugging tools into a model. Standard-size buckles.
Agent 002: A model given a goal, tools, and permission to keep going. A working horse, not a show pony.
Agentic loop 002: Look, decide, act, check, repeat. The ride itself.
Human in the loop 002: A person approves before something real happens. A hand on the reins.
Automation 002: The same work happening without you starting it each time. The horse knows the route.
File 003: A thing with a name and contents. A single piece of gear.
Folder (directory) 003: A box holding files, and sometimes other folders. A shelf.
Project 003: One folder holding one job's worth of everything. The room, with the door shut.
Path 003: The written address of a file — which boxes it sits inside. Directions to the shelf.
Editor (VS Code) 004: A window showing you one folder and everything in it. The tack room.
Terminal 004: A panel where you type an instruction to the computer directly. Talking to the stable itself.
Install 004: Putting a program on your own machine, once. Building the room.
Permission prompt 005: The stop before it changes anything, showing what it plans to do. The gate, and your hand on the latch.
Approval mode 005: Whether it asks every time, works on its own, or only shows a plan. How loose you're holding the reins.
Interrupting 005: Stopping it mid-job with the escape key. A pull on the reins. Ordinary.
Project instructions 006: A plain-English file of standing rules that lives in the folder. The saddle, hanging in the room.
Run a command 006: Doing something on the computer rather than writing words about it. Actual work, not conversation.
Working on copies 006: Duplicating a file so the original can't be harmed. Schooling in the paddock, not on the road.
Version control 007: Keeping every previous version of everything, so any of them can come back. A trail you can ride back.
Git 007: The program that keeps the trail. It runs on your own machine. What drives the markers in.
Commit 007: One marker, with a short note saying what you had just done. A gate you can ride back through.
Repository (repo) 007: A folder that keeps its own history. The field, with the trail marked in it.
GitHub 007: A copy of the repository kept online — a real backup, and a way to hand it to somebody. The shared stable at the trailhead.
Push and pull 007: Sending your markers up to that copy, and fetching down anything that is there and not here. Riding to the trailhead and back.
Spec (brief) 008: One page describing a job well enough to hand it over. What it must do — not how to build it. The trail map. Where you are going, not which foot the horse leads with.
Scope 008: What is in this job, and what is deliberately not. Where the map stops. The country past the edge is not today's ride.
Acceptance 008: How you will know the thing is right when you see it. How you know you arrived.
Plan mode 008: A setting where it works out what it would do, and shows you, before touching anything. Reading the map aloud before anyone mounts up.
Assumption 008: Something you took to be true and never checked. A stretch of map you drew from memory rather than from riding it.
Database 009: One place the information lives, built to be read and written by several things at once without ever disagreeing with itself. The well.
Table 009: A list of one kind of thing, with the same facts recorded about each one. One list on the slate: every job, every time.
Row 009: One of the things. One job, one customer, one invoice. A single line on the slate.
Column 009: One fact, kept about every row. Customer. Status. Date received. The same question asked of every line.
Query (SQL) 009: A written question put to the database. SQL is the language they are written in. Lowering the bucket, and what you asked it to bring up.
Connection string 009: One line of text that says where the well is and unlocks it. Treat it as a key, because it is one. The key to the pump house.
Postgres (Neon) 009: The most widely used serious database; Neon is a company that runs one for you. A well somebody else dug, and maintains.
Deploy 010: Sending a copy of your work to a machine that is always on, so other people can reach it. Loading the wagon and driving it to market.
Production 010: The version the public sees. There is only ever one. The open road.
Preview 010: The same work, live on the internet, at an address only your people can open. The training ring — real ground, fence round it.
Rollback 010: Putting the previous version back as the public one. Seconds, not a repair job. Turning the wagon round.
Domain 010: The name people type. Yours, rented by the year, pointed at your work. The name over the stall.
Environment variable 010: A secret kept on the machine that serves the page, never inside the page itself. The key stays in the driver's pocket.
Test 011: One thing that must always be true, written so a machine can check it. One fence post you ride out to.
Test suite 011: All of them together, run in one go. The whole round.
Regression 011: Something that used to work and quietly stopped. A gap that opened where you had already mended it.
Continuous integration (CI) 011: The machine running the round for you, on every single change. Somebody rides the fence every time, without being asked.
Edge case 011: The odd situation nobody thought about until it happened. The corner of the field where the ground goes soft.

★

Everything on one page

If you photograph one thing today, photograph this.

1 · One rail, gone

No alarm. Nobody tells you. A customer finds it in July.

2 · Four sentences

Things that must never quietly stop being true.

3 · The round, then the road

One red and it never reaches a customer.

Next session

4 · Who's at the gate

Logins, accounts, and keeping one customer out of another's business.

The whole method: write four sentences that must never quietly stop being true, have the machine check them on every change, and ride the fence yourself for five minutes a month for everything you did not think of. Add a sentence each time something surprises you. That is a testing practice, and it fits on a beer mat.

Next session

#012 — Who's at the Gate

Everything you have built so far has one user, and it is you. The moment somebody else needs to log in — a member of staff, or a customer looking at their own job and nobody else's — a set of new questions arrives all at once. Next time is the last session in this series: who is at the gate, how the thing knows them, how one customer is kept out of another's business, and how it sends an email without you.

Before you come: answer the question from session nine in writing, for your own project. Just you, you and your staff, or your customers?

Want someone to hold the reins with you?

I do this for a living, and love to help people.

Thirty-plus years in enterprise software and a computer science degree — which mostly means I have watched a great many horses bolt, and I can usually tell you which ones are worth saddling before you spend money on the saddle.

In person

Your team, your room, your actual work on the whiteboard instead of somebody else's examples.

Over video

The same session, at your desks, with fewer chairs to stack afterwards.

Built for real

When the idea survives the workshop and somebody has to go and build the thing — that part I do too.

Fun fact — I rode to school on horseback as a kid in South Africa. So the metaphor isn't borrowed. I've done the falling off in person.

Emile du Toit brainitconsulting.com

Workshop #011 · Riding the Fences
© 2026 Emile du Toit, BrainIT Consulting
Print it, download it, share it with your team. Just leave my name on it.