AI headcount cuts have a poster child, and its numbers don’t look good for us humans. Block cut nearly half its company in February, from over 10,000 people to just under 6,000. It told shareholders a much smaller team using its own tools could do more. By May, Block reported that its incident rate after a production code change had dropped more than 40% from the prior quarter. If you’re a CISO fighting an AI headcount cut, start by admitting the CFO’s got a point.
The CFO’s Case for AI Headcount Cuts Holds Up
Block’s Q4 2025 shareholder letter announced the cut, and its Q1 2026 letter returned data reinforcing the decision. By mid-April, production code changes per engineer were up more than 2.5x from January, while incident rate after a production code change was down more than 70% from a year earlier and more than 40% from the fourth quarter.
Block isn’t the only organization on the AI headcount-reduction path. Challenger, Gray & Christmas counted 120,136 announced job cuts that employers attributed to AI through September 2026. That’s about 21% of all cuts announced this year. Cloudflare cut more than 1,100 people in May and said it was restructuring for the agentic AI era.
Eli Goldratt gave the CFO the math for this decision. He and Jeff Cox wrote The Goal, the 1984 novel built around the Theory of Constraints (TOC). It’s standard reading for any MBA program worth its salt, including mine. Goldratt Research Labs credits him with throughput accounting, a way of judging every decision with three numbers.
Throughput (T) is the money the business brings in, revenue minus the costs that come with each sale. Investment (I) is the capital tied up in the system. Operating expense (OE) is what you’d pay to keep capacity running, which includes every salary in your security budget. Throughput accounting combines the three into net profit (NP) and return on investment (ROI).
TOC practitioner Eli Schragenheim puts the rule simply: grow T faster than OE. He compares every change in OE against the change in T it’s expected to bring, which you can write as a change in net profit.
On a security team, the reviewers are the analysts and engineers who check and approve what the rest of the business wants to do (AI use cases, access requests, security exceptions, and production changes). If you cut one, OE drops by that salary, so ΔOE goes negative and net profit goes up on paper as long as T holds.
Goldratt’s own people don’t argue with the CFO on this. Schragenheim and Jürgen Kanz write that a technology pays off when sales grow or when costs’re cut “in a way that doesn’t harm the delivery performance” and the quality customers see. That’s a test, and on Block’s own measure, Block passes it.
As a leader, you should always assess your team’s headcount against its capacity, regardless of AI. For a security team, I’d focus on the number of review requests coming in each week, how long they wait, and how much longer they’d wait with one less reviewer. Block’s data covers about two months after the cut, and it tracks code output and incidents after code changes. None of it shows what a staffing cut does to security reviews, which is exactly where AI is adding work vs. reducing it.
The Constraint Moved to the Checkers
The Five Focusing Steps are Goldratt’s procedure for working a constraint, the one step that limits what the whole system can deliver. Goldratt Research Labs lists them in order:
Identify the constraint
Exploit it so none of its time is wasted
Subordinate every other decision to it
Elevate it by adding capacity
Then go back to step one because the constraint has moved
Goldratt Research Labs adds a warning to that last step. Don’t let inertia, meaning the rules and habits you built around the old constraint, become the next constraint. An AI headcount model pays for an AI tool by cutting the people around it. That jumps to step four (elevate) without doing step one, so nobody checks where the constraint’s moved.
Step one (finding the constraint) has an answer for security teams. ISC2 surveyed 856 security professionals who use AI in their work, and its July report found 63% spend more time reviewing or validating AI output and 65% spend more time deciding when to trust it or act on it. Nine in ten (89%) have watched AI recommendations lead to incorrect outcomes at their organization, and half say a human decision-maker gets held accountable when that happens.
In the same survey, 56% said AI cut the need for entry-level security roles, though 53% said it’s also creating new kinds of entry-level roles. Their own checking work keeps growing. The constraint’s moved to the people who check AI’s work.
Software teams hit this bottleneck first. DORA’s March analysis of 1,110 survey responses from Google engineers found that time saved writing code often gets spent again auditing it, and the extra load lands on the reviewer. Faros AI’s Speed Trap telemetry from 22,000 developers (vendor research) shows time spent in QA (quality assurance) up 300.6%.
IT Revolution’s September 28 guide, When Coding Is Free, Where Is the Bottleneck?, argues that once AI makes code cheap, the bottleneck moves to the coordination work around the code, including approvals that “still arrive on a calendar built for a slower world.”
The strongest evidence against my argument comes from inside a SOC. Microsoft ran a randomized controlled trial of its Security Copilot Phishing Triage Agent with 154 professional analysts in the final analysis. Under the trial’s conditions, where about 12% of the 93 test emails were malicious, and the agent got every verdict right, analysts working with the agent correctly identified 6.5 times as many malicious emails per minute of analyst time. In the authors’ pessimistic scenario, where 20% of emails are malicious, one in five of the agent’s malicious verdicts is wrong, and it misses one malicious email in five, the gain is 3.1 times.
Analysts with the agent didn’t rubber-stamp its malicious verdicts. They spent 53% more time on each malicious email than the control group did. It’s Microsoft research on a Microsoft product, and it’s also a randomized trial. The agent increased the number of malicious emails each analyst caught per minute.
Look at where the gain came from, though. Under the trial’s conditions, the authors attribute 83% of the gain to auto-resolving emails the agent judged benign, which in the real world get closed without human review. The researchers also planted false negatives, malicious emails where the agent’s verdict said benign. Analysts who saw those benign verdicts missed 46% of the planted emails, and the control group, working without the agent, missed 17% of them. AI took the easy work and left people the hard cases.
Lisanne Bainbridge described this pattern in 1983. Her ironies of automation cover what happens when a machine takes over the routine part of a job: the person keeps the rare, hard exceptions and loses the practice that made them good at handling those exceptions. In her own words, automation “can make the difficult parts of the human operator’s task more difficult.”
Protective Capacity Is the Line Your Spreadsheet Deleted
Protective capacity is spare capacity you keep on purpose so normal swings in demand don’t overload the step that limits you. On a capacity report, it looks like waste. Schragenheim calls maintaining it a real need and admits “there’s no safe formula to calculate precisely the required protective capacity.” His advice is to start with a conservative estimate and check it against results. A headcount model built on average weekly volume cuts protective capacity first, because in an average week those reviewers look idle.
In my September 29 issue, I ran the math for a single review queue. Real security teams’ve got several reviewers pulling from one queue, and the model for that is Erlang C. It’s the formula, named for A. K. Erlang, that gives the probability a request has to wait when several identical reviewers (servers, in queueing terms) share one queue.
Bertsekas and Gallager derive it in section 3.4.1 of Data Networks. It takes three inputs. λ is the number of requests arriving per week, μ is the number one reviewer can clear per week, and c is the number of reviewers. Utilization (ρ) is the share of the team’s capacity the arrivals use, and the offered load (a) is how many reviewers’ worth of work shows up.
Erlang C turns those into C, the probability that a request has to wait. Dividing C by the team’s spare capacity, the requests per week it could clear beyond what arrives, gives W, the average time a request sits in the queue before anyone starts on it.
For example, five reviewers handle security exception requests, and each one can clear four a week, so one review takes a quarter of a week, a little over a working day. I’ll measure waits in review times, so a wait of one review time’s a quarter of a week. At 15 requests a week, Erlang C says 46% of requests’ve got to wait.
That’s about half a day.
An AI rollout lets the business generate requests faster, and arrivals climb 27% to 19 a week. The team now runs 95% busy, 88% of requests wait, and the average wait jumps to 3.51 review times, more than four working days.
A 27% increase in work bought a 9.5x increase in waiting, because the spare capacity in the denominator fell from five requests a week to one and the share of requests that wait nearly doubled.
Now take a reviewer away. At the original 15 requests a week, four reviewers get a wait of 3.46 review times, nearly as long as the 3.51 the AI surge produced on its own. If you do both, 19 requests a week go to four reviewers who can clear 16. Erlang C only has an answer while the team can clear more than arrives, and this team can’t.
The queue never settles. It grows every week until somebody throttles the requests, reviews them badly, or goes around you.
With a sixth reviewer at 19 requests a week, the wait drops to 0.40 review times. The sixth reviewer is the protective capacity.
The model assumes requests arrive at random and review times vary at random (the textbook M/M/c case), and your team won’t match it exactly. The general pattern holds anyway, because waits stay short at moderate utilization and climb steeply as it nears 100%. With five reviewers, the wait roughly quadruples as the team goes from 85% to 95% busy, and that last stretch’s where the AI rollout pushed the team.
Variation makes it worse. Kingman’s formula, named for J. F. C. Kingman’s 1961 paper on queues in heavy traffic, is the standard approximation for the wait in a queue with one reviewer, any arrival pattern, and any spread of review times.
The first term is utilization divided by idle time, and it climbs steeply near 100% busy. The middle term uses coefficients of variation (CV), the standard deviation divided by the mean, for the gaps between arrivals (CVa) and for review times (CVs). It measures how uneven the work is, and if it doubles, the wait doubles. E[S] is the mean review time.
Microsoft’s trial shows the middle term at work. Under auto-resolve, analysts see only the emails the agent called malicious, and in the trial they spent 53% more time on each malicious email than the control group did. The mean review time goes up, and the spread of review times (CVs) changes with it. I haven’t seen anyone publish that spread for a security queue that AI screens, so it’s the number I’d measure first.
Silvia Bartolucci and Pierpaolo Vivo modeled what happens when AI speeds up a task and a person still reviews the output, in a May 2026 preprint. AI drafts faster, some of its errors slip past review and come back as rework, and the gap between faster tasks and a slower workflow is what they call a variance wedge.
Their model’s got a second finding I didn’t enjoy. Under load, reviewers rationally raise the risk threshold an AI output has to cross before they check it, so they check fewer outputs when errors’re most likely. That’s a model with no field data behind it yet.
Their model has a second finding I didn’t enjoy. Under load, reviewers rationally raise the risk threshold an AI output has to cross before they check it, so they check fewer outputs when errors are most likely. That’s a model with no field data behind it yet.
A Security Gate Fails Open
A factory constraint fails closed, meaning nothing gets past it until it catches up. When the bottleneck machine falls behind, parts pile up in front of it, everyone on the floor can see the pile, and output drops until somebody fixes it. A security review gate fails open, meaning work keeps moving without it. Nobody’s forced to wait in its queue, and a requester who gets tired of waiting can stop asking and use an AI tool security never approved.
Freshworks published a survey of 1,000 IT decision makers at US mid-market companies in April (vendor research). Of those, 27% named slow approval processes as the primary reason employees go around IT. In the same survey, 86% reported at least one negative incident tied to unapproved AI in the past year.
PagerDuty and Wakefield Research asked 1,250 office professionals outside IT roles at companies with at least $500 million in revenue (also vendor research). Of the ones using AI, 66% had used it at work while believing company policy didn’t allow it.
The gates had been slow before AI added load. NetFoundry’s survey of 200 senior security and technology leaders (vendor research), published in August, put the average time to implement a single network or firewall change at eight days. Risk and compliance approvals, meaning security reviews and change advisory boards, tied with cross-team dependencies as the top cause of delay.
You cut a reviewer, the queue in front of your AI use case review or your access approvals gets longer, and some share of the people stuck in it stop waiting. The business keeps shipping, so throughput, the number the CFO watches, holds.
The share of work that goes through your review falls, and no queue dashboard reports it. Half of ISC2’s respondents said a human decision maker is held accountable when AI gets it wrong. The work that went around your gate never reached a reviewer, so nobody signed off on it.
The Freshworks and PagerDuty surveys report what people say about why they bypass controls. Neither one tracked an organization’s queue growing and its bypass rate following it, so the link between a cut and a bypass is my inference (see… inference isn’t reserved to only AI) from the mechanism.
If you cut security review capacity and, over the next 12 months, the oldest open request in your queue keeps getting older while the number of unapproved AI tools you find in use stays flat, I’m wrong about your shop. For a public test, use PagerDuty’s 66%. If sanctioned tools and faster gates were absorbing the demand, that number would fall the next time someone measures it, and I expect the next edition of that survey to show 66% or higher.
Size the Reserve Before You Sign an AI Headcount Cut
Run the Five Focusing Steps on your review gates before anyone runs a headcount model. Start with the gates AI is sending more work to, such as AI use case intake, access requests for agents and the people building them, security exceptions, and the change advisory board.
Identifying the constraint takes five numbers per gate. You need requests arriving per week, the median and 90th percentile review time, the age of the oldest open request, and the number of unapproved AI tools you found in use that month. If the oldest open request at one gate keeps getting older while the other gates hold steady, that gate is your constraint.
Exploit that gate next, which means getting every hour you can out of the reviewers you already have. Microsoft’s trial shows one way to do it, with automation closing the requests it can close with evidence attached and reviewers spending their time on the cases that need judgment.
Then subordinate the rest of the program, which means setting every other rule to fit the constraint’s pace. Change the intake rules before anyone touches staffing. Cap how many changes ride in one request, require evidence with every request, and send low impact requests to a standing policy approved in advance so they never enter the queue.
Last, elevate the gate by sizing your protective capacity with the arrival rate you expect after the AI rollout, because today’s rate understates it. You want the smallest reviewer count, c*, whose Erlang C wait at the new arrival rate stays under the wait you can live with.
With the illustrative team and a target of one review time, five reviewers at 19 requests a week wait 3.51 review times and six wait 0.40, so c* is six. Start conservative, as Schragenheim advises, and watch the queue for a quarter before you trust the number.
Gene Kim co-wrote The Phoenix Project, which teaches the Theory of Constraints through an IT story. In his 2019 essay on The Five Ideals, three years before ChatGPT launched, he told leaders to “think carefully about how each and every position you eliminate might disrupt flow.”
His First Way, the first of the three principles he says underpin DevOps, warns against a local optimization that degrades the whole system. An AI tool that multiplies your teams’ requests is one local optimization, and a headcount model that trims the reviewers who clear them is a second. The whole system pays for both at your review gate.
Block’s numbers may hold up for a full year. If they do, they’ll show that a smaller engineering team can ship more safely, and they still won’t tell you how long requests wait at your security review gate.
Before you sign an AI headcount cut for your security team, which week’s your review queue got to survive, and how many reviewers does it take to get through that week?
What to do next
Pull 12 weeks of history for one review gate that AI is feeding (start with AI use case intake) and compute the five numbers above. Plug the arrival rate you expect after the rollout into Erlang C, and see where the wait lands with today’s headcount and with one fewer reviewer. Bring both waits to the meeting where the cut gets decided.
The quarterly recheck of those numbers belongs in the Evolve stage of the CARE framework (Create, Adapt, Run, Evolve), and the RockCyber team can help you set it up. For the single queue version of the math, read Human in the Loop Is a Rubber Stamp. Its Replacements Are Too., and run whatever numbers you bring through the questions in Evaluating AI Security Research.
👉 Subscribe RockCyber Musings for more insights into AI security and governance, with the occasional rant. You can subscribe above
👉 Visit RockCyber.com to learn more about how we can help with your traditional Cybersecurity and AI Security and Governance journey.
👉 Want to save a quick $100K? Check out our AI Governance Tools at AIGovernanceToolkit.com
👉 As a bonus, I got to hang out again with my friends Candy Alexander and Cailin Sullivan on Cybersecurity Refined and Feral to argue whether AI Armageddon is fact or fiction, and whether we slow down for safety or floor it to beat China. After two airliners collided over the Grand Canyon in 1956, Congress built air traffic control and kept the planes flying, and that’s where the conversation went: guardrails you can actually test, starting with an agent kill switch that stops every subagent it spawned.