When a CEO wants to cut the engineering team because of AI, a flat "no" loses and a flat "yes" is expensive to undo (judgment). This article gives you a third answer: a baseline of numbers, a test with a threshold and a date, and an ordered list of what to cut first if the decision is made anyway. The claim is rarely tested at the source, and you can test it. For the rest of the VP's toolkit, see Engineering management guides for CTOs and VPs of Engineering.
What is your CEO actually asking for?
Find out whether the driver is AI, cost, or a story for investors. The three need different answers, and only one of them is about AI.
A letter your CEO may have read is Block's Q4 2025 shareholder letter. It says the company is "reducing Block by nearly half, from over 10,000 people to just under 6,000." The thesis is stated plainly: "A significantly smaller team, using the tools we're building, can do more and do it better." And the letter predicts that "[W]ithin the next year, I believe the majority of companies will reach the same conclusion and make similar structural changes." Block's Q4 highlights panel shows gross profit up 24% year over year, and the letter calls 2025 "a strong year." Judgment: the letter reads as a bet made from strength rather than a rescue.
Judgment: note the phrase "the tools we're building." Block is building the intelligence tools it says justify the cut. A letter from a company with that stake is evidence of what Block believes, not a measurement of what your team would do.
Before you argue about AI, ask the CEO for two things: the target (a number and a date) and the goal (margin, runway, speed). "Cut 20% by Q2 to extend runway" is a cost conversation, and the usual cost-cutting order applies whether or not AI is involved. "Ship the roadmap with fewer people because AI makes us faster" is a testable claim. Treat them separately.
What does the evidence say about AI and headcount?
Less than the headlines suggest, and what it says points in two directions.
What leaders report
LeadDev's Engineering Leadership Report 2026 found that only 8% of respondents said AI reduced their headcount in 2025, while 21% believe it will reduce headcount in 2026. Expectation is running well ahead of what has happened. If your CEO says everyone is cutting because of AI, that's the number to put next to it.
What the productivity studies show
None of the well-known studies measures headcount. They measure speed and quality, which is the input to the headcount argument, not the argument itself.
METR's 2025 study recruited 16 experienced developers and tracked 246 completed issues. The developers expected AI to speed them up by 24%. They took 19% longer, and afterwards still believed AI had sped them up by 20%. METR's own page now says these results are out of date, so don't quote it as current fact. Quote it for the gap between feeling fast and being fast.
METR's February 2026 update measured again. For the original developers the estimate was -18%, with a confidence interval from -38% to +9%. For the new group it was -4%, with an interval from -15% to +9%. METR's sign convention is that negative means less time with AI. Both intervals include zero, and METR calls the result "an unreliable signal of the current productivity effect of AI tools." The main reason: 30% to 50% of developers said they chose not to submit some tasks. Whatever those tasks were, the study can't see them.
DORA's 2025 report, built on survey responses from nearly 5,000 technology professionals, is the most useful one for this meeting. It found "a positive relationship between AI adoption on both software delivery throughput and product performance." It also found that "AI adoption does continue to have a negative relationship with software delivery stability." In DORA's words, "AI accelerates software development, but that acceleration can expose weaknesses downstream." Throughput up, stability down.
Judgment: going from "developers code faster" to "we need fewer developers" is an inference with two unmeasured steps in it. Faster coding doesn't automatically mean faster delivery (review and stability sit in between), and faster delivery doesn't mean the roadmap shrinks. If your team already shipped with the same headcount and the CEO is asking why it didn't shrink, what to tell the board when AI didn't shrink the team covers that conversation.
Which numbers do you bring to the meeting?
Bring a baseline from before any cut, and pick metrics that cover both sides of DORA's finding: speed and the damage downstream.
| Metric | Where it comes from | What it tells the CEO | Why it's here |
|---|---|---|---|
| Deployment frequency and lead time | Your CI/CD and Git history (DORA throughput) | Whether the team ships faster | The CEO's claim is that AI makes the team faster |
| Change failure rate and time to restore | Incident tracker and deploy logs (DORA stability) | Whether speed is costing quality | DORA found stability falls as AI use rises |
| Median time to merge and PRs per reviewer | Git host | How much review load AI-assisted code is creating | Judgment: faster writing can move the bottleneck to review |
| Reverts and same-file rework in a fixed window | Git history | How much merged work gets redone | Rework is the cost the speed number hides |
| AI spend | Vendor invoices | What the tools cost | A smaller team with a bigger tool bill is not a pure saving |
| Roadmap items delivered vs planned | Your planning tool | Whether the outcomes the CEO cares about moved | Throughput of what matters, not of commits |
Don't lean on surveys. In LeadDev's report, employee feedback is the most-used measure of AI impact, at 63%. Development time per feature is tracked by 31%, change failure and PR reversion rates by 22%, and time spent reviewing AI-suggested code by 21%. METR's perception gap is the reason that ordering should worry you: developers believed they were faster when they weren't. Of the measured metrics, LeadDev found only development time per feature (31%), change failure and reversion (22%) and review time (21%) in use at a minority of organizations.
How to pull these numbers without buying a platform is covered in a five-step plan to measure AI coding tools ROI, so there's no repeat here. If the CEO's version of "numbers" is token counts, read answering a CEO who asks for token counts first.
What if you have no baseline?
Say so. Then propose a baseline quarter: one quarter of the table's numbers with no change to team size, so the pilot below has something to be compared against. Judgment: a leader who admits the gap and offers a dated fix is more credible than one who produces a number in the meeting and defends it for six months.
How do you test the claim before anyone is cut?
Propose a pilot with a stated threshold and a date. A layoff can't be undone, and a pilot can. Judgment, and our recommendation:
- Get the CEO to name the metric and the number that would convince them. "Roadmap items delivered per quarter, up by X with the same people" is a claim. Write X down, in their words.
- Run two cohorts if the team is big enough to split: one with the current AI setup, one without a change. If it isn't, compare against your baseline quarter.
- Set a review date, typically one or two quarters out, and commit to a decision on that date.
- Add a stop rule. If change failure rate or time to restore gets worse by an agreed margin, the pilot ends and the speed gain doesn't count.
Include review and stability in the test, not only coding speed. DORA's point is that the acceleration exposes weaknesses downstream. A pilot that measures only commits per week will confirm the CEO's belief and miss the cost.
If the CEO won't agree to a threshold, that tells you the decision was made before the evidence. You can still use the rest of this article. You're just now planning the cut, not testing the claim.
If they insist, what do you cut first?
Judgment throughout this section: no study ranks cuts. This is the order we'd use, and it's built from the evidence above and from how headcount decisions tend to be reversible or not.
Scope before people
Rank the roadmap and cut items, not names. If the plan assumes fewer engineers can do the same work, the plan is the thing that's wrong, and the CEO should see which features drop off the bottom. This turns "AI makes us faster" into a trade the CEO has to accept openly.
Open roles and attrition before layoffs
Close open requisitions and don't backfill people who leave. It's slower, but it's reversible, and it keeps the knowledge in the building that a layoff takes out. What to cut first without killing the roadmap covers the cost order, layoff savings and the notice rules in the EU, so they aren't repeated here. Our order differs from the cost-cutting guide's table because we put reversibility first.
Contractors vs employees
Contractor notice is usually short, and employee notice, severance and consultation vary by country and can delay the saving. That makes contractors the quicker step, with one check: find out what each contractor holds before the contract ends, such as access, a service only they understand, or an on-call rota. If you'd need to rehire later, senior engineers on a contract through HighCircl come with no recruitment fee, a 3-5 candidate shortlist and 72-hour matching, which shrinks the cost of reversing the decision.
Which roles
Judgment: pick by the kind of work, not by title. Work that is bounded and measurably faster with AI is the candidate for fewer people. METR's results are the reason for caution on anything else: its experienced developers were measured at 19% slower in 2025, and the 2026 update couldn't show a reliable speedup. Protect the owners of production (on-call, billing, security) and the senior reviewers, whose load goes up as AI-assisted code increases. Cutting those roles risks removing the capacity that absorbs the downstream weakness DORA describes (our judgment).
Write down the restart trigger
Before the cut, agree in writing which metric would reopen hiring. For example: change failure rate above the baseline for two consecutive months, or roadmap delivery below an agreed share of plan. Otherwise a cut made on a theory has no way to be corrected by a fact.
What this means for your headcount decision
The decision isn't "AI or people." It's whether you accept a cut on a claim nobody has tested at your company, and what you require before you do.
Judgment, in order: first, make the CEO state the target and the goal. Second, bring the baseline from the table, or commit to a baseline quarter. Third, offer the pilot with a threshold and a review date, because LeadDev's 8% against 21% suggests few respondents have yet reported AI-driven headcount cuts. If the answer is still yes, cut scope and open roles first, then contractors, and agree the restart trigger in writing.
If you're on the other side of this and need headcount rather than cuts, the case works in reverse. The business case for a senior engineer shows how to put one in front of a CEO or CFO.
FAQ
Is engineering going to get replaced by AI?
Nothing in the sources here says so. LeadDev's 2026 report found only 8% of respondents saying AI reduced their headcount in 2025. DORA's 2025 data shows AI raising throughput while lowering stability, which, as judgment, is a tooling change that can add review and recovery work. Whether that changes team size is the claim to test, not assume.
Are engineers losing jobs due to AI?
Some are. Block's letter shows a company cutting from over 10,000 people to just under 6,000 and tying that to AI tools. But in LeadDev's survey, 8% of respondents said AI reduced their headcount in 2025 and 21% expect it to in 2026. The expectation is larger than the observed effect.
How do you respond when the CEO says AI means a 30% smaller team?
Ask what the 30% is based on, and what it's for. Then bring your baseline, the pilot proposal and the stop rule. Don't argue the number in the abstract. We have no sourced benchmark for a typical cut, so any percentage, yours or theirs, is a guess until you measure it on your own team.
Should you accept a headcount cut if AI tool adoption is already high?
High adoption doesn't prove the savings exist. DORA found about 90% of respondents using AI at work, and still found stability worse. If adoption is high and your delivery numbers haven't moved, that's your evidence against the cut. If they have moved, that's evidence for it, and you should say so.
What metrics prove AI did or did not reduce the need for engineers?
Roadmap delivered against planned, deployment frequency and lead time, change failure rate and time to restore, and review load. Compare each to a baseline from before the change. Surveys of how fast developers feel are the weakest evidence: METR's developers believed they were 20% faster while taking 19% longer.