I finally got the chance to play with GitHub Spec Kit the other day. It’s a pretty good framework for spec driven development! It establishes a spec -> implementation plan -> task list pipeline, followed of course by task implementation.

It’s possible to “hand roll” this same pipeline with well-chosen prompts, so this tool is not strictly necessary. What Spec Kit brings to the table is a standardized set of commands that provide a golden path towards this practice. Moreover, these commands are source-controlled so they can be improved and shared readily.

The best thing about this approach is that it pushes engineers towards timeless best practices - planning, problem decomposition, etc. It also creates source-controlled artifacts (implementation plans, task lists) that can be tremendously helpful in long-term maintenance. You might say, we should have been practicing this approach all along.

More tactically, this approach maximizes the coding agent’s context window, by giving it just-enough context at every step of the way. It’s a special form of context engineering, really.

But there are some pretty big questions left open.

  • Is this process overkill? Are we reinventing waterfall? I see the value in this criticism, but I think the answer is, “it depends.” Some problems are so small or straightforward that the coding agent can jump straight to implementation. Others are so vague that they’re not even ready for specs. I suspect there are a lot of problems that fall into the “sweet spot” where this approach makes sense.
  • Should specs be generated by coding agents? In terms of Spec Kit, is the “/speckit.specify” command actually a good idea? It seems to me that specifications should be written through a collaboration between product management and engineering, and the agent’s place is at best to identify inconsistencies or ask clarifying questions. My preference is for specs to live in Jira and to be imported into context via an MCP.
  • What do we do if specs change after implementation is done? Should we rerun the pipeline with modified specs, or just start a new feature? I think the answer is probably “it depends.” Some modifications are small enough that they can be achieved by directly fiddling with the task list; others are so substantial that they should be treated as a brand-new feature.

I think that spec-driven development is an important new skill, and Spec Kit is a pretty good framework. A lot of the questions above will probably become questions of craft and skill over time, in just the same way that writing a good function or class has been for many years now.

Also find this post on LinkedIn!