Claude Code Series Tutorial 4: What Are the Use Cases of Claude Code?

Typical Use Cases

I categorize use cases into four types, listed in descending order of frequency.

Category 1: Understanding Code

This is probably the most common type. When taking over someone else's project, looking at an old module, or opening a repository without documentation, just ask it.

Specific practices:

claude "What is this project about? Where is the entry point?" — It reads package.json, directory structure, and key files, and gives an overview.
Open a function and have it explain the logic, outline the flow (using text).
Have it trace the complete path of an API request from frontend to database.

What it does here is essentially the "dirty work of code reading." You don't need to grep around for a long time and then piece things together in your mind. It organizes the path, and you make the judgments.

This scenario replaces: Manually searching through the codebase, taking notes, and drawing call graphs.

Category 2: Writing and Modifying Code

This is the most discussed category, but it's actually not the most frequent. Scenarios for writing code usually go like this:

Generating new features: "Add an endpoint to change the email under the user module. Validate the email format and write unit tests."
Cross-file refactoring: "Replace all moment() calls in these three files with dayjs(), without changing other logic."
Migration and upgrade: "Convert this Vue 2 component to Vue 3 Composition API syntax."

The code it generates may not be perfect at once, but it can make cross-file changes all at once, and you can diff file by file, accepting or rejecting changes one by one.

This scenario replaces: Manually writing repetitive code, manually searching and replacing cross-file references.

Category 3: Debugging and Fixing

When a bug appears, the usual workflow is: look at the error, locate the file, guess the cause, try a fix, and if it doesn't work, go back and examine again. Claude Code can directly take the entire error stack, combine it with the project code, and locate the issue.

Typical usage:

Feed it the output of a failed test; it reads the relevant code, gives a fix solution, then runs the test again to check if it passes.
When encountering a CI error, paste the log, have it fix it, then run git diff to confirm changes.

Here, it acts more like a "first-round troubleshooter." You spend time thinking about the problem, but it does the file searching, comparison, and running verification commands.

This scenario replaces: Repeatedly running tests, reading error logs, manually comparing code differences.

Category 4: Miscellaneous Automation

This category is the least noticeable, but combined, it saves the most time.

Examples:

Writing Git commit messages: claude "Write a Conventional Commits format commit message based on the current git diff"
Generating PR descriptions: Have it compare the current branch with main and produce a summary of changes and test instructions.
Writing release notes: Let Claude Code read the commit history from the last week and generate a CHANGELOG.
Answering environment issues: "This dependency installation errored. Help me check the terminal output and find the cause."

These tasks have one thing in common: not complex, but tedious. Doing them yourself requires switching windows and typing a lot. Hand them over to Claude Code, and it's done in seconds.

This scenario replaces: Manual text editing, writing standard documentation, searching for environment configuration issues.

A "Map"

Putting these four categories into a daily workflow looks something like this:

Get an unfamiliar project
    │
    ▼
[Understand Code] ─── Figure out the structure, entry point, key logic
    │
    ▼
Start writing new features or modifying modules
    │
    ▼
[Write/Modify Code] ─── Generate implementation, cross-file refactoring
    │
    ▼
Run tests, encounter bugs
    │
    ▼
[Debug and Fix] ─── Analyze errors, locate, fix, re-run
    │
    ▼
Prepare to commit
    │
    ▼
[Miscellaneous Automation] ─── Write commit, PR description, release notes
    │
    ▼
Commit, done

You don't need to use it across all four quadrants. Some teams only use it for understanding code, others only for writing tests and sending PRs. Start with the scenario that troubles you the most.

Two Useful Criteria

If you're unsure whether to delegate something to Claude Code, ask yourself two questions:

1. Is this task more "mechanical" than "creative"?

Changing a hundred references, formatting output, generating boilerplate code — doing these yourself cumulatively takes a lot of time, but you already have the idea. Suitable to hand over.

2. Is the "verification cost" high?

If a modification requires repeated jumps, tests, and log checks to confirm, then manual trial and error is slow. Claude Code can complete the "change-run-check-rechange" loop on its own, making things much easier for you.