A startup called CodePlain is making a bold claim: “Code should be regenerated, not maintained.” Their pitch is that you write specs in their Plain language, and whenever something needs to change, you edit the spec and CodePlain regenerates the implementation from scratch. No patching, no refactoring — just nuke and rebuild.
The New Stack covered it last week, and it’s been making the rounds. Good. The topic deserves attention. But I want to separate the insight from the implementation, because CodePlain has one thing profoundly right and one thing that will smash into reality the moment you try it on a real production system.
What CodePlain Is Doing#
Plain is an open-source specification language — structured, Markdown-flavored documents that describe what software should do at the feature and behavior level. You write your requirements in Plain. CodePlain reads those specs and generates the corresponding implementation. The thesis is that as AI makes code generation cheap, the bottleneck shifts: from writing software to reviewing and maintaining it. Reviewing a spec is cognitively cheaper than reviewing the code that implements it.
That framing is sharp. The CEO Dušan Omerčević puts it cleanly: “Specs encode intent. Code encodes implementation. When you conflate the two, you end up maintaining the wrong thing.”
Hard to argue with that.
The Part They’ve Absolutely Nailed#
The core mental model — specs as the durable artifact, code as ephemeral output — is exactly where software development needs to go in the AI era.
We have spent decades treating code as the primary artifact because it was the only executable artifact we had. Documentation rotted because nobody updated it. Comments lied because they weren’t enforced. Requirements documents turned into museum pieces the moment a sprint ended. Code was the truth because code was what ran.
AI changes that equation. If you can regenerate a correct implementation from a spec on demand, the spec becomes authoritative. You no longer need to maintain both a spec and code that slowly diverge from it. The spec is the truth. The code is just a build artifact, like a compiled binary — something you produce from the real source rather than something you hand-edit.
This is the same insight that drives serious SDD (Spec-Driven Development) practitioners. Write the spec first. Make the spec precise enough that an AI agent can implement it correctly. Review the spec, not the code. The code can always be regenerated; the spec captures the decisions that matter.
That’s right. Full stop.
Where It Falls Apart#
The problem is CodePlain’s conclusion that you should therefore regenerate everything whenever something changes.
That works for greenfield projects with no state. The moment you have a production system, it breaks down in at least four ways.
Database migrations don’t regenerate. Your spec says “users have a timezone field.” Previously they didn’t. You can’t regenerate your Postgres schema — you have to migrate it. Migrations are append-only history. They represent state that existed, transformations that ran, data that was affected. Regenerating the database layer from the spec every time you change it means writing and running migrations that match whatever the spec delta is — which is its own complex problem, and CodePlain doesn’t solve it. You’re still maintaining migration files. The spec didn’t eliminate that work; it just moved the complexity.
Runtime state is real. Caches, sessions, queued jobs, in-flight requests, feature flags with live traffic — none of this lives in the spec. Regenerating the application layer doesn’t know about any of it. You can’t regenerate your way out of a corrupt Redis key or a half-finished background job.
Handwritten code exists for reasons. Production code isn’t pristine. That particular sorting function is O(n log n) instead of the naive O(n²) because somebody spent three hours profiling it. That database query has three manually crafted indexes because the ORM-generated one triggered a full table scan on 40 million rows. That API response is cached with a custom TTL because a third-party dependency is flaky. None of that intent is in the spec — it’s in the code, and you probably lost the PR description that explained it. Regenerate from spec, and you lose all of it. Not because the spec was incomplete, but because implementation knowledge that isn’t in the spec is real and accrued and hard-won.
Large codebases make regeneration expensive. Full regeneration for a small CRUD API is feasible. A system with 200k lines of code across a dozen services? You’re looking at hours of LLM inference per change, output that has to be reviewed, integrated, and tested — at a time when your spec change was one paragraph. The cognitive savings from reviewing a spec instead of code evaporate if you then have to validate 50k lines of regenerated output.
The Better Model#
The right answer isn’t to abandon the spec-first insight. It’s to use specs to guide targeted changes rather than to trigger wholesale regeneration.
This is exactly how mature SDD workflows operate with Claude Code. You write and maintain a spec. When something needs to change, you update the spec. Then you hand the updated spec — along with the existing codebase — to an agent that makes the minimal surgical changes to bring the code into alignment. The spec is authoritative. The code evolves under its authority rather than being demolished and rebuilt.
You get the core benefit: the spec is what you review and maintain, and the AI does the implementation. But you don’t throw away the accumulated implementation knowledge, the migration history, the performance work, or the integration subtleties.
This model also handles partial changes correctly. If your spec update touches three features, a targeted agent makes three targeted changes. Regenerating the entire system to pick up three feature changes is using a flamethrower where you needed a scalpel.
Where CodePlain Fits#
None of this means CodePlain is without merit. For greenfield services with no historical state and purely stateless logic, regeneration is actually fine — maybe even ideal. Scaffold a microservice, specify it precisely in Plain, regenerate freely as requirements evolve. Zero legacy weight, zero migration complexity, and the spec stays authoritative throughout. That’s a real use case and CodePlain does it reasonably well.
The problem is presenting this as the future of all software development. Most software development is not greenfield stateless microservices. Most software development is systems that have been running for years, with all the accumulated complexity that entails. The “regenerate, don’t maintain” thesis is too blunt an instrument for that reality.
The Right Takeaway#
CodePlain is surfacing the right argument at the right time. As AI-generated code volume explodes, the cognitive bottleneck shifts from writing to reviewing. Specs that encode intent are cheaper to review than code that encodes implementation. The spec should be the source of truth.
But full code regeneration is not the correct operationalization of that insight for production software. The correct operationalization is spec-first development: write the spec first, keep it authoritative, and use agents to make targeted spec-aligned changes throughout the lifecycle of the system.
The spec is the real asset. Treat it that way — and let the AI handle the rest surgically, not by demolishing and rebuilding every time.