← research

Anthropic's official YouTube channel — mined 2026-07-08

Jul 14, 2026

Scope: the user's linked video (hyqLNX3VExQ) plus the 10 most substantive other uploads pulled via yt-dlp (auto-captions) from Anthropic's current YouTube channel — note below on which channel that actually is. Deduped against docs/RESEARCH_video_insights.md (Thariq's Fable keynote), docs/RESEARCH_top_voices.md, and docs/RESEARCH_loops2/3/4.md. Everything below is net-new unless flagged otherwise.

Channel correction, worth logging: @anthropic-ai (channel id UCrDwWp7EBBv4NwvScIpBDOA, ~97 older videos — product launches, "Introducing X", customer testimonials) is not where current content lands. The active channel is now simply branded "Claude" (youtube.com/channel/UCV03SRZXJEz-hchIAogeJOg, 134 uploads, includes the user's linked video). All picks below are from the Claude channel. If you re-run this sweep later, enumerate that channel, not the @anthropic-ai handle.

What the channel emphasizes (meta-read)

Three visible tracks, roughly by volume:

  1. Conference-talk dumps ("Code with Claude" London/Tokyo workshops + keynotes) — dense, technical, presenter is an Anthropic applied-AI engineer walking a live demo. This is where almost all the durable technique lives. Auto-captions exist for nearly all of these.
  2. Product-launch shorts ("Introducing X", "What is Y") — thin, marketing register, 1-3 min, frequently missing auto-captions entirely (see honest nulls below) — skipped per instructions.
  3. Customer-conversation series (Boris Cherny or a colleague interviewing a customer CTO/founder — DoorDash, Spotify, Cursor, Lovable, Replit, Legora, Genspark, Cognition) — long-form (25-45 min), surprisingly substantive: real architecture, real ROI numbers, real failure modes. The user's linked video is one of these.

The center of gravity right now is Claude Managed Agents (CMA) — a big fraction of the recent conference talks exist to teach CMA primitives (memory stores, dreaming, callable sub-agents, environments/sessions). If you only have time for one theme going forward, track CMA.

Video 1 — DoorDash gave every employee Claude Code (the user's link)

Video: "DoorDash co-founder Andy Fang on building with Claude" (YouTube page title shows as "DoorDash gave every employee Claude Code") — hyqLNX3VExQ — uploaded 2026-07-07 — 25:11 — `

Why it matters: Andy Fang (DoorDash co-founder, still an active engineer) interviewed by Boris Cherny. Org-scale adoption story with concrete mechanisms, not just "we use Claude Code now."

Durable takeaways:

  • Written artifacts as the org's distillation mechanism. "Try to as much as possible get people to produce written artifacts because that's stuff I can share with the entire company... it's just as important to showcase, hey, here's something I did that was cool versus... here's this workflow that I tried that didn't work or here's this MCP integration that I did that wasted a bunch of tokens." This is the same "HTML/markdown artifact as durable knowledge transfer" pattern already banked from Thariq — DoorDash independently arrived at it as an org-scale practice, not a presentation trick.
  • Agent-friendly codebases as upfront investment. "The tech lead... jotted down maybe 50 plus like principles of architectural principles that he cared about for a particular codebase... in these markdown files within the GitHub repository so that when the agent was coding it could reference these architectural principles." Direct precedent for treating CLAUDE.md as a living architecture-principles doc, not just a build-command cheat sheet.
  • Standardized skills as the mechanism for spreading power-user technique. One engineer did a 4-engineer/1-quarter migration solo in 3 weeks; DoorDash's response was to package the mobile team's simulator-spin-up workflow as a shared skill rather than tell people to imitate the power user.
  • Internal "Flux" platform — VMs in DoorDash's cloud, security-blessed, that spin up Claude sessions on the Agent SDK; this is what powers their AI code-review agent. Confirms the "agent SDK + isolated cloud sandbox" architecture pattern independently at both DoorDash (Flux) and Spotify (Honk, see Video 8) — convergent evidence this is becoming the standard shape for org-scale autonomous agent infra.
  • "AI champions" discovery model, not top-down mandate. "Give people the tools and just see who ends up naturally picking it up... they can't help but share that enthusiasm." Explicit rejection of top-down workflow assignment: "if you're top down like hey go automate this workflow you might actually just pick the wrong workflow or the wrong person."
  • Throwing away working ideas is now correct, contra prior engineering culture: "it used to be the worst idea before... to take the same idea and try it over and over again... but actually now trying that same exact idea with a newer model sometimes it just works."

Exploit: (1) The written-artifacts pattern is a third independent confirmation (Thariq, DoorDash, and — see Video 6 below — the Spotify/Honk conversation) that any loop-engineering doctrine should have a standing "publish a shareable artifact" step, not just a private implementation-notes.md. (2) DoorDash's CLAUDE.md-as-architecture-doc pattern is directly reusable for Mission Control's own CLAUDE.md and for any /document-generate output. (3) The Flux/Honk convergence (VM-per-agent-session

  • Agent SDK, security-blessed) is worth a one-line addition to loop-engineering's "primitives" table: this is now the standard shape of org-scale autonomous coding infra, and worth benchmarking Mission Control's own session-observability model against it if it ever needs to observe hosted (not just local ~/.claude) agent fleets.

Video 2 — Tool, skill, or subagent? Decomposing an agent that outgrew its prompt

Video: mWvtOHlZM-I — Code with Claude London workshop (Will, Applied AI) — uploaded 2026-05-23 — 45:06 — `

Why it matters: This is the single most directly actionable talk in the batch. It's a live, step-by-step refactor of a degraded agent (400-line system prompt, 12 tools, 3 sub-agents, eval score dropped from 83% to 62% under regression) back up to 92% — and every fix is a named, reusable pattern.

Durable takeaways:

  • The decision rule for tool vs. skill vs. subagent, stated explicitly: "Leave the system prompt only for the information that Claude needs in its mind, regardless of the task... Skills are fantastic for packaging information that Claude is going to need some of the time, not all of the time." System prompt = universal context; skill = progressive disclosure; tool = an action Claude needs to take; subagent = only for (a) parallelizing a lot of Claude at one problem or (b) needing a genuinely fresh, uncontaminated mind (code review is the canonical case).
  • "Lean into human-like primitives first" — bash, file system, web search, to-do list — before writing custom tools, and "only in the case where we have a common collection of tools that multiple clients will benefit from accessing, do we go about the process of... publishing them as an MCP server." MCP is explicitly the last resort, not the default: "We see a lot of folks run towards MCP first, and a lot of our customers end up in this ecosystem where there's a lot of chaotic MCP servers... which can create some problems."
  • Measured effect of primitives-over-tools: replacing 12 custom data-reasoning tools with bash/read/write (i.e., letting Claude write a script instead of stuffing a CSV into context) dropped token usage from 200k+ to a small fraction, and cut cost and latency accordingly — concrete numbers, not a vibe claim.
  • Sub-agent communication breakdown is a named, common failure mode ("F2" in their eval suite): the sub-agent got the task right, but the orchestrator misread the hand-back. CMA's answer is "callable agents" — native sub-agent support with full observability/logging parity with the orchestrator, specifically built to fix this.
  • Hill-climbing on evals is the whole workflow: run eval → have Claude itself triage why each case failed (root-cause categories, not just pass/fail) → make one architectural change → rerun → repeat. Claude was used to diagnose its own failures, not just fix them.

Exploit: This is the clearest external validation yet for a fable-judgment or loop-engineering addendum: a decision tree for tool/skill/subagent, stated as Anthropic's own internal default, not folklore. Worth lifting near-verbatim into loop-engineering's anatomy section. Also directly actionable for CLAUDE.md's own subagent-pinning section: the "fresh mind" justification for subagents (code review, adversarial QA) is the same shape as this user's own code-review/review-pr fan-out — worth citing as the canonical justification. The MCP-last ordering is worth a doctrine line given how many MCP servers are already configured in this environment (context-tax risk, per eW3oTyfeWZ0 below).

Video 3 — Evals for taste: Hill-climbing a slide-generation agent

Video: v9FTCvkV_a0 — Code with Claude London workshop — uploaded 2026-05-23 — 39:16 — `

Why it matters: A full grader taxonomy plus two field-tested anti-patterns for LLM-judge reliability that aren't in the existing banked eval material.

Durable takeaways:

  • Four grader types, explicit trade-offs: code-based (fast/cheap/deterministic but brittle, lacks nuance), model-based/rubric (flexible, nuanced, but non-deterministic and needs calibration), multi-judge consensus (run N judges, majority wins — buys back determinism at the cost of compute), human (highest quality, slowest, most expensive — reserved for spot-checks and A/B, not routine grading).
  • Anti-anchoring fix for LLM judges: "if it is anchored on like this four, it will do anything it can to argue why it should be a four... So how you do it is you actually turn it around. First you say, 'give me pros, give me cons'... and then based on all of those reasons together, then you need to make your final decision." Asking for the score before the reasoning corrupts the reasoning — ask for pros/cons first, force the score to be the last token, not the first.
  • Eval saturation is named and normal: "if you have a grader that you get no useful information out of, then you should not have that part of your eval" — evals are a living artifact, not a fire-and-forget test suite; a judge giving uniformly high scores regardless of visible quality (e.g., scoring a slide with zero images 5/5 on "image quality") means the rubric has stopped discriminating and needs re-anchoring with explicit bad/good examples.
  • Adversarial QA-loop instruction pattern, generalized beyond code review: "require QA loop... assume there are problems, and your job is to find them. Approach QA as a bug hunt, not a confirmation step." Applied here to slide decks (render → screenshot → self-critique → fix → re-render, don't stop until one full fix-and-verify cycle completes) — the same shape as code review, generalized to any artifact-producing agent.

Exploit: The multi-judge-consensus grader and the pros-before-score anti-anchoring fix are directly reusable for any LLM-as-judge component in Mission Control (e.g., grading transcript quality, skill-fire usefulness, or fallback-receipt severity) — cite this talk as the source pattern rather than reinventing judge-prompt design from scratch. The eval-saturation framing is a good line for loop-engineering's finish-condition doctrine: a checker that always passes (or always scores high) is itself a bug to detect, not a green light.

Video 4 — Agents that remember + Memory and dreaming for self-learning agents

Videos (two talks on the same feature, complementary — worth reading as one entry):

  • geUv4CjPpxI — "Agents that remember" (Kevin, hands-on CLI/console workshop) — 2026-05-23 — 28:42 — `
  • IGo225tfF2I — "Memory and dreaming for self learning agents" (Ravi, keynote/architecture talk, same topic also uploaded as RtywqDFBYnQ) — 2026-05-21 — 21:34 — `

Why it matters: This is Anthropic's own shipped "Dreaming" feature for Claude Managed Agents — directly relevant given the user's own project already has a docs/DREAMING_LEDGER.md that explicitly positions itself against "Anthropic Dreaming (cloud)." These two talks give the actual technical mechanics that the existing ledger doc doesn't have yet.

Durable takeaways:

  • Memory store = a file system Claude reads/writes via bash/grep, not a special API the model has to learn. "The actual interesting thing here is that we've actually mounted it as a file system because it's such a powerful interface for the model... it can use grep to search for keywords." Deliberate "get out of Claude's way" design philosophy, same one used for skills.
  • Two-tier scoping: read-only org-wide memory (shared policy/runbooks, updated infrequently) + read-write task/team-scoped memory, with optimistic concurrency control to prevent agents clobbering each other's writes. Full version history, per-write attribution to the session that made it, and diffable versions — enterprise audit trail, not just a blob store.
  • Dreaming is an async batch job, architecturally decoupled from the hot path: "It's completely removed from the hot path" — one sub-agent spawned per input session, deliberately exhaustive by design ("if you give it 100 chances, you want to make sure Claude is looking over all the information"), non-destructive (clones the input memory store into a new output store rather than editing in place — a human/agent can diff before adopting), triggerable ad hoc/nightly/hourly/on session-end via API. Reported ~95% cache hit rate on dream sessions (most of the token spend is cached re-reads of prior transcripts, not fresh generation).
  • Real customer numbers, not a demo claim: Rakuten saw a 97% decrease in first-pass errors; Harvey saw a 6x increase in completion rate on a legal benchmark after adding dreaming; WiseDocs reduced recurring issues via cross-session memory in document verification.
  • The mechanism, concretely, from the demo: an SRE-triage agent notes "fix in flight" in a shared memory store; a later session investigating the same alert reads that note before acting — literal cross-session, cross-agent coordination via a shared file, not a message bus.

Exploit — directly relevant to docs/DREAMING_LEDGER.md: the ledger's comparison table currently describes Anthropic's cloud Dreaming only at a conceptual level ("memories applied automatically"). These two talks give the concrete mechanics worth folding into that table's right-hand precision: (1) Anthropic's dreaming is exhaustive-by-design, one sub-agent per session — token-heavy but cache-cushioned (95% hit rate) — versus the Ledger's deterministic mining, zero model calls; this is a genuinely different point on the cost/thoroughness curve, worth stating explicitly as the differentiator rather than implying deterministic-mining is simply "the cheap version." (2) Anthropic's scheme is non-destructive by cloning to an output store — the Ledger's "never writes `/.claude`" principle is the same idea, applied locally; worth citing Anthropic's own architecture as validating that non-destructive-by-construction is the correct shape for any dreaming-like system, not just a safety compromise. (3) The read-only-org-tier / read-write-task-tier split with optimistic concurrency is a pattern worth considering if the Ledger's recipes ever need to be shared across multiple local Claude installs (e.g., devcube + MacBook) rather than staying single-machine.

Video 5 — Making agentic workflows trustworthy and verifiable with a custom DSL

Video: qOjleN2-50c — Code with Claude London (James Brady, Elicit) — 2026-05-22 — 29:39 — `

Why it matters: A named practitioner from Elicit (not Anthropic) arguing a specific, well-reasoned counter-position: for high-stakes domains, you may need a Turing-incomplete DSL between the model and execution, not free-form tool calls.

Durable takeaways:

  • Core thesis, quotable: "Let's say that two systems produce identical output. Do you trust them equally?... The mechanism, the how of how an answer is produced, is as important — in a different way — compared to just the final output itself."
  • Three desiderata that justify reaching for a DSL: the process must be (1) legible — spot-checkable by both humans and other agents, (2) fidelity-preserving under iteration — adding a new requirement shouldn't cause drift from the original intent, (3) followed faithfully — the plan the user approved is literally what executes, not just a suggestion the model may deviate from. Elicit's DSL (AshPL — a typed, Turing-incomplete, purely functional subset of Python) is executable itself, not a plan description that the model then interprets loosely.
  • Whole-program reinterpretation + content-addressed caching, not incremental patching. Every redraft re-interprets the entire program from scratch (not just the changed lines) — deliberately, because interpreting only the delta is where drift creeps in — but a content-hash cache makes this cheap: identical sub-expressions (a web search that already ran) resolve from a hash map instantly.
  • Practical DSL-design tip: base a DSL on an existing language with heavy training-data representation (they chose a Python subset) so the model doesn't have to learn new syntax, only a restricted grammar — most of the engineering effort is the surrounding harness (credential isolation, interrupt handling, session rehydration, event sourcing), not the language itself.

Exploit: This is a genuine counter-pattern worth flagging in loop-engineering or fable-judgment as a named alternative to "just let the agent call tools" for any Mission Control feature that needs auditable, replayable agent decision-making (e.g., if a future feature lets an agent act on audit findings rather than just report them, this is the pattern to reach for — a restricted, re-interpretable, cacheable plan language rather than trusting free-form tool-call sequences). Also useful vocabulary: "mechanism matters as much as output" is a good one-line justification for Mission Control's whole premise (forensics on how a session reached its result, not just whether it succeeded) — pairs well with the already-banked IndyDevDan epigraph ("an agent you can't monitor is an agent you can't improve").

Video 6 — The thinking lever

Video: T7KqH7kYnE4 — Code with Claude London (Alexander Briken, Applied AI Research) — 2026-05-20 — 21:17 — `

Why it matters: The most precise mental model available anywhere (including the existing banked material) for what the /effort dial and adaptive thinking actually are and are not.

Durable takeaways:

  • The dial is not a thinking toggle. "A thinking toggle is actually a poor proxy for the amount of effort a model should put in. You're not expressing how hard you want Claude to think... you're actually just turning off a core capability." The right mental model: thinking, tool calling, and text output are three always-available capabilities; effort controls how much of each Claude uses, not whether thinking exists at all. Adaptive thinking is not a router — it doesn't classify the request type, it just gives the model the freedom to interleave thinking/tool-calls/text in whatever order and depth the specific problem calls for, same as a human doesn't announce "now I will think" before every action.
  • Concrete effort-level recommendations, stated as defaults: max = diminishing returns except for genuinely hard tasks; extra high is Claude Code's and claude.ai's actual default and the recommended general-purpose choice; high = still a good speed/intelligence balance if the task needs any real intelligence; medium/low = reserved for latency-sensitive, non-intelligence-bound tasks (classification, summarization, extraction).
  • Model size vs. effort trade-off, with a measured example: a Haiku-4.5 simulation on the same prompt/effort as an Opus run took half the time and the same token count, but was qualitatively much worse — "if the question you're asking of Claude needs any intelligence at all, you're often better off using the larger model... even if you have the effort at low." Direct, source-cited reinforcement of this user's own routing doctrine ("route hard problems up a model, not up an effort tier").
  • Low effort can produce surprising, genuinely better solutions on certain tasks — the Claude Plays Pokémon eval on low effort discovered exploit-like shortcuts (repels/escape ropes to avoid battles) that beat the game faster than higher-effort, more "thorough" play. Worth remembering low effort isn't strictly "worse," just differently constrained — sometimes constraint produces a better local optimum.

Exploit: This is the clearest primary-source confirmation yet of the CLAUDE.md line "Route hard problems UP a model, not up an effort tier — effort dials don't rescue a cheaper model on genuinely hard tasks." Worth citing this talk directly as the source (with the Haiku/Opus same-token, worse-quality data point) next to that doctrine line. Also worth a one-line addition: default to extra high effort, not max, per Anthropic's own stated default — matches this user's existing "Effort high by default; xhigh only for brutal runs" but sharpens it: xhigh is the recommended default, not a rare escalation.

Video 7 — How we Claude Code

Video: IlqJqcl8ONE — Code with Claude London workshop (Arno, Applied AI) — 2026-05-23 — 31:43 — `

Why it matters: This is the hands-on workshop version of Thariq's already-banked "HTML is the new markdown" pitch — same thesis, but with concrete implementation details Thariq's talk/article didn't cover: how to actually make a UI agent-verifiable, not just how to spec it in HTML.

Durable takeaways (skipping what's already banked — interview-driven spec via AskUserQuestion, HTML > markdown for specs):

  • DOM-state-as-agent-contract, the concrete mechanism. Publish component state to the DOM as explicit data-* attributes, separate from React's internal state — "if you publish the state here separately from the React internals, you'd be able to run the verification independently of whatever the state of the app is." This is what lets an agent (or a human, or a headless CI run) read ground truth without scraping rendered pixels or reverse-engineering component internals.
  • Three verification surfaces, same underlying manifest: a human-readable dashboard, an agent-driven run from the browser via Playwright MCP, and a headless CLI run (bun verify) for CI — all three read the same schema/fixture/invariant definitions, so they can't drift from each other.
  • Invariants + probes, deliberately including a planted failure. Each component ships a schema, a set of known-good fixtures, and invariants that must always hold; probes are explicitly designed to push off the happy path (the demo plants a genuine bug — 3+4 not equalling 10 — to prove the verification framework actually catches it, not just confirms the happy path).
  • Recorded verification clips as the artifact of record. Anthropic's own Claude Code team runs every generated verification pass through a recording step and stores clips (S3 or shared with colleagues) as the evidence trail — this is their literal implementation of "pasted proof," applied to UI changes specifically.
  • Explicit model recommendation for this pattern: "Opus 4.7 works really well because it has a much better vision model... if you use Sonnet, I wouldn't recommend that" — vision-heavy design/ verification work is a case where the model tier genuinely matters, not just effort.

Exploit: The DOM-state-as-contract pattern is a concrete, buildable addition to verify skill doctrine or any future Mission Control feature that needs to verify a UI change — publish state as data-* attributes independent of framework internals, then the same manifest drives human review, agent-driven Playwright checks, and headless CI, with zero drift between the three. The recorded-clips practice is a literal implementation of this user's own "pasted proof" doctrine for unattended runs — worth citing as first-party precedent when writing a /goal finish condition that involves a visual change.

Video 8 — How Spotify runs agents across 20M+ lines of code

Video: 9DHZLw5653E — customer conversation, Niklas Gustavsson (Spotify) with Boris Cherny — 2026-06-29 — 26:11 — `

Why it matters: The most technically detailed customer-scale story in the batch — Spotify's "Honk" agent, ~5-6 years of iteration, now on its 8th internal version, built on the Agent SDK.

Durable takeaways:

  • They removed their LLM-judge once the base models got good enough. "We used to have a judge in Honk but we've actually removed it because the agent and models just got good enough that we didn't need it anymore... it made us go from roughly 20-30% success rate on PRs to 80% success rate [when the judge was added], but then as the models caught up... we've eliminated that judge." A concrete, dated data point that judge/critique layers are a stopgap for weaker models, not a permanent architecture requirement — worth re-testing periodically as models improve rather than assuming a QA-loop layer is permanently necessary.
  • Verification is explicitly named the bottleneck, not a nice-to-have. "Verification... is just the single most important thing... one of the common mistakes I see is companies underinvest in how well that verification loop works." Spotify's actual investment: dividing a 20M-line monorepo into thousands of components with clear per-team ownership and strengthened test automation specifically so autonomous PRs could be trusted to automerge without a human reviewer in the loop — the verification investment was a precondition for automation, not a parallel-track nice-to-have.
  • Standardization helps agents the same way it helps humans, stated as a direct causal claim. "If you have... code that looks 10 different ways, Claude is going to be more confused. So the more consistency we have, the better our agents work." Reframes prior human-only code-style arguments as now also an agent-performance argument.
  • ROI attribution methodology, concretely: connect PRs → deployments → planned work items → A/B test rollouts → user value, to get past "throughput went up" into "this specific shipped PR contributed to this measured outcome." 73%+ of PRs are now AI-authored; 75%+ improvement in PR frequency directly attributed to AI tooling; ~4,500 production deployments/day.
  • Fleet-scale mutation pattern, historical context for why Honk exists: before LLMs, Spotify tried deterministic AST-transform scripts for cross-repo migrations and hit a hard ceiling — "trying to make changes to code gets very complicated very quickly... each script turned into thousands of lines of taking care of every edge case." The LLM-based Honk replaced a fundamentally scaling-limited static-analysis approach, not just a manual one.

Exploit: Direct precedent for periodically re-testing whether a fixed QA/critique layer in this user's own pipelines (e.g. the code-review skill's fan-out, or any adversarial review step baked into a loop) is still earning its cost as models improve — Spotify's judge-removal decision is a template for "does this critique layer still pay for itself" audits. The ROI-attribution chain (work item → PR → deploy → A/B outcome) is a reusable shape for any future Mission Control cost/value dashboard beyond raw token spend.

Video 9 — The prompting playbook

Video: G2B0YWuJUgI — Code with Claude London (Margo van Laar, Applied AI) — 2026-05-22 — 33:49 — `

Why it matters: A live, eval-driven debugging session on a realistic, messy production prompt — each fix is a named anti-pattern with a before/after eval score, not abstract advice.

Durable takeaways:

  • "If you can't tell guidelines from policy from data, the model probably can't either." Simply restructuring an unstructured prompt into XML-tagged sections (role / guidelines / policy / tone / data) improved eval pass rate before touching any actual content — structure alone is a free win.
  • Old-model patches actively hurt newer models — named and demonstrated. A defensive instruction ("never give a customer the wrong plan detail, deflect to a URL instead") written to fix a weaker model's hallucination problem caused the newer, more capable model to withhold information it actually had access to, because it over-optimized for the single stated constraint. Fix: state both sides of the trade-off explicitly (the cost of withholding info vs. the cost of an error), not a one-sided ban — matches and sharpens the already-banked "context not constraints" finding from Thariq's talk, with a concrete before/after eval demonstration this time.
  • "Instructions don't add capability." Telling a model "critically, always calculate correctly" didn't fix a proration-math failure; giving it an actual calculator tool did, immediately, to 100% pass. The fix for a capability gap is always a tool or a model upgrade, never stronger wording.
  • Generate → evaluate → repair as a named three-prompt loop, benchmarked directly against "one big smart model" and "one bigger prompt": for a constraint-satisfaction scheduling task, Opus with adaptive thinking solved it reliably but at 3x tokens/latency; splitting into three independent simple prompts (generate a draft, evaluate specific rule violations with evidence, repair only the flagged violations) solved it with lower tokens and latency than either single-prompt approach — and, as a bonus, let soft/runtime constraints (e.g. "keep these two people off the same shift") be added without touching the underlying grading code.
  • Eval design for a new build: five test cases minimum spanning control (must-pass baseline), edge cases (previously observed failures), and capability-boundary cases (when to refuse or escalate to a human) — same shape as the control/edge/human-boundary taxonomy, stated as the standard eval skeleton to reach for on any new agent.

Exploit: The "old patches hurt new models" finding, demonstrated with a real before/after eval score rather than asserted, is worth citing directly next to the already-banked "context not constraints" line from Thariq's Fable talk — this gives it independent, reproducible confirmation from a different presenter and a different domain. The generate-evaluate-repair three-prompt pattern is a concrete, benchmarked alternative worth keeping in loop-engineering's pattern catalog for any future constraint-heavy generation task (e.g. auto-scheduling or auto-prioritizing in Mission Control) — it beat both "bigger model" and "better single prompt" on cost and quality.

Video 10 — Context Management in Claude Code (short)

Video: eW3oTyfeWZ0 — product explainer short — 2026-05-18 — 3:30 — `

Durable takeaway: Explicit, quotable rule of thumb for /compact vs /clear: "When you're working on a specific feature and are going over the context window but need to continue, then compact. If you have finished the plan and want to start on a new feature, then clear — you don't want the previous conversation to present bias in anything new." Also states plainly that MCP servers load all their tools into context by default regardless of use, and recommends turning off unrelated servers or preferring skills (which don't front-load into context the same way) — direct, first-party confirmation of a context-tax mechanism Mission Control would want to detect and flag.

Exploit: Direct, citable confirmation for a Mission Control "context tax" gauge: MCP server count (not just tool-call volume) is itself a per-session context cost, independent of whether those tools get used — worth surfacing "N MCP servers configured, M tools never called this session" as its own audit line, distinct from skill fire-count auditing.

Video 11 — The Explore → Plan → Code → Commit workflow in Claude Code (short)

Video: xJQuF02NAK8 — product explainer short — 2026-05-17 — 3:11 — `

Durable takeaway: Compact, official statement of the canonical workflow, plus one under-cited tip: "If you find Claude keeps running into the same issues, ask Claude to save the solution to his CLAUDE.md file" — i.e., CLAUDE.md as a living, agent-populated troubleshooting log, not just a static human-authored doc. Also: run a sub-agent code reviewer before every commit, then have Claude generate the commit message in your established style — stated as the default recommended close-out sequence.

Exploit: Minor but concrete — the "ask Claude to save the fix to CLAUDE.md" habit is a lightweight, low-ceremony precursor to the more elaborate learnings/extract-approach skill already in this environment; worth keeping both (quick inline save for small recurring fixes, the fuller extract-approach skill for genuinely hard-won insights).

Honest nulls — no auto-captions available

Skipped per instructions (transcript required, none exists):

  • K4-flzsPraE — "Building the best agentic analytics harness: Powered by Claude, built with Claude Code" (Code with Claude) — likely substantive by title, but no English auto-subs at all.
  • tuY2ChJIx48 — "Beyond the basics with Claude Code" — same.
  • wI0ptqCSL0I — "Stop babysitting your agents" — same, title alone suggests it's directly relevant to loop-engineering doctrine; worth a manual re-check later if Anthropic backfills captions.
  • DNRddIEoH3c — "The capability curve" — same.

Also excluded as pure marketing/product-launch register (not fetched): the ~15 "Introducing X" / "What is Y" shorts on both channels (e.g. "Introducing Claude Fable 5", "Introducing Cowork", "Introducing Claude Opus 4.6"), and single-purpose feature-announcement clips under 5 minutes with no technique content beyond what a release note already states.

Provenance

Sweep 2026-07-08. Enumerated both @anthropic-ai (97 videos, legacy/marketing) and the current "Claude" channel (134 videos, UCV03SRZXJEz-hchIAogeJOg) via yt-dlp --flat-playlist. Pulled auto-captions (--write-auto-sub --sub-lang en --sub-format vtt --write-info-json) for 16 candidate videos; 12 had captions and were read in full (deduped/cleaned VTT, not summaries or descriptions); 4 had none (see honest nulls). Deduped against docs/RESEARCH_video_insights.md (Thariq's Fable keynote — confirmed several findings here independently reinforce it: "context not constraints," "HTML over markdown," effort-dial mental model), docs/RESEARCH_top_voices.md, and docs/RESEARCH_loops2/3/4.md. Raw transcripts and cleaned text cached at /private/tmp/claude-501/-Users-thescoho/0ed7bc81-ab9b-4260-8079-f37099fa9944/scratchpad/vids/ (session-scoped scratchpad, not committed).