PodcastsHear the voice. See the shape of the thought.

Boris Cherny (creator and Head of Claude Code) and Cat Wu (Head of Product, Claude Code) look back on Claude Code's first year — from a Slack demo that earned two emoji reactions to running thousands of autonomous agents daily. They walk through how they think about verification, why auto mode replaced plan mode, how routines are eliminating entire categories of manual engineering work, and why the shift from "I write code" to "I talk to a loop" represents two major platform leaps in barely 18 months. ## [00:00] The origins and evolution of Claude Code Boris recalls posting the first Claude Code demo to Slack and getting exactly two reactions. A year later, his workflow involves "armies of agents" — a single loop prompting agents that prompt other agents, forming trees of thousands. The meta-principle that carried the tool this far: every time Claude makes a mistake, don't just correct the output — write the fix into a CLAUDE.md file or a skill so Claude can run unsupervised forever. > *"Every single time Claude makes a mistake, I don't tell Claude to do it differently. I tell it to write it to the CLAUDE.md or to make a skill… and if you can do this, then Claude can just run forever."* ## [01:10] How to make Claude good at verification Both Boris and Cat push back on the narrow view that "verification" means lint, type-check, and unit tests — things that were already automated before agents existed. Real agent verification means the agent can actually run the software under test. Boris cites a moment with Opus 4 where he asked Claude to build a feature and test itself by opening its own CLI — "crazy" at the time, table stakes now. Cat's current approach: a desktop development skill that has Claude spin up the local desktop app, use computer use to click through the UI, hit edge cases, and update the skill itself whenever it discovers a new failure mode. > *"I have it read Slack and understand: hey, is staging down right now, or has someone else already hit this? And then when it debugs the whole issue, I tell it to update the desktop development skill."* ## [03:14] Roles merging: Claude Code beyond engineers Boris recounts the moment he first saw a designer opening PRs — his initial alarm giving way to "okay the code looks good, so maybe it's fine." Cat reports that across enterprises, engineers adopt Claude Code first, then adjacent roles lean over their shoulders: designers making prototypes directly in the app, PMs shipping changes, the finance team running projections inside Claude Code, data scientists with it permanently on-screen. > *"It's kind of like all the roles are merging."* ## [04:48] Using routines for CI, code review, and more Cat describes a Claude Code power user on their team who shipped voice mode and then set up a routine monitoring every GitHub issue and bug report on that feature, automatically drafting fixes and pinging PRs. He later extended it to catch any unresponded bug older than five hours. Cat's own experience: she shipped a small feature with an edge case she missed, a bug was filed, and before she got to it that evening, Claude Code told her "another Claude has already fixed this." Boris adds that routines now handle all code review, babysit every PR, rebase, and respond to CI failures. He hasn't done those manually in a long time. > *"He has another routine that just looks for bug reports that haven't been responded to in five hours and puts up a fix, and he merges the ones that are easy to verify."* ## [06:43] Boris' go-to feature: auto mode Boris stopped using plan mode once Claude 4.6 arrived; by 4.7 the explicit planning step was no longer necessary. He now starts an agent in auto mode and moves directly to the next task without watching it. He traces the shift from the early permission-prompt model — where you had to approve every tool call — to auto mode routing suspicious actions to a classifier instead. Human attention degrades when 99% of prompts are harmless: eyes glaze, the one dangerous prompt slips through. Auto mode concentrates attention on genuinely flagged cases only. > *"Auto mode is more safe than reading every single permission prompt, because it means that you're only paying attention to the most important thing and not being spammed a bunch of things that are just 99% yes."* ## [08:10] Securing auto mode: red teaming and evals Shipping auto mode required building trust before it reached users. Cat describes the process: collecting thousands of full agent trajectories alongside permission prompts, having the auto mode classifier label each one, confirming it was "extremely good," then bringing in red teamers to attempt prompt injection attacks against the codebase. Every successful attack became an eval. Internal teams ran their own injection attempts to surface further gaps. The result is a model hardened not just against known attacks but against the most sophisticated adversarial constructions the team could devise. > *"It's not only just protecting you against the vulnerabilities that are out there in the wild today, but the most intelligent attacks that we can construct."* ## [10:24] Why loop is the next leap Boris frames two platform jumps in 18 months. First: stop writing source code directly — talk to an agent and let it write the code. Second, happening now: stop talking to an agent directly — talk to a loop or routine that prompts Claude Code on your behalf. Both felt obvious in hindsight, but neither was easy to see from inside the engineering mindset he brought to the project. > *"I don't talk to an agent anymore. I talk to a loop or I talk to a routine and it prompts Claude for me, and it's just crazy."* ## [11:06] How engineering orgs and responsibilities are changing Boris anchors the current transition to a 1990s Harvard Business Review piece asking why companies weren't seeing productivity gains from personal computers — and answering that computers needed to be at the center of every business process, not a side appliance next to the paper filing cabinet. At Anthropic, new hires don't ask colleagues questions; they ask Claude Code. Companies figuring out AI fastest are the ones putting it at the center of operations. Cat notes that the computer transition took 10–15 years; AI is compressing that because work is already digitized and Claude Code can both write and run code. > *"What you have to do is you throw out the filing cabinet. You have to throw out all your paper and all your pens and then you put a computer in the center and everything has to run through the computer."* ## [13:30] Is the future product or engineering? Boris' answer: both roles are merging into one. The Claude Code product team all writes code, the devrel team all writes code, designers write code, and engineers now ship products end-to-end — scoping the idea, building it, working with legal, marketing, and security to take it to market. The beneficiaries right now are people with high curiosity, strong product taste, and an appetite for end-to-end ownership. > *"AI really benefits people who have a lot of curiosity, have a lot of product taste, who love to have this end-to-end ownership."* ## [14:20] Working with hundreds of agents: using agent view, voice mode, and Remote Control Boris's multi-agent setup a few months ago: six terminal tabs, six git checkouts, manual context-switching. Today: one tab, the new agent view, and the desktop app handling work-tree cloning automatically. The unexpected change: roughly half his engineering now happens on his phone via Remote Control. He starts a task at his desk, walks to get coffee, checks in from his phone, starts new agents on the spot, and dictates to them via voice mode. Cat recalls noticing that Boris's laptop sat untouched on his desk for two consecutive days while he was actively merging PRs — he confirmed he was coding from his couch. > *"I'll like get coffee and then I'll check in on my agents and maybe I'll start another agent. And sometimes I'm talking to someone and we come up with a new idea — I'll just start an agent on the spot."* ## [16:05] From context engineering to context minimalism Boris traces the prompt engineering arc: Sonnet 3.5 required heavy prompt engineering; Opus 4 required careful context engineering; today's models need neither. The prescription now: give the model the minimal system prompt, the minimal tool set, and a way to pull in whatever context it actually needs — then let it work. Cat calls herself a "context minimalist": tell the model only what it needs to know, because too much upfront context is micromanagement, and the model often knows a better path anyway. > *"You give it the minimal possible system prompt, the minimal possible tools, and then you let the model figure it out."* ## [17:17] What's next for Claude Code Boris refuses to predict the specific form factor, only the direction: agents running longer, more autonomously, in parallel batches of dozens to thousands rather than one at a time. The exact interface for coordinating that many agents will be "really different than what came before" and won't come from Boris or Cat — it will come from the team and the broader community building with Claude Code every day. > *"In a year it's going to be a totally new set of things and it's going to be so surprising if it's still these same things."* ## Entities - **Boris Cherny** (Person): Head of Claude Code at Anthropic, creator of the tool; one of two interview subjects. - **Cat Wu** (Person): Head of Product, Claude Code at Anthropic; one of two interview subjects. - **Claude Code** (Software): Agentic coding tool developed at Anthropic, runs in the terminal; primary subject of the episode. - **Auto mode** (Concept): Claude Code permission model that routes tool-call decisions to a classifier instead of prompting the user for every action; replaces the earlier per-prompt approval flow. - **Loop / Routines** (Concept): Automated agents triggered by events (e.g., new GitHub issue, unresponded bug report) that prompt Claude Code without human initiation; described as the second major platform leap. - **Context minimalism** (Concept): Philosophy of providing models only the necessary system prompt and tools, letting the model pull additional context as needed rather than front-loading everything. - **Anthropic** (Organization): AI safety company that develops Claude and Claude Code. - **Remote Control** (Software): Claude Code feature enabling users to manage running agents from a mobile device. - **Agent view** (Software): New Claude Code interface for managing multiple parallel agents from a single pane.

