I deleted my source code

But what actually matters are the decisions:

• What is the API contract


• What happens when a parent record is deleted


• What validation rules do we have


• Whether partial updates use null to mean "clear this field" or "I didn't send this field"

The code is just one expression of those decisions — and increasingly, not one that anyone needs to maintain.

This raised an interesting question:

What if the code was a build artifact, like a compiled binary, and the spec was the source?

I built a proof of concept to push that idea to its limit.

The experiment

A — A plain language description of a feature. Containing business logic, and some technical spec details.

In our CI pipeline, an AI agent reads all of it, generates the implementation, runs the tests, fixes potential failures, and continues until everything is green. The generated code never gets committed. It's produced on demand, in CI, and thrown out on the next build.

The benefit of this approach, is that our code magically improves. As AI agents improve, and new models are released, our code massively improves too. Its regenerated on every build. There is no legacy code. If there is a new best practise, or even a new framework, we can just add it to the spec and regenerate.

Imagine if we add a new feature that fundamentally changes the API. We don't have to worry about how the implementation will work with the old code. The new code will support this feature from the ground up.

The sample domain is a task management API — Symfony 8, Doctrine, PostgreSQL — built incrementally in five commits. Each one follows the same pattern: write a spec, write tests, extend the schema.

Commits

— Extended the existing spec and tests rather than adding new files. Added parent_id, one-level nesting, cascade deletes, and a key business rule: a parent task can't be marked done while it has open subtasks. The agent regenerated the entire codebase and passed all tests on the first run.

— The interesting one. An activity log tracking creates, updates, and deletes across the entire system, tasks, subtasks, and comments, all scoped to the top-level task. A cross-cutting concern: the agent had to wire logging through every existing endpoint without breaking anything.

"AI writes code for us" is the shallow version. The deeper version is: the value moves from the implementation to the specification. The developer who writes a precise, testable, complete spec will produce better software than the one who writes clever code — not because the spec generates the code (though it can), but because a precise spec forces every decision to be made explicitly, documented, and verifiable.

Most teams already sense this. It's why we write acceptance criteria. It's why we write integration tests. It's why the best tech leads spend more time on requirements than on pull requests. Spec-driven development just follows that intuition to its logical end.

Whether you ever adopt this workflow or not, the experiment leaves you with one useful question:

If your specs aren't precise enough to generate correct code from, are they precise enough to build correct code from by hand?

Conclusion

While the demo project I used here is a best-case scenario, it's not impossible to imagine a future where the spec will become more important than the code.

Imagine if you can generate a full, feature complete spec from an existing codebase. Replatforming a legacy system becomes a matter of tokens, not months of development. You can switch frameworks, languages, architectures, with the push of a button.

The classic development workflow we all know and loved, is disappearing fast. We will no longer care about the nitty gritty details of how the code works. We will only care that it does.

Sources

• The Github repo