Another X-Driven Development?

I’m starting to suspect there’s a whiteboard somewhere with the alphabet down one side and “-Driven Development” down the other, and every few months someone walks up and claims a letter.

TDD. BDD. DDD (which, to be pedantic, is Domain-Driven Design, but it gets invited to the party anyway). Spec-Driven Development has been the big one for anyone working with AI agents this past year. And recently, scrolling through r/ClaudeCode, I met the newest member of the family: Artifacts Driven Development. In the comments, someone had already replied that they’d called it Proof Driven Development. Of course they had.

It’s an easy thing to poke fun at. But I read it properly, and I’ve been chewing on it ever since, because underneath the naming joke there’s a real question: why do we keep inventing these, and why does it feel like the pace has picked up?

A different question every time

My theory is that every one of these is somebody’s answer to “where does this keep going wrong?”. They just looked in different places.

Test-Driven Development
Kent Beck, late 1990s
Does the code do what I think it does?
A failing test, then the least code that passes it.
Domain-Driven Design
Eric Evans, 2003
Does the code speak the same language as the business?
A shared model, and words that mean one thing.
Behaviour-Driven Development
Dan North, mid-2000s
Are we building the behaviour people actually asked for?
Examples in plain words: given, when, then.
Spec-Driven Development
Spec Kit, Kiro and friends, 2025
Can an agent build from something sturdier than a chat?
A spec, a plan and a list of tasks.
Artifacts Driven Development
r/ClaudeCode, 2026
Can I agree on the work, and check it, without reading the code?
A prototype at the start, proof at the end.
Blank-Driven Development
Unclaimed
Did we agree on the right thing in the first place?
That’s the one this article is about.

Each one answers a different question. The blank row is the one I keep wanting to ask first.

None of them is wrong. They’re aimed at different parts of the job, and in practice most of us mix and match without much ceremony. A bit of TDD here, some domain language there, a spec when the work is big enough to deserve one.

I’ve been building software for twenty-five years, so I’ve watched a fair few of these arrive to great excitement. Some genuinely changed how we work. Others faded away. What strikes me is how familiar the problems underneath them stay. A quarter of a century on, we’re still trying to get people to explain what they actually want before we start building it. The difference now is that the agent will happily build it before anyone has finished the sentence.

BDD has been on exactly that case since the mid-2000s. Underneath all the Gherkin files, its real point was always the conversation: developers, testers and the people who wanted the thing, working through concrete examples until everyone meant the same thing by “booking”. Asking questions before writing code is not a new idea. Hold that thought.

What the agents changed

For most of my career, building software was slow. Annoyingly slow. And the slowness was doing us a sneaky favour. If a feature was going to take three weeks, somebody usually asked whether we really needed it, and what exactly “it” was, before anyone started. The cost of building was a filter, and a lot of thinking happened simply because nobody wanted to waste three weeks.

Coding agents took the filter away. Which is brilliant! I love it. I can go from a vague idea to something running before my coffee has gone cold. But it also means we can now build the wrong thing at an impressive speed.

Try it. Pretend you run a small hair salon and ask your agent:

Can you add a way for clients to book appointments on my website?

A few minutes later you’ll have something lovely. A calendar, a list of services, time slots, a confirmation email, probably an admin dashboard you never asked for. It looks done. It might even be well written.

And nobody asked a single question about how bookings actually work in that salon.

How long is a colour?: Decided for you: Every appointment is an hour, so your two-hour colours now run into the next client.
Do you still take bookings by phone?: Decided for you: The website is the only diary. Saturday at ten can go to a caller and a website visitor.
How does a client cancel?: Decided for you: With just an email address, so anyone who knows yours can cancel your appointment.
Which stylists can be booked, and when?: Decided for you: Everyone, every day, including the stylist who’s on leave all of next month.
What about no-shows?: Decided for you: No deposit and no reminder. Friday’s empty chair is now the website’s fault.

Five questions nobody asked, and what got decided anyway.