Isabella He, ingénieure Applied AI chez Anthropic, consacre 37 minutes à construire en direct un agent SRE de gestion d'incidents — partant d'un fichier `agent.py` vide pour aboutir à une application Streamlit qui diffuse les appels d'outils, maintient les sessions et diagnostique un pic de latence P99. La session associe un primer d'architecture de cinq minutes à du code pratique, permettant aux participants de repartir avec un agent fonctionnel et les bases conceptuelles pour l'étendre vers des sous-agents, la mémoire et les vaults. ## [00:19] Bienvenue et programme Isabella commence par situer l'équipe Applied AI au sein d'Anthropic — "à l'intersection des produits, de la recherche et de nos clients" — et présente les trois temps de la session : une mise à jour rapide de la plateforme, un sprint de codage pratique, puis un aperçu des fonctionnalités avancées comme le dreaming et les sous-agents. Le scénario de départ est le réveil à 3h du matin que redoute tout ingénieur logiciel, problème qu'un agent SRE construit sur Managed Agents prendra en charge de manière autonome. > *"Mon objectif aujourd'hui est de vous amener à construire concrètement sur Managed Agents, à comprendre comment le harness fonctionne sous le capot, et à vous préparer à déployer votre premier agent de gestion d'incidents."* ## [02:10] De l'API Messages aux Managed Agents Isabella retrace la genèse du produit : l'API Messages de 2023 donnait un accès brut aux tokens mais laissait aux développeurs la charge d'implémenter la gestion du contexte, les boucles d'agents et la compaction. L'Agent SDK a ajouté l'accès au système de fichiers de Claude Code, tout en exigeant encore un hébergement géré par le développeur. Managed Agents est la troisième génération — Anthropic prend en charge la scalabilité, le sandboxing, l'observabilité et le runtime des outils, permettant aux équipes de déployer "dix à quinze fois plus vite en production." Elle illustre concrètement le coût de maintenance avec un exemple réel : Sonnet 4.5 présentait une "context anxiety" entraînant une fin de tâche prématurée. Anthropic a corrigé le harness ; Opus 4.5 a entièrement éliminé ce comportement, rendant ces correctifs obsolètes. > *"Les harnesses doivent évoluer en même temps que vos agents — c'est pourquoi avec Claude Managed Agents, nous voulons qu'Anthropic gère toutes les complexités liées à la compaction, au caching et à la context anxiety."* ## [05:55] Primitives fondamentales : Agent, Environnement, Session Trois objets composent toute application Managed Agents. L'**Agent** porte la persona — choix du modèle, prompt système, serveurs MCP, skills. L'**Environnement** est le conteneur d'exécution, analogue aux "mains" face au "cerveau" de l'agent, et supporte à la fois le cloud géré par Anthropic et le bring-your-own-compute depuis la veille de la session. Une **Session** lie les deux et monte les fichiers de données ; les événements (messages utilisateur, appels d'outils, réponses) sont diffusés en continu vers les appelants plutôt que renvoyés en une seule réponse. Découpler la boucle d'agent de l'exécution des outils a réduit le temps-jusqu'au-premier-token P95 de plus de 90%, tout en éliminant l'exposition des credentials via la frontière du conteneur sandboxé. > *"Grâce à ce découplage, nos équipes ont constaté des réductions du temps jusqu'au premier token de l'ordre de plus de 90% sur nos métriques P95 de latence."* ## [09:15] Mise en place de l'atelier Les participants clonent le dépôt de l'atelier et font `cd` dans `ship-your-first-managed-agent`, créent un environnement virtuel, installent les dépendances et collent une clé API Anthropic dans `.env` avant de lancer `streamlit run app.py`. Isabella confirme que l'URL Streamlit affiche bien une interface de chat de gestion d'incidents — le canvas vierge pour la construction. > *"N'hésitez pas à faire cela au fur et à mesure ou même plus tard dans la journée — tout sera également affiché à l'écran pour suivre avec nous."* ## [10:48] Construction de l'agent étape par étape En travaillant avec `agent.py` (incomplet) ouvert à côté de `agent_complete.py`, Isabella copie six blocs de code un par un : 1. **Définition de l'agent** — `SRE_AGENT` utilisant Claude Opus 4.7, un prompt système minimal nommant le rôle de l'agent et les outils disponibles (get_metrics, get_recent_deploys, get_diff, fetch_logs). 2. **Environnement** — environnement cloud Anthropic avec réseau non restreint pour la démo ; les variantes de production peuvent se limiter à une liste d'autorisations ou passer par les tunnels MCP de Claude. 3. **Upload des logs** — attache un fichier de log via l'API Files pour que l'agent puisse exécuter du code dessus ; Isabella signale que l'ingénierie du contexte est là où les développeurs passent le plus de temps d'itération. 4. **Création de session** — transmet `agent_id`, `environment_id` et les références des ressources uploadées pour tout lier ensemble. 5. **Streaming d'événements** — reçoit des événements (pas des tokens bruts) de la session, permettant l'affichage en temps réel et la journalisation d'observabilité. 6. **Outils locaux + suppression de session** — enregistre `get_metrics`, `get_recent_deploys` et `get_diff` comme gestionnaires exécutés localement, puis ajoute un appel de suppression de session avec la précision que les sessions supprimées sont entièrement purgées des logs. > *"La pièce manquante ici est simplement de lui donner enfin nos outils locaux pour que l'agent puisse commencer à agir sur mon ordinateur ou mon infrastructure."* ## [19:43] Exécution de l'agent et démo en direct Isabella lance une nouvelle session avec le prompt "débogue mon incident pour moi." L'agent appelle `sandbox_bash`, `get_recent_deploys` et `get_diff` en séquence, diffuse chaque appel d'outil et chaque token de réponse vers l'interface, puis retourne un rapport d'incident structuré : le pic de latence P99 (10x la ligne de base) est attribué à un épuisement du pool de connexions à la base de données introduit par le commit `refactor_order_summary_builder` d'Alice. Elle note qu'une variante de production ajouterait l'accès à Claude Code pour suggérer un correctif, ouvrir une PR et boucler la boucle sans humain dans le chemin critique. Un rafraîchissement forcé du navigateur confirme la persistance de session — toutes les sessions précédentes réapparaissent depuis l'état cloud, sans base de données locale requise. > *"Vous pouvez voir ici qu'en faisant défiler tous les appels d'outils, tout est persisté dans le cloud du point de vue des logs. Tout cela sera également journalisé dans la console d'observabilité."* ## [27:18] Récapitulatif de l'architecture, fonctionnalités avancées et Q&R Isabella récapitule l'architecture orientée événements : les sessions s'expriment en événements, pas en paires requête-réponse ; le journal d'événements permet à Managed Agents de reprendre une session après un redémarrage de conteneur sans rejouer la boucle d'agent. Elle présente ensuite quatre capacités avancées : - **Sous-agents** — un orchestrateur crée des agents enfants avec leurs propres fenêtres de contexte pour le parallélisme et la gestion du budget de contexte. - **Mémoire / Dreaming** — l'agent passe en revue ses propres logs de session pour décider ce qu'il doit retenir, permettant l'auto-amélioration et le rappel des préférences entre les sessions. - **Outcomes** — les développeurs définissent un critère ; l'agent détermine quels appels d'outils produisent le résultat souhaité. - **Vaults** — credentials chiffrés entre un endpoint séparé et le conteneur de l'agent, par utilisateur et par session, s'appuyant sur la séparation cerveau/mains intégrée à l'architecture. Elle conclut en orientant les participants vers la session de suivi sur le "dreaming" et le tableau de bord d'observabilité intégré à la console Managed Agents. > *"J'espère que tout le monde repart avec une idée de comment Managed Agents fonctionne réellement sous le capot — et soyez fiers de vous, ceux qui ont réussi à déployer un agent de fiabilité de site."* ## Entités - **Isabella He** (Personne) : Member of Technical Staff, équipe Applied AI d'Anthropic ; présentatrice et animatrice de l'atelier - **Claude Managed Agents** (Logiciel) : infrastructure managée d'Anthropic pour les agents prêts pour la production ; gère la scalabilité, le sandboxing, l'observabilité et le runtime des outils - **Agent SDK** (Logiciel) : ancien harness Anthropic offrant l'accès à Claude Code ; nécessitait un hébergement géré par le développeur - **Claude Opus 4.7** (Logiciel) : modèle utilisé pour l'agent SRE dans la démo de l'atelier - **Sonnet 4.5** (Logiciel) : ancien modèle présentant une "context anxiety" (fin de tâche prématurée), utilisé pour illustrer pourquoi les harnesses doivent évoluer avec les modèles - **Files API** (Logiciel) : API Anthropic pour uploader des fichiers (logs, métriques) dans le contexte d'un agent - **Dreaming** (Concept) : fonctionnalité Managed Agents où l'agent passe en revue de manière asynchrone son historique de session pour mettre à jour sa mémoire à long terme - **Outcomes** (Concept) : spécification d'objectifs basée sur des critères dans Managed Agents ; l'agent sélectionne les appels d'outils pour atteindre un résultat défini plutôt que de suivre des étapes explicites - **Vaults** (Concept) : espace de stockage chiffré pour les credentials dans Managed Agents ; découplé du conteneur de l'agent via l'architecture de séparation cerveau/mains - **MCP tunnels** (Concept) : fonctionnalité Claude pour router le trafic des serveurs MCP via un réseau privé plutôt qu'internet public - **Context anxiety** (Concept) : comportement observé de Sonnet 4.5 consistant à terminer les tâches prématurément malgré un budget de contexte disponible ; résolu dans Opus 4.5 - **Anthropic** (Organisation) : entreprise de sécurité en IA ; créatrice de Claude et de la plateforme Managed Agents - **DataDog** (Logiciel) : plateforme de monitoring de production citée comme remplacement direct de l'outil de métriques JSON de la démo - **Streamlit** (Logiciel) : framework UI Python utilisé pour construire l'interface de chat de gestion d'incidents de l'atelier

Tushara Fernando, Head of Data and AI at Man Group, explains how the firm integrates AI into systematic trading by codifying decades of institutional knowledge into "skills." She emphasizes that robust governance and shared workflows are essential for moving AI from individual productivity tools to enterprise-scale agentic platforms. ## [00:18] AI in Systematic Trading Man Group manages over $200 billion in assets, making the stakes for AI implementation exceptionally high for their institutional clients. Tushara Fernando describes systematic trading as an algorithmic process that uses historical backtesting to evaluate investment signals, much like managing a fantasy football team. > *A trading signal is really just this with stocks... We want to back the ones that would make money and we want to short the ones that won't.* > *[2, 43]* ## [04:38] The Role of AI-Generated Signals Man Group currently runs trading signals in production that were entirely researched, backtested, and proposed by AI. While humans review the final output for sensibility, AI handles the data acquisition, strategy proposal, and productionization of these investment ideas. > *There are trading signals running right now in production at Mang Group... that were researched, back tested and proposed by AI.* > *[4, 38]* ## [05:52] The Importance of Shared Workflows The success of a trading signal depends on the underlying workflows, such as data cleaning and outlier detection, which Fernando compares to the submerged part of an iceberg. Without shared workflows, different teams produce inconsistent results, making it impossible to compare the effectiveness of various strategies. > *If different teams are running different versions of those workflows, you get different answers.* > *[6, 50]* ## [08:43] Lessons in Skills Governance Early attempts at AI adoption failed because power users, rather than process owners, were building "skills," leading to local optimizations and errors like hardcoded cost centers. To solve this, Man Group created a governed marketplace where skills are owned by workflow owners, tested with evaluations, and tracked for usage. > *Treat those skills like production code because that's what they will become.* > *[17, 21]* ## [16:40] Scaling AI Across the Enterprise Man Group has scaled AI usage to nearly half its workforce by focusing on organizational context as a competitive moat. By treating skills as a library of institutional knowledge, the firm is preparing for a future where swarms of agents leverage these capabilities to find new investment opportunities. > *Skills governance really unlocks AI at that enterprise scale.* > *[19, 21]* ## Entities - **Tushara Fernando** (person): Head of Data and AI at Man Group. - **Man Group** (organization): An alternative investment manager with over $200 billion of assets under management. - **Claude** (product): An AI model used by Man Group for research, backtesting, and workflow automation. - **Anthropic** (organization): The AI company that assisted Man Group with skills workshops and implementation. - **Systematic Trading** (concept): Algorithmic trading capabilities that look across thousands of securities and hundreds of markets. - **Backtesting** (process): The process of running a trading strategy against historical data to evaluate its performance. - **Sharpe Ratio** (metric): A statistical factor that compares the volatility of a strategy versus its returns. - **Skills Marketplace** (product): Man Group's internal library for governed AI skills, plugins, and institutional knowledge.

This session introduces Claude Managed Agents, a suite of API endpoints designed to help developers build and deploy production-ready AI agents with built-in tools, security, and observability. The speaker outlines how core primitives like Agents, Environments, and Sessions enable complex workflows such as multi-agent coordination and human-in-the-loop controls. ## [00:00] Introduction to Managed Agent Primitives Anthropic introduces Claude Managed Agents as a suite of API endpoints providing production-ready primitives like tool calling, error recovery, and memory management. The architecture relies on 'Agents' as templates for skills, 'Environments' for sandboxed execution with granular permissions, and 'Sessions' to maintain ongoing conversational context and state transitions. > *Claude Managed Agents at a high level is just a set of API endpoints that we've developed and released... that give you access to scaled ready, production ready agent. [01:35]* ## [07:54] Secure Connectivity and Sandboxing The platform supports self-hosted sandboxes, allowing developers to use private containers and VPCs to keep sensitive data secure while maintaining model access. Additionally, new MCP tunnels facilitate safe connections to internal Model Context Protocol servers, and Credential Vaults protect authentication tokens by keeping them out of the model's context window. > *Claude can directly connect to that safely without those MCP servers ever being exposed on the internet. [09:40]* ## [10:02] Multi-Agent Orchestration and Implementation A demonstration of a multi-agent architecture shows a coordinator agent spawning specialized sub-agents for complex tasks like financial analysis and macro trend research. Developers can implement these workflows using the Anthropic SDK and tools like Claude Code, which is specifically optimized to help developers implement and iterate on managed agent APIs. > *One agent is like in charge of figuring out macro trends... whereas another one is like really good at like financial analysis. [11:36]* ## [19:28] Observability, Memory, and Infrastructure The Claude Console provides robust observability, including agent versioning, session monitoring, and the ability to edit memory stores to correct agent context. By providing integrated state transitions and durable storage out of the box, the service eliminates the need for developers to build complex custom agent loops and sandboxing fleets manually. > *With cloud manage agents, we kind of were able to get all of these things out of the box. [26:54]* ## Entities - **Anthropic** (organization): The AI research and safety company that developed the Claude model family. - **Claude Managed Agents** (software): A suite of API endpoints for building and hosting production-ready AI agents. - **MCP** (protocol): Model Context Protocol used for secure authentication and tool integration. - **Claude Code** (software): A developer tool optimized for implementing and managing Anthropic APIs. - **Bun** (software): A fast JavaScript runtime used for the technical implementation demonstrations. - **Cloudflare** (infrastructure): A cloud provider mentioned as a host for private sandboxes and environments. - **Credential Vaults** (feature): A secure storage system for authentication tokens that prevents exposure to the model. - **Memory Stores** (feature): Persistent storage allowing agents to retain and retrieve information across sessions.

Anthropic engineers Michael and Harrison introduce Claude Managed Agents, a platform designed to simplify the infrastructure, security, and observability required for deploying autonomous AI agents. By handling complex backend tasks like sandboxing and identity management, the system enables developers to transition from simple tool use to long-running, outcome-oriented agentic workflows. ## [01:10] The Evolution of Agentic Infrastructure Michael and Harrison trace the progression of AI from basic function calling to autonomous agents capable of managing full feature development and PRs. They argue that infrastructure, rather than model intelligence, is now the primary bottleneck for achieving productivity where months of work are completed in hours. > *where we think we're seeing things going in the future is entire quarters worth of work being able to be getting accomplished within a couple of hours.* > *[2, 34]* ## [04:22] Core Primitives and Configuration The platform provides composable primitives for context management, observability, and secure sandboxing, allowing developers to define agents via system prompts and MCP tool configurations. Features like the 'Ask Claude' button and event streams provide real-time transparency and optimization suggestions for agent sessions. > *we did all of that platform work so that you don't have to so that you can kind of pick and choose the primitives that we have available.* > *[5, 26]* ## [10:05] Advanced Orchestration and Memory Beyond single-task execution, the platform supports multi-agent orchestration where Claude can spawn sub-agents to delegate work. Advanced features like 'Dreaming' allow agents to reflect across thousands of sessions, improving long-term memory and task performance through autonomous reflection. > *It allows Claude to spawn other agent threads with their own context windows in order to delegate work to them.* > *[10, 55]* ## [11:56] Sandboxing and Secure Connectivity Anthropic offers self-hosted sandboxes and MCP tunnels to give enterprises control over network policies and audit logs while exposing private data securely. Partners like Vercel, Modal, and Cloudflare provide specialized infrastructure, ranging from lightweight isolates for rapid scaling to high-performance GPU clusters. > *MCP tunnels are basically just a way for you to get your private MCPs in your network exposed to cloud manage agents.* > *[13, 25]* ## [20:19] Real-World Automation and Optimization Companies like DoorDash and Modal are using agents for complex technical tasks, such as autonomous account management and inference tuning. By running tools like the Nvidia profiler, agents can autonomously 'hill climb' performance benchmarks to optimize workloads without human intervention. > *Claude can optimize training loops... it'll run like the Nvidia profiler. It'll read the profiles and uh it'll just go ham and and make things better.* > *[20, 39]* ## [25:23] Future Challenges: Identity and Collaboration As agents become primary users of compute, the industry faces new hurdles in identity management, egress filtering, and task resumability. The future of AI involves moving from rigid execution to collaborative 'multiplayer' environments where agents and humans dynamically pivot based on feedback. > *how do we properly assign identity all the way down the chain such that it's only getting access to the right data* > *[25, 55]* ## Entities - **Anthropic** (organization): The AI safety and research company behind the Claude model family. - **Claude Managed Agents** (product): A platform and infrastructure suite for building and deploying autonomous AI agents. - **Michael** (person): Member of Technical Staff at Anthropic working on managed agents. - **Harrison** (person): Member of Technical Staff at Anthropic working on managed agents. - **MCP** (protocol): Model Context Protocol used for tool configuration and secure tunnels. - **Cloudflare** (organization): A cloud services provider focusing on sandboxing technologies like MicroVMs and isolates. - **Modal** (organization): A compute platform specializing in high-scale GPU sandboxes and AI workloads. - **Vercel** (organization): A partner providing fluid compute infrastructure for agent sandboxes.

