Skip to content
John Ryan

Notes

Search notes and jump to a post. Press ⌘K (Mac) or Ctrl+K (Windows) to open anytime.

How I Actually Use Claude Code

Claude Code is most useful when the task is bounded, the repository supplies the context, and every result is verified before it ships.

  • claude-code
  • workflow
  • ai
  • productivity

Author: 2 min read

I get the least value from Claude Code when I ask it for a snippet.

I get the most value when I give it a bounded outcome and let it work inside the repository: read the code, follow the existing patterns, make the change, run the checks, and show me the diff.

That is the shift: stop asking for code. Delegate a result.

Give it an outcome and a boundary

“Refactor auth” is not a task. It is a direction with no stopping point.

“Add refresh-token rotation to the existing auth flow, follow the pattern in src/auth/session.ts, and run the auth tests” is a task.

The agent knows what success looks like, where to begin, and how to verify the work.

Let the repository provide the context

Generic prompts produce generic code. I point Claude Code at the implementation it should imitate, then let it inspect the surrounding files.

Persistent rules belong in CLAUDE.md: commands, architecture decisions, coding standards, and the checks required before handoff. Task-specific context stays in the prompt.

The best work is usually boring and precise:

  • Update a schema and every type that depends on it.
  • Change a shared component without breaking its callers.
  • Add edge-case tests to existing behavior.
  • Apply the same error-handling pattern across several routes.

These are tedious enough to rush manually and structured enough to verify automatically.

Verification is part of the task

I do not ask Claude Code to “make the change.” I ask it to make the change, run the relevant tests, inspect the diff, and report anything it could not verify.

Then I read the diff.

Tests catch regressions. The diff catches bad assumptions. Neither replaces the other.

Reset when the goal gets blurry

When one task turns into three, I stop and open a fresh session. Long context feels productive while quietly weakening the original boundary.

I also use a separate review pass before the PR:

What could fail here? Which edge cases are missing? What would a senior reviewer push back on?

It catches real issues. It still does not know the business context, team history, or tradeoffs I left out.

Claude Code does not replace engineering judgment. It moves the mechanical work closer to the machine and leaves the judgment visible in the diff.

Subscribe to my notes

Stay in the loop on what I'm building and thinking about.