Rahme die KI so ein, dass sie deine Arbeit über Hinweise und ein Bewertungsraster beurteilt, ohne je deinen Code für dich neu zu schreiben.
Diese Lektion in Kodokon öffnenDu hast eine Übung beendet und willst wissen, wie gut sie ist. Der natürliche Reflex - deinen Code mit "repariere das für mich" einzufügen - ist ein strategischer Fehler: Die KI schreibt deine Lösung besser neu, du liest sie, nickst… und hast nichts gelernt. Eine nützliche Korrektur sagt dir, wo du danebenlagst, und lässt dich es selbst reparieren. Genau das solltest du verlangen.
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.Die Hierarchie in Regel 4 ist eine direkt aus der Berufswelt importierte Gewohnheit: In einem Code-Review unterscheidest du immer, was kaputtgeht (Bug), was kaputtgehen wird (Grenzfall: leeres Array, negativer Wert, Text statt Zahl) und was stört (Stil, Benennung). Feedback nach Schweregrad sortieren zu lernen, bereitet dich auf die echten Code-Reviews vor, die du im Team erleben wirst.
Um über ein einfaches "richtig oder falsch" hinauszugehen, frage nach einem Bewertungsraster. Eine nach Kriterien aufgeschlüsselte Punktzahl macht aus einem vagen Eindruck eine präzise Diagnose: Du siehst sofort, ob deine Schwachstelle die funktionale Korrektheit, die Behandlung von Grenzfällen oder die Lesbarkeit ist - und damit, woran du zuerst arbeiten solltest.
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.Der vollständige Arbeitszyklus, den du dir als professionelle Routine merken solltest: Du löst allein, du reichst mit dem Prüfer-Prompt ein, du erhältst lokalisierte Hinweise, du reparierst selbst, du reichst erneut ein - und erst wenn deine Fassung standhält, darfst du fragen: "Jetzt, wo meine Lösung korrekt ist, zeig mir, wie ein erfahrener Entwickler sie geschrieben hätte, und erkläre jeden Unterschied." In diesem Stadium ersetzt der Vergleich dein Lernen nicht mehr: Er krönt es.