The IT sector holds a position that few other sectors have: the work done here consists largely of tasks involving text, code and structured data. That is exactly the kind of work language models and AI assistants are trained on the most. Where in other sectors AI first enters at the edges of the work, in IT part of the core activity is already close to what these systems do well.
The hours in an IT organisation fall roughly into a number of blocks: software development and maintenance, functional and technical management, service desk and ticket handling, testing and quality control, documentation, and project-based work such as planning and reporting. Each of these blocks has its own ratio between tasks that are readily automated and tasks that are not yet suited for that.
Within software development, generating, restructuring and documenting code is a task where AI already performs a substantial part of the work independently. Standard functions, boilerplate code, converting specifications into first versions of scripts: this is work where a developer increasingly reviews an AI proposal rather than writing something from scratch. Something similar applies at the service desk for the first triage of tickets: recognising the type of problem, linking it to known solutions, and forwarding it to the right next step.
Testing work is shifting too. Generating test cases based on specifications, and flagging deviations in test results, is task work that is readily taken over once the input is structured enough. Documentation of systems, APIs and releases is a third area where AI often already delivers the first draft.
The second category, partly automatic with human oversight, is broader in IT than in many other sectors, precisely because the consequences of an error in code or infrastructure occur quickly and sometimes irreversibly. An AI proposal for a code change is reviewed by a developer; automated advice on a network configuration is checked before it is implemented. This pattern of approval or rejection with reasoning recurs in deployments, in security scans and in the assessment of architecture choices.
The way financial systems must be able to account for changes shows well how this combination of automation and oversight works in practice: anyone wanting to know whether an audit log of financial changes can be maintained by AI will see that recording can often happen automatically, while assessing the change itself requires a human. That principle applies equally to infrastructure changes within an IT environment.
Architecture decisions, translating vague client wishes into a workable design, and managing the relationship with clients are tasks that remain in the third category. This work requires combining technical knowledge with organisational insight and taking responsibility for a choice that does not follow from data alone. Complex problem diagnosis, where a fault affects multiple systems and there is no comparable incident on record, also remains human work for the time being.
Whether a task in IT is actually taken over depends not only on what is technically possible. It depends on how structured the organisation's own systems are, how much historical data is available to train or validate against, and how the organisation handles the oversight required for the second category. An IT department with well-documented code and clear ticket categories can move faster than a department where knowledge mainly resides in the heads of employees.
This dependence on the specific situation is not unique to IT. Anyone looking at which work in financial services is the first candidate for AI will see a similar pattern: structured, rule-bound tasks shift sooner than tasks requiring personal judgement. Even in sectors substantively far removed from IT, as shown by the analysis of what AI can take over in construction, the same question applies: how structured is the work, and how much oversight is needed before an outcome is usable.
This breakdown into three categories says something about work in general, not about the specific tasks within your own organisation. An IT company that mainly delivers custom work for complex clients has a different distribution than a company that predominantly carries out management tasks for a fixed set of systems. That difference determines how many of the hours already fall into the first or second category today.
What an employer subsequently does with that outcome falls outside what we describe as a work scan. Decisions affecting personnel are subject to their own legal requirements; these are not addressed here, and this is not a basis for such decisions.
To see how this breakdown plays out for your own company, there is the free quickscan: twelve questions, no account required, resulting in an indication of what portion of the hours in that profile can be taken over by AI today. The full work scan, which breaks the work down task by task and assesses it on eight axes, is still under construction. The quickscan already provides an initial direction, without going beyond that direction.
Vraag maar. Ik ken de kennisbank van deze site; wat ik niet weet, zeg ik erbij.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.