Chris Merrick, CTO of Omni, details the development of 'Blobby,' an agentic analytics harness powered by Anthropic's Claude models. By combining a robust semantic layer with internal dogfooding of Claude Code, Omni enables users to translate natural language into complex data visualizations while maintaining high engineering velocity. ## [00:07] Engineering Velocity with Claude Code Chris Merrick explains how Claude Code has transformed Omni's internal development, allowing a small team of 25 to maintain high commit velocity. Even as CTO, Merrick uses the tool to stay technically involved, leveraging the efficiency of the Claude Opus model to contribute code alongside his team. > *I thank Claude very much for making me uh still able to do some software engineering from time to time. [01:12]* ## [03:14] The Semantic Layer and Business Context To bridge the gap between general LLM knowledge and specific business data, Omni utilizes a semantic layer that provides essential context like fiscal definitions and table relationships. This layer acts as a permissions and curation tool, ensuring the AI agent understands the unique nuances of a company's data environment. > *Claude is incredible at answering questions, but you need to tell it more about your business if you want it to answer questions about your business. [04:03]* ## [11:15] Architectural Evolution and the 'Blabbotomy' The team evolved their AI agent, Blobby, from a simple Q&A tool into a sophisticated harness by upgrading from Claude Haiku to Sonnet for better multi-turn performance. They addressed 'split-brain' errors—where sub-agents and outer agents failed to communicate—by consolidating all tools into a single, unified agentic brain. > *You want to be careful not to have a split brain between any sort of sub agent system and outer agent system. [15:57]* ## [16:23] Leveraging SQL and CTE Proficiency Omni shifted its query strategy from a proprietary JSON format to standard SQL to better leverage Claude’s inherent proficiency with complex Common Table Expressions (CTEs). This transition allowed the agent to handle difficult data questions in a single pass, significantly improving the accuracy of generated reports. > *Claude really likes to write SQL with CTE, common table expressions... and our parser was really good at parsing those [18:27]* ## [19:09] Evals, Observability, and UI Validation Merrick emphasizes that rigorous evaluation systems and raw trace observability are critical for ensuring the predictability required by executive users. Omni follows a 'build with AI, validate with UI' philosophy, where Blobby generates the initial dashboard and users use a workbook interface to refine and troubleshoot the results. > *Our philosophy from a product perspective is AI to build, UI to sort of validate and troubleshoot and refine. [23:21]* ## Entities - **Chris Merrick** (person): CTO and Co-founder of Omni who leads the engineering team and advocates for AI-driven development. - **Omni** (organization): An AI analytics platform that enables users to query data using natural language. - **Claude** (ai-model): The family of LLMs from Anthropic that powers Omni's analytics and internal engineering. - **Claude Code** (software): An AI-powered coding tool that significantly increased Omni's development velocity. - **Blobby** (ai-agent): Omni's AI data analyst agent designed to interpret and answer complex data questions. - **SQL** (technology): The query language that Omni's semantic layer generates to interact with data warehouses. - **Claude Sonnet** (ai-model): The specific Anthropic model used to unlock performance gains in complex agentic conversations. - **GitHub** (platform): The source of pull request (PR) data used in the agent's demonstration.

Sid Budhiraja, a founding engineer of Claude Code, gave this keynote at Anthropic's Code with Claude conference to address a specific waste pattern: engineers spending most of their time staring at a screen waiting for Claude to finish, or acting as a "glorified QA tester." The talk lays out three escalating strategies—verification, parallelization, and background loops—that together let Claude run largely unsupervised. No captions existed on YouTube; transcript generated via Gemini Flash transcription (paragraph-level only, no word timestamps). ## [00:02] Opening & prerequisites Sid frames the talk as a "Claude Code 301" class and opens with a quick audience poll. Three things he calls table stakes: a high-quality CLAUDE.md file ("the single highest leverage thing you can do"), connecting external tools like Slack, Linear, and BigQuery to Claude Code so it can stitch together richer context, and setting up Claude Code on the web so that sessions are decoupled from the engineer's laptop and keep running even when the machine is closed or offline. He then lays out the structure for the rest of the talk: verification, multi-Clauding, and background loops—each building on the previous one. > *"A good rule of thumb is that if a tool is useful for you in your day-to-day life, it will also be useful for Claude. So things like Slack, Asana, Linear, Datadog, BigQuery—all of these things help Claude stitch together a much richer context for itself."* ## [05:14] Teaching Claude to verify its own work Sid asks the audience to recall how they personally verified their last feature: write code, build, run, check side effects, check logs, check the database, run unit tests, deploy to staging. That exact playbook, he argues, is also what Claude can run—if given the right tools and instructions. The key mechanism is the **loop**: an autonomous circuit where Claude writes code, hits a failure, debugs, writes more code, and keeps cycling until it reaches a success state. Once in a loop, Claude hill-climbs on a task without the engineer in the hot path. The loop works across front-end (browser-driven smoke tests), back-end (API checks), and full end-to-end flows—the principle is identical in each case. To package and distribute a verification loop, Sid recommends a **skill file**—a markdown document that stores the instructions and tool configuration for a specific verification task. Skills can be made self-improving: if you instruct Claude to update the skill every time it hits a new blocker, the document grows into a self-documenting playbook that benefits the whole team. > *"A loop essentially is an autonomous circuit that you can complete for Claude. And it allows Claude to hill climb on a given task or a given success criteria."* ## [15:46] Demo: building a verification loop live Sid demos against MonkeyType, an open-source TypeScript/Express/MongoDB/Redis typing-test application, chosen because it represents a realistic full-stack production app. Starting from a fresh Claude Code session, he tells Claude to spin up the dev server, then instructs it to use the `/chrome` Chrome MCP tool to navigate to localhost, type some text, and change a settings value—manually walking it through a basic smoke test. Once that hand-held session is complete, he tells Claude to take everything it just learned and write it into a skill file at `.claude/demo-verification`. Claude produces a skill with three sections: bring up the stack, load Chrome MCP tools, run a smoke test. He then asks Claude to build a new feature—a confetti animation on every mistype—and use the newly created verification skill to verify its own work. Claude writes the feature, hits ESLint errors, fixes them, reloads the app, and keeps cycling until the confetti appears. > *"You see the verification loop in action now where it's—it wrote some code, it encountered some issues, it fixed those issues by writing some more code, and it kind of went in a circle doing that until it came to a good state."* ## [26:38] Multi-Clauding without losing your mind Running multiple Claude instances simultaneously taxes attention, Sid's personal limit being four or five sessions before cognitive load becomes unmanageable. He covers four tools for scaling past that ceiling. The **Claude Code Desktop app** provides a unified sidebar showing all sessions across local terminal, cloud, and GitHub—sessions sorted by attention demand, color-coded, renamable. The terminal alternative is **Claude Agents** (`claude agents`), released roughly a week before the talk, which surfaces the same session list inside the terminal and sorts by urgency so the sessions that need a decision bubble to the top. **Claude Code on the Web** (claude.ai/code) runs sessions in Anthropic's cloud, fully decoupled from the engineer's hardware. And **Remote Control** (`/remote-control`) mirrors any running session to the mobile app with push notifications, so the engineer can answer Claude's questions from a car or between meetings without opening a laptop. > *"Remote Control essentially gives you the option to control any session running on any surface with your phone. If Claude needs some help from you or needs your input, your phone will buzz and you could be in your car, doing whatever you want, and you could just give Claude the input that it needs."* ## [32:41] Background loops and routines Even with good multi-session tooling, the engineer still decides when to start each session and what goal to give it. Background loops remove that last manual step. Sid describes the `/loop` command: `/loop 10 minutes "babysit my open PRs"` wakes up a Claude Code session every ten minutes, runs that prompt autonomously, and handles review comments, merge conflicts, and CI failures without the engineer watching. **Routines** are `/loop` running in Anthropic's cloud infrastructure—the same remote containers that power Claude Code on the Web. The Claude Code team itself runs two routines: one that updates docs daily, and one that scans issues and feedback and posts a summary to their Slack channel every six hours. With verification ensuring Claude's output is reliable, multi-Claude tools protecting attention across parallel sessions, and routines handling recurring bookkeeping, the engineer's role shifts from babysitter to delegator. > *"You can kind of spend your attention and your time on the tasks that you care about, and everything else can just be delegated to Claude—with high reliability and a high degree of confidence."* ## Entities - **Sid Budhiraja** (Person): Founding engineer of Claude Code at Anthropic; presenter of this keynote. - **Anthropic** (Organization): Creator of Claude and Claude Code; hosted the Code with Claude conference. - **Claude Code** (Software): Anthropic's agentic coding tool; central subject of the talk. - **Verification loop** (Concept): An autonomous write-check-fix cycle that lets Claude iterate on a task until it reaches a defined success state without human intervention. - **MonkeyType** (Software): Open-source TypeScript typing-test app (Express + MongoDB + Redis) used as the live demo target. - **Chrome MCP** (Software): Model Context Protocol tool (accessed via `/chrome`) that gives Claude programmatic control of a browser for UI verification. - **Routines** (Concept): Cloud-side scheduled Claude Code sessions with time-based or event-based triggers, enabling fully autonomous recurring tasks. - **Remote Control** (Concept): Feature (`/remote-control`) that mirrors Claude Code sessions to the mobile app with push notifications, enabling async oversight from anywhere.

