Backward mode — start from your working solution

How to use Backward mode when you already wrote the answer and want the AI to strip it into a fill-in-the-blanks lab. Best for converting your own reference implementation into student work.

Written By Alan Gandy

Last updated About 1 month ago

Backward mode is for instructors who write the answer first. You provide a working, tested solution; the AI strips it into a starter with TODOs for students to fill in, then writes tests against the original solution.

Pick this mode when you have a complete working implementation and want to turn it into a graded assignment. Common cases: converting your own reference code into student work, adapting a worked example from a textbook, or re-using a project you wrote during prep.

If you already have starter code with TODOs, use Forward mode. If you have both starter and solution, use Both Provided for highest control. If you have only prose, use From Document.

Backward mode selected — Solution Code field is required, with paste / upload / from-repo input options

The form

After clicking Backward on the mode card, the form changes to show Solution Code (required) as the main input. Three ways to provide it (paste / upload / from-repo), same as Forward.

The rest of the form is shared across modes — see Picking a generation mode for the cross-mode fields.

How "stripping" actually works

The AI looks at each top-level function in your solution and decides what to remove based on the difficulty level you picked:

  • Beginner — rips out only the inside of the most challenging function(s); keeps helper functions intact. Instructions.md will show complete code.
  • Intermediate — rips out most function bodies. Instructions.md gives partial snippets and pseudocode.
  • Advanced — rips out everything except signatures. Instructions.md describes requirements only — no code.

Difficulty matters a lot here. See Choosing a difficulty level before picking, especially in Backward mode where it shapes both the starter AND the instructions.

You can adjust the strip aggressiveness after generation by editing the Starter tab on Review directly.

Solution code that strips well — four habits

Break logic into named functions. A 200-line main() with everything inline gives the AI nothing to strip cleanly. Refactor into helpers that each do one thing — parse_input(), compute_score(), format_output(). The AI gets obvious unit boundaries to remove.

Use type hints / explicit types. In Python or TypeScript, type hints become the contract students implement against. In Java, C#, Go, or Rust, the explicit types do the same. Without types, the AI has to invent them when stripping.

Avoid one-line tricks if you want students to learn the long form. The AI preserves clever one-liners like return sum(x*x for x in nums), which means the student sees only the one-liner and never walks through the loop. Write it longhand if walking through the logic is the lesson.

Include real edge cases in your solution. If your code handles empty input, negative numbers, or off-by-one boundaries carefully, the AI sees those branches and writes test cases for them. Sloppy solutions produce sloppy test coverage.

What happens after you click Generate

Same four-step pipeline as Forward mode:

  1. Generate starter by stripping your solution
  2. Generate tests against your solution
  3. Generate Instructions.md scaled to the difficulty
  4. Sandbox check — runs your solution against the tests to confirm

Usually 1–3 minutes. The assignment moves to Review & Edit when done.

In Backward mode, the Starter tab on the Review screen is the most important thing to read — that's where you confirm the strip didn't go too aggressive (students see no signposts) or too soft (the answer is half-given). Edit directly if needed; click Regenerate if it's structurally wrong.

Common pitfalls

Solution still has placeholder code. If your "solution" has # TODO finish this or pass somewhere, the AI gets confused — is that a TODO meant for students, or your dev TODO? Clean it up first so it actually runs end-to-end.

Solution depends on external services. HTTP requests, database queries, API keys — none of these run in the autograder sandbox. Refactor to take inputs as parameters or read from stdin so the autograder can run the function with controlled inputs.

Solution prints debug output. The autograder compares stdout exactly. A stray print("DEBUG: …") or logging call will make every Exact-match test fail. Strip debug prints before submitting.

Tests look weird after generation. Sometimes the AI infers the wrong notion of "what to test" — for instance, testing implementation details instead of input/output behaviour. Open the Tests tab on Review and edit, add, or remove tests directly. Re-run validation after.

Where to go next

  • Generation finished?The Review & Edit screen — pay extra attention to the Starter tab in Backward mode.
  • Strip went too aggressive (students see nothing)? → Edit the Starter tab to add scaffolding back, or re-generate at a lower difficulty.
  • Strip went too soft (answer is half-given)? → Edit the Starter tab to remove more, or re-generate at a higher difficulty.