Examen de práctica Claude Certified Developer – Foundations

Cómo estudiar para el examen Claude Certified Developer

Construye algo real contra la Messages API antes de presentarte — la mayoría de las preguntas de integración evalúan hechos que internalizas en una tarde de código: model, max_tokens y messages son los parámetros obligatorios; el primer mensaje debe tener rol "user"; la API no tiene estado, así que reenvías toda la conversación; stream: true entrega eventos content_block_delta para mejorar la latencia percibida; las imágenes van en bloques de contenido, no en un endpoint aparte; el budget_tokens de thinking debe ser menor que max_tokens. El prompt caching es coincidencia exacta de prefijo — un timestamp al inicio del system prompt mata silenciosamente cada acierto de caché, y añadir una herramienta invalida todo el caché porque las tools se renderizan antes que system y messages.

Para agentes, interioriza "Building Effective Agents" de Anthropic: workflows (rutas de código predefinidas) para pasos fijos y predecibles; agentes (bucles dirigidos por el modelo) solo cuando la ruta no puede conocerse de antemano; y empieza siempre por lo más simple que funcione. Las preguntas de seguridad premian los mismos instintos que la seguridad de aplicaciones clásica: trata la salida del modelo y el contenido recuperado como entrada no confiable, delimita el contenido del usuario para que un "ignora las instrucciones anteriores" inyectado siga siendo datos, limita las herramientas al mínimo privilegio y usa hooks — no reglas de prompt — cuando se requiere una garantía. En Claude Code, conoce las superficies de configuración (CLAUDE.md en la raíz del repo para convenciones compartidas, settings.local.json para permisos personales, -p --output-format json para CI) y que los subagentes aíslan búsquedas ruidosas en su propio contexto. Luego haz nuestro simulacro cronometrado de 53 preguntas para ensayar el formato real.

Los mecanismos de uso de herramientas merecen una sesión de estudio propia, porque aquí las preguntas son precisas y los detalles se recuerdan a medias con facilidad. Interioriza la forma del bucle: envías la conversación junto con tus definiciones de herramientas, el modelo puede responder con uno o varios bloques de uso de herramienta, tú los ejecutas y devuelves todos los resultados —cada uno con el id de la llamada a la que responde— en un único mensaje de usuario, no repartidos en varios. Separarlos u omitir uno rompe el emparejamiento del que depende el modelo. Una herramienta que falla sigue siendo un resultado: devuélvelo marcado como error y con un mensaje sobre el que el modelo pueda actuar, en lugar de omitirlo o dejar que la excepción se propague. Añade de vuelta al historial todo el contenido del turno del asistente y no solo su texto, para que los bloques de uso de herramienta sobrevivan al siguiente turno. Y trata la definición de la herramienta como la interfaz contra la que el modelo realmente programa: la descripción y las descripciones de los parámetros son lo que determina si llama a la herramienta correcta con los argumentos correctos, de modo que una herramienta mal descrita es un problema de corrección, no un detalle cosmético de documentación.

Completa tu preparación con la mitad operativa del trabajo: coste, latencia y saber si aquello funciona. El caché premia una disciplina concreta: pon primero el material estable y al final el volátil, porque el caché casa por prefijo y cualquier cosa que cambie al principio invalida todo lo que viene después. Esa única regla explica la mayoría de los fallos de caché en la práctica, incluido el clásico autoinfligido en que una marca de tiempo o un identificador por petición se cuela cerca del inicio del prompt y desbarata todo el mecanismo en silencio. Verifica en lugar de suponer: las cifras de consumo de cada respuesta te dicen cuánto se escribió en el caché y cuánto se leyó de él. Para el trabajo que no es sensible a la latencia, el procesamiento por lotes cambia inmediatez por una tarifa menor, y el detalle que conviene recordar es que los resultados se emparejan por el identificador que asignaste a cada petición y no por su posición, ya que no tienen por qué volver en orden. Por último, aprende las razones de parada y ramifica según ellas: un turno que terminó por alcanzar el límite de salida, porque quiere una herramienta o porque fue rechazado son tres situaciones distintas, y el código que lee el primer bloque de contenido sin comprobarlo acabará equivocándose.