【第1回】Cursor × SpecKitではじめる仕様駆動開発（導入編）～AIと一緒にTerraform開発を始めてみた～ This first installment introduces specification-driven development using Cursor and SpecKi…

Specification-driven development, sometimes shortened to SDD, is gaining attention as teams look for ways to make AI coding assistants more reliable and consistent. This first article in a series demonstrates how the Cursor editor can be paired with SpecKit to apply that approach to Terraform, the widely used Infrastructure as Code tool, with the goal of improving both the quality and the consistency of infrastructure definitions.

The core idea behind specification-driven development is to treat a written specification, rather than ad hoc prompting, as the starting point for implementation. In everyday AI-assisted coding, a developer often types a short instruction and accepts whatever the model produces, a style sometimes described informally as "vibe coding." That can work for small tasks, but it tends to produce inconsistent results and makes intent hard to trace. SDD instead asks the developer to first articulate what the system should do and why, then let the AI generate a plan and code that follow from that agreed specification. The specification becomes a durable artifact that can be reviewed, versioned, and refined.

SpecKit is an open-source toolkit associated with GitHub that provides structure for this workflow. Rather than leaving the process to improvisation, it introduces a sequence of phases, typically guided by commands such as specify, plan, and tasks. The specify step captures the requirements and desired behavior in a structured document. The plan step turns that into a technical approach, and the tasks step breaks the work into discrete, actionable units that an AI agent can implement one at a time. Because SpecKit is designed to be agent-agnostic, it can be driven from several assistants, including Cursor, and this makes it a natural companion for editors that already embed a model into the coding loop.

Cursor is an AI-centered code editor built on a fork of Visual Studio Code, so it retains a familiar interface while adding chat, inline edits, and agent features that can read and modify files across a project. Its ability to keep the whole repository in context is useful for a spec-first flow, because the model can refer back to the specification and generated plan while writing code. In the Terraform setting described here, that means the AI can be pointed at specification files and asked to produce or adjust the corresponding resource definitions, provider configuration, and variables.

Terraform is a fitting target for this method. As declarative Infrastructure as Code, it describes the desired end state of cloud resources in HCL, and small errors can have outsized consequences when applied to real environments. A spec-first process appears well suited to this domain because the human-readable specification maps closely to the declarative nature of the code, and because the plan and tasks phases give reviewers a chance to catch mistakes before anything is provisioned. The article frames this as a way to raise consistency across an infrastructure codebase, which is often maintained by multiple engineers over time.

For readers new to these concepts, a few prerequisites are worth noting. Familiarity with Terraform basics, such as providers, resources, state, and the plan and apply cycle, will make the workflow easier to follow. Some comfort with Git is also helpful, since specifications and generated code are meant to be committed and reviewed like any other source. Beyond SpecKit, the broader landscape includes other agentic coding tools such as Claude Code, GitHub Copilot's agent features, and Aider, all of which reflect an industry shift from single-shot code completion toward multi-step, plan-driven automation. SpecKit's contribution is less about the model itself and more about imposing a repeatable structure around it.

It is reasonable to be measured about the benefits. A spec-driven approach adds upfront effort, and the quality of the output still depends on the underlying model and the clarity of the specification. Generated Terraform should always be reviewed, and running terraform plan against a non-production environment remains essential before applying changes. Still, for teams already using Cursor, combining it with SpecKit is a low-friction way to experiment with a more disciplined workflow. As an introductory installment, this piece sets up the tooling and the rationale; subsequent articles in the series are likely to walk through concrete examples of specifying, planning, and implementing Terraform configurations in practice.