Make the Change Easy

Kent Beck wrote the rule long before language models could write code: "for each desired change, make the change easy (warning: this may be hard), then make the easy change." Most teams file it under refactoring wisdom. We treat it as the operating principle of AI-augmented development, because everything AI changes about software work makes the rule more important, not less.

Here is the claim, plainly: what drives real velocity from AI coding tools is not prompting skill. It is whether the change was made easy before the model ever saw the codebase. The prompt is the least important part of the workflow. The state of the code when you type it determines most of the outcome.

What happens when you skip the first half

Watch what most engineers do with an agent. They open a session against a codebase that has grown organically for two years and type "add OAuth."

The model now has two jobs at once: reorganize the auth-adjacent code into a shape that can accept OAuth, and implement OAuth inside that shape. In a single diff it is inventing structure and filling it at the same time - judgment calls and pattern application interleaved line by line. What comes back touches forty files: some moves, some renames, some new abstractions, and somewhere in the middle, the actual feature. You cannot review it, because you cannot tell which hunks are restructuring and which are behavior. So you either rubber-stamp it or throw it away.

Both outcomes feed the studies finding that AI assistance makes experienced developers slower. The model didn't fail. The change was never made easy.

Phase one: mechanical preparation

The workflow we use and teach runs in two phases, and the first one contains no feature work at all.

Phase one is preparation, and it is deliberately mechanical: lift, shift, extract, spread. Move the session handling out of the controller it grew up in. Extract the token logic into its own module. Take the pattern that already exists in one service and spread it across the three places that do the same thing differently. No new behavior. No logic edits.

This matters for a specific reason: mechanical preparation has near-zero judgment calls per line. That is exactly the work AI is best at - high-volume pattern application with a verifiable definition of done. And it produces the cheapest possible diffs to review, because the review question is binary: did behavior change? Tests stay green, call sites move, nothing new executes.

It also means preparation diffs can be enormous and still be safe. A client engineering team we advised opened a build phase by breaking a monolith apart in a single preparation pass: 1,117 lines added, 5,930 removed, net minus 4,813. It was larger than any feature PR that followed and the fastest to review, because every hunk was a move or a deletion.

The "warning: this may be hard" clause in Beck's rule survives intact, but it relocates. Deciding the target structure - where things should live, which seams to cut, what the landing zone looks like - is the hard part, and it stays human. The model executes the move at machine speed. It does not get to decide where things go.

Phase two: the easy change

With the structure in place, the feature itself becomes a small, focused addition into a clean landing zone. The diff where behavior actually changes is fifty lines, not four thousand, and it lands in a structure that was shaped yesterday specifically to receive it.

This is where human judgment belongs: concentrated on a tiny surface area where every line is a decision. You are no longer reviewing restructuring noise to find the logic. The diff is the logic.

The two phases are not a ceremony. They split the work along the line that matters for AI: phase one maximizes volume where judgment is cheap, phase two minimizes volume where judgment is expensive.

The 10+10 cadence

The unit of work in this workflow is not the day-long session. It is a roughly twenty-minute cycle, split in half:

• ~10 minutes: feed context, prompt, generate.
• ~10 minutes: review the diff line by line, post-edit by hand where needed, clean up, commit, compact the session.

Then repeat.

Two things fall out of this cadence. First, review is inside the loop, not a phase at the end. Every cycle ends in a commit, which means the codebase returns to a known-good state every twenty minutes - there is never an hour of unreviewed machine output sitting in the working tree. Second, the cadence is a scoping test: if a cycle runs well past twenty minutes, the task was too big, and the fix is to cut the task, not to extend the cycle.

The cadence also has a resource side - the context window and the session itself are both bounded, and sizing the cycle is how you ration them. That is its own framework: Context and Session Management - capacity bands for the window, context rot, and why sessions should end on purpose.

This is not vibe coding

Every line of code in this workflow is reviewed. The model proposes diffs; the engineer does code review, every cycle, with post-edits by hand where the proposal is close but wrong. The cadence is what makes that economically possible - ten minutes of review per cycle is affordable in a way that reviewing a day of accumulated output is not.

The same client engagement sustained 3,000–4,000 absolute lines per day for fifteen consecutive days - roughly 48,000 absolute lines - with full review on every cycle. That throughput is not what happens when you remove the human from the loop. It is what happens when preparation makes the changes easy enough that the human in the loop stops being the bottleneck.

What this workflow does not solve: it will not rescue a team that never stabilizes (see The Stabilization Pass), and it does not change the arithmetic of how fast quality burns when the review layer thins (see AI Code Nines). It is one discipline among several, and it is the one that determines whether the model's first attempt lands in a structure built to receive it.