Drift: the spec is the desired state, the code is the actual state

Systems built one shot at a time degrade

Most new code is now written by agents, and a growing share of it is reviewed by agents too. The pattern is familiar: an engineer writes an architecture document or a spec, hands it over, and the agent builds it. The first pass usually lands; you ask for a service and get a working service, often the same afternoon. The trouble shows up months later, in a system that has absorbed hundreds of those passes. A change that should take a day takes a week, because the code is organized around decisions no one remembers making. The agent made them, for reasons that were sound inside a context window that is long gone. Then someone in a planning meeting asks a plain question: does checkout do what we said it does? And the room goes quiet.

Drift is our answer to that failure, and it rests on one sentence, printed under the board title: the spec is the desired state; the code is the actual state. The vocabulary comes from control systems. You declare the state you want, you measure the state you have, and the difference between them is the work. In the demo, the Code layer’s header reads 92% in sync, 2 gaps, 2 building (every number on these screens is demo data; what matters is that the distance between promise and behavior appears as a measured figure at all). When the spec promises something the code doesn’t do, the gap surfaces on its own, before anyone has to notice it, write a ticket, and groom it forever after.

To be plain about what Drift is: an interactive prototype from one of our design sprints, exploring a problem we kept hearing about. No part of it is running for customers. The tools we plan with today assume the scarce thing is coding time; once agents write the code, the scarce thing is a durable record of what the software is supposed to be, and why. First we show the three layers the board holds, then the graph that sits between the target and main, then how the loop closes from main back into planning.

Three layers: Vision, Spec, and Code

The board holds three layers. Vision is direction that hasn’t been committed yet, a holding pen for ideas. Spec is the contract: in the demo, 6 capabilities and 17 shall-statements, one file per capability, each shall written to be testable.

WHEN the user submits an expired card, THE SYSTEM SHALL retry authorization once, then surface a decline message that names the reason.

Code is whatever main currently does, owned by the agents pulling it toward the spec. Ideas must be promoted from Vision into Spec before they bind anything, so aspiration and commitment stay separate. The spec describes observable behavior and product-level constraints while staying out of implementation, and every spec PR is linted for that leakage, so the code layer keeps the freedom to satisfy each promise however it can.

The spec-first half of this is now common practice, and the strongest versions of it are worth naming. GitHub’s Spec Kit treats the specification as the source of truth and moves agent work through specification, plan, tasks, and implementation, ending each feature with a convergence check against the spec [1]. AWS’s Kiro IDE writes acceptance criteria in EARS notation, the same WHEN/SHALL shape as the statement above [2]. Both run the loop per feature. Drift’s difference is the standing version: the whole of main measured against the whole contract on a schedule, with the drift filed back as ordered work and every change carrying its decision record.

The graph carries the ordering and the reasoning

Here is where the sprint pushed past the obvious version. A backlog is a list, and a list carries almost none of the knowledge that makes a system buildable over time: what has to exist before what, which changes belong together, and why this is the next thing to build. The tools teams actually plan in confirm the shape. In Jira, a “blocks” link between two issues is a label for the viewer; Jira itself does not stop work on the blocked issue or schedule anything around the link [3]. The ordering lives in someone’s head, and the ticket records the what while the why stays in a meeting nobody minuted.

In Drift, the work between the target and main is a graph. The unit is a spec PR, a reviewable change to the contract, and spec PRs stack: DR-208 (“Surface saved-card expiry before checkout”) depends on DR-207 (“Retry expired-card authorization once before declining”) and stays parked until its parent lands. The ordering is part of the plan, recorded in the graph rather than remembered.

Each node also carries its discussion, and this is the part we came to think matters most. A grilling agent opens DR-207 from the vision slice it traces to (“fewer false declines”), reads the current spec and the running behavior, and posts three genuinely different ways the retry could work, each with a trade-off and a recommendation. Then it splits the open questions into decision threads, each routed to the person who owns that capability. The discussion is where the why gets captured, and that record is exactly the thing whose absence makes a year-old, agent-built system unexplainable.

