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.
Spec-driven harnesses do something quietly radical: they make the code of the system running your development lifecycle explicit. The instructions, the standards, the definition of done stop being culture and habit and become files you can read, review, and change. For most organizations it is the first time their own way of working is written down.
Which makes it a product, not setup. 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.
You need the first principles more than before. Flow, WIP limits, small batches, and fast feedback are exactly what a system needs when starting work becomes free and finishing does not. What you need much less of is the coordination apparatus, because Scrum teams are not becoming obsolete so much as smaller, from cross-functional squads to one to three people who can cover a whole slice.
That descaling is the interesting part. A large amount of organizational machinery existed only to coordinate between people who now sit inside the same small team. So customize the framework down to what is still doing real work rather than abandoning or preserving it wholesale, and notice the deeper possibility: a lot of what agile always asked for, small batches, real feedback, working software over documents, may finally be affordable now.
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.
Why I pivoted from Scaling with Agility to Scaling AI from Activity to Impact. Agility is the "Powered by Intel" inside the AI-Native organization, and the lessons from scaling it are what turn AI ambition into impact.
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.
Does your board stop at deliverable and output, or does it go towards outcome: the changed behavior for somebody? Most boards stop at deployed, and that is what teaches people deployment is success.
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.
The real magic of spec-driven-development frameworks is how they make the code of the system running the agentic/human development lifecycle explicit, and opens the door to evolving this code to coach agents and humans towards more effective choices much more effectively than ever before.
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.
The flattening pitch assumes your teams can deliver an outcome alone. Most cannot. Agents make them faster, not independent.
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.
Don't ask whether you still need Sprint Planning. Ask whether you still have an alignment problem. Separating the mechanism from the capability is the whole game right now.
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.
You can 10x engineering and still not 10x the business. AI creates speed, not automatic value, and if engineering was not the constraint, that speed just moves the congestion somewhere else.
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.
When you are running specs through coding agents, the spec is the work in progress. WIP limits are the valve that keeps agentic throughput from piling up in front of the humans who still have to review it.
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.