Writing a spec and having a coding agent follow it to generate an implementation is the easy part. But if we still have to read every line of generated code to determine whether it matches the spec, we have realized only part of the benefit of Spec-Driven Development. We may have improved our own clarity by articulating our intent through the spec. But can we trust the implementation to be aligned with it?

The harder problem is building a harness that keeps the specification and implementation aligned. When the agent gets something wrong, our first instinct is often to fix the code. Instead, we can ask a more interesting question. What gap in the spec did the implementation expose? When the same kinds of gaps keep appearing across specs, we go one level higher. We can ask what needs to change in the harness to help us better articulate, review, and refine our intent (https://intent-driven.dev/assets/blog/intent-harness/harness-feedback-loop.jpg).

In this talk, we will use practical coding-agent demonstrations to show how gaps in the implementation can be traced back to the spec. We will then trace them further back to the SDD workflow or harness that failed to ensure spec completeness. The real test of an SDD harness is whether we can eventually trust the resulting implementation enough to ship it without reading the code.