The flow model (schematic). The product team tends the target and the ordering; agents execute the graph branch by branch; drift on main flows back in as new work.

The loop closes from main

An item becomes ready when its dependencies have merged and its decision threads are resolved, and that readiness is enforced the way engineers already trust: as status checks. DR-207 shows 2 threads block merge; its decisions-resolved check reads 1 of 3, so the contract can’t change yet. Once it can, a coding agent picks the item up, opens a branch, builds against the shall-statements, and merges when the checks pass. Every branch traces to a spec PR, and every spec PR traces to a vision slice, so work done ties back to work expected.

The review surface earns its keep when owners disagree. On DR-207, the payments owner wants the retry to cover one-click checkout with a saved card, so customers see consistent behavior. The security owner objects: an expired saved card is a stale-credential signal, and silently retrying weakens it. Both positions are reasonable, and the design holds them on screen and waits for a human with authority to pick. It would be easy for an agent to average the two into something confident-sounding; the prototype treats that as the failure case.

The loop closes from the other side too. A Drift suggests panel reports what scheduled checks find on main: behavior the contract never promised (an order-shipped SMS with no matching shall, its reconciling PR already drafted), a regression against a shall in the cart spec, and a spec file 40 days quiet while vision moved on. Each gets its own verb (review the drafted PR, open a fix task, open planning) because those three failures deserve different responses, and a person chooses which way each one gets closed.

Humans tend intent; the agents do the code

Every planning tool you can buy is built for a team that will write the code by hand, so its artifacts are proxies for that labor: tickets, estimates, story points, sprint boards, all of it bookkeeping about work a person is about to do. Drift assumes the code is the agents’ job and rebuilds planning around what’s left for the humans. They tend the spec, argue the decision threads, and order the graph, while coding agents pull main toward the target branch by branch. Waterfall assumed you could define everything up front and be right. Sprints assumed the scarce resource was human coding time, so work had to be batched into a cadence a team could absorb. With agents writing and reviewing the code, both assumptions are gone, and work can flow continuously. During the sprint we started calling this shape the flow model, and the product name comes from the same picture: drift is the force out ahead of an object in a moving stream, pulling it along.

Two design choices only make sense once the human supervises the build rather than doing it. The screen’s central figure is a measured gap between what the spec promised and what the code does, because a supervisor’s first question is whether the work is drifting from what was asked, and a model can now read a prose shall-statement against running behavior and say whether they agree. And the agents open the conversations: the grilling agent brings owners three options and a recommendation, and the Drift-suggests panel arrives with reconciling work already drafted. The supervisor’s judgment is the scarce input, so the interface is built to collect it: a decision arrives with options, evidence, and a recommendation, and merge stays blocked until someone renders it.

Two things follow

The first is the planning-meeting question this piece opened with. In a flow model, “does checkout do what we said it does?” has a number for an answer; in the demo that answer is 92%, with the two gaps named and their reconciling work already on the board.

The second is about who decides what. Architecture stays engineering’s call: schema design, queue choices, and caching strategy belong to the code layer, and no product document dictates them in this design. Each of those decisions serves a need the product side can name (the cache exists because checkout has a latency budget, and the latency budget exists because abandonment costs revenue), so the spec captures the need in the discussion and leaves the how to the code layer. When an architecture upgrade comes due, the agent’s instructions are that discussion: what must stay true, who it’s for, what it must not break.

Drift remains a design prototype; nothing here is running for customers. It belongs to the same argument as the rest of our gallery, that the useful move with agentic AI is to design software around what agents can do, which is the case we make in the bespoke SaaS post. If your team plans software for a living, try the question on your own backlog this week: for each ticket, could you say which promise in a spec it serves? Where you can’t, that missing record is the thing Drift is designed to keep.