Fabian Hedin, Cofounder and CTO of Lovable, walked through two production systems his team built to stop non-technical users from getting permanently blocked: Lovable Overflow, a self-maintaining corpus of issue-solution pairs injected into the agent's context at inference time, and a "vent" tool that lets the agent itself flag platform failures and auto-open PRs for engineers to review. Together they cut the platform's stuck rate by 5% — an improvement on par with a full model generation upgrade — and now drive roughly ten merged fixes per day from agent-filed pull requests. ## [00:20] From GPT-Engineer to 600 million monthly visits Lovable's lineage traces back 35 months to GPT-Engineer, a terminal program co-founded by Anton that briefly became the fastest-growing repository on GitHub. The demo — asking for a snake game, watching the model generate and execute the code end-to-end — signaled what LLMs could do for software creation, but the abstraction wasn't ready for a non-developer audience in mid-2023. Fabian marks a turning point around eighteen months ago when the chat-plus-preview model started clicking, and every three months since then a new foundational model has pushed the envelope further. Today the platform hosts 15 million projects. More telling: the sites built on Lovable collectively receive 600 million monthly visits, far more than Lovable's own traffic — evidence that users are shipping things with real reach. > *"We have 15 million projects built on the platform. We have 600 million monthly visits to the sites built on Lovable. And I think this is an interesting statistic because it's significantly more than what Lovable has itself."* ## [04:22] Production software for the 99%: why non-technical users get stuck Lovable targets the 99% of people who can't code — and deliberately holds itself to production-grade quality, not just prototyping. That combination makes the job harder than building for expert developers. When an expert gets stuck they can read the error, switch the library, or escalate to a developer-experience team. A non-technical user working at Lovable's abstraction layer — where the code is mostly out of sight — has none of those escape hatches. Fabian applies the classic software maxim: the first 90% of code takes 90% of the time, and the last 10% takes another 90%. The pattern holds in the AI era: vibe-coding gets you to a first version fast, but finishing, bug-free, takes even longer. Getting "hard stuck" in that final stretch is the worst possible user experience Lovable can deliver. > *"If they get stuck, it's a very bad experience for them. It's kind of the worst thing that can happen to them because it's much harder for them to get unstuck."* ## [09:55] Defining stuck: the is_stuck metric and three failure buckets Lovable's `is_stuck` flag fires when a user asks for the same thing three times in a row, when they explicitly complain about the output, or when they prompt and then abandon the session. A small classification model evaluates each conversation to set this signal. The team maps stuck scenarios into three buckets. The first is promptable — a differently-worded message, or slightly more context, would have solved it; Lovable's goal is to fix these before the user even realizes they need to re-prompt. The second is a platform gap: something the agent should handle but a missing or broken tool prevents it. The third is a large infrastructure investment — for example, Lovable shipped only client-side-rendered SPAs for a long time, which hurt SEO-conscious builders; they shipped server-side rendering the week of this talk. Each bucket demands a different fix, but all three share the same core vision. > *"Really our vision with Lovable on the technical side is that every app that is built on the platform should help improve the next."* ## [13:15] Lovable Overflow: fleet knowledge that routes around errors Named in honor of Stack Overflow, Lovable Overflow is a growing corpus of problem descriptions paired with solutions, harvested from real user sessions. When a user reports laggy scrolling, a lightweight retrieval model searches the corpus for similar descriptions, and if a match is relevant it injects a synthesized fix into the main agent's context — not as raw text but reformatted to fit the current situation. The harder engineering problem is keeping the corpus honest. Knowledge grows stale when a JavaScript package ships a fix, or when a new foundational model already has the fix baked into its weights. Lovable tracks a success ratio for every entry and prunes records that stop working — including entries whose embedded knowledge is now redundant in a newer model. The tension between adding new knowledge and retiring old knowledge turned out to be as important as the retrieval mechanism itself. > *"For every knowledge file we'll track its success ratio and we'll actually just remove it and prune it from the knowledge if it is outdated. So we'll continuously review every piece of knowledge in our system and make sure that it's pruned when it's no longer helpful."* ## [17:45] Venting: letting the agent report its own frustrations The second self-healing mechanism inverts the feedback loop: instead of Lovable engineers watching for failures, the Lovable agent itself files a report when it's blocked. A tool called `vent--send_feedback` is in the agent's toolset with a prompt asking it to call the tool "once per user message when tooling, docs, or platform behavior materially slows or degrades your work." The agent's complaint lands in a Slack channel, a monitor agent de-dupes and investigates, and if the issue is real, it opens a pull request for an engineer to review. About 50% of the auto-generated PRs make sense and get merged. One example: the agent hit a space-in-filename bug in the `code--copy` tool, tried URL encoding and other workarounds, then vented — and a fix was in production ten minutes later. A second example went further: the Lovable agent complained about Framer Motion's TypeScript easing types, implying the open-source library itself could benefit from a PR. Fabian floated the idea of letting the agent contribute fixes upstream to the wider JavaScript ecosystem. The vent channel also became an unexpected early-warning system. Production incidents — inference downtime, missing sandboxes, network-level failures — show up as spikes in vent volume before conventional monitoring alerts fire. In one meta case, the agent vented 43 times in a session, then filed a PR suggesting de-duplication logic to stop spamming its own creators. > *"Several times now this Slack channel with the agent venting has been kind of the first signal for us to identify a production incident. And even if it's not the first signal, it has actually become a very helpful tool for engineers to debug what is going on."* ## [26:12] Results, lessons, and what comes after self-healing Lovable Overflow reduced the stuck rate by 5% and lifted the publish rate by 2% in its first version — before incremental tuning since then. Fabian frames the 5% number in context: that's roughly the improvement Lovable sees when it upgrades to an entirely new model generation. The venting pipeline merges about ten platform fixes per day. Three lessons stood out. First, failure-mode knowledge is model-specific: when a new foundational model ships, existing Lovable Overflow entries need revalidation because some will be redundant and others will need rephrasing for the model's different behavior. Second, knowledge has a half-life — even fixes that were correct become wrong as libraries evolve. Third, an earlier attempt at this system failed not because the idea was bad but because the success signals were too coarse to tune against; 15 million apps and 200,000 new projects per day give Lovable enough signal to make it work now. Beyond these two systems, the team is fine-tuning on fleet data and building out eval coverage to gate every model release. Fabian's closing frame: Lovable users arrive with strong intent to ship real products, and when they leave stuck, that's a failure Lovable owns — the entire self-healing apparatus exists to close that gap. > *"The stuck rate is reduced by 5%. That might not sound like a big number, but in reality that is on the same order of magnitude in what we would see this metric move if we had a new generation of a foundational model in our system."* ## Entities - **Fabian Hedin** (Person): Cofounder and CTO of Lovable; delivered this keynote at Code with Claude 2026 - **Lovable** (Organization): AI software builder for non-technical users; 15M projects, 600M monthly visits to hosted sites - **Claude** (Software): Foundational model powering Lovable's agent at consumer scale - **GPT-Engineer** (Software): Open-source terminal tool co-founded by Anton (Lovable co-founder); became the fastest-growing GitHub repo in 2023 and evolved into Lovable - **Lovable Overflow** (Concept): Fleet-learning knowledge corpus — problem/solution pairs harvested from real sessions, injected into the agent's context, and continuously pruned by success ratio - **Venting / vent--send_feedback** (Concept): Agent-side tool that files platform failure reports to Slack; a monitor agent de-dupes and auto-opens PRs for engineer review - **is_stuck** (Concept): Binary metric that flags when a user has repeated the same request three times, complained about output, or abandoned a session after prompting - **Framer Motion** (Software): TypeScript animation library; cited as an example of an open-source dependency the Lovable agent identified as having a suboptimal type API

Niklas Gustavsson, Spotify's Chief Architect and VP of Engineering, walks through how a 3,000-person engineering org went from 0 to 99% AI tool adoption in months — and what that does to your product development constraints. The talk covers three concrete systems Spotify built: FleetShift for fleet-wide automated migrations, Honk as a background Claude-powered coding agent, and Backstage as the structured environment that makes agents reliable at scale. The central argument is that the same standardization practices that made human teams fast now make agents fast too. ## [00:18] Spotify's AI adoption surge Spotify's adoption of AI coding tools didn't grow gradually — it inflected sharply around the Claude Opus 3.5 release in November 2024. Within months, 99% of engineers used AI tools weekly, 94% reported meaningful productivity gains in the latest internal survey, and PR frequency jumped 76%. Niklas notes he had to update the PR frequency slide while preparing it because the numbers kept rising. The volume shift is also qualitative: by now, the majority of PRs shipped at Spotify are co-authored by an AI agent together with the developer, not written by a human alone. > *"Today more than 99% of our engineers use AI coding tools every week. And in the latest [survey], 94% of our engineers reports that using AI tooling has helped them become more productive."* ## [03:52] FleetShift: automating fleet-wide maintenance before AI Spotify's pre-AI problem was that its production codebase was growing seven times faster than the engineering headcount. That meant engineers spent progressively more time on maintenance — version bumps, API deprecations, security patches — leaving less capacity for new features. The answer was FleetShift, a fleet management system that treats those changes as coordinated mutations across thousands of repositories rather than per-component manual work. By the time AI entered the picture, FleetShift had already automerged 2.5 million maintenance PRs with no human in the loop: automation creates the PR, validates it in CI, and merges it. That infrastructure became the orchestration layer that Honk would later plug into. > *"Today up until today we've now merged two and a half million of those automated maintenance PRs. Work that our developers did not have to do."* ## [07:38] Building Honk — a background coding agent on Claude's Agent SDK Simple rule-based scripts work fine for config changes and dependency bumps, but fall apart on anything involving actual code modifications. Code has, as Niklas puts it, a very wide API surface — there are many ways to call the same method, and when you run a migration script across millions of lines and thousands of repos, you hit every corner case (a phenomenon with a name: Hyrum's Law). That brittleness was the forcing function for Honk. Honk is today a Claude-based coding agent wrapped inside a Kubernetes pod, scheduled by FleetShift, and equipped with CI tools so it can run builds, catch compile errors, and self-correct before opening a PR. A Java version migration that previously took multiple teams months now takes a single engineer three days. > *"Instead of writing these deterministic scripts to do these code modifications, can we use an LLM for this? [...] Out of this came a tool that we now called Honk."* ## [11:34] Honk V2 and multiplayer agent sessions Developers at Spotify quickly figured out how to invoke Honk over Slack — at-mentioning it mid-conversation and getting a PR back. That grassroots pattern pushed the team toward a more interactive product model. Honk V2, released in alpha during Hack Week the day before this talk, adds two layers on top of the original batch-migration use case. The first is integration with Chirp, Spotify's internal agent orchestration layer, which lets developers run many concurrent Honk sessions and coordinate them. The second is multiplayer: shared sessions where multiple developers can give feedback to the same agent instance simultaneously — described as "Google Docs but for Claude." Projects group those sessions into a shared workspace tracking a longer-horizon goal. > *"Basically imagine, uh, Google Docs or something similar, but for Claude."* ## [14:43] Standardization as agent infrastructure Spotify has operated for more than a decade on the principle that fewer technologies means faster execution. Limiting the stack reduces decision fatigue, makes cross-team collaboration easier, and lets engineers go deep on a smaller surface rather than maintaining breadth. That same principle, Niklas argues, directly improves agent performance. The mechanism is empirical: Spotify sees Claude produce noticeably worse outputs in their more fragmented codebases and better outputs where the stack is uniform. Backstage — their developer portal and software catalog — is the enforcement layer. It exposes component ownership, technology radar recommendations, and a "Golden State" spec for each component type. A Soundcheck UI lets teams self-assess compliance. Critically, all of these are also exposed as MCP servers and CLI tools so agents can query them directly. When Honk makes a code change, lint checks give it immediate feedback if it's using an off-radar pattern, and Niklas watches Claude self-correct against those checks in real time. > *"If Claude has a lot of other code to look at and that code looks roughly consistent, Claude will do better job. That's what we're seeing. And we actually have codebases that are more fragmented, and we can actually see Claude perform worse in those codebases."* ## [22:15] What happens when coding stops being the bottleneck The sprint Niklas closes with is a reframing: the AI transition hasn't removed constraints from product development, it has relocated them. Coding used to be where time went; now that constraint is loosening, the bottlenecks are moving to human decision-making — which ideas to pursue, which PRs actually need a human reviewer, which prototypes are worth fleshing out. On the PR review side, 76% more PRs means developers are drowning in review requests. Spotify's response is to auto-approve the low-risk ones and focus human attention where it matters. On the prototyping side, Spotify now lets anyone — including executives — open Claude in the client monorepo with a set of skills and infrastructure, prompt a feature, and get an installable app back in minutes rather than days. The talk ends with Niklas noting that in six months, Spotify's entire product development process will look fundamentally different from anything they've done before. > *"Claude and agents allows us to allow anyone to prototype in our actual production codebase. [...] This has brought prototyping for something that could take days or weeks to literally taking minutes now."* ## Entities - **Niklas Gustavsson** (Person): Chief Architect and VP of Engineering at Spotify; delivered this keynote at Anthropic's Code with Claude conference - **Honk** (Software): Spotify's internal background coding agent, built on Anthropic's Agent SDK running in Kubernetes pods; integrates with FleetShift for fleet-wide migrations - **FleetShift** (Software): Spotify's fleet management and migration orchestration platform; schedules and tracks automated PRs across thousands of repositories; has automerged 2.5 million PRs - **Backstage** (Software): Spotify's open-source developer portal and software catalog; exposes component ownership, Golden State compliance, and MCP/CLI interfaces consumed by agents - **Chirp** (Software): Spotify's internal agent orchestration layer; allows running many concurrent agent sessions and coordinating multi-developer shared sessions - **Hyrum's Law** (Concept): Principle (named after a Google engineer) that any observable behavior of a system will be depended on by some user — explaining why generic migration scripts break at scale across large codebases - **Golden State** (Concept): Spotify's per-component-type specification of recommended technologies and practices; the standard Soundcheck measures compliance against

