How is this different than, say, Rational Rose or any of the other UML/WYSIWYG tools that have come down the pike over the years? Or, for instance, Rules Engines that in general no one uses because inevitably stakeholders stop trying to understand the "plain and simple" english-like syntax that have morphed into full-on semi-Turing Complete disasters that developers manage anyway?

Most code, when visualized in sequence or relational form, is generally incomprehensible even to developers until they've spent time understanding the intent and history of the domain. I can't convince most senior developers to learn to read and use the simplest of UML sequence diagrams. How are non-technical stakeholders supposed to be able to grok this?

Code is complex in the best of times, early in development. Legacy code that's actually used for business in the real world, even when visualized and distilled down to its simplest form, is generally a labyrinth of polymorphism, duplication, object/relational tension, algorithms, background jobs and asynchronous callback madness.

We've seen this kind of thing many, many times before. So often that by the early 2000s when some Golden Visual Environment For Code, the Holy Grail of "drag and drop", would emerge every couple of years or so, we used to roll our eyes and say, "here's another one." I wish I could dig up some of those links, but ALL of the language in this pitch is exactly the kind of thing we've been hearing for decades. And it never pans out.

The closest thing we have is UML. Look, I love UML, and I'm probably one of the last holdouts for it -- I read Martin Fowler's UML Distilled years ago and still use those techniques to this day. But I've never used it to generate code (a la Rational), or to fully diagram an entire system. Even with a human editor reducing the noise and focusing the diagrams on the core workflow, real world systems become extremely complex and very difficult to follow visually unless you have a long history with the system, an understanding of the patterns and architectural principles that went into designing it, and enough technical ability to grok things like inheritance, object/relational concerns, asynchronicity and the like. For these issues, the code isn't the challenge -- it's the concepts themselves, whether expressed visually or directly in code. Any system that grows to have significant business value will a) NOT be able to be maintained purely through visual environment and b) become so complex that the visual representation will be a mass of lines and boxes that, unless edited down and vastly simplified, will be too complex to read even for developers.

The Holy Grail of a visual, drag and drop environment that could create meaningful business value would have manifest years ago if it were possible or even desirable to do so. This latest attempt may end up having some limited utility for simple applications, but I'm beyond skeptical or pessimistic. This seems hopelessly naive to me.