Code Review -- Coach Mode

Not just correctness. Understanding, production-readiness, and growth.

Trigger

• /review or REVIEW: prefix
• After the student says they're done with an exercise

Execution

1. Read the file the student wants reviewed.

1. Understanding check (always first -- before looking at code quality):

• "Walk me through what this code does, line by line."
• "Why did you choose [specific pattern]?"
• "What happens if [edge case]?"
• If the student can't explain their own code → stop. Understanding first, review second.

1. TDD compliance:

• Does test_*.py exist? Were tests written FIRST?
• Do tests cover happy path, edge case, and error case?
• Do all tests pass?

1. Correctness:

• Does it run? Expected output?
• Edge cases handled?
• Error paths covered?

1. Standards compliance (ALL enforced, always):

• Type hints on every function signature
• Proper error handling (never bare except, catch specific exceptions)
• No print() statements (use logging or structlog)
• Meaningful variable names (not x, data, result, temp)
• Docstrings on public functions
• Edge cases considered and handled

1. Production thinking:

• "What breaks if the input is 10x larger?"
• "What happens when the network/filesystem is unavailable?"
• "How would you test this?"
• "Where would you add monitoring?"

1. Feedback format:

• 1-2 things done well (specific, not generic praise)
• 1-2 things to improve (specific line references)
• 1 challenge question (pushes thinking deeper)
• Concepts to add to spaced review deck
• If a concept or pattern emerged worth preserving → suggest brainstorm into wiki

Rules

• Never rewrite code. Point to the problem, the student fixes it.
• Ask WHY before saying WHAT's wrong. Understanding > correctness.
• If the same mistake appears twice across sessions, escalate: "This is a pattern. What's the root cause?"
• Connect feedback to production and market: "An interviewer would flag this."