When the agent writes the code, the problem stops being “which tool do I use?” and becomes “how do I govern what the agent does?”

Cursor, Claude Code, Kiro, OpenCode, and dozens of CLIs solve the surface: IDE or terminal, model A or model B. But if the workflow is open a chat, describe the feature in prose, and accept the diff, you’re in vibe-coding: plausible code that drifts from intent, requirements buried in a history you’ll close tomorrow, and no artifact that survives the session context.

The thread is the frame: why versioned specs matter in the IAG era, how approaches compare, and where each fits in the RPS principle.

The vibe-coding problem

Vibe-coding works until it doesn’t. The agent generates code that compiles, passes the tests you asked for, and matches the repo style. Three weeks later you don’t remember why it chose that abstraction, the original requirement lived in message 47 of the chat, and the next agent (or you, with fresh memory) reinterprets intent from scratch.

In the RPS framework, vibe-coding is degenerate rock: it has the shape of rock (zero ceremony, maximum apparent speed) but none of its virtues. Conscious rock assumes high reversibility and low cost of failure. Vibe-coding on a module with sensitive data, on code that will live for years, or in a regulated domain is improvisation dressed as pragmatism, not conscious rock.

The symptoms are predictable:

• Drift: code drifts from what you asked without anyone noticing until review, or production.
• Lost context: closing the chat deletes the spec.
• Plausible, not correct: the agent optimizes for “looking right,” not for invariants that were never written down.
• Silent hallucinations: invented APIs, dependencies that don’t exist, configurations that “should” work.

None of these are the model’s fault. They’re symptoms of missing explicit agreement between human and agent before implementation.

What SDD is

Spec-Driven Development (SDD) puts the specification as a versioned artifact in the repository (not in chat history) and treats it as a contract between humans and agent. The spec says what the system must do, under what constraints, and what it must not do. The agent implements; humans review against the spec, not just the diff.

In a bank or a company with regulated data, SDD is authentic paper in RPS: you pay upfront structure (specs, reviews, gates) for risk control. The real risk is data leaking to external APIs, hallucinations in production, or decisions nobody can audit six months later, not that the code looks ugly.

It also isn’t “always write a twenty-page PRD.” It’s choosing how much structure you need given team, domain, and cost of failure.

Maturity levels

Most teams don’t need level 3 from day one. But confusing level 0 with conscious rock is the usual mistake.

Minimum constitution: AGENTS.md and project rules

Before formal frameworks there’s a minimal step: tell the agent how to behave in this repo.

AGENTS.md is an emerging convention, Markdown at the project root with conventions, limits, and context any agent should read before touching code. It’s portable across Cursor, Claude Code, Copilot, OpenCode, and most tools that respect project instructions.

In Cursor, the practical equivalent is project rules (.cursor/rules/): files with conventions for this blog, for example, or style constraints. They don’t replace a feature spec, but they stop every session from starting at zero.

In RPS that’s minimum rock: almost zero ceremony, maximum effect per line written. No formal workflow, deltas, or traceability. But it’s a bridge: tomorrow you change IDE or agent and the project constitution travels with you.

This repository doesn’t have AGENTS.md yet; it uses Cursor rules. Adopting AGENTS.md would be the natural next step, same intent, more portability.

OpenCode: the agent that starts at minimum rock

It’s worth separating SDD frameworks (OpenSpec, Kiro) from agents that do the work. OpenCode is an open-source agent (MIT licensed) built for the terminal, with desktop and IDE extensions. It doesn’t replace a spec framework, but it belongs in this post because it bakes in several minimum-governance habits without extra ceremony.

/init analyzes the project and generates an AGENTS.md at the root. It’s the most direct bridge between “repo constitution” and tool: you don’t write the file from scratch; you review it, adjust it, and version it. Same intent as Cursor rules, with a portable artifact other agents can read too.

Build and Plan modes (toggled with Tab in the TUI) separate analysis from execution. In Plan, the agent is read-only: it explores code, proposes approaches, doesn’t touch files. In Build, it writes and runs commands. That’s not full SDD (no deltas or requirement→code traceability) but it’s honest level 1: think before mutating. If you close the session without exporting the plan, you’re back to vibe-coding with extra steps.

Provider-agnostic: seventy-plus models via API (Anthropic, OpenAI, Google, GitHub Copilot) or local inference with Ollama. In RPS that’s rock with a strong bridge: you pay little operational friction and choose who processes the code. The anchor depends on which model provider you connect, not on the agent itself.

OpenCode doesn’t store your code or context on its servers, relevant when the perimeter matters, though that doesn’t replace criteria about what you send to the model. This connects to digital sovereignty: the agent can be a bridge; a closed cloud model is still your decision.

OpenSpec, Kiro, or Spec Kit define what the system should do. OpenCode (like Cursor or Claude Code) implements it. Governance comes from repo artifacts (AGENTS.md, specs, tests), not from the agent’s name.

OpenSpec: paper with a strong bridge

