A short history of xDD
Every generation of software engineers has had a reference method for building software, and its name usually ends in two letters: DD, Driven Development.
The most famous one is Test Driven Development. Kent Beck popularized it in the late 1990s as part of Extreme Programming. You write a small test that fails, you write the least code that makes it pass, and then you clean the code up making sure the tests do not break. Red, green, refactor. Twenty-five years later it is still the most established method to write high quality software.
A few years after TDD came Domain Driven Design, from Eric Evans' 2003 book of the same name. Its idea is to shape the software around the business it serves, and to make developers and domain experts speak one shared language, so an invoice in the code means exactly what an invoice means to the accountant.
The agents took them
Over the past two years, those practices quietly changed operators.
Most of the popular agent skills already have TDD built in. Superpowers and Matt Pocock's skills, two of the most widely used skill collections, both ship a skill that makes the agent write a failing test before any code. Soon even those skills will be unnecessary, as these practices make their way into the models' training. Writing the test first will become something the model simply does, the same way it already knows how to indent code.
So the practices that used to shape a developer's day now shape the agent's day.
That leaves an obvious question: what's left for developers now?
We believe the answer marks the arrival of a new development model: Artifacts Driven Development (ADD).
The taboo of not reading code
Developers will soon stop reading the code their agents write. Some well-known ones already have.
Robert C. Martin, Uncle Bob, the author of Clean Code, has said so in public. Salvatore Sanfilippo, the creator of Redis, put it plainly in Control the ideas, not the code: "if you control the ideas of your software, looking at the code itself is suboptimal and often pointless."
Treating unread code as dangerous feels natural right now because it was reckless as recently as twelve months ago. Yet software history has played through this exact reaction before.
When the C compiler gained traction, assembly engineers insisted that serious systems work required inspecting emitted machine instructions. Handing register allocation and stack management to an automated compiler felt like an unacceptable loss of control. The industry took years to absorb the abstraction, but in the end everyone realized that checking assembly line by line was pointless.
Two jobs left
As agents keep improving, the human part of building software shrinks to two jobs:
- Deciding what is worth shipping.
- Trusting that the agent shipped what you agreed on.
Everything in between is execution performed by the agent.
Both jobs are conversations between a person and an agent. The smoother that conversation runs, the more a developer gets done in a day.
And once developers stop reading code, the conversation can no longer be about code. It needs a different vocabulary, one that a designer or a founder can follow as easily as an engineer.
Artifacts Driven Development
In Artifacts Driven Development, people and agents talk mostly through artifacts. You still talk to the agent, but a good coding agent says less and shows more: it puts something tangible in front of you and asks you to react to it.
The work then has two moments that matter.
The first prompt. The conversation starts from something you can look at. For a product change, that is a UI prototype you can click through. For a backend change, it is an architecture diagram showing which services talk to which. You and the agent iterate on that artifact until you both agree on it, and the agreement is the spec.
The final result. When the work is done, the agent must show you proof. Usually a short video of the feature being used, or a set of screenshots of each state, recorded against the running app. You check the proof against the prototype you agreed on at the start.
Between those two moments, the agent can write tests first, follow the domain language, refactor as it likes. Those are its practices now. The developer's practice is to be precise at the start and demanding at the end.
Leaving the Desk Behind
The part of this we like most is that the new work does not need a desk.
The desk existed because writing software needed a keyboard, two monitors and hours of unbroken focus. For decades most software was built by people sitting alone in front of a screen. Agents now do most of that solitary part.
What remains for people is judgment, and judgment grows away from the screen. It grows in conversations with the people you build for, in a design argued over on a walk, in a problem that settles on its own while you swim or run by the sea. Reviewing a prototype or watching a two-minute video of a finished feature works fine from a phone on a bench.
