Microsoft and GitHub have made AI assistance a key part of their software development tools. Embedded in the latest Visual Studio and Visual Studio Code releases, GitHub Copilot puts a multifaceted pair programmer—combining AI-powered code completion, coding agents, and various Model Context Protocol servers—right inside your editor.

The resulting tool kit is especially useful as part of a well-designed application development life cycle. Outside of good software engineering practices, however, it’s easy to let vibe coding run away with itself, adding features that aren’t needed and making code overly complex.

Introducing Spec Kit

GitHub recently announced a new approach to AI-assisted application development, one that aims to implement more than simple coding tools. It starts with a set of design principles and walks you through much of the software development process. With it, you can go from a basic specification to a working prototype—with dependencies installed and running—in an afternoon.

Available as the open source Spec Kit, GitHub’s tool is designed to work with AI coding assistants, such as GitHub’s own Copilot, linking to agent frameworks and using them to provide a command-line development environment. The intent is to build on the user-facing concepts behind vibe coding but to back them up with software engineering methodologies. This approach should produce better end-to-end solutions rather than blocks of code that may or may not work the way you intend.

GitHub Principal Product Manager Den Delimarsky described the problem in GitHub’s announcement blog post: “The issue isn’t the coding agent’s coding ability, but our approach. We treat coding agents like search engines when we should be treating them more like literal-minded pair programmers.” The key to spec-driven development is that description and, as a result, addressing that literal-mindedness directly.

We need a way to ground the coding agent in software development best practices, using a framework that encapsulates the steps needed to build reliable enterprise software. That’s the role of Spec Kit: to provide a way to first stand up a Git repository with the structure needed to manage coding agents, and then have a set of triggers deliver the next steps in the development process.

Using Spec Kit in Visual Studio Code

This tool works well in both Windows and Unix (and Unix-like) development environments, using PowerShell in Windows and Bash on Unix. I experimented with it using Windows Subsystem for Linux, as that would give me a chance to see how Spec Kit worked in a remote development environment. Beginning inside an Ubuntu WSL terminal, I first installed the Astral uv Python runtime environment using the Snap package manager.

Astral uv is a Rust-based Python project management tool that manages downloading packages and dependencies, as well as sets up and manages virtual environments. With it in place, I could use a provided script to download the latest version of Spec Kit and set up the required folder structure for a Spec-driven development, along with configuring my choice of coding agent, using GitHub Copilot inside Visual Studio Code. You can either run Spec Kit once, downloading, running, and discarding it once it’s set up the templates for your project, or you can install it for future use if you plan to make it a regular part of your development toolchain.

The command-line Specify tool is simple enough to run; choose a target directory and follow the steps. First, choose a target path, then pick your AI coding assistant. The tool will create folders and download the relevant templates. Once that’s done, it will display the key steps of a Spec-driven development, ready for use in your development tool of choice.

As I was using Visual Studio Code inside WSL, I launched its remote server using the code command, which updated the server to the latest version and then opened the Windows version, ready to make a remote connection to my WSL instance. Once I’d navigated to the correct folder, I could use the Spec-driven development commands from inside Visual Studio Code’s GitHub Copilot sidebar.

Hands on with Spec Kit

You can start by providing a specification prompt, but it’s sensible to begin with a constitution for your project. This is a high-level set of principles that define the approach the Copilot agent will take to building code, for example, ensuring that code will be tested and optimized for performance. These principles are best thought of as a codification of your development team’s existing architectural standards.

With a constitution in place, you can write the spec for your project, using /specify to start your prompt. This should be a detailed description of what needs to be built and why, looking at the entire stack being used to deliver your planned application from front end to back end. A spec isn’t fixed; as your project evolves, you can generate new requirements and user stories that help change the spec and trigger new development iterations.

You can now follow up by adding the technology stack you intend to use, in the shape of a /plan. This allows you to change elements of your stack, such as swapping out authentication methods or storage, allowing you to go from development to test to deployment. So, you could start with a basic SQLite implementation for development on your own PC, rebuild for MySQL on a test system, and then change to Azure SQL for deployment.

One important feature of Spec Kit is that the base system prompts are designed to minimize the risk of hallucinations. If a pass can’t implement a function, it will insert a [NEEDS CLARIFICATION] marker along with a question as part of the code so that the agent doesn’t make assumptions and requires specific intent. The base prompts include checking for this marker, ensuring that the system checks itself to avoid skipping over issues that have been flagged in earlier passes.

Once you have a spec and a plan, you can run the /tasks step. This (plus the constraints in the constitution) breaks up the project into a series of tasks: one for a front end, one for business logic, one for service interfaces, one for configuring and working with storage, and so on. Tasks themselves can be made up of subtasks, much like the project planning phase of the software development life cycle, as you work with project managers.

The last step is to run /implement. This will require multiple passes and, most likely, some manual intervention. The Copilot agent generates and checks code, including building and running tests using a test-driven development methodology. Grounding a tool in best practices makes a lot of sense; it ensures that Spec Kit and Copilot work with you, not on their own. You are the human in the loop, and you can take over whenever you want or sit back and make decisions when prompted by the agent.

Build an application with Spec Kit

Following these steps, I was able to go from a basic specification to a prototype application in a couple of hours, with code I’d have been happy to pass on to colleagues and that ran on my local WSL development system without any obvious issues.

Simon Bisson

Running the /implement command through Copilot showed some interesting behaviors. Even though the service writes code and sets up configurations, it won’t install all the necessary software for you, especially if it needs administrator access. The service will pause for you to complete actions in the terminal and wait for a manual restart when the necessary software has been installed. You will need both the Copilot pane and a terminal pane open to use Spec Kit.

Steps that take too long or that time out both require manual intervention, though this time in the Copilot pane. This isn’t a fire-and-forget tool; manual oversight is still necessary. You will be asked to approve Bash commands, for example, when running tests.

Some steps need to be run more than once, especially in the implementation phase. Specify uses a test-driven development methodology and needs to construct tests as well as code. Once tests have been implemented, the tool will create the necessary services for an application and give you the opportunity to use it from a local web server.

Should you use Spec Kit?

Spec-driven development with a coding agent isn’t as fast as vibe coding, but that’s not the point. Does it deliver better code that’s more suited to the enterprise? Yes, at least for common scenarios. You do need to have existing development skills, but a business analyst and an architect could put together a working prototype for a new application in an afternoon before passing it to a development team for refinement. That’s because the analyst and architect have skill sets that are most aligned with this methodology: Analysts are able to define a detailed specification and are in a position to refine the resulting prompt as part of an iterative, agile approach with new user stories and new use cases, and architects can define the target toolset, from front end to services and storage.

It’s important to note that the underlying prompts and the use of a project constitution provide strict constraints that reduce the risk of problems and make GitHub’s spec-driven development tool a useful part of your toolset—especially for prototyping and for upgrading your legacy applications. If you’re using Visual Studio Code and GitHub Copilot, it’s well worth giving Spec Kit a spin to see if it’s the AI pair programmer you need.