1. 터미널에서 5개의 Claude를 병렬로 실행합니다. 탭에 1-5번을 매기고, 시스템 알림을 사용하여 Claude에 입력이 필요한 시점을 파악합니다. https://code.claude.com/docs/en/terminal-config#iterm-2-system-notifications

  2. 로컬 Claude와 병렬로 http://claude.ai/code에서 5-10개의 Claude를 실행하기도 합니다. 터미널에서 코드를 작성하는 동안 로컬 세션을 웹으로 인계하거나(& 사용), Chrome에서 수동으로 세션을 시작하기도 하며, 때로는 —teleport를 사용하여 앞뒤로 이동합니다. 매일 아침과 하루 중 여러 번 휴대폰(Claude iOS 앱에서)에서 몇 가지 세션을 시작하고 나중에 확인합니다.

  3. 모든 작업에 Opus 4.5를 생각(thinking) 기능과 함께 사용합니다. 제가 사용해 본 코딩 모델 중 최고이며, Sonnet보다 크고 느리지만, 조정할 필요가 적고 도구 사용 능력이 더 뛰어나기 때문에 결국 작은 모델을 사용하는 것보다 거의 항상 더 빠릅니다.

  4. 저희 팀은 Claude Code 리포지토리를 위해 단일 CLAUDE.md 파일을 공유합니다. 이 파일을 git에 체크인하고 팀 전체가 일주일에 여러 번 기여합니다. Claude가 잘못된 작업을 수행하는 것을 볼 때마다 CLAUDE.md에 추가하여 Claude가 다음에 동일한 작업을 수행하지 않도록 합니다. 다른 팀들은 자체 CLAUDE.md 파일을 유지 관리합니다. 각 팀의 임무는 자신의 파일을 최신 상태로 유지하는 것입니다.

  5. 코드 검토 중에 동료의 PR에 @.claude를 태그하여 PR의 일부로 CLAUDE.md에 내용을 추가하는 경우가 많습니다. 이를 위해 Claude Code Github 액션(/install-github-action)을 사용합니다. 이는 @danshipper의 Compounding Engineering과 유사한 저희 버전입니다.

  6. 대부분의 세션은 계획 모드(shift+tab 두 번)로 시작됩니다. 제 목표가 Pull Request를 작성하는 것이라면 계획 모드를 사용하여 Claude와 앞뒤로 소통하며 계획에 만족할 때까지 작업합니다. 그 후 편집 자동 수락 모드로 전환하면 Claude가 보통 한 번에(1-shot) 완료할 수 있습니다. 좋은 계획이 정말 중요합니다!

  7. 하루에 여러 번 반복하는 모든 “내부 루프” 워크플로에 슬래시 명령어를 사용합니다. 이렇게 하면 반복적인 프롬프팅을 피할 수 있고 Claude도 이러한 워크플로를 사용할 수 있게 됩니다. 명령어는 git에 체크인되어 .claude/commands/에 저장됩니다. 예를 들어, Claude와 저는 /commit-push-pr 슬래시 명령어를 매일 수십 번 사용합니다. 이 명령어는 인라인 bash를 사용하여 git 상태 및 기타 몇 가지 정보를 사전 계산하여 명령어를 빠르게 실행하고 모델과의 앞뒤 소통을 피합니다. https://code.claude.com/docs/en/slash-commands#bash-command-execution)

  8. 저는 몇 가지 하위 에이전트(subagent)를 정기적으로 사용합니다. code-simplifier는 Claude가 작업을 마친 후 코드를 단순화하고, verify-app은 Claude Code를 엔드투엔드로 테스트하기 위한 상세 지침을 가지고 있습니다. 슬래시 명령어와 마찬가지로 하위 에이전트도 대부분의 PR에 대해 수행하는 가장 일반적인 워크플로를 자동화하는 것으로 생각합니다. https://code.claude.com/docs/en/sub-agents

  9. 저희는 Claude가 생성한 코드를 포맷하기 위해 PostToolUse 후크를 사용합니다. Claude는 일반적으로 바로 잘 포맷된 코드를 생성하지만, CI에서 나중에 포맷 오류가 발생하는 것을 방지하기 위해 후크가 마지막 10%를 처리합니다.

  10. --dangerously-skip-permissions를 사용하지 않습니다. 대신 /permissions를 사용하여 제 환경에서 안전하다고 알고 있는 일반적인 bash 명령어를 미리 허용하여 불필요한 권한 프롬프트를 피합니다. 이들 중 대부분은 .claude/settings.json에 체크인되어 팀과 공유됩니다.

  11. Claude Code는 제 모든 도구를 대신 사용합니다. 종종 Slack에 검색 및 게시(MCP 서버를 통해), 분석 질문에 답하기 위해 BigQuery 쿼리 실행(bq CLI 사용), Sentry에서 오류 로그 가져오기 등을 수행합니다. Slack MCP 구성은 .mcp.json에 체크인되어 팀과 공유됩니다.

  12. 매우 오래 걸리는 작업의 경우, (a) 작업 완료 시 백그라운드 에이전트를 사용하여 작업 확인을 Claude에 요청하거나, (b) 에이전트 Stop 후크를 사용하여 이를 더 결정론적으로 수행하거나, (c) (원래 [이미지 참조]에 의해 구상된) ralph-wiggum 플러그인을 사용합니다.

  13. 마지막 팁: Claude Code에서 훌륭한 결과를 얻기 위한 가장 중요한 사항은 Claude에게 작업 확인 수단을 제공하는 것입니다. Claude가 해당 피드백 루프를 갖게 되면 최종 결과의 품질이 2-3배 향상됩니다. Claude는 제가 http://claude.ai/code에 커밋하는 모든 변경 사항을 Claude Chrome 확장을 사용하여 테스트합니다. 브라우저를 열고 UI를 테스트하며, 코드가 작동하고 UX가 좋다고 느껴질 때까지 반복합니다. 검증은 도메인마다 다릅니다. bash 명령 실행, 테스트 스위트 실행, 브라우저나 휴대폰 시뮬레이터에서 앱 테스트와 같이 간단할 수 있습니다. 이 검증 프로세스를 견고하게 만드는 데 투자하세요.

