Between Intent and Code: A Panoramic View of AI Programming Paradigms

The first article in a series, explaining the origins, positioning, and decision framework of Vibe Coding, Spec-Driven Development, and Harness Engineering as a foundation for later hands-on guides.

The State of AI Programming

Current situation:

As large language models and AI agents such as Claude Code, Cursor, and GitHub Copilot become embedded throughout the software-engineering lifecycle, the bottleneck has shifted from how quickly code can be written to how precisely human intent can be communicated. AI coding practice is dividing into three core paradigms: Vibe Coding, Spec-Driven Development, and the Agent Harness.

Pain points:

• The real problem is the precision of intent transfer: how can we communicate the most accurate intent to an AI agent with less description, instead of still failing to explain what we want?
• Vibe coding has serious weaknesses in production systems: fragility, loss of trust, and compounding technical debt.
  • Scope creep: without explicit boundaries, AI tends to over-implement or omit key requirements.
  • Hallucination: AI invents APIs or incorrect usage.
  • Poor reviewability: without a spec and plan, a team cannot align before implementation.
  • Poor reproducibility: small changes in prompt wording can produce completely different implementations.
  • Exponential technical debt: every patch that “seems to work” adds hidden risk.

Why pure vibe coding cannot support production systems:

Vibe coding can appear explosively fast early in development because documentation imposes no constraints. Once the codebase exceeds the model's context window or passes a complexity threshold, however, the absence of a source-of-truth specification means that fixing bug A may introduce bug B. Teams fall into an endless loop of compile error → feed it to AI → generate another error → debug again: the context-hallucination trap.

Comparing the Three Paradigms

Positioning Vibe Coding

Key characteristics:

• Input: Natural-language conversation without structured documents.
• Loop: prompt → generate → run and evaluate → continue the conversation.
• Human role: Evaluate behavior rather than review every line. Simon Willison's test is that if you review and understand every line the AI writes, it is not vibe coding; the model is merely a typing assistant.
• Artifact: Only the code persists; intent is not recorded.

Vibe coding still has valuable uses:

• Quickly test whether an idea is feasible—a proof of concept.
• One-off scripts, data processing, and temporary tools.
• Exploratory programming while learning a new framework.
• Personal projects, hackathons, and demos.

In one sentence: Vibe coding is the sketch of AI programming, not the construction drawing.

Positioning Spec Coding

Its theoretical origin is Sean Grove's 2025 talk “The New Code.” Grove was formerly an OpenAI alignment researcher.

GitHub Spec Kit (September 2025), AWS Kiro, Tessl, OpenSpec, and others established the tooling ecosystem.

In October 2025, Thoughtworks' Birgitta Böckeler proposed the most widely used three-level maturity model.

Three levels of maturity:

Key characteristics:

• Input: Structured Markdown—often requirements, design, and tasks, or separate what-spec and how-spec documents.
• Loop: Specify → Plan → Tasks → Implement, updating the spec when necessary through “spec co-evolution.”
• Human role: Review and approve artifacts at each stage instead of reviewing only the final code.
• Artifacts: Specifications such as requirements.md, design.md, and tasks.md, plus code. The spec is a first-class artifact.

Spec coding advances the process from “guess what I want” to “build according to the specification.” It is likely to be the mainstream approach through 2026 and the first half of 2027.

Why did the industry converge on specifications?

In 2025, a consensus emerged: when an AI coding agent performs poorly, the problem is often ambiguous instructions rather than a weak model.

• GitHub open-sourced Spec Kit, with 77,000 stars, structuring spec → plan → task → implement.
• OpenAI's Symphony architecture requires each issue to bind to a SPEC.md contract.
• Anthropic added Plan Mode to Claude Code—essentially a lightweight spec.
• AWS launched Kiro, which drives agent development from specifications.

The ecosystem converged on the same conclusion: define what to build before writing code; do not make AI guess.

The core Spec-Driven Development workflow

SDD is a methodology, not a tool. It has four main steps:

• Specify—define what to build
  • Describe what, not how. A spec is functional and intentionally technology-independent.
  • In nontechnical language, a good spec explains purpose, use cases, boundaries, and acceptance criteria.
• Plan—decide how to build it
  • The plan is technical: it tells the agent how to realize the spec.
• Tasks—break down the work
  • Split the plan into small ordered tasks. Each should fit into one agent session and produce a verifiable change with tests.
• Implement—execute one task at a time
  • The agent follows the task list. It now has the necessary context and no longer needs to guess.

What does spec coding solve, and what does it not solve?

It solves:

• Ambiguity—the agent no longer has to guess.
• Reviewability—the team can align before implementation.
• Reproducibility—the same spec produces consistent results.
• A quality floor—acceptance criteria become test cases.

It does not solve:

• Runtime fault recovery for agents.
• Orchestration and state management across multiple agents.
• Dynamic context-window management.
• Safety controls and human approval flows.
• Persistent memory across sessions.

EARS syntax in spec coding

SDD frequently uses EARS (Easy Approach to Requirements Syntax) so AI can parse requirements consistently. Every requirement follows one of five conditional patterns:

• [Trigger] When a specific event occurs... (event-driven)
• [State] While the system is in a specific state... (state-driven)
• [Precondition] If a prerequisite is satisfied... (preconditioned)
• [Optional] Where an optional feature is enabled... (optional)
• The system [expected response].

The essence of spec coding

The specification is the single source of truth; code is merely its compiled output for a particular technology stack.

It directly addresses:

• Intent drift: Prevents AI from forgetting the original business goal during long conversations or large refactors.
• Context decay: Records repository rules and constraints in files such as CLAUDE.md or AGENTS.md, preventing accuracy from collapsing as the codebase grows.

Personal view: this is the main delivery approach for small and medium production projects because it can preserve both speed and quality—provided the project is genuinely small, medium, or personal.

Positioning Harness Engineering

This term only began to solidify in the first half of 2026, proposed independently by Rich Naszcyniec at Red Hat, Birgitta Böckeler at Thoughtworks, and others before rapidly converging. Its central metaphor is:

“Agent = Model + Harness.” The model is the engine; the harness is the rest of the car: steering, brakes, lane markings, and maintenance schedule. Harness engineering does not alter the model; it builds the structured environment in which the model operates.

Böckeler divides the harness into two control vectors:

• Guides—feedforward: Guidance supplied before action, such as CLAUDE.md, Skills, architecture documentation, code conventions, and type systems.
• Sensors—feedback: Mechanisms that let the agent verify its work after action, such as compilers, unit tests, linters, property-based tests, and LLM-as-judge reviews.

Key characteristics:

• Input: Not one document format, but an entire guide-and-sensor system.
• Loop: Guide constrains the action → agent works autonomously → Sensor verifies → agent self-corrects → repeat. Ideally, problems are fixed before a human sees them.
• Human role: Design the system instead of intervening each time, and periodically evaluate the harness's “harnessability.”
• Artifacts: Reusable engineering infrastructure—Skills, hooks, test suites, and CI rules. A specification is just one kind of Guide.

How the Three Paradigms Relate

• The harness is the container; SDD is one kind of content inside it. Documents such as requirements.md and design.md are implementations of a Guide: persistent Markdown describing what the agent should know before acting.
• Vibe coding is the limiting case of an almost-empty harness. There are no persistent Guides or systematic Sensors; correction depends on conversation and immediate human judgment.
• Pure SDD with Guides but no Sensors is only half a harness. That is why Kiro introduces property-based testing and Spec Kit asks for failing contract tests before implementation: both are adding Sensors.
• A good harness does not always need heavyweight SDD. A lightweight Guide—one or two Skill files—combined with strong Sensors such as comprehensive CI and automated review can deliver similar reliability. This is the lightweight philosophy behind OpenSpec and Claude Code's native Plan Mode.

In one sentence: Vibe coding answers “how do we converse?”; SDD answers “what documents do we write before acting?”; harness engineering answers “how does the entire system let AI self-correct?” Harness engineering has the broadest scope and can contain the other two.

Deeper Analysis

The Encoding–Decoding Gap

Red Hat's Rich Naszcyniec proposes a useful framework: there is a gap between what a developer intends—the encoding—and what AI produces—the decoding. Natural language is a lossy channel. You say “a concise responsive cluster-health dashboard,” while AI hears something close but not identical: it uses a deprecated library, omits authentication, or ignores existing codebase patterns.

Each paradigm addresses this gap differently:

• Vibe coding does not proactively narrow it, relying on discovering errors later and iterating through conversation.
• SDD narrows it before action by making the what and how explicit.
• A harness uses a network of Sensors after action to catch deviations and correct them before they reach a human.

These mechanisms are complementary. Specifications reduce the chance of a wrong first guess; Sensors ensure a wrong guess is discovered automatically.

Feedback-Loop Length

Calling SDD “waterfall in new clothes” is common and not entirely unreasonable. A complete requirements document existing before implementation does resemble waterfall. The essential difference is feedback-loop length:

• Traditional waterfall: write a 200-page requirements document → hand it to a development team → see the result months later, after requirements have drifted and the document has become fiction.
• SDD: write a Markdown specification → hand it to an agent → see output in minutes → edit the spec and rerun when it is wrong.

The Codagent newsletter, which articulated this distinction, also offers a sober warning: SDD fails not because specifications are written, but because their scope is too large. If an entire notification subsystem—webhooks, email digests, in-app notifications, user preferences, delivery tracking, retrying, and rate limiting—is specified at once, human review checkpoints disappear. An incorrect early assumption such as the data model is discovered only after everything is built, forcing every feature to be revisited. This is the same large-batch, late-feedback problem as waterfall, merely running on faster hardware.

