Agentic coding: What actually changes in data and dev work

Studies are split on whether AI makes developers faster, even though people often think the answer is a resounding "yes (duh!)."

Generally speaking, they show that when people are working in unfamiliar territory, agentic coding does speed things up, whereas results are the same or even slower when experienced engineers are working in code they already know well.

If “faster” is the only thing you measure, agentic coding looks like it could go either way, but I feel that speed is the wrong thing to focus on.

This blog post is based on a presentation by FELD M Data Architect, João Santos. We used a language model to summarise the main insights into a blog post. The final content was edited and critically reviewed by João and Eilish Prioul, our Marketing Lead, who has worked in B2B marketing since 2018.

With that in mind, in this blog post I'm sharing what actually changed in my day-to-day work once agentic coding entered the picture, and my tips on how you can get value from it without paying for it later.

My TL;DR is that the work shifts rather than disappears, and knowing where it shifts to is most of the battle.

Here's what I'll cover in this article:

• How much AI speeds up developers depends on what you're doing and who is doing it: it's beneficial for unfamiliar tasks but may slow experienced developers working in code they're familiar with.

• We'll look at "agentic coding," which differs from simple autocomplete by allowing AI to plan and execute tasks while a developer directs the process.

• How effort shifts from coding to directing and validating, taking the example of the Analytics Engineer to see how it impacts each aspect of the role.

• Which aspects of work change with AI: finding and building become easier while understanding and validation require more effort.

• My tips for an effective setup: Clear guidelines, connected tools, and structured instructions.

• Where all this leaves us: The value of traditional coding skills is diminishing, while framing questions, domain knowledge, and judgment are becoming more critical in the age of AI.

What is agentic coding?

Two very different things get called “AI coding”:

• AI code completion is inline autocomplete inside your editor. It suggests the next line or few, and you stay in the driver’s seat, accepting or rejecting as you type. The scope is a few lines at a time. You are still doing the work, just faster.
• Agentic coding is different. You hand the agent a goal. It plans, edits across many files, runs commands and tests, and iterates on its own while you review and steer. The scope is a whole task. The agent does the work, and you direct it.

In this article, I'm focusing on the latter. Agentic coding doesn't make you type faster, but it does change what you spend your time on.

Three things you can expect from agentic coding

• Speed is the wrong thing to measure to find out whether you're more effective with agentic coding.
• The work shifts from producing (writing code, looking things up) to directing and verifying.
• The developer is still accountable. Judgment, validation, and ownership remain the developer's responsibility.

Who does this work? A spectrum, and one role to follow

It's tempting to file agentic coding under “software engineering,” but all sorts of people in all sorts of different roles use it, from mostly-analytical to mostly-code, including:

• Data analyst: Mostly analytical work. Questions, SQL, and dashboards, with barely any software engineering.
• Analytics engineer: More code, still bounded. Models and transformations (dbt), with some engineering practices applied lightly.
• Data engineer: Much closer to a software engineer. Pipelines, orchestration, and infrastructure, but the domain is data.
• Software engineer: Mostly code workflows. Git flow, backend, and systems, with little direct data work.

Most people find that their role encompasses several of these roles. So for this blog post, I'll be focusing on one role that sits nicely in the middle and interacts with both worlds: the Analytics Engineer.

They write real code (dbt models, SQL transformations, tests) and move it through Git and CI, but their domain is data and the questions are analytical.

Because they straddle the line, what changes for them with agentic coding gives us a decent insight into what changes for everyone: an analyst will recognize the data-and-SQL parts, a software engineer the Git-and-testing parts. The examples from here on follow that role.

What changes at each step of the work

Take a typical Analytics Engineering task: a stakeholder asks for a metric, and you need to build or fix the model that produces it. As a rule of thumb, finding and building get lighter, while understanding and validation get heavier. I've tried to visualize that shift in the table below; this applies whether you lean more analyst or more engineer.

A useful way to think about any single step is to ask three questions: what does AI give me here, what goes wrong, and what do I do about it?

1. Finding and building get lighter

This is where you save time.

An agent answers in seconds what used to be a hunt through the data warehouse, trying to figure out things like which table actually holds the truth, whether a dbt model already exists, and a first draft of the SQL transformation.

But agentic coding will happily join on the wrong key, pick a column that looks like your metric but is not the definition your company reports, or invent a dbt macro that does not exist.

To fix this, you need to school the agent in your documented models and connected tools, train it to ask why rather than just what, and to confirm the definition matches the one you expected before you build on what it gives you.

2. Understanding and validation get heavier

Now you have a model you did not write, and you have to prove it is right. That means reading the SQL, checking the grain (one row per what?), and reconciling the numbers against a figure you already trust (last month’s report, an independent total, etc.).

It also means making the dbt tests meaningful rather than decorative. With agentic coding at hand, you can write 100 tests that don't really test anything, so you need to spend time making sure they're understandable and actually test what they say they do.

This is where the time the agent saved you gets spent again, and if you skip this step, all you're doing is moving the cost downstream to the next person who trusts the number.

