Specs Are the Deliverable - Jelmer SnoeckThe bottleneck in AI-assisted engineering is not code review. It is spec review, and before that, spec definition. Not many people are doing this yet, or are not doing it well. A good spec is what turns an agent&rsquo;s output from a gamble into a coding outcome you can sign your name to. We have not noticed the bottleneck because the spec is usually invisible, sitting in someone&rsquo;s head or in a Slack thread or in a comment on a ticket, and the code is the only artifact that gets a formal sign-off. That arrangement worked when a senior engineer wrote a few hundred lines a day. It does not work when an agent writes thousands.<br>Code generation got cheap, review didn&rsquo;t<br>Two pieces converge on the same observation. Facundo Olano in --dangerously-skip-reading-code argues that if your organisation is going to push you toward maximum-speed agentic coding, then rigor has to land somewhere new, and his bet is a Markdown specification checked into the repo with PR checks that verify the code conforms to it. Simon Willison frames it as a personal drift: he is reading less code, treating his agent more like another team he depends on, and feeling uneasy about it. Same phenomenon from opposite ends. Code generation got cheap while code review stayed expensive, and the two used to be matched. They are not matched anymore.<br>Once you accept that the trade is real, the next question is what the spec actually is.<br>&ldquo;Spec is just code&rdquo; is almost right<br>Birgitta Böckeler has a useful frame. Three levels of how a spec can relate to the code it produces:<br>Spec-first : you write the spec, generate code from it, and after that the code is the source of truth. The spec is a starting point that drifts.<br>Spec-anchored : the spec and the code coexist. Both are maintained, both are reviewable, and the relationship between them is the unit of work.<br>Spec-as-source : the spec is the only thing a human edits. The code is a regenerable output of the spec, the way a binary is a regenerable output of source.<br>Spec-as-source is the destination. Not because it is clever, but because it is the only position that takes the bottleneck seriously. When generation is cheap and human attention is not, you put the attention on the artifact that decides what gets built. The code becomes downstream of that decision, not the place where it is made.<br>Forge, the coding agent I have been building, aims for spec-as-source and gets close in practice. I do not write code in Forge. I edit and review specs. If I want a new feature, fix a bug, change behavior, I get the spec updated, and the code flows out of it. Forge&rsquo;s loop automatically checks the code against the spec before anything reaches me.<br>The remaining human pass on the diff is habit, not requirement. Once the conformance check is enforced automatically instead of run once and trusted, it drops.<br>The objection that &ldquo;a very very detailed spec is just the code&rdquo; is where the argument usually stops, and it stops one step too early. The goal is not a spec so detailed it becomes a programming language with Markdown syntax. The goal is a spec detailed enough about the what — desired outcomes, constraints, failure modes, invariants — that the agent can be trusted to figure out the how. If I am writing &ldquo;if this then that&rdquo; in prose, I have taken a wrong turn. That is what programming languages are for, and the agent is better at that layer than I am.<br>Every previous wave of spec-driven anything tried to land here and failed. UML, BPML, BRMS, Drools, all of those attempts collapsed for the same reason: the spec language was wrong. They tried to be executable in a syntax humans hated. They demanded the precision of a programming language without the tooling, the type checker, or the community to support it — which is exactly the mistake of treating a spec as &ldquo;code, but slower.&rdquo; The thing that changed is the compiler. An LLM is a worse compiler than gcc on every dimension except one: it can take an outcome-level description in a language humans already speak and produce code that implements it. That is what makes spec-as-source viable for the first time, and Tessl is the most ambitious live attempt at it today.<br>What changes when specs are the deliverable<br>If you take this seriously, three things change about how you work, and they get sharper the closer you get to spec-as-source.<br>First, the unit of review shifts from code diff to spec diff. A code diff is concrete, low-level, and easy to disagree about for the wrong reasons; people will argue about naming and indentation in a 200-line PR while the architectural decision that produced it goes unexamined. A spec diff is the inverse. It is high-level, abstract, and forces the disagreement onto the decision rather than the implementation of the decision. The first time you review a spec change instead of a code change, it feels strange, because the conversation you are now...