Agentic Coding in Practice: Questions from our NYC Claude Code Workshop

What controls or updates claude.md files? What are the best practices for security, access, and governance?

CLAUDE.md files are plain Markdown files. Whoever has write access to the filesystem or repository controls them. This makes governance a deliberate choice, not a built-in feature. Here's how to think about it at each level:

User-level. Global (~/.claude/CLAUDE.md): Controls personal behavior across all projects. Treat like a dotfile — only the individual should edit it.

Team-level. Project (.claude/settings.json + CLAUDE.md): Commit to version control so the whole team benefits from the same context and rules. Use branch protection, code review, and PR approvals before merging changes — the same governance you'd apply to any critical config file.

Enterprise-level. Managed/Org settings: Managed settings override user/project settings and are enforced across all instances. Use these to lock down sensitive permissions centrally.

Security best practices: use settings.json deny rules to block Claude from reading secrets (.env, credentials, SSH keys). Treat CLAUDE.md with the same rigor as infrastructure config: peer-reviewed, versioned, and audited. Conflicting or unreviewed CLAUDE.md files are a governance failure, not a tool failure.

What is a token?

A token is the basic unit an LLM reads and writes roughly 3–4 characters or about ¾ of an English word. 'Hello world' is about 2–3 tokens. 'Anthropomorphic' might be 4. Think of tokens as a budget. Spend them on what Claude actually needs to know right now.

What's the best way to handle key facts in a CLAUDE.md file? What about inputs you don't want in the context?

For key facts you want Claude to always know — architecture decisions, coding standards, key commands — put them in CLAUDE.md. They load automatically at session start.

Best practices for what goes in CLAUDE.md:

