How much process does a change need? Sizing agentic work

In this lesson you'll learn:

• why the size of a diff is the wrong measure of how much process a change needs;
• the four questions that choose shallow, standard or deep work;
• how to write down what you are skipping, and the trigger that brings it back.

Sound familiar?#

• A one-line typo fix went through six generated documents and three sign-offs.
• A one-line change to a payment limit went through none, because it was "only one line".
• The team quietly stopped using its method because it was too heavy for most of the work.

These are the same mistake: sizing process by the size of the change. The fix is to size it by the change's risk.

What decides how much process a change needs?#

Not its size. Depth is a property of the change, not of the team or the method. A one-line change to a refund cap is tiny and deep: money leaves, and it cannot be taken back. A nine-hundred-line refactor of a read-only report is large and shallow: nothing it touches can do harm, and a flag turns it off.

This is one of this manual's mental models, and every major method has arrived at it independently. AWS's AI-DLC adaptive workflows choose the breadth and depth of each task from its complexity. BMAD's documentation says the process should size itself to the work. And the most common critique of spec-driven tools is that they do not, so small bugs get elaborate treatment.

Size a change, step by step#

Step 1 · Write the change in one sentence#

What it changes and what it touches. If it takes more than a sentence, it is probably two changes, and each gets its own depth.

Step 2 · Ask the four questions#

Step 3 · Choose the depth#

Step 4 · Write down what you are skipping, and why#

A depth decision is ten lines or fewer. It names the ceremonies being skipped and why each is safe to skip for this change: "no shadow run: read-only path, no action taken, rollback is a flag". A skip with a reason is a decision; a skip without one is how shallow becomes the default for everything.

Step 5 · Name the escalation trigger#

Name the evidence that would raise the depth mid-flight: if the change turns out to touch a gated write, it becomes deep. Escalating is normal, not a failure. It is exactly what an adaptive process is for. Whatever the depth, the spec is updated: a change with no spec change is a change nobody can review.

Where you'll use it#

• At the start of every change, in under ten minutes, by the architect or engineering lead.
• When a method feels too heavy: the answer is usually a shallower depth, not a different method.
• In review: the depth decision tells the reviewer what was deliberately not done.

Why it matters#

A process applied at one depth to everything over-serves most changes and under-serves the dangerous few. Teams then abandon it, and the first changes to lose it are the ones that needed it most. Sizing each change is what keeps the process alive where it matters.

Key takeaways#

1. Depth is a property of the change, set by its risk, never by the size of its diff.
2. Four questions choose shallow, standard or deep: danger, reversibility, teams, auditors.
3. Write down what you skip and why, name the escalation trigger, and keep the spec at every depth.

FAQ#

How do you decide how much process a software change needs?#

Ask four questions: what is the most dangerous tool or path it touches, can it be undone cheaply once live, does more than one team's work change, and does an auditor read the result. Money, identity, policy or irreversibility mean at least a standard process; several teams or an auditor mean a deep one; otherwise shallow is enough.

Isn't a one-line change always low risk?#

No. A one-line change to a refund cap, a permission or a policy threshold can be the riskiest change of the quarter. Size is a poor proxy for risk, which is why this manual reviews by risk band rather than by diff size.

What does "adaptive" mean in AWS's AI-DLC?#

AI-DLC's open-source adaptive workflows select which stages a task includes and how thoroughly each is run, from the complexity of the intent, so a simple defect fix skips the elaborate requirements analysis a new service would get. It is the same principle as sizing each change by its risk.

Should every change have a spec?#

Yes, at its depth. For a shallow change that may be one updated acceptance line. Without a spec change, a reviewer cannot tell what the change was meant to do.

Apply it in your role#

Across the enterprise. Across hundreds of changes, the depth rule is the governance lever: most go shallow, a few go deep, and the rule decides rather than a committee.

The ten-minute workflow. Right-size the process for a batch of changes:

For each change below, answer four questions: the most dangerous tool or path it touches; whether it
can be undone cheaply once live; whether more than one team's artefacts change; whether an auditor
reads the result. Recommend shallow, standard or deep, and name the evidence that would raise the
depth. Changes: <list>

Sources and credits#