From Building to Bounding
Anthropic reported that, as of May 2026, Claude authored more than 80% of the code merged into its codebase. In the same paper, the Anthropic Institute argued that the world should develop a way for frontier labs to verify and coordinate a slowdown or temporary pause if the technology moves too far, too fast.
Those facts belong together. Claude is doing most of the coding in this example, whilst the company building it says the labs may need a credible mechanism for slowing the work down. The capability is moving quickly. The means of containing it are harder.
It is tempting to file the first fact under “impressive” and ignore the second. That gets the operating problem backwards.
Skilled production has usually been the thing organisations ration, including engineers, analysts, designers and writers.
In Anthropic’s case, that constraint has shifted sharply. Building more code is no longer the scarce part of the example. Deciding what the system should build, what it may change and where a person must step in has become the harder work.
That is the shift from building to bounding.
When a system only drafts, a person can catch a mistake before it moves. When the system can act, one mistake can travel through every service and record it can reach before someone steps in. The design question becomes concrete. What may the system touch? What may it change? Which decision must come back to a person? Engineers call the limit on that movement blast-radius control.
The natural response to cheaper production is to produce more. Wire in another agent, automate another step and show the activity in the quarterly update. Each new agent also widens the set of things the organisation has allowed software to do. If nobody has set its limits and named the owner, one confident mistake can become an operational incident before a person sees it.
The immediate job is to decide what should be built and draw a clean line around what each system may do. A bounded system cannot prevent every error, but it can limit how far one wrong action travels. No model upgrade makes that decision for the organisation.
Three decisions matter here. Judgement asks whether the system should exist. Constraint sets what it may decide and what returns to a person. Accountability names who owns the outcome when the system acts in the organisation’s name. Each is a decision about the work, not the model.
Somewhere in your operation, a system is already building or deciding faster than anyone can check it. Where is it? Who drew the boundary around it? If the first answer is easy and the second is not, that is the first piece of work to revisit.
Trueform works with operational and technology teams to choose where AI belongs, build the change and produce the evidence needed to use it in real work.