5-Minute DevOps: Spec-Driven Development Isn’t New

…It’s BDD that someone just discovered… again.

When someone declares a core Agile principle “obsolete” because they’ve rediscovered something experienced teams have been doing for decades, while demonstrating that they never understood agile in the first place, it’s a good reminder of how few people study how to do the work better.

The latest example showed up in my LinkedIn feed recently

A core principle of Agile is soon to be obsolete: One of the holiest lines in the Agile Manifesto is “Working software over comprehensive documentation.” But in the era of Agentic Spec-Driven Development, this is flipping on its head.

This sounds futuristic until you realize we solved this problem twenty years ago. We call it Behavior-Driven Development. SDD is not a revolution. It’s not “flipping Agile on its head” because you have detailed specifications. It’s just BDD with branding.

First, let’s clarify some things.

“Working software over comprehensive documentation.”

This never meant “don’t document.”

What it meant was that we didn’t spend months creating a Business Requirements Document and a System Requirements Document for the “finished” project. We don’t create detailed architecture, process flow diagrams, data designs, and low-level technical specifications for everything before we finally begin coding.

It meant don’t pretend to know everything up front. Write enough to align people, then prove it works by actually building something and validating it with the end-user.

Behavior Driven Development

BDD is the practice of having a conversation about how a feature should work.

BDD is:

• Concrete examples
• Expressed in plain language
• Agreed upon by product, QA, and development
• And executable as tests

Feature: I want to be able to add items to a shopping cart so that I can purchase them

Scenario: Adding a new item to an empty cart
Given the cart is empty
When I add item 123 to the cart
Then the cart should contain item 123
And the quantity should be 1

Scenario: Increasing quantity for an item already in the cart
Given the cart contains item 123 with quantity 1
When I add same item again
Then the quantity should be 2

When we begin coding, we implement using TDD using the BDD output to define the tests.

import { Cart } from '../src/cart'; // adjust path as needed

describe('Shopping Cart', () => {
describe('Adding a new item to an empty cart', () => {
let cart;

beforeEach(() => {  
  cart = new Cart();  
});  

it('should contain item 123 after adding it to an empty cart', () => {  
  cart.addItem(123);  
  expect(cart.contains(123)).toBe(true);  
});  

it('should set quantity to 1 when the item is added for the first time', () => {  
  cart.addItem(123);  
  expect(cart.getQuantity(123)).toBe(1);  
});  

});

describe('Increasing quantity for an item already in the cart', () => {
let cart;

beforeEach(() => {  
  cart = new Cart();  
  cart.addItem(123); // quantity = 1  
});  

it('should increase the quantity to 2 when the same item is added again', () => {  
  cart.addItem(123); // quantity becomes 2  
  expect(cart.getQuantity(123)).toBe(2);  
});  

});
});

Voilà, “spec-driven development.” This is a fundamental quality process for agile development, not a new invention for agentic-assisted development.

Disposable Code

Another hot take:

In the era of agents, the Spec becomes the asset. The code becomes disposable.

Reality check: that’s always been true.

If I have good acceptance tests, I can rewrite your entire system in another language, architecture, or stack. No drama.

If I only have code and no tests, I’ve inherited a dangerous artifact I can’t change safely.

Tests describe behavior. Behavior drives code. Code is the implementation detail.

This isn’t AI-era thinking. This is modern software engineering 101.

Teams that learned this years ago are not shocked by any of this.

“We’ll regenerate the whole codebase every time. No more refactoring!”

That’s not how agent-assisted development works. We add, modify, or remove behaviors as we deliver and learn. AI makes it much faster and cheaper to mutate the code to meet those behavior changes. We aren’t rebuilding the entire system on every commit.

• Small batches
• Driven by tests
• Continuously integrated with the rest of the team’s changes
• Continuously delivered and validated

That’s the work, whether a human types the code or an agent spits it out.

What people think is new is what they avoided learning for 20 years

I’ve seen this pattern repeat endlessly:

• People skip the “conversation first” part.
• They treat requirements as gospel instead of hypotheses.
• They ship quarterly bundles of misunderstood features.
• Then they declare Agile broken because the slogans didn’t save them.

If you want a taste of the real deal, try BDD and ATDD, then add agents. Now you get acceleration and safety.

If you skip the discipline, you get vibe coding with prettier marketing.

AI doesn’t eliminate engineering discipline…

It amplifies whatever you already are.

AI-assisted development works beautifully for teams with strong fundamentals — clear behavior definitions, fast feedback loops, small steps, and real continuous integration. I’ve written extensively about this.

And it works terribly for teams who lean on process theater, vague requirements, slow integration, and giant batches. They’ll blame AI. But it’s not AI. It’s them.

As I’ve said many times:

AI amplifies your discipline or your dysfunction. Your choice.