Claude Code en septiembre: la herramienta te dejó medir tu propio setup.
- claude-code
- ia
- plugin-eval
- skill-doctor
- agentes-de-codigo
- workflow-dev
- anthropic
- productividad
Es jueves a la noche. Tenés Claude Code abierto, un CLAUDE.md que ya pasó las cien líneas, varias skills instaladas y un par de plugins que sumaste hace unas semanas.
Nada de eso está puesto al azar. Lo fuiste armando con criterio, probando qué te rendía y qué no. Y funciona.
Pero si te frenás dos segundos y te preguntás cuánto te aporta hoy cada una de esas piezas, no tenés un número. Tenés una intuición, que es otra cosa.
Durante mucho tiempo esa fue la única opción: ajustabas el entorno con olfato y confiabas en que sumaba, porque medirlo con precisión era incómodo o directamente imposible.
Lo que trajo Claude Code en septiembre cambia justo eso. Hubo un modelo nuevo, claro. Pero lo que mueve el día a día es otra cosa: por fin podés medir lo que antes ajustabas a ojo, y confirmar con datos lo que ya venías intuyendo.
Qué trajo septiembre
Para ver por qué esto importa, conviene mirar primero qué llegó, sin recitar todo el changelog. Si querés el detalle semana por semana, está en el What's new oficial de Claude Code.
En la semana del 31 de agosto al 4 de septiembre llegó Fable 5.1 a Claude Code. La ventana de contexto sigue siendo de un millón de tokens, la misma que ya venían trayendo los modelos desde hace meses. Y esa amplitud es parte del problema: entra de todo, así que es fácil acumular reglas, skills y archivos sin que nadie mida qué aporta cada uno.
En esa misma tanda apareció /skill-doctor, que te muestra cuánto contexto te cuesta cada skill y con qué frecuencia se usa realmente. Y /diff pasó a abrir un panel vivo al costado de la conversación, que se refresca mientras Claude edita.
La semana siguiente, del 7 al 11, llegó lo más jugoso: claude plugin eval. Corre tu plugin contra una batería de casos de prueba, les pone puntaje y compara el resultado contra una baseline sin el plugin. claude plugin eval init incluso te redacta los casos y los evaluadores para que arranques.
En esos mismos días sumaron maxEffortLevel, un setting que le pone techo al nivel de esfuerzo en todos los proveedores, y la opción de sacar cualquier panel del Desktop a su propia ventana.
Puestas una al lado de la otra, estas features no parecen tener mucho en común. Pero apuntan todas al mismo lado: dejar de trabajar a ciegas sobre tu propia configuración.
De la intuición a la evidencia
Acá está el cambio de fondo, y es más de hábito que de features.
Un dato para dimensionarlo: según la encuesta 2026 de JetBrains, con más de 15.000 respuestas, el 90% de los devs profesionales usa agentes de código al menos una vez por semana y el 68% todos los días. Cuando una herramienta la abrís a diario, tenerla mal configurada deja de ser una molestia ocasional y se convierte en un impuesto que pagás en cada sesión.
Antes ajustabas con criterio y seguías. Ahora podés ajustar, medir, y recién ahí decidir, con el número adelante.
/skill-doctor es el caso más claro. Lo abrís y descubrís que una skill que instalaste hace un mes se usó cero veces, y que igual te viene comiendo contexto en cada arranque. La sacás. Ganaste lugar para lo que sí aporta.
plugin eval va un paso más allá. Supongamos que tenés un plugin que, en teoría, hace que Claude respete las convenciones de tu repo. ¿De verdad las respeta mejor que sin él? Corrés el eval contra la baseline y mirás el puntaje. Si no mueve nada, era decoración.
Un ejemplo chico
Digamos que instalaste un plugin para que Claude escriba tus commits con el formato de conventional commits.
Antes, la única forma de saber si funcionaba era leer commits durante una semana y confiar en tu memoria. Ahora escribís cuatro o cinco casos con plugin eval init, definís qué cuenta como un buen commit, y corrés el eval con el plugin y sin él.
El número te dice si ayuda, si da lo mismo, o si te está ensuciando la salida. Diez minutos contra una semana de percepción.
Lo mismo pasa con el esfuerzo. Si tenías todo en el máximo "por las dudas", maxEffortLevel te obliga a la pregunta incómoda: ¿esta tarea necesita el modelo pensando a fondo, o la estoy pagando cara sin razón? Muchas veces un refactor chico sale igual de bien con la mitad de esfuerzo, y te enterás recién cuando le ponés un techo y comparás.
Dónde todavía no le creo
Poder medir no es lo mismo que entender, así que conviene bajar un cambio.
Un eval verde te mide contra los casos que vos escribiste. Si tus casos están sesgados hacia lo que ya esperabas, tu confianza también lo va a estar. El puntaje es tan bueno como las preguntas que le hiciste.
/skill-doctor te dice qué se usó y cuánto costó, no si se usó bien. Una skill muy usada puede estar metiéndose donde no la llamaste, y el número igual la muestra en verde.
Y más esfuerzo no siempre da mejor resultado. A veces da lo mismo, más lento y más caro. Por eso el techo es tan útil como el piso: te obliga a pensar cuánto necesitás de verdad para cada cosa.
Medir tu setup es una herramienta nueva. No es un piloto automático que te libere de mirar: te da números, y leerlos sigue siendo tu trabajo.
Lo interesante de poder medir tu setup no es que te corrija. Es que por primera vez podés ponerle un número a lo que hasta ahora manejabas de memoria.
La herramienta se volvió medible. Ahora falta que nos hagamos el hábito de mirar.
¿Cuánto de tu setup de IA revisaste alguna vez con un número adelante, y cuánto sigue funcionando solo por intuición?