Estimating the Productivity of an Autonomous Agentic Data Platform

Data work costs a team twice: the time people wait for data, and the time engineers spend producing it. Agents shrink the first far more than the second, so we estimate time-to-data and hands-on effort separately.

The short version: on our base-case assumptions, routine data work is ready about 8.95x sooner (plausible range 4.8x to 10.0x) and takes about 4.11x less hands-on engineer effort (range 2.1x to 5.7x). We round down to one decimal everywhere, which gives 8.9x time-to-data and 4.1x developer productivity, the figures on our homepage.

Read this first. This is a model, not a measurement. The "with agents" figures are per-agent design targets from our product spec, the "today" figures are our estimates of typical practice at a mid-size data team, and we sell the product, so weigh it accordingly. Pilots measure the real numbers, and we will publish them even if they are lower.

Choosing the metrics

Cognition's write-up on estimating the productivity of an autonomous AI software engineer measures one thing: the engineering hours a person would have needed to produce what the agent produced. That is the right question for a coding agent, whose work is mostly hands-on. Data work has a second cost that a coding-agent metric misses: waiting. An access request can take three days while someone works on it for thirty minutes. So we estimate two quantities, and keep them apart.

• •Estimate A, time-to-data. We define time-to-data as the elapsed time from the moment someone asks for a piece of data work to the moment it is done and usable. It is what the person waiting experiences, queue time included. It is close in spirit to change lead time in the DORA metrics, which measures how long a change takes to go from commit to production. Estimate A is the ratio of a year of time-to-data today to the same year with agents. It backs the first homepage line.
• •Estimate B, hands-on effort. The engineer hours actually spent on the same jobs: understanding the request, building, testing, reviewing, and answering follow-ups. This is the developer experience (DevEx) side, and it is the metric closest to Cognition's. Estimate B is the ratio of hands-on hours today to hands-on hours with agents, for the same output. It backs the second homepage line.

We chose hours over dollars for the same reason Cognition did: converting hours to business value needs assumptions we cannot check. We also did not use activity counts such as queries run or tables created, because they do not track effort.

The ten jobs

The jobs are the ten rows of the homepage chart, with the same names and the same before and after values. Where the chart shows a range for the agent, the model uses the value the chart plots, which sits inside that range.

The multiples run from about 6x to about 1,200x. That spread is the main fact about this model. Agents move little on work that is mostly coordination and sign-off, like a legacy platform migration, and a great deal on work that is mostly waiting in a queue, like an access request or an ad-hoc question. Averaging ten multiples that differ by a factor of 200 produces a number that describes none of them, so we weight by a year of work instead.

A year of work

A team does not do each job once a year. The frequencies below are our assumption for a mid-size data team of about a dozen engineers, which is the median team size in a 2021 Wakefield Research survey for Fivetran. That survey is five years old, so treat it as a rough anchor. The hours columns show where each estimate's weight comes from.

Access provisioning dominates waiting time: it is 43% of all time-to-data today, because 200 requests at three days each add up to more than any build. Estimate A leans on that one job, and we test what happens without it below. Hands-on effort is spread more evenly; the migration and new pipelines are the two largest lines, at about 22% each.

Some of the frequencies are low on purpose. Monte Carlo's 2023 survey, now three years old and run by Wakefield Research with 200 data professionals, reported 67 data incidents a month and an average of 15 hours to resolve each one (TDWI coverage). We assume 50 incidents a year at 6 hours, well below that, because a vendor-commissioned survey of incidents is likely to over-sample teams that have many.

Estimate A: time-to-data

Multiplying each job's turnaround by its yearly frequency gives about 38,972 hours of time-to-data a year today. With every agent hitting its target, the same year takes about 586 hours. The ratio is 66.5x, and it is not a number we would publish, because it assumes two things that are false: that nobody checks the agents' work, and that agents never fail.

Haircut 1: a human review on every job

Every agent change waits 15 minutes for a named person to approve it before it lands. We charge this on every job, including ones the agent finishes in 30 seconds, where the review takes 30 times longer than the work. Fifteen minutes is short for a migration and long for a dataset lookup; we use one number because it is easy to check and easy to replace. Review alone brings the ratio to 37.3x.

Haircut 2: falling back to manual

Some runs fail, or the reviewer rejects the result, and the job goes back to being done by hand at today's turnaround. A failed run is charged three times: the agent's attempt, the review that caught it, and the full manual job. The first draft of this model used one fallback rate of 5% for every job. We replaced that with two rates, because a single rate is not credible across this range of work:

• •5% for operational jobs (access, schema changes, ad-hoc questions, incidents, dataset lookups). These are short, bounded tasks with a clear check at the end.
• •15% for build jobs (migration, streaming, pipelines, model deployment, audit evidence). These run for hours or weeks over many steps, and every step is a chance to fail. We have no measured success rate for our agents yet, so 15% is a judgment, not data.

With both haircuts, a year of time-to-data drops from about 38,972 hours to about 4,353, which is 8.95x. Under the draft's flat 5% rate the same model gives 13.0x; the build-job rate is the change that matters most. Review, blast-radius checks and rollback are designed to keep the fallback rate low; that is design intent, and pilots will measure whether it holds.

Estimate B: hands-on effort

Estimate B asks Cognition's question of data work: for the same output, how many engineer hours does each job take today, and how many does it take with agents? "With agents" still costs hours. Someone writes the request, reviews and approves the change, checks the result, and redoes the job by hand when the agent fails.

For today's hands-on hours there is less published data than we would like. The strongest anchors we found are shares of time, not hours per job. In dbt Labs' 2024 State of Analytics Engineering survey of 456 practitioners, 55% said maintaining or organizing datasets is one of the top ways they spend their time. In the Fivetran survey above, data leaders said their engineers spend 44% of their time building and rebuilding pipelines. Both tell us routine data work is a large share of the week. Neither gives us per-job hours, so the per-job figures below are our estimates.

