--- type: reference subtype: pattern/framework summary: Taxonomy of AI Developer Workflow (ADW) structures — from a single agent loop up through kanban-driven software factories — sourced from IndyDevDan's "Forget Loop Engineering" video, with mermaid diagrams and a marked line between his claims and my own os-sdlc extrapolations. tags: - type/reference - domain/agentic-engineering - tool/claude-code - convention/agentic-sdlc scope: global date: 2026-07-14 --- # Agentic SDLC / AI Developer Workflow (ADW) taxonomy Source: IndyDevDan, ["Forget Loop Engineering"](https://youtu.be/VQy50fuxI34), 2026. All diagrams and claims tagged `[dan]` are his, reconstructed from the video transcript (`indydevdan-agentic-engineering-overview-video.txt` in cc-os repo root) and 8 paused frames. Anything tagged `[jrs]` is my own synthesis/extrapolation for `os-sdlc` — do not attribute it to Dan. Timestamps are exact where the video scrubber was visible in the frame, and marked `≈` where inferred from chapter placement + on-screen content. ## Core thesis `[dan]` "Loop engineering" is a bad rebrand of the software development life cycle. The real unit of work is not "the loop" — it's an **AI Developer Workflow (ADW)**: a composition of three actors of value creation, combined deliberately per stage: | Actor | Cost | Reliability | Role | |---|---|---|---| | **Code** | Free (no tokens), deterministic, fastest | Highest | Linting, formatting, type-checking, tests, CI/CD, ticket-state transitions — anything that doesn't need judgment | | **Engineer** | Human time, most expensive per-hour | High (but slow, doesn't scale) | Prompting/planning (start) and reviewing/validating (end) — the two fixed constraints of agentic engineering | | **Agent** | Token cost, variable reliability | Lowest of the three, improves with scale-out | Judgment-requiring work: planning, building, scouting, testing-with-interpretation | "Loops" (fail → retry) are just one control-flow primitive inside an ADW — condition branches, retries, and routing all show up too. Naming each one "X engineering" doesn't scale; the workflow is the unit, not the primitive. ## The escalation ladder `[dan]` Dan builds up ADW complexity in one continuous demonstration. Each rung adds either an actor or a scaling axis. This is the single most useful map for "what does the next level of sophistication look like" — treat it as a menu, not a mandate to reach the top. 1. **Prompt-and-review** (4:44) — engineer prompts an agent, engineer reviews the result. No code, no loop. The floor every ADW is built on. 2. **First loop** (4:58–5:50) — add one piece of deterministic code (a linter) with a pass/fail condition that routes failures back to the build agent. This condition + routing is literally what "loop engineering" is pointing at — Dan's argument is that it's too narrow a name for the whole pattern. 3. **Multiple validation gates** (6:03–6:55) — stack lint → format → type-check, each with its own pass/fail routing back to the build agent. Still one agent, more code. 4. **Add testing** (6:55–7:12) — the build↔test loop runs until everything passes, then engineer review, then ship. This is the smallest complete ADW: `prompt → build ⇄ test → review → ship`. 5. **Scale compute, not scope** (7:40–8:08) — collapse all validation (lint/format/type-check/ test) into a single **test agent** with its own internal toolset, rather than the engineer hand-wiring each check. "Add compute to add confidence," not more engineering effort. 6. **Add planning** (8:26–9:07) — a planner agent precedes build. The ADW now mirrors the classic manual SDLC (plan → build → test → review → ship) with agents inserted at each step Dan and the engineer used to do by hand. 7. **Worktree parallelism** (9:12–10:07, `[dan]`, diagram below) — a deterministic "build worktree code" step fans out N parallel `planner → build ⇄ test → review` pipelines, each in its own git worktree (isolation, no stepping on each other), converging on a single merge → ship. Explicitly framed as "a great place to start, not a great place to end." 8. **Agent sandboxes** (10:34–11:06, `[dan]`, diagram below) — same fan-out shape as worktrees, but each pipeline gets a full sandboxed machine instead of a worktree. Buys full isolation (you can jump in and inspect the running app/web page/tests directly), at real setup cost. 9. **Kanban-driven intake** (11:56–15:21, `[dan]`, diagram below) — a ticket system (support/ product/engineer intake) becomes the trigger for the pipeline instead of a raw engineer prompt. Adds a scout agent (searches code/tickets/docs/prior specs) ahead of the planner. Advanced teams skip the "engineer translates ticket to prompt" step once ticket quality is good enough. 10. **Production incident ADW** (15:27–17:46, `[dan]`) — a specialized branch: support files a ticket → engineer triggers a scout → **hotfix agent** (a narrow, "get it out ASAP, not the fancy way" specialist) → human approve/reject gate (a hotfix needs sign-off before it burns compute) → N parallel sandboxes race the same fix → first pass wins → engineer validates → ship. The interesting structural idea: a *specialized* agent + an *extra* human gate inserted specifically because the blast radius is higher. 11. **Software factory** (17:48–26:39, `[dan]`, diagram below) — the kanban ticket now routes through a **factory router agent** that (a) sets up a sandbox and (b) picks which specialized sandboxed ADW to run — chore / bug / feature / hotfix / a custom ADW you add — each sized to the job (a chore gets a workhorse/lightweight model and skips human review once the system is trusted; a feature gets full planner → build → test → review). This is the "meta-layer" Dan argues is where senior engineering effort should go: building the system that runs the ADWs, not touching the app layer directly. ## Diagrams ### 1. Worktree-parallel pipeline — 9:12 `[dan]` The pattern Jared is targeting as the near-term "scaled" flow for os-sdlc: N parallel worktrees, each running a full mini-ADW, converging on one merge/ship gate. ```mermaid flowchart LR EP["👤 Engineer Prompt"] --> BWC{{"🔧 Build Worktree Code"}} subgraph WT1["🌿 Worktree 1"] direction LR P1["🤖 Planner Agent"] --> B1["🤖 Build Agent"] B1 -->|fail| P1 B1 --> T1["🤖 Test Agent"] T1 -->|fail| B1 T1 -->|pass| R1["👤 Engineer Review"] R1 -->|fail| P1 end subgraph WT2["🌿 Worktree 2"] direction LR P2["🤖 Planner Agent"] --> B2["🤖 Build Agent"] B2 -->|fail| P2 B2 --> T2["🤖 Test Agent"] T2 -->|fail| B2 T2 -->|pass| R2["👤 Engineer Review"] R2 -->|fail| P2 end subgraph WT3["🌿 Worktree 3"] direction LR P3["🤖 Planner Agent"] --> B3["🤖 Build Agent"] B3 -->|fail| P3 B3 --> T3["🤖 Test Agent"] T3 -->|fail| B3 T3 -->|pass| R3["👤 Engineer Review"] R3 -->|fail| P3 end BWC --> WT1 BWC --> WT2 BWC --> WT3 R1 -->|pass| M["👤 Merge"] R2 -->|pass| M R3 -->|pass| M M --> SH["👤 Ship"] ``` Source frame: `assets/agentic-sdlc-adw/01-worktree-pipeline-0912.png` ### 2. Individual cycle (zoomed in) — ≈7:00–7:12 `[dan]` The single-worktree unit that's tiled N times above. Note the two distinct fail edges: a **test failure loops back to build** ("loop back"), while an **engineer-review failure loops back to build** too, but is a distinct, human-gated edge — Dan draws them as separate arrows because a review rejection can carry different feedback than a test failure. ```mermaid flowchart LR EP["👤 Engineer Prompt"] --> B["🤖 Build Agent"] B --> T["🤖 Test Agent"] T -->|"fail: loop back"| B T -->|pass| R["👤 Engineer Review"] R -->|fail| B R -->|pass| SH["👤 Ship"] ``` Source frame: `assets/agentic-sdlc-adw/02-individual-cycle-approx-0700.png` ### 3. Individual cycle with lint + format — ≈6:03–6:25 `[dan]` Same shape, with deterministic code gates (lint, format) ahead of test/review instead of a test agent — this is the "adding code to your ADW" stage, and the shape `os-sdlc`'s Build Agent stage should actually implement (see "My extrapolation" below). ```mermaid flowchart LR EP["👤 Engineer Prompt"] --> B["🤖 Build Agent"] B --> L{{"⚙️ Lint Code"}} L -->|fail| B L -->|pass| F{{"⚙️ Format Code"}} F -->|fail| B F -->|pass| R["👤 Engineer Review"] ``` Source frame: `assets/agentic-sdlc-adw/03-lint-format-cycle-approx-0603.png` ### 4. Agent sandboxes (parallel, full isolation) — ≈10:34–11:06 `[dan]` Structurally identical to the worktree diagram — the only change is the isolation unit (sandbox/VM instead of git worktree). Reuse diagram 1's shape; the distinguishing feature is each unit is now `🖥️ Agent Sandbox N` instead of `🌿 Worktree N`, and the fan-out node is "Build Agent Sandbox Code" instead of "Build Worktree Code." Source frame: `assets/agentic-sdlc-adw/04-agent-sandboxes-approx-1040.png` ### 5. Kanban-queue-driven ADW — 12:08 `[dan]` Ticket intake replaces the raw engineer prompt as the trigger. A scout agent now precedes planning (searches code/tickets/docs/prior specs); ticket status transitions (Planning → Building → Testing) are themselves deterministic code, not agent judgment. ```mermaid flowchart LR SUP["👤 Support"] --> KT{{"🎫 Kanban Ticket"}} PROD["👤 Product"] --> KT ENG["👤 Engineer"] --> KT KT -->|advanced teams| SBX KT --> EPr["👤 Engineer Prompt"] --> SBX subgraph SBX["🖥️ Sandbox"] direction LR SP{{"Status: Planning"}} --> SC["🤖 Scout Agent"] --> PL["🤖 Plan Agent"] PL --> SB2{{"Status: Building"}} --> BD["🤖 Build Agent"] BD --> ST{{"Status: Testing"}} ST --> TS["🤖 Test Agent"] TS -->|fail| BD TS -->|pass| CI{{"⚙️ CI/CD"}} CI -->|fail| BD end ``` Source frame: `assets/agentic-sdlc-adw/05-kanban-queue-1208.png` ### 6. Software factory — 17:59 `[dan]` The kanban ticket now triggers a **Factory Router Agent** that sets up a sandbox and picks which specialized sandboxed ADW to run: feature, bug, chore, or hotfix — plus a note that any custom ADW you build slots into the same router. ```mermaid flowchart LR SUP["👤 Support"] --> KT{{"🎫 Kanban Ticket"}} PROD["👤 Product"] --> KT ENG["👤 Engineer"] --> KT KT --> SF{{"⚙️ Start Factory"}} --> IP{{"Status: In Progress"}} --> FR["🤖 Factory Router Agent"] FR --> SS{{"🔧 Setup Sandbox"}} SS -->|hotfix| HFS SS -->|feature| FES SS -->|bug| BGS SS -->|chore| CHS SS -->|"any specialized ADW you need"| YOUR["🤖 Your ADW"] subgraph HFS["🖥️ Hotfix Sandbox"] direction LR HSC["🤖 Scout Agent"] --> HFA["🤖 Hot Fix Agent"] --> APR{{"👤 Approve/Reject"}} APR -->|reject| HFA APR -->|approve| HB["🤖 Build Agent"] --> HT["🤖 Test Agent"] HT -->|fail| HB HT -->|pass| HR["👤 Engineer Review"] HR -->|fail| HB end subgraph FES["🖥️ Feature Sandbox"] direction LR FPL["🤖 Planner Agent"] --> FB["🤖 Build Agent"] --> FT["🤖 Test Agent"] FT -->|fail| FB FT -->|pass| FCI{{"⚙️ CI/CD"}} FCI -->|fail| FB FCI -->|pass| FR2["👤 Engineer Review"] FR2 -->|fail| FB end subgraph BGS["🖥️ Bug Sandbox"] direction LR BPL["🤖 Plan Agent"] --> BB["🤖 Build Agent"] --> BT["🤖 Test Agent"] BT -->|fail| BB BT -->|pass| BCI{{"⚙️ CI/CD"}} BCI -->|fail| BB BCI -->|pass| BR["👤 Engineer Review"] BR -->|fail| BB end subgraph CHS["🖥️ Chore Sandbox"] direction LR CB["🤖 Build Agent"] --> CL{{"⚙️ Lint"}} CL -->|fail| CB CL -->|pass| CCI{{"⚙️ CI/CD"}} CCI -->|fail| CB CCI -->|pass| CR["👤 Engineer Review"] CR -->|fail| CB end HR -->|pass| MG["👤 Merge"] FR2 -->|pass| MG BR -->|pass| MG CR -->|pass| MG MG --> SH["👤 Ship"] ``` Source frame: `assets/agentic-sdlc-adw/06-software-factory-1759.png` ## Dan's build-loop principle, and my extrapolation for os-sdlc **`[dan]` (27:13–27:36, "How to Build Great AI Developer Workflows")**: separate code from agents structurally, not just conceptually. Don't write a skill where the agent both builds *and* runs the linter internally — that's still "an agent calling code," not separation of concerns. Instead: run a build agent via the SDK/harness, do work, exit; run the linter as a **separate deterministic step**; on failure, feed the failure back into the *same session* of the build agent. His three tips, in order: (1) keep it simple, add nodes only as you hit real problems; (2) design the ADW by walking it yourself end-to-end first (he recommends mermaid — the exact tool used for the diagrams above); (3) use agents *and* code, don't let everything live inside a skill once you're past the prototype stage — code is free, instant, and deterministic; agents are neither. **`[jrs]` — my design decision for os-sdlc's Build Agent, going beyond what Dan says**: take his separation-of-concerns principle further than "run lint as a separate step" and apply it to the *build agent's own permissions*. The Build Agent should get the minimum tool surface needed to write code — plausibly just `Read` + `Write` (maybe `Edit`) — and should **not** have `Bash` access to run tests, linters, or formatters at all. Enforcement mechanism: `os-sdlc` hooks trigger lint/format/test after the build agent's turn ends (delta-refinery style Pre/Post/Handoff), and failures get piped back into the build agent's next turn with the failing output as context. This is a deliberately stronger claim than Dan's video makes — he argues for separating *invocation*, not for stripping the build agent's tool grants. Revisit if this turns out to over-constrain (e.g. a build agent that legitimately needs to run a quick sanity script mid-task) — not locked, no ADR yet, since the plugin has no code to reverse. ## Structures/approaches this is NOT the near-term focus for `[dan]` Documented for completeness per the taxonomy, explicitly out of scope for the first os-sdlc iteration (see `plugins/os-sdlc/OVERVIEW.md` in cc-os for the actual build plan): - **Production-incident ADW** (racing sandboxes + human approve/reject gate) — a big-team, high-blast-radius pattern; revisit once os-sdlc has a real production surface to protect. - **Full software factory + factory router agent** — the "operate the org's entire ADW portfolio" endgame. `[dan]`'s own framing: start simple, this is where you end up after scaling, not where you start. - **Agent sandboxes as the default isolation unit** — plausible but heavier to stand up than worktrees; `[jrs]`: worth reconsidering once/if worktree isolation proves insufficient (e.g. an ADW needs a running browser/server the build agent must interact with, not just a clean filesystem). See `[jrs]` note below on the worktree-vs-sandbox call. ## `[jrs]` — worktree vs. sandbox, held loosely Jared's read (2026-07-14), not Dan's: full agent sandboxes are probably overkill for most os-sdlc work right now — a plugin skill or small script doesn't need a worktree, let alone a sandboxed VM. Likely shape: **tiered isolation**, chosen per task — 1. No isolation — trivial single-file edits, tiny plugin scripts. 2. Single worktree — anything touching multiple files/tests in one repo, no parallelism needed. 3. N parallel worktrees — the diagram-1 shape, once a task is decomposable into independent slices worth racing or reviewing separately. 4. Full sandbox — reserved for cases needing a live running app/server the agent must poke at, not just source control isolation. If more than one tier is actually used in practice, a **router** (probably a cheap deterministic check, not an agent call, per Dan's "code is free" argument) will be needed to pick the tier per task — but per both Dan's and Jared's "start simple" instinct, defer building the router until tier 3 is proven useful and tier 4 has a concrete forcing use case. At a minimum, os-sdlc needs to scale using worktrees — whether that's 1 or 20 — before anything else on this list. ## Are "issues" and "tickets" the same thing? Related but deliberately two layers in cc-os's existing model, not synonymous: - A **Planka card** (`os-backlog`) is lightweight kanban/queue state — the thing that moves through columns (Backlog → Doing → Review/Done), analogous to Dan's "Kanban Ticket" node. - A **git issue** (Forgejo, created via `/to-tickets`) is the durable spec — the actual breakdown of work, meant to survive and be referenced. - `os-backlog`'s own PROMOTION rule already encodes this: when a Planka card accretes real spec content, that content moves to a git issue and the card becomes a pointer (title + link), never a duplicate of the spec text. So: Dan's "Kanban Ticket" node in the diagrams above maps to the *combination* of a Planka card (queue position, trigger) and, once work is non-trivial, a linked git issue (the actual spec the Scout/Plan agent reads). ## Related - `[[agentic-sdlc-os-sdlc-build-components]]` — not yet written; the repo-specific build plan lives in `plugins/os-sdlc/OVERVIEW.md` in cc-os instead of the vault (repo-specific, not cross-project knowledge). Link added here as a pointer once that note/section exists.