How agentic AI changes data roles

AI agents write more of the code, but data teams are not getting smaller. The work is shifting from building to verifying, managing the context and supporting the business, and that changes who you need.

In short: AI agents now write much of the code in data teams, yet most teams expect to grow or stay the same size. The work is shifting from building to verifying what the agents produce, managing the context they work from, and supporting business users. That competence is often found among business users or experienced developers. Most organisations will therefore have to train their own people and give juniors a new way into the field.

Ask an AI agent for last year’s revenue per active customer, and you have the SQL in seconds. The agent does not know that the revenue table counts European refunds twice after a half-finished migration from Stripe. Nor does it know that product and finance each count a customer as active over a different time window. The answer looks right. But it is wrong.

The examples come from a piece by Joe Reis, co-author of the book Fundamentals of Data Engineering. He writes that this kind of knowledge sits in the heads of people who have settled such questions for years, and that they take it with them when they leave.

The agents make building cheap. They do not make it any cheaper to understand what the data means. They also change which skills the data team needs.

Does the data team need fewer people?

The surveys suggest not. Joe Reis asked 1,101 data practitioners in 2026. Of them, 42 per cent expect their team to grow, 44 per cent expect it to stay the same size, and only 7 per cent expect it to shrink.

For us, it is the content of the job that has changed. We estimate that our data engineers at Glitni spent around 70 per cent of their time writing code themselves two years ago. Today it is around 15 per cent. The agents write most of the code on their instructions, and the time goes to clarifications, architecture and decisions, and to directing the agents. We have written more about how we use AI in our coding work.

We think many organisations will need fewer developers overall. Routine operational tasks are disappearing, and there is less need for new applications. At the same time the need for data is growing, because agents and automated workflows need more data and better context. The data team can therefore find many of its new people in the IT department.

What changes in the day-to-day work?

AI agents take most of the work in the middle of the chain, where a clear request becomes code with the help of an agent. An agent now produces standard pipelines in minutes. It maps fields from source to target, translates between SQL dialects and documents what already exists. Three skills remain, and they become more important:

Supporting business users: understanding how decisions are made, and asking the questions an advisor would ask. What is the number for, and what happens if it is wrong? What action should the target trigger? Is it worth spending time on?

Architecture and review: designing solutions that can be run and changed, and checking that the code from the agents is ready for production.

Stewardship of context and harness: keeping track of the concepts, the definitions and what the agents are allowed to do. The harness is the rules, tools and tests around the agent, and the context is what the agent needs to know about the business and the data.

Underneath all three lies the work of getting people to agree on the concepts. Every department can get its own number for active customers in seconds, and the differences often only come to light in the management meeting.

Julien Hurault writes about data engineering in the newsletter Boring Data & AI. He sees that most of the agents’ failures are not down to the SQL. They are down to missing context: a metric was vaguely defined, or a business rule was never written down. Every failure becomes a new rule the agent reads next time. We have written more about why metadata and ontology have become the foundation AI reads from.

Example: a new data source

A data engineer used to build the integration of a new data source herself. Now she writes the rules the agent follows: the naming standard, the tests every dbt model must have, and which tables the agent may read. The agent produces the first draft, and she reviews the code in a PR before it goes into production. She spends the time she saves on clarifying with the business what the fields mean.

Verification is where things most often stall. The dbt Labs survey of 363 data practitioners and leaders shows that 72 per cent prioritise AI-assisted coding, while only 24 per cent prioritise AI-assisted pipeline management, including testing and observability. At the same time, 71 per cent count wrong or hallucinated answers reaching the people who use the numbers among their biggest concerns. Our rule of thumb is to measure two numbers: how much the agents produce, and how much of it anyone has time to verify.

Where do you find the people?

What is scarce is people who both understand the business and have enough technical depth to verify what an agent has produced. Today the two halves usually sit in different people. IBM asked 1,700 chief data officers in 2025, and 77 per cent of them say they struggle to fill key data roles.

The people come from two directions:

From the business side: business analysts, controllers and people who have worked with reports and BI. They are curious about the problem to be solved and know the definitions, but need to build technical breadth in integrations, platform, security and access control. Their understanding of the business ranges from very good to less good.

From the software side: application developers with a technical education and background. They are good technical problem solvers, but need to learn to ask business questions and understand what the data is for.

Many organisations have far more application developers than data engineers, and the developers often know the source systems best, because they built them.

Example: the order without a delivery date

The developer who built the order system knows why an order can be marked as delivered without a delivery date. The controller knows why the same order should not count in the month’s revenue. The agent knows neither until one of them has written it down.

So map who knows the definitions before you map who knows the tools. Reis points to the risk: the people with this knowledge are not getting any younger, and they take it with them when they leave.

Who needs upskilling, and who needs reskilling?

Upskilling means new skills in the same role. Reskilling means moving into a new role. The dividing line is whether people can build the new on what they are good at today. A data engineer already knows how to code, and that is exactly what is needed to check the code the agents write. A BI developer mostly makes reports, and the agent does that now.

Seven roles need upskilling:

Three roles need reskilling:

We think the architect and product owner roles will grow, and that the report and BI developer role will almost disappear. Fewer data scientists are needed too, because off-the-shelf language models solve much of what custom models used to do. Developers in graphical ETL tools need to move to code, because an agent struggles to read, test and change a pipeline that only exists as clicks. We have written more about the choice between graphical tools and code.

Should you train your own people, hire or bring in consultants?

We believe capable people in-house can learn new things, and even if their skills are not 100 per cent there, they probably have the context. Recruitment alone rarely covers the need: IBM found that only 53 per cent of chief data officers say their recruitment and retention efforts give them the skills they need. You have already hired the people who know the definitions, and this approach delivers value faster when the agents write more of the code.

People learn fastest with a structured programme and experienced colleagues alongside them in their daily work. Experienced consultants should build the harness together with your employees, so the knowledge stays when the engagement ends. When you hire, experience with definitions, testing and data management counts for more than familiarity with one particular tool.

What happens to the juniors?

The agents first take the tasks that gave juniors effective learning: simple SQL, standard pipelines and documentation. Researchers at Stanford see the consequences in US payroll data. In June 2026, employment among 22- to 25-year-olds in the occupations most exposed to AI was around 19 per cent below the level it would have reached had it kept pace with similarly aged workers in less-exposed occupations. It appears that fewer young people are being hired, not that more are losing their jobs.

People have to be able to do the job themselves to verify an agent, and that skill is built by doing the job yourself first. Juniors used to get the practice for free. Now the data leader has to plan for it. The industry will have fewer seniors in ten years if it hires fewer juniors today.

Example: the junior’s first dbt model

A junior is asked to build a dbt model for active customers per month. She writes the SQL herself first, then asks the agent for the same and goes through the difference with a senior. The next step is to write the tests that catch the mistakes the agent made. After a few months she owns the definition of an active customer, from the source to the report.

Where should a data leader start?

Start with the tasks. Break each role down into tasks, and ask whether an agent could do the task with good enough context. The answer shows where time is freed up, where verification needs to be built up, and who needs upskilling or reskilling.

Norwegian organisations have barely started. In the 2026 business survey from Nav (the Norwegian Labour and Welfare Administration), 53 per cent of businesses said they use artificial intelligence, but only 26 per cent of them use it for data analysis and forecasting. Data leaders therefore have time to plan the roles before the agents are everywhere in the data team.

1. Find the people who know the definitions. Many of them sit outside the data team. Get their knowledge written down where the agents can read it.
2. Make a plan for each role. Decide who needs upskilling and who needs reskilling, and set aside time for it. Maturity is not built with leftover capacity.
3. Hire juniors on purpose, and give them tasks they solve themselves alongside the agent.

A test: ask who in your organisation can explain why two reports show different numbers for active customers. The answer shows who you need most, and where they sit today.

Would you like to go through the roles in your data team with us? Send us a message.

Frequently asked questions about agentic AI and data roles

Does the data team need fewer people when AI agents write the code? The surveys suggest not. Joe Reis asked 1,101 data practitioners in 2026. Of them, 42 per cent expect their team to grow, and 44 per cent expect it to stay the same size. The agents change the job: less building, and more verification, managing the context and supporting the business.

Which data roles become more important with agentic AI? The roles that combine an understanding of the business with enough technical depth to verify what the agents produce. We think product owners, architects and data stewards will grow, together with experienced analytics engineers and analysts who own the definitions of the metrics. Data engineers build the harness the agents work in.

What is the difference between upskilling and reskilling? Upskilling means new skills in the same role, as when a data engineer goes from writing every pipeline to building the harness the agents work in. Reskilling means moving into a new role, as when a BI developer starts building the semantic layer, or an application developer becomes a data engineer.

Should we train our own people or hire new ones? We believe capable people in-house can learn new things. IBM asked 1,700 chief data officers in 2025, and only 53 per cent say that their recruitment and retention efforts give them the skills they need. Your own people know the definitions, and they learn fastest with a structured programme and experienced colleagues alongside them.

How can juniors learn the craft when agents take the routine tasks? The data leader has to build in the practice on purpose. Juniors can solve the task themselves alongside the agent and go through the difference with a senior. After that they can write the tests and take responsibility for one definition, from the source to the report.

Sources

• Joe Reis: Are Data Teams Cooked?, Joe Reis on Substack, 6 September 2026.
• dbt Labs: New dbt Labs Report Finds AI-driven Acceleration is Outpacing Trust and Governance, on the State of Analytics Engineering 2026 report, 14 April 2026.
• Julien Hurault: The 10x Data Team = The Markdown Team, Boring Data & AI, 24 April 2026.
• IBM Institute for Business Value: IBM Study: Chief Data Officers Redefine Strategies as AI Ambitions Outpace Readiness, press release on the survey of 1,700 chief data officers, 13 November 2025.
• Erik Brynjolfsson, Bharat Chandar and Ruyu Chen: No Widespread Displacement, but the AI Employment Gap for Young Workers Has Widened to 19%, on the revision of “Canaries in the Coal Mine? Six Facts About the Recent Employment Effects of Artificial Intelligence”, Stanford Digital Economy Lab, 12 August 2026.
• Nav: Bedriftsundersøkelsen 2026 (the 2026 business survey, in Norwegian), Nav report 2026: 2, May 2026.