Work out the steps before you split the work
Either you already hold the pattern of the work or you have to go and find it. That, not size or difficulty, is what decides how the work gets cut up.
Before anything gets handed out, decide how the work is cut up. There are two ways to do it. Either you already know the steps, so you write them down and run them in order, or you do not, in which case the first step has to go and look before anyone can say what the second one is.
What you are reading is whether you already hold the pattern of the work or have to go and find it. Reviewing a set of pages before they go out is the first kind, because the things you want checked are known before you start, so those become the steps. Working out why a call returned a hundred items when there were a hundred and fourteen is the second kind, because the first look is what decides where the second one goes. Same site either way, so it is not size or difficulty that decides it. It is whether the shape is already known.
Common questions
- When does a fixed pipeline work?
A fixed pipeline works when you know beforehand what tasks are required to get the work done. Reviewing a set of pages is that kind of job, because the aspects you want checked are known before you start. - What happens if I use one when I do not know the steps?
You would just be guessing at the required pipeline. Fixing the steps when you do not know them is not a plan, it is a guess with a map on it, invented before anyone had seen anything. - So what do I fix instead of the steps?
Fix the scope: how far the work goes and what has to be true before it stops. Write that stopping condition down the way you would write an acceptance criterion, because work that invents its own next step will keep on inventing one. - Does the size of the job decide which one to use?
No. It is the same codebase either way, so size or difficulty is not what decides it. What decides it is whether the shape of the work is already known before you start. - How do I cut up a big review?
Splitting by unit works when the work on each piece is much the same. Splitting by aspect is one lens over everything, a security pass then a performance pass. Both keep the work focused so it is not shallow where it counts. - When is grouping better than splitting evenly?
When two pieces only make sense together. Keep a template with the trigger that fires it as one group, so a single pass holds the whole story rather than two passes each holding half of it.
Back to For developers. The craft around it is Working with AI.