Three ways to brief a coding agent: spec, product model or fresh-eyes review

A coding agent that ships the wrong thing usually understood the request and misunderstood the product. The interesting question in late 2026 is no longer which agent to use but how you brief it, and three distinct answers have emerged. They differ on one thing: what you write down, and how long it lives.

Spec-driven: a document per change

The most adopted approach writes a spec for each feature, then a plan and a task list, and has the agent build against them. Spec Kit (4.3) is GitHub's version, with about 143,000 stars and a converge step that checks the implementation against the documents; it supports more than 40 named agents. BMAD-METHOD (3.8) covers similar ground with a cast of personas. The strength is that the contract lives in git and goes through pull requests like code. The cost is reading time: Scott Logic's published trial put human review at roughly two to three and a half hours per feature, which is why both tools ship lighter paths for small fixes.

Product-driven: one standing model

A newer school argues that a spec describes the change, not the product, so the product keeps being reconstructed from scratch. pdd-kit (3.7) keeps a single, git-tracked product model, entities, journeys, business rules and variations, that every agent reads instead of guessing, with a verify step that checks code against it. It is a sharper idea than a spec folder, but it is early: about 97 stars and a single maintainer, and a model that drifts behind the code misleads agents more than no model at all. It pays off on products with real domain complexity, and not on a CRUD app.

Review-first: let fresh eyes find the holes

The third approach accepts that the drafting agent will miss its own blind spots, and brings in a reviewer that never saw the conversation. Elephant-Goldfish Model (4.2), an open-source plugin from Google, drafts a design with a deep-context agent (the Elephant) and then hands it to zero-context subagents (the Goldfish) that read only the document and its cited sources. Because they cannot lean on the chat that produced the design, they surface the unstated assumptions. The method is well argued and already at about 6,500 stars; the catch is that it needs a harness that can spawn fresh subagents, and it stops rather than fakes a review where it cannot.

Where workflow packs fit

Alongside these sit general workflow installers such as Superpowers (4.7), which give an agent planning and self-check habits without prescribing a spec format. They compose with any of the three briefing styles rather than competing with them, and are the lowest-effort place to start.

Which to use

For a one-line fix, none of this: git, the tests and a short prompt that names the files win. For a feature that needs design decisions before code, review-first catches the most real bugs for the least writing, provided your agent supports subagents. For a regulated change that an auditor will read later, spec-driven's paper trail is the point. And for a complex product where agents keep reinventing the same rules, a product model earns its upkeep, if, and only if, someone keeps it current.