La deuxième vidéo Claude Code 101 d'Anthropic explique comment rédiger son premier prompt : choisir entre le mode approbation et l'auto-acceptation, basculer en mode plan via shift+tab, et à quoi ressemble un vrai prompt sur une tâche "ajouter le mode sombre" en direct. ## [00:03] Parler à Claude Code comme à n'importe quel assistant IA Le cadrage d'ouverture est volontairement accessible : écrire un prompt à Claude Code n'est pas différent d'interroger n'importe quel assistant IA. L'idée centrale est que les décisions prises avant d'appuyer sur Entrée sont ce qui vous protège et rend l'outil plus agréable à utiliser. > *You talk to Claude Code like you would talk to any AI assistant.* ## [00:15] Mode approbation vs auto-acceptation (shift+tab) Deux modes sont disponibles d'emblée. En mode approbation par défaut, Claude demande une confirmation avant chaque modification de fichier. En mode auto-acceptation, les modifications et créations de fichiers passent automatiquement, mais l'exécution de commandes shell nécessite toujours votre accord. shift+tab bascule entre les deux, sans paramètre à chercher. Le narrateur refuse explicitement de désigner un mode "correct" : choisissez selon le niveau de contrôle souhaité. > *In auto accept mode, it will automatically approve an edit or creation of a file, but ask your permission to run commands.* ## [00:40] Mode plan : recherche en lecture seule avant de coder Un troisième mode se cache dans le même menu shift+tab : le mode plan. Claude prend le prompt, utilise des outils en lecture seule pour parcourir le code, pose des questions sur les points ambigus, et remet un plan détaillé avant de toucher un seul fichier. Cas d'usage : implémentations fonctionnelles multi-étapes et revues de code sécurisées, partout où vous voulez valider l'approche avant que l'agent commence à écrire. > *Plan mode takes your prompt and uses read-only tools to analyze your code base and do research on your suggested implementation.* ## [01:10] Démo live : créer un bouton de mode sombre La démo est le cœur de la vidéo. Depuis la racine du projet, quelques pressions sur shift+tab pour entrer en mode plan, puis un prompt qui fait trois choses à la fois : énonce l'objectif ("mode sombre sur toute l'application"), précise l'interface ("un interrupteur dans le header"), et ajoute une contrainte que Claude doit rechercher ("trouver une couleur de contraste adaptée à mon thème clair existant"). Objectif, interface, contrainte — le modèle implicite d'un bon premier prompt. > *Can you create a toggle switch on the header that allows user to toggle between light mode and dark mode?* ## [01:46] Vérifier ce que Claude a réellement fait Après que Claude a rendu son plan et que l'utilisateur a approuvé, la valeur ajoutée est la traçabilité : on voit explicitement ce que Claude a fait et comment il est parvenu au résultat. Le narrateur inspecte visuellement le mode sombre rendu et valide — la leçon implicite étant que "ça a l'air bien" est une barre de revue acceptable pour du travail UI à faible risque, à condition d'avoir vraiment regardé. > *At the end of all this, we can see explicitly what Claude did and how it came to its conclusion.* ## [02:09] Récapitulatif : soyez descriptif, utilisez le mode plan La règle d'or finale : soyez aussi descriptif que possible dans votre prompt, et utilisez le mode plan quand vous voulez que Claude explore les détails de votre intention avant d'exécuter. Le mode approbation vous maintient dans la boucle étape par étape si c'est votre préférence. > *When using Claude Code, try to be as descriptive as possible with your prompt.* ## Entities - **Anthropic Tutorial Narrator** (Person): Le narrateur officiel d'Anthropic pour la série de tutoriels Claude Code 101. - **Claude Code** (Software): L'assistant de codage agentic en terminal d'Anthropic, sujet de ce guide de rédaction de prompts. - **Approval mode** (Concept): Mode par défaut où Claude Code demande une autorisation avant chaque modification de fichier. - **Auto-accept mode** (Concept): Mode qui approuve automatiquement les modifications et créations de fichiers, mais bloque toujours les commandes shell. - **Plan mode** (Concept): Mode de recherche en lecture seule qui produit un plan détaillé avant d'écrire du code ; activé via shift+tab. - **shift+tab** (Shortcut): Raccourci clavier qui fait défiler les modes approbation, auto-acceptation et plan de Claude Code.

Le deuxième épisode de Claude Code 101 d'Anthropic ouvre le capot : la boucle agentique qui collecte le contexte, prend des actions et vérifie les résultats ; comment la fenêtre de contexte se compacte avant de déborder ; ce que les outils apportent concrètement par rapport au texte en entrée et en sortie ; et les quatre modes de permission que l'on bascule avec shift+tab. ## [00:04] Question d'ouverture : en quoi diffère-t-il d'une application de chat Le narrateur structure l'ensemble de la vidéo autour d'une seule question : Claude Code n'est pas une application de chat, alors quelle est la forme de la chose ? La réponse qu'ils vont dépaqueter, c'est la boucle agentique. > *We know that Claude code is different from usual chat applications, but how does it work?* ## [00:13] La boucle agentique — collecter, agir, vérifier, répéter La boucle a quatre temps. Vous saisissez un prompt. Claude collecte le contexte dont il a besoin en échangeant avec le modèle, qui renvoie soit du texte soit un appel d'outil. Claude exécute l'action — éditer un fichier, lancer une commande. Puis il vérifie si le résultat satisfait effectivement le prompt. S'il passe, il s'arrête ; sinon il boucle à nouveau jusqu'à ce que le travail soit accompli et vérifiable. L'utilisateur n'est pas bloqué pendant ce temps : vous pouvez ajouter du contexte, interrompre ou orienter le modèle vers l'objectif final pendant l'exécution de la boucle. > *And if they don't, Claude goes back and runs the loop again until the results are complete and verifiable.* ## [01:02] La fenêtre de contexte et la compaction automatique La fenêtre de contexte est la mémoire de travail de Claude : la conversation, le contenu des fichiers, les sorties de commandes, tout ce sur quoi il peut revenir. Elle est bornée. Quand on atteint le plafond, Claude Code compacte la conversation de lui-même : il choisit ce qu'il peut supprimer et ce qu'il peut résumer pour faire redescendre la fenêtre sans perdre le fil. > *Once you reach that limit, Claude code compacts your conversation, which automatically determines what it can take out of the context window and what it can summarize in order to bring the context window back down.* ## [01:26] Les outils — dispatch sémantique pour lire des fichiers, exécuter du code, chercher sur le web La plupart des assistants IA se contentent de texte en entrée et texte en sortie, sans rien entre les deux. Les outils changent cela : ils permettent à l'agent de décider quand exécuter du code pour se rapprocher de l'objectif. Lire un fichier, chercher sur le web, lancer une commande shell. Claude Code effectue une recherche sémantique sur les outils disponibles pour choisir lequel appeler et en consommer la sortie. > *Tools let Claude code and other agents determine when to execute code to get closer to a task.* ## [01:52] Les modes de permission et le coût de les ignorer Par défaut, Claude Code demande confirmation avant de modifier un fichier ou d'exécuter une commande shell. Shift+tab fait défiler les alternatives : **acceptation automatique des modifications** écrit les fichiers sans demander mais pose quand même la question avant les commandes ; **le mode plan** restreint Claude aux outils en lecture seule afin de rédiger un plan d'action avant de toucher à quoi que ce soit. Le narrateur souligne le compromis évident : donner à l'agent toute liberté signifie qu'une erreur est plus difficile à détecter avant qu'elle ne survienne. > *Giving Claude code free reign to run commands means a mistake could be harder to catch before even happens.* ## [02:28] Récapitulatif — ce qui en fait autre chose qu'une fenêtre de chat Quatre primitives composées en un terminal : une boucle agentique, une fenêtre de contexte gérée, des outils et des permissions configurables. La combinaison — lire la base de code, agir dessus, vérifier son propre travail — c'est ce qui distingue Claude Code d'une simple fenêtre de chat. > *It can read your code base, take action, and verify its own work, and that makes it fundamentally different from a chat window.* ## Entités - **Anthropic Tutorial Narrator** (Person): La voix off officielle d'Anthropic pour la série de tutoriels Claude Code 101. - **Claude Code** (Software): L'assistant de codage terminal agentique d'Anthropic, construit autour des quatre primitives déballées dans cet épisode. - **Agentic loop** (Concept): Le cycle collecter-contexte, agir, vérifier, répéter qui anime chaque session Claude Code. - **Context window** (Concept): La mémoire de travail bornée de Claude, contenant la conversation, le contenu des fichiers et la sortie des commandes ; auto-compactée en cas de débordement. - **Tools** (Concept): Les effets de bord que l'agent peut invoquer — lire un fichier, chercher sur le web, exécuter une commande — sélectionnés via une recherche sémantique sur le catalogue d'outils. - **Permission modes** (Concept): Par défaut (demande), acceptation automatique des modifications et mode plan (lecture seule) — basculés avec shift+tab. - **Plan mode** (Feature): Un mode de permission en lecture seule qui permet à Claude de compiler un plan d'action avant toute mutation.

Le guide d'installation officiel de Claude Code. Le narrateur d'Anthropic présente les installers en une ligne pour chaque plateforme prise en charge — terminal, VS Code, JetBrains, Claude Desktop et web — et conclut avec un critère simple pour choisir la bonne option. ## [00:04] Installers en une ligne pour le terminal (macOS, Linux, WSL, Windows) La voie par défaut est le terminal. Les utilisateurs de macOS, Linux et WSL disposent d'une commande `curl` unique ; Homebrew fonctionne aussi mais ne propose pas de mises à jour automatiques. Sur Windows, PowerShell utilise `Invoke-RestMethod`, CMD dispose de son propre extrait `curl`, et `winget` est disponible avec la même restriction d'auto-update que Homebrew. > *If you're on macOS, Linux, or WSL, use this curl command to install it in one go. If you prefer to use Homebrew, you can also use brew install to install it, but note that this doesn't have auto-update capabilities.* ## [00:33] Lancer claude dans votre projet et se connecter Après l'installation, faites un `cd` dans votre projet et lancez `claude`. Au premier démarrage, un sélecteur de thème de couleurs et un processus de connexion apparaissent, acceptant un login Pro, Max, Enterprise ou par clé API. Les comptes Enterprise doivent sélectionner explicitement cette option. Le répertoire depuis lequel vous lancez l'outil définit la limite d'accès — Claude Code voit ce dossier et tout ce qu'il contient, rien au-dessus. > *Whatever directory you decide to run cloud in, it will have access to that directory and all of its subfolders.* ## [01:02] Extension VS Code Ouvrez le panneau Extensions, recherchez l'extension Claude Code par Anthropic et confirmez la coche bleue de vérification avant d'installer. Un redémarrage peut être nécessaire. Une fois installée, la palette de commandes (`Ctrl/Cmd+Shift+P`) ouvre un nouvel onglet Claude Code ; vous pouvez aussi cliquer sur le logo depuis n'importe quel fichier ouvert, ou désactiver entièrement l'interface graphique pour utiliser uniquement l'expérience terminal via les paramètres. > *You can also opt out of the UI and just use the terminal experience directly in your settings file.* ## [01:32] Plugin JetBrains Même démarche que VS Code : installez le plugin Claude Code depuis le JetBrains Marketplace, redémarrez l'IDE, et le logo Claude apparaît au relancement. Un clic ouvre un panneau latéral qui affiche l'expérience terminal à côté de votre éditeur. > *For JetBrains IDEs, you can install the Cloud Code plugin from the JetBrains Marketplace. Once you install, restart your IDE.* ## [01:51] Claude Desktop et claude.ai/code sur le web Claude Desktop expose Claude Code via un bouton "code" en haut de l'application une fois connecté — même interface de type chat, mais limitée à un dossier spécifique avec des permissions ajustables et même un mode d'exécution cloud. La version web se trouve à `claude.ai/code` et reproduit l'expérience desktop, avec une contrainte forte : elle ne fonctionne qu'avec des dépôts GitHub. > *On the web, you can access Claude code by going to claude.ai/code. This works very similar to the desktop app. However, you're restricted to GitHub repositories only.* ## [02:27] Choisir la bonne surface La règle du narrateur : le terminal en priorité si vous voulez les nouvelles fonctionnalités dès leur sortie. Les intégrations IDE offrent une expérience quasi identique intégrée dans votre éditeur. Le Desktop est idéal quand vous voulez que Claude travaille en arrière-plan pendant que vous faites autre chose. Le web convient au travail à distance sur des dépôts GitHub ou à l'exécution de plusieurs sessions en parallèle. > *If you want to constantly keep up to date with everything, the terminal is the best bet. Features ship there the fastest.* ## Entities - **Anthropic Tutorial Narrator** (Person) : Animateur en voix off du cours Claude Code 101 d'Anthropic. - **Claude Code** (Software) : Outil de codage agentique d'Anthropic, installable sur terminal, IDE, desktop et web. - **Homebrew / winget** (Software) : Alternatives via gestionnaire de paquets aux installers curl/PowerShell officiels — aucun des deux ne prend en charge l'auto-update. - **VS Code extension** (Software) : Extension Claude Code publiée par Anthropic ; vérifier la coche bleue avant l'installation. - **JetBrains plugin** (Software) : Plugin Claude Code distribué via le JetBrains Marketplace ; ouvre un panneau latéral après redémarrage de l'IDE. - **Claude Desktop** (Software) : Application desktop exposant Claude Code via un bouton "code", avec limitation de dossier et mode d'exécution cloud. - **claude.ai/code** (Service) : Version web de Claude Code, limitée aux dépôts hébergés sur GitHub.

