# Product Foundations --- # Lección: What Claude Code is and how it behaves in a codebase LESSON 1 OF 3 · PRODUCT FOUNDATIONS ## Claude Code: an agent built for the codebase By the end of this lesson, you can explain what Claude Code is, how it operates inside a repository, and why that's different from a chat interface. What it is ## Claude Code works inside the codebase. That changes what it can actually do. Most AI tools sit outside the work. Claude Code sits inside it. Chat interface Answers questions. Generates text. No access to your files, terminal, or project context. It's stateless between messages, useful for drafting and explaining but not for building. Claude Code Reads, edits, runs, and loops. Reads and writes files directly, runs bash commands, and edits across the codebase. Maintains session context and keeps working until the task is done. How it works ## It reads, plans, acts, and checks with you before it keeps going. Claude Code doesn't generate code and stop. It works in a loop until the task is complete or you pause it. 1 Observe Reads the relevant files, terminal context, and project history. Builds an understanding of the current state before planning anything. In practice: it greps the codebase, opens the files it judges relevant, and reads recent terminal output. It does not assume the structure of your project; it looks first. 2 Plan Breaks the task into steps. Decides which files to touch, which commands to run, and in what order. For larger tasks it can surface the plan for your review before acting, so you approve the approach rather than reacting to changes after they land. 3 Act Edits files, runs bash commands, calls tools. Every action is logged and visible in the terminal, not simulated output in a chat window. Each tool call is a real operation on the machine. You see the diff, the command, and its output, which is what makes the work auditable rather than opaque. 4 Verify Surfaces the result and waits for your approval. If something needs correcting, it loops back to Observe. You stay in control of the cycle. Failed test? Unexpected output? It feeds that back into a fresh Observe pass and tries again, until the task is done or you pause it. Verify feeds back into Observe. The loop runs until the task is done or you pause it. The loop doesn't stop until the task is done or you pause it. Every tool call (file edit, bash command, search) is logged and reviewable. That's what makes autonomous operation safe to authorize. Where it runs ## The CLI is the core. Everything else is a wrapper around the same agent. Same model. Same agentic loop. The surface changes the integration point, not the intelligence. The four surfaces share the same model and agent loop. One important distinction: the CLI has native filesystem and terminal access at the operating system level. Desktop, Web, and Mobile reach those same capabilities only when the developer explicitly invokes Claude Code's agent tooling from within those surfaces, not directly from the host OS. That difference in access surface matters when scoping what a deployment can do. 01 CLINative access Native terminal access with the full Claude Code capability set. The primary interface for most developer workflows and the reference point for all configuration decisions. Access surface: direct, at the operating-system level. Filesystem and terminal are available without any extra invocation. This is the baseline every other surface is measured against. 02 IDE ExtensionsNative access Available for VS Code and JetBrains, surfacing the same agent inline with the editor. Reduces context switching without changing what Claude Code can do. Access surface: same as the CLI, since the extension runs the local agent. The editor is a wrapper, not a lighter version of the product. 03 Agent SDKNative access Programmatic access for pipeline and automation use cases. Lets engineering teams embed Claude Code into CI/CD, tooling, or multi-agent workflows. Access surface: whatever the host environment grants. In CI/CD it has the runner's access; the scope is defined by where you run it. 04 Desktop / Web / MobileScoped access Runs tasks in the cloud, without requiring a local environment. Suited for business-facing work that doesn't need filesystem or terminal access. Access surface: reaches filesystem and terminal only when the developer explicitly invokes the agent tooling, not directly from the host OS. This is the distinction that matters when scoping a deployment. Check your understanding ## What's true about Claude Code? Activity · True or false? Select an answer for each statement. 0 of 3 answered "Claude Code uses a different model tier than Claude.ai." True False False. Claude Code runs on the same model family (Haiku, Sonnet, Opus) as every other Claude product. Model choice is a configuration decision made at deployment time, not something baked into the product itself. The common misconception here is that "developer tool" implies a specialized or stripped-down model. It doesn't. You're configuring access to the same model lineup, and you can run Opus through Claude Code just as you can through Claude.ai. "Claude Code can run bash commands and edit files on the machine where it's installed." True False True. This is what separates an agent from a chat window: Claude Code has tools that interact with the real environment, including the filesystem, the terminal, and external APIs. Those tools are configurable and can be scoped or restricted by the admin. If you answered False, the likely confusion is that "AI tool" sounds like it generates output for you to copy-paste. Claude Code doesn't stop at generating code; it writes the file, runs the test, and reads the result, all on the machine where it's running. "The IDE extension gives Claude Code different capabilities than the CLI." True False False. The IDE extension and the CLI call the same agent, run on the same model, and have access to the same tool set. The surface changes the integration point, which is how you invoke Claude Code and where the output appears, not the underlying capability. If you answered True, the likely reason is that the terminal feels more "technical" and therefore more powerful. That intuition is wrong here. An IDE extension running in VS Code is not a lighter version; it's the same agent surfaced in a different wrapper. The distinction that does matter is the access surface, not the surface label. See the anatomy grid above for that nuance. The framing to carry forward: Claude Code is the same agent regardless of access point. The surfaces are wrappers. The intelligence, the loop, and the tool set are constant. What varies is the integration. Keep that in your back pocket for the first client conversation. Lesson 1 of 3 complete ## You know what it is. Now choose the right model. You can explain what Claude Code is, how the agentic loop works, and why it's categorically different from a chat interface, regardless of which surface the client or developer is using. Up next · Lesson 2 Claude family model selection and tradeoffs Haiku, Sonnet, Opus: how to pick the right model for a client's workload and defend that choice on cost, speed, and capability. --- # Lección: Claude family model selection and tradeoffs ## Claude family model selection and tradeoffs LESSON 2 OF 3 · PRODUCT FOUNDATIONS ## Three models, one recommendation, and when to deviate By the end of this lesson, you can recommend a model for a new Claude Code deployment and defend that choice against cost, speed, and capability objections. The model family ## Haiku is cheapest, Opus is sharpest, and Sonnet is where most production work lands. 01 Claude Haiku 4.5 Lowest cost tier · 200k context Cost Speed Depth Fastest and cheapest. Use when volume and speed matter more than reasoning depth. Best for: real-time apps, sub-agents, CI/CD pipelines, inline completions, and high-volume scripted tasks where latency and cost dominate. Tap to expand → 02 Claude Sonnet 4.6 Mid-range cost · 1M context Cost Speed Depth The production default for most Claude Code work. Best balance of speed and intelligence. Best for: day-to-day developer workflows, function writing, test generation, documentation, and most feature work. Where most pilots start. Tap to expand → 03 Claude Opus 4.8 Highest cost tier · 1M context Cost Speed Depth Sharpest reasoning. Use for complex, long-horizon, high-autonomy work where accuracy outweighs cost. Best for: autonomous refactoring runs, multi-hour tasks, architectural review, and any work where getting it right the first time justifies the premium. Tap to expand → Bars show relative position across the family, not exact figures. Verify current rates at anthropic.com/pricing before any client conversation. The decision ## Start with Sonnet, move to Opus for sustained reasoning tasks, and reach for Haiku when volume and cost dominate. Most pilots start with Sonnet and expand from there. High-volume or high-autonomy use cases are where the model mix gets more deliberate. Start fast (Haiku path) High-volume or time-sensitive Sub-agent pipelines, CI/CD scripting, rapid prototyping, cost-sensitive deployments. When throughput and latency matter more than reasoning depth. Start capable (Opus path) Complex or long-horizon tasks Autonomous refactoring runs, multi-hour tasks, work where getting it right the first time outweighs cost. Sonnet handles everything in between. The effort lever ## Before you switch models, try adjusting effort first. It's a cheaper move. The effort parameter tunes reasoning depth within a tier without switching models. On Opus 4.8, xhigh is available and is the recommended setting for coding and agentic work, often a better first lever than paying for a higher tier. On Sonnet 4.6, the parameter goes up to high, a useful lever before committing to Opus pricing. Writing unit tests for a 20-line utility function produces the same result at default effort as at extended thinking; a multi-file refactor with cross-module dependency analysis is where higher effort produces materially better output. To remember Model selection is an architecture decision; effort tuning is a performance lever. Know which you're reaching for before making a recommendation. Try the lever · effort on Opus 4.8 Default High xhigh Reasoning depth Relative cost xhigh effort: the recommended setting for coding and agentic work on Opus 4.8. You get the deepest reasoning the tier offers, often a better first move than paying for a higher model. Decision · Scenario ## Put the framework to work. Decision · Scenario Your client is rolling out Claude Code for 50 developers doing routine feature work (writing functions, generating tests, updating documentation). A small group will also run overnight autonomous refactoring tasks across legacy modules. What's your model recommendation? A · Haiku 4.5 for all tasks Cost-efficient at scale, keeping the bill low across 50 developers. B · Opus 4.8 for all tasks Ensures the best output quality across every type of work. C · Sonnet 4.6 default; Opus 4.8 for overnight runs Match the model to the task type. D · Sonnet 4.6 for all tasks One model across the entire team keeps configuration simple. Haiku works for simple, high-volume tasks, but complex refactoring, architectural review, and multi-step agentic tasks all require Sonnet or Opus. Using Haiku for everything degrades quality on the tasks that matter most to the client. The overnight autonomous runs in this scenario specifically need reasoning depth that Haiku cannot deliver reliably. Opus is the right call for the overnight autonomous runs, but running 50 developers on Opus for routine feature work adds roughly 65% cost for no meaningful quality gain. Sonnet handles function writing, test generation, and documentation updates at a comparable quality level and at a fraction of the cost. Match the model to the work, not to a single ceiling. Correct. Sonnet 4.6 handles routine feature work well at a reasonable cost. Opus covers the overnight autonomous runs where task complexity and duration justify the premium. This tiered approach gives the client cost efficiency on high-volume daily work while preserving reasoning depth for the tasks that need it. Sonnet for all tasks is a safe default, but you're overpaying for high-volume scripted tasks that Haiku handles just as well. Haiku handles simple, high-volume tasks like docstring generation or inline completions at lower cost and lower latency, with no meaningful quality penalty for those use cases. Most enterprise teams do better with a tiered model than one model for everything. Lesson 2 of 3 complete ## You have a model recommendation. Now choose where to run it. You can now map a client's workload profile to a model recommendation and explain the tradeoffs between cost, latency, and reasoning depth. Up next · Lesson 3 Platform options at a glance Seven deployment paths: how to match the right one to a client's cloud posture, seat type, and governance requirements. --- # Lección: Platform options at a glance: Enterprise, API, deployment paths LESSON 3 OF 3 · PRODUCT FOUNDATIONS ## Seven paths to Claude Code, one right fit for your client By the end of this lesson, you can map a client's cloud commitments, governance requirements, and feature needs to the right deployment option and explain why you're not recommending the others. The seven paths: Claude.ai Teams, Claude.ai Enterprise, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Azure AI Foundry, Anthropic API, and Anthropic Console. Three categories ## Full feature set, cloud-native, or API-only. Which category fits determines everything else. 01 Claude-managed (Teams + Enterprise) Full feature set, includes Claude on web and mobile, centralized billing, no infrastructure setup. Best for most GSI-led activations. Choose when: the client wants the fastest path to value and has no hard requirement to route through their own cloud. This is your default recommendation unless something rules it out. 02 Cloud-native (Bedrock, Vertex, Foundry) Routes through the client's existing cloud provider. IAM integration, regional data controls, billing through cloud. No Claude.ai web surface. Choose when: the client has existing cloud commitments or data-residency rules that force processing into a region they control. Flag the governance gap versus Enterprise. 03 API / Console Individual developers, API key auth, pay-as-you-go. No enterprise controls. Not the right path for a managed rollout. Choose when: a single developer or a prototype needs quick access. For a 200-seat governed rollout, this is the wrong category, name it only to rule it out. Try the framework ## Answer three questions the way you would on a discovery call. See where the path lands. Deployment picker This mirrors the real decision: cloud posture first, then governance, then feature surface. Pick an answer for each. 1Does the client require processing to stay inside a cloud region they control (residency, sovereign, existing commitment)? Yes — AWS Yes — GCP Yes — Azure No hard requirement 2Is the security team asking for SSO, audit logs, managed settings, or Compliance API? Yes, governance matters No, keep it light 3What's the scope of the rollout? A team or whole org A single dev or prototype Recommended path — Reset A guide, not a contract. Real deployments weigh procurement path, existing licensing, and security sign-off alongside these three questions. Enterprise vs Teams ## Enterprise isn't more seats. It's the controls tier. Teams For getting started Usage-based billing plus a per-seat subscription fee. Verify current pricing at anthropic.com/pricing. Team management, admin tools, basic SSO. A starting tier, not the right fit for most enterprise rollouts. Enterprise For governed rollouts SSO with domain capture, SCIM provisioning, RBAC, Compliance API, and managed policy settings. If the client's security team is asking about audit logs or managed settings, this is the tier. For most GSI-led activations, recommend Enterprise. If a client asks about SSO, managed settings, or audit logs, Teams won't satisfy the requirement. Cloud-native path ## Route through the client's cloud when they have existing commitments or data residency requirements. Bedrock for AWS-first clients, Vertex for GCP, Foundry for Azure. The trade-off: billing through their cloud, IAM integration, regional data controls, but no Claude.ai web surface, no managed settings, no Compliance API. An LLM Gateway (a middleware layer that routes model API calls through corporate network controls, adding logging, filtering, and policy enforcement before requests reach the model provider) can sit between Claude Code and any cloud provider to add centralized auth, usage tracking, and rate limiting on top. To remember Cloud-native routing satisfies an existing commitment, not a security requirement. The governance gap compared to Enterprise is real and worth flagging to the client. Seat types ## Usage-based Claude Code access requires the right seat type. Flag this early in procurement. Standard Chat only No Claude Code access. Most common default seat. Confirm this isn't what the client is buying before kickoff. Watch for: a client who assumes "we have Claude" means developers can run Claude Code. A Standard seat does not include it, this is the most common mismatch. Chat + Code Includes Claude Code The minimum tier for Claude Code access. Confirm this is in the procurement scope before the engagement starts. Watch for: the gap between what was demoed and what was purchased. If the pilot used Code, the contract must include this tier or higher. Claude Enterprise Full enterprise tier Includes Claude Code, all enterprise controls, and Compliance API access. The right seat for governed rollouts. Watch for: security teams asking about audit logs or managed settings, that requirement points here, not at the lower tiers. Procurement flag Confirm before kickoff Seat type mismatches are a common cause of activation delays. Add this to your pre-kickoff checklist. Watch for: procurement closing on the wrong tier weeks before kickoff. Catching it early is far cheaper than a mid-engagement contract amendment. These seat names reflect the usage-based pricing model. Clients on legacy seat-based plans use Standard and Premium seat types instead. Confirm which model the client is on before procurement. It affects both naming and what each seat includes. Platform selection ## Apply the framework to a real scenario. Decision · Scenario Your client is a financial services firm. They are heavily invested in AWS, their security policy requires all data processing to stay within approved AWS regions, and their IT team manages developer devices with Intune. They want a Claude Code rollout for 200 developers. A · Claude for Enterprise direct Fullest feature set, SSO, Compliance API. The standard GSI recommendation. B · Amazon Bedrock with LLM Gateway Satisfies the AWS-native and regional data processing requirements. C · Google Vertex AI Strong enterprise integration and regional data options. D · Anthropic Console Simple setup, API key auth, no infrastructure required. Why not Enterprise (Option A): Claude.ai Enterprise is a SaaS product. Anthropic's infrastructure determines where processing occurs, and the client has no control over which region handles their data. Clients that need explicit regional data boundaries (GDPR, sovereign cloud, data residency contracts) require a cloud provider deployment (Bedrock, Vertex, or Azure) where they choose and control the region. This is the most common reason enterprise clients choose cloud provider deployments over managed SaaS. Why Bedrock (Option B): Bedrock satisfies the regional data processing requirement and routes through the client's existing AWS infrastructure and billing. Add an LLM Gateway for centralized auth and usage tracking. Be explicit about the trade-off: they lose the Claude.ai web surface and Enterprise admin features. Assess with the client's security team whether that gap needs to be addressed separately. Claude for Enterprise is the right default when cloud-native routing is not a requirement. On Intune: Intune is relevant to how Claude Code gets distributed to developer endpoints, not to the deployment architecture decision. That question is driven by data residency requirements, existing cloud commitments, and procurement path. Practice Try this You've covered what Claude Code is, how to match workloads to the right model tier, and which deployment path fits which client profile. A good way to put it to work: take three client scenarios with different cloud postures, automation requirements, and team sizes, and see if you can pair each one with a deployment path and model. If you can explain the deciding factor for each in a sentence, you're ready to make that call in the room. Product Foundations · Complete ## You can frame Claude Code. Now go deploy it. You can explain what Claude Code is, recommend the right model for a workload profile, and map a client's cloud posture to the right deployment path. Next course Installation and Environments The frameworks from this course only matter once Claude Code is actually running. Installation and Environments covers OS-specific installation, IDE integration, authentication, and the security boundaries you'll need to configure before the first developer session.