SpecScore vs CodeSpeak

Two answers to "what should specs be for." CodeSpeak treats the spec assource code — an LLM compiles it, and you maintain the spec instead of the code. SpecScore treats the spec as a durable, open contract — you keep your code, and any agent (or none) can read, lint, and trace it.

What they share.

Both put the specification at the center of software development.
Both are built for an AI-assisted world — intent before implementation.
Both aim to make software easier to change by changing the spec.

What CodeSpeak does well.

CodeSpeakis an LLM-powered programming system that compiles structured-English specs to code.

A bold thesis, credibly argued

"Maintain the spec, not the code" is a genuine reframing, not an incremental tweak. It comes from the designer of the Kotlin language, and it's worth taking seriously: if the spec is the source, the generated code becomes an implementation detail.

Code-to-spec takeover

codespeak takeover reads existing source and produces a spec that captures its behavior — a low-friction on-ramp for brownfield code, with reported spec-to-code compression of roughly 5–10×.

Intent recovery from agent sessions

CodeSpeak's Intent Studio extracts requirements from prior agent sessions — harvesting intent you've already expressed rather than asking you to author a spec from a blank page.

Feature comparison.

The two make different bets, so the table compares philosophy and mechanics, not winners.

Capability	CodeSpeak	SpecScore
Source of truth	The spec (compile input)	The spec is the contract; code is the deliverable
Generated code	Produced by an LLM, not hand-maintained	You and your agents write and own the code
Spec format	Plain English, CodeSpeak-defined	Open Markdown + YAML standard, published schema
Spec → code	Core feature (proprietary LLM compiler)	Out of scope — any agent implements
Works without the vendor	Specs compile through CodeSpeak	Yes — specs work with any agent, or none
Spec linting	Not documented	Content quality — vague verbs, missing ACs, dangling refs
Code-to-spec traceability	Via regeneration	`specscore:` annotations + `Verifies:` trailers
Determinism	LLM compile (non-deterministic)	Deterministic CLI queries; code authored normally
Code → spec	`codespeak takeover`	`survey` + author
Openness	Proprietary system	Open — CC BY 4.0 format, MIT / Apache-2.0 tools
Stage	Alpha preview	Shipping

Where SpecScore differs.

You keep your code

CodeSpeak generates and regenerates the implementation; the code is an output, not an asset. SpecScore leaves the code where it belongs — in your hands, in your language, reviewable line by line. The spec adds clarity and traceability without taking the code away.

Your specs are portable

A CodeSpeak spec is valuable because CodeSpeak compiles it. A SpecScore spec is valuable on its own — it's well-structured Markdown that any agent can read, and it stays useful with no SpecScore tooling installed at all. Adopt it with any tool, or none. Leave any time.

Ambiguity is caught before it costs

With an LLM compiler, an ambiguous spec becomes wrong code at build time. SpecScore's lint surfaces vague verbs, missing acceptance criteria, and dangling references before an agent acts on them.

$ specscore lint checkout/apply-discount.md
  ✗ R3  no acceptance criteria
  ✗ verb  "handle gracefully" — unmeasurable

Determinism and traceability

CodeSpeak's answer to "which code implements this?" is "all of it, regenerated." SpecScore's answer is a specific file and line, viaspecscore code refs and Verifies: commit trailers — deterministic, auditable, diff-able.

A structured artifact graph

CodeSpeak's unit is a spec file in prose. SpecScore has a typed hierarchy — Ideas promote to Features, Features carry Requirements and Acceptance Criteria with IDs, Plans reference ACs, Tasks reference Plans — all machine-navigable.

No vendor in the build path

SpecScore is a single Go binary. Lint runs in CI and pre-commit hooks with no account, no service call, no LLM round-trip in your build.

When to use which.

Reach for CodeSpeak when…

You want to stop maintaining code and let the spec be the source.
You're comfortable depending on a vendor's compiler for that leverage.
You want to compress an existing codebase into a much shorter spec.

Use SpecScore when…

You want specs that outlive any single tool — portable by construction.
You want to keep your code, in your language, reviewable and owned.
You need spec quality enforcement — lint catches ambiguity early.
You need deterministic code-to-spec traceability.
You want no vendor and no LLM round-trip in your build path.

Two different bets.

CodeSpeak is a bet on a compiler: hand it the spec, and trust it to produce and reproduce the code. SpecScore is a bet on a format: keep the spec open and portable, keep the code yours, and let any agent work against it.

One trades portability for leverage. The other keeps you free — and lintable.

This comparison is based on publicly available documentation and source code. Something wrong or outdated? open a correction issue. Want us to compare SpecScore with another tool? request one.