Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Why Claude Code matters for teams
What Claude Code can do
Settings should be hierarchical
Memory should be split by scope
Subagents help with context isolation
Hooks are powerful, but review them first
Rollout should be driven by shared policy
How it differs from GitHub-hosted background agents
Common mistakes
Recommended rollout sequence
References

Why Claude Code matters for teams

Claude Code is Anthropic’s agentic coding tool that lives in the terminal. That one design choice changes how teams use it. Instead of opening another chat window, it meets developers where they already work, can directly edit files, run commands, create commits, use MCP, and be scripted with claude -p.

That makes it closer to an execution layer than a conversational assistant.

What Claude Code can do

The official docs describe Claude Code as able to:

edit files directly
run commands
create commits
connect to external tools with MCP
run in scripted mode with claude -p

This makes it a strong fit for real work flow: local validation, refactoring, lint fixes, commit preparation, and repeatable terminal automation.

Settings should be hierarchical

Claude Code uses layered settings, which is ideal for teams.

~/.claude/settings.json is the user-wide layer
.claude/settings.json is the shared project layer
.claude/settings.local.json is the private local layer

The practical benefit is clean separation. Team defaults live in the repository, while personal experiments stay local.

Memory should be split by scope

The memory docs are just as important as the settings docs.

./CLAUDE.md is project memory
~/.claude/CLAUDE.md is user memory
enterprise policy memory applies across the organization

For most teams, ./CLAUDE.md should hold project structure, build steps, test commands, common pitfalls, and review norms. User memory should hold personal shortcuts and preferences.

Subagents help with context isolation

Claude Code subagents use separate context windows and can be configured with specific tools. That is a big deal for larger repos.

a review subagent
a test-writing subagent
a docs subagent
a migration subagent

Splitting work this way keeps the main session from becoming overloaded and makes behavior more consistent.

Hooks are powerful, but review them first

Hooks let Claude Code run shell commands at key points in execution. They are useful for validation, logging, security checks, and workflow automation. But the docs are explicit: review and understand hook commands before adding them.

Good practice looks like this:

read the command before enabling it
use absolute paths for scripts
exclude sensitive files
keep validation hooks separate from destructive actions

Hooks are best treated as controlled automation, not as a place to improvise.

Rollout should be driven by shared policy

The safest rollout path is process-first.

Put project conventions in CLAUDE.md.
Keep shared settings in .claude/settings.json.
Leave personal preferences in .claude/settings.local.json.
Restrict dangerous commands with deny or permissions rules.
Review hooks before they ship.
Split recurring workflows into subagents.

This gives the team a shared baseline while still leaving room for local experimentation.

How it differs from GitHub-hosted background agents

Claude Code is terminal-first. It works in the same shell where developers already think and test. GitHub Copilot cloud agent is GitHub-first. It works through issues, branches, pull requests, and review loops inside GitHub.

That difference matters:

use Claude Code when you want local, interactive, command-level control
use a GitHub-hosted agent when you want asynchronous delegation inside the repo workflow
use Claude Code when policies, settings, and hooks need to be very explicit

They are complementary tools for different parts of the development process.

Common mistakes

The most common mistakes are surprisingly ordinary:

using CLAUDE.md as a personal note instead of a project contract
mixing shared settings and local-only settings
letting one giant session do everything instead of using subagents
adding hooks without inspection
expanding MCP access too quickly

Hooks deserve special care because they can turn into the riskiest part of the workflow if they are not reviewed.

Recommended rollout sequence

Start with CLAUDE.md and project conventions.
Separate shared settings from local settings.
Introduce subagents for repeated tasks.
Add MCP only where the extra context is truly needed.
Start hooks with validation use cases first.
Tighten command permissions and sensitive-file restrictions.

That sequence keeps the speed advantages of terminal automation without giving up team safety.