What makes a feedback loop with an AI coding agent actually effective — surfacing real problems fast and turning fixes into durable, reusable knowledge — rather than just patching symptoms one at a time?

Status: active

Config: journals/quests/config/effective-ai-feedback-loops.yaml

The Answer So Far #

Last updated: 2026-09-03

Cycle 5 introduces a crucial empirical refinement to hypothesis (b) and a mature engineering vocabulary for hypothesis (c), alongside a proliferation of new tools and patterns that formalize the capture of durable knowledge. An empirical study of 2,303 context files (arXiv 2511.12884, cited in “CLAUDE.md Best Practices: What the Evidence Supports”) finds that the mere presence of a CLAUDE.md file has a massive impact on rule adherence (improving it from 0% to ~68%), while its internal structure — length, rule position, organization — has no statistically significant effect. This partially contradicts the community-observed wisdom from cycle 2 about strict ~80/200-line thresholds, suggesting the benefit comes from having the file at all, and that the motive for brevity should be managing cost and noise rather than ensuring compliance.

Working hypothesis, anchored on this project’s own bug escalation ritual (dev/docs/rituals/BUG_RITUAL.md): effective AI feedback loops require (a) root-cause diagnosis before fixing, (b) promoting recurring point-fixes to durable directives/rules, and (c) an explicit escalation path when a fix reveals a gap in the surrounding process itself. Concretely, BUG_RITUAL implements this as: a Step-0 self-check against skipping the ritual; a relief valve for genuinely trivial fixes that still requires visible, explicit user approval to skip; fix-cluster detection when 3+ small fixes accumulate in one area; a “diagnose first” sequence that escalates through L1 (root cause) → L2 (is there a directive/ritual gap) → L3 (does the L2 fix reveal a meta-infrastructure gap); a rule to fix at the highest level the diagnosis reaches rather than patching just the instance; a mandatory test-first protocol; and guard comments at the fix site explaining the non-obvious constraint.

Hypothesis (a) (diagnose-first) is strongly corroborated and stable, gaining a more formal vocabulary for failure modes. The core idea is independently implemented by Boris Cherny, Simon Willison/Jesse Vincent, and Kiro (cycle 1). A formal taxonomy of agentic failures (MASFT, cited in “Failure Modes: Why Agents Break”) provides a more structured language for diagnosis, identifying recurring patterns like “cascading errors” (where one hallucinated step poisons the input for subsequent steps) that a root-cause analysis should specifically look for.

Hypothesis (b) (promote-to-durable-knowledge) is massively reinforced, with a clear shift from flat-file rules to structured, agent-maintained memory systems. The principle is now validated by at least nine independent sources or implementations. The closed-loop framework from arXiv 2607.13091 (cycle 3) provided the first quantified evidence that turning accepted code-review comments into version-controlled rules prevents error recurrence (zero recurrences across 74 exposures) and frees up human review for higher-value architectural issues. This is now complemented by a wave of new tools and practices. Snowflake’s “Experience Cards” describe a production system for capturing knowledge from approved PRs into team-owned, structured artifacts (Snowflake). New open-source tools like selvedge move beyond prose rules to persist entity-keyed decisions with attached reasoning and expiry dates (selvedge.io), while claude-mem focuses on semantic compression of session history (DEV Community). This evolution is also mirrored in user-practitioner rituals: the “Wrap Ritual” (Reddit) and the “AI Retrospective” (Scott S Nelson) both describe an explicit end-of-session habit where the agent itself helps summarize learnings and log mistakes into its own memory, directly implementing the feedback loop. This body of evidence validates the cycle-2 refinement (promote fixes to the correct enforcement layer) and elevates it to a new best practice: durable knowledge should be structured, queryable, and ideally, maintained with the agent’s help.

Hypothesis (c) (escalation and verification) is substantially deepened, with a consensus emerging that reliability is a control-flow and systems problem, not a prompting one. The idea that self-correction requires external validation is now a strong theme. Asking an agent to simply check its own work is ineffective due to self-preference bias; reliable correction requires an external verifier with new evidence, such as a test suite or a specialized tool (“Self-Correcting AI Loops,” Medium). This provides a strong mechanistic justification for BUG_RITUAL’s test-first protocol. The developer’s role in the loop is being formalized in new, structured review models like the SCOPE framework (Agent Review → Developer Review → Peer Review), which provides a clear vocabulary for the different layers of human and machine oversight (Dr. Michaela Greiler). Furthermore, industry practice is reframing agent reliability as a systems and control-flow challenge. This involves building resilient workflows with explicit states for bounded retries, durable checkpoints, and human-in-the-loop approvals, treating these as first-class engineering primitives rather than prompt instructions (Kunal Ganglani). This provides a mature vocabulary for the “meta-infrastructure gap” BUG_RITUAL’s L3 diagnosis is designed to find. Finally, the environment in which the loop operates is shifting, with fast CI/CD pipelines now seen as a critical part of the live development environment for agents, not just a post-commit gate (“Fast Coding Agents Need Faster CI”).

The open question from cycle 3/4 — what does diagnosis and escalation look like at scale, beyond the “Parallel” stage where a human reviews each fix? — remains open but has more texture. Boris Cherny’s report of directing “tens of thousands” of agents via self-review and spot-checking (cycle 4) is now complemented by complex, multi-agent review workflows where specialized “adjudicator” agents decide which bug reports from “reviewer” agents are valid before escalating them for a fix (Reddit). This suggests that at scale, the human-centric escalation path of BUG_RITUAL may be replaced by more complex, automated AI-to-AI protocols, though these are not yet mainstream, documented best practices.

Net assessment across cycles 1–5: The working hypothesis remains strongly validated and has been significantly refined. Hypothesis (a) is stable. Hypothesis (b) has evolved from “write rules in a file” to “build structured, queryable, agent-maintained memory systems,” with new empirical evidence refining our understanding of how those files are interpreted by models. Hypothesis (c) has matured from a general principle of escalation to a specific set of engineering practices centered on external verification and robust control flow, with formal models for the human-AI review process now emerging.

Synthesis History #

