[z9znz]

I suspect there are certain use cases for which low-code systems are well suited, and others where it will either not be expressive enough or will end up being so complex that it would be better/more easily expressed in code.

I spent a few years building data analytic systems for big telcos to reconcile switch and billing data. For this I used the tool my company was selling which was a visual (ugly but very practical) graphical node-based system. You pick the right type of node for a given (stream processing) need, make some configurations (including possibly adjusting the number of inputs and outputs), and then connect things together.

Many of the end results would have been reasonably simple to build in code by an experienced developer, but one of the key benefits of this toolkit was the ability to walk a client through the system, explaining what was going on. The visual nodes and connections were reasonably accessible to non programmers.

An added benefit of this kind of toolkit was the ease of discovering what the data actually looked like and seeing the effects at the output of each node. The outputs also had little number tags which provided surprisingly useful high level information: "How many records did we just cull from the source data with this filter?"

The challenge we encountered was in productionizing these systems. Sometimes they were just tools used to solve a one-time problem, but other times they were intended to become parts of a greater process. (In the latter case, I always felt we should just take the lessons learned and write the final product in code...)