These aren’t hard questions. The salon owner would answer each of them in about four seconds. The agent could have handled every one of them too. Nobody asked, so it guessed, and a guess looks exactly like a decision once it’s wearing a nice UI.

I don’t blame the agent for that, and I definitely don’t want it slower. The speed is the best part. The trouble starts when we mistake a convincing implementation for a requirement anyone actually understood.

Enter Artifacts Driven Development

The Reddit post makes a bold argument, and it’s worth reading in full. Its short version: practices like TDD and DDD have moved from developers to agents. The popular skill collections already make the agent write a failing test first, and before long the models will just do it, the way they already know how to indent code. So what’s left for us?

Two jobs, it says. Deciding what’s worth shipping, and trusting that the agent shipped what you agreed on. People and agents should talk through artifacts: something you can look at in the first conversation (a clickable prototype, or an architecture diagram for backend work) that you iterate on until “the agreement is the spec”, and proof when the work is done, usually a short video or screenshots of each state, checked against what you agreed.

There’s a lot I like in that. An agent that says less and shows more? Yes please. I’ve scrolled past enough walls of agent text looking for the one line that mattered. Proof at the end? A hundred times yes. FeatureKit shares a lot of that thinking; one of its rules is that “done” means proven, not claimed. I even like the bit about leaving the desk behind. Reviewing a prototype from a bench sounds lovely.

Who says we agreed on the right thing?

Here’s where I got stuck. To be fair to the post, it does say you iterate on the prototype until you both agree, and that’s the right instinct. My worry is what happens before that first prototype exists.

A prototype is already a proposed solution. It’s brilliant at showing you how something will look, and very good at hiding what it decided. Our salon prototype clicks through beautifully, and somewhere along the way it decided that phone bookings don’t exist. You approve the screens, and in doing so you approve the rules without ever seeing them.

Then at the end, the proof gets checked against the prototype. The loop closes perfectly, around a decision nobody actually made.

Artifacts can show that we built what we agreed on. They can’t tell us whether we agreed on the right thing in the first place.

That’s the gap I keep poking at. We’re getting genuinely good at building things right. Whether anyone asked the awkward questions first is a different matter, and that’s the conversation BDD has been championing all along. I don’t think the agents killed it on purpose; they just made it so easy to skip that we stopped noticing. So the question I find interesting is how we keep that conversation, and make it a bit harder to skip, when building has become this easy.

About not reading the code

The post goes further: developers will soon stop reading the code their agents write, and some very well-known ones already have. The comparison is the C compiler. Assembly programmers once insisted on inspecting every instruction a compiler emitted, and eventually nobody did.

I understand the thinking, I really do. Nobody is reading every line an agent produces at the speed it produces them, and pretending otherwise is its own kind of fiction.

But I don’t think the compiler comparison holds. One of the commenters pointed out that a compiler is deterministic, which is true, but for me the bigger difference is what each one is given. A compiler works to a contract: the language specification says exactly what your code means, and its job is to translate that faithfully. An agent gets “add a way for clients to book appointments” and has to make dozens of decisions the instructions never mention. A lot of that is design work, done on our behalf, from a single sentence.

A two-minute video of the happy path also doesn’t show you very much. It won’t show the booking endpoint that happily returns every client’s phone number. Or the missing constraint that lets two people grab Saturday at ten in the same second. Or the “temporary” shortcut that every future feature will have to tiptoe around. A working demo can look exactly right while the architecture underneath it isn’t.

This one humbled me a bit. In one of FeatureKit’s benchmarks, built from deliberately planted bugs, a seven-line change passed every check and still had a bug in it. Seven lines! Since then FeatureKit gives every code change at least one review, and only a small docs-only change gets by on checks alone.

So I don’t think the choice is between reading every line and reading none of them. The engineering is in knowing what deserves scrutiny, what evidence would actually convince you, and how much confidence the risk calls for. A typo fix in the docs doesn’t need anyone squinting at it. Anything touching sign-in, payments or people’s personal data does, every time. Architecture, maintainability, security and plain old technical judgement didn’t stop mattering because the typing got faster. If anything they matter more, because there’s so much more code arriving to apply them to.

