Meta's internal platforms saw 220% more changes. User-facing features rose 36%.

The evidence does not establish that AI caused every incident, that these were audited productivity statistics, or that AI-assisted coding failed. The conclusion available here is narrower and more useful: Meta scaled the production of changes past the rate at which its organization could convert them into outcomes it could stand behind.

Project OT explored a structure in which AI would perform much of the daily work and smaller, talent-dense groups of people would supervise it. Scenario planning considered reducing some teams by as much as 60% through layoffs, reassignment, closed positions and performance management.

Meta did not execute that scenario. It cut roughly 10% of employees in May 2026 and cancelled planning for a second company-wide round expected in November. Reuters reported employee opposition, disappointing internal signals about AI agent productivity, investor pressure, and a later acknowledgment from Mark Zuckerberg that the agentic trajectory had not moved as fast as anticipated. Meta said Project OT included multiple scenarios and that not all of them were operating assumptions or adopted plans.

That boundary matters: 60% of the workforce was not replaced. The defensible criticism is conceptual rather than numerical. The company appears to have explored an organizational premise before its operational evidence supported it — that greater AI agent output should allow fewer people to remain around that output. The reported figures indicate that review, incident response and integration remained a material part of the work.

Software delivery is a chain, not a typing contest. A change must express a useful intent, fit the current architecture, avoid conflict with parallel work, satisfy security and reliability constraints, pass review and tests, survive deployment, and improve an outcome somebody values. Generation is one stage of that.

When generation becomes cheaper, the constraint moves downstream: more proposals enter review, dependencies collide, edge cases reach testing, and changes compete for integration and release capacity. Unless the rest of the system scales or becomes more selective, queues grow and risk accumulates.

RADAR matters to this argument because it does not answer the bottleneck by assuming one AI agent can replace one reviewer.

It uses a risk-stratified funnel. Changes are classified by authorship and source type, passed through eligibility gates and static checks, scored for risk, reviewed with a language model, and subjected to deterministic validation before qualifying changes may land. High-risk or ambiguous work stays outside the automated path.

Meta did not meet excess code supply by adding an unconstrained synthetic employee. It built a management layer out of classification, authority boundaries, evidence, deterministic gates and escalation by risk. In that design the unit that matters is not the code-generating AI agent but the whole path from a proposed change to a verified result that policy permits to land.

The phrase itself is not the problem. IBM describes software robots performing specific processes in partnership with human colleagues; Salesforce presents digital labour as augmentation as well as autonomous execution. Serious vendors acknowledge that people remain part of the system. The difficulty is in the employee-shaped abstraction.

That abstraction invites a leader to map a role into visible tasks, automate what can be observed, count the synthetic output and compare it with headcount. A digital worker then looks like a cheaper unit of labour, because the surrounding human work has been placed outside the calculation.

A job is not a list of actions. It also involves deciding which action is appropriate, noticing when the situation no longer matches the playbook, negotiating competing goals, carrying tacit history, maintaining trust, accepting consequences, repairing failures, and knowing when not to proceed. These are hard to see in a process map precisely because working organizations perform them continuously. Reduce staffing or management capacity before the work is redesigned and the burden shifts into review queues, escalations, rework, incidents, inconsistent decisions and lost institutional context.

Under those conditions software output can rise while the system as a whole becomes less productive.

Tokens, generated files, tool calls, completed AI agent tasks, code changes and estimated hours saved are operational signals. None of them is a business outcome. Even landed code volume misleads if it creates maintenance, incident and cognitive costs that arrive later. The measurement boundary has to include the work that makes the output trustworthy, and the outcome observed after it is put into use.

For a human–AI team doing software work, an adequate measurement boundary includes at least:

• verified change throughput, not raw diff volume
• time from approved intent to a verified result
• human review and exception-handling time
• returns, rollbacks, incidents and repair work
• cost per authorized and released result, including inference and human attention
• the share of AI agent errors converted into tests or controls
• the user or business outcome observed after release

The same logic applies outside software. A research AI agent is productive when its claims survive source verification and support a decision, not when it produces fifty pages. A sales AI agent is productive when the relationship and the revenue are still healthy after the handoff. A support AI agent is productive when the customer's problem is safely resolved. Message volume and closed conversations are proxies for those outcomes, not the outcomes.

The replacement narrative assumes a workforce can be decomposed by technical feasibility alone: automate whatever an AI agent can perform, assign the rest to people.

That variation is not resistance to progress. Work contains different forms of agency, and a person may welcome automation for repetitive reconciliation while keeping control of a customer promise, a hiring decision, a diagnosis, or the interpretation of ambiguous evidence. The question is not whether an AI agent can perform a task. It is what combination of execution, judgment, authority and accountability the outcome should require.

8Hats Lab reads this as an argument for changing the design object. The useful unit is the human–AI team: the smallest combination of people, AI agents, tools, context and controls that can carry work from intent through verification, authorization, use and outcome measurement. Its composition changes with the work — AI agents researching options in parallel while a person chooses the trade-off; one AI agent implementing while another checks independently; a deterministic gate qualifying low-risk output under a stated policy and escalating the rest.

Four properties distinguish it from a collection of digital employees. One outcome boundary, so costs and failures cannot be exported to another team and left out of the productivity claim. Differentiated authority, so an AI agent can act without being allowed to approve its own action, and a person can hold decision rights without becoming the manual router for every step. Shared, versioned state, so intent, evidence, commitments and unresolved uncertainty survive individual conversations. And learning as a system, so a repeated error becomes a test, a changed task contract, a permission boundary or an escalation condition rather than another reminder pasted into the next prompt.

This is a working proposal, not a validated result. It has not been tested against a controlled comparison, and it makes the standard harder rather than softer: it asks an organization to show that automation improved the measured outcome after coordination, review, rework, incidents and human attention are counted.