Le deuxième épisode de Claude Code 101 d'Anthropic couvre le fichier unique qui transforme Claude Code d'un inconnu en coéquipier : `CLAUDE.md`. Au programme : quoi y mettre, comment la hiérarchie projet/utilisateur répartit les responsabilités, et trois habitudes pour éviter que le fichier ne devienne un mur de règles obsolètes. ## [00:02] Pourquoi Claude Code a besoin d'une mémoire persistante Sans `CLAUDE.md`, chaque session repart de zéro. Claude doit re-parcourir la base de code, deviner les dépendances et redécouvrir ce qui est déjà implémenté. Ces suppositions sont précisément ce qui rend le guidage difficile. Le fichier existe pour court-circuiter cette redécouverte à chaque nouvelle session. > *When you open up Claude Code without a claude.md file, it's like it has to start fresh every single time.* ## [00:34] Ce qu'est vraiment CLAUDE.md et la commande /init C'est un fichier Markdown ordinaire placé à la racine du projet, lu à chaque démarrage de session et ajouté directement à votre invite. Un «script d'intégration pour votre base de code». Si vous ne souhaitez pas l'écrire à la main, `/init` génère un premier brouillon à partir du code existant. L'exemple du tutoriel comporte trois blocs courts : la pile technologique (Next.js 15 app router, Tailwind, Drizzle ORM), les commandes (serveur de développement, tests, lint) et les règles de style (indentation de 2 espaces, exports nommés, routes API dans `app/api`, préférence aux server actions). Avec cela chargé, demander un composant React produit du code stylisé à la manière du projet dès le premier essai, sans aller-retour de corrections. > *It's a markdown file that you add to the root of your project and Claude Code reads it automatically every time you start a session.* ## [01:34] La hiérarchie de mémoire : projet vs utilisateur Oui, intégrez-le au contrôle de version. Le `CLAUDE.md` au niveau projet est destiné à toute l'équipe. Mais il existe un deuxième niveau : un `CLAUDE.md` utilisateur dans votre dossier de configuration, qui vous suit d'un projet à l'autre. C'est là que vivent vos préférences personnelles — style de commentaires, idiomes favoris — sans polluer le fichier partagé. > *But there's actually a hierarchy of memory files depending on who it's for.* ## [02:01] Trois conseils pour garder CLAUDE.md utile Trois habitudes recommandées par le narrateur. Premièrement, quand vous devez corriger Claude sur quelque chose de récurrent («toujours utiliser les server actions plutôt que les routes API»), demandez-lui explicitement de sauvegarder cela en mémoire pour que la correction persiste entre les sessions. Deuxièmement, référencez les docs existantes avec `@filepath` plutôt que de les copier-coller dans le fichier. Troisièmement — contre-intuitif — démarrez un nouveau projet *sans* `CLAUDE.md` et observez où vous recadrez constamment le modèle ; seuls ces points de friction méritent d'être dans le fichier. C'est ainsi qu'on garde un fichier compact plutôt que gonflé. > *We recommend you start off a project without a claude.md file so you can see where you have to constantly course correct the model.* ## [02:39] Récapitulatif : le contexte fait la différence Tout le message en une phrase : la différence entre une session frustrante et une session productive, c'est le contexte, et `CLAUDE.md` est le vecteur. Commencez petit — pile, préférences, commandes — et faites évoluer à partir des frictions réelles. > *Start with your stack, your preferences, and then commands, and just build from there as you go.* ## Entités - **Narrateur du tutoriel Anthropic** (Person): Voix off de la série officielle Claude Code 101 d'Anthropic. - **CLAUDE.md** (Concept): Fichier Markdown placé à la racine d'un projet que Claude Code charge automatiquement à chaque session, fournissant un contexte persistant ajouté à l'invite de l'utilisateur. - **/init** (Command): Commande Claude Code qui génère un `CLAUDE.md` initial en scannant la base de code existante. - **CLAUDE.md projet vs utilisateur** (Concept): Hiérarchie de mémoire à deux niveaux. Le fichier projet réside à la racine du dépôt et est partagé via le contrôle de version ; le fichier utilisateur réside dans le dossier de configuration et transporte les préférences personnelles d'un projet à l'autre. - **Référence @filepath** (Concept): Syntaxe permettant à `CLAUDE.md` de pointer vers des fichiers de documentation existants au lieu d'en dupliquer le contenu. - **Next.js 15 / Tailwind / Drizzle ORM** (Software): Pile technologique utilisée dans l'exemple `CLAUDE.md` du tutoriel pour illustrer l'apparence d'un fichier réel.

Présentation par Anthropic du Model Context Protocol dans Claude Code : ce à quoi il se connecte, comment ajouter et délimiter les serveurs, et le coût caché que chaque serveur installé fait peser sur la fenêtre de contexte. Destiné aux développeurs sur le point de brancher Claude Code sur Linear, GitHub ou leurs outils internes. ## [00:02] Pourquoi MCP existe — le contexte vit hors de l'éditeur L'argument d'emblée : la majeure partie du contexte dont Claude Code a besoin ne se trouve pas dans le dépôt, mais dans des bases de données, des applications de productivité et des paquets publics. MCP est le standard ouvert qui permet à Claude d'accéder à ces ressources de façon autonome et de décider lui-même quand les appeler, sans attendre que vous copiez-collez quoi que ce soit. > *Model Context Protocol est un standard ouvert qui permet à Claude Code de se connecter à des outils et des sources de données externes.* ## [00:35] Les outils et ce que les serveurs MCP connectent vraiment Avant d'énumérer les serveurs, le narrateur pose la notion d'*outil* : les agents comme Claude Code se servent d'outils pour effectuer des actions, c'est ce qui les distingue d'un simple chat qui ne fait que renvoyer du texte. Deux exemples concrets suivent : un serveur MCP Linear qui importe les tickets de l'équipe dans la session, et le serveur Context7 qui diffuse la documentation à jour de la dépendance en cours d'utilisation. Des centaines d'autres sont disponibles sur claude.com/connectors. > *Les outils donnent aux agents comme Claude Code la capacité d'effectuer des actions pour mieux accomplir leurs tâches.* ## [01:14] Ajouter des serveurs : HTTP vs STDIO, et /mcp Les serveurs s'ajoutent avec `claude mcp add` et se déclinent en deux types : les serveurs **HTTP**, hébergés à distance par le fournisseur et accessibles via le réseau, et les serveurs **STDIO**, des processus locaux qui tournent sur votre propre machine. Une fois installés, la commande `/mcp` en session liste ce qui est connecté, affiche l'état de chaque serveur et permet d'en désactiver à volonté. > *Les serveurs HTTP sont pour les services distants... Les serveurs STDIO sont pour les processus locaux qui tournent sur votre machine.* ## [01:42] Trois portées : local, user et project (.mcp.json) Chaque serveur appartient à l'une des trois portées. **Local** le limite au projet actuel pour vous seul ; **user** le rend disponible dans tous vos projets ; **project** génère un fichier `.mcp.json` à versionner, de sorte que chaque membre de l'équipe travaillant sur le dépôt récupère automatiquement les mêmes serveurs. > *La portée project utilise un fichier .mcp.json que vous commitez dans votre contrôle de version, si bien que toute personne travaillant sur le code base obtient exactement les mêmes serveurs automatiquement.* ## [02:04] Les définitions d'outils coûtent du contexte — quand préférer CLI ou skill Le piège que personne ne signale quand on vous remet une liste de connecteurs : chaque serveur MCP configuré injecte ses définitions d'outils dans la fenêtre de contexte, qu'on l'utilise ou non. Les mesures préconisées par le narrateur se combinent : lancer `/mcp` et désactiver tout ce qui est inactif ; préférer une CLI comme `gh` ou `aws` quand elle existe, car les CLI ne portent pas de définitions d'outils persistantes ; ou encapsuler le flux de travail dans un skill, qui ne place que son nom et sa description dans le contexte jusqu'à ce que Claude décide de le charger. Au-delà de 10 % du contexte, Claude Code bascule en mode de recherche d'outils, les découvrant à la demande — utile, mais moins fiable qu'un chargement préalable. > *Les serveurs MCP ajoutent des définitions d'outils à votre fenêtre de contexte, même quand vous ne les utilisez pas. Si vous avez beaucoup de serveurs configurés, cela grignote votre contexte disponible.* ## [03:10] Récapitulatif Les trois points à retenir : `claude mcp add` installe les serveurs, `.mcp.json` les partage avec l'équipe, et `/mcp` permet de supprimer ceux qu'on n'utilise pas vraiment. > *Ajoutez des serveurs avec Claude MCP add, limitez leur portée à votre projet avec .mcp.json pour que votre équipe les récupère automatiquement, et surveillez l'utilisation du contexte en désactivant les serveurs que vous n'utilisez pas activement.* ## Entités - **Narrateur du tutoriel Anthropic** (Person): Le narrateur officiel d'Anthropic pour la série Claude Code 101. - **Model Context Protocol (MCP)** (Standard): Protocole ouvert permettant à Claude Code de se connecter à des outils et des sources de données externes via des serveurs HTTP ou STDIO. - **Linear MCP server** (Software): Connecteur qui importe les tickets Linear de l'équipe dans une session Claude Code. - **Context7 MCP server** (Software): Connecteur qui fournit à Claude Code la documentation à jour de la dépendance utilisée. - **.mcp.json** (Config): Manifeste de portée projet versionné, permettant à chaque membre de l'équipe d'hériter des mêmes serveurs MCP. - **/mcp** (CLI command): Commande en session pour lister, inspecter et désactiver les serveurs MCP connectés. - **Tool search mode** (Feature): Mode de repli dans lequel Claude Code entre quand les définitions d'outils MCP dépassent 10 % de la fenêtre de contexte, découvrant les outils à la demande. - **Skill** (Concept): Alternative légère à un serveur MCP complet ; seuls son nom et sa description occupent le contexte jusqu'à ce que Claude charge le corps à la demande.

Fiona Fung, who runs engineering and product for Claude Code and Cowie at Anthropic, walks through what broke when agentic coding became the team's default — review, ownership, planning, hiring — and the norms they rewrote to keep shipping. The throughline: when coding stops being the bottleneck, every process built around protecting expensive engineering bandwidth quietly stops working, and the manager's job is to notice and rewrite them fast. ## [00:00] Intro and the five themes Fiona opens with a confession that the room is much fuller than she expected (Boris and Jared's session is still letting out), takes a selfie with the audience, and frames the talk. Background: she grew teams at Meta and Microsoft before Anthropic, and is now responsible for Claude Code and Cowie engineering and product. The deck she's about to walk through has already been rewritten in the past month — routines didn't exist when she first wrote the slides. She previews five threads: bottlenecks have shifted, team norms had to be rewritten, how they rolled them out, what signals say the changes are working, and the open questions she's still sitting with. > *"I did this slide deck maybe like a month ago and already I've had to change some of the content cuz when I started this deck, there were no routines."* ## [02:10] The shift: bottlenecks have moved Fiona's subtitle for the whole talk is *what served you prior may not serve you any longer*. She takes the audience back to shipping Visual Studio 2005 on CD-ROMs — hard deadlines because the manufacturing lab had to print discs — and points out that the move from CDs to online distribution already rewired how teams ship. The new shift is bigger: for years coding throughput and engineering bandwidth were the expensive things, and that's quietly stopped being true on Claude Code. When the bottleneck moves, it doesn't disappear — it relocates to verification, review, cross-functional handoffs, and security. The questions that matter now are "is this code correct?" and "is this safe?", and the old planning and ownership norms quietly stop serving the team. > *"What served you prior may not serve you any longer."* ## [07:40] Rewriting team norms: code review, JIT planning, technical debates Inside Claude Code the team had to rewrite the norms one by one. Code review is the first — human judgment shifts to "who actually needs to look at this." Planning is the second — Fiona calls it JIT planning, like JIT compiling, because prototyping is no longer the expensive step that justifies a six-month roadmap. Technical debates are the third: code wins. Instead of two engineers arguing on a doc, both prototype the API and look at impact on callers, and Fiona made a point of caring about the API's downstream effects as much as the implementation itself. The unifying rule: when building is cheap and arguing is expensive, you don't let the last person who checks in win — you build the routines that get *you* the last word. > *"When building is cheap, arguing expensive, again, how does that shift your team norms a bit?"* ## [13:30] Routines and Claude as a second pair of hands With morning coffee Fiona now reads what a routine produced overnight rather than kicking off the work herself. The team leans on Claude code review heavily — Claude babysits PRs, handles styling, lint, and feedback requests, catches bugs before commit, and adds tests — while humans focus on the calls where trust is still being built. She also stresses product sense in tooling: she themed Claude's terminal output ice blue with snowflakes over the holidays, then pulls back to the bigger point that catching bugs earlier (shift left) and automating the double-click question matter more than any one tool. > *"Where do you trust Claude a lot, but then where do you still want a human?"* ## [16:45] Cross-functional gaps and hiring for the hard parts Fiona walks through a survey-update story: she didn't have a dedicated content designer, so Claude became her partner for terse, terminal-appropriate copy. Meanwhile PMs on the team write code, and engineers lean into PM work. The flip-side conclusion for hiring: non-traditional coders can now do more engineering, so the leader's job is to double down on the hard parts the team is actually missing. When she joined, Claude Code was strong on product generalists and creative folks but thin on distributed-systems expertise — that's where she pushed recruiting. > *"With Claude, you have non-traditional coders now being able to do more engineering, but you also have engineers that we can also now lean in to do other roles."* ## [18:51] Flat org and answering customer feedback yourself Fiona pushed her recruiters into an uncomfortable place: hire managers, but have them start as ICs first. The recruiter thought she was crazy; Fiona's answer is that dogfooding Claude Code is the job, and if a candidate isn't up for it the team is better off finding out early. Flat structure plus Claude as a context-switching aid is what lets her, as a manager, still ship code and answer customer requests directly from her desktop Claude Code — instead of routing every customer question through a triage system, she pulls up the local repository and answers it herself. > *"You want to hire managers and they will start as an IC first. No manager would be interested in that."* ## [25:00] Signals you're trending right and open questions The team's working metric is unglamorous and direct: every commit is cloud-assisted by default, and Fiona hasn't seen a non-Claude commit in roughly four months. But she warns against fetishizing the "X percent of code generated by AI" headline — throughput is one signal, not the goal. The end question is what product you're making more delightful and what problem you're solving, with quality and reliability watched alongside volume. She closes with the section she calls "audit your own effort," opens up the questions she's still asking herself, and hands suggestions back to the audience to take to their own teams. > *"For us, it's by default every commit is cloud-assisted. I don't think I've seen a non-cloud-assisted commit probably in the last 4 months or so."* ## Entities - **Fiona Fung** (Person): Director of Engineering at Anthropic, runs Claude Code and Cowie engineering + product; previously led teams at Meta and Microsoft. - **Boris** (Person): Engineering lead on Claude Code, frequent collaborator referenced throughout. - **Kat (Cat)** (Person): Anthropic colleague who gave a keynote earlier the same day on Claude code review. - **Claude Code** (Software): Anthropic's agentic coding tool that is now the default for the team Fiona runs. - **Cowie** (Software): Sister product Fiona's team also owns engineering + product for. - **Anthropic** (Organization): The company building Claude and Claude Code. - **JIT planning** (Concept): Fiona's term for shifting from a six-month roadmap to just-in-time planning, modeled on JIT compilation. - **Shift left** (Concept): Moving bug-catching and verification earlier — into automation and tooling — instead of relying on review after the fact. - **Routines** (Concept): Repeatable Claude-driven workflows the team relies on so a single human gets the last word on outcomes rather than the last commit timestamp winning.

