Skip to content

Deterministic generators and the twentieth modification

For the last week, I've been meditating on RAD-style code generators. The old-fashioned deterministic kind.

The classical systems had a fundamental problem: they made code easy to generate and difficult to maintain. You almost always had to edit the output, making regeneration fragile.
Some problems seem solvable now, particularly preserving customizations through sanctioned extension mechanisms.

RAD systems got something important right: treating a model as the source of truth.

Many predated SOAP and REST, so their models were primarily database schemas. Today, we can represent application intent more richly, including contracts, permissions, workflows, integrations, and UI behavior.

The challenge is keeping applications maintainable as they evolve.

Security, regeneration, extensibility, and architectural rigidity were major weaknesses. Low-code survived, but the promise of generating maintainable application code never quite materialized.

My theory is that a clean, flexible generator exposed through MCP could reduce an agent's token consumption by an order of magnitude. Assuming the workflow is cheaper than writing code directly. Which remains to be seen.

I appreciated RAD systems' predictability. Whatever you built, you knew what you were getting. The code quality might be trash, but it was consistently trash.

Architectural entropy

Modern coding agents have almost the opposite problem.

They can produce excellent code, but not necessarily the same architecture twice. That flexibility introduces architectural entropy.

There's a useful division of labor here.

Let deterministic generators handle repetitive implementation, conventions, and predictable output. Let agents handle interpretation, specification, and exceptions.

Put the intelligence in the thing operating the generator, rather than the generator itself.

I suspect many limitations reflected the technology, budgets, and practices of the era rather than deterministic generation itself.

Developer productivity has changed dramatically since then. Coding agents also make building and maintaining generators cheaper.

If we could go from generating a complex enterprise application in three hours to ten minutes, the impact could be substantial.

The twentieth modification

But initial generation time may be the wrong metric.
The more revealing test is the twentieth modification.

That's where classical RAD systems fell apart. Every customization increased the distance between the application and its underlying model.

A system that remains easy to modify because its model continues to represent application intent would be fundamentally different.

Maybe the opportunity isn't generating more code, or even generating it faster at all... so much as it is in reducing the complexity a developer has to personally manage.

I'm curious how much the possibility space has changed.

Codex just delivered a first draft.
Take a look at this beautiful abomination of a prototype.

I'm going to contemplate this a little more.