[draazon]

Diagrams are good for representing structure, and inherently less good at representing behaviour (as mentioned in the article). I recall that in the early 2000s some UML tool venders were pushing "round-trip automation" as a way of tackling this problem; basically you'd model your business domain with some class diagrams, generate some boilerplate code, write code for the actual behaviour and then the tool would magically suck all the behaviour logic back into the diagram. It sort of worked, for a couple of passes, until the tool failed to capture the precise semantics of some perfectly valid code (which was probably inevitable).

I'm hoping that the (somewhat-fine) distinction between no-code and low-code is made with the same problems in mind, that is, an acknowledgement that code is quite often the best way of expressing the behaviour of a system.