Why DevSpec

Stop engineering the harness.

Every AI coding agent needs a harness — the memory, context, tools, and feedback loops that turn a clever autocomplete into a teammate that ships. With a standalone editor you build that harness by hand and maintain it forever. DevSpec is the harness, managed for you.

Session 23 · payments-apiMemory recall

Why don't we verify webhook signatures inline? Feels wrong.

You and Tom decided this on 12 May — inline verification blocked the worker pool under load, so verification moved out-of-band. The trade-off is recorded; the constraint was p95 latency, not security. If the load profile has changed, it's worth revisiting — but that's the history.

decision
Webhook signatures verify out-of-bandRecorded 12 May · session 14 · confidence 0.9

— the living memory your agent reads from. No rule file required.

01The Problem

You're already doing harness engineering

The developer and writer Addy Osmani put a name to it: agent harness engineering. A coding agent is only as good as the scaffolding around it — its memory, its tools, its context, its sandbox, and its feedback loops.

Standalone editors hand you the agent and leave the harness to you. So you build it by hand: rule files to explain the architecture, a custom MCP server to reach your tracker, an onboarding prompt to re-orient an agent that forgot everything overnight. It works — until the project moves and the whole rig needs re-engineering.

You spend twenty minutes re-authenticating an MCP token and re-pasting yesterday's context before the agent writes a single line. The harness took longer than the work.

02The DIY Harness

What you maintain by hand

Four standing chores stand between a standalone agent and a working AI workflow — and none of them are the actual product work.

01

Rule files that rot

You write .cursorrules, CLAUDE.md, or AGENTS.md files to tell the agent how the codebase works. The moment the architecture moves, those files go stale — the community even has a name for it: context rot.

The agent confidently follows a convention you abandoned three weeks ago.

02

MCP servers as duct tape

To get tickets in front of the agent, you stand up a custom MCP server bridging the editor to Jira, Linear, or Confluence. It is a fragile middle-layer you now own, host, and debug.

One upstream API change, and the bridge you built quietly stops returning tasks.

03

Auth and endpoints that churn

MCP tokens expire, so you re-authenticate constantly. Endpoints change and the connection silently breaks, and you are back in the config files instead of building.

Monday morning is a re-auth ritual before any real work begins.

04

Sessions with amnesia

Open a new terminal and the agent has forgotten the plan. You keep complex onboarding prompts on hand just to re-explain yesterday before it can do anything today.

Every session starts by re-teaching the agent what it already knew.

03The Landscape

Everyone else bridges two systems

The market split the agent and the plan into separate tools, then taped them back together. Four flavours of the same gap:

Local-first hacks

Tickets as markdown files

Tools like Centy and Beads save issues as files in the repo so a terminal agent can read them. It works in one repo, on one machine — until you need a teammate, a tester, or a second project to see the same plan.

Agent platforms

Execution without the plan

OpenHands, AutoForge and the cloud-VPC agent runners execute code well, but they don’t hold the human planning. They still depend on requirements written and maintained somewhere else entirely.

Legacy adapters

AI bolted onto a board

Linear and Jira are adding MCP servers to expose their tickets to agents. But they were built for humans filing tickets, not for a native human-and-agent loop — the agent is still a guest in someone else’s system.

Multiplayer chatbots

Engagement without a Lifecycle

Tools like Claude Tag pull AI into shared chat, but they don’t solve the AI-Driven Development Lifecycle (ADLC). You are still left engineering the harness to manage task states, Git branches, and verification loops. Without a structured system of record, your engineering workflow is just abandoned in a sprawling chat stream.

04The Managed Harness

DevSpec is the harness

The same scaffolding, provided and maintained for you. You brainstorm; DevSpec streams the rest.

The Shared Brain replaces the rule file

Your brainstorms, decisions, and conventions live in DevSpec and stream to the agent the moment it picks up an item. There is no rule file to write or keep current — the agent reads the living project memory directly, and it cannot go stale.

Session 23 · payments-apiMemory recall

Why don't we verify webhook signatures inline? Feels wrong.

You and Tom decided this on 12 May — inline verification blocked the worker pool under load, so verification moved out-of-band. The trade-off is recorded; the constraint was p95 latency, not security. If the load profile has changed, it's worth revisiting — but that's the history.

