The leap that matters
The hard problem with AI coding agents is not “this week’s model”. Models change fast. The hard question is: how do you turn human intent into trustworthy software without losing control, quality, and ownership along the way.
Vibe coding, the practice of building by talking to the model, showed that AI can generate a lot of code from natural language. That is powerful for prototypes. In a professional setting, shipping software does not end when code appears. Delivery also means aligning scope, preserving architecture, protecting data, validating behavior, reviewing changes, auditing decisions, and keeping the system healthy after deploy.
That is where two ideas need to travel together:
- SDD, or Spec-Driven Development: writing and evolving specifications that work as a contract.
- Harness Design: the tooling around the agent so it has context, limits, and validation.
Apart, they help. Together, they change the delivery pattern.
What SDD is
SDD means Spec-Driven Development, development guided by specification.
In this context, a spec is a living, versioned, reviewable artifact that answers:
- which problem we are solving;
- who it matters for;
- what is in and out of scope;
- which behaviors must exist;
- which technical, legal, or product constraints must be respected;
- which criteria prove the delivery is correct;
- which risks need human review.
The shift is simple: the agent does not implement “the prompt”. It implements a solid, reviewable, verifiable plan.
What Harness Design is
Harness Design is the environment of the coding agent.
If SDD answers “what needs to be true?”, the harness answers “how do we create a system where the agent can execute, validate, and improve without relying on luck or context that exists only in the chat?”.
A model is not an agent
A model answers. An agent tries to finish a task using tools in a loop: it reads context, takes an action, observes the result, and decides the next step.
The harness is what makes that loop useful in real work. It tells the agent which rules to respect, which tools to use, where to find context, when to ask for approval, and how to prove it is done.
agent = model + harness
What goes into a harness?
Think of the harness as the agent’s work infrastructure: the set of elements that lets you leave the chat and arrive at a validatable delivery.
- Instructions: files like
AGENTS.md, rules, and skills that load commands, patterns, and project agreements. - Context: specs, technical decisions, architecture, product docs, and enough history so the agent is not working in the dark.
- Tools: terminal, Git, browser, GitHub, logs, MCP servers, and other integrations that let the agent act in the right environment.
- Limits: sandbox, permissions, human approvals, and blocks for destructive or sensitive actions.
- Validation: lint, tests, typecheck, build, diff review, and checklists that push against broken delivery.
- Observability: UI, logs, metrics, traces, screenshots, and reproducible checks that the agent (and the human) can read to understand what happened.
- Learning: each recurring failure becomes a rule, test, hook, doc, or skill. The harness improves because the team learned.
Good rails give the agent room to move while making that movement predictable, reviewable, and safe.
Where this breaks
A bad harness becomes theater. README rules nobody follows. A skill nobody invokes. A build that passes while nobody reads the diff. Infinite context dumped into the prompt with no curation.
Bad SDD becomes a dead document: a spec nobody updates, criteria nobody tests, scope that only changes in chat.
Maturity shows up when a failure leads the team to improve the system (rule, test, limit, doc) instead of only repeating the prompt louder.
The engineer’s role
With agents in the flow, the work shifts. Less time typing boilerplate. More time on specification, review, governance, and harness quality.
Useful questions for an explicit harness:
- Does the agent know the goal and the out-of-scope for this task?
- Which files and tools can it touch without approval?
- What proves it finished (test, build, checklist)?
- What must it never do alone (secrets, production, force push)?
- Where does today’s failure become tomorrow’s rule?
AI-native work means owning the system that produces the diff, not accepting generated changes faster.
In practice (PM, QA, leadership)
- PM: the spec becomes the shared contract. Less “where is the feature?”, more “is this acceptance criterion covered?”.
- QA: enters before implementation. Criteria and risks become checks, not only end-of-line bugs.
- Leadership: the risk stops being only model hallucination. It becomes missing trail: decisions only in chat, no plan, no validation, no review at merge.
If you want the field version (what changes on a Tuesday), read Harness in daily work.
Takeaway
Models change. Tool categories change. The lasting pattern is simpler: clear intent (SDD), an environment with rails (harness), explicit validation, and a human accountable at merge.
Loose prompting explores. Repeatable delivery needs a system.