Codeplain's Argument: Code Should Be Regenerated, Not Maintained

The software engineering orthodoxy is that code is the thing you preserve. Codeplain’s thesis is the opposite: the spec is the durable artifact; code is the disposable output you generate from it.

What Codeplain Does

Codeplain, founded by Dušan Omerčević in Ljubljana, Slovenia, is built around a purpose-built specification language called Plain. Plain documents define how software should behave in structured, human-readable form. The system then generates implementation code from the spec.

When something breaks or needs to change, you edit the Plain spec — not the generated code. Codeplain regenerates the implementation from the updated spec. The generated code is not maintained; it’s replaced. The spec is what engineers version, review, and evolve.

The argument behind this approach, according to The New Stack’s reporting: in a world where AI code generation is accurate enough to produce production-ready implementations from specifications, treating generated code as the source of truth is an inefficiency. The spec already contains all the durable knowledge. The code is just the latest rendering of it.

Why the Timing Is Right

This argument was easier to dismiss when code generation was unreliable. You had to maintain code carefully because generated code needed constant correction. The quality curve on AI code generation in 2026 changes the math.

Teams are already drifting toward regeneration patterns without formalizing them. An engineer who prompts an AI assistant to rewrite a function from scratch rather than iterating on existing code is practicing an informal version of the regeneration principle. Codeplain formalizes that into a discipline: one canonical spec, one generation step, no manual edits to generated output.

This positions Codeplain in a larger conversation about what engineering discipline looks like in the age of AI-assisted development. The traditional value proposition of code review, careful manual iteration, and incremental change management presumes that the code carries embedded knowledge. In a regeneration model, the spec carries the knowledge and code becomes ephemeral.

The Catch

The model works cleanly for well-bounded implementation problems. It’s harder for systems where the implementation contains accumulated learning — edge case handling discovered through production incidents, performance optimizations that aren’t expressible in a specification, architectural decisions embedded in code structure that predate the spec.

Regeneration requires that the Plain spec fully captures intent. In systems with significant organizational debt — where the code knows more than any specification does — the spec must be written from the code before regeneration becomes viable. That documentation work is not free.

Source: The New Stack

Content created with AI assistance and reviewed for accuracy.