OpenSpec proposes a spec layer for AI coding, but the hard part is still the model

AI coding assistants produce unpredictable results when requirements live only in chat history. That is the problem Fission-AI’s OpenSpec sets out to solve. The project, released as an open-source npm package under the MIT license, adds a lightweight spec layer that sits between a developer’s intent and the code an assistant generates. The pitch is straightforward: agree on what to build before any code is written.

The idea is not new. Spec Kit from GitHub and AWS’s Kiro both attempt something similar. OpenSpec differentiates itself by claiming to be lighter, more fluid, and compatible with 20-plus AI assistants rather than locked into a single IDE or model. The project recommends Codex 5.5 and Opus 4.7 for both planning and implementation, and it works with pnpm, yarn, bun, and nix alongside npm.

OpenSpec introduces a set of slash commands that run inside a developer’s existing chat interface. /opsx:explore acts as a no-stakes thinking partner that reads the codebase and weighs options before anything is written. /opsx:propose generates a structured proposal folder with a proposal document, a specs directory, a design file, and a task checklist. /opsx:apply executes the tasks. /opsx:archive moves the completed change into an archive folder and updates the living specs.

The workflow mirrors what disciplined developers already do on paper. The difference is that OpenSpec formalizes the structure and makes it machine-readable. Each change gets its own folder. The spec persists beyond the chat session. The human and the AI align on a shared artifact before a single line of code is written.

This matters because the current crop of AI coding assistants treats each conversation as a fresh start. Context windows fill with back-and-forth corrections. Requirements drift. The assistant hallucinates implementation details that the developer never asked for. OpenSpec addresses the drift by freezing intent in a spec file that both parties can reference.

The project’s philosophy statement emphasizes fluidity over rigidity, iteration over waterfall, and ease over complexity. It is explicitly built for brownfield projects, not just greenfield ones. That is a practical choice. Most real-world development happens on existing codebases with existing constraints. A tool that only works from scratch is a toy.

OpenSpec’s comparison page is worth reading. It calls Spec Kit “thorough but heavyweight” with rigid phase gates and a Python setup. It calls Kiro “powerful but locked into their IDE and limited to Claude models.” The criticism is fair. Spec Kit requires a specific workflow. Kiro requires a specific ecosystem. OpenSpec bets that developers want a tool that fits into whatever stack they already have.

The bet is not guaranteed to pay off. OpenSpec adds a spec layer, but it cannot control what the AI does with that spec. The project recommends high-reasoning models for a reason. A weak model will produce weak specs and weaker implementation. The spec layer is only as good as the model interpreting it.

The project also collects anonymous usage telemetry by default. Command names and version numbers only, with no arguments, paths, content, or personally identifiable information. Telemetry is automatically disabled in CI. Developers can opt out by setting OPENSPEC_TELEMETRY=0 or DO_NOT_TRACK=1. The disclosure is transparent, but it is worth noting that a tool designed to capture intent is also capturing metadata about how that intent is expressed.

OpenSpec’s maintainers and advisors are listed in a separate MAINTAINERS.md file. The project accepts contributions, with small fixes submitted as direct PRs and larger changes routed through an OpenSpec change proposal first. AI-generated code is welcome as long as it is tested and verified, and PRs must mention the coding agent and model used.

The real question is whether spec-driven development for AI coding assistants will gain traction beyond the early adopter crowd. The developer tools space is littered with well-designed projects that never crossed the chasm from GitHub stars to daily use. OpenSpec has the advantage of being lightweight and tool-agnostic, but it still asks developers to adopt a new workflow on top of whatever they already use.

The project’s reliance on high-reasoning models is both its strength and its vulnerability. OpenSpec works best with models that can parse structured specs and generate coherent implementation plans. Those models exist today, but they are expensive to run and not universally available. A developer on a budget or in a region with limited API access may find that OpenSpec degrades gracefully but not usefully.

OpenSpec’s approach is a bet that the future of AI-assisted development includes a formal spec layer. That is a plausible future. The alternative is that AI models become good enough at inferring intent from context that explicit spec files feel redundant. Either outcome is possible. OpenSpec is betting on the former.

The project ships today as an npm package with documentation, examples, and a community Discord. It is worth trying on a brownfield project with a high-reasoning model. The results will tell you more about the state of AI coding assistants than about OpenSpec itself.