How I Actually Use Claude Code in My Daily Engineering

How I used Claude Code efficiently, in real time, for my daily engineering at Spritle.

I'm Claude Certified Architect CCA-F now. While preparing for CCA-F, and after it, I found a lot of methodologies to use Claude Code wisely. But in real time, there are many that we cannot implement in fast-paced development. After a lot of trial and error, I gradually adjusted a little with my personal experience and found some really practical methods to continue with Claude Code.

I also wrote a shorter take on this on dev.to.

1. CLAUDE.md in local

Have strict instructions with examples. For instance:

• How you code manually before vibe coding
• How the AI should explain the changes
• What the permissions are, and how it should ask for them
• Your coding style and tone

Here is a sample to start from. Change it to your own style:

# Global instructions

## How I code
- Small functions, each doing one job
- Clear names over short names: write getUserById, not gub. Also not too long
- Handle errors explicitly, never swallow them
- Follow the existing patterns in the project before introducing new ones
- DRY and no lengthy code, break into chunks of methods

## How to explain changes
After every change, tell me:
1. What you changed, and in which files
2. Why you changed it
3. Anything I should double-check
4. Don't explain in paragraph

## Permissions
- Ask me before creating, deleting or renaming files
- Ask me before installing any package
- Never run database write operations or migrations without my approval
- Never read .env files, keys or secrets
- Tell why need the permission, what going to do 

## Tone
- Short and direct, no long introductions
- If you are not sure, ask me. Don't guess.

2. Hooks

Before anything else, set up custom hooks to prevent the agent from reading sensitive files and keys.

Here is a sample. First, register the hook in ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Edit|Write|Grep|Glob|Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/block-sensitive-files.sh"
          }
        ]
      }
    ]
  }
}

Then create the script at ~/.claude/hooks/block-sensitive-files.sh and make it executable with chmod +x:

#!/bin/bash
# Blocks the agent from touching sensitive files

input=$(cat)
target=$(echo "$input" | jq -r '.tool_input.file_path // .tool_input.path // .tool_input.command // ""')

if echo "$target" | grep -Eiq '\.env|\.pem|\.key|id_rsa|secret|credential'; then
  echo "Blocked: this may contain sensitive data." >&2
  exit 2
fi

exit 0

Exit code 2 blocks the action and sends the message back to Claude. Change the file patterns to match what is sensitive in your projects. The script uses jq, so install it if you don't have it.

3. CLAUDE.md in project

Set this up first. Give Claude some needed ideas about the project and a little of its scope. Don't give too much data here. If any feature needs depth, use skills.

4. Utilize the skill files

A skill file keeps the detail that doesn't belong in CLAUDE.md, like how a feature works or a finalized plan. Claude loads it only when it's needed, so the main files stay light.

5. Keep the architecture and DB design accessible to Claude Code

For any new feature, even if the plan looks good, we need to check it against the existing structure. So keep that available.

6. Go with plan first

This doesn't mean plan mode. Yes, we need to use plan mode for the initial feature, but I recommend doing the plan yourself first.

1. Do the plan yourself first.
2. Propose your requirement and your plan, and debate it with Claude Code in plan mode.
3. After that, you will get a clear picture.
4. Once the plan is finalized, create a skill file from it for later use.

7. Utilize artifacts

Sometimes we get a giant plan from Claude Code, and reviewing it in the terminal is hard. It's better to read and approve it in a UI. It's also useful for the future.

8. Task splits

When the task is small, it's good. But if the task is big, it gets confusing and it's hard to understand what it's doing.

So, just like we do manually, we split the big feature into tasks. Here, split the tasks into small chunks of to-dos. That way you have a clear vision of what it's doing, and it's easy to stop if anything goes wrong.

9. Renaming

Use the same session by renaming it, so the context stays clear.

10. Be cautious with DB operations

Check any database operation yourself before it runs, like queries, migrations, or anything that changes data. Don't give blanket permission for these. Code can be reverted easily, but data often can't.

11. Test cases

Test cases should not be generated autonomously.

• Ask the agent to give the scenarios first.
• Review them, and only once you approve should it create the tests.
• Also, set a size for the files while approving.

12. Two-branch approach

I learned this after a long time. Usually we work in a feature branch, raise a PR to dev, and then review. If it's a small chunk, it's good and easy to review. But with vibe coding, it's heavy to review. Even if we use another AI agent in the CI/CD pipeline for review, we still need to review manually, right? So use the two-branch approach.

If you're going to build a feature, create two branches: feature and feature-draft.

• Merge the completed small chunks of code from feature-draft into feature. This gives good visibility and makes it easy to review.
• Then merge feature into main.

13. Review with another Claude session

Review with another Claude session before merging or raising a PR.

I hope this will be helpful for developers.