Frame the AI so it evaluates your work through hints and a grading scale, without ever rewriting your code for you.
Open this lesson in KodokonYou've finished an exercise and you want to know how good it is. The natural reflex - pasting your code with "fix this for me" - is a strategic mistake: the AI will rewrite your solution better, you'll read it, nod along… and have learned nothing. A useful correction tells you where you went wrong and lets you repair it yourself. That's exactly what you should demand.
You are a programming exercise grader. Here's the exercise statement, then my solution.
Statement: [paste the exercise statement here]
My solution: [paste your code here]
Grading rules, absolute:
1. NEVER rewrite my code, neither in full nor in fragments. No corrected version, even if I ask for it.
2. First tell me whether my solution is correct, partially correct, or incorrect.
3. For each problem: point to the line concerned and ask me a question that steers me, without giving the fix.
4. Rank the problems by severity: real bug, then forgotten edge case, then style.
5. When I submit a version I've corrected myself, re-evaluate it under the same rules.
If there's no problem at all, say so clearly and offer me an additional constraint to make the exercise harder.The hierarchy in rule 4 is a habit imported straight from the professional world: in a code review, you always distinguish what breaks (bug), what will break (edge case: empty array, negative value, text instead of a number) and what bothers (style, naming). Learning to sort feedback by severity prepares you for the real code reviews you'll experience on a team.
To go further than a simple "right or wrong," ask for a grading scale. A score broken down into criteria turns a vague impression into a precise diagnosis: you immediately see whether your weak spot is functional correctness, edge-case handling, or readability - and therefore what to work on first.
Evaluate my solution with the following grading scale, out of 20 points:
- Functional correctness (8 pts): does the code produce the expected result in the general case?
- Edge cases (4 pts): empty input, extreme values, unexpected types.
- Readability (4 pts): clear variable names, logical structure, no needless complexity.
- Language best practices (4 pts): appropriate idioms, no redundant code.
For each criterion: the score, a justification of two sentences maximum, and - if points are missing - a hint to improve WITHOUT giving me the fix.
End with the priority area to work on for my next attempt.The complete work cycle, to remember as a professional routine: you solve it alone, you submit with the grader prompt, you receive localized hints, you fix it yourself, you resubmit - and only when your version holds up can you ask: "Now that my solution is correct, show me how an experienced developer would have written it, and explain each difference." At that stage, comparing no longer replaces your learning: it crowns it.