The Work Loop -- Six Steps That Make Accountability Concrete
Personal accountability is a conviction. The work loop is what that conviction looks like when it meets real code.
I've been running this process for more than a year. Not as an experiment -- as my actual working method, every day. What follows is not theory. It's what works.
Why a Loop Is Needed
LLM-assisted development has a fundamental problem: the context window is finite and fragmented.
You read the project, talk with the model, write some code, talk more, change focus, switch back. Halfway through the implementation, the model no longer remembers what you decided in the planning phase. Planning noise follows you into the implementation and corrupts it.
The loop solves this. Each phase starts clean. Planning stays in the plan. Implementation begins with only what's needed to build.
The Six Steps
Step 1: Read the project
Load the context window with everything relevant -- codebase, guidelines, git history, architecture decisions. Five minutes of context loading saves hours of correction later.
This step is not preparation. It is work. You read to understand what the system actually does, not what you think it does.
Step 2: Write a change request
Describe the task in a file on disk. Not in the chat. The file survives the next step.
A CR should answer three questions: What needs to be done? What is the acceptance criterion? What is out of scope?
Large task? Break it into phases. One file per phase. Each phase has its own scope and acceptance criteria. That forces precision -- you cannot plan vaguely when every phase must be able to stand on its own.
Step 3: Clear the context
Close the conversation. Start from zero.
This is the step most people skip -- and it's the most important. The planning discussion contains uncertainties, alternatives, discarded ideas. It should not carry over into the implementation. Only the CR goes with you. And relevant code.
Clean context window = clean output.
Step 4: Build from the plan
Follow the CR. Nothing else.
Something unexpected happens? Stop. Update the CR first. Then implement. That can feel cumbersome. It is not -- it is what separates intentional implementation from drift.
Step 5: Review every line
Read the diff. Assess your confidence:
- High: I understand every line. I can explain why. → Commit.
- Medium: It looks right but I'm uncertain about parts. → Review more. Ask the model. Ask a colleague.
- Low: I don't understand why this works. → STOP. Understand before proceeding.
This step is the work. Not a hurdle in front of the work -- it IS the work. This is where personal accountability takes shape in action. Every line you review is a line you own.
Step 6: Commit and document
Manual commit message. Update changelog. More phases to go? Back to step 3 with the next phase.
The commit is not administrative work. It is the final accountability step -- you put your name on what you have reviewed and understood.
The Inner Loop
For large tasks with multiple phases, steps 3 through 6 repeat for each phase. Each phase gets a clean context window.
That's called the inner loop. And it's what keeps complex tasks manageable -- not because they're simple, but because you never carry more than one phase at a time.
What the Loop Actually Is
The loop is not a productivity technique. It is an accountability structure.
Step 2 forces you to think clearly before you build. Step 3 protects the implementation from planning noise. Step 5 means you cannot commit what you don't understand. Step 6 puts your name on what you own.
Every step is designed to make it harder to escape the consequences. Not as punishment -- but because that's how good code actually gets created.
Personal accountability is a conviction. This is what it looks like when it works.
See also: You Can't Validate What You Don't Understand (series 17) and AI Forces You to Think Harder (series 12).