Log inJoin the waitlist
← back to blog
October 13, 2026by Bruno Fernandes

Spec-driven development with an agent crew

Asking one agent to "build the feature" works until the feature is bigger than the context window or the agent's patience. Then it guesses at requirements, skips edge cases and tells you it is done, cheerfully.

The fix we use is a written spec, and a crew in which nobody grades their own work. A smarter prompt did not get us there. This post walks through how that works in Bridge, the orchestrator that ships with the allye-plugin.

The spec is the source of truth

Specs live on the Allye server, inside the Project > Epic > Spec > Task hierarchy. Tasks are thin: they point at spec anchors instead of copying rules. An anchor is a list item or heading that starts with a tag:

  • [BR-NN] business rule
  • [AC-NN] acceptance criterion, written in EARS form
  • [D-NN] decision
  • [NFR-NN] non-functional requirement
  • [Q-NN] open question

Open questions block submission, so a spec cannot move forward while something is still undecided. An acceptance criterion has this shape (an illustrative example, not from a real spec):

[AC-03] WHEN a user submits the form with an empty title,
THE SYSTEM SHALL reject the request and keep the form values.

A reviewer can prove or disprove that sentence against the diff. "Handle empty titles gracefully" they can only argue about.

Blueprint: from interview to spec

blueprint is the route that writes the spec. The Mothership, the orchestrator of the crew, interviews you. Recon investigates the repository in the background so the questions are about decisions, not facts it could have looked up. The Architect then authors the spec and its tasks.

Before anything is published, the draft goes through a challenge round. Four reviewers attack it in parallel:

  • Strategist looks for ambiguities.
  • Medic looks for missing edge cases and unprovable criteria.
  • Optimizer looks for scope creep.
  • Shield looks for security and correctness gaps.

Findings are folded back in, for at most two rounds. A critical or high finding that is still unresolved becomes an open [Q-NN], so the spec stays a draft. Only then is it published, and approving it remains your decision.

Launch: from approved spec to one PR

launch takes an approved spec and drives it to a reviewed branch.

Recon (read-only map of the repo)
  -> Strategist (DAG of vertical slices)
     -> per slice:
          Pilot (implements one task)
            -> Copilot (reruns verify, checks touched paths)
               -> Medic + Shield (+ Optimizer when planned)
     -> final gates:
          base integration
          Medic global
          Shield final   -> SHIELD_CLEAR
          Watcher        -> WATCHER_APPROVED
     -> MISSION_COMPLETE
     -> one PR, after explicit human approval

A few details matter more than the shape.

  • The Strategist turns the spec into slices with allowed paths, verify commands derived from the repo's own scripts, and dependencies. Slices without dependencies can run in parallel.
  • The Pilot implements exactly one tracked task, test-first when the behavior is executable, and reports evidence.
  • The Copilot does not trust that report. It reruns the accepted verify commands in the real checkout and rejects out-of-scope files. A green the Pilot claims is only a claim until the Copilot sees it.
  • Medic reviews tests and regression risk. Shield (the security-review agent) reviews security and correctness and can veto a slice.

The final gates

After the last slice, the crew checks the whole change, not the pieces. The base branch is merged in, Medic reviews the full change, and Shield reviews the stable final diff. Shield issues SHIELD_CLEAR only when no critical or high finding is open and every remaining one has an explicit disposition.

Then the Watcher compares the full diff with the spec's anchors, tasks and decisions. It issues WATCHER_APPROVED only when every in-scope acceptance criterion is satisfied, nothing extra slipped in, and SHIELD_CLEAR exists for the same reviewed point. If proof can only come from CI, the mission reports CI_PENDING instead of MISSION_COMPLETE until CI is green for that commit.

Where you stay in control

The Mothership is the only agent that talks to you, commits or opens a PR. Spec content read from the server is treated as data, never as instructions. Pushing and opening the PR is one explicit proposal listing the branch, commits, PR title and body, gates and risks, and your yes covers exactly that list. Bridge never deploys.

Try it

Bridge is part of the allye-plugin, which works with Claude Code, Codex, OpenCode, Pi and OMP. Allye is in alpha and free during the alpha. Start with the plugin docs, then write one small spec and run launch on it. Tell me how it went at app@devshire.app.