decision
Webhook signatures verify out-of-bandRecorded 12 May · session 14 · confidence 0.9

The context the agent reads — current by construction.

One bridge, and we maintain it

The agent connects over a single managed MCP endpoint. No custom server to host, no adapter to debug, no token to re-authenticate every morning, no endpoint that breaks when something upstream changes. The plumbing is ours, not yours.

Autopilot — queue2 runners active
#214

Exponential backoff for Stripe webhook retries

runner mini-pc-01 · worktree wt-3f2a

implementing
#209

Empty state for the deployments page

pushed · [devspec:209] → staging

deployed
#216

Rate-limit headers on the public API

staged behind #214 — shares lib/api/middleware.ts

staged

Work reaches the agent over a connection you never touch.

The loop does not forget

Every session inherits the full record — what was decided, what shipped, what is left. A new terminal is not a blank slate, and the tester who picks the work up afterwards gets the exact context the agent had, automatically.

payments-api — team session

Ali, Priya, Tom + DevSpec

3 online

Priya

Stripe webhooks keep timing out on retries. Can we just stage a fix for the backoff and get it out today?

The retry loop is in lib/payments/webhooks.ts:42— fixed 2s delay, no jitter. You decided in May that webhooks verify out-of-band, so the fix is safe to stage. I've written the acceptance criteria; rush it to the top?

#214
Exponential backoff for Stripe webhook retries3 acceptance criteria · staged for Autopilot
staged
22 minutes later

Done. Pushed as [devspec:214], deployed to staging, and the AI test walked all three criteria — passing, on video. Want the link?

Yesterday’s context, already loaded.

Swarms without the mess

Everyone can run five agents at once; the hard part is knowing which five pieces of work won’t collide. DevSpec predicts the files each item will touch and keeps a live map of overlaps and dependencies, so Parallel Mode shows you — before anything runs — which work is safe to launch together, autopilot or supervised. Anything it can’t verify is marked unknown, never assumed safe.

Autopilot — queue2 runners active
#214

Exponential backoff for Stripe webhook retries

runner mini-pc-01 · worktree wt-3f2a

implementing
#209

Empty state for the deployments page

pushed · [devspec:209] → staging

deployed
#216

Rate-limit headers on the public API

staged behind #214 — shares lib/api/middleware.ts

staged

A swarm assembled from work that provably cannot collide.

05The Methodology

Built for the AI-DLC

AWS calls the successor to the old sprint-based SDLC the AI-Driven Development Lifecycle: the AI orchestrates and executes, the human sets intent and validates. DevSpec is built for exactly that loop.

Phase 01

Inception

The brainstorm, the decisions, and the action items with acceptance criteria — captured natively as you talk. This is the phase every other stack makes you do in a separate app.

Phase 02

Construction

Action items flow straight to coding agents on your machines over the maintained MCP bridge. They inherit the full intent, implement in isolated worktrees, and report back — one agent, or a swarm of them running work DevSpec knows cannot collide.

Phase 03

Operations

Deployments link back to the work that caused them, AI verification walks the acceptance criteria on the live app, and failures return as new items. The loop closes.

In the AI-DLC the human stops hand-writing code and starts validating it — defining intent, setting the guardrails, and approving what the agent ships. DevSpec is the first platform purpose-built for that reversal: Inception and Construction run on the same system, so context never has to be rebuilt between them, and the human stays in the loop as the validator, not the typist.

06Yours to extend

A loop you can build on

We've distilled what it takes to get real work out of AI into one fundamental loop — brainstorm together, recall the context, do the work, test and validate it, write back what was learned, and compound it next time. That loop is the foundation: every decision, plan, and outcome is captured, stored, and fed back as context. Everything becomes context. Nothing is lost. It's also open.

That openness is the point — there's no single way to build on the loop. You fold in whatever your work demands: a compliance gate the agent has to clear, your own design system, the incident history it should read before touching production. Memory is one example. Run a local server like MemPalace, tell your agent to recall from it before it acts, and every session draws on bothDevSpec's shared brain and a private memory that spans all your work — exactly how we build on the loop ourselves. We give you the loop that makes AI effective. You shape it into the loop that's yours.

DevSpec

Stop building the harness. Start shipping.

Connect your repo, start a session, and let DevSpec stream the context your agents need. The harness is on us.

Start Your Project

14-day free trial · 1,500 credits included