EP4 Workflows: a production line with checkpoints, and no skipped steps

In EP3 we got several helpers. The next problem is not who is capable but order. Real work almost never finishes in one step: plan, build, check, then ship. Leave the AI to choose the order each time and some days it skips the check, other days it forgets the last step. A workflow locks that order in place.

The problem: good work, done differently every time

Ask where the AI goes wrong most often and the answer is rarely “wrote bad code”. It is “skipped a step”: saying it is done without running the build, or deploying and only then remembering it was never checked on a phone.

Factories solve this with a production line. Every piece passes the same stations in the same order, with checkpoints that bad pieces cannot get past.

Principle: steps that are the same every time go to a script, steps that need thinking go to the AI, and a checkpoint sits before everything irreversible.

Fixed steps versus thinking steps

Step	Who does it	Why
build, test, upload	script	identical every time, with a clear pass or fail
writing code or articles, fixing bugs	AI	needs interpretation
reviewing whether it is good enough	a second AI, or a person	needs judgment
deciding to go live	a person	hard to undo; the responsibility is a person’s

AI is good at the thinking. It should not be the one remembering which buttons to press. If the order can be written as a script, write it.

A real example: the line this article went through

The article you are reading went through this line, like every article here:

1. Write (AI), following the site’s writing guide, in Thai and English
2. Build (script), the first checkpoint. A title over 80 characters or a category that does not exist fails the build, and nothing moves on
3. Look at it on a real screen (AI opens a browser), the second checkpoint, at 375px in both languages. This one has caught a headline overflowing the screen and Thai words broken mid-word
4. Commit, so the work is in history and can be undone
5. Deploy (script): build, upload, then swap folders in one move, so readers never see a half-uploaded site, with the previous version kept for rollback
6. Check after going live: the new pages answer 200 and the other sites on the same server still open

Steps 2, 5 and 6 do not rely on the AI’s memory at all. Step 3 is written in the project handbook, with a hook reminding it (EP2).

Checkpoints that work

• Build and tests, the cheapest checkpoint, run every time
• Constraints in code, such as titles capped at 80 characters. The system refuses, which beats a polite request in the handbook
• A reviewing subagent: one writes, another checks (EP3)
• A person, the last checkpoint before anything irreversible: going live, deleting data, sending anything out

Background jobs need collision rules

Long workflows usually get pushed into the background, and there is a trap there. Another project of ours is research that runs experiments in queues lasting hours. Once a queue was told to stop, but 8 jobs inside it kept waiting, then timed out and burst into a new queue that had just started. The results got mixed up and had to be run again.

Since then the rule is one queue only: a lock file blocks a second queue, and a stale lock means clearing out the old jobs completely before starting again. It sounds small, but a line without this rule produces results you cannot trust.

Putting the AI inside a script

Claude Code can run non-interactively with claude -p, so it can be one step of a script:

npm run build && npm test || exit 1
claude -p "Read git diff main and summarise the risks to check before merging" > review.md

The script does the fixed steps, the AI does the step that needs thinking, and the result waits for a person to read. This can go into CI or run on a nightly schedule. Give it read-and-report access only; never let the AI in a script merge or deploy on its own.

Try it in 10 minutes

1. Write down the steps of the job you do most often, and circle the ones that are “the same every time”
2. Move the circled steps into one script, such as npm run check
3. Edit that job’s skill (EP2) to say “before calling it done, run npm run check and make sure it passes”

Where a person is needed

A person designs the line: how many steps, where the checkpoints go, and which ones must be a person. And when something bad slips through, a person asks “which checkpoint should have caught this?” and adds one, rather than just telling the AI to be more careful next time.

Next episode

By now the AI works as a team on a production line. The question that always follows is cost. EP5 covers choosing the right model for the job: which one to think with, which to search with, and which dial to turn before switching models.