Developer – Foundations
Este examen es el único de los cuatro cuya guía publica el peso de cada skill, no solo de cada dominio. Con 53 ítems y los pesos oficiales se puede calcular cuántas preguntas caen por tema, y eso cambia por completo dónde merece la pena invertir el tiempo. El resto de la página parte de ese cálculo.
La ficha
| Código | CCDV-F | Ítems | 53 |
|---|---|---|---|
| Tiempo | 120 minutos (≈2 min 15 s por ítem) | Corte | 720 sobre 100-1.000 |
| Formato | Opción múltiple y respuesta múltiple; cada ítem indica cuántas hay que marcar | ||
| Tasa | 125 $ | Validez | 12 meses |
Criterio-referenciado: compites contra un estándar fijo, no contra otros candidatos. El informe te da el escalado total y el % de acierto por dominio, pero el aprobado depende solo del total.
Mapa de skills: cuántos ítems vale cada tema
Los 25 skills del blueprint, ordenados por peso, con la conversión a ítems esperados sobre 53. La columna de prioridad es mía, no de la guía: cruza el peso con lo que ya sabes por tu trabajo diario.
| Skill | Dominio | Peso | Ítems | Prioridad |
|---|---|---|---|---|
| Claude Application Design | 2 | 8,6% | 4,6 | Máxima |
| Software Engineering Foundations | 2 | 7,4% | 3,9 | Repaso rápido |
| Claude API Mechanics | 2 | 6,8% | 3,6 | Máxima |
| Technical Fundamentals | 5 | 6,1% | 3,2 | Repaso rápido |
| Agent Construction with Claude | 1 | 5,3% | 2,8 | Alta |
| LLM Fundamentals | 5 | 5,2% | 2,8 | Alta |
| Agent Patterns and Frameworks | 1 | 4,9% | 2,6 | Alta |
| Prompt Engineering | 6 | 4,6% | 2,4 | Media |
| Agent Architecture | 1 | 4,5% | 2,4 | Media |
| Tool Implementation | 8 | 4,4% | 2,3 | Media |
| Configuration Management | 2 | 4,1% | 2,2 | Media |
| Agentic Customization | 8 | 4,1% | 2,2 | Media |
| Context Engineering | 6 | 3,8% | 2,0 | Media |
| Understanding Requirements | 2 | 3,4% | 1,8 | Baja |
| AI Application Security | 7 | 3,2% | 1,7 | Media |
| Claude Code Operation | 3 | 3,1% | 1,6 | Ignorar |
| Systems Life Cycle | 2 | 2,8% | 1,5 | Baja |
| Cost and Token Management | 5 | 2,8% | 1,5 | Media |
| Model Selection and Tradeoffs | 5 | 2,7% | 1,4 | Baja |
| Output Handling | 6 | 2,6% | 1,4 | Baja |
| Debugging and Error Handling | 4 | 2,6% | 1,4 | Baja |
| Guardrails and Safe Deployment | 7 | 2,3% | 1,2 | Baja |
| MCP Server Development | 8 | 2,1% | 1,1 | Baja |
| Identity, Secrets, Key Management | 7 | 1,6% | 0,8 | Baja |
| Claude Hooks | 7 | 1,0% | 0,5 | Ignorar |
2. Claude Code vale 3,1% y Claude Hooks 1,0%: entre los dos, dos ítems. Es exactamente lo que más usas a diario y lo que menos te renta estudiar. Resiste la tentación.
3. Software Engineering Foundations + Technical Fundamentals = 13,5%, siete ítems, y es ingeniería de software genérica: REST, JSON, asincronía, control de versiones, code review, refactor, websockets, SDKs que envuelven APIs REST. Puntos casi gratis para ti.
1 · Claude Application Design — 8,6%, el skill más pesado
El objetivo literal habla de «cómo interpreta Claude las instrucciones a través de las interfaces, límites de contenido, diseño de esquemas, higiene de sesión y gestión de plugins». No existe una página oficial con ese título: es una síntesis del examinador sobre cinco áreas distintas. Aquí están las cinco.
Cómo cambia la interpretación según la interfaz
- API cruda: no hay más system prompt que el tuyo, con una excepción — si mandas
tools, la API construye automáticamente un system prompt con el bloque de instrucciones de tool use, los esquemas JSON, tu system prompt y la configuración de tools, en ese orden. Cuesta cientos de tokens que no escribiste tú. - Si incluyes el memory tool, la API añade sola su protocolo de memoria al system prompt. No hay que reenviarlo.
- claude.ai, móvil y escritorio tienen system prompt propio (fecha, formato, comportamiento de producto) que no se aplica a la API. Anthropic lo publica íntegro en sus release notes.
- Agent SDK: tres puntos de partida — sin system prompt (mínimo, solo tool calling), con el preset de Claude Code (prompt completo del CLI), o con el tuyo.
claude -p usa el prompt completo por defecto; el Agent SDK no. Al portar algo del CLI al SDK hay que fijar el preset explícitamente o el agente pierde toda la guía de comportamiento y parece «tonto» sin motivo aparente. Y en el SDK, CLAUDE.md no va al system prompt: se inyecta como contexto de conversación y su carga depende de los setting sources.Content boundaries
Separar instrucciones, contexto, ejemplos y entrada variable en etiquetas XML propias, con nombres consistentes. En contextos largos (20k+ tokens): los documentos arriba, la pregunta al final — hasta un 30% de mejora en las pruebas de Anthropic. Y la regla dura ya conocida: el contenido de terceros va solo en bloques tool_result, nunca en el system prompt ni en texto de usuario.
Diseño de esquemas: los límites que se preguntan
| Límite | Valor |
|---|---|
Tools con strict: true por request | 20 |
| Parámetros opcionales, total del request | 24 |
Parámetros con tipos unión (anyOf) | 16 |
| Timeout de compilación de la gramática | 180 s |
Soportado: tipos básicos, enum escalar, const, anyOf, $ref interno, default, required, formatos de string. No soportado (400 si lo usas): esquemas recursivos, $ref externo, restricciones numéricas como minimum/maximum, minLength/maxLength, y lookahead en pattern.
Para reducir complejidad, el orden oficial es: marcar strict solo las tools críticas → convertir opcionales en required (cada opcional casi duplica parte del espacio de estados) → aplanar anidamientos → repartir en varios requests o subagentes.
Higiene de sesión
Qué sobrevive a la compactación y qué no: el system prompt queda intacto y el CLAUDE.md de raíz se reinyecta desde disco; se pierden las reglas con paths: y los CLAUDE.md anidados hasta que se vuelva a leer un fichero que las active. Los cuerpos de skills invocadas se reinyectan con tope por skill y total, descartando las más antiguas.
Y una recomendación que suena contraintuitiva: a menudo es mejor empezar en limpio que compactar, porque el modelo puede reconstruir el estado desde el filesystem si le das un arranque prescriptivo («revisa progress.txt, tests.json y el git log»).
Plugins
Un plugin es un directorio autocontenido con skills, agents, hooks, servidores MCP y ajustes por defecto. Solo el manifiesto va dentro de .claude-plugin/; el resto de carpetas van en la raíz. Cuatro scopes de instalación: user (por defecto), project (compartido por git), local (gitignored) y managed (solo lectura). El versionado es la clave de caché de las actualizaciones, y se resuelve en cascada: versión del manifiesto → versión del marketplace → SHA del commit → digest → desconocido.
2 · Claude a través de terceros — dentro de API Mechanics, 6,8%
El objetivo dice «invoking Claude through third-party vendors». Hoy son cinco plataformas, no tres, y la distinción que más se puede preguntar es quién procesa los datos.
| Plataforma | Quién opera | Cliente del SDK | Auth |
|---|---|---|---|
| Claude API | Anthropic | Anthropic | API key |
| Amazon Bedrock | AWS | AnthropicBedrock / AnthropicBedrockMantle | Credenciales AWS |
| Claude Platform on AWS | Anthropic | AnthropicAWS | IAM o API key |
| Google Cloud / Vertex | AnthropicVertex | Credenciales Google | |
| Microsoft Foundry | Anthropic sobre Azure | AnthropicFoundry | API key de Azure o Entra ID |
Lo que cambia en el código es solo la clase del cliente y la autenticación: client.messages.create(...) es idéntico.
Diferencias que caen
- Vertex: el
modelno va en el body (va en la URL) y en cambioanthropic_versionsí va en el body. Es la diferencia de formato más citable. - Tamaño máximo de petición: Bedrock 20 MB, Vertex 30 MB.
- Batch processing y data residency existen solo en la Claude API y en Claude Platform on AWS. En Bedrock, Vertex y Foundry no hay Batches.
- Bedrock exige inference profiles para los modelos nuevos: invocar con el model ID base devuelve 400. Prefijos
global.,us.,eu.… - Global vs regional: el enrutado regional garantiza residencia y cuesta un 10% más.
3 · Frameworks agénticos — 4,9%
El blueprint nombra tres explícitamente: Strands, LangGraph y PydanticAI. No hace falta saber programarlos; hay que saber para qué se elige cada uno.
| Framework | Idea central | Se elige cuando |
|---|---|---|
| Strands (AWS) | Bucle agéntico «model-driven» ya hecho, agnóstico de modelo, con MCP nativo y patrones multi-agente | Quieres un bucle sin escribirlo y despliegas en AWS |
| LangGraph | Orquestación de bajo nivel por grafo de estado: nodos hacen el trabajo, edges deciden el siguiente | Necesitas ejecución durable y reanudable, human-in-the-loop y topología auditable |
| PydanticAI | Bucle tipado: el modelo Pydantic genera el esquema y valida cada ejecución; si falla, re-prompta al modelo | El valor está en el contrato de datos y en la portabilidad de proveedor |
De LangGraph, dos conceptos con nombre propio que se prestan a pregunta: los reducers (sin reducer, el update de un nodo sobrescribe la clave del estado) y la diferencia entre checkpointer (snapshots de un hilo, memoria a corto plazo, time travel) y store (clave-valor entre hilos, memoria a largo plazo). Los checkpoints se guardan en fronteras de paso, no a mitad de nodo, así que al reanudar el nodo se re-ejecuta entero: los nodos deben ser idempotentes.
Matriz oficial de producto
- Client SDK (Messages API): acceso directo, tú implementas el bucle. Máximo control.
- Agent SDK: agente sin implementar el tool loop, corre en tu proceso.
- Claude Code CLI: uso interactivo o puntual en terminal.
- Managed Agents: agentes largos y asíncronos sin gestionar sandbox ni sesiones. Es un producto separado del Agent SDK, con API REST hospedada.
4 · Despliegue: self-hosted vs Anthropic-hosted — dentro de Agent Construction, 5,3%
El objetivo menciona «managed agent deployment models (self-hosted vs. Anthropic-hosted)». La distinción exacta:
- Self-hosting del Agent SDK: el SDK lanza un subproceso por sesión con shell, directorio de trabajo y transcripciones en disco local. N sesiones son N subprocesos. El estado local no sobrevive a reinicios, así que en producción hace falta un almacén de sesiones externo que espeje las transcripciones.
- Managed Agents (Anthropic-hosted): harness preconstruido sobre infraestructura gestionada. Cuatro conceptos: Agent (modelo, prompt, tools), Environment (dónde corre), Session (instancia en ejecución) y Events (historial persistido en servidor). Cada sesión recibe su propio sandbox aislado.
Hay un tercer modelo intermedio: self-hosted sandbox dentro de Managed Agents, donde la orquestación sigue en Anthropic y solo la ejecución de tools se mueve a tu infraestructura. Ojo al matiz: los inputs y outputs de las tools siguen fluyendo al plano de control de Anthropic.
5 · Los dos skills «gratis» — 13,5% juntos
Software Engineering Foundations (7,4%) y Technical Fundamentals (6,1%) no van de Claude: van de ingeniería de software. REST y JSON, programación asíncrona, control de versiones, integración en el ciclo de desarrollo, code review, refactorización a pequeña y gran escala, y SDKs que envuelven APIs REST y websockets. Son siete ítems que ya sabes responder; no gastes tiempo aquí más allá de una lectura.
Understanding Requirements (3,4%) y Systems Life Cycle (2,8%) tampoco son técnicos de Claude: requisitos funcionales y de infraestructura derivados de necesidades de negocio, y gestión del ciclo de vida de sistemas. Responde con criterio de ingeniería clásica: primero requisitos y criterios de aceptación, después arquitectura; y nada llega a producción sin observabilidad ni plan de reversión.
6 · Cómo enseña el módulo oficial (y qué implica para los ítems)
El módulo Production-grade prompting, Agents & tool use no enseña definiciones: enseña diagnóstico. Cada takeaway tiene la forma «este síntoma significa que falta esta técnica». Los ítems se escriben contra ese molde, así que la pregunta típica no será «¿qué es X?» sino «esto está fallando, ¿qué falta?».
La tabla de diagnóstico que hay que saber en frío
| Síntoma | Lo que falta |
|---|---|
| La salida no tiene la forma esperada | Una restricción de salida |
| Deriva de comportamiento entre turnos | System prompt poco especificado |
| Estructura alucinada | Ejemplos few-shot |
| Entradas no probadas siguen rompiendo el parser | Salir del prompt: salida estructurada en la API |
| La selección de tool se degrada tras N turnos | La ventana de contexto, no el esquema |
| Se elige la tool equivocada desde el primer turno | La descripción de la tool |
| Error de tool use al reintentar tras un stream caído | Un bloque a medio construir, no el esquema |
Cifras y reglas nuevas que aporta el módulo
- Condición de exclusión: cada descripción de tool debe incluir una línea que diga cuándo NO llamarla, escrita al diseñar el esquema y no después del primer fallo en un log. Es la frase que resuelve la mayoría de bugs de tool equivocada: dos tools que dicen «úsala para buscar información» son indistinguibles para Claude por muy distintos que sean sus esquemas.
- Las salidas de tools en producción ocupan de 3 a 5 veces más que los fixtures de desarrollo. Una sesión que aguanta 50 turnos en pruebas puede tocar techo en el turno 8 al desplegarse.
- Un servidor MCP conectado gasta contexto aunque no uses sus tools. La doc pone cifra: un montaje típico de cinco servidores consume ~55.000 tokens en definiciones antes de que Claude haga nada. Tool search lo reduce más de un 85%.
- Coste de imagen:
⌈ancho / 28⌉ × ⌈alto / 28⌉visual tokens — Claude ve parches de 28×28 px, no píxeles. - El refactor de memoria en contexto a almacenamiento externo bajo presión de producción cuesta una hora; tomar la misma decisión a conciencia en diseño cuesta veinte minutos.
El techo de tokens de imagen es por tier, no por modelo
| Tier | Lado máximo | Visual tokens máx. |
|---|---|---|
| Alta resolución (modelos 4.7 y posteriores) | 2576 px | 4784 |
| Estándar (todos los demás) | 1568 px | 1568 |
Las imágenes que superan cualquiera de los dos límites se reescalan automáticamente al mayor tamaño que respeta la proporción, lo que acota el coste. Después se aplica padding al siguiente múltiplo de 28 px. Una imagen de alta resolución puede costar unas tres veces más que la misma en un modelo de tier estándar, así que la fórmula hay que correrla contra la entrada más grande que esperas en producción, no contra las de tu set de pruebas.
Streaming: dónde el módulo y la documentación no coinciden
En lo básico coinciden, y es lo que hay que llevar sabido: un bloque solo está cerrado en su content_block_stop y el mensaje solo termina en message_stop. Los deltas de un tool use son cadenas JSON parciales: no se parsean hasta que el bloque cierra.
La documentación viva dice otra cosa: reanudar, no descartar — y en los modelos recientes hacerlo añadiendo un mensaje de usuario que pida continuar, no metiendo la respuesta parcial como mensaje del asistente.
Punto en el que sí coinciden y que probablemente sea el examinable: los bloques de tool use y de thinking no se pueden recuperar parcialmente. Solo se puede reanudar desde el último bloque de texto. Si un ítem te ofrece «acumula y reintenta el
tool_use parcial», es el distractor.Los cuatro alcances de memoria, elegidos por la forma de la sesión
| Alcance | Coste | Cuándo |
|---|---|---|
| En contexto | El más fácil de escribir | El primero que falla si las sesiones reales son cortas y numerosas |
| Almacenamiento externo | Añade latencia | El estado debe sobrevivir entre sesiones |
| Memoria resumida | Baja el coste | Se pierde lo que el prompt del resumidor no preservó |
| Sin estado | Ninguno | Trabajos que se completan y se cierran |
Workflow o agente, en la formulación del módulo
Workflow cuando puedes escribir los pasos exactos en código. Agente cuando puedes especificar el objetivo y las tools pero no el camino entre ellos. Equivocarse solo se ve en producción: agentes donde bastaba un workflow añaden coste de contexto y comportamiento que vive en transcripciones; workflows donde hacía falta un agente se rompen con la primera entrada que se sale del camino.
Razonamiento
Activarlo solo donde una pasada de razonamiento cambia la respuesta, y calibrar el effort al problema en vez de subirlo en todas las llamadas. Los bloques de thinking vuelven a la API sin modificar o la siguiente petición falla. Ojo a la distinción del módulo: elegir qué modelo ejecutar es un tema distinto de si activar el razonamiento, y se enseña en un módulo anterior.
Plan de 10 días
Ordenado por peso, no por temario. Cada día cierra con una tanda de tarjetas del tema, y los tres últimos días son solo simulacro y fallos.
Interfaces y qué inyecta cada una. Lee la página de modificación de system prompts del Agent SDK y las release notes de system prompts. Porta un prompt tuyo del CLI al SDK y observa la diferencia.
Esquemas: límites de complejidad, qué admite y qué no el JSON Schema estricto. Higiene de sesión y qué sobrevive a la compactación. Plugins: scopes y versionado.
Messages, streaming y sus errores, batch con sus límites y estados, y las cinco plataformas con su data processor. Escribe una llamada por batch de verdad y mira el ciclo completo.
Los cuatro skills del dominio 5: fundamentos de LLM, fundamentos técnicos, tradeoffs de modelo y gestión de coste. Prompt caching a fondo: TTL, invalidación y el fallo silencioso del mínimo de tokens.
Arquitectura, construcción con el Agent SDK, y los tres frameworks con su criterio de elección. Self-hosted vs Managed Agents y la consecuencia de compliance.
Implementación de tools, desarrollo de servidores MCP, y los tradeoffs entre tool built-in, tool propia, Skill y MCP. Monta un servidor MCP mínimo si no lo has hecho nunca.
Ingeniería de prompt y de contexto, manejo de salida, y el dominio 7 entero: inyección indirecta, guardrails, secretos. Salta los hooks: valen medio ítem.
53 ítems cronometrados a 120 minutos. Sin pausas y sin consultar. Anota el acierto por dominio.
Repaso dirigido de los dominios rojos del simulacro. Nada de material nuevo.
Simulacro y repaso de la tabla de números. Si el ponderado no pasa del 85%, mueve la fecha.
Las tres preguntas de muestra oficiales
Vienen en la guía. No salen del banco real, pero fijan el nivel cognitivo: todas son de escenario y todas se resuelven con un principio, no con memoria.
- Enviar todo síncrono en paralelo para acabar cuanto antes.
- Usar la Message Batches API.
- Bajar
max_tokensen las llamadas síncronas. - Cambiar al modelo más pequeño sea cual sea la calidad.
max_tokens ni reducir el modelo atacan el tradeoff batch-vs-tiempo real.- Subir la temperatura para que sea menos predecible.
- Tratar el contenido recuperado como entrada no confiable, mantenerlo separado de las instrucciones y usar guardrails o hooks para que lo inyectado no dispare acciones sensibles.
- Pedir en el system prompt que no incluyan instrucciones maliciosas.
- Cambiar a un modelo mayor que siga mejor las instrucciones.
- Meter la lógica en el system prompt de cada aplicación.
- Construir un servidor MCP que exponga las operaciones como tools.
- Pegar los datos de inventario en el contexto en cada petición.
- Confiar en una tool built-in, que puede alcanzar cualquier API REST interna.
Las 48 horas de antes
- Repasa la tabla de números y la sección de trampas por versión. Ahí está casi toda la parte memorística.
- Haz una pasada completa de tarjetas de los temas API y batch, Caching, Modelos y coste. Son los que más cifras exactas tienen.
- Un simulacro cronometrado, no dos. Descansar rinde más que un repaso de última hora.
- Prepara el DNI con el nombre idéntico al del registro, y despeja la mesa: nada de notas, móvil, reloj ni segundo monitor.