Write the spec first, then let an agent build to it. Tools like GitHub's Spec Kit turned this into a real workflow this year: a constitution, a spec, a plan, a task list, all markdown, all in the repo next to the code.
specs/account-deletion.md
The spec defines what the agent will build next.
Users can delete their account at any time. Users can delete their account after a 14 day grace period.
An agent edit, caught in review.
An agent can write the spec and the code that implements it. The code gets reviewed the normal way, in a diff, by whoever owns that part of the codebase. The spec is different. It is the one document where a human has to stand behind the decision itself, not just the syntax.
Today that spec usually lives in the same repo as the code, and gets reviewed the same way: a pull request, a diff view, an engineer's eyes. If the person who should approve the plan is a PM or a lead who does not live in pull requests, the spec either gets rubber-stamped or skipped.
A spec nobody actually read is not a spec. It is a plan the agent wrote to itself.
The toolkit that popularized spec, plan, and task files as first-class repo artifacts.
github.github.comDocumentation on the constitution and the spec, plan, and tasks flow.
developer.microsoft.comAn introduction to spec-driven development with Spec Kit.
scalablepath.comA look at the spec-driven workflow in practice.
Spec files sit in the same repo as code, so they get the same review tool by default: a code-diff UI built for reading changed lines, not changed meaning. A spec is prose. Reading a spec as a diff means reconstructing the sentence in your head before you can judge whether it says what you want.
Most people give up on that reconstruction and skim. The spec ships. The plan ships. The task list ships. Three documents nobody actually reviewed, upstream of every line of code that follows.
Point Stet at your specs/ folder and every agent edit to the constitution, a spec, a plan, or a task list shows up as a plain-English proposal you accept or reject, the same way you would review any other piece of writing.
Send a spec back with a note using AI notes instead of writing a comment thread the agent has to go find. And keep a full history of how a spec evolved from draft to approved, separate from the code's own git log.
Download the starter kit. It has a constitution template, spec/plan/task templates, and an empty src/ folder ready for implementation.
specs/ folder in Stet.specs/templates/spec.md and ask your agent to draft a spec for one small feature.