Most jobs take 8x to 12x less hands-on effort; migration and access provisioning gain least, because people keep the planning and the approvals. A few of these deserve a reason. The migration assumes two engineers at about three-quarters time for nine months today, and a quarter of that effort with agents: planning, reviewing translated code, validating data parity and running the cutover stay with people. Access provisioning is half an hour of real work today (triage, approval, the grant, a check) against about ten minutes with agents, because a person still approves every grant; that is why its effort multiple is the lowest on the list even though its turnaround multiple is the highest. Ad-hoc questions and dataset lookups assume a few minutes of a person checking the answer each time.

Weighted by the same yearly mix, hands-on effort goes from 3,700 hours today to 506 with agents, which is 7.3x. Applying the same fallback rates, where a failure wastes the agent-side effort and then costs the full manual effort, gives 901 hours and 4.11x. Under the draft's flat 5% rate it would be 5.4x.

Estimate B is lower than Estimate A, which is what we expected. Agents remove waiting almost completely, but they only remove part of the work, because review and approval stay with people by design.

On every job the green mark sits well to the right of the diamond. The gap is mostly queue time, which agents remove and engineers never spent hands-on.

How sensitive the numbers are

Very. The grids below vary the two inputs we trust least. For Estimate A they are review time and fallback rate. For Estimate B they are the agent-side effort and the fallback rate.

Leaving out the no-fallback column, which no one should believe, Estimate A ranges from 4.8x to 10.0x and Estimate B from 2.1x to 5.7x. The fallback rate moves both numbers more than anything else, because one failed build sends the job back to weeks.

The yearly mix matters too. The table below changes one frequency at a time.

Access provisioning carries Estimate A: removing it drops A from 8.9x to 6.4x. A team with self-serve access already in place should use that row, not the headline. Estimate B moves much less across the same changes, which is one reason we trust it more.

What this means for a team

The 4.1x applies to the ten routine jobs, not to everything a data engineer does. If those jobs are half of a team's hands-on time, a 4.1x gain on them frees about 38% of the week, which is about 1.6x for the team as a whole.

A concrete case: on the base mix for a team of about 12, the ten jobs take about 3,700 hands-on hours a year today and about 901 with agents. That frees about 2,800 hours a year, roughly 54 hours a week across the team, or about 4.5 hours per engineer. That is time the team gets back for the work only it can do.

Expect less than the headline numbers if your team already has mature self-serve access (use the 6.4x row above), sees few incidents and ad-hoc questions, or is spending the year mostly on a migration, the job agents speed up least.

Comparison to prior work

We know of no published estimate of agent productivity for data engineering specifically, so the nearest comparisons are from software engineering. They differ from ours in one important way: they measure real sessions, and we model targets. The work differs too: coding studies measure hands-on time, while much of a data request's elapsed time is queue time and coordination between teams, so they compare to our Estimate B, not Estimate A.

• •Cognition (2026) estimated the human-equivalent hours of 258 Devin sessions against interviews and surveys of the users who ran them, and deliberately calibrated its estimator to undercount. Our Estimate B asks the same question, without sessions to measure. Source.
• •METR (February 2026) had a model estimate time saved from 5,305 Claude Code transcripts by seven of its staff, and found time-savings factors of about 1.5x to 13x, which the author calls a soft upper bound on real uplift. Our 4.1x effort figure sits inside that range. Source.
• •METR (July 2025) ran a randomized trial with 16 experienced open-source developers and found that early-2025 AI tools made them 19% slower, while the developers believed they were 20% faster. It is the clearest evidence that predicted speedups can have the wrong sign. METR notes the result is now out of date. Source.
• •Anthropic (November 2025) had Claude estimate task times across 100,000 conversations and found a median time saving of about 80% per task, while noting the estimate leaves out time spent checking and fixing the output, which the haircuts in our model try to include. Source.

Threats to validity

• •The agent times are targets. Every "with agents" value is a design goal from our spec, not an observation. Some will be missed in a given company's stack, and we have not yet measured how often.
• •The fallback rates are judgments. They move both numbers more than any other input, and we have no measured rate behind them.
• •The "today" values are typical, not yours. A team with mature self-serve tooling already answers some questions in minutes, and its multiples are lower.
• •The yearly mix is assumed. Estimate A in particular depends on how many access requests a team handles.
• •Effort on these jobs is not the whole week. The homepage line describes routine data work and should be read that way; the team-level effect is smaller, as shown above.
• •Hours are not value. Neither estimate says whether the time saved goes to higher-value work, and neither measures quality: an agent that ships a subtle error has saved hours that will be spent later.
• •Our sources have interests too. The Fivetran and Monte Carlo surveys were commissioned by vendors who sell into the problems they describe, as are we.

How we measure it in every pilot

This model is the starting point, not the result. The homepage chart that plots CURRENT against WITH AGENTS for these ten jobs is its input, and a pilot redraws it with a company's own measurements. Every Data Workers pilot measures these numbers for that company, on its own stack and its own mix of work.

• •Baseline first. Before the agents start, we record how long the same jobs took the team in the previous quarter: time-to-data from the ticket or request history, and hands-on hours from the people who did the work.
• •Every agent run is logged. For each job the agents take on, we record time-to-data, the hands-on minutes people spent writing the request and reviewing the result, whether the reviewer approved it, and whether the job fell back to manual.
• •Both multiples, side by side. At the end of the pilot the company gets its own time-to-data multiple and its own developer-productivity multiple, computed exactly as in this post, from its own runs.

As pilots accumulate, the measured numbers replace both estimates here, with the same tables and charts, including if they come in lower than the figures above.