Skip to main content

IT Teams evolution in AI era

 When we discuss AI in IT delivery, the main point isn’t that AI will take over everyone’s jobs. The bigger shift is that AI will cut down on the number of handovers between people. Right now, a feature might go from a Business Analyst to a Product Owner, then to a developer, tester, DevOps, and finally support. Each step adds meetings, tickets, explanations, and sometimes delays.

With AI, many of these tasks won’t go away completely, but they’ll be combined into broader roles. Teams might get smaller in some areas, but more importantly, the way teams are structured will change.



Before going into more details, you can find below a possible mapping of new roles, covering the full SDLC.

Before

With AI

BA + PO + Process Analyst + Data Analyst

Product Discovery Lead

Scrum Master + PMO + Project Coordinator

Delivery Manager

Developer + QA Automation + Basic Tester

AI Product Engineer

Manual QA + QA Analyst + Test Case Writer

Quality Engineer

DevOps + Build + Release + Environment

Platform OR Release Reliability Engineer

Cloud + Infra + Sysadmin

Platform Engineer

NOC + Monitoring + Incident Support

AIOps

L1 Support + Desktop + Knowledge Support

Digital Workplace Automation Engineer

In the next sections, we will cover each main phase of SDLC and explore what the future roles might look like.

1. Requirements and discovery

Before AI, discovery often needed several people: a Business Analyst, a Product Owner, a Process Analyst, and sometimes a Data Analyst. Each person handled a small part of the work. The BA wrote requirements, the Product Owner managed the backlog, the process analyst mapped flows, and the data analyst reviewed numbers.

With AI, one stronger role, the Product Discovery Lead, can handle many of these tasks. AI can summarise meetings, create user stories, draft acceptance criteria, and analyse feedback. The focus shifts from writing documents to really understanding the business problem.

Before

With AI

What

Business Analyst

Product Discovery Lead

Requirements-only Business Analyst

Product Owner

Product Discovery Lead OR Product Manager

Junior Product Owner focused only on backlog admin

Process Analyst

Product Discovery Lead

Process Documentation Analyst

Data Analyst

Product Discovery Lead

Basic reporting Data Analyst

2. Planning and delivery management

Right now, planning and delivery might include a Scrum Master, Project Manager, PMO Analyst, and Project Coordinator. Some of these roles are still needed, especially for large programs. But many of the tasks are repetitive, such as status reports, meeting notes, RAID logs, sprint summaries, and dependency tracking.

AI can automate much of this admin work. Because of this, these roles might combine into a Delivery Manager role. This person does more than just organise meetings; they focus on delivery flow, blockers, risks, and dependencies.

Before

With AI

What

Scrum Master

Delivery Manager

Ceremony-only Scrum Master

Project Manager

Delivery Manager OR Program Manager

Project Manager focused only on tracking

PMO Analyst

Delivery Manager

PMO Reporting Analyst

Project Coordinator

Delivery Manager

Status Reporting Analyst

Delivery Manager

Delivery Manager

Delivery Coordinator

3. Technical design and architecture

In architecture, AI will be very helpful, but it won’t replace senior judgment. AI can create diagrams, compare architecture options, and write decision records. However, people still need to handle trade-offs, risks, integration, scalability, and costs.

In the future, roles will look more like AI-native Solution Architects or Technical Leads. They’ll use AI as a design assistant, but people will still make the final decisions.

Before

With AI

What

Solution Architect

AI-native Solution Architect

Junior Solution Designer

Tech Lead

AI-native Technical Lead

Technical Diagram Designer

Security Architect

Security Architect OR AI Security Architect

Security checklist-only reviewer

Data Architect

Data OR AI Architect

Architecture documentation analyst

4. Development and testing

This might be the biggest change. Right now, developers and testers are usually separate. Developers write code, QA writes test cases, automation engineers create scripts, and manual testers run regression tests.

With AI, one engineer can generate code, tests, test data, mocks, and documentation. This means future teams will have more AI-enabled Product Engineers who focus on quality. Developers will need to take more responsibility for quality. Testers will shift from manual work to quality strategy, exploratory testing, and risk-based testing.

Before

With AI

What

Frontend Developer

AI-enabled Product Engineer

Junior Frontend Developer doing basic UI only

Backend Developer

AI-enabled Product Engineer

Junior Backend Developer doing boilerplate only

Integration Developer

