AI-Graded Coding Challenge
Published Jul 7, 2026
Reading a lesson tells you whether you recognize an idea. Writing code tells you whether you can use it. The AI-Graded Coding Challenge closes that gap: every lesson ships a hands-on coding task in the /practice workspace where you write real code, run it in a real sandbox, and get back line-level feedback plus a score — not a bare green or red. This guide is for learners who want to prove a skill stuck, and for admins who curate and maintain those challenges.
What you'll need
- A published lesson. Challenges live alongside the lesson's exercises, so the lesson must be past
draftandgenerated. - A learner account (the practice workspace is login-gated).
- Nothing to install. Code executes remotely in a sandbox — wandbox by default, or a self-hosted piston if your instance is configured for it — so you never run untrusted code on your own machine or the server.
How to take a challenge
- Open the lesson from
/learnand read through the four sections. The challenge assumes you've seen the lesson's material, so skimkey_principlesandsummaryfirst if you're rusty. - Enter the practice workspace at
/practice/[lessonId]. This is the interactive space that sits outside the focused reading view — the same place your MCQ,fill_blank, andcalculationexercises live. Find the Coding Challenge. - Read the prompt carefully. It states the problem and any constraints. The grader judges against the intent of the task, so edge cases mentioned in the prompt are fair game.
- Write your solution in the editor. Start simple and get something running before you optimize.
- Run it in the sandbox. Your code is sent to the execution sandbox, compiled/interpreted, and run. You'll see real output — stdout, errors, stack traces — exactly as the runtime produced them. Iterate here as many times as you like; running is cheap and doesn't grade you.
- Submit for grading. When you're happy with the output, submit. Now the AI grader reads your code and its execution result, checks correctness against the task, and returns line-level feedback plus an overall score.
- Read the feedback, then revise. The grader points at specific lines — a missed boundary condition, a fragile assumption, a cleaner idiom — rather than just saying "wrong." Fix what it flags and resubmit.
- Pass it. When your submission clears the bar, the challenge is marked challenge-passed on your
LessonProgress. That flag feeds your completion percentage, accuracy, and streak on the Progress dashboard, and the lesson stops nagging you in the spaced-review schedule.
Tip: Run before you submit. Running exercises the sandbox and shows you real output for free; submitting is where the AI spends effort and grades you. Getting a clean run first almost always raises your score.
Why it grades, not just checks
A traditional autograder diffs your output against an expected string — it can only tell you that you failed. Praxis924 pairs two signals: the sandbox proves your code actually executes and produces the right result, and the AI grader reads the code to explain why it's right or wrong and how to improve it. That's the difference between "test 3 failed" and "line 12 mutates the list while iterating, which skips every other element." One is a verdict; the other is teaching.
When it goes wrong
The two systems fail in different ways, so read the signal you got:
| Symptom | Likely cause | What to do |
|---|---|---|
| Code won't run, syntax/runtime error | A bug in your code | Read the stack trace in the sandbox output and fix the line it names |
| Runs locally in your head but sandbox errors | Missing import, wrong entry point, or language mismatch | Check the prompt's language and make the program self-contained |
| Submission spins, no grade returns | LLM provider quota/outage (LLMUnavailableError) | Wait and resubmit — the pass isn't recorded, so nothing is lost |
| Score feels low despite correct output | Grader flagged style, edge cases, or clarity | Read the line-level notes; correctness is necessary, not always sufficient |
| Sandbox unreachable | Execution backend down or misconfigured | Ping an admin; wandbox/piston is an infra dependency, not your code |
Note: When the AI grader is unavailable, grading fails cleanly and your challenge stays re-runnable — exactly like lesson generation. You never get a phantom pass or lose progress because a provider was rate-limited.
For admins: reviewing and regenerating challenges
Challenges are authored the same way lesson content is, and you own them from the /admin console. Open the framework, then the lesson, and you can review a challenge — read its prompt and expected behavior — and regenerate it if the task is too easy, too vague, or off-topic for the lesson. Regeneration goes through the same LLM path (provider failover, response caching) as the rest of the pipeline, so a single flaky provider won't block you. Treat a challenge like any other section: if learners keep failing for the wrong reasons, the prompt probably needs a rewrite, not the learners.
What you get
A pass is more than a checkmark. You've written working code, seen it run in a real runtime, and gotten specific, actionable feedback on how to write it better — the loop that actually builds skill. On the dashboard it lifts your completion and accuracy and keeps your streak alive; in the spaced-review schedule it clears a lesson from the resurface queue. Next: open Lucy from the lesson to talk through anything the grader flagged, then move to the next lesson in the framework's timeline while the concept is fresh.