# Human in the Loop (Eric Zakariasson) > [!question] Lingering Questions > - What fraction of real coding tasks actually admit a definition of done an agent can score without a human at all? > - How do you keep a thin notify channel from becoming a noisy interrupt stream as fleet size grows? > [!tip] Article Ideas > - A worked "five done-definitions" cheat sheet (eval score, QA/Playwright pass, green test suite, perf number, validation count to zero) as a practical companion to the more theoretical loop-engineering threads in this cluster. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/The Maker Should Not Grade Its Own Homework]] — the whole method rests on the same independent-check rule, operationalized as five concrete done-definitions. > - [[3. Resources/MOCs/AI Agent Safety MOC]] > [!quote] Vocabulary > - *Definition of done the agent can score* — an objective check (eval score, test suite, perf number, validation count) the agent can run without a human, locked before a long task starts. > - *Stop condition* — the explicit rule that ends a loop: metric hits target, no improvement after N tries, out of ideas, or blocked/unsure. ## Bib capsule Eric Zakariasson, "Human in the /loop," X/Twitter thread, 2026. [[3. Resources/Readwise/Full Document Contents/Tweets/Human in the loop]] ## Author's thesis Agent coding scales into a low-attention-cost parallel practice only when each task carries a definition of done the agent can score itself, wrapped in a loop with explicit stop conditions, plus a thin notification path so the human leans in exactly when a decision is needed — the check is the spec. ## Key arguments 1. Five task types (model work, web/UI, backend/refactor, speed/flakiness, data cleanup) each map to a concrete, self-scorable definition of done. 2. Writing the loop is mostly writing how you'd check the work yourself; start explicit, loosen once you see what the model can infer. 3. Concurrency is throttled by the human's review capacity, not by compute — when several runs wait on a decision, stop starting new ones and go review. ## Claim atoms ### Lock a definition of done the agent can score > [!quote] ID:rw_1 > "Before kicking off a longer running task, I lock a definition of done." The load-bearing move — without a self-scorable check there's no autonomous loop, only supervised prompting. ### Writing the loop is writing your own check > [!quote] ID:rw_2 > "Writing the loop is mostly writing how you'd check the work yourself." Reframes prompt-craft as check-craft; the check is the spec, not an afterthought. ### Throttle concurrency to your review capacity > [!quote] ID:rw_4 > "If three are waiting on me I stop starting stuff and go review." Human review bandwidth, not the machine, caps how many loops run in parallel — a distinct operational claim from the "define done" cluster. ### The reply is the loop's next input > [!quote] ID:rw_5 > "When I answer, that reply is the next thing the loop runs on." Closes the human-in-the-loop cycle: the agent pings on a decision, the human's answer becomes the next iteration's input. ## Permanent candidates - "Lock a definition of done" duplicates the existing maker/checker claim in spirit — connected, not re-promoted. - "Throttle concurrency to your review capacity" is a genuinely new operational claim — promoted. ## Processing checklist - [ ] Recover the prompt-template image (failed to import) to capture the exact `/loop` + `/notify` shape - [ ] Map each of the five done-definitions onto a concrete vault loop-registry row - [x] Connect into the relevant MOC — [[3. Resources/MOCs/AI Agent Safety MOC]] ## Links - [[3. Resources/Permanent Notes/The Maker Should Not Grade Its Own Homework]] — the five done-definitions are this rule made concrete and operational. - [[3. Resources/MOCs/AI Agent Safety MOC]] — stop conditions and review-capacity throttling are agent-safety and operations infrastructure.