Skip to main content

Module 4: The local ADW loop

Prefer to listen? 🔊
Narrated by the Wasteology Academy guide (~90 sec)

You've met the pieces separately: spec-first planning (Module 3), the human merge gate and maker-checker verifier (Module 0). This module puts them together into the actual sequence the loop runs, and has you run it yourself — entirely on your local subscription, not the metered API.

The loop, in order​

This is the real sequence implemented in adws/adw_plan_build.py:

Walking through each step:

  1. Classify the work item — bug, feature, or chore. This shapes how the rest of the loop treats the task.
  2. Generate a branch name from the task.
  3. Plan the implementation — Claude Sonnet (claude-sonnet-4-6) writes the plan, grounded in the task (and, ideally, in lat.md context from Module 2).
  4. Review the plan — a separate pass critiques it, as covered in Module 3.
  5. Implement — Claude Sonnet (claude-sonnet-4-6) writes the actual change.
    • 5.5. Review spec completeness, only if the task carries a spec_file — and skipped entirely if the spec was already complete.
  6. The maker-checker gate — an independent adversarial verifier checks the implementation before it's allowed anywhere near a commit. This is not the same pass that wrote the code. If the work is unfinished or unverified, it does not proceed.
  7. Commit — the commit message is generated by Gemini Flash, not Sonnet. This is a deliberate cost choice: using a cheaper, faster model for a low-stakes text-generation step saves roughly 98% on that specific step's cost, with no reduction in the quality of the actual code.
  8. Create the PR — draft by default, which is the always-on human merge gate from Module 0. A human reviews the diff and presses merge. (A legacy option, ADW_AUTO_COMPLETE=true, restores auto-squash-merge — most teams should leave this off.)

The maker-checker gate, closer up​

This is worth dwelling on because it's the mechanic most likely to get flattened into marketing language elsewhere. The concrete claim is narrow and verifiable: the agent that writes the implementation is not the same pass that approves it for commit. An independent verifier sits in between and can send work back for rework rather than letting it through. "The maker no longer grades its own homework" is a fair one-line summary of that mechanic — not a metaphor standing in for something vaguer.

Caging the LLM — the architecture of ADW (NotebookLM-generated)
Reading the video

"Caging" is evocative framing for what is, mechanically, a fixed sequence of steps with an independent verifier and a human gate — not a sandbox or containment technology. Where this track can name the exact mechanism (as above), trust the mechanism over the metaphor.

This runs on your local subscription​

Everything in this module — classify, plan, review, implement, maker-checker, commit, draft PR — is available to run from ops digest runner --local, which dispatches to the local Claude Code CLI on your own Claude Code subscription. Nothing about this loop requires metered API access. That's the entire point of teaching it first: you get the full mechanics of spec-first + human-gated ADW at zero marginal per-run cost, on hardware you already have.

The two cloud execution models — a central ADO pipeline and repo-native GitHub Actions — run this same shape of loop, but on the metered Anthropic API instead of your subscription. You'll meet both in Module 6. For now, everything you practice in this module's lab transfers directly: the sequence doesn't change when it moves to the cloud, only where it runs and how it's billed.

Wastey says

If a task is small enough to fit your local loop, run it locally. You lose nothing in rigor — the maker-checker gate and the draft-PR human merge are exactly as real locally as they are in the cloud — and you pay nothing extra to iterate.

Hands-on lab​

  1. Pick a trivial, low-stakes change in a repo you can safely experiment in — the kind of thing you'd be comfortable with an agent touching unsupervised for a minute (a docstring, a small refactor, a chore-tier fix).
  2. If the repo supports ops digest add-task, add your change as a task and dispatch it with ops digest runner --local. If you don't have that tooling available, walk the same shape manually in a Claude Code session: ask it to classify the task, propose a plan, implement it, and explain what a maker-checker-style self-review of its own work would look for.
  3. Watch for the PR (or proposed diff, if you did this manually) landing as a draft, not merged. Read the commit message it generated — notice it reads like a human-authored, low-effort commit message rather than a verbose model-generated one; that's the Gemini Flash step doing its job cheaply.
  4. Actually perform the human merge step yourself. Read the diff in full before merging — don't skip this because it's a trivial change. That habit is the whole point of the gate.

Practice: step through a local run​

The full ADW loop — each step with its actor, ending at the always-on human-merge gate.
The full ADW loop — each step with its actor, ending at the always-on human-merge gate.
Step 1 of 7Local ADW loop

1. Classify

ADW reads the work item and classifies it — bug, feature, or chore. That classification shapes the plan and the branch name.

And this is the command that kicks it all off locally — on your own subscription, unmetered:

your machine — unmetered subscription
$ ops digest runner --local▋

Knowledge check​

Which model is used for the plan and implement steps in the real loop?
What does the maker-checker gate actually verify, and who performs it?
What is the default behavior when the loop finishes and opens a PR?
Where does this entire loop run when you use ops digest runner --local?

You've completed the local foundation of the ADW Track. Modules 5 through 8 and the capstone continue the arc into evidence and validation, cloud scaling, onboarding your own project, and cost/safety governance.