One year in, two members of the Claude Code team look back at how the workflow shifted from prompting a single agent to orchestrating trees of thousands. The through-line is a recursive goal: turn every mistake into a CLAUDE.md rule or a skill so Claude can "run forever," make verification a first-class step so the agent can actually run and check its own work, trust auto mode instead of plan mode, and take the next leap — from talking to an agent to talking to a loop or a routine that prompts Claude for you.
CLAUDE.md or turn it into a skill. Compound these and the agent can "just like run forever."The conversation opens on how modest the beginning was: when Claude Code first shipped it was "like a little video" posted to Slack that drew a whopping two reactions, and it was, generously, "quite good" at very easy engineering tasks. A year later the picture is unrecognizable. Instead of prompting one agent, the team now runs "armies of agents" — an agent prompting agents prompting agents, "a tree of like thousands of agents." The single most important habit that makes this possible is treating every failure as a permanent fix rather than a one-off nudge.
"I don't tell Claude to do it differently, I tell it to write it to the CLAUDE.md, or to like make a skill"
Do that consistently, and the agent stops repeating its mistakes and "can just like run forever." This is the loop as a recursive goal: each correction is captured so the next run starts smarter.
The team says the thing everyone misunderstands is verification. When people hear the word they think unit tests, lint, or type-checking — but those were "obviously really easy to automate" and were already automated. Verification for agents is something slightly different: can the agent run the thing? Figuring out how to give an agent that ability "takes a little bit of mental work" because it's often not straightforward.
The turning point was watching Opus 4 test itself: told to build a feature and then test itself "in like bash," it opened its own Claude CLI and exercised the feature it had just written. What felt astonishing then is now routine — loops run against the iOS simulator, the Android simulator, and desktop. One concrete example is a desktop development skill an engineer added that teaches Claude to spin up the local desktop app and use computer use to click around, invoke new UX, test edge cases, and fix and re-check issues on its own. When the skill hits a snag (say, a flaky staging environment), Claude even reads Slack to check whether staging is down or someone else already hit the bug, then updates the skill.
A recurring delight is that on this team "everyone codes." Designers put up PRs (an early horror that quickly became normal once the code looked good), PMs make changes directly in the app, the finance team runs projections in Claude Code, and data scientists keep Claude Code up on their screens. The pattern generalizes: across enterprises, engineers adopt Claude Code first, then adjacent roles look over their shoulder, realize how powerful it is, and pick it up. Because Claude writes the code, what matters more is the idea — so people with product and business context "come up with better ideas," and the traditional roles start to merge.
Asked which use cases are pushing the limit, the answer is routines. One engineer who launched voice mode set up a routine that listens for every ticket, GitHub issue, and bug report about voice mode; his Claude picks it up, proactively opens a fix, and pings him the PR. He added a second routine that watches for any bug report left unanswered for five hours and puts up a fix, merging the ones that are easy to verify. The result is uncanny: a bug the speaker planned to fix that night had already been resolved by "another Claude." Routines, they argue, are the first really obvious application of the Agent SDK — the idea that you can drive Claude Code programmatically. Routines now handle code review, "babysit every PR," fix CI, and rebase — chores nobody has done by hand in a long time.
For synchronous work in the CLI, plan mode used to be the go-to; now it's auto mode. Newer models don't need an explicit planning step: it mattered for roughly Opus 4 through 4.5, but starting around 4.6 and "definitely with four seven" the model just doesn't need it. Auto mode means you start an agent, it begins working, and you move on to the next one without watching it. Crucially, auto mode routes permission decisions to a separate model that checks for security — a big step up from the original yes/no permission prompt, which was the best available "a year and a half ago" before classifiers and better-aligned models.
"we feel that auto mode is more safe than reading every single permission prompt"
The reasoning is human nature: when you approve 99% of requests, your eyes glaze over. Routing the decision to a model that flags anything "suss" — and lets you allow it later — keeps attention on what actually matters. Getting there internally took real work: thousands of transcripts of full agent trajectories were classified for safety, red teamers and internal teams tried to prompt-inject and hack auto mode, and those attacks were turned into evals so the system defends not just against vulnerabilities in the wild but against the most intelligent attacks the team could construct.
The speakers frame the past 18 months as two big leaps. The first: engineers stopped interacting with source code directly and started talking to an agent that writes the code for them. The second is happening now.
"I don't talk to an agent anymore. I talk to loop or I talk to a routine and it prompts Claude for me."
To zoom out, one speaker puts on a "business cat hat" and reaches for a Harvard Business Review case study from the '90s asking why computers weren't yet delivering productivity gains. The lesson: you don't bolt a computer onto a paper-and-pen process — you throw out the filing cabinet and put the computer at the center of every business process. Anthropic does the same with Claude: people ask Claude instead of each other when they onboard, and Claude sits at the center of coding, code review, security review, and paperwork. Because so much work is already digitized and Claude can use a computer and run code, this transition is arriving far faster than the 10–15 years the PC took.
As people go from one agent to dozens to hundreds, the tooling changes. Six terminal tabs with six git checkouts gave way to a single tab using the new agent view and the desktop app, which handles work-tree cloning automatically. Half of one speaker's engineering now happens on a phone via remote control — starting agents, checking in over coffee, kicking off a new build by voice on the spot. On context, both describe themselves as minimalists: prompt engineering matched Sonnet 3.5, context engineering matched Opus 4, but with today's models you give the minimal possible system prompt and tools and let the model figure out the rest.
"I'm a context minimalist, so my general philosophy is tell the model only what it needs to know and let it figure out the rest of it."
Overloading context, they warn, is a form of micromanaging — often the model knows a better route to the same outcome. The team is also making the harness leaner to leave more room for users' own prompts. Looking ahead, they expect a year from now the toolkit will look completely different, with agents running longer, more autonomously, and in far greater numbers — and they're betting the best ideas for that form factor come from the whole team and community, not just from the top.
"I don't tell Claude to do it differently, I tell it to write it to the CLAUDE.md, or to like make a skill"
"we feel that auto mode is more safe than reading every single permission prompt"
"I don't talk to an agent anymore. I talk to loop or I talk to a routine and it prompts Claude for me."
"I'm a context minimalist, so my general philosophy is tell the model only what it needs to know and let it figure out the rest of it."
| Approx. Time | Topic |
|---|---|
| 0:00 | Cold open — the two-reaction Slack launch |
| 0:31 | A year in: from single prompts to trees of thousands of agents |
| 0:57 | The core habit — turn every mistake into a CLAUDE.md rule or skill |
| 1:40 | What verification really means for agents |
| 1:50 | Opus 4 testing itself; simulator and desktop loops |
| 2:24 | The desktop development skill and computer use |
| 3:13 | Everyone codes — PMs, designers, finance, data science |
| 4:51 | Routines: auto-fixing bugs and babysitting PRs |
| 6:41 | Auto mode vs plan mode |
| 7:22 | Permission prompts and why auto mode is safer |
| 9:00 | Making auto mode trustworthy — red teaming and evals |
| 10:28 | Loop — the next leap beyond talking to an agent |
| 11:07 | Business cat hat: the '90s computing-productivity lesson |
| 13:31 | Product vs engineering — the roles are merging |
| 14:29 | Tooling for hundreds of agents: agent view, phone, remote control |
| 16:06 | Context engineering and the context-minimalist philosophy |
| 17:17 | What comes next |