Un court tutoriel Anthropic sur les hooks Claude Code, la porte de sortie déterministe pour tout ce qui doit absolument s'exécuter à chaque édition, chaque appel d'outil, chaque commit. Le message clé : si vous écrivez "toujours exécuter prettier" dans claude.md en espérant que ça marche, vous avez déjà perdu. Mettez-le dans un hook. ## [00:02] Ce que sont les hooks et pourquoi ils sont déterministes Les hooks se déclenchent à des points fixes dans le cycle de vie de Claude Code, et l'argument central du narrateur est que, contrairement aux instructions au niveau du prompt, ils s'exécutent toujours. Indiquer au modèle dans claude.md de lancer prettier après chaque édition fonctionne la plupart du temps, mais "la plupart du temps" est exactement la faille que comble un hook. Même intention, mais imposée par le runtime plutôt que suggérée au LLM. > *You can tell Claude in your claude.md file to run prettier after every file edit and most of the time it will do that, but sometimes it won't. It's not perfect. But a hook makes it happen every single time with no exceptions.* ## [00:37] Cas d'usage courants Quatre exemples représentatifs délimitent le périmètre : formatage automatique après les éditions de fichiers, journalisation de toutes les commandes exécutées pour la conformité, blocage des opérations dangereuses comme la modification des fichiers de production, et envoi d'une notification lorsque Claude termine une longue tâche. > *Common use cases could include auto formatting after file edits, logging all executed commands for compliance, blocking dangerous operations like modifying production files, and sending yourself notifications when Claude finishes a task.* ## [00:52] Configurer les hooks et les cinq événements du cycle de vie La configuration réside dans `settings.json` : choisissez un événement, affinez-le optionnellement avec un matcher pour l'outil concerné, puis fournissez une commande shell. Cinq événements couvrent la boucle : `UserPromptSubmit` avant que Claude voie un prompt, `PreToolUse` et `PostToolUse` encadrant chaque appel d'outil, `Notification` quand Claude alerte l'utilisateur, et `Stop` quand Claude termine sa réponse. > *Pre-tool use which runs before a tool call, post-tool use runs after a tool call completes. Notification runs when Claude sends a notification, and stop runs when Claude finishes responding.* ## [01:22] Formatage automatique avec un hook post-tool-use L'exemple canonique : un hook `PostToolUse` avec un matcher `Edit` ou `MultiEdit` se déclenche chaque fois que Claude modifie un fichier. La commande vérifie l'extension et dirige vers le bon formateur : prettier pour TypeScript, gofmt pour Go, ruff pour Python, ou tout ce que le projet standardise. > *You set a post-tool use hook with a matcher of edit or multi-edit, right? So, it fires whenever Claude modifies a file. The command checks the file extension and runs the appropriate formatter.* ## [01:49] Bloquer les appels d'outils avec pre-tool-use et les codes de sortie Les hooks `PreToolUse` reçoivent le nom de l'outil et son entrée en JSON sur stdin, puis décident via le code de sortie : `0` pour continuer, `2` pour bloquer. Quand un hook bloque, ce qu'il a écrit sur stderr est renvoyé à Claude comme feedback, permettant au modèle de comprendre pourquoi et d'adapter son plan. C'est ici qu'on applique les règles strictes : bloquer les écritures dans un répertoire de config de production, refuser les commandes bash contenant `rm -rf`, bloquer les commits sur main. Le narrateur résume : ce que l'équipe doit garantir, pas simplement suggérer. > *If it exits with code two, the action is blocked and the STD error message gets fed back to Claude's feedback so Claude knows why it was blocked and can adjust.* ## [02:26] Hooks au niveau projet et partage en équipe Les hooks dans `.claude/settings.json` ont une portée projet et peuvent être commitués dans le dépôt, ce qui signifie que toute l'équipe les hérite automatiquement au clonage. Référencez les scripts via la variable d'environnement `CLAUDE_PROJECT_DIR` pour que les commandes se résolvent correctement, quel que soit le répertoire courant de Claude. La règle de clôture : si quelque chose doit se produire à chaque fois sans exception, ne le mettez pas dans un prompt, mettez-le dans un hook. > *If something needs to happen every time without fail, don't put it in a prompt. Put it in a hook.* ## Entities - **Anthropic Tutorial Narrator** (Person): La voix officielle d'Anthropic pour la série de tutoriels Claude Code 101. - **Claude Code** (Software): L'outil de codage terminal agentique d'Anthropic auquel les hooks se connectent lors des événements du cycle de vie. - **Hooks** (Concept): Commandes déterministes se déclenchant à des points fixes dans la boucle Claude Code, alternative imposée par le runtime aux instructions au niveau du prompt. - **settings.json** (Configuration): Là où les hooks sont déclarés ; `.claude/settings.json` à la racine du projet est versionné dans le dépôt afin que les équipes partagent les mêmes règles. - **PreToolUse / PostToolUse / UserPromptSubmit / Notification / Stop** (Events): Les cinq événements du cycle de vie auxquels un hook peut se rattacher. - **CLAUDE_PROJECT_DIR** (Environment variable): Utilisée dans les commandes de hook pour référencer des scripts relatifs au projet, indépendamment du répertoire courant de Claude.

La présentation officielle d'Anthropic sur Claude Code — ce que c'est, en quoi il diffère de Claude.ai, et les trois choses à savoir avant de laisser un LLM exécuter des commandes sur votre base de code. Destiné aux développeurs sur le point d'installer l'outil terminal pour la première fois. ## [00:04] Ce qu'est Claude Code et où il s'exécute Claude Code se positionne comme un outil de codage agentique : il comprend votre base de code, édite des fichiers, exécute des commandes et s'intègre aux outils de développement que vous utilisez déjà. Il fonctionne sur plusieurs surfaces — terminal, VS Code, JetBrains IDE, l'application de bureau Claude et le web — mais cette présentation se concentre sur le terminal comme expérience de référence. > *Claude Code is an agentic coding tool that understands your code base, edits your files, run commands, and integrates with your existing developer tools to help you get things done faster.* ## [00:34] En quoi il diffère de Claude.ai La distinction clé n'est pas la capacité du modèle mais l'accès : Claude Code accède directement à votre terminal et à l'intégralité de votre base de code, ce qui élimine le cycle copier-coller dans le chat — l'outil effectue le travail sur place. L'appeler "agent IA" résume cette surface d'exécution directe. > *Unlike Claude AI, Claude Code has direct access to your files in your terminal and your entire code base.* ## [00:51] Les agents IA et ce que Claude Code peut faire Un agent IA désigne ici un logiciel qui interagit avec son environnement et prend des mesures pour atteindre un objectif défini — dans sa forme la plus basique, un LLM en boucle en temps réel avec accès à des outils, des services externes et d'autres agents. Pour Claude Code, cela se traduit par des capacités concrètes : lire et expliquer votre base de code, tracer des bugs à travers les fichiers, exécuter des scripts de build et des tests, installer des paquets, et récupérer sur le web la documentation API la plus récente pour décider de la prochaine action. > *An AI agent is a software that can interact with its environment and perform actions to complete a defined goal.* ## [01:45] Trois concepts à connaître avant de commencer Le narrateur signale trois propriétés qui façonnent l'utilisation quotidienne. Premièrement, la **fenêtre de contexte** est la mémoire de travail de Claude — grande mais finie — c'est pourquoi l'agent doit naviguer stratégiquement dans une base de code plutôt que de tout charger. Deuxièmement, Claude Code **demande une autorisation** avant d'exécuter des commandes ou de modifier des fichiers ; vous gardez le contrôle que vous souhaitiez piloter chaque étape ou le laisser fonctionner de manière autonome. Troisièmement, **il peut se tromper** : mal interpréter l'intention, introduire des bugs ou sur-ingéniérer une correction. Traitez les sorties comme vous le feriez avec n'importe quel outil, sans les considérer comme parole d'évangile. > *By default, Claude Code will ask you before running commands or making changes to your code base.* ## [02:34] Récapitulatif Claude Code est un outil de codage agentique qui lit votre base de code, édite des fichiers, exécute des commandes et se connecte à des outils externes pour vous aider à livrer plus vite — disponible dès maintenant sur le terminal, VS Code, JetBrains et l'application de bureau Claude. > *Claude Code is an agentic coding tool. It reads your code base, edits your files, runs commands, and connects to external tools to help you ship faster.* ## Entités - **Anthropic Tutorial Narrator** (Person): Le narrateur officiel d'Anthropic pour la série de tutoriels Claude Code 101. - **Claude Code** (Software): L'assistant de codage agentique basé sur le terminal d'Anthropic, qui opère directement sur votre base de code. - **Claude.ai** (Software): Le produit Claude basé sur le chat — mis en contraste avec l'exécution en environnement de Claude Code. - **AI agent** (Concept): Un LLM fonctionnant en boucle en temps réel avec accès à des outils, des services externes et d'autres agents pour poursuivre un objectif défini. - **Context window** (Concept): La mémoire de travail de Claude — finie, c'est pourquoi l'agent navigue stratégiquement plutôt que de charger la base de code entière. - **VS Code / JetBrains IDEs** (Software): Les intégrations d'éditeurs dans lesquelles Claude Code est disponible, aux côtés du terminal et de l'application de bureau Claude.

Présentation en trois minutes par Anthropic de la boucle qu'ils considèrent comme l'habitude la plus importante lors du travail avec Claude Code : d'abord rechercher en mode plan, définir ce que "terminé" signifie avant de toucher un seul fichier, puis faire réviser le diff par un sous-agent avant de pousser. ## [00:03] Pourquoi explorer-planifier-coder-committer surpasse le démarrage immédiat L'introduction est directe : si vous n'adoptez qu'une seule habitude du cours, que ce soit ce workflow. Le mode d'échec combattu est le réflexe de coller une tâche dans Claude et de le regarder générer du code immédiatement, ce qui accélère le démarrage mais repousse le coût de correction. > *Without this, most people jump straight to pasting in Claude to write code, which means more course correcting later on.* ## [00:21] Le mode plan : recherche en lecture seule avant toute édition Le mode plan compresse exploration et planification en un seul geste. Claude peut lire des fichiers et effectuer des recherches web mais ne peut pas écrire — Shift+Tab permet de basculer depuis l'invite. Le narrateur fait la démonstration avec une vraie demande (ajouter la conversion WebP à un pipeline d'upload d'images, identifier l'endroit approprié, les dépendances nécessaires et l'approche). Claude retourne un plan ; vous le lisez et demandez des révisions si quelque chose manque. C'est l'endroit le moins coûteux de tout le cycle pour changer de direction, car rien n'a encore été écrit. > *With plan mode, Claude can't edit files. It just reads files to gather research on how to tackle this implementation.* ## [01:11] Approuver le plan puis corriger la trajectoire pendant que Claude code Une fois le plan satisfaisant, Approuver rend l'exécution à Claude pour qu'il coche les éléments de la liste. Vous choisissez si les éditions de fichiers s'auto-acceptent ou demandent une confirmation à chaque fois. Claude résoudra les problèmes seul, mais prévoyez d'intervenir — et le bénéfice du mode plan ici est que l'agent conserve le contexte de recherche qui a produit le plan, donc les corrections en cours d'exécution atterrissent au bon endroit plutôt que de repartir de zéro. > *This is the benefit of working with plan mode because after the plan is finished, we also have the context of how it got to the results to help it guide its next decision.* ## [01:39] Expliciter les critères de succès et donner de vrais outils à Claude Un plan sans définition du "correct" laisse Claude deviner. Précisez à quoi ressemble le succès, puis équipez l'agent pour le vérifier réellement : l'extension Claude+Chrome lui permet de piloter un onglet de navigateur pour tester une interface qu'il vient de construire ; une suite de tests lui fournit quelque chose à valider à chaque boucle, et Claude peut aussi écrire les tests — mais seulement si vous les avez déjà validés comme vérité terrain. Conseil de durabilité : quand Claude bute sans cesse sur le même problème, demandez-lui de persister la solution dans le fichier CLAUDE.md pour arrêter de le réapprendre. > *In order for Claude to be confident in its results, it has to be clear on what it deems correct.* ## [02:24] Revue par sous-agent, commit et récapitulatif Avant de pousser, lancez un reviewer de code sous-agent sur le diff — une seconde passe sans attachement à l'implémentation. Ensuite, demandez à Claude de rédiger le message de commit dans votre style et d'expédier. Le récapitulatif recadre chaque étape : Explorer fournit le contexte, Planifier définit le succès, Coder est l'aller-retour qui converge vers le plan, Committer révise et pousse pour passer à la suite. > *A tip before you commit, run a sub agent code reviewer to look at your code.* ## Entities - **Anthropic Tutorial Narrator** (Person): La voix officielle d'Anthropic pour le cours Claude Code 101. - **Claude Code** (Software): Outil de codage agentique en terminal dont la boucle quotidienne recommandée est le sujet de cet épisode. - **Plan mode** (Feature): Mode lecture seule activé par Shift+Tab — Claude recherche et propose un plan mais ne peut pas éditer de fichiers. - **Claude + Chrome extension** (Software): Permet à Claude Code de piloter un onglet Chrome pour vérifier les modifications d'interface avant de déclarer une tâche terminée. - **CLAUDE.md** (File): Fichier de mémoire du projet utilisé ici comme cible de persistance pour les corrections que Claude réapprend sans cesse. - **Subagent code reviewer** (Pattern): Sous-agent Claude pré-commit qui révise le diff avant que l'humain pousse.

