Spec-Driven Development Is The New Programming Language

TL;DR

Spec-driven development looks like a step backward if you think of the spec as a document that sits between business people and developers. In that model, a detailed spec is requirements theater with more Markdown. It invites mini-waterfall behavior: write a lot, hand it off, let the builders build, and review the mess later. I think that is the wrong mental model for what is happening.

The better frame is that the spec is becoming a higher-level programming language. Humans will increasingly maintain intent, constraints, acceptance criteria, examples, context, and learning strategy at the spec layer, while AI agents do more of the lower-level coding work. That does not mean Scrum needs detailed specs in the Product Backlog, refinement, or Sprint Planning. It means the team aligns around goals and context there, then develops the spec during the Sprint as part of doing the work.

The question behind the process anxiety

A Scrum community thread recently raised a question I expect many teams are asking in different words: if AI is doing more task decomposition, and specs are detailed enough that they almost describe the code AI will generate, what happens to Product Backlog Refinement, Sprint Planning, and Scrum itself?

The concern is fair. Some teams are seeing refinement become disengaging because one person, sometimes with AI, arrives with a detailed breakdown before the conversation starts. Some teams are spending less time estimating because the work is sliced smaller or because the implementation effort feels less meaningful when AI is in the loop. Some people look at the flow and see docs first, execution second, review later, and they reasonably ask whether we have recreated waterfall with better tools.

I look at the whole spec-driven thing differently.

In my view, the intent of spec-driven development is not to create a heavier ticket before coding starts. It is that the spec becomes the code layer humans maintain most of the time. Think about the historical stack: machine code, assembly, C, higher-level languages, low-code, no-code. We moved upward because each new layer let humans express intent at a more useful level of abstraction, while still allowing lower-level work when the situation demanded it. We did not stop caring about lower layers. We just stopped asking most people to live there every day.

AI-assisted software development is pushing us through another layer shift. Much of our “code” will be managed through spec-driven interactions. There will still be lower-level coding. There will still be situations where someone has to inspect the generated code, tune the architecture, write a tricky algorithm, debug a production issue, or work close to the metal. There are still people writing C in the Linux kernel even though most business software moved far above that layer. But for a growing share of product work, the human programming surface is becoming the spec.

Coding the spec is not a burden

This is why I do not buy the complaint that writing the spec is just a new administrative burden. It can become one, absolutely. Bad process can turn anything into burden. But the useful version of spec-driven development is not “write more documentation before the real work.” The useful version is “program the system at the level where human judgment matters most.”

The spec is where we express the goal, the intent, the context, the constraints, the tradeoffs, the acceptance criteria, the examples, the risks, the assumptions, and the signals we will look for. That is not paperwork. That is the work. It is the programming language of human intent.

If you do not care about that layer, you may still have a perfectly good career for a while. There will be plenty of lower-level code to maintain, plenty of complex systems that need expert judgment, and plenty of environments where AI agents cannot safely own the loop. But if you are in a space where AI coding agents can translate clear intent into working software, then refusing to learn the new programming language is a career bet. You may be choosing to become the next generation of COBOL programmer. That can be a fine niche if there is a moat. It is a dangerous default.

The important shift is that the spec is not a proxy for requirements being fed to passive builders. It is the place where builders, product people, designers, domain experts, and agents collaborate to shape intent into a working outcome. That is a very different thing from a business analyst writing a detailed requirements document and throwing it over the wall.

Do not stuff this into the Product Backlog

The next mistake is trying to force this new spec layer into classic Scrum artifacts at the wrong altitude.

A Product Backlog does not need to contain detailed specs. A Product Backlog item does not need to include the full spec an AI agent will use to build. During refinement, and even during Sprint Planning, the useful level is usually the same level good teams already aimed for before AI: what is the goal or intent, what are the rough acceptance criteria, what context matters, what leading indicators would tell us this is worth doing, and what is the next sensible slice?

That is enough to have a refinement conversation. It is enough to prioritize. It is enough to decide what is worth pulling into a Sprint. It is enough to align around a Sprint Goal. It is not enough to drive an AI coding agent all the way through a meaningful implementation, and that is fine. It was never supposed to be.

