Running both personal and work projects on one dev machine, with commits going to different GitHub accounts. Don’t want to manually change user.email after every clone, and don’t want a global account-switching script. SSH key isolation + Git conditional config solves it once and for all.

1. Scenario

Typical needs:

• Personal projects (~/personal/*) commit with personal GitHub account
• Work projects (~/work/*) commit with company GitHub account
• Each account has its own SSH key, no interference
• Identity switches automatically when entering different directories, no manual setup

Additional pain points:

• Corporate network might block SSH default port 22, need to use 443
• Some projects need aliases (like work.github.com) to differentiate remote URLs

2. Overall Strategy

Three-layer configuration working together:

1. SSH layer (~/.ssh/config): Configure separate keys and Host aliases for different accounts
2. Git global layer (~/.gitconfig): Set default account and SSH command
3. Git conditional layer (~/.gitconfig-work): Auto-override account info based on directory path

Key mechanism: includeIf lets Git load additional config files in specific directories.

3. Steps

3.1 Generate SSH Key Pairs

Generate independent keys for each account:

# Personal account key
ssh-keygen -t rsa -b 4096 -C "personal@example.com" -f ~/.ssh/id_rsa_personal

# Work account key
ssh-keygen -t rsa -b 4096 -C "work@company.com" -f ~/.ssh/id_rsa_work

After generation you’ll have:

• ~/.ssh/id_rsa_personal + ~/.ssh/id_rsa_personal.pub
• ~/.ssh/id_rsa_work + ~/.ssh/id_rsa_work.pub

Add the .pub public keys to the SSH keys settings page of the corresponding GitHub accounts.

3.2 Configure SSH Host Aliases

Edit ~/.ssh/config (create if it doesn’t exist):

# Personal account (default)
Host github.com
  HostName ssh.github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal
  Port 443

# Work account (using alias work.github.com)
Host work.github.com
  HostName ssh.github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work
  Port 443

Key points:

• Port 443: Bypass firewall blocking of port 22, GitHub officially supports ssh.github.com:443
• Host alias: work.github.com is a local alias, actual connection is still to ssh.github.com
• IdentityFile: Specify which key to use

Test connections:

# Test personal account
ssh -T git@github.com
# Expected output: Hi personal-username! You've successfully authenticated...

# Test work account
ssh -T git@work.github.com
# Expected output: Hi work-username! You've successfully authenticated...

3.3 Configure Git Global Defaults

Edit ~/.gitconfig:

[user]
  name = Your Name
  email = personal@example.com

[core]
  # Globally force use of personal account key
  sshCommand = ssh -i ~/.ssh/id_rsa_personal -F /dev/null

# Conditional config: work directory auto-switches account
[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

Key points:

• sshCommand forces use of specified key, -F /dev/null prevents ~/.ssh/config interference (optional, depends on your priority strategy)
• includeIf path matching: the path after gitdir: must end with / to match subdirectories
• Path supports ~ expansion and wildcards *

3.4 Configure Work Account Conditional File

Create ~/.gitconfig-work:

[user]
  name = Your Name
  email = work@company.com

[core]
  sshCommand = ssh -i ~/.ssh/id_rsa_work -F /dev/null

Now the logic is:

• Default uses personal account (~/.gitconfig)
• Entering any subdirectory of ~/work/, auto-switch to work account (~/.gitconfig-work overrides)

3.5 Clone Work Projects Using Host Alias

When cloning work projects, modify the URL:

# Original URL (would use personal account)
git clone git@github.com:company/project.git

# Use Host alias (will use work account key)
git clone git@work.github.com:company/project.git

Or modify remote after cloning:

git remote set-url origin git@work.github.com:company/project.git

Why need alias?

Even in ~/work/ directory, if remote URL is git@github.com, SSH will prioritize matching the Host github.com config in ~/.ssh/config. Host aliases let you differentiate accounts at the URL level.

4. Verify Configuration

4.1 Check Active Config in Current Directory

# In personal project directory
cd ~/personal/my-project
git config user.email
# Output: personal@example.com

# In work project directory
cd ~/work/company-project
git config user.email
# Output: work@company.com

4.2 Check SSH Key Being Used

# View actual SSH command in use
git config core.sshCommand

# Manual test (with verbose logging)
GIT_SSH_COMMAND="ssh -v" git ls-remote origin
# Output will show "Offering public key: /path/to/id_rsa_xxx"

4.3 Test Commit Identity

# Create test commit
echo "test" > test.txt
git add test.txt
git commit -m "test commit"

# View commit author
git log -1 --format="%an <%ae>"

5. Common Issues

5.1 Port 22 Blocked

Symptom: ssh -T git@github.com times out

Solution: Add to ~/.ssh/config:

Host github.com
  HostName ssh.github.com
  Port 443

GitHub officially provides SSH service on port 443 at ssh.github.com, specifically for bypassing firewalls.

5.2 Key Permission Issues

Symptom: Permissions 0644 for 'id_rsa_work' are too open

Solution:

chmod 600 ~/.ssh/id_rsa_*
chmod 644 ~/.ssh/id_rsa_*.pub

Private keys must be readable/writable only by owner (600), public keys can be more permissive (644).

5.3 includeIf Not Taking Effect

Checklist:

1. Path must end with /: gitdir:~/work/ (correct) vs gitdir:~/work (wrong)
2. Git version: includeIf requires Git 2.13+, run git --version to confirm
3. Path expansion: ~ expands, but relative paths don’t, recommend absolute paths or ~/
4. Debug: Run git config --show-origin user.email to see config source

5.4 Switching Account for Existing Projects

If project has already committed with wrong account:

# 1. Modify remote URL (if needed)
git remote set-url origin git@work.github.com:company/project.git

# 2. Modify most recent commit author (if not yet pushed)
git commit --amend --reset-author

# 3. Batch modify historical commits (use with caution, rewrites history)
git filter-branch --env-filter '
if [ "$GIT_COMMITTER_EMAIL" = "wrong@example.com" ]; then
  export GIT_COMMITTER_EMAIL="correct@example.com"
  export GIT_AUTHOR_EMAIL="correct@example.com"
fi
' --tag-name-filter cat -- --branches --tags

6. Advanced: Finer-Grained Control

6.1 Project-Specific Configuration

If a project needs special configuration, run within the project:

git config user.email "special@example.com"
git config core.sshCommand "ssh -i ~/.ssh/id_rsa_special"

Project-level config (.git/config) has highest priority, overrides global and conditional configs.

6.2 Multiple Work Directories

If you have multiple work directories:

[includeIf "gitdir:~/work/"]
  path = ~/.gitconfig-work

[includeIf "gitdir:~/company-a/"]
  path = ~/.gitconfig-company-a

[includeIf "gitdir:~/company-b/"]
  path = ~/.gitconfig-company-b

6.3 HTTPS Protocol Multi-Account

This article focuses on SSH, but HTTPS also supports multi-account:

• macOS Keychain stores credentials, managed by git-credential-osxkeychain
• Or use GitHub CLI: gh auth login supports multi-account switching
• Conditional config can set different credential.helper

7. Summary

Workflow after configuration:

1. Personal projects in ~/personal/, auto-use personal account
2. Work projects in ~/work/, auto-use work account
3. Remember to use git@work.github.com when cloning work projects
4. Forgot to configure? Check with git config user.email before committing

Core benefits:

• Zero manual switching: Automatic upon entering directory
• Thorough isolation: Keys, identity, directories three-layer isolation
• Verifiable: Clear testing methods for each step

This setup has been in use for two years, never had a commit with the wrong account since.

Half a year of running Claude Code, and the framing has shifted on me. Started out treating it like “VSCode + Cursor with a different vibe”; now it feels closer to managing a small team that can run jobs in parallel. This post is a sweep of the high-leverage features I actually depend on — hooks, MCP, subagents, worktrees, layered CLAUDE.md, when to /clear. Not a doc rewrite. The lens is “what a user with opinions actually does”, and you should be able to lift any block straight into your own setup.

0. Map of the article

Eight modules, ordered from “do this first” to “feel this out”:

Hands-on sections come with copy-paste-able snippets. Conceptual sections explain “why this is shaped this way” and “when to reach for it”.

1. Hooks: scripts on lifecycle events

Hooks are the single most underrated capability in Claude Code. They slice the session into a set of lifecycle events and let you inject your own scripts at each point:

Registration goes in ~/.claude/settings.json or the project’s .claude/settings.json. The two most useful patterns:

Pattern one: hang automation on either side of model actions. For example, run ESLint on every Edit and feed the errors back. Telling lint errors to the model directly works far better than “you forgot to lint, please remember next time” — the model fixes them on the next turn without being asked.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "node /Users/me/.claude/hooks/lint-changed.js",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

matcher is a regex over tool names — Edit|Write triggers on file-write tools. The script reads the hook payload from stdin (including the path of the file that changed), runs lint, and prints errors to stdout. A non-zero exit code makes Claude Code feed stderr into the model’s next input.

Pattern two: wire session state to the outside world. I wrote a whole post on Mac notifications + Bark push earlier — the meat of it is a Python script bound to Stop and Notification, throwing a local macOS toast and a remote push to my phone. Long jobs no longer require staring at the screen.

The real strength of hooks is that they turn “remind the model to do X” into “the system enforces X”. Instructional prompts get forgotten. Hooks don’t.

2. CLAUDE.md: a project manual for the agent

CLAUDE.md looks trivial — it’s just a Markdown file injected into every session’s system prompt. The leverage comes from layering:

~/.claude/CLAUDE.md         # global: injected for all projects
<repo>/CLAUDE.md            # project: only when cd'd into that repo
<repo>/<subdir>/CLAUDE.md   # subdir: only for work in that subtree

Merge order is outside-in, with inner files taking precedence. Combine them like this:

• Global holds “who I am, what I prefer”. e.g. “I’m Jason, prefer functional style”, “use formal terms over slang in Chinese replies”.
• Project holds “the implicit rules of this repo”. e.g. “use pnpm not npm”, “must run pnpm test before committing”, “Tailwind colors only from tokens.ts, no bg-red-500”.
• Subdir holds “the local conventions for this slice”. e.g. apps/api/CLAUDE.md says “every endpoint needs a zod schema”.

What works best to write in there? A few rules I’ve internalized:

1. Write the traps the model will fall into, not the obvious. Don’t write “we use React” — the model will read package.json. Do write “our useFetch must live outside the try/catch because internal handling already wraps”.
2. Write things that pay off forever once taught. Boris Cherny’s “compounding engineering” — each mistake the model makes, once captured, never has to be re-explained. Add the small ones: “yesterday it imported logger from the wrong path again”.
3. Give a reason where you can. “Use X not Y” is weaker than “use X not Y because Y triggers ESM/CJS interop issues”. Reasons make the rule generalize.
4. Keep it lean. CLAUDE.md loads every session and eats context. My personal red line is 200 lines per file. Beyond that, split into subdirs or move to slash commands that load on demand.

A trimmed sample of my project-level template:

# Project: lifelog

## Stack
- Hugo (extended) + custom theme `inkstone` (git submodule)
- Posts in content/posts/, bilingual: foo.md + foo.en.md
- Linked via translationKey

## Writing conventions
- First person, opinionated
- Open with a blockquote
- For long posts, give a map of the article in section 0
- Avoid colloquial translations of jargon

## Operational conventions
- Local preview: `hugo server -D`
- Before committing: `hugo --minify` to check for build errors
- Never `git push` directly. I'll do it.

That last line pairs with §7 below — agents that see this will pull back on their own.

3. MCP server: wrap external capabilities as tools

MCP (Model Context Protocol) is Anthropic’s open protocol that lets any external tool/data source plug into Claude (or any compatible client) through a uniform interface. Anthropic’s own line: MCP is to LLMs what USB-C is to hardware.

Claude Code ships with a few built in (filesystem, bash, web fetch), but the real unlock is custom MCP servers. The three primitives map to three “ways an agent knows things”:

Fastest way to register a server with Claude Code is the CLI:

# Add a local stdio server
claude mcp add my-tools \
  --command "node /Users/me/mcp-servers/my-tools/index.js"

# Add an HTTP server
claude mcp add notion \
  --url "https://mcp.example.com/notion" \
  --header "Authorization: Bearer xxx"

# See what's currently mounted
claude mcp list

Writing a minimal custom server isn’t hard either. Here’s a “read a Linear issue” skeleton in Node.js + the official SDK:

// index.js
import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";

const server = new Server(
  { name: "linear-mini", version: "0.1.0" },
  { capabilities: { tools: {} } }
);

server.setRequestHandler("tools/list", async () => ({
  tools: [
    {
      name: "get_issue",
      description: "Fetch a Linear issue by identifier (e.g. ENG-123)",
      inputSchema: {
        type: "object",
        properties: { id: { type: "string" } },
        required: ["id"],
      },
    },
  ],
}));

server.setRequestHandler("tools/call", async (req) => {
  if (req.params.name !== "get_issue") throw new Error("unknown tool");
  const { id } = req.params.arguments;
  const r = await fetch(`https://api.linear.app/graphql`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: process.env.LINEAR_API_KEY,
    },
    body: JSON.stringify({
      query: `query($id:String!){ issue(id:$id){ title description state { name } } }`,
      variables: { id },
    }),
  });
  const data = await r.json();
  return { content: [{ type: "text", text: JSON.stringify(data, null, 2) }] };
});

await server.connect(new StdioServerTransport());

Once mounted, just say “look at issue ENG-123” in the session and the model calls get_issue.

How I think about it:

• If a stock MCP exists, don’t write one. GitHub, Notion, Slack, Postgres all have official/community servers. Browse modelcontextprotocol.io↗ first.
• Custom MCP fits “private / internal / cross-tool” capabilities. Internal status board, your personal notes vault, the NAS at home — that kind of thing.
• A failing MCP server doesn’t kill the session, it degrades. If a server can’t start at launch, the whole session still runs; that one tool is just unavailable. So mount freely.

4. Parallel agents: fan out subagents

Claude Code ships with a Task tool that fans out subagents from the main session in parallel. Not a gimmick — it’s the feature that genuinely changes work rhythm.

Typical fits:

• Large refactors: “rename X to Y” splits into “find all references”, “rewrite src/”, “rewrite test/”, “rewrite docs/”, four lanes in parallel
• Multi-stack comparison: two subagents implementing the same component in React and Vue, return for diffing
• Code review: one subagent for security, one for performance, one for readability

Triggering it from the main session is just natural language: “fan out 3 subagents to check type errors in src/api/, src/components/, src/hooks/ respectively, then summarize.” The model uses Task automatically.

To freeze it as a standard flow, define named subagents under .claude/agents/:

<!-- .claude/agents/security-reviewer.md -->
---
name: security-reviewer
description: Code review agent focused on security
tools: Read, Grep, Glob, Bash
---

You are a code reviewer focused on the OWASP Top 10.
For each finding, output:

- **Severity**: Critical / High / Medium / Low
- **Location**: file:line
- **Class**: SQL Injection / XSS / SSRF / ...
- **Fix**: a specific change

Security only. No style or performance feedback.

After this, “use the security-reviewer subagent to scan src/api/” lights it up directly. The tools: field locks down what the subagent is allowed to use (omit Edit/Write to keep it strictly read-only).

A handful of things I’ve learned the hard way:

• The practical ceiling is ~5–8 in parallel. Beyond that, token cost and context-switching cost dominate.
• Subagents don’t share the main session’s context. They only see their own prompt and the tools they can call. The instruction has to be self-contained.
• Merging the results is the main agent’s job. After getting N outputs back, the main agent still has to synthesize. This step quietly determines whether the parallelism actually paid off.
• Not every task is parallelizable. Strongly coupled tasks (B’s input is A’s output) get slower when forced into parallel. Test: can you write the work as several truly independent subtasks?

5. Worktree isolation: physically separate sessions

Another granularity of parallelism is multiple Claude Code main sessions on the same repo at once. The pitfall: they all touch the same working tree and stomp each other.

git worktree was made for this:

# Main repo at ~/code/myapp (working on main as usual)
cd ~/code/myapp

# Spawn two isolated working dirs on independent branches
git worktree add ../myapp-feat-a -b feat/a
git worktree add ../myapp-feat-b -b feat/b

# Three physical directories now exist:
#   ~/code/myapp        (main)
#   ~/code/myapp-feat-a (feat/a)
#   ~/code/myapp-feat-b (feat/b)
# Same .git, fully isolated working trees

Open three terminals, cd into each, and claude in each. Three agents working on three things, no cross-contamination.

My flow:

1. For complex tasks, drop into plan mode (shift+tab) in the main repo and split the work with the model into 3–5 orthogonal subtasks.
2. Each subtask gets a worktree (named <repo>-<task-slug>).
3. Open three terminal panes (tmux / Warp split), one Claude per pane.
4. After everything finishes, return to the main repo, git worktree list, review each, merge, git worktree remove.

git worktree list                      # what's currently active
git worktree remove ../myapp-feat-a    # tear down when done
git worktree prune                     # clean stale references

A few notes:

• Each worktree gets its own branch. Two worktrees on the same branch is rejected by git (and that’s a feature).
• node_modules / .venv aren’t shared. Each worktree reinstalls. pnpm’s content-addressable store or a venv symlink can help, at the cost of more setup.
• Cross-worktree env vars / .env don’t auto-copy. cp or symlink as needed.
• A worktree is not a fork. All worktrees share the same .git/, so git fetch updates everything once and commits land in the same object database. That’s why it’s much faster than a full git clone.

Worktrees and parallel subagents are two different parallels. Subagents fan out inside one session. Worktrees physically isolate between sessions. The former is fast but coupled, the latter is slower but cleaner. I reach for worktrees on refactors / cross-module changes, and for subagents on investigation / inspection / generation tasks.

6. Slash commands / Skills: freeze the workflow

/command is the other compounding investment in Claude Code. Anything you’ve done twice should be considered for a slash command on the third pass.

Where they live:

~/.claude/commands/<name>.md         # global, available everywhere
<repo>/.claude/commands/<name>.md    # project-scoped

The file itself is Markdown that gets injected as a prompt. Here’s the /review I use:

<!-- .claude/commands/review.md -->
---
description: Self-review the diff between this branch and main
allowed-tools: Bash(git diff:*), Bash(git log:*), Read
---

Self-review every change on this branch relative to main:

1. Run `git diff main...HEAD --stat` to see which files changed
2. Run `git diff main...HEAD` for the full content
3. Give feedback on:
   - Abstractions that add complexity without value
   - Violations of established conventions (consult CLAUDE.md)
   - Test coverage (especially new public functions)
   - Lingering console.log, debugger, TODO

Finish with a markdown review report I can paste straight into the PR.

Type /review in a session and the whole thing fires. The allowed-tools field temporarily whitelists git diff/log even if they aren’t in the global allowlist — safe by default.

Arguments are easy too — use $ARGUMENTS in the file:

<!-- .claude/commands/explain.md -->
Explain in detail what $ARGUMENTS does, why it's written this way,
and whether there's a simpler alternative.

In session, /explain src/utils/debounce.ts substitutes the path in.

My current resident commands:

Skills (the broader “packaged capability” idea) are still evolving, but the principle is the same: turn “things you keep re-explaining to Claude” into “one-line triggers that are now project assets”. Each one is permanent dividend.

7. Permission & safety model: allow / deny / skip

The permission system is one of the things that sets Claude Code apart from generic “AI editors”. Three tiers:

The permissions block in settings.json is where you tune most often:

{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(pnpm:*)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(git log:*)",
      "Edit",
      "Write",
      "Read"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(chmod:*)",
      "Bash(curl:*)",
      "Bash(git push:*)",
      "Bash(git commit:*)"
    ]
  }
}

deny beats allow. My personal style is conservative:

1. Deny anything genuinely dangerous you can name. rm -rf, git push, git commit, curl (defends against exfil), chmod, sudo.
2. Allow common reads. git status, git log, ls, pwd, cat, the test commands.
3. Don’t allowlist writes. I leave Edit / Write on default ask — the extra prompt feels slow but the floor is solid.

--dangerously-skip-permissions (a launch flag) is the nuclear option: every check is bypassed. It is not for daily use. Reserve it for:

• Docker / VM sandboxes where blowing things up is “rebuild and move on”
• One-shot script tasks, e.g. batch-renaming 1000 files while you’re literally watching
• CI / Headless runs where the environment is throwaway by design

Never flip on dangerouslySkipPermissions on your daily-driver setup. The day a hallucination decides to rm -rf ~, you’ll cry.

A safer alternative is sandboxing: run Claude in a devcontainer / Docker / Multipass VM, physically isolated. Anthropic’s own security best practices↗ recommend this.

The point of the permission model is to let agents act autonomously inside a defined zone, and force a stop at the edge. Allow too loose and you eat damage; deny too aggressive and you’re back to “co-pilot mode” pressing accept on everything, losing the agentic value. The dial is per-project and per-personality.

8. Context management: context is king, but it rots

Last one, conceptual. Karpathy’s much-quoted line:

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”

And Anthropic’s own research keeps confirming a counterintuitive point: more context isn’t better. Models exhibit “context rot” under long inputs — even on simple tasks, performance degrades as input length grows.

Claude Code gives you a few knives:

How I use them:

• Task boundaries are the natural /clear point. Done with feature A and now fixing bug B? /clear first.
• 30+ turns deep on the same task and the model starts drifting? /compact. It re-focuses noticeably.
• CLAUDE.md is “permanent context”, don’t let it rot into a junk drawer. Every line should earn its keep.
• Long reference material doesn’t go in chat — write it to a file and let the model Read it. Read is on-demand; pasting is once-and-stuck.

A deeper point: subagents are a context-management tool. Each fanned-out subagent gets a clean window; only the summary returns to the main. That’s why a big refactor is faster as fan-out than as one main agent grinding through — not because parallelism saves wall time, but because each sub-context stays cleaner.

Like the permission model, context management is a question of timing. The only rule: when the model starts repeating, looping, or forgetting, act. That intuition only develops with reps.

9. Closing: from tool to team

Stepping back from eight sections, the through-line is:

What’s most valuable about Claude Code isn’t that it can write code. It’s that it can be configured into a part of how you work.

Hooks are reflex arcs. CLAUDE.md is long-term memory. MCP is sense extension. Subagents are clones. Worktrees are physical isolation. Slash commands are muscle memory. The permission model is the boundary. Context management is restraint. Composed together, what you’re managing isn’t “an AI editor” anymore — it’s a small team with reflexes, memory, parallelism, boundaries, and the discipline to rest.

If you can only adopt three:

1. Every project gets a CLAUDE.md under 200 lines. Cheapest compounding move there is.
2. Anything you’ve done twice, on the third pass becomes a slash command or a hook.
3. Tasks longer than 30 minutes go through plan mode; complex changes go straight into a worktree.

The rest — MCP, subagents, custom servers — is “next step”. Add when needed, skip when not. The value of a tool is what it does when you’re not there, not how many of them you collected.

References:

• Claude Code official docs↗
• MCP protocol homepage↗
• Anthropic Engineering: Claude Code Best Practices↗
• How Anthropic Teams Use Claude Code↗
• My earlier post: Wiring Claude Code into macOS Notifications + Bark Push
• My earlier post: CS146S course notes (Week 3 / Week 4 overlap most with this one)

CS146S — The Modern Software Developer↗ is a new Stanford course from Fall 2025, taught by Mihail Eric, with a heavyweight guest each week (Boris Cherny, Zach Lloyd, Isaac Evans, Tomas Reimers…). I worked through all eight weeks in the official assignments repo↗ and did the exercises along the way. This post is the consolidated note.

1. The Course’s Real Theme: A Shift in Developer Identity

The tagline on the course site is unusually direct:

“Many AI coding courses only teach you how to write fast — this course draws the baseline for shipping: testable, auditable, defensible.”

If you only skim the weekly schedule, you’d think it’s “An AI Tools Survey.” But after reading the materials and doing the assignments, a more honest description is:

It is systematically training you to become an Agent Manager.

Not “learn to code with ChatGPT,” but: stop being the person who writes the code and become the person who directs Agents to write it — and who owns the result. Boris Cherny (creator of Claude Code) gets quoted again and again:

“It’s not so much about deep work, it’s about how good I am at context switching and jumping across multiple different contexts very quickly.”

The eight weeks fall into three storylines:

1. Prompt → Context (Weeks 1 → 3): from writing one good prompt to architecting a whole information environment
2. Coder → Agent Manager (Weeks 2 → 5): from writing code yourself to directing and orchestrating multiple Agents
3. Speed → Defensible (Weeks 6 → 8): from rapid output to auditable, defensible, ship-ready

The rest of the post follows those three lines.

2. Storyline One: Prompt → Context

Week 1: Six Foundational Prompting Techniques

Week 1 runs local models through Ollama and drills six techniques in turn: K-shot, Chain-of-Thought, Tool Calling, Self-consistency, RAG, Reflexion. One Python file per technique, iterate the prompt until tests pass.

The takeaway isn’t “I learned six tricks.” It’s: these aren’t parallel options, they form an evolutionary chain.

• K-shot gives the model a pattern
• CoT gives it room to reason
• Tool Calling lets it stop guessing and actually look things up
• Self-consistency trades sampling cost for stability
• RAG plugs external knowledge into the context
• Reflexion lets the model critique its own output and try again

By Reflexion, the model has gone from “answer machine” to “small self-correcting loop.” That is the seed of an Agent.

Week 2: First Time Closing the Loop on a Real Task

The assignment is a minimal FastAPI + SQLite Action Item Extractor: free-form notes → structured todo list. Use Cursor’s Agentic Mode to land five TODOs: replace rule-based extraction with an LLM, add unit tests, refactor, add a new endpoint + frontend button, generate a README.

In my own practice notes I distilled a minimum capability model for “a local Agent that executes simple requirements”:

understand intent → fetch code context → plan → generate code → verify → feedback
        ↑                                                                  |
        └────────────── on failure, backtrack & correct ←─────────────────┘

Each step maps onto a Week 1 technique. Agents are not a new invention; they are those atomic capabilities wired up around this loop.

After running it end-to-end the strongest impression: today’s Agents shine on tasks with clear boundaries that you can verify. Scaffolding, single-function implementations, happy-path tests, doc generation — these are strengths. Deciding “what not to change,” reasoning about cross-module side effects, refactors that involve real tradeoffs — those still need a human.

Week 3: From Prompt Engineering to Context Engineering

Week 3 is the densest week of the course (the other one being Week 6). Boris Cherny is the guest. The thesis traces back to Andrej Karpathy’s definition:

“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”

Two things in this week made me re-examine how I work:

“Context is King” — and a precondition for intelligence. A line that hits hard: “Claude is already smart enough — intelligence isn’t the bottleneck, context is. When the Agent fails, the instinct is to blame the model, but it’s almost always wrong. What’s actually underperforming is the information environment around it.”

Context Rot. Model performance degrades with input length, even on simple tasks. So /clear, /compact, tiered memory, keeping CLAUDE.md lean — these aren’t aesthetic choices, they’re performance strategies.

The Week 3 assignment is to build a custom MCP Server. I built a GitHub Issue assistant: 3 Tools (search_issues / create_issue / get_issue_detail) + 1 Resource (repo metadata) + 1 Prompt (bug report template), STDIO transport into Claude Desktop.

Building it by hand is the only way I really understood: the three MCP primitives (Tools / Resources / Prompts) aren’t abstract concepts — they map to three different ways an Agent “knows” something — what it can do, what it can look up, how it should phrase things.

Boris also shared his daily workflow: 20–30 PRs a day, sustained by running 5 Claude Code instances in terminals plus 5–10 sessions on claude.ai/code, every instance starting in Plan Mode, with CLAUDE.md as shared team memory. The line that gets hammered home:

“Give Claude a way to verify its own work — browser tests, test suites, simulators. Verification is what gives you a 2-3x quality improvement on the final output. Everything else (subagents, slash commands, MCP integrations) is built on top of that.”

3. Storyline Two: Coder → Agent Manager

Week 4: Claude Code as Agent Manager

Week 4’s central line:

“The goal is to train you as an Agent Manager — not someone who writes code, but someone who directs Agents to write code.”

This week catalogs 5 agentic workflow patterns:

• Sequential Flow — the default. About 70% of daily work.
• Operator — hierarchical: a central planner + specialized sub-agents
• Split-and-Merge — fan-out / fan-in, up to ~10 parallel branches
• Agent Teams — collaborative; agents can talk to each other across independent sessions
• Headless — triggered by CI/CD, Cron, webhooks; no human in the loop

Plus 12 “Agent Harness Patterns” (persistent instructions, directory-scoped instructions, tiered memory, memory hygiene, context compaction, parallel branching, checkpoint review, selective tool loading, purpose-built tools, permission granularity, lifecycle hooks, compounding corrections).

The line that stuck:

“The problem isn’t your model — it’s your harness. What separates a flashy demo from a production-grade AI system isn’t intelligence, it’s control.”

The assignment: build at least 2 automations (Slash Commands, CLAUDE.md, SubAgents) on a FastAPI starter app. After this week my muscle memory shifted: every time I see a repeated workflow I now ask “could this become a .claude/commands/ entry?”; every time Claude makes the same mistake twice I ask “should this go into CLAUDE.md?”

The phrase Compounding Engineering is one I like a lot: every recorded mistake becomes permanent leverage.

Week 5: The Terminal Is Not a Power User’s Toy

Week 5’s guest is Warp CEO Zach Lloyd. Warp 2.0 reframes itself from “a better terminal” to ADE — Agentic Development Environment.

The comparison table I found most useful:

These stack rather than compete: Claude Code can run inside Warp. The key tool for parallel Agents is git worktree — each Agent works in an isolated working tree, no clobbering, merge branches at the end. I started using this in real work after reading this week.

But the Warp team is honest about the cost: parallelism isn’t free. Saving 6–7 hours a week is real, but only if your cognitive bandwidth can actually steer 5 tabs at once — that turns out to be the real bottleneck.

4. Storyline Three: Speed → Defensible

Week 6: Semgrep and AI Code Security

Week 6 brings Semgrep CEO Isaac Evans. The opening number made me pause:

Claude Code, run as a security scanner, surfaced 46 real vulnerabilities — at a 14% true positive rate and 86% false positive rate.

This isn’t “Claude is bad.” It’s that AI’s security intuition isn’t reliable — out of 7 alerts only 1 is a real issue. Semgrep flips that ratio: 80% fewer false positives, 250% more true positives.

Semgrep’s three products:

• Code (SAST) — first-party code vulns, with cross-file analysis
• Supply Chain (SCA) — reachable CVEs in dependencies (reachability analysis filters out unreachable ones, cutting high/critical-severity false positives by 98%)
• Secrets — hardcoded credentials, with semantic + entropy analysis + live validation

The assignment: run semgrep ci --subdir week6 on a deliberately vulnerable FastAPI app and fix at least 3 findings. The fixes are unglamorous but fundamental: parameterized SQL, restricted CORS, secrets to env vars, dependency upgrades, stronger crypto, sanitized DOM writes.

The blunt takeaway: “Secure Vibe Coding” wants speed and safety unified, not opposed — the way you get there is automating scans into CI rather than retrofitting safety after the fact.

Week 7: Graphite Diamond and AI Code Review

Week 7’s guest is Graphite CPO Tomas Reimers. The thesis:

“AI will never replace human code review. But every PR should be reviewed by AI + human together.”

AI’s strengths in review: style consistency, common bug patterns, security vulnerabilities, code duplication, 100% PR coverage, second-level latency. Human strengths: architectural judgment, business logic correctness, tradeoff analysis, creative alternatives, team context, UX design.

The recommended pattern is “AI First, Human Second”: AI filters the mechanical stuff, humans focus on the high-leverage judgment calls. Graphite’s other product innovation is Stacked PRs — break a big PR into a chain of small sequential ones, because AI review performs noticeably better on small PRs.

The assignment is dense: 4 independent tasks, each going through “create branch → 1-shot AI implementation → manual line-by-line review → open PR → run Graphite Diamond → compare.” Then a written reflection: my review vs Graphite’s, which one was better, when, and why.

That comparative reflection is the most valuable part of the week, in my view. It isn’t teaching you to trust AI. It’s teaching you to know when AI is better than you, and when it isn’t. That meta-cognition is more durable than any specific tool.

Week 8: Bolt.new and Multi-Stack Rapid Builds

Week 8 pivots to “prototype to production.” The guest is Vercel’s Head of AI Research. The framing:

“Rapid prototyping is just the starting point. Between demo and production lies a chasm.”

Bolt.new uses StackBlitz’s WebContainer technology to run Node.js entirely in the browser, generating full-stack apps from prompts. But its capability curve is steep:

The assignment asks you to build the same app in 3 different stacks, at least one via Bolt and at least one in a non-JS language. The design is sneakily clever — it trains two things at once:

1. Abstraction — you have to pull the business logic out of the framework and figure out what’s essence vs implementation
2. AI-tool literacy — the same prompt produces wildly different quality across Next.js / Django / Rails, so you have to develop a feel for “what does production-ready code actually look like”

5. Three Lessons I Actually Use Daily

After eight weeks of material and a stack of assignments, these are the three I’ve actually absorbed into my workflow:

5.1 Plan Mode Is Free Leverage

Boris’s “never let Claude write code before you have reviewed and approved a written plan” is the most-quoted line of the course. For any task longer than 30 minutes I now hit shift+tab into Plan Mode, iterate with Claude until the plan is right, then switch to auto-accept. Rework rate dropped noticeably.

5.2 CLAUDE.md Is Where Compounding Lives

Every time Claude makes a mistake or I notice a non-obvious project convention, it goes into CLAUDE.md. The habit is incredibly cheap and incredibly profitable — once it’s in there I never explain it again. Just keep it lean: it loads every session and eats context.

5.3 Always Give the Agent a Way to Verify Itself

Boris’s “most important insight.” Concretely:

• Backend work: have Claude run the tests, fail-then-fix, never “looks fine, ship it”
• Frontend work: spin up the dev server and have Claude actually click through the golden path with Playwright
• API integrations: get a minimal curl/httpie reproduction script first

This is just the engineering version of Reflexion (Week 1) — bake “self-review” directly into the workflow.

6. Closing: The Eight-Week Arc

Week 1:  How to talk to AI                  → Prompt Engineering
Week 2:  How AI uses tools                  → Coding Agents & MCP
Week 3:  How to build AI's information env  → Context Engineering
Week 4:  How to manage AI                   → Agent Manager
Week 5:  AI-native terminal                 → AI Terminal
Week 6:  AI code security                   → Semgrep
Week 7:  AI code review                     → Graphite Diamond
Week 8:  AI-built applications              → Bolt.new multi-stack
(Weeks 9-10: AI ops + the future            → second half of the course)

Each week is the foundation for the next. What you walk away with isn’t a tool manual — it’s a new posture:

You aren’t the person writing code anymore. You’re the person designing the information environment, directing the Agents, and answering for the final output.

Coding speed is up 10x. So is the speed at which you can ship the wrong thing. The baseline this course draws — testable, auditable, defensible — isn’t a constraint. It’s the floor that makes the new posture viable.

References:

• Course homepage: themodernsoftware.dev↗
• Assignments repo: mihail911/modern-software-dev-assignments↗
• Community Chinese edition: ShouZhengAI/CS146S_CN↗
• Claude Code best practices: anthropic.com/engineering/claude-code-best-practices↗
• 12 Agentic Harness Patterns: generativeprogrammer.com↗
• How Anthropic Teams Use Claude Code: claude.com/blog↗
• Andrej Karpathy on Context Engineering (original X post)
• Boris Cherny’s workflow: howborisusesclaudecode.com↗

Origin story: spotted a Windows gist that wires Claude Code into system notifications↗ , written in PowerShell, useless on a Mac. Rewrote it for macOS, then added a Bark↗ channel — when a long job finishes and you’ve wandered off, the phone in your pocket should be the one that pings.

1. The shape of it

Claude Code’s hook system exposes a set of lifecycle events. For “notify me”, you only need two:

• Stop — the model finished its turn. Time to ring the bell.
• Notification — the model wants confirmation or input (permission prompts, questions). More urgent.

The hook command receives JSON on stdin: cwd (project path), transcript_path (full JSONL conversation), and Notification events also carry a message.

Design choices:

• Single Python file — macOS ships python3 by default, so no jq / curl JSON-escaping ceremony.
• Local toast prefers terminal-notifier — use it if installed (clickable, supports group dedup); fall back to osascript otherwise. Zero install required.
• Bark is opt-in — only fires when BARK_KEY is set. Failures are silent; the hook’s exit code stays clean.
• No chmod — see the “gotchas” section below. The script isn’t executable; we invoke it as python3 path/to/notify.py.

2. The script: ~/.claude/hooks/notify.py

#!/usr/bin/env python3
"""Claude Code notification hook for macOS.

Local toast (osascript or terminal-notifier) + optional Bark push.

Usage: notify.py <Stop|Notification|...>

Reads JSON from stdin (Claude Code hook payload):
  cwd               -> current working directory
  transcript_path   -> path to JSONL transcript (Stop event)
  message           -> notification message (Notification event)

Environment variables (all optional):
  BARK_KEY            Bark device key. If unset, Bark push is skipped.
  BARK_SERVER         Bark server (default: https://api.day.app).
  BARK_GROUP          Notification group (default: ClaudeCode).
  BARK_SOUND          Notification sound (default: minuet).
  BARK_ICON           Custom icon URL.
  BARK_STOP_LEVEL     Level for Stop events (default: passive).
  BARK_NOTIFY_LEVEL   Level for Notification events (default: timeSensitive).
                      Valid: active | timeSensitive | passive | critical.
  CLAUDE_NOTIFY_OFF   If set to "1", suppress all notifications.
"""
from __future__ import annotations

import json
import os
import shutil
import subprocess
import sys
import urllib.request
from pathlib import Path

TITLE_PREFIX = "ClaudeCode"
MAX_BODY_LEN = 200


def read_stdin_json() -> dict:
    try:
        raw = sys.stdin.read()
    except Exception:
        return {}
    if not raw.strip():
        return {}
    try:
        return json.loads(raw)
    except Exception:
        return {}


def last_assistant_text(transcript_path: str) -> str:
    p = Path(transcript_path)
    if not p.is_file():
        return ""
    try:
        with p.open("r", encoding="utf-8", errors="replace") as f:
            lines = f.readlines()[-30:]
    except Exception:
        return ""
    for line in reversed(lines):
        try:
            entry = json.loads(line)
        except Exception:
            continue
        msg = entry.get("message") or {}
        if msg.get("role") != "assistant":
            continue
        content = msg.get("content")
        text = ""
        if isinstance(content, str):
            text = content
        elif isinstance(content, list):
            for block in content:
                if isinstance(block, dict) and block.get("type") == "text":
                    t = block.get("text", "")
                    if t.strip():
                        text = t
                        break
        if text.strip():
            return text
    return ""


def truncate(s: str, n: int) -> str:
    s = (s or "").strip()
    if len(s) <= n:
        return s
    return s[: n - 1] + "…"


def send_mac_notification(title: str, body: str) -> None:
    tn = shutil.which("terminal-notifier")
    if tn:
        try:
            subprocess.run(
                [tn, "-title", title, "-message", body,
                 "-sound", "Glass", "-group", "claude-code", "-ignoreDnD"],
                check=False, timeout=5,
                stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL,
            )
            return
        except Exception:
            pass

    def esc(s: str) -> str:
        return s.replace("\\", "\\\\").replace('"', '\\"')

    script = (
        f'display notification "{esc(body)}" '
        f'with title "{esc(title)}" sound name "Glass"'
    )
    try:
        subprocess.run(
            ["osascript", "-e", script],
            check=False, timeout=5,
            stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL,
        )
    except Exception:
        pass


def send_bark_push(title: str, body: str, event: str) -> None:
    key = os.environ.get("BARK_KEY", "").strip()
    if not key:
        return

    server = os.environ.get("BARK_SERVER", "https://api.day.app").rstrip("/")

    if event == "Notification":
        level = os.environ.get("BARK_NOTIFY_LEVEL", "timeSensitive")
    elif event == "Stop":
        level = os.environ.get("BARK_STOP_LEVEL", "passive")
    else:
        level = "active"

    payload = {
        "title": title,
        "body": body or " ",
        "group": os.environ.get("BARK_GROUP", "ClaudeCode"),
        "level": level,
        "sound": os.environ.get("BARK_SOUND", "minuet"),
    }
    if icon := os.environ.get("BARK_ICON", "").strip():
        payload["icon"] = icon

    try:
        req = urllib.request.Request(
            f"{server}/{key}",
            data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
            method="POST",
            headers={"Content-Type": "application/json; charset=utf-8"},
        )
        with urllib.request.urlopen(req, timeout=5) as r:
            r.read()
    except Exception:
        pass


def main() -> int:
    if os.environ.get("CLAUDE_NOTIFY_OFF") == "1":
        return 0

    event = sys.argv[1] if len(sys.argv) > 1 else "Stop"
    data = read_stdin_json()

    cwd = data.get("cwd") or ""
    project = os.path.basename(cwd) if cwd else ""

    if event == "Stop":
        title = f"{TITLE_PREFIX} - {project}" if project else TITLE_PREFIX
        body = ""
        transcript = data.get("transcript_path") or ""
        if transcript:
            body = last_assistant_text(transcript)
        if not body.strip():
            body = "Task completed, please review results."
    elif event == "Notification":
        title = f"{TITLE_PREFIX} - Needs Attention"
        if project:
            title = f"{title} - {project}"
        body = (data.get("message") or "").strip() \
            or "Claude is waiting for your input or approval."
    else:
        title = TITLE_PREFIX
        body = f"Event received: {event}"

    body = truncate(body, MAX_BODY_LEN)

    send_mac_notification(title, body)
    send_bark_push(title, body, event)
    return 0


if __name__ == "__main__":
    sys.exit(main())

A few details worth flagging:

• Walking the transcript backwards — read the last 30 JSONL lines, iterate in reverse, take the first entry where role == "assistant" with non-empty text. The content field can be either a string or an array depending on SDK version; both shapes are handled.
• Truncation uses … — a single ellipsis character, not three ASCII dots. Saves two bytes for actual prose.
• Bark level differs by event — Stop defaults to passive (silent, just lands in the push list), Notification defaults to timeSensitive (pierces Focus mode). Long jobs finishing shouldn’t shriek; mid-task confirmations must.
• Silent failure — Bark unreachable, osascript erroring, transcript missing — all caught and swallowed. A hook should never wedge the model.

3. Wiring it into ~/.claude/settings.json

Merge this block into settings.json, preserving your existing env / permissions / enabledPlugins etc.:

{
  "hooks": {
    "Notification": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /Users/you/.claude/hooks/notify.py Notification",
            "timeout": 15
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "python3 /Users/you/.claude/hooks/notify.py Stop",
            "timeout": 15
          }
        ]
      }
    ]
  }
}

matcher: "" is “match anything” — Stop and Notification don’t have sub-matchers anyway. The timeout: 15 seconds is a backstop; timing out doesn’t break the main flow.

4. Enabling Bark

Bark is a long-running iOS push tool. The free key comes from day.app↗ . Install the app and the home screen shows a URL like https://api.day.app/abc123xyz/ — the middle slug is your device key.

Drop it into the env block of settings.json (hooks inherit env from there):

"env": {
  "BARK_KEY": "abc123xyz"
}

Quick reference for the optional knobs:

5. Verification

With BARK_KEY set, fire a manual Notification simulation:

BARK_KEY=your_key echo '{"cwd":"/tmp","message":"test"}' \
  | python3 ~/.claude/hooks/notify.py Notification

Expected:

1. A macOS toast pops in the top-right corner.
2. A Bark notification arrives on your phone, grouped under ClaudeCode, level timeSensitive.

To preview local-only behavior, just unset BARK_KEY for the call.

6. Gotchas

Hook not firing? The Claude Code settings watcher only watches directories that already had a settings file at session start. If .claude/ was created mid-session, edits may not reload. Open the /hooks menu once (forces a reload), or restart the Claude Code session.

chmod denied in your permissions? My settings include Bash(chmod:*) in permissions.deny, so the script can’t be chmod +x’d. Fix: invoke via python3 path/to/notify.py so the executable bit is irrelevant. Bonus — it’s more explicit and removes a hidden piece of state.

Body too long? The script caps at MAX_BODY_LEN = 200 (199 chars + …). macOS Notification Center will truncate too, but capping early avoids ugly mid-JSON breakage on the Bark side.

Want to dial it back? Stop fires every turn — easy to find noisy. Two ways out:

• The Bark side already uses BARK_STOP_LEVEL = passive — silent push, lands in the list only.
• For local silence on Stop too: add if event == "Stop": return to the top of send_mac_notification. Five-line change.

7. Where to take it next

Saving these for future me:

• Telegram / Lark / Slack — rename send_bark_push to send_remote_push, dispatch on a REMOTE_KIND env var. Bark is just one of many.
• Sharper Notification copy — currently I just pass through whatever message the model sent. Could branch on tool_name (if hook payload starts including it) for sharper titles.
• Debounce a burst — multiple Stop events within 5s collapsed into one. Right now every turn rings.
• Stats — append a line to ~/.claude/hooks/notify.log per fire. A week’s worth of “how many turns ran, how often the model got blocked on input” tells you something interesting.

You set this up once and forget about it. When the model finishes a turn or stalls waiting for input, a soft chime in the top-right and a buzz in your pocket — long jobs can finally run while you make a coffee.