AI moves your constraint. It does not remove it.

Gartner expects worldwide AI spending to reach $2.59 trillion this year, up 47 percent. McKinsey surveyed 1,719 business leaders and found that 37 percent could attribute some EBIT impact to AI, the same share as the year before. Six percent qualified as high performers.

Spending grew by almost half. The share of companies who can find the result in their earnings did not move at all.

The comfortable explanation is that measurement is still immature. That explanation is mostly wrong, and this year produced two cases that show why. One organization is enormous, the other is tiny. Both got a large, real, measurable acceleration out of AI. One converted it into shipped work. The other converted it into incidents. The models were not the variable.

What Meta's own numbers show

In January, Meta executives created a program codenamed Project OT, short for organization transformation. Reuters reported the details in August after reviewing internal documents and speaking with more than 20 people, and Meta confirmed the program's existence. The plan explored reducing some team headcounts by 60 percent and called for two rounds of layoffs. One HR executive put the total reduction at roughly 25 percent or more. An internal document defined "AI native" as a company where AI-ready tools and agents interact, workflows are automated, and new builds are AI-first.

The first round of layoffs happened in May. Mark Zuckerberg canceled the second.

The reason sits in two figures from an early June internal post by CTO Andrew Bosworth, reported by Reuters and covered by Ars Technica:

Six times the activity. A third more output.

The gap did not evaporate. It reappeared as cost. Internal posts described AI agents taking "large-scale, disruptive actions that humans are unlikely to execute," a 40 percent increase in major technical and security incidents against the prior year, and employee time spent resolving those incidents rising by as much as 70 percent. In July, Zuckerberg told a company meeting that the trajectory of agentic development over the previous four months "hasn't really accelerated in the way that we expected."

Read that sequence in order, because the order is the lesson. Meta committed to an organizational structure in January, cut staff against it in May, and only established in June and July that the capability the structure assumed was not there.

The same wall, from the other side

For the past year I have worked with a direct-to-consumer personalization business, from before its MVP through launch and into growth. It went from about 15 people to about 40. It is the closest thing I have seen to a genuine AI-native operation, and it hit exactly the same wall Meta did.

The company could not launch without a catalog. It needed more than 10,000 unique designs, each with its own premise, written content, and distinct visual style, aimed at a young and unforgiving audience that recognizes generic AI output instantly. A traditional operation would have needed hundreds of artists, writers, and designers working for years. We built a generation pipeline and produced the catalog in about six weeks, with two people running it.

Then we met the constraint.

Generated500

Published after review200

Sent back for rework150

Discarded150

Review took longer than production. It still does. Around 30 percent of what the pipeline produced had to be discarded, either because it read as generic AI output or because it carried defects a customer would notice. Across the whole program, close to 70 percent of our time went to reviewing and evaluating output, against 30 percent building the systems that produced it.

That ratio is the part nobody plans for.

The constraint moved. That is the entire problem.

Meta's engineering was never rate-limited by how fast code could be written. It was limited by review, integration, and the capacity to absorb change without breaking things. Accelerate the writing and you have not removed that limit. You have pushed more work into it, which is why 220 percent of the activity produced 36 percent of the output and a 40 percent rise in incidents.

Our catalog was never rate-limited by how fast a design could be generated. It was limited by how fast a human could decide the design was good enough to sell.

This is old industrial logic arriving in a new domain. Speeding up a step that is not the bottleneck does not increase throughput. It increases work in progress, and work in progress that nobody can absorb turns into defects. The reason it catches capable organizations by surprise is that AI makes the acceleration so cheap and so visible, while the constraint it exposes is downstream, diffuse, and staffed by people who were already busy.

So the screening question for any AI initiative is not "can AI do this task." The answer is almost always yes, and that answer has no economic content. The question is: if this step were ten times faster tomorrow, what would become the new limit, and are we willing to fund it?

Meta could not answer that in January. It found the answer in June.

Substitution and expansion are not the same investment

There is a second distinction in these two cases that matters as much as the first.

Meta applied AI to work it was already doing. Every workflow it touched had an incumbent process, an existing review path, and an established rate of absorption. Substituting AI into that inherits all of those limits and pushes against them harder.

The catalog was different. That work was not slow before. It was absent. No plausible budget would have paid hundreds of people for several years to produce a launch catalog for an unproven product, so the project simply would not have existed. AI did not make an existing process faster. It moved a project from impossible to viable.

