Ten years ago, I attended a workshop on building DevOps teams for CTOs at Chef's annual conference in Austin, Texas.
One of the speakers was Chef's VP of Engineering, who shared a story about Spotify. He opened with a provocative line: "nothing of what's published about how Spotify works is true." He then mentioned that some of the articles we could find online were actually his own. He had consulted with the team to help them develop their working methodology. What he had learned from them was their unique capacity for reflection and continuous evolution: how they work today is very different from how they worked 6 months ago, which in turn was very different from how they worked 6 months before that.
That continuous learning mindset became an inspiration for how I work, and it has shaped my approach to agentic software development and, especially, to adopting Spec-Driven Development in that context.
Why I Don't Recommend Any SDD Framework
Several people have asked me which GitHub SDD-framework repositories I recommend. My answer is none. Does that mean they're not good? Not at all. Some contain very valuable insights and can offer inspiration for designing your own model. If you find an interesting project, explore it, understand it, and learn to extract the valuable lessons and incorporate them into your own model.
My recommendation is to follow your own path: build your own SDD implementation and evolve it continuously. For every mistake you encounter along the way, every lesson learned, take the time to analyze it and add it to your knowledge base. You can use skills to implement continuous improvement cycles. This gives you the flexibility to create a system tailored to your needs, with the ability to incorporate the learnings you gain from experience.
A Concrete Example: /pipeline-optimizer
In all my projects, I implement a /pipeline-optimizer skill. When an error occurs, its role is to investigate the root cause and propose systematic improvements to prevent errors of the same kind from happening again. The skill owns the definitions for agents, skills, rules, hooks, and the specifications of the development pipeline and quality guidelines.
Why Self-Evolution Matters
This capacity for self-evolution becomes critical because of the speed at which tools and LLM models are changing. As an example, Claude Code ships a new release every 1 or 2 days, and it's not just bug fixes: each release brings new functionality. If you own your model, you can understand those changes, evaluate them, and adopt them at your own pace. If you depend on an external framework, you wait for someone else to do it for you.
** What path are you following? Are you building your own SDD implementation, or still relying on external frameworks? **
Top comments (0)