Robert Ta and Jonathan argue specs should replace code as the primary source of truth in AI-assisted development. GitHub Spec Kit shows a 10× reduction in regeneration cycles, and AWS Curo completed an 18-month re-architecture in 76 days with six people by investing upfront in research.md, teststrategy.md, and implementation plans before invoking coding agents.
Let's talk about spec-driven development a little bit. This almost seems like it's old news because we've been doing it for so long, but in working with orgs, we realize that actually at most orgs I work with, it's like there's 1 to 10%, maybe, that are really AI-pilled that are like, yeah, spec-driven development. I've been doing that for like a year now. And then there's the rest of the org that is like, what is this spec-driven development? Like, why do I need to use this? I'm already underwater from all my feature development. Do I need to change? Some of why you should be using spec-driven development, and then we'll ground it in How do you build harnesses? Spec-driven development is now the 2026 enterprise standard. The specification, not the code, becomes the version-controlled source of truth in plain English. If you're an engineer, you're typically not reading code anymore. Even the best engineers out there like Karpathy, Hashimoto, they're talking about how they're not reading code 100% of the time anymore. And so the spec, the English, like the contract that you hold the agent to, that matters a lot. And our recommendation is have your engineers ship the spec to the codebase as part of the PR. So Some stats from spec-driven development. 10x fewer regenerate from scratch cycles via ad hoc prompting. This comes from GitHub Spec Kit data. 76 days to do an 18-month rearchitecture completed by 6 people using AWS Curo. This was a data point that sort of shows that if you get your engineers shipping the right way on, on a team, and this team centered it around spec-driven development, they could ship faster. Many tools ship using spec-driven development. So you've probably used some of these tools like GitHub Spec Kit, AWS Curo, or Cloud Code or Cursor or Antigravity. And it basically looks like this. What is speculative development? Here's the old world. The old world is you give a vague prompt, the LLM generates some stuff, you review what's missing, you regenerate stuff, and you rework things. It takes on average 5 cycles to rework, and then you ship it and you might have tech debt because you didn't think through everything and you got to rework later. Versus new world is most of your brainpower goes into researching requirements, figuring out the test strategy, the exit criteria, making the spec, This in itself is version reviewed, cited. Me and Jonathan, for example, will ship a spec as a PR, give the PR link to each other. We read it, we add a comment, we'll regenerate. And that way we get rapid stakeholder feedback on the spec. And then the agent execution. Now we have goal loops and long-running autonomous agent loops as a meta standard. Now, if the spec is really good, you're just nudging and stirring agentically. And you might have multiple sessions you're doing this with, and that increases your leverage and throughput as a builder by orders of magnitude. And then the spec is the acceptance criteria. So anytime you need to go in there for a human review, you're just checking off boxes. And that way there's 10x fewer rework cycles. The reason why this is important is because if you check in the spec and then you learn, hey, was this PR good? Did it actually move business outcomes, product metrics that we care about? Then you can actually go back to making the harness of all this better tied to, you know, real-world value. Thoughts on spec-driven development? Jonathan, any meta you want to give in terms of how you do your spec-driven development and what's important to you before you ship off the agent to execution land?
Yeah, well, honestly, the word spec-driven development and the toolkits that come with it are new terms to me. So, you know, I'm kind of curious, what do you see as the, the innovation that they're providing? Is this kind of like the MCP standard for how to evolve specs? You know, when we look at something like the GitHub Spec Kit, for instance.
Yeah, let's go ahead and look at that. 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 Spec Driven 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. So towards your question, I think the way that Jonathan and I have been working, we just have a set of commands that we have standardized for ourselves, for our own pull request lifecycle or pull PR lifecycle. 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 are essentially doing is curating the input artifact that feeds the code generation. That is it. That's Spectra development is curate the input artifact that informs the code generation. 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 teststrategy.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 it right. The implementation plan, so the step-by-step map to the acceptance criteria you create. And 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, is my experience. 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. So yeah, Jonathan, to answer your question, 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 is the TL;DR.
