Before You Cut Engineering Headcount for AI, Prove the Capacity

The CFO sees rising AI adoption and asks why the engineering plan still includes ten open roles. The CTO can point to faster code generation, but not yet to shorter release cycles, fewer incidents or more customer value. Meanwhile, the people team needs an answer before offers, budgets and reorganisation plans move forward.

This is where an attractive productivity thesis becomes a workforce decision. If leaders move too slowly, they may keep hiring against an outdated operating model. If they move too quickly, they can remove the system knowledge, review capacity and technical ownership needed to make AI-assisted delivery work at all.

The right question is not how much code an AI tool can produce. It is whether the organisation has evidence that its required capacity has changed.

Reporting about Meta’s internal planning created an easy headline but a less portable lesson. Meta reportedly considered scenarios in which some teams could be reduced by as much as 60%; this was not an announced plan to remove 60% of the company, and not every scenario proceeded (Ars Technica).

That distinction matters. Scenario modelling is a legitimate management exercise. A ratio taken from another company is not a defensible operating assumption.

The effect of AI depends on the work, codebase, architecture, controls, customer expectations and experience of the team. A company maintaining a mature payments platform should not apply the same staffing logic as one producing disposable internal prototypes. Even within one engineering organisation, AI can materially accelerate one workflow while adding review and rework to another.

Nor is the choice simply “keep everyone” or “cut everyone.” The available actions include:

• leaving selected vacancies unfilled;
• redeploying engineers into platform, reliability or AI evaluation work;
• changing the seniority mix;
• using external specialists for a time-bounded capability gap;
• removing work that no longer supports the strategy;
• reducing roles where demand has genuinely fallen.

A percentage target chosen before this analysis reverses the order of the decision.

AI tools make certain activity metrics move quickly. More code can be produced, more pull requests opened and more tickets touched. None of those measures confirms that customers receive useful changes sooner or that the operating cost of the system has fallen.

A practical definition of engineering capacity is the volume of accepted product, reliability or risk-reduction outcomes delivered for the total human, machine and rework cost required.

The baseline should therefore include:

• end-to-end lead time, from an accepted requirement to production;
• active engineering and human review time;
• rework after review or testing;
• escaped defects and security findings;
• rollback, incident and recovery rates;
• infrastructure and tooling costs;
• cost per accepted outcome;
• time spent on coordination, exceptions and approvals.

Measure these by workflow rather than averaging the whole department. Department-wide averages conceal where AI is helping and where it is transferring effort from implementation to review, debugging or operations.

This is consistent with DORA’s 2025 finding that AI tends to amplify the strengths and weaknesses of the surrounding delivery system (DORA). Faster generation will not repair unclear product decisions, weak tests, fragmented ownership or a slow release process. It may simply send more work into those constraints.

Most engineering roles are bundles of tasks. Some tasks can be automated without eliminating the need for the role that owns the outcome.

A useful workflow map has four categories:

1. Bounded and repeatable: dependency updates, standard test generation, routine migrations and well-specified internal tooling changes.
2. Context-heavy: changes in mature services where undocumented history, customer behaviour and architectural constraints affect the right answer.
3. Risk-intensive: identity, payments, security, privacy, infrastructure and production access.
4. Judgement-intensive: product discovery, architecture, technical trade-offs, incident command and cross-functional decisions.

The first category may produce credible capacity gains relatively quickly. The others can still benefit, but usually need more experienced review and clearer controls.

A controlled METR study illustrates why perception is an unsafe basis for workforce planning. Experienced developers working in familiar, mature repositories expected early-2025 AI tools to make them faster, but measured completion time increased by 19% when the tools were permitted (METR). The study was small and tool capabilities have moved since then, so it should not be treated as a universal result. Its decision value is narrower: confidence and code-generation speed are not substitutes for end-to-end measurement.

Before removing a role, leaders should identify which accountabilities disappear with it. If nobody retains production knowledge, architecture ownership, mentoring responsibility or incident authority, the organisation has not removed only automatable work.

A useful pilot compares one repeatable workflow with one context-heavy workflow. Toy exercises are inadequate because they remove the conditions that make production delivery difficult.

A worked illustration

Consider a hypothetical SaaS company with 28 engineers and six approved vacancies. Management is considering cancelling all six because AI coding tools appear to be increasing output.

The company runs a six-week pilot using approved tooling, restricted permissions, mandatory code review and named human ownership for every production change. The figures below are illustrative, not benchmark data.

Scroll horizontally to see all columns.

AI improved the bounded workflow by 22%. It made initial implementation faster in the mature service, but total effort rose by about 7% because reviewers had to detect assumptions that conflicted with existing behaviour.

Cancelling six roles would not follow from these results. A more defensible response would be to standardise the first workflow, expand the sample, improve context and evaluation for the second, and reassess capacity after several release cycles. The business might also redirect some time into reliability work rather than removing it immediately.

