Boris Cherny, described in the source as the creator of Claude Code, said in a public talk for developers that he has not written a line of code by hand over the past year. Even so, he said he still submits dozens of pull requests a day, with a personal record of 150 in a single day.
According to the talk, Cherny keeps 5 to 10 Claude conversations open at once in the mobile app. Each conversation can contain multiple agents. He said hundreds of agents run during the day, and the number rises into the thousands at night as they take on deeper work. The models write all of the code, while he no longer touches the code directly.
Loop is the operating model
Cherny said the key to managing that many agents inside one codebase is a loop. He called Loop the simplest and most useful mechanism he has seen, and said he sees it as the future.
In his description, Loop lets Claude schedule repeatable jobs on a timer. A task can run every minute, every five minutes, or every day, then continue with little direct supervision once it is in place.
He said he has dozens of loops running on a permanent basis. One watches his pull requests, fixes continuous integration issues, and rebases automatically. Another is meant to keep CI healthy by identifying and repairing unstable tests. A third checks X every 30 minutes, gathers user feedback, clusters it, and sends it back to him.
Cherny also gave an example in which he asked the model to run a data query. The model replied that the data kept changing, proposed starting a loop, and suggested producing a fresh report every 30 minutes. He approved the idea and asked for delivery through Slack, and the model handled the rest.
He said recently that he no longer writes prompts and instead writes loops. He also suggested that even that step may not remain manual for much longer.
From turn-by-turn prompting to system design
The source frames this as a broader shift in how work gets done. The older pattern was simple: the user writes one instruction, the model answers, and the next instruction follows. The newer pattern is to build a small system that can find work, execute it, and return output on its own, then let it keep running.
The article notes that Anthropic recently launched Routines, moving the same kind of mechanism to the server side so work can continue even after the user closes the laptop.
That changes what the engineer does. In Cherny’s account, the model writes the code while he designs the system and reviews output. When dozens or even hundreds of pull requests arrive from agents in a day, his actual job is to decide which ones can be merged and which ones should be sent back.
He did not describe that shift as AI replacing engineers. Instead, he said people are moving from direct operators to designers of automated systems. The center of gravity moves away from writing each line correctly and toward building a system that can produce correct code on its own.
He also predicted that within another year, safeguards such as prompt injection defenses, command validation, and manual approval would matter less because models would become more likely to do the right thing by default.
Inside Anthropic, AI agents coordinate through Slack
Cherny said this is not limited to his own workflow. According to him, hand-written code has become rare across the company, and even SQL is now produced by models. He said it would be difficult to find more than a few lines of code that were still typed out by a person.
He also described another internal scene: when several of his Claude agents are writing code inside loops, they can go into Slack and talk with colleagues’ Claude agents to align on points that are still unresolved. Groups of AI agents meeting in Slack, dividing work, and then returning to execution has become routine at Anthropic, according to his account.
The team structure he described is also broader than engineering alone. Engineering managers, product managers, designers, data scientists, finance staff, and user researchers are all writing code. Their formal job functions remain, but each person also gains a general ability to dispatch AI to do work.
/goal is the acceptance layer
The source raises a practical question: why does a self-running system not turn into a high-speed machine for producing bugs? Cherny’s answer is acceptance.
Loop stays on track because it uses a goal-driven mechanism, represented inside Claude Code by the /goal command. The user defines a target, such as getting all tests under /tests/ to pass and leaving lint clean. After each step, a separate small model checks whether the target has been met. If the answer is no, the work continues. If the answer is yes, the loop stops.
The model that scores the outcome is not the model that performs the work. The article presents that design choice as the heart of the loop system.
Without that layer, an overnight loop could keep submitting bad code in bulk. Cherny said he had already validated that point in practice. In an earlier workflow discussion, he argued that the most important step in getting the most out of Claude Code is giving it a way to verify its own work. Once that feedback loop exists, he said output quality often rises by 2x to 3x. In his telling, making AI check itself can matter as much as moving up an entire model generation.
A widely shared Fable 5 guide points to the same two commands
The article also cites a Fable 5 guide that circulated widely on X. After three weeks of hands-on testing, the author said most people were still using Fable 5 the way they used ordinary Claude, which meant missing the part that was actually worth paying for.
That guide highlighted three core capabilities that, in the author’s view, separate Fable 5 from earlier Claude models: long-running autonomous work, self-verification, and the ability to read dense charts and diagrams.
The first point is duration. Earlier models were described as short-distance runners. Fable 5, by contrast, was presented as the first model built for multi-day autonomous work. Inside Claude Code, a user can hand over a multi-day project, and the model can stage the plan, dispatch sub-agents, and keep working until the target is met.
The second point is self-checking. Instead of declaring a task finished as soon as it completes the main work, the model writes tests, runs them, finds errors, fixes them, and only then reports completion.
The third point is chart comprehension. The guide author said Fable 5 was more reliable than Opus 4.8 on items such as financial report tables, graphics embedded in PDFs, architecture diagrams, and dashboard screenshots. In the source account, Opus 4.8 would occasionally misread columns or confuse axes, while Fable 5 remained more stable.
Still, the guide argues that those capabilities only become useful when paired with two commands: /goal and /loop. Without them, the user is paying twice the price for a chatbot. With them, the purchase is closer to hiring an autonomous worker.
How the guide defines /goal and /loop
/goal is meant to push toward an endpoint and stop when it gets there. /loop does not aim for a final endpoint. It runs on a schedule until the user tells it to stop.
The guide sets a clear rule for /goal: the completion criteria must be specific, and the task should include a fallback path if it fails.
That is why “improve this code” is a bad goal in the guide’s framework. It cannot be verified. By contrast, “make every test under /tests/ pass, only modify files in /src, and stop to report back after three failed attempts” is a good goal because every condition can be checked.
/loop is for repeated work on a timer. The guide gives examples such as checking error logs every 30 minutes, surfacing severe issues, and explaining them in plain language, or scanning an inbox every hour, summarizing new mail, and drafting replies where needed.
Its shorthand division of labor is simple: use /goal when there is a clear endpoint, use /loop when the work repeats on a schedule, and combine the two when the system should keep running until a condition is met.
The guide also includes a practical warning before handing over control: set a spending cap first. If an uncapped /goal runs into a hard problem, token usage can rise quickly.
A 20-minute local context system
Another part of the guide focuses on memory. It says Fable 5 does not remember the user by default. Each new session starts without business context, writing preferences, client background, or operating assumptions.
The proposed fix is a local context system that can be assembled in about 20 minutes. The setup consists of one folder, two Markdown files, and a skill set, and the guide breaks it into four steps.
Step 1: create a workspace folder
The guide suggests making a folder such as fable-workspace and treating it as the single source of truth that the model should read before starting work. Suggested contents include a one-page summary of the business and priorities, standard operating procedures, key facts about active projects, frequently cited strategy documents, and a decision log. Each file should stay within one page, because overly long material consumes context space.
Step 2: create a memory file
The second file is claude-memory.md. The guide recommends adding an instruction that says any important detail about the business, the user’s preferences, or current circumstances should be added there in short form and tagged with a date whenever it appears in conversation. That way the system can carry forward new client information or other background into the next session.
Step 3: create an instructions file
The third file is claude-instructions.md. This is where the user defines operating rules for every session: read the memory file before starting work, check past decisions before making recommendations, ask questions instead of guessing when uncertain, and report back after finishing while flagging items that need human review.
Step 4: connect it inside Claude Code
The final step is to point Claude Code at that folder with /add or place the relevant setup in CLAUDE.md. Once connected, each session starts with the full background already in place.
The guide says that setup has another benefit: if the user switches to another AI tool later, the context package can move with them.
Cost control and model tiering
On cost, the guide recommends an 80/20 approach: reserve Fable 5 for the 20% of tasks that truly need its strengths.
Inside Claude Code, the source says Fable can also delegate cheaper execution work to sub-agents. In that setup, Fable produces the plan, Sonnet and Haiku handle lower-cost execution, and Fable returns at the end to review the output.
The article closes that loop with a simple breakdown of Cherny’s “overnight AI army.” Strip it down, and the system rests on three pieces: a model that can work on its own, a standard that clearly defines what “done” means, and a loop that keeps running on schedule.
The model and the loop already exist. What remains scarce, the source argues, is the person who can define the finished state clearly enough for the model to pursue it.