Agentic coding is changing something more fundamental than developer productivity. It is changing the unit by which we should measure software progress.

Waterfall gave us milestones. Agile shortened the feedback loop and gave us sprints, story points and burn up/down charts. Kanban shifted attention towards flow. None of these ideas is suddenly wrong. But when coding agents can implement multiple tasks in parallel, sometimes while the human team is doing something else, task-level effort becomes an increasingly weak proxy for progress. Human review, specification and requirements development, QA and validation becoming the constraints rather than code production.

I think the next step is to measure verified capability flow: requirement bundles and functional capabilities moving from agreed intent, through implementation and validation, into production and measurable business outcomes - but at what level?

What is it?

I have been thinking about a fairly basic project-management question: What does “progress” mean when writing the code is no longer the slow part?

We moved from large project phases and milestone gates to sprints, story points, burn up/down charts and regular demos - of some combination or waterfall and agile. Agile pushed much harder towards short feedback loops and working software. The Agile Manifesto says that working software is the primary measure of progress. Many organisations will still use those techniques as proxies for delivery - points completed, backlog size remaining, is the burn-down line where we expected it to be? All of this made sense, up to a point, when implementation tasks consumed meaningful chunks of human time.

Agentic coding (and spec-driven development approaches) changes things. Spec-driven development puts a structured, reviewable specification ahead of implementation. GitHub’s Spec Kit formalises a flow of Spec → Plan → Tasks → Implement. The important change is that the specification becomes durable context from which coding agents can plan and execute work, rather than documentation that sits beside the “real” development. A coding assistant helps a developer write or understand code (e.g. I use Claude as a Solution Architect advisor to work alongside Claude Code). A coding agent can take a goal, inspect a repository, modify files, use development tools, run tests, iterate and prepare a pull request for review.

Initially I thought Kanban is useful here because it measures flow - work in progress, throughput, work-item age and cycle time. The units of value actually are, which turns out to be rather important in an agentic environment and what my thinking started to revolve around.

If our work item remains at the individual requirements level (e.g. user stories) or levels of granularity like “write this API method” or “change this field on the form”, even Kanban may be measuring at the wrong level. We may have to roll the measurement up the Functional Area (a group of requirements) or a System level (a group of functional areas that deliver a portion of an application).

What does it mean from a business perspective?

Essentially, the unit of progress needs to move up the abstraction stack. If an agent can complete several implementation tasks while a product owner is in a meeting, counting tasks or points tells us increasingly little about whether the product is closer to the outcome we funded. The scarce resources start to become clear intent, decision-making, review, validation and integration, rather than production of code (obviously the question of code quality remains - but that was there with human developers).

I think the better unit, as I mentioned above is a requirement bundle (functional area) or system (a group of functional areas), something a business stakeholder can recognise and an automated system can verify. “Customer onboarding works end to end” is more meaningful than twelve completed stories. Underneath that capability might sit identity verification, authentication, validation, notifications, audit logging and several agent-generated pull requests.

At leadership level, progress should move when the capability meets agreed acceptance criteria, quality controls and operational evidence. Kanban still helps, but the work item becomes the capability increment, rather than every coding task. Flow measures then sit beside delivery-quality and outcome measures.

Agile itself seemed to already moving towards this idea and with the coding bottleneck removed, we can.

What do I do with it?

Start by changing the measurement model before changing the methodology.

• Define three levels of work. Keep implementation tasks for agents and engineers, requirement bundles (functional areas) for delivery management, and functional areas or system capabilities for executive reporting. Maintain traceability between them, but do not aggregate story points upwards and call that progress.
• Make “done” executable wherever possible. A capability should have acceptance tests, security and policy checks, observability and an agreed production signal - i.e. done. The agent should be able to see the specification, tests, architecture rules and relevant telemetry.
• Use flow, but measure the right thing flowing. Track requirement-bundle (functional area or system capabilities throughput, lead time, cycle time and WIP - more useful question than “how many points can we deliver?”: for example, how predictably does a defined unit of value move from commitment to acceptance?
• Add quality and stability beside speed. That becomes more important when AI can increase the amount of change being delivered. A faster code generator attached to a slow or unreliable review and deployment process does not create faster business value.
• Run the old and new views side by side for a few delivery cycles. Velocity may still help a team locally, while capability completion, lead time, WIP, change failure, rework and user impact are likely to be more useful to decision-makers.
• Keep human control where consequence is high. Agent permissions, protected environments, secret handling, review policies, auditability and mandatory CI gates become more important as autonomy increases. Continuous delivery foundations, strong platforms, testing and observability as increasingly important when AI accelerates development activity.

The Agile Manifesto was arguably closer to the answer all along: working software is the measure of progress.

I’d argue that the Agile manifesto is more important now that ever.

When implementation becomes cheap and parallel, leaders should stop asking:

• “How much work have we done?”

and start asking:

• “What verified capability can the organisation use now, how quickly did it flow, and did it create the outcome we expected?”

We spent decades improving how we estimate the work required to create software and measuring it. Agentic coding is pushing us towards measuring the evidence that the required system capability now exists. Those are not quite the same thing.