Cycle 3 adds the first quantified, independently-measured validation of hypothesis (b), with a mechanism that formalizes exactly the “accepted-fix becomes durable rule” step BUG_RITUAL implements informally. A closed-loop framework (arXiv 2607.13091) converts accepted code-review comments into persistent, version-controlled behavioral rules — deliberately gated on human acceptance, since “an incorrect rule would amplify rather than correct errors,” mirroring BUG_RITUAL’s requirement that the user, not the agent, approves any ritual skip or scope decision. Each rule carries metadata (ID, category, trigger origin, scope, constraint, rationale, originating review comment) and agents run a self-review checklist derived from the accumulated rule set before submitting code. Reported results over a four-week single-team deployment: rules grew from 5 to 18 (plus 15+ code standards and a 15-item checklist); across 9 tracked error classes with 74 cumulative post-rule exposures, zero recurrences; the mix of review-comment content shifted from 14% mechanical-correctness issues toward 66% architecture/API/performance issues (i.e., once mechanical errors stopped recurring, review effort reallocated to higher-value judgment); and 60% of captured rules (9/15) transferred knowledge across repository or tool boundaries, not just within one codebase. Assessment: this crosses the significance threshold — it is the first measured evidence (not just convergent practitioner description) that promoting accepted fixes to durable, structured rules actually prevents recurrence, and the reported review-effort reallocation (toward exactly the L2/L3-type findings BUG_RITUAL’s diagnose-first escalation is designed to surface) is independent support for the hypothesis’s core bet: that durable-knowledge capture pays off by freeing review capacity for structural rather than mechanical problems. Authors caveat this as observational, single-deployment evidence, not a controlled experiment — a caveat this quest should track being addressed (or not) in follow-up work.

Working hypothesis, anchored on this project’s own bug escalation ritual (dev/docs/rituals/BUG_RITUAL.md): effective AI feedback loops require (a) root-cause diagnosis before fixing, (b) promoting recurring point-fixes to durable directives/rules, and (c) an explicit escalation path when a fix reveals a gap in the surrounding process itself. Concretely, BUG_RITUAL implements this as: a Step-0 self-check against skipping the ritual; a relief valve for genuinely trivial fixes that still requires visible, explicit user approval to skip; fix-cluster detection when 3+ small fixes accumulate in one area; a “diagnose first” sequence that escalates through L1 (root cause) → L2 (is there a directive/ritual gap) → L3 (does the L2 fix reveal a meta-infrastructure gap); a rule to fix at the highest level the diagnosis reaches rather than patching just the instance; a mandatory test-first protocol; and guard comments at the fix site explaining the non-obvious constraint.

Cycle 1 established broad, independent convergence on (a) and (b). Boris Cherny’s “add it to CLAUDE.md” practice, Simon Willison/Jesse Vincent’s “Root Cause Tracing” skill, and Kiro’s falsifiable-root-cause-hypothesis-plus-preservation-property mechanism all independently reconstruct this project’s own diagnose-first, promote-to-directive design — strong corroboration that the hypothesis names a real, convergently-discovered pattern rather than an idiosyncratic local convention. Kiro’s “sledgehammer problem” (AI agents ~2x more likely than humans to add unneeded defensive scope when fixing a bug) remains a concrete gap BUG_RITUAL’s test-first protocol doesn’t yet close — it verifies the fix works but not that unrelated behavior was preserved.

Cycle 2 adds two further independent confirmations of hypothesis (b), and — more importantly — the first real refinement of it. Simon Willison’s in-progress “Agentic Engineering Patterns” guide (simonwillison.net, published from Feb 2026) includes a chapter, “Hoard things you know how to do,” that generalizes durable-knowledge-capture beyond reactive bug-fixing: proactively accumulate solved-problem assets (blog posts, TIL entries, reusable tools) before a bug forces the issue, so an agent has more to draw on than what any single ritual has captured. Addy Osmani’s “Self-Improving Coding Agents” independently converges on the same shape via AGENTS.md as long-term semantic memory, explicitly describing the loop as “every fix or pattern rolled into the context for next time” — a third, differently-branded (but mechanically identical) implementation of hypothesis (b), reinforcing that this is now a broadly-adopted industry pattern rather than a niche practice.

However, a dev.to deep-dive (“I Wrote 500 Lines of Rules for Claude Code…”) surfaces a real limit the working hypothesis had not accounted for: naive, unbounded accumulation of directives into one CLAUDE.md degrades rather than improves reliability. Community-observed thresholds cited: past ~80 lines, rules start being dropped; past ~200 lines, large blocks get ignored entirely; each additional rule makes every other rule slightly less likely to be followed. This is a genuine partial contradiction of the naive reading of hypothesis (b) — “keep appending promoted fixes to CLAUDE.md forever” is not a free action, it has a real ceiling. The proposed fix is not to stop capturing durable knowledge but to route it through the right level of an enforcement hierarchy instead of flattening everything into prose rules: hooks for deterministic, unskippable constraints; skills for on-demand procedural knowledge (loaded only when relevant, not always-on); path-scoped rules for precision; CLAUDE.md reserved for compact, always-needed context. Notably, this project’s own CLAUDE.md already has a dedicated DIRECTIVE_PLACEMENT_RITUAL.md, triggered specifically on “adding a directive to CLAUDE.md” — meaning the project had already anticipated exactly this failure mode with a placement gate, rather than defaulting to flat accumulation. This new evidence validates that anticipation rather than exposing an unaddressed gap, but it sharpens hypothesis (b) from “promote fixes to durable directives” to “promote fixes to durable knowledge, routed to the correct enforcement layer, with active pruning against directive bloat.”

Hypothesis (c) gains contextual (not yet structural) extension via a live industry shift. Boris Cherny’s June 2026 “loop engineering” framing (“I don’t prompt Claude anymore… my job is to write loops”) and Claude Code’s new /goal command — where a second, smaller model judges whether a stated goal condition has been met and keeps iterating autonomously until it has — push more automated self-verification down into the fast, agentic-coding loop itself (Andrew Ng’s innermost loop). This doesn’t change BUG_RITUAL’s escalation design, which still operates one loop up (the developer feedback loop, per Ng’s vocabulary), but it’s a signal worth tracking: as more routine verification gets automated inside the fast loop, the residual cases that actually need BUG_RITUAL-style human escalation may narrow toward genuinely structural, process-level gaps — arguably strengthening the case for reserving escalation for L2/L3-type findings rather than routine fixes, which is already BUG_RITUAL’s design intent.

Cycle 3 delivers the first genuinely new structural question for hypothesis (c), plus primary-source confirmation — from the reference tool’s own creators — of hypothesis (b)’s cycle-2 refinement. Boris Cherny’s July 16, 2026 “Steps of AI Adoption” framework names five maturity stages for teams working with coding agents: Gated (0) → Assisted (~1 agent/dev, high supervision) → Parallel (~10 agents/dev, AI codes / humans verify) → Supervised autonomy (~100 agents/dev, AI verifies / humans supervise outcomes) → AI-native (1,000+ agents, humans steer by intent). This makes explicit something the working hypothesis hadn’t reckoned with: BUG_RITUAL’s design — a human diagnosing and approving each escalation — is characteristic of the “Parallel” stage, where a human still reviews each agent’s output directly. Cherny’s own framework implies that at “Supervised autonomy” and beyond, verification itself gets delegated to AI, with humans stepping back to overseeing outcomes rather than individual fixes. This doesn’t contradict BUG_RITUAL at this project’s current scale, but it names a real, unresolved gap: what does root-cause-diagnose-then-escalate look like once there’s no human left to review each individual diagnosis? No source in this quest yet answers that.

