AI coding agents are getting very good at writing code.
The harder problem is increasingly controlling what they are supposed to build.
When a project uses specification-driven development, the workflow is no longer just:
Prompt → AI → Code
It becomes something closer to:
Specification
↓
Change proposal
↓
Design
↓
Tasks
↓
AI coding agent
↓
Implementation
↓
Validation
↓
Archive
This workflow works well from the command line, but as the number of changes, specifications, agents, and repositories grows, a CLI-only interface can become difficult to navigate.
That's the problem I wanted to solve with OpenSpec-UI.
What is OpenSpec-UI?
OpenSpec-UI is an open-source visual workspace for OpenSpec.
It provides a graphical way to work with:
- Changes
- Proposals
- Designs
- Specs
- Tasks
- Archived changes
- Templates
- Repository setup
- Validation workflows
It also provides an interface for launching AI coding agents directly from the same workspace.
The project currently supports:
- Claude CLI
- GitHub Copilot CLI
- Codex CLI
- Gemini CLI
- local LLMs through an OpenAI-compatible API
The important part is that OpenSpec-UI is not intended to replace OpenSpec.
It is a workspace around it.
Why build another UI?
OpenSpec already provides openspec view, which is useful for browsing specifications and changes.
So why build another interface?
There are several practical reasons.
1. Working with archived changes
One useful addition is the ability to inspect differences between versions of archived changes.
When a project has accumulated many changes, simply browsing the current state is not always enough. Sometimes you want to understand how a particular proposal evolved.
2. AI agents become part of the workflow
An increasingly common development workflow looks like this:
Create specification
↓
Review specification
↓
Create implementation tasks
↓
Start AI coding agent
↓
Agent modifies repository
↓
Run validation
↓
Review result
If the specification management tool and the coding agent are separate applications, developers constantly switch between terminals, editors and browser windows.
OpenSpec-UI puts these operations closer together.
3. VS Code integration
Many developers already spend most of their working day inside VS Code.
For that reason, OpenSpec-UI has two delivery modes:
OpenSpec-UI
│
┌──────────┴──────────┐
│ │
VS Code extension Standalone Web UI
│ │
native workbench local browser
Both use the same underlying core.
The VS Code extension provides native integration with the editor, while the standalone application is useful when a separate local web interface is preferable.
One core, two interfaces
One architectural decision was particularly important: the business logic should not be duplicated between the Web UI and the VS Code extension.
The repository is organized as a TypeScript monorepo with shared packages.
At a high level:
OpenSpec / Git / CLI Agents
│
▼
┌─────────────┐
│ Core │
│ │
│ OpenSpec │
│ parser │
│ Git │
│ security │
│ execution │
│ agents │
└──────┬──────┘
│
┌────────────┴────────────┐
│ │
▼ ▼
REST / WS Direct import
│ │
▼ ▼
Standalone Web UI VS Code Extension
The repository currently separates responsibilities into packages such as:
-
core— execution engine, OpenSpec parsing, Git integration, agent orchestration and security -
server— REST/WebSocket layer for the standalone application -
webui— shared React UI -
extension— VS Code integration -
cli— non-interactive CLI functionality for CI workflows
This allows the UI to remain relatively independent from the transport mechanism.
Running everything locally
Another design goal is that OpenSpec-UI should work as a local developer tool.
The standalone application runs locally and operates on the local repository.
The VS Code extension also works without requiring a remote OpenSpec-UI service.
A typical standalone setup is currently as simple as:
npm install
npm run build --workspace @openspec-ui/server
npm run start --workspace @openspec-ui/server -- <workspaceRoot> 4317
The server exposes a localhost URL containing a temporary access token.
This is useful for workflows where source code and specifications should remain on the developer's machine.
AI agents as an execution layer
One of the interesting parts of the project is the agent integration.
Instead of treating an AI coding agent as a completely separate tool, OpenSpec-UI treats it as an execution component of the specification workflow.
Conceptually:
OpenSpec Change
│
├── Proposal
├── Design
├── Spec
└── Tasks
│
▼
Agent Launcher
│
┌──────┼──────┬──────┐
▼ ▼ ▼ ▼
Claude Copilot Codex Gemini
This is deliberately designed around a command/event protocol rather than tightly coupling the application to one particular AI provider.
That makes it possible to use different agents for different tasks.
For example, a developer might use one agent for implementation and another for review.
What about local LLMs?
The project also supports a local LLM through an OpenAI-compatible API.
That means the execution layer does not have to be limited to hosted AI services.
This can be particularly useful for development environments where source code cannot be sent to external services or where developers already operate their own inference infrastructure.
The goal is not to build another LLM runtime.
The goal is to make the model or agent available as one of the execution options in the development workflow.
A specification-first workflow
The larger idea behind OpenSpec-UI is that AI coding does not have to start with a prompt.
A more structured workflow can be:
Human
│
▼
Define the change
│
▼
OpenSpec
│
┌───────────┼───────────┐
▼ ▼ ▼
Proposal Design Tasks
│ │ │
└───────────┼───────────┘
▼
AI Agent
│
▼
Codebase
│
▼
Validation
│
▼
Archive
The human remains responsible for defining and reviewing the intended change.
The AI agent becomes an implementation tool operating within that context.
This distinction becomes increasingly important as coding agents become more autonomous.
Why not just use an AI coding IDE?
Tools such as AI-enabled IDEs are very good at generating and modifying code.
But specification management is a slightly different problem.
An IDE answers questions such as:
What code should I edit?
A specification workflow also needs to answer:
What are we changing?
Why are we changing it?
What requirements does the change introduce?
What tasks are required?
What was changed previously?
What is the canonical specification?
These are different layers of the development process.
OpenSpec-UI is intended to sit between the specification layer and the coding-agent layer.
The project is still evolving
OpenSpec-UI is actively developed.
The current implementation already contains:
- standalone Web UI
- VS Code extension
- shared execution core
- OpenSpec integration
- Git integration
- AI agent orchestration
- archived change management
- Specs and Tasks views
- templates
- repository setup tools
- CLI functionality
- local execution
But the project is intentionally still evolving.
One of the reasons for publishing it publicly is to get feedback from developers who are experimenting with specification-driven development and AI coding agents.
There are still many questions worth exploring:
- How should agents and specifications interact?
- What should an AI-native development workbench look like?
- How much autonomy should an agent have?
- How should changes be reviewed before execution?
- How should multiple agents cooperate?
- What is the right UI for long-running agent workflows?
These are not completely solved problems yet.
Try it
The project is open source:
GitHub: https://github.com/VeryComplexAndLongName/OpenSpec-UI
If you are experimenting with OpenSpec, AI coding agents, or specification-driven development, I'd be interested in your feedback.
In particular, I'm interested in whether a visual workspace makes specification-driven AI development easier to manage than a CLI-only workflow.
Final thought
AI coding agents are rapidly improving at implementation.
That makes the specification and orchestration layer increasingly important.
The future workflow may not simply be:
Human → AI → Code
It may look more like:
Human
↓
Specification
↓
Change
↓
Agent
↓
Implementation
↓
Validation
↓
Human review
OpenSpec-UI is an experiment in building the workspace around that workflow.
The code is open, the architecture is visible, and contributions and feedback are welcome.
Top comments (0)