The friction layer (Part 2): Why the most AI-exposed function isn't the most strained

TL;DR

Software engineering is the biggest technical function and the most obvious place AI shows up, yet it is not where AI puts an organisation under the most structural strain: several much smaller functions carry more. What makes engineering matter for AI strategy is something the strain ranking does not show. It is the shared software layer the rest of the business runs on, so the AI rules a company sets inside engineering quietly become the defaults everyone downstream inherits.

This is part 2 of the Friction Layer series, with TechWolf, by Markus Bernhardt, Principal at Endeavor Intelligence. The image provides an overview of how each blog post fits within the series:

• Part 1 highlighted strain (where reorganisation pressure concentrates).
• Parts 2 & 3 will sharethe undercurrent view: Part 2 follows it outbound (the shared software layer whose defaults propagate downstream), Part 3 inbound (those same shared skills carrying pressure onto hardware).
• Part 4 will highlight capacity to absorb (the buffer): what separates the functions that bend from the ones that break.

Visibility isn't strain

Software engineering is the function every company names first when AI comes up. It is the largest technical function by a wide margin, and much of its day-to-day work, writing code, reviewing it, testing it, is precisely what the current wave of AI tools does. So the natural assumption is that this is where AI hits an organisation hardest.

It is not. Rank the functions by how much structural strain they carry as AI reshapes the work, and software engineering sits well down the list. It carries real strain, more than most functions do, but it is well below the ones at the top. Several functions a fraction of its size - the teams running deployment, quality, and parts of finance - carry more. The biggest, most exposed function is out-strained by a handful of much smaller ones.

That gap is counterintuitive, and it is robust, because size and strain are different things. The pressure AI puts on software is large in absolute terms, but it is spread across an enormous base of work, and the craft at the centre of that work - the architectural calls, the hard design judgments - stays human-led. Pressure spread thinly across a vast, varied base does not pile up the way it does when it lands on a small function whose work sits at a busy intersection. Volume dilutes strain; it does not concentrate it.

So if software engineering is not where the strain lands, why does it still belong at the centre of an AI strategy? For a reason the strain ranking cannot show.

The layer the rest of the business is built on

Look past job titles to the actual work, and one thing sets software engineering apart from every other technical function: it builds what the others run on. The tools, the data pipelines, the internal platforms, the code other teams depend on to do their own jobs. When a marketing team automates a workflow, a finance team stands up a reporting system, an operations team wires two tools together, they are building on software that engineering wrote, to standards engineering set. The craft of writing code stays inside engineering. What that code becomes, the shared substrate everyone else operates on top of, does not.

Engineering matters here because so much of what every other function does is built on top of the software it produces. Change how that software gets made, and you have changed the ground a large part of the organisation is standing on, whether or not anyone aimed a tool there.

Software engineering is where general-purpose software skills concentrate, and those skills are the substrate a great deal of other technical work is built on. When AI reshapes how that software gets written, you are not changing one function. You are changing the layer underneath many of them.
Jeroen Van Hautte, CTO at TechWolf

Why the decisions made inside engineering do not stay there

AI strategy for engineering is usually treated as an internal engineering matter. Engineering picks its coding assistants, decides how to govern code review, sets the rules for when AI can act on its own and when a person signs off. The structural picture says those choices do not stay local. They get baked into the shared tools, standards, and codebases the rest of the business builds on, and they travel with them. The rule an engineering team sets for when an AI may merge code without a human reading it becomes, in practice, the rule for everyone downstream of that code. Set the defaults well and others inherit clarity; set them badly and others inherit the ambiguity. AI governance for engineering turns out to be AI governance for much of the company.

Policy is not the only thing the shared layer carries downstream; the same path carries mistakes. AI tools are most confident on routine work and least reliable on unusual edge cases. Coding assistants are no exception, so a review agent that waves a rare security case through inside engineering passes that mistake straight to everything built on top of it.

If a mistake can travel that far, the question is what reliably stops it, and in practice one answer holds up. The AI deployments that already run dependably at scale share a single trait: they check the AI's output against something outside the AI. An automated code-checker catches the error no matter how confident the model was. A test suite either passes or it does not. Using one AI to review another fails exactly here, because the second model can be talked into approving the first one's mistake by the same confidence that produced it. The check that holds validates against something fixed, a test, a linter, a specification, never against another model's opinion.

What this asks of the people who run the organisation

Every CHRO and CTO is being handed the same question right now: where do we start with AI in engineering? The structural answer reframes it. You are not setting rules for one function. You are setting the defaults the rest of the organisation will inherit through the software it runs on. So the place to be most careful is exactly the place most companies treat as a local technical call.
— Markus Bernhardt, Principal at Endeavor Intelligence

AI oversight tends to concentrate on the functions that are biggest and most visible, and software engineering is the most visible of all. That attention is well spent, as long as it is aimed at the right worry. Engineering is worth governing carefully for what it propagates: the defaults it sets travel outward into everything built on its software. The strain itself concentrates elsewhere, in smaller, less prominent functions. Govern engineering for what it sends downstream, and the effort lands where it actually matters.

The shared software layer has reached further than most organisations track. A later piece in this series follows it somewhere almost no one is looking: into the physical-engineering teams who now draw on the same software skills, and who have quietly become one of the most AI-exposed functions in the business, without the defences software teams spent years building.

How this analysis works

TechWolf's Skills Intelligence Index maps 2,500 skills across seventeen job families, drawn from more than two billion job postings at over 1,500 companies between 2015 and 2025. AI impact is scored using TechWolf's operationalisation of the Stanford Human Agency Scale, which sorts each task into work that stays human-led, work AI can augment, and work AI can automate. The structural analysis is Endeavor Intelligence's own, applying the method published in The Undercurrent in Data, with no editorial control by the data provider.

Two findings from that data anchor this piece: software engineering is the largest technical function, roughly three times the combined size of the most-pressured functions, and it sits well down the pack on structural strain, below the most-strained functions though not at the bottom. This piece argues that the AI defaults set there travel outward. That is a structural reading of software as shared infrastructure, not a claim that engineering is the single most-connected function. This is a directional analysis: it shows where AI pressure concentrates and how it travels, not a precise league table, and exact positions shift with the modelling choices. It reads the shape of the work as it stands today, a signal of where to look rather than a prediction of what will happen. It is not a forecast of job losses.

This analysis was co-published with TechWolf.

Further reading. This is one of four pieces mapping how AI pressure moves through an organisation. The Friction Layer sets out where that pressure finally concentrates as strain. The Crossover follows the shared software layer into physical-systems engineering, which has quietly become one of the most AI-exposed functions in the business, without software's review habits. The Capacity to Absorb asks what decides whether a function bends or breaks under the pressure that reaches it. None is needed to follow this one.