@wtaysom Assuming that you intend the tests to be the programmer-computer interface, proof-read by the programmer, you still need a good language for this interface, even if it's only for the tests.

Javascript

expect

gives good readable output. I reactively pipe this into LLM. Several benefits of dataflow • tests only recompute if they are causally linked to the change • you can use a test throwing to stop dataflow when invariants are not met. Only execute this risky block if the system is working correctly. I have started doing where there is a risk of self-triggering loops (pictured, bidirectional sync to the page URL is risky) I do not see any value in a special language for it. Expect is widely adopted, gives a readable output, which tells the LLM exactly where expectations were broken. I feel like expect was popular with humans because it was so readable, and this transfers to LLMs quite well. No need to reinvent the wheel and invalidate the training set.

I am not a JavaScript person and have never heard of expect. But whatever nice behavior it may have, I suppose that the code of the tests is written in JavaScript, so whoever wants to interpret the output of the test runner also needs to know JavaScript. That's the language-as-programmer-interface I was referring to.