Meta’s internal software platforms and infrastructure saw code changes rise 220% year over year. Changes that led to new or upgraded features reaching users rose 36%. Major technical and security incidents rose 40%; firefighting time rose 70%.
These four figures come from internal posts reviewed by Reuters. They capture the organizational gamble behind Meta’s Project OT: the company treated prospective agent capacity as actual operating capacity.
Reuters reconstructed the proposed design from scores of internal documents, posts and recordings and more than 20 sources. The plan was that conventional product teams of 10–20 people...
Would give way to 3–5-person pods: three or four fluid-role “builders” plus a Pod Lead.
Designers, researchers, data scientists, data engineers and ML specialists would be shared across pods. By June, at least 11 engineering and research units had adopted variants of this design.
Meta confirmed Project OT to Reuters and acknowledged that the most extreme scenarios contemplated shrinking some teams by up to 60%. It stressed that several major units were outside the exercise, the scenarios included redeployments, and 60% was never a company-wide layoff target. The project explicitly combined cost cutting with organization design.
The pod architecture economizes on the scarcity of local coordination, which is a real problem both at first glance and in my own data. After all, four people can decide faster than 15. Beyond that, generalist roles reduce internal handoffs, and pooling specialists removes duplicated capacity. And yet! A builder who needs design, research, data, ML and security now competes across shared service queues, because small teams in large organizations not optimized for their needs will always sit inside a larger, slower coordination system.
What we are observing is that AI does radically increase software development throughput, which is bounded by review, integration, release and general operating capacity. Pooling that integration capacity creates a bottleneck. Reuters’ metrics do not necessarily prove that Project OT caused the incident spike, but they are consistent with this failure mode.
Meta made some ways of working changes, too. Direction or Pod Leads steered daily work without formal people authority. Org Leads overseeing roughly 30–50 people owned ratings and promotions, supported by HR and unspecified AI systems; Meta says people made the decisions (important for regulators). This generally would give the person closest to the work more "free speed" without a full manager load (good). It also offers Pod Leads responsibility without reward authority, and Org Leads career authority without daily observation (not as good). This can work, but only with explicit conflict rules and unusually good information. Reuters found at least one new Pod Lead confused about lacking manager training and ratings tools.
The same pod model should perform very differently as those capabilities spread and become more ~industrialized. Meta’s own engineering posts show credible gains from specialized agents with bounded codebases, explicit tools, context, guardrails and human approval.
So what can future designers and managers learn from this? Changing team size, role boundaries, management spans and career authority before shaping the bottlenecks is a recipe for thrash. Designing for sustainable production changes is another thing entirely.
Reporting note: Reuters’ special report relies on internal Meta documents, posts, recordings and more than 20 sources. The internal percentages are not a controlled experiment, use different denominators, and are not identified to Project OT pod adopters. Meta declined to comment on the disruption data. Project OT also mixed AI-native design (some with layoffs, redeployments and cost reduction.
