Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Code Reviews With Claude: Explaining and Improving Existing Code

Code Reviews With Claude: Explaining and Improving Existing Code

~6 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026

Not every request to Claude Code has to be a new feature or a bug fix. A code review - having existing code critically examined without necessarily changing anything - is a useful use case in its own right. In this chapter you'll have src/recipes.js from the recipe planner explained and improved.

Having existing code explained

Especially in a project that has grown over time, or one you didn't write yourself, it's worth starting with a pure explanation question before even talking about changes:

Terminal
> Explain src/recipes.js function by function: what does each function do, and what could go wrong if it's used incorrectly?

Claude Code reads the file with the Read tool from chapter 6 and walks through the functions one by one - for example noting that loadRecipes() throws an error if data/recipes.json is missing or contains invalid JSON, without that error being caught anywhere.

Asking specifically for improvement suggestions

Based on that explanation, you can ask specifically for improvements:

Terminal
> What would you improve about src/recipes.js, without changing behaviour for existing callers? Suggest it, but don't change anything yet.

The addition "don't change anything yet" is deliberate: it gets you a list of suggestions you can decide on calmly, instead of the whole file being rewritten right away. A typical set of suggestions for recipes.js:

  • Add error handling for when data/recipes.json is missing or corrupted.
  • A small, dedicated validation function for new recipes (title must not be empty, ingredient list must not be empty).
  • A clearer error, instead of a generic JavaScript error, when a recipe with an unknown id is looked up.

Implementing suggestions selectively

From that list, you pick specifically what should actually be implemented - for example just the validation, since it's needed for the next feature anyway:

src/recipes.js
/** Validates a new recipe before it gets stored. Throws with a clear message if invalid. */
export function validateRecipe(recipe) {
  if (!recipe.title || recipe.title.trim() === "") {
    throw new Error("A recipe needs a title.");
  }
  if (!Array.isArray(recipe.ingredients) || recipe.ingredients.length === 0) {
    throw new Error("A recipe needs at least one ingredient.");
  }
}

Code reviews for your own and other people's code

The same pattern - have it explained, gather suggestions, pick selectively - works just as well for code you wrote yourself ("Did I make a logic mistake here?") as for code you inherited from someone else or find in an existing library.

Tipp: Actively use code reviews as a learning tool, too: ask Claude Code to justify a particular design decision in the code ("Why is Array.some() used here instead of a for loop?"). That deepens your own understanding, instead of just blindly accepting changes.