The Review Queue Beats the Chat Box: Lessons from Boris Cherny
Nov 2026What the creator of Claude Code says about building with agents, and what I think it means for interface design.
Why this is on my mind
Boris Cherny is the creator and head of Claude Code at Anthropic, and he's been unusually open about how he works. As a designer, I don't care about the coding details. I care about what his workflow implies for the interface of managing agents.
What's true right now
The role and the moment. The Computer History Museum describes him as creator and head of Claude Code at Anthropic and hosted him in a September 2026 conversation asking what happens when coding stops being the hard part. Fortune reported in June 2026 that he hadn't handwritten a line of code in eight months and manages a large fleet of AI agents, with days where the number runs into the tens of thousands.
The design stance is minimal. One profile describes Claude Code as a Unix-style utility with raw model access and minimal UI, composable with hooks, plugins, skills, and sub-agents. A summary of his own comments says it runs locally with no virtualization, which he attributed to always picking the simplest design.
The process changed. A Latent Space profile notes he said cheaper implementation changed his own design process: he could ask Claude Code for three working prototypes and compare them instead of writing a long design document first.
The team shape changed. Notes from his Acquired interview describe a team where every engineer does scoping, talks to users daily, pulls data, and ships design work, and designers ship code. Fortune also reported the traits he says Anthropic hires for: generalists, empiricists, and low-ego people, per the same summary.
What I notice
The tools he describes have almost no interface. That's a statement of confidence in the model, but it also reveals a gap. When one person runs many agents in parallel, the hard question isn't how to talk to one agent, it's how to know which of them needs you right now.
A day with ten agents
Illustrative: my own sketch, not a sourced fact.
Imagine the morning. Ten agents have been working. Six finished cleanly, two are blocked waiting on me, one looks odd, and one is about to do something I cannot undo. In a chat window those are ten transcripts of equal weight. In a review queue they are four different kinds of attention. The difference is not speed alone. It is that the attention goes where it is needed first, instead of wherever the latest message arrived.
The queue answers one question. Which of these needs me right now? Everything else on the screen exists to make that answer fast and trustworthy: a one-line summary of what changed, a diff I can read at a glance, and a single motion to accept, redirect or stop. That is a small amount of text carrying a lot of weight, and it is a design problem as much as a language one.
My hypothesis
This section is my opinion, not a sourced fact.
The primary interface for managing agents will be a review queue ranked by stakes, not a chat window, and designers will spend more time on that queue than on any conversational surface.
A chat box scales to one conversation. A fleet needs triage: what finished and is safe to accept, what is blocked on me, what looks wrong, what is about to do something irreversible. The design problems are prioritization, summarization (what changed, in one line), diffs you can trust at a glance, and one-motion actions (accept, redirect, stop).
It also reframes the designer's role. If prototypes are cheap and engineers handle scoping and design too, the designer's scarce contribution is the judgment of what a good outcome looks like and the system that lets a person check agents' work quickly. That's closer to orchestration and quality control than to drawing screens.
Where the queue could fail
My opinion, based on the tradeoffs above.
Ranking can be wrong. A queue sorted by stakes is only as good as its idea of stakes. If a risky change is ranked low, the interface has taught me to look away from exactly the wrong thing. I would want the ranking to be explainable, not just a number. I would want to see the ranking logic in plain words, so a person can disagree with it before it costs them something.
Summaries can flatter. A one-line summary of what changed is useful and also a place where mistakes hide. If I accept work because the summary sounds fine, I have moved the trust from the work to the sentence. I would keep the path from summary to real diff very short. The safeguard I would try is a visible link from each summary to the evidence beneath it, one tap away and never buried.
How I'd test it
Simulate ten agents completing tasks of mixed risk. Give users either a chat transcript or a ranked review queue. Seed two bad outputs. Measure how many users catch both, and how long it takes.
What would change my mind
If agents become reliable enough that review is rarely needed, the queue shrinks to exceptions, and the interface becomes mostly notifications and trust, not triage.
What I would design first
Illustrative: my own sketch, not a sourced fact.
The accept and stop actions. Before any dashboard, I would get the smallest actions right: accept, redirect, stop. They have to be fast, reversible where possible, and clear about what they affect. If those three feel solid, the rest of the queue has something to stand on. A slow or ambiguous accept would push people to approve in batches without looking, which defeats the point of having a queue.
Then the triage states. I would name the states plainly: safe to accept, blocked on me, looks wrong, about to be irreversible. Four states are easier to learn than a score. I would test whether people can sort a mixed batch correctly in seconds before adding any polish. If testers hesitate on a state, the label is wrong, and that is cheaper to fix on a prototype than in a shipped product.
References
- Computer History Museum, In Conversation with Boris Cherny, Creator of Claude Code
- Fortune, Boris Cherny says there are days he manages tens of thousands of AI agents at once
- Latent Space, Boris Cherny profile
- WorkOS, Key takeaways from Boris Cherny on building Claude Code
- Layer3 Labs, Who is Boris Cherny
- BestBlogs, Boris Cherny: Building Claude Code (profile)