What stays yours
A short list of decisions you do not delegate, and a rule for expanding it.
Delegation works when the boundary is explicit. Here is a default boundary that holds up across most codebases. Adjust it, but adjust it deliberately.
Yours, always
- What to build and why. Agents are excellent at building the wrong thing very quickly.
- Data model and schema changes. Migrations are hard to reverse and easy to generate.
- Public API shape. Anything with consumers you do not control.
- New dependencies. Every added package is a supply-chain and maintenance decision. Agents add them casually.
- Security and authorisation boundaries. Not because agents are bad at them — because you cannot verify them by reading a diff quickly, so the review cost is the wrong shape.
- Whether it ships. Your name is on the commit.
Theirs, by default
- Implementation inside an agreed shape.
- Mechanical refactors with a check command behind them.
- Test writing, once you have specified the cases that matter.
- Exploration and summarisation — where they are genuinely better than you, because they are fast and tireless at reading.
- Boilerplate, glue, and the fourth near-identical handler.
The rule for moving the line
Move a decision from your column to the agent's only when you can name the check that catches it being wrong. "The type checker will fail", "there is a test for that invariant", "the lint rule rejects it". If you cannot name the check, the decision stays yours — not forever, but until you build the check.
This single rule generates most of the practice in the rest of this course. It is why Module 04 spends so long on feedback loops, and why Module 05 is about encoding conventions into files the agent reads: both are ways of manufacturing checks so you can delegate more.
Can I name the automated check that fails if the agent gets this wrong? yes -> delegate it no -> either keep it, or go build the check first
Try it
Take the three tasks you listed in Lesson 1.4 and split each into the two columns. For every decision that lands in your column, write one sentence on what check would have to exist to move it. Keep that list — it is a backlog worth working through.
Takeaways
- Keep intent, schema, public API, dependencies, security, and the ship decision.
- Delegate anything you can name a failing check for.
- When you want to delegate more, build the check first. That is the whole growth path.
Why are security boundaries on the keep-it list even though a competent agent can often write them correctly?
Because the review economics are wrong, not the generation quality. A subtly broken authorisation check looks identical to a correct one in a diff, and there is usually no fast automated check that catches it. Per the delegation test, no nameable check means it stays yours — until you write the test that makes it delegable.
Module 01 of this course ends here
The Next Steps goes under it: why the process works at all, starting from what a forward pass actually does.
See what is in it →A course by Pieter Zandbergen