The Question Isn't What AI Replaces. It's What Your IT Department Becomes When Execution Is Free.

This article is the second of two in the series "What AI Actually Replaces." The first argued that AI doesn't come for SAP expertise. It comes for the friction layer, the roles that exist only because information travels badly. This one asks the question that leaves open: if execution is becoming nearly free, what is your IT department actually for?

Let me put a warning on this one before I write a word of it. Nobody knows what the future looks like, me included. This piece is an extrapolation, not a forecast. It's built on three things: what I've seen on the ground across ten years of SAP work, what I studied in economics, and what I read every week in the American tech press, which runs a few years ahead of where my own corner of the world is. Treat it as a hypothesis worth thinking through, not a prediction I'm asking you to bet on.

With that said, here's the hypothesis.

The first article in this series argued that AI eats the friction layer first, the re-encoding, the relays, the work that looked like expertise and was actually transcription. If that's right, the natural next question for a CIO is "how many people do I still need?" And that is the wrong question. It assumes the department is a production capacity, a thing you size by how much it has to produce. The moment execution stops being the bottleneck, that whole way of counting breaks.

The value doesn't vanish. It moves.

The value doesn't evaporate when the cost does. It moves to wherever the new scarcity is.

When execution gets cheap, being able to execute stops being worth much. What becomes valuable is knowing what to execute, and whether what came back is right. On a project, I've watched the moment when writing the code stopped being the hard part. The hard part was always upstream of that: deciding what the thing should do, against a landscape nobody fully held in their head.

So the question isn't whether AI makes execution cheap. It will. The question is what your department is for once that's true, and the answer is the part that was never execution in the first place.

The wall of context

There's a hard technical reason the judgment part isn't getting automated soon, and it's worth being precise about it rather than waving at "the human touch."

An AI today works inside a context window of around a million tokens at the frontier, with a few models claiming several times that. As of mid-2026 that's the state of play, and it moves fast, so treat the number as a snapshot. It sounds enormous until you measure it against what a company actually is. The accumulated record of an enterprise, its configuration history, its specifications, its exceptions, the decisions buried in a decade of tickets, runs to tens of millions of tokens. For a large group, more. And it gets worse, because the advertised window isn't the usable one. Independent benchmarks show effective context degrades well before the limit, with reliable performance often holding only up to about half the advertised size, and accuracy falling off once you actually fill it.

So no, there is no press-button LLM that knows what to look at and where, at the scale of a whole organization. Not today. The thing that knows where to look, which table, which custom program, which old decision still constrains this one, is a person who has lived in that system. The model can read what you point it at. It cannot yet decide what to point itself at, across a landscape too large to fit and too undocumented to load.

The hidden factory: where judgment is actually made

The productivity math never sees this part, and it's the heart of why cutting execution is a mistake rather than a saving.

Think about how a person actually becomes an SAP expert. You don't start as one. You start as someone else's hands. You build the Excel sheet, you make the slide deck, you set one isolated customizing point because someone told you exactly which one. Then a senior starts explaining the use cases behind what you're touching, why this configuration and not that one. Then, the real turn: they teach you to clear new ground yourself. How to search the customizing, how to find the tables and the technical field names behind a screen, how to dig up the programs that already exist, how to search Google and the forums and the SAP Notes when the answer isn't in front of you. From there you become the owner of whole process flows. Then you can walk into a new technical subject you've never seen and find your own way through it. And then, if you want, you move on to project management, or into ABAP.

Every one of those steps is built on the execution work underneath it. The grunt work was never just grunt work. It was the apprenticeship.

Now picture a junior who skips all of it because the AI just hands over the answer. They look productive. The output is there. But they've caught the fish without ever learning to fish. They succeed exactly as long as someone, or something, keeps handing them the fish. The day the AI can't crack the problem, and on a real client landscape that day comes often, they're stuck, because they never built the thing the apprenticeship was quietly building: the judgment to know where to look when nothing works.

Cut the execution layer to the bone and you don't just save a cost. You unplug the factory that turns juniors into the seniors whose judgment you just decided was the only thing worth paying for. You need them to become that, at exactly the moment you've removed the path that gets them there.

What IT actually becomes: the architect of context

So if the department isn't a production line anymore, what is it?

Here's the shift. Before AI, IT's job was to guarantee that when "A" goes into SAP, the business rules you configured return "B," exactly as the rules say they should. That was the work: correct, controlled execution of a logic someone specified.

That job doesn't disappear, but a new layer sits on top of it, and it's the one that matters now. When a new business rule arrives, the work becomes structuring the context, the data, and the architecture so that the AI can implement a correct solution, or propose a correct one to the business on its own. You stop being the one who builds "B." You become the one who arranges everything around the machine so that what it builds is right, and so that it can be trusted to build it without you in the loop for every step.

This is already visible in the more open tech-web world, where the tools landed first. It will reach the ERP world with a lag, the way most things do, because ours is a closed, conservative, heavily regulated corner and the open one always runs a few years ahead. I'm extrapolating across that gap, deliberately. But the direction is the same: orchestration and context design become the work, and raw execution becomes the thing you supervise rather than the thing you do.

What a CIO should actually do now

If the hypothesis holds, the worst move is the one that looks smartest on a spreadsheet: take the productivity gain, divide your headcount by it, and cut. The open web has already run that experiment, and the results are in.

Companies that replaced people with AI have been quietly hiring them back. IBM cut thousands of HR roles for an AI system, then found it couldn't handle the cases that needed judgment or empathy, and started rehiring. The pattern has a name now, the "AI boomerang," and the numbers aren't marginal: a Robert Half survey put it at close to a third of companies rehiring for roles they'd cut after deploying AI, and Forrester's 2026 work reported that around 55% of employers regretted laying people off for AI reasons. And the sting in the tail: the people who come back often come back lower-paid and, more importantly, stripped of the institutional knowledge they took with them when they left. That knowledge, the undocumented context, was the thing of value, and it doesn't reload like a file.

So the move isn't to size the team by execution capacity. It's to ask a different question for every role and every euro. Stop asking "how many tasks, divided by AI productivity, equals how many heads." Start asking: am I paying for execution, which is heading toward free, or for judgment and context, which are getting rarer and more expensive? Fund the second. Protect the junior pipeline as an investment in future judgment rather than cutting it as a present cost. Move the budget that used to buy raw execution toward data governance and architecture, because that is where the value is migrating.

It's where the arrows point if you take the open-web evidence and the technical limits seriously and extrapolate honestly across the lag.

So what your IT department becomes

Pull it together and the department isn't shrinking into irrelevance. It's being pushed into the role it probably should have held all along.

Before AI, the DSI made sure the machine ran the rules correctly: "A" in, "B" out, as specified. That was guardianship of execution. What's arriving on top is a different job: architect of the context, orchestrator of the intelligence and the information that the business functions run on. The work becomes making sure that when the business changes its rules, the machines around it can be trusted to implement the right thing, or to propose the right thing, because someone designed the context for them to do so.

The CIO who sees that recruits judgment while the others are still counting hands. Execution was never the point. It was only ever the thing that, for a while, happened to be scarce.