How Do You Know Agentic Development Is Making Delivery Better?

It’s one thing to show that AI agents can write code, run tests and open pull requests. It’s another to show that they’re making software delivery better.

That’s the question we’ve been asking at Studio Graphene as we’ve developed and tested our agentic development workflow. Our early findings are encouraging, but the case isn't proven, and it won't be proven by counting how much code agents produce. This article looks at what we've seen so far, what we haven't established and what we'd need to measure next.

The First Signal: Hands-On Developer Time

The clearest early result is a reduction in the hands-on developer time needed for a ticket. We talked about this in From AI-Assisted Coding to Agentic Software Development - our internal testing has shown that development tickets can require around three to five times less hands-on developer time. It's an early internal measurement, so it's worth being clear about what it covers.

Even with AI-assisted coding tools, a relatively small ticket could take 10 to 15 prompts across multiple stages, with the developer coordinating each one. In our agentic workflow, agents move the work between stages and respond to automated feedback without needing a new instruction at every step. That reduces the time an engineer spends actively managing a ticket.

It doesn't follow that a ticket, project or release is delivered three to five times faster. Waiting time, dependencies, approvals and everything else in delivery still count. Hands-on time measures effort, not delivery speed, and certainly not cost.

Coordinating More Work at Once

The second benefit is coordination. In a recorded run, one command started work on two real backlog tickets: a relatively small frontend change and a larger change spanning frontend and backend systems.

The workflow gathered context, prepared implementation plans and presented them for human approval. Once approved, agents carried out the work, ran automated checks and opened two draft pull requests.

Two pull requests aren't the point. What matters is that separate pieces of work moved through a defined process without a developer directing every activity. That could let engineers oversee more work without becoming the bottleneck between stages. Whether it improves overall team throughput is something we'll need to track over time.

Faster Doesn't Mean Lower Standards

Any efficiency gain has to be weighed against quality. Less developer involvement isn't useful if it creates more defects, rework or maintenance problems. That's why the workflow includes automated checks, multiple review stages and human approval before implementation and before merge, as discussed in Can AI Agents Really Review Each Other's Work?.

Those checks are designed to make sure the same standards are applied throughout the process. They don't yet show that defect rates have fallen. To establish that, we'd need to compare quality outcomes over time, and we don't yet have evidence from this workflow demonstrating an improvement.

Does the Saving Reach the Client?

Not automatically as less hands-on developer time doesn't necessarily mean a shorter project or a lower cost. In If AI Makes Software Cheaper to Build, Should Clients Pay Less?, we highlighted how efficiency gains translate into value for clients, whether through greater delivery capacity, improved responsiveness or more time spent on the work that matters. To understand that impact, we need to look at delivery as a whole, not just one efficiency figure.

What Should We Actually Be Measuring?

What matters is whether the whole delivery process is getting better. A workflow can cut manual effort and leave delivery times unchanged. Faster implementation can also be cancelled out by rework if requirements are unclear or checks aren't effective.

To understand the wider impact, teams need a combination of measures: how long work takes from ticket to delivery, how much engineering effort it needs, how often changes pass review and testing, and how much rework follows. They also need to account for complexity, since a small frontend change and a substantial full-stack change shouldn't be treated as equivalent just because both produce a pull request.

This is central to our data-driven delivery approach, where we use delivery data and our platform, Pulse, to understand performance, identify bottlenecks and see whether changes to how we work are making a difference.

Better Delivery Is the Goal

So far, our experience suggests agentic workflows can reduce hands-on developer effort, coordinate multiple pieces of work and apply structured checks before work reaches a human reviewer. Those are meaningful early results, but they don't prove that every project will be delivered faster, at lower cost or with fewer defects. We'll need to keep measuring performance across different types of work to understand the wider impact.

What makes agentic development interesting isn't simply the prospect of producing more code. It's the opportunity to remove unnecessary coordination, apply engineering standards more consistently and give developers more time for the decisions that shape delivery outcomes.

The next step is to measure whether those changes translate into better software delivery, not just faster software development.