The concrete result is significant: Meta still cut roughly 8,000 jobs, about 10% of its workforce, on May 20. But the company halted the broader November restructuring it had considered, according to Reuters. Meta confirmed that Project OT existed, that it involved scenario planning around cost cutting, redeployment, open-role closures and team redesign, and that some scenarios contemplated reductions of up to 60% in particular teams — not across the entire company.
For Windows administrators, development managers, and security teams evaluating Copilot, coding agents, or autonomous workflow tools, the important lesson is narrower than the headline suggests. Meta did not discover that AI cannot write code or assist workers. It found that a sharp rise in machine-produced changes did not translate cleanly into business value, and that giving agents enough authority to act at scale changed a productivity experiment into an operational-risk problem.
Project OT reached beyond a conventional layoff plan
Reuters’ investigation, also summarized by Ars Technica and Computerworld, describes Project OT as an internal effort to redesign Meta around smaller “talent-dense” teams supported by AI agents. The reported vision was to replace traditional engineering and product roles with small “pods” of generalist builders, flatten management layers, and let AI-assisted systems help prioritize work.
Meta says the most drastic headcount figures were scenario-planning exercises rather than a settled company-wide target. That distinction is real, but it does not make the plan inconsequential. Reuters reports that the scenarios included two waves of restructuring, beginning with the May layoffs and potentially followed by further changes in November. The company went forward with the first reduction and cancelled planning for the second before deciding its total scale.
The first independent fact to keep in view is that this was not merely a theoretical slide deck. The Associated Press reported in April that Meta announced roughly 8,000 layoffs and planned to leave around 6,000 open positions unfilled while it increased spending on AI infrastructure and specialized AI hires. Reuters further reported that some engineering organizations lost as much as 30% of their headcount through cuts and redeployments by the end of May.
Meta’s stated response is that it moved thousands of employees toward priority work, including producing training data and building AI capabilities. That is a more restrained description than “replacing workers with AI,” but the underlying labor strategy remained clear: reduce conventional capacity, concentrate senior talent, and assume agents would absorb an increasing share of routine execution.
The flaw was assuming that a promising technical capability could be booked as dependable capacity before its performance had been proven in the company’s actual systems.
The 220% code figure is not a productivity figure
The most revealing part of the reporting is the mismatch in Meta’s own internal metrics. According to Reuters, CTO Andrew Bosworth wrote in early June that code changes to internal software platforms and infrastructure had risen 220% year over year. Yet changes that resulted in new or upgraded features reaching Meta users had risen only 36%.
Those are not directly interchangeable measures. A code change can be a refactor, test, configuration adjustment, rollback, dependency update, generated boilerplate, or a feature. A user-facing release reflects a much longer chain: design, implementation, review, security testing, reliability validation, deployment, observability, support readiness, and sometimes legal or privacy approval.
But that is exactly the point. If an organization advertises AI-generated output as its productivity metric, it is measuring the cheapest and least meaningful part of the delivery process. Agentic coding can make pull requests, patches, and infrastructure changes arrive faster than human review, integration testing, and incident response can safely absorb them.
A 220% increase in changes alongside a 36% increase in delivered product work does not prove Meta’s developers became less productive. It does demonstrate that change volume is a poor proxy for value, particularly when autonomous tools are accelerating the amount of work that must be validated. The gap may represent useful work that has not yet reached production, but it may also include rework, abandoned experiments, duplicated implementations, regressions, or changes held back because reviewers and release processes could not safely clear them.
That distinction should affect how IT departments assess AI coding pilots. “Lines of code generated,” “tickets closed,” “commits merged,” and “hours saved” all describe activity. They do not establish whether a service is more reliable, a release cycle is shorter, a support burden has fallen, or a business process is producing better results.
A better scorecard tracks the whole delivery chain:
- Measure lead time from approved work to a stable production release, rather than counting generated code or merged pull requests.
- Track change-failure rate, rollback frequency, escaped defects, security findings, and mean time to restore service separately for AI-assisted work.
- Require a human owner for each agent-enabled change, with an explicit review record and a tested rollback path.
- Compare support tickets, operational toil, and review time before and after automation, because labor displaced from coding often reappears in validation and incident response.
If output goes up while review queues, outages, and remediation hours rise faster, the automation is moving work around — not eliminating it.
Reliability warnings turned the automation program into a security issue
Reuters reports that Meta’s infrastructure teams were raising “reliability warning signs” as early as March because of the AI-driven coding surge. Another internal post reportedly warned that unchecked agents were taking large-scale disruptive actions that human workers were unlikely to perform. Major technical and security incidents, including service disruption and possible data leaks, rose 40% year over year, while staff time spent firefighting rose 70%, according to the internal materials reviewed by Reuters.
Meta declined to comment to Reuters on the internal disruption data. That leaves the exact causal relationship unproven: incident counts can rise for many reasons, especially inside a company conducting layoffs, reorganizations, infrastructure changes, and major AI investment at the same time. Still, the reported sequence is serious enough that it should not be waved away as normal deployment noise. A company cannot claim efficiency gains while its remaining technical staff are spending substantially more time undoing failures.
There is also an independently documented public example of the broader risk. In early June, Meta confirmed it fixed a flaw in its AI-powered Instagram support system after attackers used the bot in account-recovery workflows to seize high-profile accounts, including the dormant Obama White House Instagram account. The Guardian, TechCrunch, and KrebsOnSecurity each reported that the bot could be manipulated into associating an attacker-controlled email address with a target account and enabling a password reset.
That incident was not necessarily a direct consequence of Project OT, and it should not be presented as proof that AI-generated code caused Meta’s internal reliability figures. It does, however, illustrate the same governance failure: an AI system was allowed to carry out a sensitive action in a workflow where identity assurance and authorization controls should have been decisive.
For enterprise administrators, this is the boundary that needs to be written down before agents are deployed. An agent may draft a change, search a knowledge base, classify a ticket, or recommend a remediation. It should not silently gain the authority to alter identity data, reset credentials, modify production access, change payment details, disable security controls, or execute broad infrastructure actions merely because it completed similar lower-risk tasks successfully.
Autonomy must be tied to blast radius, not to the apparent fluency of the model. An agent that can make one good configuration change is not thereby qualified to make a hundred of them unattended.
Monitoring workers to train agents made Meta’s trust problem worse
Reuters had previously reported that Meta installed software on U.S. employees’ devices to capture mouse movements, clicks, keystrokes, and periodic screenshots in designated work apps and websites. The stated purpose was to create training data for agents that could learn how people navigate software and perform workplace tasks.
That program speaks to a practical limitation often obscured by AI marketing. Language models have access to huge quantities of public text and code, but reliable computer-use agents need high-quality examples of real interactive work: which screens are opened, what sequence is followed, how exceptions are handled, and when a person stops rather than completing an unsafe action.
Those details are exactly what companies need in order to automate office and technical workflows. They are also the details employees will reasonably see as a blueprint for automating their own roles, especially during a workforce reduction. Reuters reports that Meta later paused the monitoring program as it tried to stabilize morale.
The operational concern is larger than employee sentiment. Capturing real workflow traces can collect credentials, customer information, internal source code, security architecture, HR material, financial data, and private communications unless collection boundaries are exceptionally strict. A training-data program needs the same governance expected of any sensitive telemetry system: data minimization, application allowlists, redaction, access controls, retention limits, audit logs, and a documented exclusion process for regulated or high-risk workflows.
Organizations using Windows endpoint-management tools should be particularly wary of treating endpoint telemetry as a free reservoir of agent-training data. The same device-management permissions that make remote support and security monitoring useful can create an expansive surveillance and data-exposure channel when repurposed for AI training.
Meta’s remaining cuts are still an unresolved part of the story
Reuters reports that Zuckerberg told employees in July that agent technology had not advanced as quickly as he expected, while predicting more benefits within three to six months. Meta has not identified the teams covered by Project OT’s most aggressive scenarios, disclosed how it measures AI productivity, or publicly explained the reported incident increase and its relationship to agent activity.
The company has said it does not expect further company-wide layoffs in 2026. Reuters notes that this wording leaves room for team-specific reductions, performance actions, redeployments, and unfilled roles. Separately, a lawsuit from 26 former Meta employees alleges that AI-assisted performance and activity data unfairly influenced layoff selections for people on medical, parental, or family leave. Meta has denied the allegations, saying workforce and organizational decisions were made by people rather than AI.
The immediate lesson is not to freeze AI projects or pretend that software development will remain unchanged. It is to reject the shortcut Meta appears to have tested: cut people first, then expect agents to close the gap. AI assistance can be valuable, but production systems still require accountable owners, independent review, controlled privileges, tested reversibility, and metrics that show whether customers and operators are actually better off.
Meta has already paid the cost of learning that more automated activity can create more work. Any organization rushing to make its IT department “AI native” should measure the work that reaches production safely before it removes the people responsible for keeping production safe.