spec-editor Autonomic is in early access. Request access

The software development lifecycle, run by AI agents

Code got cheap. Knowing what to build did not.

spec-editor is a system for building and maintaining software with AI agents. The requirements live as a model in the repository next to the code: every requirement has an address, points at the code that implements it and carries the check that proves it. A team of agents writes the code, tests it, deploys it and watches it run.

Get startedView on GitHubHow it works
curl -sSL https://raw.githubusercontent.com/spec-editor/spec-editor/main/install.sh | bash -s -- --dev

Open core, Apache-2.0. Installs from the GitHub repository.

aspects/user_interface/SCR-004/REQ-EXAMPLE-12.md

REQ-EXAMPLE-12 Password reset form

reviewed

acceptance: 3 criteria

  • AC-1Deterministic

    Run the command: npm test -- password-reset. Expected: exit code 0, and the test "expired link is rejected" is listed as passed.

  • AC-2Judged

    A judge reads the rendered confirmation text and checks that it never reveals whether the e-mail address has an account. Evidence named: the rendered page text.

  • AC-3Seen

    Marked for a visual check: in the screenshot of the form, the error message sits next to the field it refers to and is readable.

Illustrative example, not a requirement of spec-editor.

Example

A requirement that can check itself

The proof travels with the requirement. This one is invented, to show the shape.

Deterministic criteria are a command and its expected result. Judged criteria are read by a judge against a stated expectation, with the evidence named; Seen criteria are marked for a visual check of a screenshot.

The gap

Five questions an agent needs answered

Question 1

Does a requirement have a stable address?

Each requirement is one Markdown file with an id, a type, a parent and a status. Files nest by parent, so the folder tree is the tree of the system.

Question 2

Is the system described as it is now?

The model describes the system as it is now. History stays in git and in the journal, not in the requirement.

Question 3

Is a requirement linked to code, both ways?

Code carries @implements markers. spec-editor validate checks the model and the links between model and code.

Question 4

Can acceptance be executed?

Acceptance criteria live inside the requirement, as a command with an expected result or a check by a judge with the evidence named.

Question 5

Is it known what the system actually did?

Code marked with an element writes operation events. The run-time trace map shows which requirements actually ran.

Agentic engineering

Agentic engineering, not faster vibe coding

Vibe coding gets you code. Agentic engineering gets you code you can account for: the specification it satisfies, who checked it, and what it did once it ran.

The specification it satisfies

Every change answers to a requirement in the model, with an address and acceptance criteria. The specification belongs to the system, not to one task.

Who checked it

The acceptance criteria run as commands or judged checks, not as the agent's own report. With Autonomic, review stages decide by evidence and ask a person where evidence is missing.

What it did

Code marked with a requirement writes operation events, and the run-time trace map shows which requirements actually ran.

How spec-editor compares with coding agents and vibe coding

Path

The path of one requirement

The open core gives you the model, validation, links to code, export and the interface. The steps marked Autonomic add the delivery team.

  1. 01

    A source arrives

    A document, a bug, an incident or an idea. Channels in the open core: Jira, GitHub Issues, Slack, Discord and Telegram.

  2. 02

    Analysts turn it into requirements Autonomic

    Analysts work on a source independently, a second pass reconciles their results, and the result is checked against the source.

  3. 03

    The requirement enters the model

    One Markdown file with a status and its acceptance criteria. The model is checked by spec-editor validate.

  4. 04

    Review stages decide by evidence Autonomic

    Risk classes A to D. A human is asked only where evidence is missing.

  5. 05

    Code is written and linked

    Code carries @implements markers back to the requirement. With Autonomic, a coder and a tester do this work.

  6. 06

    Acceptance runs on a test stand Autonomic

    Every plan is deployed to a test stand and its criteria are run there before promotion. Rollback exists.

  7. 07

    Run-time events come back

    Code marked with an element writes operation events, and the run-time trace map shows which requirements actually ran.

Alternatives

Where other tools stop

Six families of tools stand between an idea and working software. Each is good at something, and each stops somewhere. Products are named only as examples of a family.

spec-editor is more than memory for agents. It is a system for writing and maintaining software: the whole SDLC, from the requirement to the running product.

  1. Requirements

    The system described as it is now, with the acceptance written into each requirement.

  2. CodeAutonomic

    A coder writes it against the requirement and links it back with @implements.

  3. IntegrationAutonomic

    Every agent works on its own branch. Finished work lands through a merge queue, one change at a time.

  4. Visual testingAutonomic

    A tester runs the acceptance on a test stand and checks every screen by screenshot.

  5. Debugging

    The log follows the tree of requirements. Turn up the detail for one element and see what it did.

  6. DeploymentAutonomic

    Devops builds, deploys to a blue/green stand, promotes and rolls back.

  7. MonitoringAutonomic

    Repeating errors in the logs become incidents, and an on-duty role sends them back as sources.

The model, the links to code and the logging are in the open core. The delivery team comes with spec-editor Autonomic.

Six families of tools: what each does well, where it stops, and what spec-editor does instead
ItemWhat it does wellWhere it stopsWhat spec-editor does instead
Requirements management systemsDOORS Next, JamaIds, statuses and traces to tests. Long use in regulated work; vendors now expose requirements to agents.The model usually lives in a system apart from the code, and it describes what should be, not what ran.Keeps the model in the repository as files, and links requirements to code and to run-time events.
Trackers and wikisJira, Confluence, NotionThe common home of requirements; agents can be assigned a ticket.A ticket describes a change. When it closes, the system as it is now is not written down.Describes the system as it is now; a Jira or GitHub Issues item arrives as a source.
Instruction filesAGENTS.md, CLAUDE.mdPlain text the agent reads first. Simple and portable.Prose without structure, with no status, no test and no address for one requirement.Serves an agent only the elements it needs, over MCP, instead of one growing file.
Spec kitsSpec Kit, Kiro, OpenSpecPuts the spec before the code: requirements, design, tasks.The spec is a plan for one feature, and acceptance is often a checklist that the same agent ticks.Keeps one model for the whole system, with acceptance written into each requirement.
Agent memoryMem0, Hindsight, ZepThe agent recalls what was said across sessions.Memory of a conversation is not a description of a system: no status, no test, no link to code.Stores the system itself as addressable elements that you can read, review and diff in git. Then it builds, tests, deploys and watches that system.
Autonomous coding agentsDevin, Factory, CodexCarry one task from a description to a pull request.A task goes in and code comes out. What was learned about the system is not kept for the next task.Many agents in parallel on one codebase, merged in order, built, tested and released as one product. The model of the system stays after the task is done.

Read the articles How spec-editor compares with agent memory

Editions

Open core and Autonomic

Apache-2.0

Open core

The model, validation, links to code, export, the command line, the MCP server and the web interface. Free, installed from GitHub.

Early access

spec-editor Autonomic

A plugin that adds the delivery team: analysts, coordinators, a coder, a tester and devops. GitHub Runner compatible: it runs on-premise on your existing GitHub, GitLab or Gitea infrastructure. Purchase is not open yet; you can request early access.

How we work

Built with itself

spec-editor is developed with its own pipeline: its features went through source, analysis, plan, code, check and release. It runs on your own subscriptions or tokens; we do not sell tokens, and your code is not sent to us.

See the numbers on the stats pageread the articles