Counterexamples from practice include:

• The Marmelab team recorded Spec Kit producing 1,300 lines of Markdown for a simple “display a date” feature.
• Multi-agent research-and-validation workflows such as GSD (Get Shit Done) can consume more than 100 agent calls for one bug fix.

Practical advice: keep each specification small enough to evaluate in one pass—one feature or one change, not an entire subsystem.

The Two Axes of a Harness

Böckeler distinguishes two kinds of control:

Sensors themselves divide into two often-overlooked categories:

• Computational: Deterministic, fast, and executable on a CPU—linters, type checks, and compilers.
• Inferential: Require another LLM to judge—LLM-as-judge and code-review subagents.

A common mistake is to treat “be careful” in a prompt as a reliability guarantee. Böckeler's distinction is direct: prompt engineering says “tell the model to be careful”; harness engineering says “make the careful path the default.” If an agent writes code that does not compile, adding “pay attention to type safety” to the prompt is ineffective. Compilation and tests need to be mandatory parts of the loop.

Timeline

The Four-Pillar Model

In March 2026, Red Hat proposed a more granular breakdown that combines SDD and harness concepts:

The model makes clear that Vibe and Spec are not substitutes but two stages of one workflow: explore with vibes, record decisions in a spec, package reusable capability as Skills, and give the work to an agent with the appropriate autonomy. Red Hat also distinguishes “interacting”—conversation and coaching—from “instructing”—directed execution. This is another, compatible view of the three paradigms in this article.

Decision Framework

Is the task simple and free of team-collaboration or audit requirements?
   ├─ Yes → Vibe Coding for exploration and prototyping
   └─ No ↓

Are the requirements and boundaries unclear—even to you?
   ├─ Yes → Vibe a rough prototype first, then write the Spec
   │         (“vibe before you spec”)
   └─ No ↓

Can the scope be evaluated completely in one pass—one feature or change?
   ├─ No, it spans subsystems or a large refactor → Split it and apply SDD
   │   separately; do not specify the whole system at once
   └─ Yes ↓

Does it require long-term maintenance, team collaboration, or an audit trail?
   ├─ Yes → Spec-Driven Development; spec-anchored is enough, and
   │         spec-as-source is unnecessary
   └─ No → Use a lightweight Guide—one or two Skill files—plus strong
             Sensors such as tests and CI; avoid a heavyweight SDD toolchain

Whichever route you choose, build in parallel:
   └─ A Sensor layer—automated tests, type checks, and security scans.
      Every paradigm needs this safety net.

References

• Andrej Karpathy coins vibe coding, February 2025: https://x.com/karpathy/status/1886192184808149383
• Sean Grove, “The New Code”: https://my.infocaptor.com/hub/summaries/ai-engineer/the-new-code-sean-grove-openai-8rABwKRsec4
• Birgitta Böckeler, three-level SDD framework, October 2025: https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html
• arXiv 2602.00180, “Spec-Driven Development: From Code to Contract”: https://arxiv.org/abs/2602.00180
• arXiv 2505.19443, “Vibe Coding vs. Agentic Coding”: https://arxiv.org/pdf/2505.19443
• arXiv 2510.17842, an academic definition of Vibe Coding: https://arxiv.org/pdf/2510.17842
• Birgitta Böckeler, “Harness engineering for coding agent users”: https://martinfowler.com/articles/harness-engineering.html
• Birgitta Böckeler and Chris Ford, “Harness engineering and agent feedback”: https://www.thoughtworks.com/insights/blog/generative-ai/harness-engineering-agent-feedback-exploring-ai-coding-sensors
• Thoughtworks Podcast, “What is harness engineering?”: https://www.thoughtworks.com/insights/podcasts/technology-podcasts/what-is-harness-engineering
• Red Hat, “Vibes, specs, skills, and agents: The four pillars of AI coding”: https://developers.redhat.com/articles/2026/03/30/vibes-specs-skills-agents-ai-coding
• Codagent Newsletter, “Think Before You Prompt”: https://codagent.beehiiv.com/p/think-before-you-prompt
• Awesome Harness Engineering: https://github.com/ai-boost/awesome-harness-engineering
• GitHub Spec Kit: https://github.com/github/spec-kit
• AWS Kiro Specs: https://kiro.dev/docs/specs/
• OpenSpec: https://github.com/Fission-AI/OpenSpec
• Anthropic, “Equipping agents for the real world with Agent Skills”: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
• Claude Code best practices: https://code.claude.com/docs/en/best-practices
• Marmelab, “Spec-driven development: Waterfall strikes back”: https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html
• Thoughtworks Technology Radar discussion of SDD as “Assess”: https://vibeready.sh/blog/what-is-spec-driven-development/

Series