AI-enabled Product Engineer

Simple API Developer

QA Automation Engineer

Quality Engineer

QA Automation as isolated separate role

Manual QA Tester

Quality Engineer

Manual QA Tester, Regression Tester

QA Analyst

Quality Engineer

Test Case Writer

UAT Coordinator

Product Discovery Lead OR Quality Engineer

UAT Coordinator as standalone role


5. DevOps, release and infrastructure

Before AI, there were often separate people for DevOps, build, release, environments, cloud, and infrastructure. Much of this work relied on scripts, pipelines, checklists, and repeatable processes.

AI, along with platform engineering, will combine many of these roles into a Platform or Reliability Engineer role. The focus will shift from manual deployment to self-service platforms, reusable pipelines, automated checks, and reliable cloud foundations.

Before

With AI

What

DevOps Engineer

Platform Engineer

DevOps focused only on pipeline tickets

Build Engineer

Platform Engineer

Build Engineer

Release Manager

Platform OR Reliability Engineer

Manual Release Coordinator

Environment Manager

Platform Engineer

Environment Booking Coordinator

Cloud Engineer

Platform OR Reliability Engineer

Cloud Provisioning Engineer

System Administrator

Platform Engineer

Traditional Sysadmin

Infrastructure Engineer

Platform Engineer

Infrastructure Administrator

6. Operations and support

Operations and support will also change a lot. Today, L1 support, NOC analysts, and monitoring teams spend a lot of time on standard tickets, dashboards and alerts. AI agents can already help with password resets, known issues, ticket routing, alert correlation and incident summaries.

In the future, roles like AIOps, Reliability Engineer and Digital Workplace Automation will become common. People will still be needed for complex incidents and important decisions, but not for every simple ticket or alert.

Before

With AI

What

L1 Service Desk Agent

Digital Workplace Automation Engineer

L1 Service Desk Agent

Helpdesk Analyst

Digital Workplace Automation Engineer

Helpdesk Analyst

Desktop Support

Digital Workplace Automation Engineer

Basic Desktop Support Technician

Password Reset Operator

Digital Workplace Automation

Password Reset Operator

Access Request Operator

Digital Workplace Automation

Access Request Operator

NOC Analyst

AIOps OR Reliability Engineer

NOC Analyst

Monitoring Specialist

AIOpsOR  Reliability Engineer

Dashboard Monitoring Specialist

Incident Coordinator

AIOps OR Reliability Engineer

Incident Scribe, RCA Documentation Analyst

Final thought

The future IT team will not only be smaller; it will also be more efficient. It will be more integrated. Roles will merge where the work is repetitive, document-heavy, checklist-driven or based on handovers.

People will be the gates where judgment, architecture, business ownership, security, quality and human coordination are important.

 

Comments

Popular posts from this blog

How to audit an Azure Cosmos DB

In this post, we will talk about how we can audit an Azure Cosmos DB database. Before jumping into the problem let us define the business requirement: As an Administrator I want to be able to audit all changes that were done to specific collection inside my Azure Cosmos DB. The requirement is simple, but can be a little tricky to implement fully. First of all when you are using Azure Cosmos DB or any other storage solution there are 99% odds that you’ll have more than one system that writes data to it. This means that you have or not have control on the systems that are doing any create/update/delete operations. Solution 1: Diagnostic Logs Cosmos DB allows us activate diagnostics logs and stream the output a storage account for achieving to other systems like Event Hub or Log Analytics. This would allow us to have information related to who, when, what, response code and how the access operation to our Cosmos DB was done. Beside this there is a field that specifies what was th...

Can User Technical Profile Influence AI Architecture Decisions?

In the last few days, I ran a small experiment on Devin/Windsurf/Cascade, BMAD, and LLM-based architecture decisions. The initial concern was simple: if an AI coding assistant knows something about the user, for example, that the user is a Java developer or a .NET developer, can this information influence the architecture and technology stack that the AI will propose? This question is important because many companies are starting to use AI tools not only for coding but also for product discovery, architecture, documentation, and technical decision-making. If the AI is influenced by the developer's personal profile, the result may not be fully neutral. It may look like a business or architecture decision, but in reality, it may be partially shaped by the context of the person using the tool. The test was done using BMAD with Devin/Windsurf/Cascade. The scenario was a unified field service operations platform. The task was to let BMAD refine the product, define the architecture and s...

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see...