• Architecture overview and directory structure
• Build, test, and lint commands (so Claude doesn't have to rediscover them)
• Code style standards, naming conventions, patterns to follow or avoid
• Key constraints (e.g., 'never push directly to main', 'always write tests')
• For one-off context that shouldn't persist, pass it inline in your prompt rather than writing it to a file.

How does Claude Code work best in the terminal? What's the best way to interface with it?

Claude Code is a terminal-native REPL (Read-Eval-Print Loop). You type instructions in natural language, and it reads your codebase, runs commands, and edits files all from the CLI.

Key interaction patterns:

• Be specific about scope: 'refactor the auth module in /packages/api/src/auth/' gets better results than 'improve the code'.
• Use @ to reference files: typing @./src/user-service.js loads that file into context immediately.
• Use # to add memory on the fly: '# always use MUI for new components' auto-saves to the most relevant CLAUDE.md.
• Use /commands for repeatable workflows. They autocomplete in the terminal and act as reusable prompts.
• Start complex tasks in Plan Mode: Claude asks clarifying questions before writing any code.
• Use /rewind immediately if Claude goes off track. Don't try to fix a bad path, just rewind.

Claude Code also integrates with VS Code and JetBrains IDEs, though the core experience is terminal-first. Bash commands run directly within the session—no need to switch to a separate terminal window.

Can you set temperature in Claude Code? If not, how does it work with reasoning?

Claude Code doesn't expose temperature as a user-facing setting the way the raw API does.

What you can control instead:

• Extended thinking (effort level): Controls how much reasoning Claude does before responding. You can toggle this with Option+T in a session, or set alwaysThinkingEnabled: true in settings.json to persist it. Extended thinking adds latency and cost but significantly improves results on complex multi-step problems.
• Model selection: Switching between Haiku, Sonnet, and Opus is the primary lever for quality vs. speed tradeoffs.
• If you need precise temperature control (e.g., for content generation), use the Claude API directly rather than Claude Code.

What's the difference between extended thinking and temperature?

These control fundamentally different things:

• Temperature controls randomness/creativity in token selection. High temperature = more varied, creative, sometimes unpredictable outputs. Low temperature = more deterministic, consistent outputs. It's a sampling parameter.
• Extended thinking controls reasoning depth before responding. When enabled, Claude works through the problem step-by-step internally before giving an answer — like showing its work before stating a conclusion. It affects how much computation goes into the response, not how random it is.

What's the best way to identify which model to use? Opus vs. Sonnet vs. Haiku?

Start with the use case, then match to the model:

• Haiku — Fast and cheap: Simple, well-defined tasks. Generating boilerplate, reformatting files, answering quick questions, running in background agents where cost matters.
• Sonnet — Balanced (default): Most day-to-day coding work. Feature development, debugging, refactoring, code review. Good capability at reasonable cost and speed.
• Opus — Most capable: Complex architectural decisions, difficult debugging, reasoning through ambiguous requirements, tasks where getting it right matters more than getting it fast.

Practical approach: start with Sonnet for everything. If results feel shallow or Claude is missing nuance, switch to Opus for that task. If you're doing high-volume repetitive work, try Haiku first. Claude Code supports per-subagent model selection, so you can run your main session on Sonnet while a background agent runs on Haiku to keep costs down.

Is Claude Code memory session-only? How does context work across sessions?

Each Claude Code session starts fresh with its own context window. There's no automatic memory that carries over between sessions by default. This is by design: it prevents context pollution and keeps behavior predictable.

How to persist knowledge across sessions:

• CLAUDE.md files: Loaded automatically at every session start. The primary mechanism for persistent project knowledge.
• Subagent MEMORY.md: Individual subagents can maintain their own memory files that persist across sessions, building up institutional knowledge over time.
• The # shortcut: During a session, type # followed by anything to instantly save it to the most relevant CLAUDE.md for future sessions.

Every time you run Claude in a new terminal window or start a new conversation, that's a new session. Session history is auto-saved for reference (/insights can draw on past sessions), but active context doesn't persist.

When you compact at the end of a session, what does Claude Code throw away?

Compacting is Claude Code's way of freeing context window space when a session grows long. It summarizes older conversation history into a condensed form, retaining the most important information.

What gets removed during compaction:

• Questions that were answered and are no longer relevant to the current task
• Exploratory conversation that didn't lead anywhere actionable
• Redundant or repetitive exchanges
• Non-functional language from prompts (e.g., polite filler, restated context)

What gets retained:

• Specific numbers, identifiers, file paths, and technical details
• Decisions made during the session
• The current state of the codebase as Claude understands it
• Anything you explicitly flag to preserve before compacting

Pro tip: before compacting, tell Claude what matters. 'Before we compact, make sure to preserve the API endpoint structure we designed and the decision to use JWT for auth.' You can also write critical decisions to CLAUDE.md before compacting so they survive future sessions too.

When switching models mid-session (e.g., Sonnet to Opus in Claude Code) does context carry over?

Yes, when you switch models within a Claude Code session using the /model command, the session context is preserved. You don't lose your conversation history or the current state of the work. This is different from the web claude.ai interface, where model selection affects the whole conversation. In Claude Code, model is just another configurable parameter that you can optimize for cost, speed, or capability at each step of a workflow.

What does versioning look like in Claude Code? Can you go back and restore a previous session?

Claude Code provides two layers of 'going back':

• Within a session — /rewind: Rolls back to a previous state within the current session. Double-clicking Escape also initiates rewind in some configurations.
• Across sessions — Git: All conversations are auto-saved, but the primary versioning mechanism for code changes is Git. Claude Code is designed to work with Git natively. Always branch before starting a feature, commit frequently, and let Git be the source of truth for code history.

Best practice: before starting any significant work, create a Git branch. This gives you a clean rollback path regardless of what happens in the session.

How do you balance skills vs. CLAUDE.md inputs? What should go where?

This is one of the most important decisions for keeping Claude Code efficient. The core principle: CLAUDE.md is for what Claude should always know; skills are for what Claude should know when it's relevant.

Put it in CLAUDE.md if:

• It's always true about your project (architecture, coding standards, key commands)
• Claude needs it from the very first message of every session
• It's short and foundational

Create a skill if:

• It's a repeatable pattern done at high volume or by multiple people
• You want standardization: the same process every time, regardless of who runs it
• It's detailed enough that loading it on every session would waste tokens
• You want to trigger it on-demand or assign it to a specific subagent
• It involves supporting scripts, templates, or multi-step workflows

If you find yourself copying the same instructions into prompts repeatedly, that's a skill candidate. If it's context Claude needs before it can do anything useful on your project, that's CLAUDE.md.

Are Claude Code skills analogous to Gems (Gemini) or custom GPTs (ChatGPT)?

Gems and custom GPTs are human-built personas: you configure them with a system prompt and some instructions, and they become a specialized chatbot. The intelligence comes from the underlying model; the customization is mostly framing. Claude Code skills are closer to loadable domain expertise: structured instruction sets with optional supporting scripts and templates. They activate automatically based on task context: Claude decides when a skill is relevant, loads it, and applies the specific methodology. They can include executable code, not just instructions.

What happens if there are conflicting skills? How does Claude Code handle conflicts?

Conflicting skills are a governance problem. Claude Code doesn't have a built-in conflict resolver; if two skills give contradictory instructions, Claude will attempt to reconcile them, but the results will be unpredictable.

The same applies to CLAUDE.md files: if project-level and user-level files contradict each other, you have a governance gap.

How to prevent conflicts:

• Treat skills like any other shared engineering artifact: design review, version control, and team sign-off before they go into production.
• Namespace skills clearly so their scope is obvious. Don't create two skills that both claim to handle 'code review'.
• Use the plugin system's namespacing feature to prevent naming collisions across plugins.
• Audit your skill library periodically. Deprecated skills that contradict current standards are a real risk.

When should I use each feature? (CLAUDE.md, Skills, Hooks, MCP)

• CLAUDE.md — Standing knowledge: 'Claude always needs to know this.' Architecture, conventions, commands, constraints. Loaded every session automatically.
• Skills — On-demand expertise: 'Claude needs detailed instructions when doing this specific type of task.' Workflows, templates, domain knowledge. Loads only when relevant.
• Hooks — Automated enforcement: 'This should happen automatically without Claude having to remember.' Run formatters on save, block dangerous commands, send notifications when tasks complete. Event-driven.
• MCP — External connectivity: 'Claude needs to read from or write to systems outside the codebase.' GitHub, Jira, databases, APIs. Persistent connections to external tools.

How close to production can you take Claude Code? What are the best practices for new codebases vs. existing ones?

Claude Code can take you very close to production, but 'close' requires deliberate governance. The pattern that works: Claude handles implementation, humans own review and deployment decisions.

For new codebases, start with structure:

• Give Claude a clear architecture outline upfront (CLAUDE.md with directory structure, naming conventions, tech stack)
• Define what 'done' means: tests required, linting enforced, documentation format
• Use hooks to automatically run formatters, type checks, and security scans after every edit
• Commit CLAUDE.md to version control from day one

For existing codebases, governance is harder but more critical:

• Use deny rules in settings.json to protect production configs, credentials, and critical files
• Enable sandboxing (/sandbox) to isolate filesystem and network access during exploration
• Always work on feature branches. Use hooks to block direct pushes to main
• Run Claude Code in a devcontainer for full isolation from your host machine and credentials
• Build in human review checkpoints before any merge to production-adjacent branches

What's the difference between agent teams/swarms and subagents?

Subagents (you in the driver's seat): Claude spawns a specialized helper to handle a specific part of a task (e.g., while you're working on features, a background agent monitors logs). You're still directing the overall flow. Subagents run in isolated context windows so they don't pollute the main session.

Agent teams/swarms (Claude in the driver's seat): You define a high-level goal and Claude orchestrates multiple agents in parallel to achieve it (e.g., three parallel explore agents search different parts of the codebase simultaneously, then a synthesis agent combines the findings). You step back and review results.

When to use which:

• Subagents: When you want parallel specialization but still want to direct the work. Good for adding 'always-on' capabilities like a background security auditor or log monitor.
• Agent teams: When the task is large and parallelizable, and you want Claude to manage the orchestration. Good for large-scale refactors, comprehensive codebase analysis, or automated CI workflows.

How does Claude Code interface with external platforms like GitHub, Salesforce, and Jira?

External integrations work through MCP (Model Context Protocol), a standardized protocol that acts like a universal adapter connecting Claude Code to external tools and data sources.

The MCP ecosystem now includes 300+ integrations. The real power is that Claude can orchestrate across multiple systems in a single session (e.g., check a Jira ticket, write the code, run tests, and create the PR) all without leaving the terminal.

 How do you build Claude Code workflows for an enterprise team, not just an individual?

The shift from individual to enterprise use is fundamentally about standardizing and distributing the configuration that makes Claude Code effective.

Key building blocks:

• Shared CLAUDE.md in version control: The team's collective knowledge lives here. Governed like any critical config (PR reviews, branch protection).
• Plugins and shared skills: Package your team's best workflows as installable plugins. New team members get the same capabilities on day one without manual setup.
• Managed settings (org-level): Enforce security policies centrally and deny rules for sensitive files, required hooks, approved tool lists. These override individual and project settings.
• Standardized subagents: Define specialized agents (code-reviewer, security-auditor, doc-writer) that all engineers can invoke consistently.
• Hooks for quality gates: Automatically run linting, type checking, and security scans after every file write

What's the difference between the Claude Code sandbox and a Docker container?

Both provide isolation, but they operate at different levels:

• Claude Code's native sandbox (/sandbox): Uses OS-level primitives (Seatbelt on macOS, bubblewrap on Linux) to isolate bash commands from your filesystem and network. Fast to enable, no additional setup. Restricts writes to the project directory and limits network access to allowed domains. Best for: everyday development where you want safety without overhead.
• Docker container: Full process isolation — Claude Code runs in a container that only has access to mounted project files. No access to your host filesystem, SSH keys, cloud credentials, or anything outside the container. Best for: fully unattended operation, CI/CD pipelines, or situations where you need to be certain nothing can escape the sandbox.
• Devcontainer (Docker-based): Team-standardized Docker environment with pre-configured IDE extensions, Claude Code pre-installed, and a built-in firewall. Best for: enterprise teams that want reproducible, auditable environments.

What does Claude Code look like in the IDE?

Claude Code has official extensions for VS Code and JetBrains IDEs. The same settings hierarchy (managed > project > user) applies across CLI and IDE.

What works well in the IDE:

• Language Server Protocol (LSP) integration: Claude gets IDE-level code intelligence — Go to Definition, Find References, type information. This lets it navigate codebases more precisely than text search alone.
• Inline editing: Review and accept/reject code changes directly in the editor
• Terminal integration: The Claude Code REPL runs inside the IDE terminal

How do you run bash commands directly in Claude Code without jumping into a new session?

You don't need to leave the Claude Code session to run bash commands. The Bash tool is built in and runs commands in your current working directory as part of the same session.

Ways to run bash within Claude Code:

• Natural language: Just ask Claude to run a command: 'Run the test suite and tell me what fails.' Claude uses the Bash tool automatically.
• Slash commands: Create custom commands that run bash scripts as part of a workflow.
• Hooks: Configure bash commands to run automatically on specific events (e.g., run prettier after every file write).
• Background tasks with &: Long-running commands can be sent to the background so you keep working while they execute.

Agentic development is moving quickly, but the core challenges are becoming clearer: workflow design, context management, and governance at scale. The teams that solve these will be the ones that move fastest. If you’re thinking about how to apply this in your own environment, take a look at how we’re partnering with Anthropic.