By now you’ve probably guessed it: Endora Commerce is built with the support of AI tools. I use AI to prepare base designs, to research and discuss product, business and architecture decisions, and, yes, to write the code. My job is to review what’s generated, set the direction and suggest corrections. So far I haven’t written a single line of code in this project myself.
But the work that takes most of my time, and the heart of this post, is writing specifications. For this platform I decided to use Spec-Driven Development.
What Spec-Driven Development actually is
The idea is simple: as the person creating the solution, I describe every business, technical, architectural, performance and security aspect of the features and of the platform as a whole. From those specifications, the AI tools then do the work:
- Write the tests: acceptance criteria from the spec become executable checks.
- Write the code: implementation is generated against the spec and its tests.
- Generate the docs: project documentation stays in sync with what was specified.
I describe the business, technical and security aspects of each feature. The AI writes the tests, the code and the documentation against that spec.
Why a toolkit helps
Because I hadn’t worked this way before, I leaned on what the market offers and adopted the Spec-Kit toolkit. It’s a kind of framework that helps you write specifications for business features in digital products, breaks that specification into tasks, and implements them with an AI-assisted coding approach.
I’d recommend it strongly, especially if you’re just starting with Spec-Driven Development, since it builds good habits for working in this methodology. And the same Endora Commerce design work can be imported straight into a coding agent, so the design stage flows directly into implementation.
In practice, a single feature spec usually runs a few pages: business context, user stories, acceptance criteria, and notes on performance and security. The more precisely I describe edge cases, for example what happens when two pricing rules overlap, the less I end up correcting in the generated code afterward.