Code Review with Claude Code

Lesson 21

Claude Code is not just a code generator — it’s one of the best code reviewers you have access to. Using it only to generate code wastes half its value. Once you have working code, run it through a review pass before considering the feature done.

The four review dimensions

Every review prompt should target one of these four dimensions:

Performance — Are there unnecessary DOM queries, redundant repaints, or O(n²) loops?

이 코드에서 성능 문제를 찾아줘.
구체적인 개선 방법을 코드로 보여줘.

Accessibility — Can keyboard-only users interact with everything? Do screen readers get the right information?

접근성 관점에서 개선할 점을 aria 속성과 함께 알려줘.

Maintainability — Is there repetition that should be a function? Are there magic numbers that should be constants?

이 코드를 리팩토링해줘. 반복이 너무 많아.

Security — Is user input sanitized? Are there XSS or injection risks?

이 폼에 보안 취약점이 있어? XSS 가능성 포함해서.

What to do with the review

The review output is a list of issues. For each one, decide: patch (fix the specific line) or rewrite (the design is wrong, start the section over). Most issues are patches. A rewrite is warranted when the core approach is flawed — for example, using innerHTML for user content isn’t a bug to patch; it’s an approach to replace.

For patches, copy the specific issue into a new prompt and ask for just that fix. Don’t ask Claude Code to fix all issues at once — reviewing a large diff is harder than reviewing small targeted changes.

The “explain while fixing” modifier

When you’re learning, always add this to review prompts:

고쳐줄 때 왜 이게 문제인지도 설명해줘.

This turns every fix into a teaching moment. Over time, you start catching these issues yourself before asking for a review.

Building the review habit

A practical workflow: after every feature is working (Phase 3 from the previous lesson), run a one-line review prompt before moving to Phase 4 polish. If the review finds performance or security issues, fix them before adding animations. Polish on top of broken fundamentals is polish wasted.

The demo shows four before/after code review scenarios — one per dimension. Each card lets you toggle between the problematic code and the improved version, with an explanation of what was wrong and why the fix works.