Gergely Orosz’s reporting in The Pragmatic Engineer, published this week, documents something significant happening inside Meta: between 30 and 50 percent of engineers on its core product, infrastructure, and security teams have been reassigned to data labeling and reinforcement learning from human feedback work. His estimate puts the total at roughly 6,500 Meta engineers — about one in every five or six of their full headcount — now doing annotation and labeling as their primary function. The purpose is Meta’s frontier AI training pipeline, which requires high volumes of precisely labeled data that third-party contractors have not been able to provide at the quality and specificity that frontier model training demands.
This is a deliberate strategic bet, not an organizational accident. Meta has concluded that training data quality labeled by its own domain-expert engineers will produce competitive differentiation at the frontier model level that externally sourced data cannot replicate. That calculation may prove correct — at Meta’s scale, a data flywheel built from internal engineering labor is genuinely defensible. What it also creates is an organizational cost that is rarely modeled explicitly, and that is the useful signal for technology leaders at every other scale.
quadrantChart title Organizational Approaches to Building AI Capability x-axis Low Disruption to Engineering Teams --> High Disruption to Engineering Teams y-axis Lower AI Capability Gain --> Higher AI Capability Gain quadrant-1 High-stakes frontier bets quadrant-2 Scalable advantage quadrant-3 Falling behind quadrant-4 Diminishing return Embed AI tools in engineering workflow: [0.2, 0.62] Hire dedicated AI/ML specialists: [0.28, 0.72] Upskill existing engineers on AI: [0.32, 0.58] Redeploy engineers to data labeling: [0.82, 0.78] Buy third-party training data: [0.12, 0.38]
The Rundown: What Orosz Documented
Published in The Pragmatic Engineer this week, Orosz’s reporting draws on sources inside Meta and on the public footprint of the restructuring. The context: Meta is training frontier-class models — Watermelon has benchmarked competitively with GPT-5.5 — and training data quality is one of the primary variables in frontier model performance. To get data at the quality level its pipeline requires, Meta turned to its own engineers rather than to external annotation vendors.
The scale is what makes this significant. Between 30 and 50 percent of core engineering headcount is not a small experiment — it is a structural organizational shift. Teams that were building product, maintaining infrastructure, and running security are now doing labeling work as their primary contribution. The engineering culture that built those systems continues to exist, but it is doing something different.
Orosz also reported a separate incident during this same period: an Instagram account-takeover outage in which an AI customer-support system was manipulated into sending password-reset codes to an attacker’s email. That incident is a separate organizational failure from the redeployment story, but the timing is a reminder that aggressive AI deployment in customer-facing workflows requires adversarial testing that is easy to skip when organizational attention is on training pipelines.
For Engineers: What Happens to Team Knowledge During Redirection
When a team of infrastructure engineers is retasked to data labeling, two dynamics begin immediately. The first is skill atrophy: engineers who stop solving infrastructure problems begin losing the situational pattern recognition that made them valuable for that work. This is not a hypothetical long-run effect — it starts in weeks. The on-call rotation, the post-incident review, the architecture discussion: these are practices that sharpen through repetition. Interrupting them for months has a cost that cannot be easily reversed by returning the team to their original role.
The second dynamic is selective attrition risk. Engineers capable of doing complex technical work at Meta’s level are also capable of finding roles elsewhere where they do that work. Redirection to annotation work does not affect all engineers equally — the ones most likely to leave are the ones who are most valuable to retain. This is a predictable human-capital dynamic that is difficult to model in advance but straightforward to observe in retrospect.
Neither of these dynamics negates the strategic logic of what Meta is doing. But they are real organizational costs that belong in the calculation, and they are costs that compound over time rather than resetting.
For Business Owners: The Opportunity Cost No One Budgets
The organizational cost of redeploying technical specialists to a different function has three components that most companies do not formally track. The first is the direct output loss: what the engineers would have built or maintained in their original role. The second is the attrition-and-replacement cost: finding, hiring, and onboarding engineers to fill gaps created by departures that redeployment accelerated. The third is the organizational momentum loss: the team culture, operating rhythm, and institutional knowledge that existed before the restructuring and may not reassemble cleanly afterward.
For most organizations, the decision is not whether to send thousands of engineers into labeling work — that is a frontier-lab problem at a frontier-lab scale. The relevant question is whether a quieter version of the same mistake is happening. Redeploying specialized technical staff to fill AI gaps — having your infrastructure engineers build internal AI tooling they were not hired to build, having your product engineers support AI training pipelines as a side responsibility — creates the same opportunity cost structure at a smaller scale. The cost is just less visible because the headcount number is smaller and the redeployment is framed as temporary.
Building genuine AI capability into an organization is not primarily a resource-reallocation problem. It is an organizational design problem. The organizations that solve it well tend to add AI capacity incrementally and specifically, rather than borrowing it from the capacity that already exists.
My Take: The Value of a Focused Engineering Team Compounds
At Carvana in 2016, I led a data team of five developers responsible for parsing and processing millions of vehicle records daily using an event-driven architecture. The team was small and its scope was tight — vehicle data systems for external partners and internal stakeholders, nothing more. What that focus produced was outsized precision. Five developers who owned their domain completely, who understood every edge case in the data pipeline, who had seen every failure mode — they delivered results that a larger, more diffuse team rarely does.
What made that team valuable was not just their individual capability but the compounding effect of focused expertise over time. When you redirect a team of that character to a different function — even a useful one — you break the compounding. The institutional knowledge does not pause and wait for the team to return. It disperses.
Meta is making a bet that the data flywheel its engineers can build will outcompete the institutional knowledge they are spending to build it. At Meta’s scale, with Meta’s resources, that bet may pay off. For most technology organizations, the more durable competitive advantage is an engineering team that stays focused on the problems it was built to solve — and an AI strategy that amplifies that team rather than redirecting it.
