Meta’s attempt to become “AI native” offers a useful warning about how organizations measure AI productivity. The problem was not that AI failed to produce work. It produced a great deal of it! The problem was that production increased much faster than the surrounding system’s ability to turn that work into useful outcomes.
Reuters reported that code changes to Meta’s internal software platforms and infrastructure increased 220 percent year over year as AI use expanded. Changes that resulted in new or upgraded features reaching users increased only 36 percent. At the same time, major technical and security incidents reportedly rose 40 percent, while the time employees spent firefighting them increased 70 percent.[1]
Those numbers describe a systems problem that is easy to miss when AI success is measured near the point of generation.
Production Capacity Is Not Absorption Capacity
Organizations have at least two relevant capacities when they introduce generative AI and autonomous agents:
- Production capacity: how much work the organization can generate.
- Absorption capacity: how much work the organization can safely review, integrate, govern, deploy, and maintain.
AI can increase the first much faster than the second.
That matters because useful work does not end when code, documentation, analysis, designs, or plans are generated. Software still has to be reviewed, integrated, tested, secured, deployed, observed, and maintained. Documentation still has to be validated against the product, fitted to the information architecture, reviewed for audience and policy requirements, published, and kept current. Decisions still have to survive contact with architecture, users, budgets, regulation, and other decisions already in motion.
When production capacity exceeds absorption capacity, the extra work does not disappear. It becomes queues, review burden, coordination overhead, technical debt, incidents, rework, and cognitive load.
The organization may therefore look dramatically more productive at the beginning of the pipeline while becoming less effective at the system boundary, where work actually reaches users.
AI Often Moves Work Instead of Removing It
This is why simple activity metrics can be misleading. Organizations can count prompts, documents generated, code produced, tickets closed, or tasks completed because those numbers are visible and easy to attribute to an AI tool.
But generation frequently creates additional work elsewhere in the system:
- Generated documentation creates verification and editorial work.
- Generated code creates testing, security, integration, and maintenance work.
- Autonomous agents create monitoring, exception-handling, and recovery work.
- Faster individual contributors can create new bottlenecks for downstream teams.
The right question is not whether AI made one worker or one stage faster. It is whether the entire system delivered more useful work with an acceptable level of supervision, risk, and rework.
A more useful way to think about automation value is:
Net automation value = useful work delivered - supervision - verification - coordination - remediation - recovery
The exact formula will differ by organization, but the principle is durable: measure what survives the whole system, not merely what enters it.
Find the New Constraint
When AI accelerates one part of a workflow, the limiting factor often moves. Review may become the constraint. Security may become the constraint. Integration, governance, deployment, user research, or decision-making may become the constraint.
There is a useful analogy from chemistry and biology. Many reactions have a rate-limiting step: the slowest stage constrains the speed of the overall process. Change the environment and you may accelerate one part of the reaction, but the limiting step does not necessarily disappear. It can shift somewhere else.
AI adoption behaves similarly. Faster generation can make review the constraint. Faster review can expose integration, governance, deployment, or decision-making as the next constraint. The system gets faster only to the extent that its rate-limiting steps move with it.
That means AI transformation cannot stop at tool adoption. Organizations need to ask what happens to the surrounding workflow when production becomes cheaper and faster, who owns the new bottlenecks, and what capacity must change with them.
This is specifically a capacity-mismatch problem. The work may be perfectly parallelizable, but the organization cannot absorb it as quickly as AI can produce it. That is different from another AI-scaling problem: work that has a genuine critical path and cannot be parallelized no matter how much capacity is available.
Both matter, but they require different fixes.
For the capacity problem, the central question is not:
How much more can we produce?
It is:
How much additional work can the system safely absorb and turn into something useful?
That is the number worth optimizing.