The detailed spec belongs closer to execution. Once the Sprint starts, a human team member, or a pair, or a small swarm, pulls a backlog item from the Sprint Backlog and develops the spec in collaboration with AI. That is when the real spec-driven cycle goes into full gear. It may involve one person and one agent. It may involve several specialized agents. It may involve two people pairing with an agent. It may involve the whole team swarming on a bigger item because the risk or importance justifies it.

Scrum does not need to prescribe that. It never needed to prescribe detailed tasking either.

One of the healthiest things AI can do for Scrum teams is force them to revisit what refinement is actually for. Refinement is not a ceremony where the team must collectively decompose everything into tasks. It is not where the team has to manufacture detailed estimates. It is not where the entire implementation approach has to be agreed in advance.

Useful refinement creates shared understanding of the business problem, the product intent, the shape of the option, and the reasons this might or might not matter. It should help the Product Owner and Developers inspect whether the item is worth keeping, whether it is small enough to pull soon, whether the acceptance criteria are directionally clear, and whether there is enough context for a team to make progress.

If a team is using refinement to review a giant AI-generated task breakdown, I would not be surprised if engagement drops. Most of that detail can be figured out at code-writing time. Worse, that detail can crowd out the conversation humans should be having: what are we trying to achieve, what might we be wrong about, what are we choosing not to do, and what would make this a bad bet?

The Product Backlog should carry intent and context. The spec-driven loop should elaborate the work at the moment the work is being developed. These are different altitudes. Mixing them creates process mud.

Sprint Planning should not become an architecture review for every spec

The same applies to Sprint Planning. The goal of Sprint Planning is not to finish all thinking before the Sprint starts. It is to decide why this Sprint is valuable, what can be done, and how the selected work will initially be approached. The “how” can be quite lightweight, especially when the team has the ability to elaborate specs rapidly during execution.

That does not mean planning becomes irrelevant. If anything, AI makes focus more important. AI does not unlock the dream of doing everything at once. It makes it easier to start too many things, create too many branches of work, generate too much code, and flood the review and adoption parts of the system. A Sprint can still be very useful as a focus mechanism: this is what we are aiming at now, and that means we are not doing all the other plausible things yet.

The Sprint Backlog can contain a couple of bigger outcome-oriented items, several smaller ones, or one large bet the team intentionally swarms around. The team can decide in Sprint Planning how much collaboration each one deserves. Maybe one person takes the lead and pulls in others at decision points. Maybe two people pair with an agent because the architecture is sensitive. Maybe the team divides and conquers after agreeing on boundaries. Maybe they swarm because the risk is high or the learning matters.

That is team design work. Scrum gives the container. It does not need to micromanage the spec cycle inside the container.

The Daily Scrum becomes a steering point again

When a human-agent pair is moving quickly, important learning can show up mid-Sprint. The agent discovers the existing architecture does not support the intended direction. The spec exposes a hidden assumption about the workflow. A prototype makes the original idea look less valuable than a nearby option. A technical constraint suggests a different slice. Customer feedback changes the bet.

Waiting a week or two to discuss that can be silly. This is where the Daily Scrum can become useful again, not as a status meeting, but as a steering point. What did we learn? Is our plan for the Sprint Goal still coherent? Do we need a product decision, architecture conversation, customer touchpoint, or team swarm? Is the work moving toward the intent, or are we just generating output?

AI makes this more important because things move faster. A bad direction can produce a lot of plausible code quickly. A good learning loop can redirect quickly too. The Daily Scrum is one of the places where the team can keep the learning loop visible without turning every spec into a whole-team meeting.

The Sprint Review matters more, not less

At the end of the Sprint, the team needs to step back. That is not less important because AI helped ship more. It is more important because AI can create acceleration whiplash: the inner loop of building accelerates faster than the outer loop of deciding, adopting, measuring, and learning.

The Sprint Review is where the team and stakeholders look at what was shipped, what was learned, and what might make sense next. Did anyone use it? Did it change behavior? Did it move the leading indicator we cared about? Did it reduce the constraint we were aiming at? Are we closer to the Product Goal, or did we just produce impressive activity?