The pilot needs three gates:

1. Outcome throughput improves by a meaningful amount.
2. Reliability, security and product quality do not deteriorate.
3. Review, exception handling and incident costs do not absorb the apparent saving.

NIST’s guidance supports this operating discipline: define human oversight, test outputs under realistic conditions, review generated code for downstream risks and monitor incidents and overrides after deployment (NIST).

The output should be an evidence-backed planning range for each workflow, not one percentage applied across engineering.

A productivity pilot should end in a workforce action, but reduction is only one option.

Scroll horizontally to see all columns.

A reduction can be justified when demand has structurally declined or a body of work is being stopped. That is a business portfolio decision, not proof that AI has made a given percentage of engineers unnecessary.

Where evidence supports slower recruitment, be specific about which requisitions change. Pausing three generalist roles while retaining a staff engineer, security specialist and platform owner is a real operating choice. Announcing a department-wide freeze is not.

The same specificity applies to redeployment. Moving an engineer into “AI enablement” without an accountable remit merely changes the cost centre. Useful mandates include evaluation design, internal platform ownership, permission controls, test infrastructure, data quality and adoption support for a defined workflow.

AI can reduce implementation effort while increasing demand for judgement. That changes the talent mix before it necessarily changes total headcount.

Capabilities worth protecting or adding often include:

• senior ownership of mature systems;
• product-minded engineering that can challenge poor specifications;
• test and evaluation design;
• security, privacy and reliability engineering;
• platform work that supplies safe context and controlled access;
• incident leadership and production diagnosis;
• mentoring for less experienced engineers.

The fashionable alternative is a small group of senior “agent supervisors.” This can work where work is bounded and validation is cheap. It is a poor fit when each reviewer must understand several complex domains, approve high-risk changes and remain accountable for production behaviour. Review attention becomes the scarce resource, and concentrating it in too few people creates delay and key-person risk.

There is also a development problem. If routine work disappears without a replacement learning path, junior engineers lose the tasks through which they build system understanding. Companies then depend on a senior talent market without producing future senior engineers themselves.

The riskiest shortcut is to turn AI-generated productivity signals into employee rankings. Tool usage, acceptance rates, commit volume or estimated time saved do not provide a fair account of individual contribution. They can penalise engineers doing ambiguous, preventive or high-risk work.

For European employers, this is also a governance issue. Annex III of the EU AI Act lists employment uses including recruitment, candidate evaluation, promotion, termination, task allocation, performance evaluation and worker monitoring among its high-risk categories (European Commission AI Act Service Desk). Exact obligations and timing should be assessed with appropriate legal advice and local employee-representation requirements.

A safer boundary is to use pilot data to assess workflows, not to automate final decisions about people. If AI-derived information enters hiring, promotion, performance or redundancy processes, leaders should be able to explain:

• the lawful purpose and data used;
• why the signal is relevant to the decision;
• its known error and bias risks;
• who reviews and can override it;
• how an affected person can challenge the result;
• how long the information is retained.

The Chief People Officer should co-own this design from the start. Bringing People or legal teams in after the target headcount has already been announced leaves them to govern a decision they did not help shape.

A leadership team does not need perfect certainty. It does need enough evidence to distinguish a delivery gain from a shift in hidden work.

Pre-decision checklist

• Name the customer, reliability or risk outcome that should improve.
• Select at least one bounded and one context-heavy production workflow.
• Record the baseline before changing tools or staffing.
• Count review, rework, incidents and tooling costs.
• Restrict permissions and assign a human owner to production changes.
• Set quality, security and reliability stop conditions.
• Identify the system knowledge and accountabilities at risk.
• Decide in advance what evidence would support hiring, redeployment, restraint or reduction.
• Keep experimental productivity data out of individual employment decisions.
• Define how the organisation will reverse course if the thesis fails.

This approach is not a reason to delay every difficult workforce decision. A company facing a cash constraint or sustained fall in demand may need to reduce costs before a long pilot concludes. Leaders should be candid that this is a financial or portfolio decision, rather than presenting unproven AI productivity as its technical justification.

For companies with stable demand, the next decision should be smaller and more disciplined: approve a time-boxed capacity test, appoint Engineering and People owners, and defer any percentage target until the results show which work has changed.

If that process exposes a gap in AI evaluation, platform ownership, security, reliability or technical leadership, turn it into a precise hiring brief. Deeptal connects companies with senior European specialists, with human-reviewed shortlists and no recruitment fees. For a qualified brief, an initial shortlist is typically prepared within two business days, and selected specialists typically start in 7–14 days, subject to fit, availability, interviews and terms. Deeptal can also handle contracts, payroll and compliance administration, with billing consolidated into one monthly invoice.