The leap that matters
The problem with using AI agents for development 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 accountability 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. But in a corporate 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, or specification, 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 lost in the conversation?”.
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.
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.
At first glance, it may look like you have less control over the code you generate. The reality is the exact opposite.