This post is a a follow up to experimenting with OpenSpec from last week. For today’s experiment, I used GitHub Spec Kit. I did this all on my laptop, under WSL. I repeated my Towers of Hanoi project, which I’ve been using for miscellaneous AI experiments. Once again, I used a “requirements.md” file that describes the program I want to write, the same file as I’ve used for the other Towers of Hanoi projects.
Installing Spec Kit is a little harder than installing OpenSpec. You need to install something called “uv” first. Then, you use that to install Spec Kit. (OpenSpec is just a regular “npm install…” thing.)
To start a new project, you do something like this: “specify init towers-speckit”. (This is from bash, before you’ve launched Claude.) That creates a folder with a bunch of template files in it, basically.
After that, you can go into Claude and run “/speckit-constitution”, which is supposed to create a “constitution” for your project. OpenSpec doesn’t have anything exactly like this. I’m not sure how valuable it is; I think a lot of stuff that goes into the constitution could just as easily be in CLAUDE.md. (I guess I can see some point in keeping them separate.)
I’d be interested to see what Spec Kit does with this command, when run on a brownfield project. On a greenfield project, there’s not much to go on, so you’re going to get a pretty generic document. I guess you could go in and fiddle with it yourself, customizing it with your own preferences.
(One interesting side-note here: at no point in this experiment did I get around to creating a CLAUDE.md, nor did Claude / Spec Kit ever suggest that I do so.)
After that, the process looks similar to OpenSpec. You start with “/speckit-specify” to create a spec, then “/speckit-plan” to create a plan, then “/speckit-tasks” to generate a task list, then “/speckit-implement” to actually write all the code.
I found that this process took longer and (probably) burned more tokens than in my OpenSpec experiment. The repo for the project is here.
I had Claude Cowork run a comparison of the two repos, OpenSpec vs Spec Kit, just in terms of size (number of files, etc). In terms of program source, they’re quite similar. Claude thought that the Spec Kit one had “richer test coverage,” but I don’t think there’s a big difference. It noted that Spec Kit has far more spec content (~83 KB vs ~39 KB) and is is overall ~77% larger by byte count. So yes, the idea that Spec Kit is “heavier” holds up.
One other thing to note is that the Spec Kit implementation had a bug in it. If I had actually reviewed the spec, plan, and task docs, I could probably have tweaked them to avoid the bug, but I didn’t do a thorough review of them before proceeding to implementation. So I think that, if you’re just vibing your way through things, SDD doesn’t help that much. Maybe on larger projects it would. But on smaller projects, I don’t think the spec docs are that useful, unless you’re actually reviewing and correcting them before implementation. (It’s kind of like the spec docs we created in the old days; if nobody’s reading them, and thinking deeply about them, then they’re just extra paperwork.)
I’m still undecided as to whether or not I want to start using one of these tools at work. My current workflow for AI development is working reasonably well. I usually create a “plan” doc myself, sometimes with the help of AI and sometimes from scratch. Then, I point the AI at that doc and tell it to implement the feature or fix and update the doc as it goes. Putting more structure around that might be useful, or might just be extra work/bloat.