The scarce resource is no longer code. It's judgement.

For three decades, an engineer's value was simple to measure: the more correct code someone produced, the more valuable they were. Hiring tested exactly that: puzzles, whiteboard exercises, timed tests. Writing correct code was genuinely the bottleneck.

That bottleneck is dissolving. In a controlled study, developers using GitHub Copilot completed a defined coding task 55.8% faster than a control group, a result replicated across experience levels.¹ The task was narrow; the direction of travel is not. As AI absorbs more of the mechanical work of coding, the value of everything code is meant to serve (the right problem, the right architecture, the right judgement) rises.

PwC's 2026 Global AI Jobs Barometer, drawn from over a billion job ads across 27 countries, names this shift: the labour market is splitting into two tracks. “Democratised” roles let AI make existing work easier; “professionalised” roles let AI automate the routine and intensify the premium on judgement. Professionalised roles are growing at twice the rate, with 42% faster salary growth.² In the UK, “AI user” roles, specialists applying AI within a domain, grew 65.8% year-on-year, outpacing pure AI-developer hiring.³

Put plainly: the market rewards people who know which problems are worth pointing AI at, not people who operate it quickly.

Most hiring processes were built for a world where execution was scarce. They measure whether someone can solve a well-specified problem fast, not whether they can recognise which problem to solve, reason about how a system fails at scale, or adapt as tools change every few months. That second set of capabilities is where advantage now lives.

The New Economics of Software Engineering

Economists have a vocabulary for this that predates generative AI by two decades. Autor, Levy and Murnane showed that technology doesn't automate jobs wholesale: it automates tasks, the routine and codifiable ones.⁴ What's left, and rises in value, is what resists codification: framing ambiguous problems, exercising judgement, adapting to conditions no rule anticipated.

The mechanism is economic. AI is a substitute for the routine component of engineering work, and a complement to the non-routine component. Substitutes push a price down; complements raise the marginal productivity (and price) of whatever they're paired with.

Scarcity hasn't disappeared. It has moved to a different address.

The wage premium for AI skills has climbed to 62% globally, up from 57% the year before.⁵ Companies aren't buying less engineering talent. They're paying more for a different mix of it.

To be precise: this is not an argument that AI replaces developers, or that coding no longer matters. It's narrower: as routine execution gets cheaper, the relative value of problem definition, architecture and tradeoff judgement goes up. An organisation still hiring as though execution speed were scarce is optimising for a falling cost while underpricing what actually drives its results.

That's a dangerous place to build a hiring strategy.

Why This Isn't the End of Software Engineering

An obvious objection: if execution is compressing, don't organisations simply need fewer engineers?

History says no. Technologies that sharply raise a profession's productivity rarely shrink demand for its expertise; they expand what's expected of it. The spreadsheet didn't eliminate accountants; it removed the tedious part and raised what finance teams were expected to model and advise on. Generative AI looks to be following the same pattern: headcount at the most AI-exposed companies is growing faster than at the least exposed (52% versus 36% since 2018⁶), not what a profession in decline looks like.

Some roles built entirely around routine execution will genuinely shrink. But the claim that AI ends software engineering as a valuable profession isn't supported by how equivalent technologies behaved before. What's ending is a particular definition of what makes an engineer valuable.

Why Streaming and AdTech Feel This First

This reallocation isn't evenly felt. It shows up earliest where the technical system is the product's economics (streaming, advertising technology, large consumer platforms), because their core systems sit on ambiguous, fast-moving problems no spec fully captures.

Take a recommendation system. At the code level it's largely solved: the techniques are documented, and AI can scaffold a pipeline quickly. But embedded in a real streaming business, it isn't just a model to optimise for accuracy: it sits at the intersection of licensing costs, churn, engagement targets and editorial constraints on what gets promoted to whom. An engineer treating it as a pure ML problem builds something that misfires commercially, over-optimising for watch time at the expense of catalogue economics.

The differentiator was never whether someone could implement the model. It was whether they understood the business well enough to know which objective function was the right one.

AdTech makes the point more starkly. As third-party cookies have been phased out, the industry has had to reconstruct identity resolution and measurement under real regulatory constraints: reasoning across privacy law, advertiser economics and distributed systems architecture at once. AI can help write the pipelines. It can't decide what they should preserve.


In both cases, the engineering challenge isn't implementation. It's choosing the right optimisation target.

Beyond Coding: The Rise of Systems Thinkers

“Systems thinking” gets used loosely, so it's worth being precise. In the tradition associated with Donella Meadows, it means seeing a system's structure (feedback loops, delays, points of leverage), not just its components.⁷ Meadows' counterintuitive finding: the highest-leverage interventions are almost never at the level of parameters or code, but at the level of structure and purpose. That's the layer AI doesn't touch: the layer a problem statement has to exist in before any code gets written.

Three capabilities sit at that layer: problem framing rooted in customer and industry understanding; architectural reasoning, meaning the ability to anticipate how a system behaves under scale and failure; and commercial judgement, meaning knowing a technically elegant solution isn't always the commercially correct one. None of these show up reliably in a coding interview. What's new is that they're no longer complementary to execution; they're becoming the primary source of differentiation, because execution itself is compressing. The market already rewards people who apply AI expertly within a field over people who can merely build AI systems.

