Vos agents travaillent seuls. Alors pourquoi êtes-vous encore devant l’écran ?

Technological concept / product analysis: “agent supervision bottlenecks”

The video argues that the limiting factor when adopting software agents is not developer motivation, but verification and supervision capacity—the process for reviewing, testing, and approving agent-produced changes.

It uses and extends a “progression scale” (attributed to Boris Cherny) describing how teams move from single-agent, human-supervised coding toward more parallel and autonomous agent execution—while the main bottleneck shifts from human attention to review throughput and then to trust/decision flow.

---

The progression scale (Cherny’s “stages”) and what blocks teams at each stage

Source: Boris Cherny (Claude Code / Anthropic ecosystem tools). The speaker summarizes the climb in five stages, noting competitors reportedly observe similar patterns.

1. Stage 0 – Access locked

   • Tool purchase happens, but approval processes and governance slow or block real output.

2. Stage 1 – The “pair”

   • Engineer + single agent, with tight supervision.
   • Bottleneck: attention You must re-read everything—your focus never fully leaves the screen.

3. Stage 2 – The “orchestrator” (parallel agents)

   • ~10 agents in parallel in isolated sandboxes.
   • You review final results instead of watching keystrokes.
   • Bottleneck: review throughput Can reviewers keep up with the volume of agent output?

4. Stage 3 – The “hundred agents” (team tree)

   • ~100 agents; manual line-by-line monitoring becomes impossible.
   • Bottleneck: trust in the loop and team decision flow.

5. Stage 4 – The “thousand agents” (steering by intention)

   • Steering becomes higher-level (“by intention”), with much less human intervention.
   • The speaker claims: remaining debate is about supervision, not capacity.

Key claim: Teams aren’t blocked by willingness to adopt agents at any stage—they’re blocked by a verification system that doesn’t scale.

---

Reviews / evidence / telemetry cited (anti-pattern + updated findings)

The video references evidence supporting the idea that faster writing without verification harms quality and review dynamics.

• MTR study (updated):

  • Initially reported experienced developers were 19% slower with AI, even when they believed they were faster.
  • Later revised the coefficient to show roughly ~18% gains, attributing early results to learning effects.

• Telemetry from “Pha” (agents accelerating writing without verification):

  • Among 22,000 developers, median time spent reviewing code jumps by 441%.
  • 31% more merges are done without review.
  • Interpretation: teams scale agent writing but abandon verification rather than scaling validation.

---

“Culture” / skeptical stance: expertise isn’t dead, it shifts

The speaker addresses objections that agents hallucinate or can’t produce reliable systems:

• Mentions quotes/references suggesting improved agent reliability after a specific time (notably “since December”).
• Highlights:
  • Linux Foundation hosting an agents-focused initiative with major companies (Anthropic, OpenAI, Microsoft, Google, Amazon).
  • The agent.md standard reportedly adopted by 60,000+ open source projects.
  • A skeptical founder (“Skever”) reframing the problem as reliability and judgment, not “resistance to automation.”

Main conclusion: the debate shifts from “can agents code?” to “how do we supervise and verify reliably?”

---

Product/standards guidance: a “passage plan” to reach Stage 2

The video offers a practical guide—“Step 1 toward Step 2”—intended for most viewers.

Project 1: The “contract” (instruction file)

• Create an instruction file the agent reads every session:
  • agent.md / cloud.md (Anthropic naming vs equivalents).
• Anything the agent must do repeatedly should be included:
  • conventions, compilation commands, “do not touch” areas.
• Claimed benefit: reduces repeated human monitoring and minimizes context loss between sessions.

Project 2: The “examination” (verification loop)

• A prerequisite command the agent runs before presenting results.
• Includes:
  • tests, compilation, linting, and optionally end-to-end browser tests.
• Rule: the agent is not allowed to present work it hasn’t verified.

Project 3: The “sandboxes” (isolated worktrees + permissions)

• Avoid agents working in the same directory.
• Use isolated working copies (e.g., git worktrees / “work tree per project”).
• Manage permissions so authorization prompts don’t constantly interrupt you into manual review.
• Allow manual approval only for sensitive operations:
  • network access, secrets, deletions.
• Early recommendation: start with two agents before scaling to ten+.

Project 4: “Proofreading” (agent-to-agent review)

• Before merging, have a separate agent review the diff:
  • “find what breaks” in a new session.
• Positioning: equivalent to human review—only code that would pass human standards should be merged.
• Emphasis: intervene at verification/merge time, not by continuously watching execution.

Two “done-when” checks (self-auditing)

1. Ask before each agent run: “Would an engineer have done it like that?”
2. Start two projects and then go away for a 2-hour walk.
   • If that feels unbearable, the verification loop isn’t trustworthy yet.

---

Counterintuitive trap described

Trap: increasing the number of agents before the verification loop earns trust. Result: output accelerates, quality silently collapses, and the “bill” arrives later as technical debt and rework.

---

Token/cost gauge and “token maxing” warning

The speaker proposes using token usage to estimate agent workload and cost efficiency:

• Converts typical per-token pricing into a rough “all-inclusive” rate (with examples like $2/$10 token costs for models).
• Estimates that a $100 tool invoice corresponds to ~25–30 million tokens passing through the system.
• Warning: token counters may mislead because some include tokens read as well as written.

Risk: “token maxing” as a KPI

• As token consumption becomes a goal, it becomes a bad measure (invoking Goodhart’s law).
• People optimize for “burned tokens” rather than ROI.

---

How to interview/grade an organization’s agent maturity (3 questions)

To identify which stage a team is truly at, the speaker proposes:

1. How many agents run in parallel, and are they isolated?
2. Show the verification loop: what runs without human triggering?
3. Who connects/merges the final deliverable, and under what standard?

Expected stage behaviors:

• Stage 0: responds with “our license/tooling.”
• Stage 2: responds with command names/tools and process, not just products.

---

Main speakers / sources (as mentioned)

• Boris Cherny: creator of Claude Code; also credited via subtitles with “Entropique”; authored the stage progression scale via an artifact generated by Claude Code.
• Microsoft: cited for publishing a similar scale based on internal telemetry.
• MTR: the most cited anti-AI statistic study; includes revised findings.
• Pha: telemetry report covering ~22,000 developers.
• André Carpathier: credited with the phrase “verb coding,” referenced as writing less code manually after agents improved.
• Linux Foundation: agents initiative; agent.md adoption mentioned.
• “Skever”: skeptical figure; quoted as focusing on reliability/judgment.