Hi Sjoerd
Good to hear that you're keen on CodeRunner. Welcome aboard.
The Sample Answer field in the question authoring form is for the question author to provide a sample solution, which in Moodle's context is taken to be "the" correct answer. The quiz settings page lets you select, under "Review options", when this answer is displayed to students. Usually we turn it off altogether, to lessen the risk of students passing it around or adding it to a database of "known right answers" (though that's a pretty sad reason), and instead use the sample answer for testing. [When previewing a question you can load that sample answer directly into the answer box with a single button click, then check it.]
A couple of other users have asked for the ability to pre-load the answer box with skeleton code. I've posted a lengthy discussion here.
Since my last posting on that issue, I've put a bit more effort into finding a solution I'm happy with. I'm proposing to add annotations to the sample answer which permit the question author to designate which bits of it should be preloaded into the student's question answer field. I wish to keep alive the option of adding a write-protect capability to the Ace code editor so that the author can additionally lock all or parts of the pre-loaded question answer from being modified by the student. For compatibility with the rest of CodeRunner I'm further proposing to use Twig syntax for the annotations; the Twig engine is very flexible and can be programmed to generate two output streams from the input sample answer, viz. the actual runnable answer and the code to be preloaded into the answer box. The latter itself needs to be annotated with "read only" attributes for use by Ace, even though such a capability will not be part of the initial implementation. I've got a prototype of the Twig processing phase working, but I'm not yet happy with the syntax and don't wish to go ahead until I am happy that it's a good final solution.
To summarise: I still hope to implement such an answer-preload feature "reasonably soon", but design decisions, other priorities and teaching pressures have put the project on hold for a bit. Stay tuned! In the meantime, please use one of the approaches I suggested in my original response on GitHub.
-- Richard