Give two engineers the same brief: reduce latency in a personalisation pipeline. One optimises as specified, shaving milliseconds. The other asks why the latency budget exists, traces it to an auction-timing constraint three layers away, and finds the real leverage point is an unquestioned caching decision. AI can help either write code faster. It can't ask the second question.

What Carol Dweck Got Right, and Why It Matters More Today

This essay began with a conversation about a book published nearly two decades ago. In Mindset, Carol Dweck distinguished a “fixed mindset” (believing ability is stable, so you avoid challenges that might expose its limits) from a “growth mindset” (believing ability develops through effort, so setbacks are information, not a verdict).⁸ In her research with adolescents, a growth-mindset intervention reversed a documented decline in maths achievement, while a control group kept declining: evidence the orientation shapes performance, not just correlates with it.⁹

Management writing has mostly treated this as a culture-and-morale idea. That's not wrong, but it understates the stakes now. In a domain rewritten on an eighteen-month cycle, growth mindset stops being a wellbeing variable. It becomes a structural input: learning velocity, the rate at which someone's expertise can be rebuilt as the ground moves.

That reframes risk on both sides of a hire. Deep, fixed-mindset expertise in today's stack isn't safe: its half-life is short enough that defending the approach that made you the expert, rather than revising it, becomes a liability on a predictable timeline. A strong growth orientation with less current expertise may be the better bet: what compounds isn't today's knowledge but the rate it gets replaced. Dweck found this at the organisational level too: “genius cultures” that prize innate brilliance see more hoarding, less collaboration.¹⁰

A growth mindset without domain depth is enthusiasm without judgement. Paired with problem-framing, architecture and commercial judgement, it's what keeps those capabilities from decaying.

Rethinking Technical Talent

If this argument holds, why haven't hiring processes adapted? Not oversight: these capabilities are the hardest to assess at scale, while execution speed is the easiest to standardise and score across a thousand candidates. Judgement can't be scripted that way; it takes an open conversation and someone senior enough to recognise it.

Hiring infrastructure, like any infrastructure, was built around what was cheap to measure, not what was most predictive of value.

Interview formats were optimised over the past decade for what the market priced most highly then: fast, correct execution. The market signal described earlier has already arrived, but most interview loops haven't been rebuilt to receive it, which is why senior engineers can interview brilliantly and then struggle with the ambiguous, cross-functional problems the role actually requires.

Closing that gap doesn't mean abandoning technical assessment; depth still matters. It means treating execution as a threshold to clear, not the primary axis of comparison: a genuinely underspecified problem instead of a timed one, a system to critique rather than build from scratch, and a question about a time their judgement was wrong (itself a direct probe of learning velocity).

Over the past year, we've noticed a recurring pattern across executive searches in streaming, media and AdTech: the candidates who get offers are rarely the fastest through the case study. They're the ones who, partway through, pushed back on the brief and pointed out the real constraint wasn't the one on the page. That used to be a minor preference. Now it's often the deciding factor.

Conclusion

None of this argues that AI is quietly making engineers obsolete. It's the opposite: as AI makes execution cheaper, the people who combine technical depth with judgement about what's worth executing become an organisation's scarcest, most valuable resource. That's a more demanding standard than most hiring processes were built to meet, and a more durable one, since it doesn't expire when the tooling changes again.

Over the next five years, I expect leading technology companies to redesign technical interviews around architectural reasoning, commercial judgement and learning velocity, with coding assessments becoming necessary but no longer sufficient as predictors of long-term performance.

The most valuable engineer in 2030 may not be the person who writes the best code. It may be the person who asks the best questions before a single line is written.

The question belongs to anyone building technical organisations now: not “can this person code,” but “can this person see the system, frame the right problem, and keep revising their expertise as the field changes.” The candidates worth finding are no longer the ones a keyword search or timed test surfaces; they are the ones trusted with problems nobody has fully defined yet.

Notes

1. Peng et al., “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” Microsoft Research / arXiv:2302.06590.

2. PwC, 2026 Global AI Jobs Barometer.

3. PwC UK, 2026 AI Jobs Barometer (UK press release).

4. Autor, D., Levy, F., & Murnane, R. (2003), “The Skill Content of Recent Technological Change: An Empirical Exploration,” Quarterly Journal of Economics.

5. PwC, 2026 Global AI Jobs Barometer.

6. PwC, 2026 Global AI Jobs Barometer.

7. Meadows, D. (2008), Thinking in Systems: A Primer, Chelsea Green Publishing.

8. Dweck, C.S. (2006), Mindset: The New Psychology of Success, Random House.

9. Blackwell, L.S., Trzesniewski, K.H., & Dweck, C.S. (2007), “Implicit Theories of Intelligence Predict Achievement Across an Adolescent Transition: A Longitudinal Study and an Intervention,” Child Development, 78(1).

10. Dweck, C.S. (2014), “How Companies Can Profit from a ‘Growth Mindset,’” Harvard Business Review.