“Spec-driven development” is an approach to software development in which one formalizes a specification or spec before writing any code. A spec is a formalized plan that includes “user stories” (what a potential user would want to do with the code) and acceptance criteria (a detailed list of what is acceptable behavior for the code). This would be extremely tedious for the small-userbase computational biology projects that we work with, but it’s 2026 and agents can do all the hard work for us.

Spec-kit is a toolkit from GitHub for spec-driven development using an agent. It solves the central problem with agentic coding: that the agents require frequent guidance to do the right thing. Once you have a spec, you have all of the guardrails set up in advance and the agent can just execute without feedback. Spec-kit works with all major agentic coding tools.

I really recommend this approach. This feels like the way software development should be. One writes out a file (with an agent) describing what is desired, and then the agent asks questions to clarify, carefully works through edge cases, and comes up with a detailed plan, including tests. The agent then writes all the code and tests.

I recently used spec-kit to build a bioinformatics pipeline from scratch in a day. This post walks through that experience. Seeing it in action should be much more helpful than describing the process in vague terms.

Note 1: Spec-kit also works wonderfully for implementing new features in existing codebases. The pattern I like is: (1) raise a GitHub issue describing the vision for the feature, (2) create a spec-kit subdirectory named after the issue number (e.g. specs/298-mpnn-residual), (3) run through the full spec-kit workflow there, and (4) merge. This keeps each feature’s spec artifacts organized and co-located without cluttering the rest of the repo.

Note 2: Some respected colleagues have suggested that Claude Code’s improving long-range planning makes spec-kit irrelevant. That may become true in the future, but as of Claude Code 2.1.42 in February 2026, the depth of planning, consistency checks, and research that spec-kit produces far exceeds what you get from Claude Code alone in my experience.

Start with a vision

My from-scratch bioinformatics pipeline started by agentically writing a docs/vision.md file that described, in broad strokes, what it was I wanted to do. It did some exploration as well about databases we could use and the scale of computation to be done, resulting in a docs/exploration-notes.md.

The Constitution

The process begins by installing spec-kit and establishing a “constitution”: the governing principles for your project. I pointed the agent at my existing coding standards and project documentation (note here that my prompts start with ❯ and are indented):

The agent reads the spec-kit templates and creates a constitution combining principles from my existing standards:

The result is a set of principles tailored to the project. In this case they emphasize prototype-first development, fail-fast error handling, Snakemake best practices, real tests with real data, and clean code essentials. It also lists the key spec-kit commands you’ll use:

/speckit.specify: Creating the Specification

With the constitution in place, you run /speckit.specify to create a detailed specification. I pointed it at my project’s vision documents in docs from the first step:

The agent produces a structured spec with user stories, functional requirements, and success criteria. (The goal of this pipeline is to extract PCPs—parent-child pairs from ancestral sequence reconstructions on phylogenetic trees—but the details aren’t important for understanding the spec-kit workflow.)

You can iterate here with the agent. For example, as I reviewed the spec, I noticed it was missing some requirements around tree rooting and directionality that were important for my use case. The agent updated the spec with new functional requirements:

I also noted that I wanted the spec to be tool-agnostic at this point:

/speckit.clarify: Resolving Ambiguities

Once you have a draft spec, /speckit.clarify helps identify and resolve gaps. The agent analyzes your spec and presents questions organized by category.

Each question comes with recommended options based on the constitution principles. For example, here’s a question about edge case handling with clear options and a recommendation:

After working through the questions, you get a summary showing which categories are resolved and which are deferred to the planning phase:

Important: at this point you want to read the spec in detail. This is the best place to make sure that the process is going as desired.

/speckit.plan: Research and Planning

The planning phase is quite remarkable. /speckit.plan researches open questions for you. Here the agent spawns multiple research agents to investigate workflow engines, tree rooting methods, and output formats:

The research is thorough. Here the agent is discussing taxonomy tools, comparing ETE3’s NCBITaxa with alternatives like taxoniq and direct NCBI dumps:

It even writes code sketches to verify approaches will work. In response to the question above, it did:

All the research culminates in a decision summary—a clear table of choices made and their rationale:

/speckit.tasks: Breaking Down the Work

With the plan in place, /speckit.tasks generates a comprehensive task breakdown. The output looks like:

/speckit.analyze: Catching Problems Early

Before implementation, /speckit.analyze performs a read-only consistency check across the spec, plan, and tasks. Like /speckit.clarify, it’s a quality gate: it catches duplications, ambiguities, coverage gaps, and contradictions between artifacts before you’ve written any code. It also checks alignment with your constitution, so principles you established at the start don’t silently erode as the spec evolves.

/speckit.implement: Implementation and Validation

From here, the agent executes the implementation. After working through the tasks, here’s the summary of key features implemented:

The pipeline validation shows concrete results—92 sequences processed, 5 clusters created, 146 PCPs extracted:

The agent then helped set up remote execution using the tooling we have available in our group.

And here’s the pipeline actually running MMseqs2 clustering on a remote server:

Finally, the pilot run completes with a summary of what was accomplished and issues discovered:

Conclusion

This for me is a really remarkable milestone: we were able to go from zero to a mostly working pipeline, only starting with an idea, and mostly participating by answering some completely reasonable questions. Even without the agentic implementation step, this is a highly productive way to think through all of the gotchas that usually require code rewrites down the road. Give it a shot and let me know how it goes.

This is part 5 of a series on agentic coding:

1. Agentic Coding from First Principles
2. Agentic Git Flow
3. Writing Scientific Code Using Agents
4. The Human Experience of Coding with an Agent
5. Spec-Driven Development with spec-kit (this post)

View the complete series →