That pattern repeated. A five-person marketing team began producing daily video and image content at a volume that would previously have required an agency. Two product managers started building working prototypes and handing them to engineering, which removed a design bottleneck that twelve engineers had been waiting on, and took the path from idea to shipped feature down to days. None of those were accelerations of existing work. All three were projects that had never been on the roadmap because they were not worth attempting.

Expansion has more headroom than substitution, because there is no incumbent process whose constraints you inherit. It is also where the McKinsey high performers are likely to be found, though the survey does not say so directly. What expansion does not buy you is exemption. Our catalog project was pure expansion and it still ran straight into a review constraint within weeks.

The evaluation layer is what you are actually buying

Here is the line item that appears in no business case I have ever read.

Once generation is cheap, the binding cost of an AI program is deciding whether the output is any good. That cost is real, it is permanent, and it is mostly human at the start.

We had to build an automated evaluation workflow to judge catalog quality. It was not in the original plan. Once it existed, auditing all 10,000 designs cost about $400 in inference, which is the strongest argument I can make that AI can relieve the constraint it creates, provided you treat that as an engineering problem rather than an afterthought.

That $400 is also the most misleading number in this article, so here is the rest of it.

The inference is 2.4 percent of what evaluation actually cost. Every business case I have read for an AI program costs the $400 and omits the $16,500, because the $400 arrives as a vendor invoice and the rest arrives as people doing work that nobody labeled as an AI cost. A cost model you can populate for your own workflow, including the acceptance rate that most business cases quietly assume is one, is in The AI Transformation Sequence.

What could not be automated was the input to it. Building the golden set, the curated examples of good and bad output that any evaluation depends on, meant people reading through the library and the agent logs by hand, deciding what quality meant, case by case. There is no version of that work a model does for you, because it is the definition of the standard the model will be held to. The conversational agent needed its own evaluation suite, running continuously to catch regressions, which is now a standing cost in our deployment pipeline rather than a project.

Against that, the direct spend is almost a rounding error: roughly $100 per employee per month for assistant subscriptions, and around $1,000 a month in API costs at the peak of catalog production. Anyone budgeting an AI program from vendor pricing is costing the cheapest part of it.

Some work should not be accelerated at all

A multinational consumer products company I worked with had a subtler problem, and it involved no pipeline and no queue.

Employees began using AI to draft internal communications. A decision that would previously have gone out as three bullet points in an email arrived as a five page document. Managers replied in kind, and a point that needed one sentence in a chat message came back as a research brief.

Nothing was constrained. Everything got slower. Action items went missing inside documents that were thorough and unreadable, and the failure had a peculiar symmetry: the sender frequently did not know exactly what had been said on their behalf, and the reader could not find the decision inside the detail.

The fix was to stop. Leadership issued a directive that AI was not to be used for routine internal communication. Using it to think through a strategy stayed fine. Using it to write the memo announcing that strategy did not.

That case is worth sitting with, because the constraint framework does not cover it. For most work, more output is good up to the limit of what can be absorbed. For this work, more output is worse output, because the reader pays a cost for every word and the value of the message falls as its length rises.

Which gives a test. Between the generation and the person who bears the cost of it, can you put a filter? A catalog can be reviewed before a customer sees it. A ticket queue can be triaged before a project manager reads it, which a global manufacturer I worked with discovered after wiring chat messages straight into its ticketing system and losing the ability to distinguish an urgent request from a passing remark. A memo cannot be filtered, because the person bearing the cost is the person it was written for.

Where no filter is possible, generation is the wrong tool, and the correct decision is to leave the work alone.

What to do before you commit

Four things, and none of them require a new platform.

Ask whether a filter is possible before you generate anything. If the output goes straight to the person who bears the cost of reading it, there is nowhere to put quality control, and volume works against you. That work is better left alone.

Find the constraint before you fund the acceleration. For the workflow you are about to automate, write down what limits throughput today. If the answer is not the step you are automating, you are buying work in progress rather than output.

Fund the evaluation layer in the original business case, not the second year. Budget the human review it depends on, and expect a discard rate. Ours was 30 percent, and knowing that early would have changed our staffing plan.

Do not restructure ahead of measured capability. This is the specific mistake that cost Meta a canceled program and a round of layoffs it did not need to run. Prove the throughput in production, with the new constraint funded, and only then change who reports to whom.

The organizations that will find AI in their earnings next year are not the ones that automated the most work. They are the ones that funded the bottleneck the automation exposed, and left alone the work that was never going to survive being done faster.