3. Framing and shipping stay human

These two ends of the work stay much the same. Framing the request needs human judgment as ever: what does “active user” mean, at what grain, over which window (and AI is only too happy to amplify a vague brief into a confident, wrong answer!).

Shipping stays human too, because you're the one who merges the model and stands behind the number on the dashboard. These are the steps you want to keep human. 

In practice: My setup, and what I’ve learned

A lot of whether this works comes down to the setup, and most of that setup isn't really about me so much as about the environment I'm working in.

Setup

• Good guidelines and guardrails (coding standards, linters, dbt conventions) have helped me keep the output coherent.

• Agents connected to the tools we actually use (the data warehouse and dbt docs, Jira, Confluence, GitHub) let them reason from real context instead of guessing.

• Well-structured instructions (including subagents with their own focused prompts and a project instructions file) push the agent toward a repeatable workflow.

• And I insist on reviewable artifacts (a findings document, the SQL and its results, the model and its tests, a PR description) so I can vouch for the output and actually understand it.

Planning

• This is where an agent hugely helps me. Because it has seen many solutions to similar problems, you effectively get three approaches for the price of one (three ways to model the same metric), and you can pressure-test your assumptions before writing a line.

• You then rely on your own experience to decide which of those approaches makes the most sense.

Development

• You're working with a tool that builds tools, so it can take some time to get your head around this part.

• Use the right tool for the job: build small deterministic scripts for deterministic problems, and save the agent for the parts that need finessing afterwards.

Evaluation

To catch output that seems right but isn't (which you'll need to do on a recurring basis):

• Sample a few real cases

• Check that your assumptions actually hold, for instance, by reconciling the metric against a number you already trust rather than assuming it lines up.

• I find it helps me to remember that humans aren't that great at writing tests either, and that the AI learned from us, so the tests it writes need the same scrutiny as its code.

That leaves me with two big topics open.

• Reliability is the big one: Agents sometimes do not go deep enough and reach incorrect or incomplete conclusions, which sends me back into the output to analyze and interrogate it.

• Some agents let you get away with loose instructions; others need a lot of detail before they behave as you'd expect. So remember that the underlying agent (Claude, Copilot, etc.) is not interchangeable.

Where you gain speed is by running multiple agents at once

Everything I've listed above aside, one key benefit that doesn't require you to be faster at any single task is that you can run several streams at once.

So while the agent builds one model, you review another, and the gain comes from concurrency, not per-task speed.

Of course there are limits. Every stream still funnels back through the same human review, so if you launch more than you can meaningfully check, the extra work is left unreviewed. The ceiling to this approach is your capacity to review and integrate, not the number of agents you can spawn.

So my tip is to give each stream a clearly isolated scope, run only as many as you can properly review, and treat integration as its own step.

It depends on the person: seniority and working style

Two people can use the same tool and get very different results, and it is not only about skill.

• Experience shows up in the context you give, not how fast you type. A junior analytics engineer is more likely to get fooled by a model that looks almost right, and to let the agent guess the details. A senior spells those details out from the start — the grain, what the metric actually means — and asks for the proof behind every assumption. Knowing how much context an agent needs is a sign of experience in itself.
• It also depends on you as an individual. Some people do great work running several threads at once; others perform better focusing on one task at a time. The trick is to play to your strengths and make a point of covering your style's blind spot. Don't force yourself to work the other way.

Tool-specific knowledge is losing value

Knowing the tool is worth less than it used to be. The syntax of Python, the flavor of SQL, the exact dbt macro or Jinja incantation — the agent has all of that, and it recalls it faster than you can.

What is gaining value is everything the agent does not have:

• Framing the right question

• The business logic and domain knowledge that decide what “correct” even means (what “active user” means, which of three revenue tables is the source of truth)

• The best practices that keep a system maintainable (architecture, testing, review, data modeling), and

• The judgment to know when the output is wrong and when to stop.

The AI knows the tool/language. It does not know your business, your data, or what good looks like. That part is the job now.

What this means for you

Agentic coding is leverage when you bring discipline to it, and a liability when you do not. The same capability that lets one person cover more ground will just as happily flood your warehouse with confident, unreviewed models that are flat out wrong. 

So stop grading it on speed. Judge it on whether it lets you spend more of your attention on the parts that actually matter — framing, judgment, validation, and business context — and less on the mechanical production that never really needed a human.

Adapt the workflow to your role on the spectrum and to your own way of working, invest in the environment (standards, connected tools, data quality) that makes the output trustworthy, and keep the human firmly on the steps where accountability lives.

The AI writes the code. You own the outcome – and we'd love to hear about your experiences along the way.

For agentic coding to pay off, you need the right environment around it, meaning: clear standards and guardrails, connected tooling, solid data foundations, and people who know how to direct and verify what the agent produces. That is exactly the kind of groundwork we help data and engineering teams put in place. If you would like a hand introducing agentic coding, get in touch.

Here's an overview of the services we can help with:

• AI literacy training
• Data science & AI consulting
• Data engineering & architecture