Separately, Simon Willison’s July 21, 2026 fireside chat with Claude Code’s own Cat Wu and Thariq Shihipar supplies primary-source confirmation of the enforcement-hierarchy refinement to hypothesis (b) first surfaced by cycle 2’s dev.to piece. Claude Code’s own system prompt was recently cut by roughly 70–80%, specifically by removing “examples and lists of things not to do” — the same always-loaded, negative-example-heavy style BUG_RITUAL’s guard comments and this project’s CLAUDE.md directives use. Willison: “it’s time to stop overloading our prompts with examples and lists of things not to do.” Additionally, Claude Tag’s memory is implemented as one markdown file per Slack channel (scoped, not global), with individual session contributions merged back into shared channel memory — a concrete, shipped example of “route knowledge to the right scope, don’t flatten everything into one always-loaded file,” now confirmed as the reference implementation’s own practice rather than just community-observed advice. This elevates hypothesis (b)’s cycle-2 refinement from “one dev.to author’s observation” to “corroborated by the tool creators’ own shipped behavior.”

Two further cycle-3 items reinforce existing threads for hypothesis (c) without shifting them. Cloudflare’s production case study (a 7-agent automated review system across 48,095 merge requests over 30 days; a human “break glass” override used only 0.6% of the time) gives Ankit Jain’s proactive risk-routing idea (cycle 1, hypothesis (c) complement) a concrete, at-scale implementation — automated review is the default, human escalation the rare exception, which is the inverse of where BUG_RITUAL currently places the human (reviewing every escalation, not overriding a rare one). A UNU Campus Computing Centre write-up on using NotebookLM as a queryable “external brain” for coding agents offers a different technical mechanism for the same cycle-2 enforcement-hierarchy idea: retrieval-on-demand instead of an always-loaded file, functionally similar to a skill loaded only when relevant.

Other cycle-1 findings stand unchanged: Ankit Jain’s proactive risk-classification escalation (hypothesis (c) complement, not competitor); the “ritual approval” pejorative-naming caution from industry AI-code-review coverage; Andrew Ng’s three-loop vocabulary as useful framing.

Cycle 4 supplies the first concrete (if partial) glimpse of what happens to hypothesis (c)’s open “who reviews the diagnosis at scale” question beyond the “Parallel” stage. A June 8, 2026 Fortune interview with Boris Cherny — describing days where he is directing “tens of thousands” of AI agents at once — reports that “Claude Code is fully writing itself” and “is also doing its own security review,” and that Cherny “wakes up in the morning, and Claude has already taken action” overnight. This is a real, if thin, data point for the “Supervised autonomy”/“AI-native” end of Cherny’s own maturity-stage framework (cycle 3): verification is delegated to the agent itself (self-review), and the human’s role compresses from reviewing each diagnosis to a periodic, after-the-fact check-in — structurally different from BUG_RITUAL’s design, where every escalation gets an explicit approval gate before proceeding. The source doesn’t describe the actual verification mechanism (what “doing its own security review” consists of, or what happens when that self-review is wrong), so the open question from cycle 3 is not resolved, only given its first empirical texture: at extreme scale, the practiced answer so far appears to be trust-then-spot-check rather than any richer AI-to-AI escalation protocol — a gap BUG_RITUAL still fills at this project’s current (human-scale) stage, but a specific point of contrast worth continuing to track.

A second cycle-4 item reinforces and mechanistically deepens hypothesis (b)’s cycle-2/3 enforcement-hierarchy refinement. A March 2026 piece (“Why Does CLAUDE.md Lose to Claude Code System Prompt Directives?”, docs.bswen.com) argues the reason generic CLAUDE.md rules get under-followed isn’t just volume (the dev.to piece’s ~80/~200-line thresholds) but position: the system prompt sits at the very start of every context window and carries structural weight CLAUDE.md cannot match by token count alone. Its proposed countermeasure is not relocation but reinforcement — pair each directive with an explicit rationale (why the rule exists, concrete consequences of non-compliance, how compliance is verified) so it competes on information content rather than position. This gives a plausible mechanistic explanation for why BUG_RITUAL’s own design already requires guard comments “explaining the non-obvious constraint” at the fix site, rather than a bare prohibition — the ritual’s existing practice is independently justified by this new source’s reasoning, not just its prior design intuition.

Net assessment across cycles 1–4: no full contradiction of the working hypothesis; hypothesis (a) remains strongly corroborated (four independent implementations, unchanged this cycle); hypothesis (b) is now corroborated by five independent sources plus two primary/mechanistic confirmations — the Claude Code team’s own system-prompt and Claude Tag memory practices (cycle 3), and a new mechanistic account of why generic always-loaded rules lose to positionally-privileged system prompts, which independently validates BUG_RITUAL’s existing guard-comment-with-rationale practice (cycle 4); hypothesis (c)’s open structural question from cycle 3 (what does escalation look like once verification is delegated to AI at higher autonomy stages?) gets its first concrete, if incomplete, empirical answer — Cherny’s own tens-of-thousands-of-agents practice appears to be self-review plus periodic human spot-checking rather than any richer AI-to-AI escalation protocol — alongside the unchanged reinforcing data points from cycle 3 (Cloudflare’s break-glass case study, NotebookLM-as-external-brain).

Working hypothesis, anchored on this project’s own bug escalation ritual (dev/docs/rituals/BUG_RITUAL.md): effective AI feedback loops require (a) root-cause diagnosis before fixing, (b) promoting recurring point-fixes to durable directives/rules, and (c) an explicit escalation path when a fix reveals a gap in the surrounding process itself. Concretely, BUG_RITUAL implements this as: a Step-0 self-check against skipping the ritual; a relief valve for genuinely trivial fixes that still requires visible, explicit user approval to skip; fix-cluster detection when 3+ small fixes accumulate in one area; a “diagnose first” sequence that escalates through L1 (root cause) → L2 (is there a directive/ritual gap) → L3 (does the L2 fix reveal a meta-infrastructure gap); a rule to fix at the highest level the diagnosis reaches rather than patching just the instance; a mandatory test-first protocol; and guard comments at the fix site explaining the non-obvious constraint.

Cycle 1 established broad, independent convergence on (a) and (b). Boris Cherny’s “add it to CLAUDE.md” practice, Simon Willison/Jesse Vincent’s “Root Cause Tracing” skill, and Kiro’s falsifiable-root-cause-hypothesis-plus-preservation-property mechanism all independently reconstruct this project’s own diagnose-first, promote-to-directive design — strong corroboration that the hypothesis names a real, convergently-discovered pattern rather than an idiosyncratic local convention. Kiro’s “sledgehammer problem” (AI agents ~2x more likely than humans to add unneeded defensive scope when fixing a bug) remains a concrete gap BUG_RITUAL’s test-first protocol doesn’t yet close — it verifies the fix works but not that unrelated behavior was preserved.

