IT built its legitimacy on one skill: translating the business’s intentions into working software. It is a role organizations paid dearly for over thirty years, and one that is disappearing faster than anyone is planning for. The real question is not how IT will adapt. It is what IT will produce once its original reason for being no longer exists. What some organizations have started building in its place is more radical, and more coherent, than you might imagine.
I. The incident
It is a Friday afternoon in September 2026. In a Teams channel you rarely check, you discover that a sales team has put an automated reporting tool into production. The tool consolidates data from three different sources, generates weekly summaries by client portfolio, and sends alerts as soon as a threshold is crossed.
You look at the project’s creation date in Github.
Monday.
Five days.
Your first reaction is bureaucratic. No formal request, no architecture sign-off, no review by the change advisory board. You think about the governance memo you are going to have to write.
Then you look at the tool. It works. People are using it. No bug reports. The person who built it is not an engineer: she is a product manager. She just used Claude Code.
You close Teams. You open your IT backlog. The equivalent feature has been waiting for seven months, estimated at twelve weeks of development, stuck in an ongoing prioritization with three teams.
You could write the governance memo. You don’t. Instead, you ask yourself a question you had never really put into words: if the business can do this on its own, what good are we, IT?
II. The diagnosis
The honest answer takes a few weeks to build. It is uncomfortable.
IT really does three things.
It translates. Historically, this is the heart of the job: turning a business intention into a specification, a specification into code, code into tests, tests into a production release. This translation chain has justified the existence of Business Analysts, developers, testers, release managers, level 1 and level 2 support. In your organization, these roles make up 60 to 70% of IT headcount.
It operates. It keeps systems running in production, handles incidents, ensures continuity. Part of this can gradually be automated: detecting, diagnosing and resolving infrastructure incidents. Another part probably cannot, in the medium term. Decisions with a direct financial or regulatory impact require human judgment and documented traceability.
It governs. It defines who has the right to do what on the systems, under which conditions, with what auditability. This role exists in every IT organization, but it is rarely structured as a function in its own right. In most cases, it is exercised by default: by overloaded architects, security managers with too broad a scope, committees that meet too rarely.
This diagnosis has a direct implication. Translation, the bulk of the headcount, is the part that generative AI tools are compressing the fastest. What the product manager did in five days is exactly that translation work: she formalized her intention in natural language and got working software. The middleman step disappeared.
Operations and governance hold up better. Not because they are safe from automation, but because they carry responsibilities that nobody can delegate to a system without explicit human oversight.
The real question gets reframed. If translation disappears, what is IT’s product? What does it provide to the business?
The answer is not “fewer things”. It is fundamentally different things. IT stops being a supplier of deliveries and becomes a supplier of capabilities: platforms, agents, infrastructure on which the business and the IT teams aligned with it build directly. This shift changes the nature of the work, the profiles required, and the organizational model. It does not happen through marginal adjustments.
III. The plan: what it really cost
You present the diagnosis to the executive committee in November 2026. The room is attentive. The executive committee understands what is at stake with AI: it has been approving the corresponding budgets for two years. What it grasps less well is the conclusion you draw from it: cutting IT headcount by 65% over four years, reshaping what remains around three capability pillars, and creating an agent governance function that did not exist.
The CEO asks you the predictable question: how do you announce a massive IT cut when digital transformation is the group’s priority?
You answer that the cut is the transformation. That keeping 200 people on a translation model that is becoming obsolete means investing in something AI does better and cheaper. That the 70 people who remain will do structurally different work: more demanding, better paid, not replaceable in the medium term.
The CEO approves the plan. That is not the hard part.
The hard part starts with the teams.
Your Tribe Lead used to run a tribe of sixty people spread across five squads. In the target model, his cluster has twelve people, four of whom do not report to him directly: they belong to the AI Engineering pillar, embedded in his cluster for 80% of their time. His organizational legitimacy rested partly on the scope he controlled. He resists. Not openly. He asks for clarifications on the governance model, raises coordination risks, suggests variants that would keep his scope intact. You recognize the pattern. You name it clearly in a one-on-one: it is his own position in this model that he is calling into question. The conversation is difficult. It is necessary.
The developers are another source of tension. Some make the transition to the role of AI Systems Engineer: they learn to orchestrate agents, to evaluate behaviors, to design systems that supervise other systems. The transition takes time, and it requires a capacity for abstraction that cannot be decreed. Your HR director warns you in the first half of 2027: mid-level profiles, ten years of experience in a specific technical field, struggle the most. Their core skill is precisely what is being automated the fastest: writing code specific to their field. Retraining is possible for some of them. Not for all. You lose people through voluntary departures or mutual agreement. It is a reality the plan accepts from the start, not a surprise along the way.
The business creates a tension you had not anticipated. It wants the autonomy the new model offers: building its own tools, defining its own agents. But it resists the other side of the deal: taking responsibility for those tools. When a tool built outside IT supervision produces a data anomaly or a calculation error, the question of accountability gets blurry. You impose a simple rule from 2027 on: any tool that touches a critical information system or a regulatory flow goes through an IT validation process. Not delivery: certification. IT no longer builds what the business can build on its own. It certifies that what the business built is safe. The rule creates friction the first year. It prevents significant incidents in the years that follow.
The regulator is a constraint you did not choose, but one that turns out to shape everything. The requirements for documented human oversight of high-impact decisions limit the autonomy of agents on certain flows: market abuse surveillance, regulatory reporting. These constraints force your organization to build explicit governance where there was only the implicit. By 2029, this governance is an asset. It is what allows your agents to run without the regulator calling them into question.
IV. 2030
Your IT organization now has 70 people. It had 200 in 2026.
What shrank sharply: level 1 and level 2 support, about 80% automated for infrastructure and data incidents in your context. Dedicated testers, whose tasks are now generated and run continuously by agents. Release managers, replaced by a continuous process with automated checkpoints. Scrum Masters and portfolio coordinators, whose workflow orchestration is automated. Manual reconciliation operators: exceptions are detected, categorized and handled without human intervention in the vast majority of cases.
What remains is organized into three pillars.
Domain Intelligence, 35 people. These are the profiles who hold the business knowledge that no agent can acquire through training. Not developers: domain specialists who know what a valuation agent should do in a dislocated market, what a regulatory rule implies in an edge case nobody has formalized, what an anomaly signal means in the specific context of your organization.
The 35 are split into six expertise clusters of four to six people. This split answers two specific constraints. The first is resilience: on each critical domain, at least two people share the same tacit knowledge. The risk of depending on a single holder of knowledge has disappeared from the model. The second is transmission: senior profiles specify, validate and handle escalations. Junior profiles observe, ask questions, take charge of narrow scopes until they master the whole. It is an apprenticeship model, the new peer programming.
Each cluster covers a broader functional scope than the old squads. A squad in the Spotify model was built around one specific flow. A Domain Intelligence cluster covers an entire domain, with its variants and its edge cases. Agents handle the standard cases. Humans handle the cases that agents cannot recognize as exceptional.
Their job is no longer to write code. It is to specify precisely the behaviors expected of agents, to validate their outputs, and to handle the escalations they cannot resolve on their own. This role is more demanding than a developer’s, not less.
AI Engineering Platform, 20 people. This is the only line in your organization that has grown since 2026, both in proportion and in absolute terms.
Their work is organized around three responsibilities. The first is building the shared agentic infrastructure: the orchestration patterns all clusters use, the processes for deploying to production and rolling back, the interfaces with external language models. Every Domain Intelligence cluster relies on these building blocks. Nobody rebuilds their own. The second is observability: behavioral monitoring of the fleet of agents in production, automatic kill switches when an agent drifts beyond a defined threshold, dashboards that make it possible to detect anomalies before they become incidents. The third is evaluation: test frameworks that qualify an agent’s behavior before it goes into production, not only its technical performance, but its outputs on business edge cases defined by the Domain Intelligence clusters.
These profiles are not attached to any specific business domain. They serve all the clusters of the first pillar. In 2026, they were scattered across secondary functions. It has become the central pillar.
Data & Intelligence, 10 people. Their work is the least visible in the organization. It is also the one that holds everything else up.
They maintain the pipelines that feed agents with up-to-date data, with quality controls that detect anomalies at the source rather than at the agent’s output. They formalize the contracts between data producers and the agents that consume the data: who produces what, how often, in what format, with what freshness guarantee. This formalization work is recent. Before 2026, data circulated informally and ambiguities were resolved in meetings. Everything had to be formalized.
They also maintain the infrastructure that gives agents access to organizational memory: past decisions, documented incidents, historical configurations. A valuation agent that does not know what happened to an underlying asset last month takes risks its parameters do not capture. This memory does not build itself automatically. It has to be maintained.
Five more people make up cross-cutting governance: who has the final say on an agent in production, under which conditions it gets shut down, how decisions are documented for the regulator, who is accountable when an agent drifts.
The only line that grew is the one that supervises, evaluates and governs intelligent systems. Not the one that writes code for the business.
This shift says everything about what IT’s product has become.
What you did, and what you didn’t do
The Friday afternoon incident has already happened in your organization, or it will happen in the coming months.
Don’t ask yourself how to rein in the Shadow IT that comes out of it. Answer instead the only question that matters: if the business can do without your translation, what is IT’s product?
Answering honestly means retraining those who can be retrained, parting ways with those who cannot, and building something structurally different. It is a redefinition of scope.
The organizations doing it now are building something. The others will get nibbled away by their own business, flow by flow, without anyone really deciding it.
Reminds me of a story about a frog in a pot of water…