November 2026

2nd Order Change: Build or Rebuild for AI?

AI agents deliver more changes, but approvals remain a bottleneck. How companies can test new working rules and why starting a new company makes this easier.

Suppose the development team from the first two articles uses AI agents that independently create and test clearly bounded changes. The agents deliver far more completed changes than the team did before, yet releases barely increase because every change still has to go before the change board individually. Leadership therefore asks the team to speed up approvals through better documentation, additional meetings and an AI-assisted preliminary review.

These measures can shorten waiting times and allow more releases. None of them changes the requirement for people to approve every individual change.

Where change reaches its limit

In Organizational Transformation (1986), Levy and Merry distinguish between two orders of change. First-order change improves and adjusts a system without touching its core. They define transformation as second-order change: profound change across several organisational levels and dimensions, including a shift in fundamental principles of thought and action. This connects with Watzlawick, Weakland and Fisch from the first article: improving the existing way of working or changing its underlying rules. In our example, the key distinction is whether people must still assess every case personally or instead set the conditions under which routine cases may be checked automatically.

Better documentation, additional meetings and an AI-assisted preliminary review improve work within the existing rules. More test environments or reviewers can also increase throughput. Even individual human approval can be accelerated this way. As long as it is mandatory for every change and remains the bottleneck, however, Goldratt's bottleneck logic from the first article ties throughput to human review capacity. If agents deliver more changes ready for review than people can approve, the backlog grows. More work by the agents alone then does not increase releases.

Anthropic's October 2026 report on its own workforce also describes how human attention can constrain work with agents. Commits per engineer were five times the level of six months earlier, although the authors stress that the increase cannot be cleanly attributed to agents. Meanwhile, around 80 per cent of the total duration of interactive agent sessions was spent waiting for human input, and the report identifies human attention as a bottleneck for agent work. This waiting time covers human input generally; it does not measure an approval queue.

Why transformation is needed

If suitable routine changes are to be released independently of individual human approval, the organisation must change the approval rule itself. People then set the conditions for checking changes, monitor results and decide on exceptions. Their judgement shifts from each routine change to designing and overseeing the procedure. A change to approvals can thus become the starting point for a transformation that changes tasks, responsibilities and collaboration. Control remains, with a different distribution of responsibilities.

Jacob Sansbury, founder of Spawn, a platform where players build multiplayer games with AI, describes one possible form of this rule change. By his account, Spawn has dropped pull requests but has other agents review changes before they are incorporated; fixed technical gates remain for irreversible actions. The team condensed past decisions into principles and built AI-based reviewers from them. These decide cases already covered by principles and refer questions requiring fresh human judgement to people.

According to Sansbury, Spawn incorporated around 1,000 changes a day into its codebase in the week before these reviewers were introduced; on 10 October 2026, the figure was 7,250. A single peak day does not establish a sustained daily level, and the founder's figures do not demonstrate that the reviewers alone caused the increase. The comparison illustrates where he saw the bottleneck.

At Anthropic, standing instructions for agents grew within a year from a few hundred to around 8,500. The average share of each employee's interactive sessions devoted to designing and steering the agent environment rose from 10 to 22 per cent. This included instructions, specifications and reviewing other agents. It illustrates a shift from execution towards design and oversight; it does not, by itself, demonstrate the removal of individual approvals.

This oversight also places demands on collaboration. Decisions need to be accessible to agents so they can work to the agreed criteria. At Anthropic, conversations that leave no written trace are therefore discouraged. The report also describes greater emphasis on autonomy and judgement when assessing technical candidates. These are examples of changing practices and expectations in a rapidly growing company. They establish neither that agents alone caused the changes nor that every change to an approval rule triggers a comprehensive transformation.

The specific way of working must also remain open to development. According to its founder, Spawn had been working towards largely autonomous agents since 2024. This way of operating only became possible with Anthropic's Fable model in June 2026, and the team had to keep changing its processes afterwards. The development team can therefore start with a direction and a provisional design, then use the results to assess which further adjustments are needed.

Testing new working rules

The examples and the first two articles suggest the following approach to trials in an established company. These steps organise the decisions involved; depending on the results, earlier assumptions may need to be revisited.

First: identify the bottleneck. The team establishes where completed work waits and which capacity limits its throughput. It first checks whether additional capacity or better preparation can deliver the required throughput at an acceptable cost. If so, the existing rule can remain. If the requirement for individual human approval itself is to be tested, the team records which tasks might allow a change and which consequences remain unclear. In our example, a trial could establish whether suitable routine changes can be released sooner, at least at the same quality, without individual approval by the change board.

Second: establish who can change the rules. As the second article set out, it must be agreed before the start which rules are open to testing and who has authority to change them. In the example, that is the requirement to put every change before the change board. The responsible authority needs to permit a limited exception for the trial. The agreement also specifies the criteria and timing for assessing the results, and who will then decide on adoption.

Third: make decision criteria explicit. Criteria previously held in experienced people's judgement need to become accessible to automated checks, as Spawn did with its reviewers and Anthropic with its standing instructions for agents. For the development team, this would mean writing down the change board's criteria so that routine cases can be checked against them. Doing so also reveals which criteria can be stated and which cases still need human assessment.

Fourth: connect checks and feedback. Within a bounded area, agents work under the rules being tested. Automated checks before a change are combined with continuous monitoring and rapid correction in production. According to its founder, Spawn complements review by other agents with hourly releases, runs its full test suite every 15 minutes and can roll back faulty changes within 30 seconds.

