Leadership in the AI Era: What Amplification Means for Engineering Leaders

Leadership in the AI Era

In 2023, Klarna announced that AI was handling the work of hundreds of employees. The throughput metrics looked fine. Customer interactions were being processed. Tickets were moving. From the outside — and from most internal dashboards — things were working.

Twelve months later, they were partially rehiring. Quality problems had become visible to customers. The terms for the rehired workers were worse than before.

What went wrong was not the AI. What went wrong was the assumption that throughput and quality are the same metric. They are not, and they never were. AI made the difference visible faster than anyone expected.

What DORA actually found

DORA — the most widely cited annual study of engineering team performance — added a fifth metric for 2025: Rework Rate. It measures the proportion of shipped work that had to be re-implemented within 30 days.

This is the first DORA metric that asks whether the output was correct, not just whether it was delivered. The distinction matters more than it used to.

The headline finding that came with it: AI adoption amplifies existing organisational capability in both directions. Teams with strong specification discipline found that AI accelerated correct output. Teams with weak specification discipline found that AI accelerated incorrect output.

The tool is neutral. The organisation's existing practices determine the direction.

This is the amplifier insight: before asking what AI will do for your team, ask what AI is amplifying in your team.

The three things AI amplifies

Specification quality

If your team writes clear specifications before building, AI-assisted development produces correct output faster. If your team generates code from Jira ticket descriptions, AI-assisted development produces technically plausible but behaviourally wrong output faster.

The bottleneck was never implementation speed. It was always specification clarity. AI removed the implementation buffer that used to make bad specs look tolerable. The problems that were always there are now arriving sooner.

Code review discipline

If your team reviews code for domain correctness — not just whether it compiles and passes tests — AI output is caught before production. If your team rubber-stamps code review, AI-generated errors enter production at the same rate as human-generated errors, but at higher volume.

Code review in the AI era is a management discipline, not just an engineering practice. Whether your team actually does it, and what they look for when they do, is visible in your rework rate. Most leaders are not looking there yet.

Domain knowledge density

AI generates technically correct code that is domain-wrong regularly. An engineer who knows what correct looks like for their domain catches this. An engineer without deep domain knowledge often does not — the code looks reasonable, it passes review, and the error surfaces in production.

The engineers with domain knowledge are the ones who make AI output safe to ship. They are also the ones most likely to leave in a headcount reduction, because their value does not show up in throughput metrics. It shows up six months later, when nobody catches the errors they used to catch.

What Klarna's leaders missed

Klarna measured throughput. Throughput looked stable. What they did not measure: defect capture rate, rework rate, domain coverage — the metrics that would have shown quality degrading while the volume numbers held.

The engineers who left disproportionately were mid-career domain specialists. Engineers who knew when AI output was wrong in their specific context. That evaluation capacity was invisible in the metrics. Twelve months later, it was visible in production.

55% of organisations that made AI-driven workforce reductions in 2023–2024 reported regretting them within 12 months (Forrester, 2025). The regret was consistently the same thing: we removed the people who caught the errors.

The structure of the error is not unique to Klarna. It is the predictable result of optimising for the metric you have when the metric you need does not yet exist on your dashboard.

Three questions before the next AI investment

1. What is your current rework rate?

If you do not know: measure it now. It is your baseline. Until you have it, you are flying blind on whether AI is helping or compounding.

If it is above 25%: further AI investment will accelerate rework before it reduces it. Specification discipline needs to come first. If it is below 15%: your team has the specification quality for AI to amplify correct output.

2. Do your engineers know when AI output is wrong?

Not "do they use AI" — can they evaluate what it produces against domain requirements?

The practical test: give a senior engineer 30 minutes with AI-generated code in their domain and ask them to find the errors. If they find nothing, either the code is genuinely correct or the evaluation depth is not there. Both outcomes are worth knowing.

If your team cannot reliably catch AI errors before production, more AI tooling increases your production error rate. That is not a configuration problem. It is a domain knowledge problem.

3. What would you lose in a 20% reduction?

List the ten engineers you would be most reluctant to lose. Look at what their primary skill is: implementation speed, or domain knowledge and evaluation?

If the list is weighted towards evaluation, your team's value is already in the right place. If it is weighted towards implementation speed, your team's value is concentrated in exactly the skill AI replaces fastest.

This exercise is useful even if no reduction is planned. It tells you whether your team is positioned for the environment it is operating in.

What this means for the engineering manager right now

The EM's job has shifted from delivery management to quality management. Only 20% of engineering teams measure AI impact in any structured way, despite adoption rates above 90% (Jellyfish, 2025). That gap is where the EM's day-to-day work is — not auditing AI use, but tracking the signals that actually reveal whether quality is holding.

One practical addition to regular one-on-ones: ask whether the engineer can explain a production issue in their domain. Not as a test. As a proxy for domain ownership. An engineer who cannot explain why something failed in their area probably does not have the depth to evaluate AI output in that area either. If the answer is consistently vague, the domain assignment may be wrong.

The organisations that will look back on this period as a competitive advantage are not the ones that adopted AI fastest. They are the ones that understood what they were amplifying before they amplified it.

That requires measuring quality, not just throughput. It requires knowing who holds domain knowledge and treating that as the asset it is. And it requires the uncomfortable conversation when AI investment decisions were made on throughput metrics and the quality degradation is now in production.

That conversation is not evidence that AI was a mistake. It is the beginning of getting it right.