Cycle 2 adds two further independent confirmations of hypothesis (b), and — more importantly — the first real refinement of it. Simon Willison’s in-progress “Agentic Engineering Patterns” guide (simonwillison.net, published from Feb 2026) includes a chapter, “Hoard things you know how to do,” that generalizes durable-knowledge-capture beyond reactive bug-fixing: proactively accumulate solved-problem assets (blog posts, TIL entries, reusable tools) before a bug forces the issue, so an agent has more to draw on than what any single ritual has captured. Addy Osmani’s “Self-Improving Coding Agents” independently converges on the same shape via AGENTS.md as long-term semantic memory, explicitly describing the loop as “every fix or pattern rolled into the context for next time” — a third, differently-branded (but mechanically identical) implementation of hypothesis (b), reinforcing that this is now a broadly-adopted industry pattern rather than a niche practice.

However, a dev.to deep-dive (“I Wrote 500 Lines of Rules for Claude Code…”) surfaces a real limit the working hypothesis had not accounted for: naive, unbounded accumulation of directives into one CLAUDE.md degrades rather than improves reliability. Community-observed thresholds cited: past ~80 lines, rules start being dropped; past ~200 lines, large blocks get ignored entirely; each additional rule makes every other rule slightly less likely to be followed. This is a genuine partial contradiction of the naive reading of hypothesis (b) — “keep appending promoted fixes to CLAUDE.md forever” is not a free action, it has a real ceiling. The proposed fix is not to stop capturing durable knowledge but to route it through the right level of an enforcement hierarchy instead of flattening everything into prose rules: hooks for deterministic, unskippable constraints; skills for on-demand procedural knowledge (loaded only when relevant, not always-on); path-scoped rules for precision; CLAUDE.md reserved for compact, always-needed context. Notably, this project’s own CLAUDE.md already has a dedicated DIRECTIVE_PLACEMENT_RITUAL.md, triggered specifically on “adding a directive to CLAUDE.md” — meaning the project had already anticipated exactly this failure mode with a placement gate, rather than defaulting to flat accumulation. This new evidence validates that anticipation rather than exposing an unaddressed gap, but it sharpens hypothesis (b) from “promote fixes to durable directives” to “promote fixes to durable knowledge, routed to the correct enforcement layer, with active pruning against directive bloat.”

Hypothesis (c) gains contextual (not yet structural) extension via a live industry shift. Boris Cherny’s June 2026 “loop engineering” framing (“I don’t prompt Claude anymore… my job is to write loops”) and Claude Code’s new /goal command — where a second, smaller model judges whether a stated goal condition has been met and keeps iterating autonomously until it has — push more automated self-verification down into the fast, agentic-coding loop itself (Andrew Ng’s innermost loop). This doesn’t change BUG_RITUAL’s escalation design, which still operates one loop up (the developer feedback loop, per Ng’s vocabulary), but it’s a signal worth tracking: as more routine verification gets automated inside the fast loop, the residual cases that actually need BUG_RITUAL-style human escalation may narrow toward genuinely structural, process-level gaps — arguably strengthening the case for reserving escalation for L2/L3-type findings rather than routine fixes, which is already BUG_RITUAL’s design intent.

Cycle 3 delivers the first genuinely new structural question for hypothesis (c), plus primary-source confirmation — from the reference tool’s own creators — of hypothesis (b)’s cycle-2 refinement. Boris Cherny’s July 16, 2026 “Steps of AI Adoption” framework names five maturity stages for teams working with coding agents: Gated (0) → Assisted (~1 agent/dev, high supervision) → Parallel (~10 agents/dev, AI codes / humans verify) → Supervised autonomy (~100 agents/dev, AI verifies / humans supervise outcomes) → AI-native (1,000+ agents, humans steer by intent). This makes explicit something the working hypothesis hadn’t reckoned with: BUG_RITUAL’s design — a human diagnosing and approving each escalation — is characteristic of the “Parallel” stage, where a human still reviews each agent’s output directly. Cherny’s own framework implies that at “Supervised autonomy” and beyond, verification itself gets delegated to AI, with humans stepping back to overseeing outcomes rather than individual fixes. This doesn’t contradict BUG_RITUAL at this project’s current scale, but it names a real, unresolved gap: what does root-cause-diagnose-then-escalate look like once there’s no human left to review each individual diagnosis? No source in this quest yet answers that.

Separately, Simon Willison’s July 21, 2026 fireside chat with Claude Code’s own Cat Wu and Thariq Shihipar supplies primary-source confirmation of the enforcement-hierarchy refinement to hypothesis (b) first surfaced by cycle 2’s dev.to piece. Claude Code’s own system prompt was recently cut by roughly 70–80%, specifically by removing “examples and lists of things not to do” — the same always-loaded, negative-example-heavy style BUG_RITUAL’s guard comments and this project’s CLAUDE.md directives use. Willison: “it’s time to stop overloading our prompts with examples and lists of things not to do.” Additionally, Claude Tag’s memory is implemented as one markdown file per Slack channel (scoped, not global), with individual session contributions merged back into shared channel memory — a concrete, shipped example of “route knowledge to the right scope, don’t flatten everything into one always-loaded file,” now confirmed as the reference implementation’s own practice rather than just community-observed advice. This elevates hypothesis (b)’s cycle-2 refinement from “one dev.to author’s observation” to “corroborated by the tool creators’ own shipped behavior.”

Two further cycle-3 items reinforce existing threads for hypothesis (c) without shifting them. Cloudflare’s production case study (a 7-agent automated review system across 48,095 merge requests over 30 days; a human “break glass” override used only 0.6% of the time) gives Ankit Jain’s proactive risk-routing idea (cycle 1, hypothesis (c) complement) a concrete, at-scale implementation — automated review is the default, human escalation the rare exception, which is the inverse of where BUG_RITUAL currently places the human (reviewing every escalation, not overriding a rare one). A UNU Campus Computing Centre write-up on using NotebookLM as a queryable “external brain” for coding agents offers a different technical mechanism for the same cycle-2 enforcement-hierarchy idea: retrieval-on-demand instead of an always-loaded file, functionally similar to a skill loaded only when relevant.

Other cycle-1 findings stand unchanged: Ankit Jain’s proactive risk-classification escalation (hypothesis (c) complement, not competitor); the “ritual approval” pejorative-naming caution from industry AI-code-review coverage; Andrew Ng’s three-loop vocabulary as useful framing.

