Concept: Code vs. Infrastructure in an ADW
What you'll take away
Every ADW-produced pull request contains two different kinds of change, and they deserve two different kinds of scrutiny:
- Code — the bespoke, per-task product: application logic, files, functions, types, database schema. This is what the agent actually wrote for this task, and it is different every time.
- Infrastructure — the deterministic, reused scaffolding: the ADW loop itself, the gates it runs through, the environment it executes in. This is built once (by an engineer, deliberately) and then reused, unchanged, across hundreds of tasks.
By the end of this page you should be able to: name which layer a given change belongs to, explain why that split determines how much of a PR you personally need to read line-by-line versus trust at a glance, and apply a concrete checklist the next time you review an ADW-produced PR.
The core mental model
The framing here is adapted from IndyDevDan's "agentic operating level" idea (see Attribution below): as you or your agent move up a stack of abstraction, you gain leverage and speed but lose direct control and understanding. As you move down, it's the reverse. Neither direction is "better" — the skill is choosing the right level for the problem in front of you, and being able to move both ways.
Applied to an ADW, that stack splits cleanly into two zones:
| Zone | What lives here | Changes... | Reviewed by... |
|---|---|---|---|
| Infrastructure (the harness) | The ADW loop's steps, the maker-checker gate, the draft-PR + human-merge gate, the execution environment (local subscription vs. cloud), CI checks | Rarely — engineered once, then reused for every task | Whoever builds/maintains the ADW itself; reviewed as infrastructure work, not per-task |
| Code (the product) | Application logic, files, functions, types, classes, database schema/migrations | Every single task — this is the actual diff | The human at the draft-PR merge gate, every time |
The failure mode the video warns about maps directly onto this split: leverage without control is meaningless. If you trust the infrastructure layer so much that you stop looking at the code layer at all, you've given up the one checkpoint that actually catches a bad change before it ships. Conversely, if you re-derive every line of every PR by hand, you've thrown away the entire point of building the harness in the first place.
Two more ideas from the video are worth carrying into this model directly:
- "Three makes a pattern." If you've done the same task by hand three times, that's the signal to stop doing it manually and push it into the infrastructure layer (a script, then an ADW). This is exactly how a one-off manual fix should graduate into something the harness handles for every future occurrence.
- "Out of distribution." A model is reliable ("in distribution") for common, well-represented work — a REST endpoint, a Postgres table, a serviceable UI. It is unreliable ("out of distribution") for anything it hasn't seen enough of, or was actively trained to avoid — often exactly the internal conventions, compliance rules, or domain quirks that make your codebase yours. No amount of trustworthy infrastructure substitutes for a human recognizing "this is out of distribution for the model" and dropping down to the code layer to check it directly.
Mapping this onto our real ADW setup
The video's framework is a general mental model; here is how it lands on the actual mechanics this track teaches.
The local-first loop is the infrastructure layer, and it's intentionally
boring. adws/adw_plan_build.py runs the same seven-ish steps for every
task — classify, generate a branch name, plan (Claude Sonnet), review the
plan, implement (Claude Sonnet), an independent maker-checker verification,
commit (Gemini Flash writes the message), and open a draft PR. None of
that sequence changes based on what the task is. That's the point: it's
infrastructure precisely because it's the same scaffolding every time,
engineered once by someone with real harness-engineering skill, and it runs
on the developer's own Claude Code subscription — no per-run metered cost.
This is also where the video's "three makes a pattern" heuristic is already
applied inside our own tooling: the commit-message step is low-stakes and
repetitive, so it deliberately uses the cheaper Gemini Flash model instead
of Sonnet, saving roughly 98% on that one step with no loss of code quality.
The two cloud execution models are the same infrastructure, relocated.
Neither cloud model changes the shape of the loop — they change where it
runs and how it's billed. The central ADO pipeline (pipeline 9) queues
work to a self-hosted ADW-Agents pool and can target other repos by name
(re-validated against a hardcoded allowlist before cloning). The
repo-native GitHub Actions model (the "Mars model") triggers off an adw
label on an issue and runs on an ephemeral runner, passing only the issue
number to the agent — not the issue body — so a malicious issue can't
inject instructions. Both still open a draft PR. Both are infrastructure
in exactly the video's sense: built once, reused for every task routed to
them, and never something a reviewer needs to re-derive per PR — you review
that infrastructure once, as its own piece of engineering work, not every
time it runs.
The draft-PR + human merge gate is the permanent "go back down"
checkpoint. However high up the leverage stack a change came from — a
local run, a cloud pipeline, eventually a "software factory" composing many
ADWs — every single change re-enters at the same place: a draft PR that a
human must read and merge. This is the literal, mechanical answer to the
video's "leverage without control is meaningless" warning. It's also why
ADW_AUTO_COMPLETE=true (which restores legacy auto-squash-merge) should be
treated as an explicit, rare opt-out, not a default — it deletes the one
guaranteed control point in the whole system.
Sandbox vs. production is the video's "high risk, high impact -> go down and get control" rule, encoded as infrastructure instead of left to discipline. The video argues that when a domain is high-stakes, you should drop to a lower, more controlled level rather than trust leverage. Our setup doesn't rely on every reviewer remembering that rule under pressure: dev/staging/prod environment separation and scoped credentials make it structurally hard for an agent (or a careless human) to reach production data directly. The code layer still changes per task; the environment separation is infrastructure that stays constant.
Evidence gating operationalizes "if the debugging evidence is weak, you
have to go down." The video's line — you must have some way to tell good
outcomes from bad ones, or you're flying blind — is exactly what the
evidence-gated validation pattern automates. For web-UI work, a Playwright
validator produces a chaptered walkthrough, before/after screenshots, and a
RESULTS.md verdict; if that evidence artifact is missing or unconvincing,
promotion is refused. "Absence of proof is failure" is the infrastructure
saying: don't make the human manually notice weak evidence — refuse to
proceed without strong evidence in the first place.
The maker-checker gate is "the maker doesn't grade its own homework," built into the harness. An independent verifier — not the same pass that wrote the implementation — checks the work before it's allowed near a commit. This is infrastructure standing in for a control-heuristic a human reviewer would otherwise have to apply manually on every PR: don't just trust that the author checked their own work.
How to think while reviewing an ADW PR
A practical checklist, combining the video's leverage/control decision framework with the gates this track teaches:
- Start at the diff/plan level, not the line level. The application and repo layer is the natural place to begin — it's where you can see both what changed and, if a spec/plan is linked, why.
- Check that the gates actually fired. Is this a maker-checker-passed,
draft PR (not an auto-merged one)? If the work is evidence-gated, is
RESULTS.md(or the equivalent artifact) present and does it look like real proof, not noise? Missing or weak evidence is your signal to stop trusting the harness and go down a level. - Ask: do I understand this domain and this part of the codebase? If it's unfamiliar — a new service, a new business rule — go down and read the actual code. Don't review at the summary level for something you don't already have a mental model for.
- Ask: is this high-risk or high-impact? Anything touching auth, billing, PII, production data, or financial calculations earns a line-level read regardless of how clean the diff looks or how well the gates passed.
- Ask: could this be out-of-distribution for the model? Internal conventions, unusual domain rules, or compliance requirements a general model wouldn't know are exactly the places an agent tends to guess plausibly and wrongly. If the change touches one of those areas, check it specifically rather than assuming the model "knew."
- Give the data layer extra scrutiny even when everything else looks fine. Database schema and migrations are contracts for the rest of the system — mistakes here are expensive and often silent until much later.
- If it's routine, familiar, low-risk, and well-evidenced, trust the infrastructure and move fast. That's the entire value of having built it: you don't need to re-derive every line of a change your gates were specifically engineered to catch problems in.
- Regardless of level, you are the merge. Draft PRs never self-merge. No matter how much leverage the loop gave you, a human presses merge.
Attribution
The "operating level" / leverage-vs-control framing used throughout this page is adapted from:
"Agentic Engineering Operating Level: WHERE to FOCUS your AGENTS?" by IndyDevDan (YouTube, ~36:32, published 2026-08-31) https://www.youtube.com/watch?v=rPWCYB62wvI
The video's own framework runs from individual lines of code up through a "software factory," and includes a promotional segment for the creator's paid course plus speculative teasers ("dark factory," "RSI") for levels beyond current practice — those are marketing framing, not mechanics, and are intentionally not carried into this lesson. The parts adapted here (leverage vs. control, "three makes a pattern," out-of-distribution, the decision checklist for when to move up vs. down) are the parts that map cleanly onto real, verifiable mechanics in this repo's ADW implementation.