> Code is just detailed specifications on how things should operate.

The spec defines how things should operate. Code defines how things operate.

The problem being that if there is only code, then any change to system behaviour is always correct (including bugs). Because that's what the code says.

Relying on tests won't help without a spec to create tests from. So tests are generated from code. So if a test fails, it's the fault of the test, not the code.

Yes, actually that's what I'd had argued a few years ago as well.

It turns out that there are now a few more people that want to get their hands on building software, that don't necessarily understand code, but do have a fundamental idea of system design / requirements.

As you said code has always been a much more explicit representation of those specs, yet arguably introduces lots of noise, necessary to make the program compilable.

Us devs already had the obligation of writing technical documentation for non-technical people, just not at an explicit depth. From an efficiency PoV making that documentation more explicit is much cheaper than manually writing the compilable code. Hurts to say but AI got pretty good with the latter.

Isn't maintainability mostly about applying basic engineering principles e.g. separation of concerns, single responsibility, dependency inversion, open-closed etc..? If these topics are addressed in the normative representation, and correctly translated by an LLM into code (especially by slicing up the specifications into measurable outcomes to set the intended foundation), then future change e.g. maintainability becomes essentially easy as well, no?

Historically I know that the majority maintenance problems occur from slow continuous evolution of a system that it initially was never designed for. And the only way to address this was continuous system design.