Net assessment across cycles 1–3: no full contradiction of the working hypothesis; hypothesis (a) remains strongly corroborated (four independent implementations, unchanged this cycle); hypothesis (b) is now corroborated by five independent sources plus one primary-source confirmation (the Claude Code team’s own system-prompt and Claude Tag memory practices) that its cycle-2 refinement — route durable knowledge to the correct enforcement layer, scope it, and prune it, rather than flatly accumulating always-loaded rules — is the reference implementation’s actual behavior, not just outside commentary; hypothesis (c) gains its first genuinely open structural question — Cherny’s maturity-stage framework implies BUG_RITUAL’s per-fix human-escalation design is scale-bound to something like the “Parallel” stage, and no source yet describes what escalation looks like once verification itself must be delegated to AI at higher autonomy stages — alongside two reinforcing (not novel) data points on proactive/automated-default escalation (Cloudflare’s break-glass case study, complementing Jain) and alternative knowledge-routing mechanisms (NotebookLM-as-external-brain, complementing the dev.to enforcement hierarchy).

Working hypothesis, anchored on this project’s own bug escalation ritual (dev/docs/rituals/BUG_RITUAL.md): effective AI feedback loops require (a) root-cause diagnosis before fixing, (b) promoting recurring point-fixes to durable directives/rules, and (c) an explicit escalation path when a fix reveals a gap in the surrounding process itself. Concretely, BUG_RITUAL implements this as: a Step-0 self-check against skipping the ritual; a relief valve for genuinely trivial fixes that still requires visible, explicit user approval to skip; fix-cluster detection when 3+ small fixes accumulate in one area; a “diagnose first” sequence that escalates through L1 (root cause) → L2 (is there a directive/ritual gap) → L3 (does the L2 fix reveal a meta-infrastructure gap); a rule to fix at the highest level the diagnosis reaches rather than patching just the instance; a mandatory test-first protocol; and guard comments at the fix site explaining the non-obvious constraint.

Cycle 1 established broad, independent convergence on (a) and (b). Boris Cherny’s “add it to CLAUDE.md” practice, Simon Willison/Jesse Vincent’s “Root Cause Tracing” skill, and Kiro’s falsifiable-root-cause-hypothesis-plus-preservation-property mechanism all independently reconstruct this project’s own diagnose-first, promote-to-directive design — strong corroboration that the hypothesis names a real, convergently-discovered pattern rather than an idiosyncratic local convention. Kiro’s “sledgehammer problem” (AI agents ~2x more likely than humans to add unneeded defensive scope when fixing a bug) remains a concrete gap BUG_RITUAL’s test-first protocol doesn’t yet close — it verifies the fix works but not that unrelated behavior was preserved.

Cycle 2 adds two further independent confirmations of hypothesis (b), and — more importantly — the first real refinement of it. Simon Willison’s in-progress “Agentic Engineering Patterns” guide (simonwillison.net, published from Feb 2026) includes a chapter, “Hoard things you know how to do,” that generalizes durable-knowledge-capture beyond reactive bug-fixing: proactively accumulate solved-problem assets (blog posts, TIL entries, reusable tools) before a bug forces the issue, so an agent has more to draw on than what any single ritual has captured. Addy Osmani’s “Self-Improving Coding Agents” independently converges on the same shape via AGENTS.md as long-term semantic memory, explicitly describing the loop as “every fix or pattern rolled into the context for next time” — a third, differently-branded (but mechanically identical) implementation of hypothesis (b), reinforcing that this is now a broadly-adopted industry pattern rather than a niche practice.

However, a dev.to deep-dive (“I Wrote 500 Lines of Rules for Claude Code…”) surfaces a real limit the working hypothesis had not accounted for: naive, unbounded accumulation of directives into one CLAUDE.md degrades rather than improves reliability. Community-observed thresholds cited: past ~80 lines, rules start being dropped; past ~200 lines, large blocks get ignored entirely; each additional rule makes every other rule slightly less likely to be followed. This is a genuine partial contradiction of the naive reading of hypothesis (b) — “keep appending promoted fixes to CLAUDE.md forever” is not a free action, it has a real ceiling. The proposed fix is not to stop capturing durable knowledge but to route it through the right level of an enforcement hierarchy instead of flattening everything into prose rules: hooks for deterministic, unskippable constraints; skills for on-demand procedural knowledge (loaded only when relevant, not always-on); path-scoped rules for precision; CLAUDE.md reserved for compact, always-needed context. Notably, this project’s own CLAUDE.md already has a dedicated DIRECTIVE_PLACEMENT_RITUAL.md, triggered specifically on “adding a directive to CLAUDE.md” — meaning the project had already anticipated exactly this failure mode with a placement gate, rather than defaulting to flat accumulation. This new evidence validates that anticipation rather than exposing an unaddressed gap, but it sharpens hypothesis (b) from “promote fixes to durable directives” to “promote fixes to durable knowledge, routed to the correct enforcement layer, with active pruning against directive bloat.”

Hypothesis (c) gains contextual (not yet structural) extension via a live industry shift. Boris Cherny’s June 2026 “loop engineering” framing (“I don’t prompt Claude anymore… my job is to write loops”) and Claude Code’s new /goal command — where a second, smaller model judges whether a stated goal condition has been met and keeps iterating autonomously until it has — push more automated self-verification down into the fast, agentic-coding loop itself (Andrew Ng’s innermost loop). This doesn’t change BUG_RITUAL’s escalation design, which still operates one loop up (the developer feedback loop, per Ng’s vocabulary), but it’s a signal worth tracking: as more routine verification gets automated inside the fast loop, the residual cases that actually need BUG_RITUAL-style human escalation may narrow toward genuinely structural, process-level gaps — arguably strengthening the case for reserving escalation for L2/L3-type findings rather than routine fixes, which is already BUG_RITUAL’s design intent.

Other cycle-1 findings stand unchanged: Ankit Jain’s proactive risk-classification escalation (hypothesis (c) complement, not competitor); the “ritual approval” pejorative-naming caution from industry AI-code-review coverage; Andrew Ng’s three-loop vocabulary as useful framing.

Net assessment across cycles 1–2: no full contradiction of the working hypothesis; hypothesis (a) remains strongly corroborated (four independent implementations now, including Willison’s own live TDD advocacy); hypothesis (b) is now corroborated by five independent sources total but requires one concrete refinement — durable capture must be routed to an enforcement hierarchy and actively pruned, not flatly accumulated, a limit this project’s own tooling had already anticipated; hypothesis (c) gains one complementary mechanism (Jain) and one contextual signal about automation creeping into the fast loop (loop engineering / /goal), neither of which displaces BUG_RITUAL’s reactive, diagnosis-triggered design.

