For months now I have been building with AI using a vibe coding methodology, making heavy use of tests and of agent and skill definitions as the project moves forward — and on a project that was already up and running more than two years ago. The result is very satisfying: I can honestly say the development throughput is at least 10 to 1, meaning that what used to require 10 working days of effort now takes 1 with vibe coding.

In this post, and in all the related ones, I make the jump to AI-driven development using the Spec Kit development kit created by GitHub in order to apply Spec-Driven Development or SDD, and build a sample application that a friend has asked me for: an application to manage the members, documents and logbook/minutes of an association — in this case a religious brotherhood (cofradía). That application will be CirineumSDD, and it is the one I will use throughout these posts to detail how Spec Kit SDD works.

Everything detailed in this post and its related ones regarding the CirineumSDD application — the Spec Kit files and the AI harness prompts — is written in Spanish, because that is my natural language.

I do not have deep knowledge of AI-driven development with SDD beyond what I have read on the internet, and in particular in the book "Spec Driven Dev" by Bazael Pérez, where all the concepts are explained.

I see SDD as a development methodology that is based on defining everything up front, the way orthodox development has always done it: requirements definition, usage rules, functional definition, organic (technical) definition, validation checklist, and so on. And once you have all of that, you build.

From my experience in the development world, the requirements are generally never fully there, the usage rules have to be guessed, the functional definition is incomplete and the organic definition is non-existent — and let's not even talk about the tests or acceptance validations, which are neither available nor expected to be. And in the face of that scenario, work goes ahead without any of it, through continuous adjustment processes whenever a non-conformity is detected... and that is partly where the rise of Agile-style methodologies comes from: narrowing the focus onto small goals and gradually analyzing the deviation and the roadmap to follow in the very short term. Making friends along the way.

With AI-driven development under SDD, everything must be defined before development starts, across a set of files named according to the Spec Kit conventions plus a series of commands that drive the Spec Kit workflow cycle (that flow varies depending on how the Spec Kit has evolved, but the philosophy is visible in what I detail below), per "feature":

  • Definition of the project's technical principles, in what is called the constitution, by running the command "/speckit.constitution": allowed technologies, security requirements, performance and scalability requirements, naming and coding conventions, and general constraints at the level of regulations, accessibility and audits.
  • Create the git branch for the "feature".
  • Definition of the "features" the application must have. These "features" are created with the Spec Kit command "/speckit.specify", which details the "feature" and is the first command of the Spec Kit workflow cycle. Every feature must have its own git branch, and we will see in other posts why this is necessary.
  • Once the "feature" is defined, the command "/speckit.clarify" must be run so that the agent reads what has been specified in the "feature" plus everything detailed in the constitution that relates to it, and finds ambiguous or conflicting aspects, asking us how to resolve them with different options. It can be run more than once, which is what is called "grilling".
  • Then "/speckit.plan" must be run; it generates the technical plan for the specification, producing a plan.md file for the "feature". The plan carries the technical architecture, the components (which I call "gates"), the dependencies between these components or "gates", the relevant decisions, and the structure tree of the code and the documentation (the "feature" itself).
  • Then "/speckit.tasks" must be run; it turns the previous plan into executable tasks or issues, producing a tasks.md file.
  • Then the command "/speckit.analyze" must be run; it checks consistency by verifying whether every requirement of the "feature" is implemented, whether the tasks cover every element of the plan, and whether there are conflicts between the plan and the constitution.
  • Then the command "/speckit.checklist" must be run, generating a quality verification list according to what has been specified for the "feature".
  • Once all of the above is done, "/speckit.implement" must be run: the agent reads the tasks, the specification, the corresponding plan and the constitution, executing each task, implementing it and documenting what has been implemented.
  • With the "feature" now a priori implemented, the command "/speckit.converge" must be run; it performs an audit and a gap analysis on the project, checking what has been implemented against what was specified, the plan and the task list. It is useful for detecting pending work or deviations. It never alters the code, but it can update the tasks.
  • Commit the code and the documentation. With almost every Spec Kit command you run, it matters to always commit. And since that is true of almost all of them, I apply it to all of them, so I don't end up forgetting.
  • Create a Pull Request (PR) from the "feature" branch to the target branch, develop or main, depending on the project team's branching strategy.
  • Human review (code review) with unit, integration, performance and functional tests, plus the usual CI/CD flows.
  • Once the code review is approved, merge the "feature" branch into the target branch.

Now let me detail the harness I have decided to use for this CirineumSDD development with AI using Spec Kit SDD, on an Ubuntu machine:

  • Planner: Opencode with the GLM 5.3 LLM
  • Executor: pi with the GLM 5.3 Flash LLM
  • Runtime: Orca
  • Pair or coding partner in the Navigator role: Hermes with the DeepSeek V4 Flash LLM. In pair programming I always take the Driver role. I never let Hermes modify anything, but I do ask it to always review the outcome of every Spec Kit task executed for each feature, in order to detect gaps or aspects to improve in the definition or clarification.
  • Debug, for diagnosis, detection and fixing of software bugs: VSCode with the Zoo Code AI plugin in "Debug" mode, using the Qwen 3.8 Flash LLM.

Throughout the different related posts we will be looking at how each of these tools is used and the considerations to keep in mind.