More than a hundred thousand GitHub stars in under a year, for a project that is mostly a collection of Markdown templates. GitHub's Spec Kit passed 115,000 stars by June 2026, less than a year after launch. It isn't a new engine, a compiler or an AI model. It's an organized way of asking a coding agent for things. I think this says more about programming in 2026 than a lot of new model announcements do. The thesis behind spec-driven development (SDD) fits in one sentence: if the machine writes the code, the document that comes before it becomes the real work. It grew out of a very concrete frustration with "vibe coding", the habit of telling the agent what you want in a chat and correcting as you go. Some guides claim the freeform mode stops being reliable around 500 lines, because the agent guesses at requirements nobody wrote down. That's a round number and a rule of thumb, not a law of physics. But anyone who has left an agent alone on a project with three screens and a database knows the moment it starts making things up. #### <br>Three files, four commands Kiro, from AWS, is an editor derived from VS Code. It enforces a three-phase flow: requirements, design and tasks. Each phase lives in a Markdown file, `requirements.md`, `design.md` and `tasks.md`, stored in `.kiro/specs/` inside the repository itself. You can start from requirements or from design, and there's a looser mode for when you just want to experiment. Spec Kit does the same without tying you to an editor. It's a loop of /specify, /plan, /tasks and /implement that runs across dozens of agents, from Claude Code to Copilot to Cursor. In both cases there are stops where a human has to approve before the next phase starts. The practical effect is a change of trade. You spend less time writing functions and more time reviewing intentions, and plenty of people didn't sign up for that. #### <br>UML promised this too In the 2000s there were tools that generated code from diagrams. The promise was the same as today's: go up one level of abstraction and let the machine handle the rest. A comparison of SDD tools published on GitHub lists, among the risks, a resemblance to model-driven development, which failed. The comparison is fair. The model needed so much detail to generate anything useful that it ended up being code with worse syntax. And when someone edited the code by hand, the diagram fell behind, forgotten in a folder. Swap "diagram" for `spec.md` and both failures still fit. A forty-page requirements file full of edge cases is programming in plain English, without even a compiler to tell you you got it wrong. The second failure, drift, doesn't come with encouraging numbers. In the classification that's going around, tools like Spec Kit, Kiro and BMad sit at the "spec-first" level, where the spec comes before the code but is discarded afterwards. The spec is used to generate, then it dies. Those betting on treating the spec as a long-lived artifact, like Tessl, take the problem head-on. And that's where the parallel with the 2000s tightens. #### <br>Plain language, not formalism There's a difference that isn't marketing. The 2005 models demanded a formal language. An LLM accepts a paragraph of ordinary English, ambiguous and a little sloppy, and returns something that compiles. The barrier to entry has dropped, and that changes who can write a spec: the product manager, the solo founder, the person who never opened a class diagram. But the ease comes at a price. A compiler gives you the same binary twice, and an agent doesn't. The same spec can produce two different implementations, both defensible. That's why a spec isn't "source" the way source code is, and anyone selling the opposite is pushing an analogy past what it can carry. A hypothetical example. You write in a spec: "a comment with three reports gets hidden". It looks closed. The agent has to choose: three reports from distinct users? Within what time window? Do moderators' reports count the same? A ten-word sentence was hiding at least three product decisions, and each one ends up somewhere different in the code if nobody writes it down. My reading is that the value lies in the act of writing, not in the file. Being forced to decide what happens when a payment fails, or what an "active" user is, before the agent touches a line, solves half the problems. The `.md` is a useful by-product, but still a by-product. For a landing page or an afternoon script, all of this is too much ceremony. For three services and four people asking the same agent for things, it isn't. One detail to finish. According to a July 2026 survey, Kiro was at version 1.0 and Spec Kit was still at 0.14.1. The comparison I mentioned records those two versions. Worth remembering the next time someone tells you the method is settled.