Capital de Tokens
15 horas de certificación de Anthropic: lo que realmente enseña y lo que deja fuera
La educación sobre inteligencia artificial tiene un problema extraño: cuando un curso consigue explicar con claridad una herramienta, existe la posibilidad de que esa herramienta ya haya cambiado.
Ese es el contexto detrás de una experiencia interesante publicada por Natalia Quintero, responsable de consultoría de Every. Parte del equipo de Every completó la formación necesaria para obtener la certificación de Anthropic y dedicó aproximadamente 10 a 15 horas por persona a cuatro cursos oficiales.
El resultado no fue una colección de secretos para multiplicar la productividad con Claude.
Fue algo más básico y, probablemente, más importante para una industria que todavía está definiendo sus conceptos: un lenguaje compartido.
El artículo original de Every puede leerse aquí: What We Learned From 15 Hours of Anthropic Certification Training.
Los cuatro bloques de la certificación
Según Every, el recorrido exigido para la certificación incluía cuatro áreas:
- Introduction to Agent Skills
- Building with the Claude API
- Introduction to Model Context Protocol (MCP)
- Claude Code in Action
La selección es reveladora porque muestra qué considera Anthropic parte del conocimiento fundamental para trabajar con sistemas modernos basados en Claude.
No se trata solamente de aprender a escribir mejores prompts.
El mapa ya incluye:
modelo
↓
prompt + contexto
↓
tools / API
↓
MCP
↓
skills
↓
agentes y workflows
↓
evaluación y verificaciónEse cambio es importante. Durante buena parte de la primera etapa de la IA generativa, aprender a usar un modelo significaba principalmente aprender a conversar con él. Ahora el conocimiento se está desplazando hacia cómo diseñar el sistema que rodea al modelo.
La gran lección: las definiciones importan
Every esperaba encontrar formación que transformara la manera en que su equipo construía workflows. Sin embargo, la principal utilidad resultó ser otra.
Los cursos establecen respuestas oficiales a preguntas que en la práctica suelen tener definiciones imprecisas:
- ¿Qué es exactamente un Skill?
- ¿Cuándo conviene un Skill y cuándo un archivo de instrucciones del proyecto?
- ¿Qué problema resuelve MCP?
- ¿Qué diferencia hay entre una tool, un resource y un prompt dentro de MCP?
- ¿Cómo piensa Anthropic la construcción de aplicaciones con su API?
- ¿Cómo encaja Claude Code dentro de un workflow de ingeniería?
Eso puede parecer demasiado elemental para alguien que ya utiliza estas herramientas todos los días. Pero en una organización grande, tener diez definiciones diferentes para “agente”, “skill” o “MCP” termina convirtiéndose en un problema de arquitectura y comunicación.
Una especificación compartida permite que un desarrollador, un arquitecto, un responsable de producto y alguien de operaciones hablen de la misma cosa.
En ese sentido, la certificación funciona menos como un manual de trucos y más como una capa de normalización conceptual.
Agent Skills: enseñar una vez en vez de repetir prompts
El curso actual de Introduction to Agent Skills presenta los Skills como instrucciones reutilizables que Claude Code puede cargar cuando una tarea coincide con ellas.
La idea parece sencilla, pero representa una transición importante:
antes
cada conversación → volver a explicar el procedimiento
ahora
procedimiento → SKILL.md → reutilización automáticaUn Skill permite codificar conocimiento operativo: convenciones del repositorio, pasos de publicación, procesos de revisión, procedimientos internos o instrucciones para una tarea especializada.
El curso de Anthropic no se limita a crear un SKILL.md. También cubre cómo organizar Skills de varios archivos, restringir tools, distribuirlos entre equipos, diagnosticar por qué no se activan y decidir cuándo utilizar un Skill frente a subagentes, hooks, MCP o instrucciones persistentes.
Esto sugiere algo más amplio: el prompt aislado está dejando de ser la unidad principal de reutilización. El conocimiento útil empieza a empaquetarse como artefactos versionables y compartibles.
MCP: de “conectar cosas” a entender el protocolo
Uno de los puntos más interesantes del relato de Every aparece alrededor de MCP.
Quintero explica que su equipo ya usaba MCP con frecuencia, pero que recorrer la estructura del protocolo —endpoints, clientes, tools, resources y prompts— hizo que la lógica terminara de encajar.
Ese detalle importa porque MCP suele explicarse de manera demasiado superficial:
“Es una forma de conectar Claude con aplicaciones externas.”
Eso es cierto, pero insuficiente.
El curso actual de Introduction to Model Context Protocol enseña a construir servidores y clientes con el SDK de Python y separa tres primitivas fundamentales:
- Tools: acciones que el modelo puede solicitar.
- Resources: información que un servidor puede exponer al cliente.
- Prompts: plantillas o workflows reutilizables suministrados por el servidor.
Comprender esas diferencias cambia la manera de diseñar una integración. Ya no estás simplemente “dándole acceso” al modelo. Estás definiendo un contrato explícito entre un sistema de IA y capacidades externas.
La API termina siendo mucho más que hacer una llamada HTTP
El bloque más grande es Building with the Claude API. El catálogo público actual de Claude Academy lo presenta como un curso de decenas de lecciones que recorre buena parte del ciclo de construcción, incluyendo:
- llamadas a la API;
- conversaciones multi-turn;
- system prompts;
- structured data;
- evaluación de prompts;
- tool use;
- RAG;
- búsqueda agentic;
- extended thinking;
- imágenes y PDF;
- citations;
- prompt caching;
- MCP;
- agentes y workflows.
Aquí aparece otra lección útil del artículo de Every: uno de los ingenieros destacó especialmente la sección de evaluación de prompts porque condensaba el tema de una forma práctica.
Ese énfasis es saludable. Un sistema serio no debería preguntarse solamente:
¿el modelo respondió bien esta vez?sino:
¿cómo sé que responde bien de forma repetible?
¿con qué dataset lo pruebo?
¿qué métrica define éxito?
¿qué casos fallan?
¿qué cambia cuando actualizo modelo o prompt?La diferencia entre una demo y un sistema confiable suele aparecer precisamente ahí.
Claude Code: del asistente interactivo al agente operable
El cuarto componente, Claude Code in Action, apunta hacia sesiones más largas y menos supervisadas.
La formación actual cubre temas como configuración, automatización, verificación y uso dentro de GitHub Actions. La pregunta deja de ser únicamente “¿puede Claude escribir este código?” y pasa a ser:
¿puedo delegarle una tarea completa y tener suficiente control para confiar en el resultado?
Eso exige otras disciplinas:
- permisos limitados;
- instrucciones persistentes;
- herramientas explícitas;
- límites de ejecución;
- validación automática;
- revisión del resultado;
- observabilidad del proceso.
Cuanto más autónomo es el agente, menos suficiente resulta juzgarlo por una respuesta bonita en la terminal.
Lo que la certificación no enseña
Aquí está la crítica principal de Every.
Los cursos explican bien las piezas, pero no entregan un playbook completo para transformar un workflow real.
Por ejemplo, una formación de arquitectura agentic podría partir de un proceso existente y recorrer algo como esto:
workflow humano actual
↓
mapear decisiones y pasos repetitivos
↓
identificar qué debe seguir siendo humano
↓
identificar tareas delegables
↓
definir contexto y fuentes de verdad
↓
crear tools / MCP / skills
↓
diseñar el loop del agente
↓
construir evals y gates
↓
medir resultado en producciónEse recorrido no aparece de forma integrada.
Y probablemente esa sea la parte que más necesitan muchas empresas. Saber qué es un MCP no responde automáticamente a la pregunta más difícil: ¿debería este workflow usar MCP?
Saber crear un Skill tampoco te dice qué conocimiento merece convertirse en Skill y qué información debería permanecer en el contexto del proyecto.
La arquitectura aparece cuando tienes que tomar esas decisiones en conjunto.
El problema del curso único para todo el mundo
Every también señala una tensión importante: la experiencia de certificación es esencialmente la misma independientemente del rol.
Eso produce resultados muy diferentes.
Para una persona no técnica, algunas secciones de API pueden resultar excesivamente profundas. Para un ingeniero que ya trabaja diariamente con Claude, parte del contenido puede resultar demasiado introductorio.
Y, paradójicamente, los propios modelos de IA ya son excelentes adaptando una explicación al conocimiento previo del estudiante.
Una formación más madura podría comenzar con una evaluación y generar rutas distintas:
Ejecutivo
→ capacidades, límites, riesgo, ROI y diseño organizacional
Producto / Operaciones
→ workflows, skills, automatización, supervisión y evals
Ingeniería
→ API, MCP, tools, agentes, observabilidad y producción
Seguridad / Plataforma
→ permisos, aislamiento, identidad, auditoría y gobernanzaEso sería mucho más cercano a la forma en que la IA termina utilizándose dentro de una organización real.
El segundo problema: el material envejece muy rápido
El artículo identifica un problema inevitable de cualquier certificación de IA en 2026: el software alrededor del modelo cambia más rápido que el currículo.
Every encontró ejemplos de material que ya hacía referencia a componentes o modelos que habían cambiado, además de funcionalidades nuevas que todavía no estaban incorporadas en algunos cursos.
No es necesariamente una señal de mala calidad. Es una consecuencia de intentar convertir un ecosistema en movimiento en material educativo estable.
El ciclo es casi imposible:
producto cambia
↓
documentación se actualiza
↓
curso se reescribe
↓
video se vuelve a grabar
↓
evaluaciones se actualizan
↓
producto vuelve a cambiarPor eso el equipo de Every llegó a una conclusión especialmente relevante para perfiles técnicos: la documentación oficial de Anthropic suele ser una referencia mejor y más actual que el curso cuando necesitas comprender cómo funciona algo hoy.
Entonces, ¿vale la pena la certificación?
La respuesta que emerge del artículo es: sí, pero depende del objetivo.
Tiene valor si quieres:
- establecer un vocabulario común en un equipo;
- entender cómo Anthropic define sus propias herramientas;
- recorrer de forma estructurada Skills, MCP, API y Claude Code;
- detectar huecos en conocimientos que habías adquirido de manera fragmentada;
- tener un punto de referencia compartido para conversaciones técnicas.
Tiene menos valor si esperas:
- un sistema completo para rediseñar operaciones con agentes;
- una ruta personalizada para tu rol;
- técnicas necesariamente más recientes que la documentación;
- recetas avanzadas para workflows específicos de tu empresa.
Qué haría después de los cursos
La certificación puede ser el comienzo, no el final.
Una ruta práctica sería:
1. Aprender las primitivas
Comprender Skills, MCP, tools, API, Claude Code y evals con las definiciones oficiales.
2. Elegir un workflow real
No un ejercicio artificial. Un proceso que realmente ejecutes cada semana.
3. Convertir instrucciones repetidas en artefactos
Si una explicación se repite, evaluar si debe convertirse en Skill, instrucción de proyecto, tool o automatización.
4. Diseñar el contrato con el mundo exterior
Cuando el agente necesite datos o acciones externas, decidir explícitamente qué capacidades exponer y mediante qué interfaz.
5. Añadir evaluación antes de añadir autonomía
Un agente que puede actuar más veces sin supervisión necesita mejores mecanismos de verificación, no menos.
6. Volver a la documentación
Los cursos enseñan el mapa. La documentación te ayuda a navegar la versión del territorio que existe hoy.
La verdadera transición educativa de la IA
La historia de esta certificación revela una transición más grande.
La primera alfabetización de la IA fue:
aprender a preguntarLa siguiente está siendo:
aprender a diseñar sistemas alrededor del modeloEso incluye contexto, memoria, tools, Skills, MCP, agentes, permisos, evaluación, observabilidad y workflows humanos.
Anthropic todavía no ha convertido todo eso en una receta universal —y probablemente ninguna empresa pueda hacerlo todavía—, pero su certificación ayuda a fijar las piezas y a darles nombres compartidos.
En una industria donde casi todo sigue moviéndose, ponerse de acuerdo sobre qué significa cada pieza ya es una forma de progreso.