Spec-driven development with Codeplain is the future AI-era codebases have been signaling for years: maintaining code doesn’t scale when models generate it faster than humans can review or patch. The value (and pain relief) is direct—strip maintenance out of the loop by regenerating production code from a single human-readable spec. Codeplain’s approach, built around its open-source Plain specification language, reframes the hardest part of AI-driven engineering: stop chasing code entropy, focus on expressing intent, and let regeneration handle the churn. This is not a coding productivity booster. It’s a rewrite of the maintenance loop, cut to its core.
Spec-driven development, as framed by Codeplain, means building software from structured, human-readable specifications rather than laboring over thousands of lines of hand-maintained code. Codeplain’s core tooling is built around Plain: an open-source, YAML-like language that forms the single source of truth for how software should behave. Dušan Omerčević, Codeplain’s CEO and co-founder, described it plainly: “Code should not be maintained — code should be regenerated. Specs should be reviewed, and it's the specs that you maintain.”
Instead of patching bugs in procedural code or updating APIs by hand, the development process shifts: you edit or extend the Plain spec, addressing the requirements or the problem at the level of intent. Codeplain then regenerates the codebase from the revised spec—automatically, from scratch. The spec is always the authoritative version of the system.
Launched in Ljubljana, Slovenia in early 2025, Codeplain went live in September that year. While plenty of platforms promise AI-powered codegen, Codeplain positions itself as delivering “spec-driven, production-ready code generation”—not playground throwaways, but code intended for real-world operations. By using Plain, teams encode domain logic, endpoints, data models, and behaviors at a high level, letting the actual code drift or be replaced as needed, as long as the spec is correct.
Takeaway: instead of fighting code entropy, Codeplain makes the spec itself the product, and the code an ephemeral artifact.
[[CONCEPT: the spec as the lasting asset, regenerated code as a disposable output]]
AI-generated code has outpaced the models of traditional review and maintenance. As Omerčević puts it, “the bottleneck has shifted from writing software to reviewing and maintaining it.” AI models—Claude Code, Codex, OpenCode, and their ilk—can spin out working code faster than any team can keep up with. The effect: quality assurance and maintenance become the last manual checkpoint in a fully-automated pipeline, and it’s the part that simply doesn’t scale.
Reviewing AI-generated code is cognitively demanding. Unlike code you wrote by hand, generated code often lacks the local context and intention that make diffs intelligible. Every unfamiliar variable, mangled function name, or synthetic pattern adds review overhead. Worse: reviewing thousands of lines of AI code is error-prone—teams skim rather than read, and bugs or subtle breakages slip by. Patch those bugs, and the code diverges from later generations; patch enough times, and the AI’s next output rewrites over human fixes entirely.
The challenge is structural:
The upshot is clear: more AI generation means more entropy, and humans are ill-suited to manage that at scale through code review alone.
Spec-driven development with Codeplain shifts the focal point: you’re no longer staring at implementation details but at structured descriptions of what the system should do and handle. Reviewing specs is qualitatively different from reviewing code. Where code review demands tracking function calls, control flow, and idioms, spec review is about understanding the high-level system intent—what endpoints exist, which behaviors are required, what constraints matter.
Cognitive load drops dramatically:
As Omerčević argues, “reviewing specs, which encode intent rather than implementation, requires a fraction of the cognitive load of reviewing code.” That means faster onboarding, easier audits, and less fatigue. Code review is about hunting edge cases and subtle contract violations. Spec review is more about clarity: does this spec capture what we mean for the system to do?
Example:
Suppose a checkout API needs to require strong customer authentication after $500. The spec change looks something like:
endpoint: /checkout
require_strong_authentication: true
threshold_amount: 500
Instead of hunting that logic through controller classes and middleware, a reviewer checks intent directly in the spec.
Takeaway: Spec-driven review is not a silver bullet, but it cuts the loop down to the essentials—intent, not syntax or implementation quirks.
[[COMPARE: spec review vs code review — direct comparison of lines, cognitive steps, error surface]]
Adopting Codeplain’s spec-driven approach is concrete, not speculative. The core developer flow is:
A concrete workflow:
vim api-spec.plain
codeplain generate --spec api-spec.plain --out ./src
npm test
Plain is open source, so the language itself is vendor-neutral and reviewable. For teams already working with code generation (perhaps piecemeal, via prompts or partial templates) the leap to full Plain-based specs is organizational, not technical. The main shift is to keep specs as the only human-maintained asset, and treat all code as a disposable output. Teams transitioning should enforce invariants:
Codeplain announced, alongside its 2025 launch, a public open-source agentic skills framework: plain-forge. This allows coding agents (Claude Code, Codex, OpenCode, etc.) to draft and maintain Plain specs conversationally. As this matures, generating and maintaining specs becomes easier than managing code diffs, especially as agents handle routine format and compliance work.
Supported platforms: The company highlights production-readiness, but as of the June 2026 article, specific languages or frameworks are not detailed. The safest assumption is that initial targets are web backends typical of enterprise and SaaS stacks.
Takeaway: Any team with repetitive backend/service generation or high AI-code churn can start today—setup is mostly about organizational discipline and CI integration.
Benefits:
Limitations:
Long-term, the impact is structural: engineering organizations that embrace spec-driven development, as Codeplain frames it, build institutional knowledge into specs—not into code (which remains transient and interchangeable). Bugs in generated code stop being patch-and-forget; they’re reframed as issues to be addressed in the spec, then respun across all environments on regeneration.
Codeplain’s roadmap is ambitious: with $3M funding raised and a public position as the driving force behind spec-driven, “production-ready” generation, the company is betting that as code generation becomes richer, regenerating code will beat maintaining it, and that review/maintenance workflows will shift wholesale from code to spec as the source of truth.
[[CHART: spec-first workflow scales while code maintenance plateaus]]
The Omerčević thesis is hard-edged: maintaining code doesn’t scale; regenerating code from a spec does. Codeplain’s spec-driven development makes the spec the durable asset, the code its safely-regenerated byproduct. Codeplain’s ecosystem isn’t about making code review faster. It’s about making code review irrelevant—because the only thing that matters is the intent encoded in a Plain spec, and generation is always a clean slate. For teams fighting AI drift and maintenance entropy, moving to spec-driven development is both a bet and a future-proofing act. Regenerate, don’t repair. The phoenix principle wins.