Why I built FeatureKit

This is a big part of why I built FeatureKit. It came out of a problem I kept running into: coding agents that write fast and leave a mess behind, usually because nobody had properly worked out what we wanted before they started.

FeatureKit isn’t trying to replace TDD, BDD, DDD or any of the others, and it certainly didn’t invent asking questions. It’s an experiment in wiring those established ideas into a workflow an agent actually follows, so the thinking stays connected to the doing. It starts with the bit we keep skipping, understanding what we’re trying to achieve, and runs as a loop.

Clarity
Plan
Slice
Build
Verify
Learn

Each round starts knowing a bit more

FeatureKit’s loop.

Clarity is the stage I care about most, and it’s more than collecting requirements. The agent works out what it can from the project itself, then asks about the decisions only you can make, one per question, with what each choice would mean. Its job is to challenge assumptions, yours included, and help you work out what you actually mean. For the salon, that’s whether phone bookings share the calendar, and what happens to the forty minutes while a colour develops.

Plan writes the answers down as checks the work has to pass, and nothing gets built until you’ve seen the plan and said yes (unless you’ve told it tiny fixes can skip that). Agreeing with a few answers along the way doesn’t count.

Slice cuts the plan into thin pieces that each work end to end, so booking one service with one stylist comes before anyone worries about colour gaps.

Build does one slice at a time, and this is where the other Ds live: tests first where they fit, and the project’s own glossary, so a “booking” means the same thing in the code as it does in the salon.

Verify checks each acceptance criterion against real evidence, then gets a review sized to the risk. A passing build isn’t proof, and a check that didn’t run is reported as “not run”. This is where Artifacts Driven Development’s proof at the end fits in nicely.

Learn isn’t a retrospective at the end. Whenever something goes wrong in a way that could have been prevented, the fix goes somewhere it will last, a test first, then the project’s own docs, so the next round of Clarity starts knowing more and we stop repeating the same mistake. FeatureKit’s own rules change the same way: only when an eval, a trial or a real project shows they should.

The FeatureKit page shows eight steps rather than six. That’s one trip round the loop in more detail, with approval, review and handoff named separately; Learn doesn’t get a step because it happens whenever something worth keeping turns up. You can answer the salon’s questions yourself and follow them through to a first slice with evidence.

It’s an experiment, and it’s been wrong

I don’t want to make this sound tidier than it is. FeatureKit has been wrong plenty of times. My favourite: for a few releases, an opt-in mode sent tasks through a routing optimiser that chose how capable a model each one needed. Very clever. In calibration it picked the level the caller had already asked for, eleven times out of eleven. I had built a beautifully elaborate way of agreeing with myself. Release 0.11 deleted it.

It isn’t free either. In the last full comparison, on release 0.11, it passed more of the evals’ checks than the same agent without it, mostly by stopping to plan and by fixing out-of-date project docs, and it did a little worse on reviewing and two other tests. It also cost about a quarter more per run. That’s a small sample, so I treat it as a hint rather than a law, and the numbers are all here.

And there’s plenty I haven’t worked out. How many questions is too many before someone just shouts “build it”? The salon interview on the FeatureKit page has been cut down more than once because it was too long, which tells you something. I’m still learning, and FeatureKit changes as I do.

So what’s our job now?

I think the Reddit post is right that the job is changing. I just think it’s growing in a different direction. Less typing, sure. More being clear about what we want. More asking the awkward questions early, before the agent fills the silence with guesses. More deciding which parts of the code deserve a careful read, and keeping the whole thing understandable for whoever comes next, which is usually us, three months later, slightly confused.

That sounds like more engineering to me, not less. It was always the hardest part of the job. We just used to have the typing to hide behind.

So, another X-Driven Development? Please, no. The whiteboard’s full. If I could add anything, it would be a question rather than a letter, the one from that blank row: did we agree on the right thing in the first place?

Building software has never been easier. Working out what’s worth building is still on us, and I think that was always the fun part.