Robert Ta built Spec Kit, an open-source toolkit with 122k GitHub stars that uses AI to generate code from detailed specifications. The key insight: 65-80% of the work is writing the specs themselves, not the code. His team writes research docs, test strategies, and implementation plans upfront, then lets AI handle the generation.
This is Spec Kit. They describe themselves as an open source toolkit for building high quality software with any coding agent, a ready to use spec driven process, or bring your own endlessly extensible community driven built for your whole org. This has 122,000 stars. So speculative development flips the script on traditional software development. Any AI builders, you want to take a look at this. For decades, code has been king. Specifications were just scaffolding we built and discarded once the real work, quote unquote, of coding began. Spec-driven development changes this. Specifications become executable, directly generating working implementations rather than just guiding them. I think the way that Jonathan and I have been working, for us, our general thinking on methodology is spend a lot of time thinking about the plan that you'll set the agent on and be able to hold it to with evidence that it did the thing you wanted it to do with the exit criteria. This is our PR lifecycle, and this green area is where we define our specs. This could look like something different for many different people, but this is what we do. And in Spec Kit, they kind of talk about your whatever spec process, bring it. So there's lots of different spec processes, but what you're essentially doing is curating the input artifact that feeds the code generation. That is it. How you do that, lots of different flavors, lots of different toolkits to do it. Me and Jonathan, we do this where most of our effort goes into a research MD file that researches the state of the existing codebase, formulates a test strategy MD, which is the exit criteria. You hold the coding agent to, so it verifies the outcomes you're driving and you know that it did right. The implementation plan, so the step-by-step map to the acceptance criteria you create. We're basically saying like, when you start a PR and it's in progress, we have some commands for this. You're just iterating here for a long time, maybe 65, 80% or more of your brainpower time. Then you actually go execute and that takes less time. Now you're typically just steering sessions at the end of the execution. You have another phase where you could review this and do an adversarial code review. A lot of people are doing like Codex code reviews my Fable PRs or vice versa. That's really how I think about it. It's like a very loaded term and there's lots of tools and lots of ways to do it, but put a lot of brainpower in the input artifact that informs the code generation. It's the TL;DR.
