Build journal
AI FEATUREPractice 5 min read

AI-Graded Coding Challenge

Published Jul 7, 2026

Write code, run it in a sandbox, and get AI feedback — not just pass/fail, but line-level insight and a score.

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 draft and generated.
  • 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

  1. Open the lesson from /learn and read through the four sections. The challenge assumes you've seen the lesson's material, so skim key_principles and summary first if you're rusty.
  2. 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, and calculation exercises live. Find the Coding Challenge.
  3. 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.
  4. Write your solution in the editor. Start simple and get something running before you optimize.
  5. 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.
  6. 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.
  7. 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.
  8. 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:

SymptomLikely causeWhat to do
Code won't run, syntax/runtime errorA bug in your codeRead the stack trace in the sandbox output and fix the line it names
Runs locally in your head but sandbox errorsMissing import, wrong entry point, or language mismatchCheck the prompt's language and make the program self-contained
Submission spins, no grade returnsLLM provider quota/outage (LLMUnavailableError)Wait and resubmit — the pass isn't recorded, so nothing is lost
Score feels low despite correct outputGrader flagged style, edge cases, or clarityRead the line-level notes; correctness is necessary, not always sufficient
Sandbox unreachableExecution backend down or misconfiguredPing 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.

Published in build journal