Working hypothesis, anchored on this project’s own bug escalation ritual (dev/docs/rituals/BUG_RITUAL.md): effective AI feedback loops require (a) root-cause diagnosis before fixing, (b) promoting recurring point-fixes to durable directives/rules, and (c) an explicit escalation path when a fix reveals a gap in the surrounding process itself. Concretely, BUG_RITUAL implements this as: a Step-0 self-check against skipping the ritual; a relief valve for genuinely trivial fixes that still requires visible, explicit user approval to skip; fix-cluster detection when 3+ small fixes accumulate in one area; a “diagnose first” sequence that escalates through L1 (root cause) → L2 (is there a directive/ritual gap) → L3 (does the L2 fix reveal a meta-infrastructure gap); a rule to fix at the highest level the diagnosis reaches rather than patching just the instance; a mandatory test-first protocol; and guard comments at the fix site explaining the non-obvious constraint.

First-cycle evidence is strongly, and somewhat surprisingly, supportive. Three independent sources — including both of this quest’s named watch authors — arrived at close analogues of both halves of the hypothesis without any reference to this project, which is meaningfully stronger corroboration than if the search had simply surfaced people citing similar rituals by name:

• Boris Cherny (Claude Code’s creator) directly instantiates hypothesis (b): “Anytime we see Claude do something incorrectly, we add it to the CLAUDE.md, so Claude knows not to do it next time” — a point-fix promoted to a durable, shared, version-controlled rule, with a GitHub Actions workflow (@.claude PR-review tagging) that automates the capture step.
• Simon Willison, describing Jesse Vincent’s “Superpowers” plugin, directly instantiates hypothesis (a): the “Root Cause Tracing” skill’s explicit instruction is to “trace backward through the call chain until you find the original trigger, then fix at the source” rather than patching where the symptom surfaces — functionally identical to BUG_RITUAL’s L1 diagnose-first step, plus a defense-in-depth recommendation (multiple protective layers, not one correction point) that maps onto BUG_RITUAL’s “fix at the highest level” principle.
• Kiro (AWS’s coding-agent product) independently arrived at a third implementation of hypothesis (a): before writing any code, it formulates a falsifiable root-cause hypothesis and presents it for human review, then differentially tests a “fix property” and a “preservation property” (behavior must stay unchanged where the bug condition doesn’t hold). This adds a genuinely new idea BUG_RITUAL doesn’t yet make explicit: Kiro’s write-up names the failure mode this guards against as the “sledgehammer problem” — AI agents are measured as nearly twice as likely as humans to add unnecessary guard clauses and defensive error handling when fixing a bug, drifting the fix scope beyond the actual defect. BUG_RITUAL’s test-first protocol catches whether the fix works, but doesn’t explicitly test that the fix didn’t also change unrelated behavior — Kiro’s “preservation property” is a concrete, adoptable refinement worth considering.

One genuinely different (not contradictory) mechanism for hypothesis (c) surfaced. Ankit Jain’s “Code Review Is Dead” argues review effort should move from reactive (inspect the finished change) to proactive (inspect the intent/spec before generation, then auto-escalate specific change categories — auth logic, schema changes, new dependencies — to mandatory human review regardless of agent confidence). This is escalation-by-risk-classification-of-the-change, decided upfront; BUG_RITUAL’s escalation is triggered reactively, by what a specific bug’s diagnosis reveals. The two aren’t competitors — a mature system plausibly wants both a proactive risk gate and a reactive diagnostic escalation path — but it’s worth watching whether practitioner convergence favors one over the other, or a hybrid.

A naming caution surfaced from the broader industry. A same-week (2026-07-25) piece on AI code review explicitly uses “ritual approval” to mean the opposite of what this project intends — perfunctory rubber-stamping born of alert fatigue (“the AI cried wolf too many times… the team rubber-stamps approvals”). This project’s BUG_RITUAL is a structured diagnostic escalation process, not a rubber stamp, but the term “ritual” is being used pejoratively elsewhere in the same problem space — worth being deliberate about if this project’s ritual vocabulary is ever discussed externally.

Contextual framing. Andrew Ng’s three-loop model (agentic coding loop: seconds–minutes, agent-internal test/verify iteration; developer feedback loop: minutes–hours, human steering and spec refinement; external feedback loop: days–weeks, real users/production) doesn’t test the hypothesis directly but supplies useful vocabulary: BUG_RITUAL operates inside Ng’s “developer feedback loop,” and its output (a new directive, a new test, a guard comment) is precisely the artifact that lets a single agentic-coding-loop failure compound into durable protection across all future loops, rather than being re-discovered each time.

Net assessment for cycle 1: no contradiction of the working hypothesis found; three independent convergent implementations of both (a) and (b); one concrete refinement candidate (Kiro’s preservation-property / sledgehammer-problem framing); one complementary-not-competing alternative for (c) (Jain’s proactive risk routing); one terminology caution.

Evidence #

2026-09-03 — CLAUDE.md Best Practices: What the Evidence Supports (2026) (example.com) #

Type: contradictory This item provides the first empirical study (arXiv 2511.12884) on CLAUDE.md effectiveness, finding that the mere presence of the file dramatically improves rule adherence (from 0% to ~68%), but that its internal structure — length, rule position, organization — has no statistically significant impact, partially contradicting the community-observed wisdom about strict line-count thresholds being critical for reliability.

2026-09-03 — AI Agent Control Flow Patterns: 7 That Ship (Kunal Ganglani) #

Type: supporting This piece reframes agent reliability as a control-flow problem, not a prompt-tuning problem, providing a robust engineering vocabulary (bounded retries, durable checkpoints, human-in-the-loop as a first-class state, compensation) for the kinds of meta-level infrastructure gaps that hypothesis (c)’s escalation path is designed to surface.

2026-09-03 — Self-Correcting AI Loops: How to Catch Agent Mistakes Before They Reach Users (Medium) #

Type: supporting This item provides a critical mechanism for hypothesis (c), arguing that effective self-correction is not achieved by asking an agent to review its own work (which is prone to self-preference bias), but by using an external, deterministic evaluator (like a test suite or tool) that provides new evidence for the agent to react to.

2026-09-03 — Long-term memory for AI coding agents: decisions that survive the session (selvedge) #

Type: supporting This introduces a more advanced mechanism for hypothesis (b), moving beyond prose rules in a flat file to a structured, queryable memory of decisions keyed to specific code entities, complete with the reasoning for the decision and a potential expiry date — a concrete implementation of turning fixes into durable, reusable knowledge.

2026-09-03 — SCOPE: A Staged Code Review Model for Agentic Development (Dr. Michaela Greiler) #

Type: supporting This provides a formal, multi-stage framework for the human-AI review process (Agent Review → Developer Review → Peer Review), giving a structured vocabulary to the escalation and verification loop that hypothesis (c) describes more informally.

2026-09-03 — Fast Coding Agents Need Faster CI (Suyog Joshi) #

Type: contextual This piece reframes CI/CD not as a post-commit gate but as a critical, high-frequency feedback loop during agentic development, arguing that a slow pipeline becomes the primary bottleneck for an otherwise fast agent, and that the agent must not be allowed to weaken the tests that define its success.

2026-09-03 — AI Session Memory: The ‘Wrap’ Ritual for Context and Self-Correction with Markdown Files (Reddit) #