The trial in the established company compares similar tasks under the existing and proposed procedures. Outcome quality, the consequences of errors and lead time are central, alongside the costs of operating, checking and correcting the work. Revert rate can provide useful information, but it cannot replace a quality measure. Sansbury reports that around 0.9 per cent of changes were reverted, while also describing how faults are fixed through further changes. Neither those corrections nor undetected faults are fully captured by the revert rate.

Fifth: decide on adoption. Whoever has authority to change the rule assesses the results against the agreed criteria. Approval can be removed for suitable tasks, modified or retained. If quality, the consequences of errors or costs are worse, shorter lead time alone does not justify adoption.

The workflow needs continued observation after adoption, too. Following Goldratt's bottleneck logic, the next step is to establish where work now waits and whether additional capacity, better processes or another rule change would help. At Spawn, the founder describes the remaining human work as including judgement about quality, even saying no to a solution that works.

Why building new is easier

In an established company, the changes from the opening example are a natural first step. They can be approved within existing responsibilities, whereas changing the approval requirement needs agreement with a body whose own work is affected. Spawn, by contrast, oriented the company towards agents early and changed its processes as their capabilities grew, although its specific way of working also emerged gradually. A small, founder-led company can test such rule changes with fewer organisational dependencies than a company where several departments share responsibility for the same workflow. That additional coordination explains part of the difference.

In Meeting the Challenge of Disruptive Change (2000), Clayton Christensen and Michael Overdorf locate an organisation's capabilities in its resources, processes and values, including established routines and the criteria used to set priorities. Different organisational arrangements, including separate units, may be appropriate depending on whether new tasks fit existing processes and priorities. Applied to our example, the change board brings together human review of changes. If the volume of changes rises sharply while other methods of checking them become available, its role needs reassessment. A company still building its way of working has more freedom to combine those methods from the outset.

Socialisation adds to this, as the second article described with Van Maanen and Schein: new members learn an organisation's norms. Anthropic's headcount tripled within a year. Many employees therefore joined while agents were already part of day-to-day work. Socialisation theory suggests that these practices can become the default for new arrivals. The same mechanism that stabilises the old rules in the second article can also anchor new ways of working.

The organisational advantages of starting a company do not, however, establish how much autonomy is appropriate. Anthropic notes that many of its employment practices cannot be replicated across the wider economy; it also builds the models its employees use. Spawn develops a platform for games. Simon Willison, reviewing the founder's account, finds it hard to imagine this way of working on software where mistakes carry higher stakes.

The autonomy described at Spawn is most suitable for trials where the consequences of errors can be contained and corrected quickly. Rolling back a software change does not automatically reverse harm already done. Safety-critical control systems or executed payments may therefore still require prior approval, even if the code itself could be corrected quickly.

What an established company can take from this

Copying Spawn's removal of pull requests and hourly releases does not create equivalent conditions. An established company needs explicit decision criteria, suitable checks and feedback from production. It also needs to establish who can change responsibilities across departments and which tasks remain with those currently accountable for the work.

A dedicated unit with its own decision rights can create room for this. O'Reilly and Tushman describe how such units can have their own processes while remaining connected to the existing business through shared leadership. Before our trial begins, it should be clear who will assess the results, against which criteria, and when adoption into operations will be decided. The agreement establishes the procedure; the outcome remains open.

The development team at the start therefore explains to leadership how far approvals can be accelerated within existing rules. It also proposes a trial of the approval rule itself. Its first task is to work with the change board to make the board's decision criteria explicit. The responsible decision-maker and success criteria are then agreed for the trial. Whether suitable routine cases can proceed without individual approval depends on a comparison of outcome quality, the consequences of errors, lead time and costs. If the comparison favours the existing procedure, approval stays, and throughput remains tied to the change board's available review capacity. If the new way of working proves better, the responsible authority can use that evidence to change the rule for operations.

References

  • Christensen, C. M. & Overdorf, M. (2000). Meeting the Challenge of Disruptive Change. Harvard Business Review, 78(2).
  • Goldratt, E. M. & Cox, J. (1984). The Goal: A Process of Ongoing Improvement. Great Barrington: North River Press.
  • Levy, A. & Merry, U. (1986). Organizational Transformation: Approaches, Strategies, Theories. New York: Praeger.
  • O'Reilly, C. A. & Tushman, M. L. (2004). The Ambidextrous Organization. Harvard Business Review, 82(4).
  • Sansbury, J. (2026, 29 October). How I Built the Most AI-Pilled Company in the World. X. https://x.com/jsnnsa/status/2115623382721126826
  • Van Maanen, J. & Schein, E. H. (1979). Toward a Theory of Organizational Socialization. Research in Organizational Behavior, 1.
  • Watzlawick, P., Weakland, J. H. & Fisch, R. (1974). Change: Principles of Problem Formation and Problem Resolution. New York: Norton.
  • Willison, S. (2026, 29 October). Building a multiplayer game world with autonomous Fable-class models. https://simonwillison.net/2026/Oct/29/how-i-built-the-most-ai-pilled-company-in-the-world/
  • Wilmers, Catipon, Massenkoff & McCrory (2026). How Employment is Changing at Anthropic. Anthropic. https://www.anthropic.com/research/employment-at-anthropic

Let’s discuss your AI application.

I help you assess your situation and identify the next steps.

Request a Conversation