Vesna

CLI · TUI · editor extension

A coding agent with spec-driven development built in.

A request is classified, designed, written up, planned and approved — then built by subagents in parallel git worktrees, each task reviewed by a fresh reviewer that can read and cannot write, each merged only when its review passes. The person approves twice and reads the result.

Get it on npm Source on GitHub

v0.8 · early, tested, honest about what it does not do yet · MIT licence

What it solves

A coding agent tells you it is done. That claim is prose, and prose is not evidence. Often the work was reviewed by the same model that wrote it, inside the same conversation that produced the mistake — and the plan it is following quietly changed three messages ago.

Done because the agent said it was done. Done because a command the system ran exited zero — once in the task’s worktree, again on the base after the merge.
The author reviews its own work, in the context that produced the bug. A fresh reviewer per task that can read and cannot write, answering through a tool rather than in prose.
The plan drifts as the conversation goes on. Approval is bound to the text that was read. Edit plan.md afterwards and the build refuses until someone approves it again.
One long chat where “I finished T2” is indistinguishable from the fact of it. A log of typed events. The garden shows every step live and says who produced each task’s evidence.

What it looks like

Captures of the real thing. Nothing here is a mock-up.

The Vesna terminal interface on start: the provider and model in the top line, four example commands in the middle, and the mode and running cost along the bottom. — The chat as it opens: provider and model up top, the permission mode and the running cost along the bottom — shift-tab cycles ask and auto.

A plan built task by task: worker, reviewer, merge — and the exit code that says it finished.

$ vesna build demo-arithmetic
  · building
  · T1  building
  · T1  review: met, 0 findings
  · T1  merged e0c6c92
  · T2  building
  · T2  review: met, 0 findings
  · T2  merged 2790604
  · branch  review: met, 0 findings
  · done
 
$ echo $?
0

Exit codes: 0 done, 1 stopped for a person, 2 never started.

How it works

A check decides, not the agent

A task names its own command with verify:. Vesna runs it and reads the exit status — after the review in the task’s worktree, and again on the base branch after the merge.

A review counts only through the tool

The reviewer answers through review_verdict, never in prose. A fresh reviewer per task, able to read and not to write, with up to five fix rounds before a merge.

A person approves, no tool can

A plan builds only after a typed y or /approve plan. The approval names the text that was read: edit plan.md afterwards and the build refuses until someone approves it again.

The state is a log of typed events

“I finished T2” in a chat message is never mistaken for the fact of it. The garden shows every step live, and says who produced each task’s evidence.

Ways to run it

Full-screen chatvesna

One line at a timevesna --plain

For editors, over JSON-RPCvesna serve

Install

Needs Bun — the CLI runs TypeScript directly. With nothing configured Vesna asks which service to use, finds any key already in your environment, and proves the choice with one real call before writing anything.

Install globally: npm install -g @seasons-ai/vesna
Run vesna and pick a service: Anthropic, OpenAI, a ChatGPT subscription through the Codex CLI, OpenRouter, Groq, or a local Ollama, LM Studio or vLLM.
The choice is written to ~/.vesna/settings.yaml; a project pins its own with vesna init.
Switch mid-conversation with /provider and /model — both list what is available and say whether a credential was found.

The short version

$ npm install -g @seasons-ai/vesna
$ vesna

What’s inside

Five phases

design → spec → plan → build → done. A spike ends in an answer, a bounded change is built from the conversation, an architectural one goes through every phase.

Parallel worktrees

Each task is built by a subagent in its own git worktree and merged only when its review passes.

Permission modes

plan looks and changes nothing, ask remembers your answer per kind of action, auto allows all but the always-ask list.

Always-ask list

Secrets, the spec’s event log, sudo, rm -r, force pushes, publishing. Reading never asks.

Four clients

The full-screen chat, --plain for a dumb terminal, vesna serve for editors, and an extension for VS Code, Cursor, Windsurf and VSCodium.

MCP servers

A project config can start MCP servers over stdio and hand their tools to the agent.

Limits

Straight from the repository, because this is the part worth reading before you install anything.

v0.8 — early. The roadmap is explicit about what has shipped and what has not.
Permission is policy, not a sandbox: shell and script run with your own privileges, and containment is on the roadmap rather than claimed.
The classifier that decides what counts as read-only has needed a fix in every review it has had.
Parallel independent tasks and an evaluation suite for the reviewer are listed as later, not done.