Type: supporting This describes a concrete, user-developed practice for hypothesis (b) where the developer and agent collaborate in an end-of-session “wrap” ritual to explicitly summarize key decisions and log mistakes into a persistent file, which is then loaded at the start of the next session to prevent recurrence.

2026-09-03 — Experience Cards: Team-Owned repo Memory for CoCo (Snowflake) #

Type: supporting This describes a production system that implements hypothesis (b) by capturing institutional knowledge from human-approved pull requests and review comments into structured “Experience Cards,” which are owned by the team and resurfaced to agents in relevant contexts, formalizing the “accepted-fix becomes durable rule” loop.

2026-08-04 — Self-Improving AI Coding Agents Through Accumulated Behavioral Rules: A Closed-Loop Framework (arXiv 2607.13091) #

Type: supporting First quantified, independently-measured validation of hypothesis (b) — see “Cycle 3” in The Answer So Far above for full detail. Core numbers: 5→18 behavioral rules over 4 weeks, zero recurrences across 9 error classes / 74 post-rule exposures, review-comment mix shifting from 14% mechanical to 66% architecture/API/performance, 60% of rules transferring across repo/tool boundaries. Single-deployment observational evidence per the authors, not a controlled experiment.

2026-06-08 — Anthropic’s Boris Cherny creator of Claude Code says there are days he manages tens of thousands of AI agents at once (Fortune) #

Type: contextual First concrete (if thin) empirical glimpse of hypothesis (c)’s open “who escalates at scale” question raised in cycle 3: Cherny reports Claude Code “is fully writing itself” and “is also doing its own security review,” and that he “wakes up in the morning, and Claude has already taken action” overnight. Doesn’t describe the actual verification mechanism or what happens when self-review is wrong, so the open question isn’t resolved — but it gives the “Supervised autonomy”/“AI-native” end of Cherny’s own maturity-stage framework its first real-world texture: self-review plus periodic human spot-check, not a richer AI-to-AI escalation protocol. A named watch author, directly on-topic.

2026-03-15 — Why Does CLAUDE.md Lose to Claude Code System Prompt Directives? (BSWEN) #

Type: supporting Argues generic CLAUDE.md directives lose not just to rule-count volume (the dev.to piece’s ~80/~200-line thresholds, cycle 2) but to position — the system prompt’s privileged place at the start of every context window gives it structural weight CLAUDE.md can’t match by token count alone. Recommends pairing each directive with explicit rationale (why the rule exists, consequences of non-compliance, how compliance is verified) so it competes on information content rather than position. Supplies a plausible mechanistic explanation for why BUG_RITUAL already requires guard comments “explaining the non-obvious constraint” rather than a bare prohibition — independently validating existing ritual design, not just adding a new practice to adopt.

2026-07-21 — A Fireside Chat with Cat and Thariq from the Claude Code team (Simon Willison, with Cat Wu and Thariq Shihipar, Anthropic) #

Type: supporting Primary-source confirmation, from Claude Code’s own creators, of the enforcement-hierarchy refinement to hypothesis (b) first surfaced in cycle 2 (dev.to piece): Claude Code’s system prompt was recently cut ~70-80%, specifically by removing “examples and lists of things not to do” — Willison: “it’s time to stop overloading our prompts with examples and lists of things not to do.” Claude Tag’s memory is implemented as one markdown file per Slack channel (scoped, not global), with individual session contributions merged back into shared channel memory. Elevates the “route knowledge to the right scope, prune rather than flatly accumulate” refinement from community observation to the reference implementation’s own shipped practice. A named watch author, on a preferred-source domain, directly on-topic.

2026-07-16 — “Steps of AI Adoption” (Boris Cherny, Anthropic) #

Type: contextual Names five maturity stages for teams working with coding agents: Gated (0) → Assisted (~1 agent/dev, high supervision) → Parallel (~10 agents/dev, AI codes / humans verify) → Supervised autonomy (~100 agents/dev, AI verifies / humans supervise outcomes) → AI-native (1,000+ agents, humans steer by intent). First genuinely new structural question raised for hypothesis (c): BUG_RITUAL’s per-fix human-diagnosis-and-approval design matches the “Parallel” stage, where a human still reviews each agent’s output directly. At “Supervised autonomy” and beyond, per Cherny’s own framework, verification itself gets delegated to AI and humans supervise outcomes rather than individual fixes — raising an open question no source in this quest yet answers: what does root-cause-diagnose-then-escalate look like once there’s no human left to review each individual diagnosis? A named watch author, directly on-topic, from a primary source.

2026-04-30 — The Missing Layer Between AI Coding Agents and Institutional Knowledge (UNU Campus Computing Centre) #

Type: contextual Proposes using Google NotebookLM as a queryable “external brain” for coding agents — grounded Q&A over curated sources (specs, postmortems, debugging logs), queried at session start and written back to at session end, with every answer citation-backed to source material. A different technical mechanism for the same cycle-2 enforcement-hierarchy idea (dev.to piece): retrieval-on-demand instead of an always-loaded file, functionally similar to a skill loaded only when relevant rather than always-on. Minor/product-oriented source but thematically on-point.

2026-04-20 — Orchestrating AI Code Review at scale (Cloudflare) #

Type: contextual Production case study: a 7-agent automated review system (security, performance, code quality, documentation, release management, compliance) ran 131,246 review runs across 48,095 merge requests in 5,169 repositories over 30 days, median review time 3m39s. A human “break glass” override (forces approval regardless of AI findings) was used only 288 times (0.6%). Gives Ankit Jain’s proactive risk-routing idea (cycle 1, hypothesis (c) complement) a concrete, at-scale implementation — automated review is the default, human escalation the rare exception, the inverse of where BUG_RITUAL currently places the human (reviewing every escalation, not overriding a rare one). Discussed on news.ycombinator.com, a preferred source.

2026-06-22 — Claude Code Loop Engineering: Stop Prompting, Start Designing Autonomous Agent Workflows #

Type: contextual Reports Boris Cherny’s June 2026 framing shift: “I don’t prompt Claude anymore. I have loops running that prompt Claude… my job is to write loops.” Covers Claude Code’s /goal command (added v2.1.139, week of May 11, 2026): a second, smaller model judges whether a stated goal condition is met after each turn and keeps iterating autonomously if not. Extends Andrew Ng’s three-loop vocabulary already in this quest’s evidence — pushes more automated self-verification into the fastest (agentic-coding) loop. Doesn’t test the working hypothesis directly, but is a live signal from a named watch author that could narrow, over time, which cases actually need BUG_RITUAL-style human escalation.

2026-04-07 — I Wrote 500 Lines of Rules for Claude Code. Here’s How I Made It Actually Follow Them. #