============================================================== 원문

  1. I run 5 Claudes in parallel in my terminal. I number my tabs 1-5, and use system notifications to know when a Claude needs input https://code.claude.com/docs/en/terminal-config#iterm-2-system-notifications

  2. I also run 5-10 Claudes on http://claude.ai/code, in parallel with my local Claudes. As I code in my terminal, I will often hand off local sessions to web (using &), or manually kick off sessions in Chrome, and sometimes I will —teleport back and forth. I also start a few sessions from my phone (from the Claude iOS app) every morning and throughout the day, and check in on them later.

  3. I use Opus 4.5 with thinking for everything. It’s the best coding model I’ve ever used, and even though it’s bigger & slower than Sonnet, since you have to steer it less and it’s better at tool use, it is almost always faster than using a smaller model in the end.

  4. Our team shares a single CLAUDE.md for the Claude Code repo. We check it into git, and the whole team contributes multiple times a week. Anytime we see Claude do something incorrectly we add it to the CLAUDE.md, so Claude knows not to do it next time. Other teams maintain their own CLAUDE.md’s. It is each team’s job to keep theirs up to date.

  5. During code review, I will often tag @.claude on my coworkers’ PRs to add something to the CLAUDE.md as part of the PR. We use the Claude Code Github action (/install-github-action) for this. It’s our version of @danshipper ‘s Compounding Engineering

  6. Most sessions start in Plan mode (shift+tab twice). If my goal is to write a Pull Request, I will use Plan mode, and go back and forth with Claude until I like its plan. From there, I switch into auto-accept edits mode and Claude can usually 1-shot it. A good plan is really important!

  7. I use slash commands for every “inner loop” workflow that I end up doing many times a day. This saves me from repeated prompting, and makes it so Claude can use these workflows, too. Commands are checked into git and live in .claude/commands/. For example, Claude and I use a /commit-push-pr slash command dozens of times every day. The command uses inline bash to pre-compute git status and a few other pieces of info to make the command run quickly and avoid back-and-forth with the model https://code.claude.com/docs/en/slash-commands#bash-command-execution)

  8. I use a few subagents regularly: code-simplifier simplifies the code after Claude is done working, verify-app has detailed instructions for testing Claude Code end to end, and so on. Similar to slash commands, I think of subagents as automating the most common workflows that I do for most PRs. https://code.claude.com/docs/en/sub-agents

  9. We use a PostToolUse hook to format Claude’s code. Claude usually generates well-formatted code out of the box, and the hook handles the last 10% to avoid formatting errors in CI later.

  10. I don’t use —dangerously-skip-permissions. Instead, I use /permissions to pre-allow common bash commands that I know are safe in my environment, to avoid unnecessary permission prompts. Most of these are checked into .claude/settings.json and shared with the team.

  11. Claude Code uses all my tools for me. It often searches and posts to Slack (via the MCP server), runs BigQuery queries to answer analytics questions (using bq CLI), grabs error logs from Sentry, etc. The Slack MCP configuration is checked into our .mcp.json and shared with the team.

  12. For very long-running tasks, I will either (a) prompt Claude to verify its work with a background agent when it’s done, (b) use an agent Stop hook to do that more deterministically, or (c) use the ralph-wiggum plugin (originally dreamt up by

  13. A final tip: probably the most important thing to get great results out of Claude Code — give Claude a way to verify its work. If Claude has that feedback loop, it will 2-3x the quality of the final result. Claude tests every single change I land to

http://claude.ai/code using the Claude Chrome extension. It opens a browser, tests the UI, and iterates until the code works and the UX feels good. Verification looks different for each domain. It might be as simple as running a bash command, or running a test suite, or testing the app in a browser or phone simulator. Make sure to invest in making this rock-solid


관련 노트