Product Foundations — Resumen de estudio

Path: Architect · 3 lecciones interactivas
Lo que necesitas saber antes de asesorar a un cliente sobre Claude Code: qué es, qué modelo recomendar y por qué vía desplegarlo.

1. Qué es Claude Code y cómo se comporta en un codebase

Un chat responde preguntas y genera texto, sin acceso a archivos, terminal ni proyecto, y sin estado entre mensajes. Claude Code trabaja dentro del codebase: lee y escribe archivos, ejecuta bash, edita en muchos archivos y mantiene el contexto de la sesión hasta terminar.
Loop: Observe → Plan → Act → Verify (vuelve a Observe si algo falla):
- Observe: hace grep, abre los archivos relevantes, lee la terminal. Mira primero, no asume.
- Plan: pasos, archivos y comandos. En tareas grandes muestra el plan para que apruebes el enfoque.
- Act: cada tool call es una operación real, registrada y visible (diff, comando, salida). Por eso es auditable.
- Verify: muestra el resultado y espera tu aprobación. Un test que falla vuelve a Observe.
Superficies: el mismo modelo y el mismo loop; cambia el punto de integración, no la inteligencia.
- CLI: acceso nativo al sistema operativo (archivos y terminal). Es la referencia para configurar todo lo demás.
- Extensiones de IDE (VS Code, JetBrains): lo mismo que la CLI; el editor es un envoltorio, no una versión ligera.
- Agent SDK: el acceso que le dé el entorno (en CI/CD, el del runner).
- Desktop / Web / Mobile: corren en la nube y acceden a archivos y terminal solo si se invoca explícitamente el agente. Esta diferencia importa al definir el alcance de un despliegue.
Verdadero o falso:
- "Usa otro modelo que Claude.ai" → Falso: la misma familia; el modelo se configura.
- "Ejecuta bash y edita archivos" → Verdadero: son tools reales, que el admin puede limitar.
- "La extensión del IDE tiene otras capacidades" → Falso.

2. Elegir modelo

Modelo	Costo · contexto	Para
Haiku 4.5	El más barato · 200k	Apps en tiempo real, subagents, CI/CD, completado inline, tareas masivas guionizadas
Sonnet 4.6	Medio · 1M	El default de producción: funciones, tests, documentación, la mayoría de las features. Donde arrancan los pilotos
Opus 4.8	El más caro · 1M	Refactors autónomos, tareas de horas, revisión de arquitectura, cuando acertar a la primera justifica el costo

Regla: empieza con Sonnet, usa Opus para razonamiento sostenido y Haiku cuando dominan el volumen y el costo.
Antes de cambiar de modelo, ajusta el effort (es más barato):
- En Opus 4.8, xhigh es lo recomendado para código y trabajo agentic.
- En Sonnet 4.6 llega a high.
- Un test unitario de 20 líneas no gana nada con más effort; un refactor de varios archivos con dependencias cruzadas sí.
La elección de modelo es una decisión de arquitectura; el effort es una palanca de rendimiento.
Escenario (50 devs en trabajo rutinario + refactors autónomos nocturnos): C: Sonnet por defecto y Opus para lo nocturno.
- Todo en Haiku pierde calidad donde más importa.
- Todo en Opus cuesta ~65% más sin ganancia.
- Todo en Sonnet paga de más en las tareas masivas que Haiku resuelve.
- Un esquema por niveles suele ser lo mejor.

3. Las 7 vías de despliegue

Claude.ai Teams · Claude.ai Enterprise · Amazon Bedrock · Google Vertex AI · Microsoft Azure AI Foundry · Anthropic API · Anthropic Console. Se agrupan en 3 categorías:

Gestionadas por Claude (Teams + Enterprise): todas las funciones, Claude en web y móvil, facturación centralizada, sin infraestructura. Es la recomendación por defecto si nada la descarta.
Cloud-native (Bedrock, Vertex, Foundry): pasan por la nube del cliente (IAM, control regional de datos, facturación en la nube). No incluyen la web de Claude.ai, managed settings ni Compliance API.
API / Console: un desarrollador, API key, pago por uso, sin controles empresariales. Solo para prototipos.

Selector (en este orden): ¿el procesamiento debe quedar en una región de nube que controla el cliente? → ¿seguridad pide SSO, audit logs, managed settings o Compliance API? → ¿es un equipo/organización o un solo desarrollador?

Teams vs Enterprise: Enterprise no es "más asientos", es el nivel de controles.
- Teams: gestión de equipo, admin, SSO básico.
- Enterprise: SSO con domain capture, SCIM, RBAC, Compliance API, managed policy settings.
- Si preguntan por SSO, managed settings o auditoría, Teams no alcanza.
Cloud-native atiende un compromiso existente con un proveedor, no un requisito de seguridad. Señala la brecha de gobierno frente a Enterprise.
LLM Gateway: un middleware que pasa las llamadas por los controles de red corporativos (auth centralizada, logs, filtrado, rate limits) y puede ir delante de cualquier proveedor.
Tipos de asiento (modelo por uso):
- Standard: solo chat, sin Claude Code. Es el error más común: "tenemos Claude" no significa que los devs puedan usar Claude Code.
- Chat + Code: el mínimo para Claude Code.
- Claude Enterprise: todos los controles + Compliance API.
- Confírmalo antes del kickoff (lo comprado frente a lo que se mostró en la demo). Los planes legacy usan Standard/Premium.
Escenario (banco en AWS, procesamiento obligatorio en regiones aprobadas, Intune, 200 devs): B: Bedrock + LLM Gateway.
- Con Enterprise (SaaS), el cliente no controla la región.
- Hay que explicitar lo que se pierde (web de Claude.ai y funciones de admin de Enterprise).
- Intune solo afecta la distribución a los equipos, no la arquitectura.