Type: contradictory Documents community-observed instruction-following degradation as CLAUDE.md rule count grows: past ~80 lines rules start being dropped, past ~200 lines large blocks get ignored entirely, and each added rule makes every other rule slightly less likely to be followed. Proposes an enforcement hierarchy instead of flat accumulation — hooks (deterministic, unskippable) > managed settings > output styles > CLAUDE.md/root rules (always loaded) > path-scoped rules/subdirectory CLAUDE.md (on-demand, precise) > skills (on-demand procedures). A genuine partial contradiction of the naive reading of hypothesis (b): “keep appending promoted fixes to CLAUDE.md” has a real reliability ceiling, not just a scale-of-effort cost. Notably, this project’s own CLAUDE.md already routes new-directive decisions through dev/docs/rituals/DIRECTIVE_PLACEMENT_RITUAL.md, suggesting this exact failure mode was already anticipated rather than discovered the hard way.

2026-02-23 — Writing about Agentic Engineering Patterns (Simon Willison), esp. Hoard things you know how to do #

Type: supporting Willison’s ongoing guide to coding-agent practices (published incrementally, ~1-2 chapters/week through spring 2026) includes “Hoard things you know how to do” — proactively accumulate solved-problem assets (blog posts, TIL entries, reusable tools/scripts) as durable inputs an agent can draw on, generalizing hypothesis (b) beyond reactive point-fix promotion to anticipatory knowledge capture. The guide’s red/green TDD chapter also reinforces hypothesis (a)’s mandatory test-first requirement — Willison independently advocates test-first-with-agents as now “effectively free” and non-optional, consistent with BUG_RITUAL’s test-first protocol. A named watch author, on a preferred-source domain, directly on-topic.

2026-01-31 — Self-Improving Coding Agents (Addy Osmani) #

Type: supporting Independently converges on hypothesis (b) via a differently-branded but mechanically identical mechanism: AGENTS.md as long-term semantic memory, with “every fix or pattern rolled into the context for next time” so the agent’s effectiveness compounds across iterations rather than re-discovering the same mistakes. A third independent implementation of the point-fix-to-durable-artifact pattern (after Cherny’s CLAUDE.md and Willison’s hoarding), from a well-known, non-Anthropic-affiliated source — further evidence this is a converged industry pattern, not an idiosyncratic one.

2026-07-25 — Why AI Code Review Overwhelms Developers and How to Fix It #

Type: contextual Names “ritual approval” as the failure mode where high-volume, high-false-positive AI review comments cause developers to rubber-stamp PRs without genuine scrutiny — the opposite connotation of this project’s BUG_RITUAL. Proposes risk-tiered escalation instead: critical changes (auth, APIs, payments) require two human reviewers plus security scanning; standard changes need one reviewer; low-risk changes (docs, tests) auto-approve. A terminology caution plus a concrete example of proactive, risk-classification-based escalation (contrast with BUG_RITUAL’s reactive, diagnosis-triggered escalation).

2026-06-30 — Andrew Ng’s 3 Loops for 0-to-1 AI Products #

Type: contextual Three nested feedback loops at different timescales: agentic coding loop (minutes — agent writes/tests/iterates autonomously), developer feedback loop (hours — human steers product decisions and refines specs), external feedback loop (days–weeks — real users, alpha tests, production data). Explicitly credits Boris Cherny and Peter Steinberger for popularizing “loop engineering” as the underlying agentic-coding-loop concept. Doesn’t test the hypothesis directly but situates BUG_RITUAL’s mechanism inside the “developer feedback loop” layer — the layer where a single agent failure gets converted into a durable artifact.

2026-03-02 — How to Kill the Code Review (Ankit Jain, Latent.Space) #

Type: contextual Argues manual code review can’t scale against AI-generated volume (91% increase in review time despite 98% more PRs merged at high-AI-adoption teams) and proposes shifting human oversight upstream — “from reviewing Code to reviewing Intent” — with automatic escalation for specific change categories (auth logic, schema changes, new dependencies, infra config) regardless of agent confidence. A genuinely different mechanism for hypothesis (c): proactive, change-classification-triggered escalation, versus BUG_RITUAL’s reactive, diagnosis-triggered escalation. Complementary rather than contradictory.

2026-02-19 — The bug fix paradox: why AI agents keep breaking working code (Kiro / AWS) #

Type: supporting Names the “sledgehammer problem”: AI agents are measured as nearly twice as likely as humans to add unnecessary guard clauses and defensive error handling when fixing a bug, drifting scope beyond the actual defect without explicit constraints. Kiro’s countermeasure independently reconstructs hypothesis (a): before writing code, formulate a falsifiable root-cause hypothesis and present it for human review, then define a “fix property” (bug condition → postcondition must hold) and a “preservation property” (behavior must stay unchanged when the bug condition doesn’t hold), testing both differentially. The preservation-property idea is a concrete refinement BUG_RITUAL’s current test-first protocol doesn’t explicitly require.

2026-01-03 (approx.) — 13 Practical Claude Code Tips from Its Creator, Boris Cherny #

Type: supporting Tip 5 directly instantiates hypothesis (b): “Anytime we see Claude do something incorrectly, we add it to the CLAUDE.md, so Claude knows not to do it next time” — with a GitHub Actions workflow tagging @.claude in PR reviews to automate the capture. Tip 4 (shared CLAUDE.md in source control for team-wide learned anti-patterns) and Tip 13 (“verification is the most important tip” — feedback loops via tests/browser validation give a 2-3x quality improvement) reinforce the same mechanism from the tool creator’s own stated practice, independent of this project’s ritual design.

2025-10-10 — Superpowers: How I’m using coding agents in October 2025 (Simon Willison, describing Jesse Vincent’s Superpowers plugin) #

Type: supporting The “Root Cause Tracing” skill directly instantiates hypothesis (a): “Trace backward through the call chain until you find the original trigger, then fix at the source,” explicitly warning against fixing where a symptom appears (e.g., a bug surfacing deep in a call stack from git initialization in the wrong directory). Recommends defense-in-depth — multiple protective layers rather than a single correction point — which maps onto BUG_RITUAL’s “fix at the highest level found” principle. Predates this quest and this cycle’s window but is foundational, directly on-point evidence from a named watch author establishing a real, adopted mechanism rather than a hypothetical one.

How We’re Looking #

Keywords: "feedback loop" AI coding agent, AI code review escalation OR ritual, "root cause" AI generated bug fix, AI pair programming retrospective OR postmortem, CLAUDE.md directive OR ritual pattern, "class of bug" AI agent prevention, AI agent self-correction OR learning workflow, AI coding agent memory OR institutional knowledge

Watch authors: Boris Cherny, Simon Willison

Preferred sources: docs.anthropic.com, simonwillison.net, martinfowler.com, news.ycombinator.com, github.com/anthropics

Negative filters: beginner content, “getting started” tutorials

Strategy Changelog #