If AI cut your coding time from 3 days to 30 minutes but your cycle time from prompt to deploy is still 2 weeks, you've optimised the wrong thing.
The "traditional" bottleneck in software has been writing code. We built processes to ensure we were always producing the highest-priority code with this limited resource. But that bottleneck has now opened — AI can produce code at a massive scale.
Consider a radical idea: backlogs are obsolete in the age of AI. Sprints too. The biggest objection I hear is “where is the filter? what if we produce bad features or garbage?” Some counterpoints:
-
A significant portion of a backlog is bugs, quality of life fixes, documentation, and so forth. There is little reason to hold these back besides development capacity. The time spent juggling these tickets[1] might now be more than just fixing them.
-
Many features can be deployed safely behind feature flags or similar mechanisms. Getting them live is the best way to iterate and prove them out.
-
While this seems all about delivering new features, it can equally apply to removing features. Tidying up old features and cruft is a hard ask in a busy backlog.
-
For the remainder, you now have more time for design and pre-work — precisely because you’re no longer burning capacity on the points above. Give yourself permission to spend time upstream of the backlog.
I'm not arguing there should be no filter at all. But anyone who has inherited a crufty forever-growing backlog knows there must be a better way. We can revive the spirit of Kanban and create a system with real pull.
The metric that matters now isn't velocity, it's cycle time. How long from first prompt to something live in production? The burndown should be getting prompts deployed, not tickets managed.