What Meta's Collapsed AI-Native Plan Actually Proves

Meta Platforms Inc. canceled the second wave of its AI-native Project OT, which had been planned for November, hours before the first wave of roughly 10% staff cuts went ahead on May 20, according to Reuters. Internal data reported by Reuters showed code changes to Meta's internal platforms up 220% year over year versus only 36% for user-facing features, while major technical and security incidents rose 40% and firefighting time rose 70%, highlighting a bottleneck in verification rather than generation.

Two takes on Meta's collapsed AI-native plan are already hardening into consensus, and both are wrong in the same way. One says this proves AI can't actually replace knowledge workers: the technology overpromised, Zuckerberg blinked, case closed. The other says Meta was simply too ambitious, that a more gradual rollout would have landed fine. Both takes are arguing about ambition. Neither is looking at the mechanism sitting inside Meta's own numbers. Here's what's confirmed. In January 2026, Meta began exploring what it internally called Project OT: a push to make the company "AI native" by having AI agents perform much of the daily work currently done by thousands of employees, with smaller, more talent-dense human teams overseeing the result. In scenario planning, executives explored cutting some teams by as much as 60%. That was a planning ceiling, not a company-wide target Meta committed to, and Meta has disputed the characterization of Project OT as a finalized "bold plan." The second wave was canceled before a final number was fixed. The first wave, roughly 10% of staff, went ahead on May 20. Hours before it did, Zuckerberg canceled the second wave, which had been planned for November. Reuters could not establish exactly what prompted the change of course. That distinction matters: I'm not going to manufacture a cause Reuters itself could not establish. The more interesting evidence is elsewhere. Two internal Meta data points reported by Reuters expose the problem. One, attributed to CTO Andrew Bosworth in an early-June internal post: code changes to Meta's internal software platforms and infrastructure were up 220% year over year, while changes that produced new or upgraded features reaching Meta users were up only 36%. The public reporting does not establish that the 220% increase was specifically agent-generated, and the underlying definitions of those metrics have not been disclosed. The second is harder to dismiss as a simple measurement problem. Internal posts in March and April described AI agents taking what they called "large-scale, disruptive actions that humans are unlikely to execute." Major technical and security incidents subsequently rose 40% year over year, while the time employees spent firefighting them rose as much as 70%. Meta declined to comment on those internal figures. Treat those figures accordingly. They are internal Meta accounts reported by Reuters, not audited public metrics. But they reveal something important even without assuming more than the evidence allows. They reveal the difference between generation and organizational throughput. I've called this the Hourglass Firm . As generation gets cheaper with more code, more content, more agent-initiated action, produced faster, the organization doesn't necessarily become proportionally more productive. Instead, the bottleneck can move downstream to whoever has to verify that output before it can be trusted and acted on. The organization becomes an hourglass: wide at generation, narrow at verification, wide again at accountability. That distinction matters because generation is easy to measure. Verification is not. A company can count lines of code, documents produced, experiments run, tickets closed and actions initiated. It is much harder to count the work required to determine which of those outputs are correct, safe, useful and worth shipping. That is where the 220/36 gap becomes interesting. It does not prove that AI agents generated 220% more code and failed to ship it. The reporting does not establish that. What it does show is a much broader phenomenon: activity inside the organization increased dramatically faster than user-facing output. That is the distinction the AI productivity debate keeps missing. A machine can become much busier without the company becoming proportionally more productive. The 40/70 figures show the other side of the same problem. Internal Meta posts described agents taking disruptive actions and, during the same period, major technical and security incidents rose 40%, with employee firefighting time rising as much as 70%. If the purpose of deploying agents is to free human capacity, an operating model that creates more exceptions for humans to diagnose and absorb has a very different economics from the one the restructuring assumes. And that is where the Hourglass Firm becomes more than a metaphor. The people at the narrow point: reviewers, verifiers, integrators, incident responders can look inefficient when viewed from the perspective of raw generation. They aren't generating the visible volume. They are slowing the machine down. But that "slowness" may be the mechanism that turns generation into reliable output. Cutting those roles because you've "captured AI productivity gains" mistakes the wide part of the hourglass for the bottleneck. Notice what this argument does not require. It does not require knowing whether the incident data specifically triggered Zuckerberg's decision. Reuters couldn't establish that. It does not require believing that every extra code change was generated by an AI agent. The reporting doesn't establish that either. And it doesn't require treating Meta's internal numbers as audited truth. The argument is simpler: even on Meta's own account, the transformation produced a widening gap between organizational activity and useful output, alongside a rise in the human capacity required to absorb technical and security problems. That is enough to challenge the two dominant interpretations. "AI can't replace workers" treats this as a capability failure as if a better model would have made Project OT work. "Meta was too ambitious" treats it as a pacing failure as if the same operating model, run 18 months slower, would have landed cleanly. Neither gets at the bottleneck. A slower rollout does not automatically fix a transformation in which execution capacity is scaling faster than verification and incident-absorption capacity. It simply gives the same imbalance more time to accumulate, unless the organization changes what it builds alongside the agents. What has to scale is not caution. It is verification. It is review depth. It is integration. It is incident response. It is the human capacity to determine whether an increasingly large volume of machine-generated activity should actually be trusted, shipped or acted upon. That is the question I would ask of any company moving toward an agent-driven operating model: Is verification and incident-absorption capacity being scaled anywhere near the rate at which execution capacity is being scaled? Because if it isn't, the organization may discover a strange version of AI productivity: the machines produce more, while the humans spend more of their time making sure the machines haven't created something the company cannot safely use. That is not an argument against AI. It is an argument against confusing generation capacity with organizational capacity. Meta's Project OT is interesting precisely because it may have exposed that distinction from inside the company that was trying hardest to erase it. What actually made Zuckerberg pull back the second wave, Reuters still doesn't know. But the more important question may be one step upstream: What happens when you make generation dramatically cheaper before you make verification dramatically cheaper too? That is where the Hourglass Firm begins.