Insights Topic
Generating work is nearly free now. Deciding, reviewing, and finishing are not. The lifecycle has to be rebuilt around what is actually scarce.
This is the delivery side of my AI work: what has to change in how product and engineering teams actually operate once an agent can produce a week of code in an afternoon. If your question is which AI bets are worth funding in the first place, that is the companion topic below.
Start here · Cornerstone read
Agents write code faster than ever, and the bottleneck moved to human decision latency and review capacity. The operating system that closes that gap.
Read the full articleCoding was the constraint for a long time, so we built the whole lifecycle around protecting it. Agents removed that constraint and it moved somewhere else: deciding what is worth building, reviewing what came back, integrating it, and getting somebody to actually use it. None of those got faster on their own.
In practice that looks like a team generating more than it can finish. Pull requests pile up, review turns into rubber-stamping or into a wall, and unreleased work quietly accumulates. Faster generation into an unchanged downstream is just a bigger queue.
When code is nearly free, a vague spec does not slow you down. It gets built instantly and wrong. So the thinking moves upstream. Writing the spec first is not a return to requirements documents; it is choosing a higher-level language to work in, one a human can review before a thousand lines exist.
The difference between spec-driven development and waterfall with more tokens is whether the spec generates learning. Write it once, sign it, hand it down, and you have rebuilt the old failure at speed. Write it to make a bet reviewable and let what comes back change it, and you have moved judgment to where it is cheap.
The system prompts, knowledge bases, tool configurations, and agent instructions your teams depend on are not setup. They are a product: discovered, versioned, improved, and occasionally wrong in ways that cost you a week. Treated as one-time setup, they rot quietly.
A Lean sensei could tell whether an organization was still improving by looking at how recently the standard work had been updated. Your agent config is that document, so check the date on it. And when you tell an agent what done means, notice whether you described an output or an outcome, because it will run straight at whatever you said.
More than before, and for a specific reason: agents made starting nearly free while finishing stayed expensive. That is the exact condition WIP limits exist for. Work item age, cycle time, and throughput are still the honest signals, and they get more useful, not less, as the arrival rate climbs.
The other thing worth fixing is where the board ends. Most boards stop at deployed, which was defensible when deploying was the hard part. It is not anymore. If the board ends before somebody’s behavior changed, it is measuring the easy half.
Scrum teams are not becoming obsolete. They are getting smaller, from cross-functional squads to one to three people who can cover a whole slice. That descaling is the interesting part, because a lot of organizational machinery existed only to coordinate between people who now sit inside the same small team.
Which means a good deal of your scaling apparatus is genuinely optional now, and your first principles are not. Flow, WIP, small batches, and real feedback still decide the outcome. The ceremony built to manage dependencies that no longer exist is what you get to put down.
It is a product and engineering lifecycle built for AI-assisted work, where specification, review, validation, and deployment keep pace with much faster code generation. The point is to manage the whole flow from intent to outcome rather than optimizing the coding step that is no longer the constraint.
Only if you use it that way. Waterfall writes the spec once, signs it, and hands it down. Spec-driven development writes the spec to make a bet reviewable before code exists, and expects what comes back to change it. The test is whether the spec is generating learning or suppressing it.
AI raised the arrival rate of pull requests without raising review capacity, and AI-generated diffs are larger and harder to reason about. The answer is not telling reviewers to go faster. It is making changes smaller and more reviewable, and moving judgment upstream into the spec so review is not the first time a human sees the intent.
You need the first principles (flow, WIP limits, small batches, fast feedback) more than before. You need much less of the coordination apparatus, because smaller teams absorb dependencies that previously needed ceremony to manage. Customize the framework down to what is still doing work rather than abandoning or preserving it wholesale.
Insights Database
Browse the complete archive of articles and case studies related to agentic development lifecycle.
AI made starting work nearly free. It did not make finishing free: deciding what is worth doing, reviewing, shipping, and closing the loop still cost the same judgment they always did. So the bottleneck moved, and what you get is not more impact but a pile of half-finished threads. I built a personal kanban board for my own AI coding threads and the first thing it showed me was the size of my own pile.
A Lean sensei could tell an organization had stopped improving by looking at one document. In spec-driven development your harness is that document, and the measurement takes one git command.
AI agents make it remarkably easy to start and generate work. Here is how I would use WIP, work item age, cycle time, and throughput when code review and customer learning cannot keep up.
Spec-driven development gave you a fast software lifecycle. It stops at released. The product lifecycle does not, and the gap between the two is where AI adoption quietly dies.
Most of your scaling apparatus is now optional. Your first principles are not. A companion for leaders running SAFe while adopting AI-native, spec-driven development, and trying to tell the difference.
Is Scrum still relevant when agents write the code? Yes, and more than before, provided you are willing to customize it. A companion to the Scrum Guide walking the accountabilities, events, artifacts, and values for a team running an AI-native, spec-driven lifecycle.
A companion to the Kanban Guide for Scrum Teams for AI-native product teams. What changes in your Definition of Workflow, WIP limits, flow metrics, and Scrum events once agents do the building, and what happens to scaling when the old dependencies start dissolving.
Starting numbers for active work and queues, covering solo and multiplayer spec-driven development, pod topology, flow buffers, and replenishment cadence.
AI agents write code faster than ever, but the bottleneck moved to human decision latency and review capacity. Here is the operating model that closes it: roles, rituals, and metrics.
AI speeds up delivery and thins out team-level dependencies. Scaling framework mechanics become optional; flow and WIP first principles matter more.
When AI coding raises the arrival rate of pull requests, telling reviewers to work faster is the wrong move. Fix reviewability and end-to-end flow instead.
AI isn't killing Scrum. It's shrinking teams from cross-functional squads to 1-3 people, and that descaling collapses a lot of org complexity with it.
Why the rise of Forward Deployed Engineering is the next agility problem, and how to scale "unreasonable agility" without it eating itself.
Spec-driven development looks like a step backward if you read it as requirements theater. The better frame: the spec is a higher-level language for intent.
Spec-driven development points an agent at a deliverable. Goal-based loops let you point it at a condition instead: the question is whether the condition you picked is an outcome or just green tests.
AI coding can make engineering dramatically faster. The business does not follow automatically: the constraint moves to deciding what is worth building.
Spec-driven development can be a smarter way to steer AI coding agents, or waterfall with more tokens. The difference is whether the spec creates learning.
AI context (system prompts, knowledge bases, tool configs) is a product you keep discovering and improving. Product thinking applied to AI enablement.
AI tools promise to speed up product discovery, but do they? A close look at where AI actually helps, and where the bottleneck is still human judgment.
Practical patterns for using AI across the product development flywheel: from discovery and validation to faster build cycles and better feedback loops.