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
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.
Contents
- Before you startThree things about your site that must never stop being true.
- 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.
Before you start
- Workshop #010 done — something of yours published, and the change-commit-live loop working.
- Node.js installed. The checks run with Node's own test runner, which means nothing to install beyond Node itself. The setup page has it.
- Three things about your site that must never stop being true. Bring them written down. That is genuinely the hard part of today.
- About 45 minutes.
This is the workshop the free browser route does not reach. The labs need the assistant writing a test file into your folder and running it, and doing that by copy and paste is an evening rather than an hour. If you have come this far free, this is the point where the $20 earns itself — and you now have eight workshops of real use behind you to judge that on. No testing framework, no configuration file, nothing else to buy. If you would rather not install Node, read it through — the idea transfers, and Lab 1 is worth doing on paper regardless.
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.
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.
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.
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?
Lab 1 — Write the three sentences 15 min
This is the whole workshop, and it needs no computer. Everything after it is plumbing.
Finish this sentence three times
“I would be embarrassed if, one day without noticing, my site stopped …”
Real answers from real people: the phone number vanished. The gas warning came off. The opening hours said Sunday when we are shut. The contact form went to an address nobody reads.
The test for a good one
- Is it true or false? Not “looks professional” — something you could point at.
- Would you notice if it broke? If yes, within a day, it does not need a check.
- Would it cost you a customer, a call-out, or an apology?
Write them as plain sentences
Notice you have just written a specification without anybody using the word. If those three sentences are right about your business, the checks will be right. Everything after this is plumbing.
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.
“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.
Lab 2 — Have it write the checks 15 min
You wrote the sentences. It writes the code. You never have to read the code, and that is not a cop-out — it is the same deal as an accountant preparing your return.
Hand over your three sentences
Run them
Three green. That is the fence, ridden, in under a second.
The part that matters: make it go red
A check that has never failed proves nothing. Delete your phone number from the page, save, and run it again.
It goes red, and it tells you which of your own sentences is no longer true. Put the number back and watch it go green.
Do this every single time you add a check. A green suite you have never seen fail is a fence you have never actually ridden.
Lab 3 — Make a change any sensible person would make 10 min
The real value of a check is not catching a typo. It is catching a change you made on purpose, for good reasons, having forgotten why the old thing was there.
Tidy something up
Find a line on your page that reads a bit clumsily and is doing a job you have forgotten — the disclaimer, the exception, the thing you added after a bad week. Tidy it away. It reads better now.
Run the checks
Red. In your own words, from a sentence you wrote yourself when you were thinking clearly about what mattered.
Sit with that for a second
Nobody had to notice. Nobody had to remember why the line was there. You were about to make a perfectly reasonable change that would have cost you three wasted call-outs, and a machine you set up in fifteen minutes stopped you.
Somebody always asks: “why not just remember not to delete it?” Because in July, in a hurry, on a different page, with somebody else editing — you will not. That is what the check is for.
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.
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.
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. One 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
Connect it once, switch on the hold, 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 while the change becomes a preview.
- All green, and it goes on to the open road — when you promote it, as in session ten, or by itself on main once Lab 4 has switched on the hold.
- One red, and it stays in the ring. Vercel holds it, the last good version stays on the road, 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.
Lab 4 — Make the machine ride the fence 15 min
A check you have to remember to run is a chore you will stop doing by March. Wire it to the publishing loop and it rides itself.
Ask for it
Prove it works, both ways
- Commit and push with everything passing. Look at the Actions tab on GitHub — a green tick. Note the name of the job beside it. You need it next.
Switch on the hold
Until now a red round only told you. From here, it holds the road.
- On Vercel, open your project, then Settings, Build and Deployment, Deployment Checks, Add Checks.
- Choose GitHub. Search for the job by the name the Actions tab showed you, and select it.
Vercel knows the job by its name. Rename it, and you come back here and pick it again. It also needs automatic aliasing for production switched on, which it is unless you turned it off.
Now break it
- Break one thing on purpose, commit, push to main.
- A red cross, and an email telling you which of your sentences is no longer true.
- On the Vercel dashboard the new version is there, waiting for its checks. Open your address: it still shows the last good version.
- Put it back, commit, push. Green, and it goes live by itself.
A held version has a Force Promote button on its deployment page that sends it out anyway. It is for the rare day a check is wrong, not the day you are in a hurry.
That is the fence being ridden without you, and the gate staying shut until it has been. It costs nothing, it runs on every change forever, and the only thinking you ever did was the three sentences in Lab 1.
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.
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 you close this page
The four labs are the doing. Two things are worth carrying out of here.
- Put the five-minute round in your calendar — monthly, starting next month. Not the automatic checks, which now look after themselves. The round you still do: open the thing, use it the way a customer would, and look at it with fresh eyes. That is the one no machine does for you.
- Answer the question from #009 in writing, for your own project: who is going to use this? Just you, you and your staff, or your customers? #012 is the last workshop, and how much of it applies to you is decided entirely by that one line.
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.
The first one is the one everybody wants to skip, and it is the one that tells you whether any of this was real. A check that runs itself is worth having. A person who still looks is worth more.
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 notes 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.
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.
#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 start it: nothing new to install. #012 is the one workshop where the reading is worth more than the building.
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, share it, leave my name on it.