[svieira]

The bit you are missing is that "known to the system" is not enough, as the consumer I need to _verify the logic_, which means that at some level, I do have to read the DSL (just as I have to read the Java, not, in general, the actual assembly emitted by the JIT). Which means that the DSL is actually the product here (though the LLM may make it easier to learn that DSL and in some cases to write something in it).

[kgeist]

1) You don't need to read the DSL in the raw form if you use a language model to convert it to a few paragraphs in natural language.

2) You can test the created workflow on a bunch of test data to verify it works as intended. After a workflow is created, it's deterministic (since we don't use LLMs anymore for decision making), so it will always work the same.

Sure we can expose DSL to power users as an option, but is reading the raw DSL really required for the majority of cases?

[svieira]

1. Now you have two problems (did the writer translate what I said correctly and did the summarizer translate what the writer wrote correctly).

2. This is absolutely true and it does help somewhat. However, writing the test cases is now your bottleneck (and you're writing them as a substitute for being able to read a reliable high-level summary of what the workflow actually is).

[vrighter]

NAtural language isn't precise enough to describe exactly what's happening. If you do try to use natural language for that purpose, trying to eliminate ambiguity, you end up with legalese. And people can't read legalese, even though it's technically "plain english"