Estrategia de updates de Claude Code, sin que tu workflow se rompa de golpe

El 23 de abril de 2026 Anthropic publicó un postmortem. Una reducción de verbosidad en el system prompt de Claude Code había empeorado de forma medible la calidad del código para algunos usuarios. Desde entonces Anthropic introduce evals por modelo para cada cambio de prompt. En Reddit (r/Anthropic, 125 upvotes) y Hacker News (47878905) eso fue el tema estrella durante días. La lección importante: necesitas tu propia estrategia de actualización, porque "instalar la última actualización y rezar" ya no basta.

Este playbook trae 10 pasos de higiene de actualización para Claude Code, Cursor y Codex. Aprendes cómo fijar una versión, cómo construir tu propio eval-set, cómo notar después de una actualización si la calidad es estable, y cómo hacer rollback sin dramas.

Parto de Claude Code, pero el patrón se traslada 1:1 a otras herramientas.

Paso 1, averiguar la versión actual y dejarla anotada

Haz claude --version en el terminal. Recibes algo como 2.1.x. Escríbelo en un CLAUDE_VERSION.md en tu proyecto principal con la fecha al lado. Suena simple, pero vale oro cuando después de tres semanas "algo es distinto" y quieres saber desde cuándo.

Con Codex eso va vía codex --version, con Cursor la versión está bajo Help → About. Ahí también: anótala.

Paso 2, desactivar la auto-actualización

Por defecto Claude Code se actualiza al arrancar. Eso es cómodo pero traicionero. Si Anthropic publica una build que te causa problemas, no tenías opción. Desactívalo en ~/.claude/config.json con "autoUpdate": false.

En su lugar actualizas cuando tienes tiempo. El domingo por la mañana está bien. Entonces tienes todo el día para testear sin que una tarea en vivo esté esperando por ello.

Paso 3, leer las release notes (de verdad)

Anthropic publica las releases en github.com/anthropics/claude-code/releases. Antes de la actualización, dale un scroll una vez. Tres cosas que buscas: breaking changes (aunque no se llamen así), funciones nuevas que te afectan, bug fixes de bugs que tú mismo reportaste.

Las actualizaciones pueden ser masivas. Un solo patch bump puede traer más de 50 cambios, nuevos slash commands, migraciones de config, arreglos de casos límite. Lo que no te afecta directamente (por ejemplo un arreglo de Bun cuando no usas Bun en absoluto), lo lees por encima. Lo que toca tu workflow, lo lees con detalle.

Fuente externa como respaldo: claudelog.com/claude-code-changelog/ agrega las releases con mejor legibilidad que el formato de GitHub.

Paso 4, montar un eval-set

Este es el paso más importante. Necesitas una pequeña lista de 5 a 10 tareas típicas que haces con regularidad con Claude Code. En mi caso son: "escribe un script de migración de Prisma", "revisa este pull request en busca de bugs de seguridad", "constrúyeme un endpoint simple de Express con validación", "arregla este error de tipo de TypeScript".

Escribe cada tarea en su propio archivo evals/01-prisma-migration.md, con el prompt concreto y la solución esperada. Esa es tu vara de medir.

Quien no tiene un eval, nota una regresión de calidad solo cuando un trabajo real de un cliente sale mal. Eso es demasiado tarde.

Paso 5, ejecutar la baseline previa a la actualización

Antes de actualizar, recorre el eval-set una vez por completo. Guarda los outputs en evals/baselines/<tu-versión-actual>/ (por ejemplo evals/baselines/2.1.x/). Por cada eval la respuesta, el recuento de tokens, si la solución funcionó (tú como humano decides), y subjetivamente cómo de buena.

Esto tarda 30 minutos. No se hace a menudo, pero una vez que lo tienes, lo tienes.

Paso 6, instalar la actualización

Ahora sí la actualización. Con Claude Code claude update o npm install -g @anthropic-ai/claude-code@latest según la vía de instalación. Con Codex codex update. Con Cursor vía su propio sistema de actualización.

Justo después de la actualización otra vez claude --version y amplía CLAUDE_VERSION.md. Fecha, versión antigua, versión nueva.

Paso 7, ejecutar el eval posterior a la actualización

Exactamente el mismo eval-set que en el paso 5. Guarda los outputs en evals/baselines/<versión-nueva>/. Compara.

Te fijas en tres cosas. Primero, ¿sigue funcionando la solución (binario). Segundo, ¿la respuesta se ha vuelto más corta/larga, y eso es bueno o malo (ver el postmortem de abril, la reducción de verbosidad fue negativa). Tercero, ¿ha cambiado el estilo de una forma que no te gusta.

Si todo está mejor o igual: sigue adelante. Si algo está peor: paso 8.

Paso 8, ruta de rollback

Anthropic sigue publicando versiones antiguas en npm. Puedes volver a una versión antigua con npm install -g @anthropic-ai/claude-code@<versión-anterior> (por ejemplo @2.1.142 si actualizaste a 2.1.143). Anota siempre antes de la actualización qué versión tienes (ver paso 1), entonces el rollback es cosa de 30 segundos.

Si el problema de verdad está en la actualización, escribe un issue en github.com/anthropics/claude-code/issues. Con el input del eval, la respuesta antigua, la respuesta nueva. Anthropic reacciona a reportes bien documentados, justo después del postmortem.

Paso 9, arrastrar al resto del mundo

Si tu actualización fue limpia, hay todavía una capa. Hooks, skills, servidores MCP. Algunos se rompen con versiones más nuevas de Claude Code porque las APIs han cambiado. Después de cada actualización, comprueba si tus hooks más importantes siguen corriendo (por ejemplo con un claude hooks list), y si tus servidores MCP siguen conectando (claude mcp list).

Si un servidor MCP ya no conecta, mira en sus issues si es un conflicto conocido. A veces ayuda un simple npm update -g <mcp-server>. A veces esperar hasta que el maintainer reaccione.

Paso 10, encontrar tu frecuencia de actualización

Mi propio ritmo. Las patch releases (por ejemplo 2.1.x → 2.1.x+1) a menudo las salto una semana hasta que veo si alguien se queja en Reddit o en el Discord de Anthropic. Las minor releases (2.0 → 2.1) las actualizo el fin de semana con una ejecución completa de eval. Las major releases (1.x → 2.x) las planifico a conciencia, leo el doc de migración, y me tomo medio día.

La palanca no es "ser rápido", la palanca es "saber qué ha cambiado". Con un eval-set y pinning de versión una actualización te cuesta 45 minutos y te da seguridad. Sin disciplina una actualización fallida te cuesta un día entero de trabajo y la confianza en la herramienta.

Qué viene después

Si todavía no tienes hooks, la lección L4-04 "Hooks und Skills" más el playbook "Hooks gegen Halluzinationen". Si quieres profundizar en el desarrollo guiado por evals, la lección L2-06 "Capstone" más las lecciones L5 sobre reviews multi-agente. Para el loop general de actualización de servidores MCP mira el playbook "MCP-Server publishen" que también trata el versionado.

Fuentes: Anthropic Postmortem 23.04.2026 (anthropic.com/engineering/april-23-postmortem), discusión en r/Anthropic 125 upvotes, HN 47878905, releases de claude-code en GitHub, agregador de changelog claudelog.com.