OpenSpec is a tool-agnostic SDD framework aimed at brownfield and incremental change. Specs live in openspec/specs/; proposed changes in openspec/changes/ with explicit deltas: ADDED, MODIFIED, REMOVED.

The core idea: before implementing, the agent (or you) proposes a structured change. You review the delta spec, approve it, then implement. Afterward you archive the change and the base spec updates.

Why it fits RPS as paper:

• You pay structure for alignment and fewer surprises.
• Artifacts are Markdown in your repo, not in a proprietary SaaS.
• Works with Cursor, Claude Code, Copilot, or OpenCode without framework vendor lock-in.

Strong bridge: the specs are yours; the agent is interchangeable. Low anchor: you depend on discipline to follow the workflow, not on a specific vendor.

OpenSpec shines when the project already exists, changes are frequent, and you need the agent to not reinvent requirements every session. Commands like /opsx:propose or /opsx:apply speed the cycle; official docs cover the detail, here the criterion matters, not the syntax.

Kiro SDD: paper with traceability, ecosystem anchor

Kiro takes SDD further: structured workflow requirements → design → tasks, EARS notation for requirements, specs in .kiro/specs/, and hooks that validate before and after the agent runs tools.

Where OpenSpec is agnostic and light, Kiro bets on requirement→design→task→code traceability and deep integration in its own IDE and CLI. For regulated teams or projects where “who asked for this and why?” isn’t rhetorical, that traceability is real paper, not theater.

The RPS cost:

• Anchor in the Kiro/AWS/Bedrock ecosystem: specs may be yours, but the full workflow assumes their tools.
• Paper/scissors by context: paper if the domain demands audit; scissors if you adopt hooks, multi-agent flows, and full methodology for a one-person homelab.

Kiro doesn’t compete with OpenSpec on “which is better.” They compete on how much institutional structure you need and how much anchor you accept in return.

Kiro vs OpenSpec

Other names on the map

GitHub Spec Kit: GitHub’s SDD reference with more ceremony than OpenSpec; useful for greenfield teams already living in GitHub. Paper with bridge (Markdown in repo), somewhat more anchor in the GitHub ecosystem.

Cursor Plan Mode: light SDD without an extra framework: plan before executing, the agent follows the plan in the same session. Rock/paper depending on discipline: if you export the plan to a versioned file, it approaches level 1; if it dies when you close the chat, it’s vibe-coding with extra steps.

OpenCode: covered above: OSS agent, not an SDD framework. Stands out for /init → AGENTS.md, read-only Plan mode, and model agnosticism. Operational rock with bridges; deep tool comparison (IDE vs CLI, vs Cursor) belongs in the agent landscape post.

BMAD, Tessl, Antigravity: heavier multi-agent or commercial methodologies. Scissors in RPS: maximum methodological potential, overkill risk if you’re one person and the domain doesn’t ask for it. Honest mention without in-depth review: I haven’t used them in production.

SDD in the RPS framework

Back to the triad:

The useful question is which strategy I’m using and whether the context justifies it, not which framework has the most stars.

A bank team processing PII with cloud models and no SDD isn’t on rock; it’s on degenerate rock with legal consequences. A solo developer writing full Spec Kit for a 40-line script isn’t on paper; it’s on false paper.

Bridges and anchors in SDD

This connects to digital sovereignty: you can have impeccable specs and still leak data if you send repo contents to a closed model without criteria. SDD governs intent; cognitive sovereignty governs the perimeter.

When you don’t need SDD

SDD is paper, and paper has cost: it isn’t mandatory.

Stay on vibe-coding (conscious rock, not degenerate) when:

• The artifact is thrown away in hours or days.
• Nobody else will maintain the code.
• Failure is cheap and reversible.
• You’re exploring, not building.

Move to AGENTS.md or rules when:

• The project will live weeks or months.
• You return with different agents.
• There are conventions the agent breaks every session.

Move to OpenSpec or equivalent when:

• Code already exists and changes accumulate.
• You need the agent to propose deltas before implementing.
• Several people (or several sessions) must share the same intent.

Move to Kiro or heavy methodology when:

• Audit or regulatory requirements exist.
• Agent commands can be destructive.
• The cost of a production hallucination is unacceptable.

What SDD doesn’t solve

SDD doesn’t replace human review. It doesn’t guarantee the agent follows the spec, only that you have something to measure breach against. It doesn’t remove tests, CI, or acceptance criteria. And it doesn’t pick the model for you: an excellent spec with an agent that can’t see it is decoration.

The leverage is knowing when the spec is worth the effort, and when it’s noise.

What comes next

This post names governance: vibe-coding as degenerate rock, SDD as paper, and the spectrum between AGENTS.md and full frameworks. Other IAG series posts will get concrete on the tool landscape (Cursor, Kiro, Claude Code, OpenCode, IDE vs CLI) and homelab operations (compose → quadlet, SSO, diagnosis with a terminal agent), always with the same criterion: not recipes for their own sake, but knowing what you’re paying for when you choose.

You pay structure for alignment when the agent writes the code and you need intent to outlive the chat.