A brief and a spec are not the same thing.
We had a moment, early on, that I think a lot of teams are having right now.
An engineer picked up a task on a Monday morning. By Monday afternoon the code was written. By Tuesday it was reviewed and merged. By Wednesday the PM was in standup asking what had actually shipped, because the PR description didn't quite match what she'd understood the task to be.
The feature worked. The tests passed. It was just... not entirely what the designer had specified, and not entirely what the PM had meant when she'd written the brief, and the engineer — reasonably — had bridged the gap the only way available to them, which was to make a call.
Nobody had done anything wrong. The brief was ambiguous in the usual ways briefs are ambiguous. In the old timeline, that ambiguity would have surfaced during implementation — an engineer would have got stuck, or asked a question, or pushed the PR back because something didn't add up. The human in the loop was slow enough that there was time to catch it.
The AI wasn't slow. It made the call and kept going.
I've come to think that speed is doing something specific to how teams break down.
The coordination mechanisms we've built up — design reviews, PM sign-offs, spec walkthroughs, even just the informal "do you have five minutes" conversation — exist because implementation is slow. Slow enough that you can run a checkpoint before the code is committed. Slow enough that changing course is annoying but not catastrophic.
When implementation compresses to hours, those checkpoints become either blockers or skipped steps. If you run them, you slow the AI down to human speed and lose most of the gain. If you skip them, you're shipping fast but without anyone having actually agreed on what was built.
Most teams I've talked to have landed somewhere in the middle, which usually means: the checkpoints happen, but they happen after the fact, when everyone's looking at something already built and merged.
The thing I keep noticing is that "we discussed this" and "we had a spec" feel like the same thing but they're not.
A brief is intent. It's the what and the why, usually written for a product audience, often under-specified in exactly the ways that matter for implementation — the conditions, the edge cases, the explicit exclusions that tell an AI agent where to stop.
A spec is executable intent. It's what you get when someone has translated the brief into something concrete enough that there's only one reasonable interpretation of it. What does done look like? What can it not do? What constraints apply? Who decided what?
The gap between them is where the coordination failure lives. The PM thinks the spec conversation happened because there was a brief. The engineer thinks it happened because the brief seemed clear. The AI doesn't know there was a gap at all — it builds against whatever it was given, confidently.
The pattern we landed on was simple enough in principle and harder in practice: the spec gets written before the build starts. Not by the engineer alone, not by the PM alone — together, in the same document, before anyone opens a terminal.
The designer writes expected results. The PM sets conditions. The lead draws the boundaries. And then — only then — the AI agent gets the spec as its input.
What that does, structurally, is move the alignment conversation to before the build rather than after it. The review of the spec becomes the design review, the PM sign-off, and the scoping conversation all at once. When the AI finishes, the PR reflects what everyone agreed to — because everyone agreed to the spec, and the spec is what the AI built against.
The speed doesn't go away. If anything, it improves. The AI isn't slower because the spec is better-defined — it's faster, because it's not making guesses you'll spend two days unwinding.
There's an organisational shift in here too, and it's the part that takes the most adjustment.
The spec has to be a team artifact. Not a prompt someone writes by themselves and hands to an agent. Not a document that lives in one person's head or one person's editor. A shared document that everyone who has a stake in the outcome has actually read and signed off on — before the code exists.
That changes the role of the PM. Instead of writing a brief and waiting for a PR, they're in the spec, setting conditions. It changes the role of the designer. Instead of reviewing output, they're shaping expected results upfront. It changes the role of the lead. The architectural constraints aren't discovered in review — they're written into the spec as boundaries before the build starts.
The AI doesn't change what good coordination looks like. It just surfaces very quickly what happens when you skip it.
Penling is the tool we built around this — a shared workspace where the spec gets written before anyone touches a terminal, handed directly to your coding agent via MCP, and committed to the repository with the PR when the work ships. Everyone who touches the work is in the same artifact, at the same time, before the AI starts building.
The standup conversation changed. It's a lot less "what did we actually ship" and a lot more "that went in exactly as planned."
This is part of a series on adopting spec-driven development. Part one is on why specs make AI output reliable. Part two covers what happens to the reasoning after the code merges.