Geoff,
I think one of the big differences with Clarion is that the instructions matter a lot more than they might with some of the more commonly used languages.
If I just ask an AI to “write some Clarion code,” I may still get code that looks plausible but has function names that do not exist, techniques borrowed from C#, JavaScript, or Python, or Clarion code that technically resembles Clarion but would not compile or would be a maintenance headache.
But if I give it specific instructions, the quality improves dramatically. Simple rules make a big difference. Some are coding patterns, some are personal preferences. For example:
Do not invent Clarion functions that do not exist.
Do not borrow syntax or coding patterns from other languages.
Do not assume a method exists unless it has been shown in the INC or CLW.
Use standard Clarion syntax.
Use full IF / END blocks.
Do not use one-line IF statements.
Do not use Clarion reserved words as variable names.
Do not scatter CLIP() everywhere unless it is actually needed.
That kind of guidance can be the difference between “interesting rough guide” and “usable code.”
I think this is especially important because Clarion is not represented in the training data at anything like the same level as C#, Python, JavaScript, or Java. So the AI needs a tighter harness. It needs examples, rules, and correction when it drifts.
The mistake, in my opinion, is treating AI as if it already knows your Clarion coding standards. It usually does not. But when you give it those standards clearly, and especially when you give it the existing INC and CLW files to work from, it can become much more useful.
So I would not say “AI writes perfect Clarion code now.” I would say that AI can write much better Clarion code when it is constrained, guided, and reviewed by somebody who actually knows Clarion.
Charles