Meta spent 2026 trying to become an AI-native company, and its own internal numbers tell the story. Software changes up 220 percent year over year. Changes that actually reached users up 36 percent. Major technical and security incidents up 40 percent. Employee time spent cleaning them up, up as much as 70 percent. None of that proves the layoffs caused the incidents, and Meta declined to comment on the figures Reuters reported. But it does expose the measurement problem underneath every AI productivity dashboard right now: generated code, closed tickets and shipped changes all count activity, not value. Velocity and productivity are different things. Meta got faster. Whether it got more productive is a separate question, and one most organizations deploying coding agents are not asking.
In 2008, I was building Facebook applications.
It was an exciting time to work on the platform, and an occasionally frustrating one. Facebook Platform never seemed to sit still. APIs changed, capabilities changed, and developers kept adapting. At the 2008 f8 conference, Facebook was already talking about more than 400,000 developers building on it.
The philosophy behind all that churn eventually got captured in Facebook’s famous motto:
“Move fast and break things.”
Almost twenty years later, Facebook is Meta, AI has replaced social apps as the industry’s obsession, and Meta is trying something far more ambitious than changing an API.
It’s trying to redesign how the company itself works.
And “move fast and break things” is very much alive.
The difference this time is that some of what’s breaking may be the systems Meta needs to run.
From AI tools to an AI-native company
Meta’s AI push didn’t start as a plan to give programmers better coding assistants.
In 2025, teams inside Meta started experimenting with much smaller development groups backed heavily by AI. One pilot set up “small tech pods” of just two or three engineers and a designer.
That grew into an internal “AI-Native Playbook.” The line between engineers and product designers could disappear. People would become generalist “builders.” Management layers could go. AI-assisted analysis could help decide what teams worked on.
Then in January 2026, Mark Zuckerberg and other Meta executives put together a much bigger initiative known internally as Project OT, short for Organization Transformation.
According to Reuters, internal planning imagined an “AI native” Meta where AI did a large share of the work employees used to do, overseen by smaller groups of very capable people.
Some scenario planning looked at shrinking individual teams by as much as 60 percent. Meta has stressed that this was scenario planning, not a plan to cut 60 percent of its total workforce, and that many of those scenarios were never carried out.
Still, the direction was obvious.
The question Meta was asking had moved well past “how can employees use AI?”
It was closer to this: what should an organization look like if we assume AI agents can do a meaningful chunk of the work?
That’s a much bigger bet.
May 2026: Meta gets smaller
In May the transformation moved off the whiteboard.
Meta cut roughly 10 percent of its workforce and moved thousands of other employees into priority areas tied to its AI strategy.
Reuters reported that some engineering organizations saw headcount drop by as much as 30 percent through a mix of layoffs and reassignment.
A second restructuring had been pencilled in for November.
It never happened.
Hours before the May layoffs, Zuckerberg cancelled planning for that second company-wide wave. Afterward, he told employees he didn’t expect more company-wide cuts in 2026.
By then there were signs the AI experiment wasn’t going the way Meta expected.
AI produced a lot more code
The most interesting number in this whole story is 220 percent.
According to an internal post from Meta CTO Andrew Bosworth, reported by Reuters, changes to Meta’s internal software platforms and infrastructure were up 220 percent year over year by early June.
If you measure AI productivity by how much software gets produced, that looks incredible.
Another number tells a different story.
Changes that delivered new or improved features to actual Meta users rose only 36 percent.
Sit with that gap for a second.
Software changes: up 220%.
Changes that reached users: up 36%.
AI seems to have massively increased the activity inside Meta’s development machinery without anything close to a matching increase in what customers actually got.
Then there are two more numbers.
Incidents increased 40 percent
Meta’s infrastructure teams reportedly started spotting “reliability warning signs” from the flood of AI-generated code as early as March.
An internal post in April warned that unchecked AI agents were carrying out “large-scale, disruptive actions that humans are unlikely to execute.”
The fallout was real.
According to internal Meta data reviewed by Reuters, major technical and security incidents rose 40 percent over the previous year.
Those included service disruptions and potential data leaks.
Worse, the employee time spent dealing with those incidents went up by as much as 70 percent.
Meta declined to comment to Reuters on these specific figures, so treat them as numbers from internal posts reported by Reuters, not as official Meta metrics.
Even so, line them up:
Software changes up 220%.
User-facing improvements up 36%.
Major technical and security incidents up 40%.
Employee time spent firefighting up as much as 70%.
That’s a very different picture of AI productivity.
And it raises a question every organization rushing to deploy coding agents should be asking.
What are we actually measuring?
Lines of code? Pull requests? Tickets closed? Software changes?
Or reliable business outcomes?
Humans cleaning up after AI
The last number carries an uncomfortable irony.
A big part of the pitch for agentic AI is that it cuts the human labour needed to run an organization.
But if AI lets you generate far more changes while also generating more incidents, the people who are left may just spend more of their day reviewing, fixing and recovering from what the machines did.
The bottleneck didn’t go away.
It moved.
This ties directly to something I wrote in June, Stop Treating AI Like an Employee: What the Meta Support Incident Teaches Us About AI Security.
That piece looked at attackers abusing Meta’s AI-powered support system to take over high-profile Instagram accounts.
My argument was that we shouldn’t think of an AI agent as another employee.
An employee has judgment, accountability, and an understanding of how the organization works. An AI agent is better understood as a highly privileged automation layer running at machine speed.
That distinction matters more every time we hand agents more authority.
Meta has now given us another example.
September: Muse arrives
Earlier this month Meta launched Muse, its personal AI agent.
Muse is the next step in Meta’s agent strategy. This isn’t a chatbot that answers questions.
It takes actions.
It can send email, shop, book travel and operate websites for you. To do any of that, users have to give Muse a lot of access.
Meta leaned hard on security at launch, including running agents inside isolated virtual machines and protecting sensitive credentials.
Less than two weeks after Muse debuted, security researcher Patrick Wardle disclosed a serious vulnerability in the macOS app.
According to Ars Technica, another app or command running locally on a Mac could exploit it to grab Muse’s authentication token and take over the agent.
That’s a big deal, because compromising an agent can be far more powerful than compromising a normal app.
An attacker doesn’t need to build their own way into all your services.
The agent already has access.
Meta pushed out a hotfix quickly after disclosure. But the episode shows the architectural problem organizations are building for themselves as they give agents more and more authority.
The more useful the agent, the more valuable it is to compromise.
This doesn’t prove layoffs caused Meta’s problems
One distinction matters here.
You can’t look at Meta’s layoffs and the incidents that followed and conclude the smaller headcount caused them.
Correlation isn’t causation.
Meta runs one of the largest and most complicated technology environments in the world. Its systems change constantly, and any given outage or security problem could have countless causes.
But we don’t need to prove causation to learn something from this.
By Meta’s own internal data, as reported, the company saw a lot more software changes, a lot more serious incidents, and a lot more employee effort spent cleaning them up, all while it was aggressively experimenting with AI-native engineering.
That deserves attention.
Apparently Meta thought so too.
In July, Zuckerberg reportedly acknowledged internally that agentic technology hadn’t moved as fast as expected. Meta backed away from the second broad restructuring Project OT had contemplated.
That doesn’t mean Meta is giving up on AI. Far from it.
It means Meta is finding out what deploying AI at organizational scale actually looks like.
The productivity metric is wrong
The lesson here goes well beyond Meta.
Organizations are starting to measure AI adoption with metrics like:
- percentage of developers using AI;
- percentage of code generated by AI;
- number of tasks completed by agents;
- reduction in time required to produce software; and
- number of employees required to perform a function.
Every one of those can look fantastic while the organization gets less productive.
Say AI lets an engineering team ship three times as many software changes.
Sounds like a productivity revolution.
Now say those changes bring more bugs, more code review, more security incidents, and more senior engineering time spent troubleshooting.
You haven’t necessarily gotten more productive.
You may have just gotten faster.
Velocity and productivity are different things, and I think a lot of AI dashboards right now are confusing the two.
A real measure of AI productivity has to account for the whole system: useful output, minus errors, minus remediation, minus oversight, minus security risk, minus operational cost.
That’s a much less exciting equation than counting generated code.
It’s also a lot closer to measuring value.
Move fast, but know what breaks
“Move fast and break things” made sense for Facebook in 2008.
The company was young. The platform was changing constantly. Developers experimented, Facebook experimented, things broke, and everyone learned.
By 2014, Facebook had run into the limits of that approach. Zuckerberg famously swapped the motto for “Move fast with stable infrastructure.”
There was a reason for the change.
At a certain scale, breaking things gets expensive.
AI makes that lesson more urgent, not less.
A coding assistant can produce changes faster than a human developer. An autonomous agent can take actions faster than a human employee. An organization full of interconnected agents could eventually run faster than any organization we’ve built before.
But speed amplifies mistakes just as well as it amplifies good decisions.
Anyone thinking about building an “AI-native” organization should be watching Meta closely.
The takeaway isn’t that AI doesn’t work. It isn’t that organizations shouldn’t automate or get smaller as the technology improves.
It’s that AI-generated activity is not organizational productivity, and treating them as the same thing is how you end up firefighting.
Meta increased internal software changes by 220 percent. Over the same stretch, its internal data reportedly showed major technical and security incidents up 40 percent and the human effort to handle them up by as much as 70 percent.
And less than two weeks after launching one of its most capable consumer AI agents, a researcher found a flaw that could turn the agent’s broad privileges against its own user.
Almost twenty years after I started building Facebook apps, Meta is moving extraordinarily fast again.
It’s going to break things. That part isn’t in question.
What I want to know is whether we’re getting any better at measuring what breaks along the way.
Frequently Asked Questions
What was Meta’s Project OT?
Project OT, short for Organization Transformation, came out of a January 2026 leadership gathering. It imagined an AI-native Meta where agents handled a large share of the work employees used to do, supervised by small groups of generalist “builders.” Some scenario planning looked at shrinking individual teams by as much as 60 percent across two waves. Meta says this was scenario planning to evaluate cost-cutting and redeployment, not a plan to cut 60 percent of the workforce.
What do Meta’s internal numbers actually show?
Four figures, from internal posts reported by Reuters. Changes to Meta’s internal software platforms and infrastructure rose 220 percent year over year. Changes that delivered new or improved features to users rose 36 percent. Major technical and security incidents rose 40 percent. Employee time spent resolving those incidents rose by as much as 70 percent. Meta declined to comment on the specific figures, so they are reported internal numbers rather than official Meta metrics.
Did the layoffs cause the incidents?
Nobody can say that from this evidence, and I’m not claiming it. Correlation isn’t causation, and Meta runs one of the largest and most complicated technology environments on earth, where any given outage could have countless causes. What the data does show is that a lot more software changes, a lot more serious incidents and a lot more cleanup effort all happened during aggressive AI-native experimentation. That’s worth paying attention to without overclaiming.
What’s the difference between velocity and productivity?
Velocity is how much activity you generate. Productivity is how much value survives it. An engineering team shipping three times as many changes looks like a revolution until those changes bring more bugs, more code review, more security incidents and more senior engineering time troubleshooting. A real measure of AI productivity has to net it all out: useful output, minus errors, minus remediation, minus oversight, minus security risk, minus operational cost.
Which AI adoption metrics are misleading?
Percentage of developers using AI, percentage of code generated by AI, number of tasks completed by agents, reduction in time to produce software, and number of employees needed to perform a function. Every one of them can climb impressively while the organization gets less productive, because each counts activity rather than outcomes.
What happened with Meta’s Muse agent?
Muse is Meta’s personal AI agent, and it takes actions rather than just answering questions: sending email, shopping, booking travel, operating websites. Shortly after launch, security researcher Patrick Wardle disclosed a vulnerability in the macOS app that let another locally running app or command capture Muse’s authentication token and take over the agent. Meta shipped a hotfix quickly. The structural lesson stands: the more useful the agent, the more valuable it is to compromise, because the agent already holds the access an attacker would otherwise have to earn.
Why shouldn’t an AI agent be treated like an employee?
Because an employee has judgment, accountability and an understanding of how the organization works. An AI agent is better understood as a highly privileged automation layer running at machine speed. That distinction gets more important every time we hand agents more authority, and it’s the reason a compromised agent is more dangerous than a compromised app.
Does this mean AI doesn’t work?
No, and that isn’t the takeaway. Organizations can automate and can get smaller as the technology improves. The point is narrower: AI-generated activity is not organizational productivity, and treating them as the same thing is how you end up firefighting. Meta is finding out what deploying AI at organizational scale actually looks like, which is useful for everyone else watching.