This is where the “spec is the new programming language” idea has to stay connected to value. A beautiful spec that generates working software is still not the finish line. The finish line is learning whether the product, workflow, customer, or business is better off. Scrum’s review cadence is a useful forcing function for that conversation, especially when AI-assisted teams can generate more work than the organization can absorb.

The Retrospective becomes about the human-agent operating model

The Retrospective also remains very relevant, but the questions change. What did we learn about our collaboration model? Where did AI help? Where did it create noise? Where did we over-specify? Where did we under-specify? Which agent instructions worked? Which review patterns caught problems early? Where did handoffs slow us down? Where did we create too much work in process? What should we retire, try, or tighten?

The bottleneck may not be coding anymore. It might be review, product judgment, customer access, data quality, adoption, release safety, or decision-making. The Retrospective is where the team can inspect the whole operating system instead of only asking whether the Sprint felt good.

If the team discovers that specs are becoming too detailed too early, change that. If one person plus AI is doing all breakdown and the rest of the team is losing shared understanding, change that. If every backlog item is turning into a giant spec, change that. If AI is helping the team move faster but the organization cannot use what ships, change that.

That is agile. Not preserving a ceremony exactly as it was practiced in 2016.

Product ownership is still about strategy, not feeding specs

It still makes sense to have someone focused on overall product direction: where we play, how we win, what outcomes matter, what tradeoffs we are making, and where the next best bet might be. That person was never supposed to be a proxy, a firewall, or a requirements vending machine.

The builders on the team should go as close to customers and users as possible. They should understand the business context, the product strategy, the constraints, and the outcome they are trying to create. They are not fed requirements. They are not fed specs. They are aligned to an intent and surrounded with context. So are their agents.

That distinction matters. If Product Ownership becomes “write detailed specs so AI can build,” we have recreated the old requirements factory at a higher token count. If Product Ownership stays focused on strategy, context, outcomes, ordering, and learning, then the team can use spec-driven development as a powerful execution and discovery layer without losing agency.

Scrum does not need to become AIScrum

I do not think teams need a branded “AIScrum” or “AIban” to move forward. Start by stripping Scrum back to its kernel. Empiricism. Focus. Transparency. Inspection. Adaptation. Commitment to goals. A self-managing team working with a Product Owner toward a Product Goal. A Sprint as a container for focus and learning. A Review to inspect product progress with stakeholders. A Retrospective to improve the system.

Then look at the complementary practices around that kernel. Estimation? Optional. Story points? Optional. User stories? Optional. Detailed task breakdown in Sprint Planning? Optional. Whole-team refinement of implementation detail? Optional. If those practices help, keep them. If AI-assisted spec development has made them low-value or actively harmful, retire or reinvent them.

Kanban can help here too. Not as Scrum’s enemy, but as a way to see the flow. Visualize where specs are emerging, where agent work is in progress, where review is backing up, where adoption is stalled, and where validation is missing. Limit work in process. Manage flow. Make blocked learning visible. Scrum and Kanban have always been more compatible than the framework debates made them sound.

AI is doing for Scrum what Kanban did for many Scrum practitioners a decade ago. It is helping people see the essence by making the accumulated baggage more obvious.

The opportunity is unreasonable agility

The best version of this future is not one where AI writes all the code and humans review a pile of generated output with a grim sense of duty. It is also not one where humans write giant specs and agents mechanically execute them.

The best version is a team with agency. Humans and agents aligned around outcomes. Backlogs that carry intent instead of fake certainty. Specs that are developed at the right altitude, at the right time, by the people and agents closest to the work. Reviews that inspect real value. Retrospectives that improve the human-agent operating model. Product leadership that provides strategic context instead of feeding requirements.

That team can move very fast without pretending uncertainty went away. It can use specs as a programming language for intent, not as a wall between thinking and doing. It can let AI accelerate the lower layers while humans get better at the higher ones: choosing, framing, steering, sensing, learning.

That is not abandoning agility. That is what agility looks like when the programming surface moves up a layer.

The spec is not the paperwork before the work. Increasingly, the spec is the work humans maintain so people and agents can build, learn, and steer together.