Le tutoriel Claude Code 101 d'Anthropic sur le contexte — ce qui remplit la fenêtre, quand la compaction automatique se déclenche, et les leviers pratiques (/compact, /clear, /context, claude.md, toggles MCP, skills, sous-agents) pour garder une session suffisamment légère. ## [00:03] Pourquoi le contexte est fini et pourquoi cela compte Le contexte est la mémoire de travail de Claude : chaque prompt, chaque lecture de fichier, chaque résultat d'appel d'outil atterrit dans la même fenêtre. La fenêtre est grande mais finie, donc optimiser ce qui y entre devient incontournable dès que l'on commence des sessions multi-étapes. > *Every file it reads, every command it runs, every message you send, it all takes up space in the context window.* ## [00:39] La compaction automatique et la commande /compact En approchant de la limite, Claude Code compacte automatiquement : il résume les éléments importants et supprime les résultats d'appels d'outils bruyants pour libérer de l'espace. Vous pouvez aussi déclencher `/compact` manuellement — utile quand vous voulez de la marge tout en conservant le fil de votre travail. Compromis : la compaction peut faire perdre les détails des tours précédents. > *Compaction will summarize important details and remove the unnecessary tool call results and free up a lot of space in your context window.* ## [01:11] /clear et /context : repartir de zéro et voir ce qui est utilisé Si vous voulez une réinitialisation totale sans mémoire de la session précédente, `/clear` efface tout. Pour voir où va réellement votre espace, `/context` affiche la taille totale, les catégories les plus gourmandes et un graphique de répartition — le diagnostic avant de choisir entre compact et clear. > *To check the state of your context, run the /context command.* ## [01:35] La règle empirique : compact en cours de tâche, clear entre les tâches Le narrateur donne une heuristique claire : vous travaillez encore sur une fonctionnalité et approchez du plafond ? Compactez — vous voulez que l'historique pertinent persiste. Vous avez terminé le plan et passez à autre chose ? Effacez — l'ancienne conversation risque de biaiser le nouveau travail. > *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 that you want to create.* ## [01:57] claude.md, précision des prompts et écrire moins en écrivant plus Tout ce que Claude doit retenir d'une session à l'autre appartient à `claude.md` pour éviter qu'il redécouvre les mêmes faits à chaque fois. Et paradoxalement, les prompts courts coûtent plus de contexte : face à une demande vague, Claude parcourt le codebase avec grep et raisonne davantage, ce qui remplit la fenêtre. Une ou deux phrases de précision supplémentaires économisent beaucoup d'espace par la suite. > *The irony behind writing a smaller prompt is that it in the long run, it will take up more context.* ## [02:26] Serveurs MCP, skills et sous-agents comme outils de gestion du contexte Les serveurs MCP chargent par défaut tous les outils qu'ils exposent dans le contexte — pratique s'ils sont pertinents, coûteux sinon, donc désactivez ceux sans rapport avec le projet. Les skills se comportent comme des serveurs MCP mais n'injectent pas toute leur surface dans le contexte. Les sous-agents fonctionnent en parallèle avec leur propre fenêtre séparée ; pour les tâches de recherche d'informations ("où sont les endpoints d'authentification ?"), vous pouvez déléguer à un sous-agent et ne récupérer que la réponse, sans tout le cheminement. > *Sub agents run in parallel with your main agent but has a complete separate context window.* ## [03:06] Récapitulatif Gérer le contexte dans Claude Code est la différence entre une session longue et productive et une session bloquée. Utilisez `/compact` pour résumer les longues sessions, `/clear` pour repartir à zéro, soyez précis dans vos prompts, vérifiez `/context` pour voir ce qui consomme la fenêtre, et déléguez les tâches de recherche d'information aux sous-agents. > *Managing context within cloud code is crucial. Use slash compact to summarize long sessions and slashclear to start fresh.* ## Entités - **Anthropic Tutorial Narrator** (Person): La voix officielle d'Anthropic pour la série de tutoriels Claude Code 101. - **Claude Code** (Software): L'assistant de codage agentic en terminal d'Anthropic dont la fenêtre de contexte est le sujet de cet épisode. - **Context window** (Concept): La mémoire de travail de Claude — finie, remplie par les prompts, lectures de fichiers et résultats d'appels d'outils. - **/compact** (Command): Commande slash (et déclencheur automatique) qui résume l'historique et supprime le bruit des appels d'outils pour libérer de l'espace. - **/clear** (Command): Commande slash qui efface intégralement la session pour un départ propre sur un nouveau travail. - **/context** (Command): Commande slash qui indique la taille totale du contexte et les catégories qui le consomment. - **claude.md** (File): Fichier mémoire au niveau du projet que Claude lit entre les sessions pour ne pas redécouvrir les mêmes faits. - **MCP servers** (Software): Fournisseurs d'outils qui chargent par défaut tous les outils exposés dans le contexte — à désactiver quand ils sont sans rapport. - **Skills** (Feature): Alternative allégée aux serveurs MCP qui évite de charger toute la surface d'outils dans le contexte. - **Sub agents** (Feature): Agents parallèles avec leur propre fenêtre de contexte, utilisés pour répondre à des questions ciblées sans polluer la fenêtre principale.

Les sous-agents sont puissants quand le travail intermédiaire n'a pas sa place dans le thread principal — mais déléguer sans discernement aggrave les choses. Ce tutoriel trace la ligne entre délégation utile (recherche, revue de code, prompts système spécialisés) et anti-patterns courants (revendications d'expertise, pipelines séquentiels, test runners) qui gaspillent le contexte et font perdre les informations dont on a réellement besoin. ## [00:03] Introduction : quand les sous-agents aident ou nuisent La série a jusqu'ici couvert la création et la conception des sous-agents. Ce dernier épisode se concentre sur la question du déploiement : quelles tâches bénéficient vraiment de l'instanciation d'un agent distinct, et lesquelles en souffrent ? La réponse tient à un seul test : le travail intermédiaire compte-t-il pour le thread principal ? Quand l'exploration est séparée de l'exécution, les sous-agents sont rentables. Quand chaque étape dépend de ce que la précédente a découvert, le coût du transfert fait perdre précisément les détails nécessaires. > *"Simply put, the difference comes down to whether the intermediate work matters to your main thread."* ## [00:32] Tâches de recherche : garder l'exploration isolée La traçabilité de l'authentification est un exemple concret. Le thread principal a besoin de savoir où se produit la validation JWT, pas de connaître la douzaine de fichiers parcourus en chemin. Un sous-agent de recherche peut scanner l'ensemble du dépôt, suivre les appels de fonction entre fichiers et renvoyer une réponse unique et précise : la validation JWT se trouve dans middleware/auth.js à la ligne 42, appelée depuis route/api.js. Toute cette exploration reste enfermée dans le contexte du sous-agent. Le thread principal reçoit la conclusion et avance sans que l'historique de recherche n'encombre sa fenêtre. > *"Your main thread receives JWT validation happens in middleware/auth.js at line 42, called from the Express router and route/api.js, or something like that."* ## [01:15] Sous-agents de revue de code : un regard neuf Claude relire du code qu'il a contribué à écrire pose un problème de biais — il a assisté à chaque décision et ne peut pas facilement repérer ce qui paraît suspect de l'extérieur. Un sous-agent reviewer contourne entièrement cela : il ne voit que le diff et les fichiers modifiés, sans aucun historique sur la façon dont le code a évolué. Cette ardoise vierge crée un second avantage. Les critères de revue propres au projet — conventions de nommage, patterns de sécurité, règles architecturales — peuvent être encodés une fois dans le prompt système du sous-agent et appliqués de manière cohérente, sans que le thread principal ait à s'en souvenir tour après tour. > *"A reviewer sub agent sees the changes in a separate context. It runs get diff, reads the modified files, and applies its specialized review criteria without the history of how the code was written."* ## [01:59] Prompts système personnalisés : rédaction et style Le prompt par défaut de Claude Code est optimisé pour une sortie concise et technique — exactement ce qu'il ne faut pas pour une landing page ou un email marketing. Un sous-agent de rédaction reçoit des instructions complètement différentes sur le ton, le public et la structure, produisant un résultat que les réglages par défaut du thread principal ne génèreraient jamais. La même logique s'applique au CSS. Un sous-agent de style qui mentionne les fichiers de votre design system charge automatiquement variables de couleur, conventions d'espacement et patterns de composants dans son contexte avant d'écrire la moindre ligne, garantissant que chaque décision de style reflète le système réel plutôt que des suppositions raisonnables. > *"Claude Code's default prompt tends towards concise, technical writing, which really isn't what you want for a landing page or email campaign, unless you want to put your customers to sleep."* ## [02:57] Anti-patterns : expert claims, pipelines, test runners Trois patterns dégradent systématiquement les résultats. D'abord, les prompts de persona — « Tu es un expert Python » ou « Tu es un spécialiste Kubernetes » — n'apportent rien, car Claude dispose déjà de ces connaissances. Lancer un sous-agent simplement pour lui coller une étiquette d'expert gaspille le surcoût de l'isolation sans rien apporter que le thread principal ne puisse faire. Ensuite, les pipelines séquentiels s'effondrent dès que les étapes ne sont pas vraiment indépendantes. Un flux en trois agents — reproduire un bug, le déboguer, le corriger — paraît propre mais échoue en pratique : l'agent de débogage a besoin du contexte en direct de l'agent de reproduction, pas d'un résumé compressé. Enfin, les sous-agents test runner masquent activement de l'information. Quand les tests échouent, il faut la sortie brute pour diagnostiquer ce qui s'est passé. Un sous-agent qui renvoie seulement « test failed » oblige à écrire des scripts de débogage supplémentaires pour récupérer des détails que la sortie directe aurait montrés immédiatement. > *"A sub-agent that returns a test failed forces you to create additional debug scripts to get details that would have been visible in direct output."* ## [04:10] Récapitulatif et heuristique de décision clé En synthèse : les sous-agents sont des threads isolés créés avec /agents, conçus avec des sorties structurées et des descriptions précises. À utiliser pour la recherche, la revue de code et les tâches nécessitant un prompt système personnalisé. À éviter pour les revendications d'expertise, les pipelines multi-étapes dépendants et l'exécution de tests. Tout le framework se résume à une question : le travail intermédiaire compte-t-il ? Si la réponse est non, déléguez-le. > *"The key question, does the intermediate work matter? If not, then delegate it."* ## Entités - **Anthropic Tutorial Narrator** (Personne) : présentateur de la série de tutoriels Claude Code sur les sous-agents, Anthropic - **Claude Code** (Logiciel) : assistant de codage IA d'Anthropic ; l'environnement dans lequel les sous-agents sont créés et orchestrés - **Subagent** (Concept) : thread Claude isolé lancé depuis le contexte principal, renvoyant un résumé compressé plutôt qu'exposant son contexte de travail complet - **JWT (JSON Web Token)** (Concept) : utilisé comme exemple concret pour un sous-agent de recherche traçant la logique d'authentification dans un dépôt - **System prompt** (Concept) : jeu d'instructions par sous-agent permettant un comportement spécialisé différent du prompt par défaut de Claude Code - **Anthropic** (Organisation) : développeur de Claude et de la série de tutoriels Claude Code sur les sous-agents