Method
AI-augmented development, driven by specifications
AI augments an engineer's skills: it writes fast, in every language, and writes tests without ever tiring of it. It decides neither which system to build nor what is correct. My method keeps those two decisions on my side and hands the rest to the machine, under control.
Origin
A method formalised by GitHub
Spec-Driven Development was formalised by GitHub in September 2025 with Spec Kit, an open source toolkit presented by Den Delimarsky. The specification becomes the project's source of truth: the AI works from it rather than from a conversation. I apply it to all my development work, complemented by rules drawn from twenty years of industrial R&D.
The cycle
The life of a feature
- 01
Specify with you
We write the general specification together: what the software must do, for whom, with which business rules and which exceptions.
- 02
Detail
I then detail the specification point by point, as numbered, verifiable requirements that you review before we go further.
- 03
Validate the screens
Before a single line of code, you handle the screens as interactive mock-ups. You correct them, then you sign them off.
- 04
Plan
I choose the architecture, the interfaces and the technical trade-offs, then break the plan into short tasks linked to the requirements.
- 05
Implement
The code and the tests are produced task by task, within the set framework, using in-house tooling and production methods. I review every change before it enters the repository.
- 06
Verify
Unit, integration and end-to-end tests, in a real browser or on the real hardware. The integration pipeline blocks any regression.
What AI changes, and what it does not
What AI has changed
- Language is no longer a barrier: AI writes Rust as easily as Kotlin.
- Full test coverage becomes within reach of every project.
- Code is produced in abundance.
What remains a craft
- You still need to know which system to build, and why.
- You still need to recognise a wrong result, and you can only review well what you could have written.
- The contractor alone remains responsible for what is delivered.
What you gain
Everyone knows software should be covered by unit, integration and end-to-end tests. Few projects pay for them, because writing them used to cost more than the code itself. Framed by specifications, AI brings that cost down: you get a level of test coverage that used to be reserved for certified programmes.
What you get
At the end of the engagement, everything that was produced belongs to you.
- The source code, in your repository
- The numbered specifications
- The test suite, runnable by your teams
- The test execution reports
- The technical documentation
Questions
The questions I am asked
Where does my code go?
Your code stays in your repository and on my workstation. Only context excerpts go to the AI provider, never the whole repository and never your production data. If your security policy requires a stricter boundary, I comply and tell you what it changes to the schedule.
Is code written with AI reliable?
As reliable as the frame around it. Here, a numbered requirement comes before every feature, a test verifies it afterwards, and I review in between.
Who is responsible for the delivered code?
I am. Delivered code is reviewed, tested and owned, however its first version was written.
This site follows the same method
Its test suite runs on every release, and the report is published with its date and version number.