Cuando la herramienta deja de ser tuya

Hace unos meses conté que el gobierno apagó dos modelos y yo seguí trabajando sin enterarme. El fallback silencioso de Claude Code se había encargado de todo antes de que yo lo notara.

Poco después, en junio, llegó el release 2.1.17x — el que confirmó hacia dónde iba la herramienta.

Ese release incorporó enforceAvailableModels: los administradores de una organización podían bloquear modelos vía managed settings. El usuario no los podía saltar por variable de entorno. No había override posible desde la terminal del empleado.

Combinado con el fallback automático que había llegado en ese mismo ciclo de releases — si el modelo configurado no estaba disponible, el sistema hacía fallback al mejor Opus habilitado — el cuadro se completaba solo.

Mi lectura en ese momento: en un entorno de equipo, qué modelo corre empieza a dejar de ser decisión del que escribe el prompt.

Para mí no cambió casi nada, para una empresa cambiaba bastante

Yo uso Claude Code como usuario único. Sigo eligiendo yo el modelo, sigo controlando mi propio flujo. Aquel release no me afectaba en el día a día.

Pero si estuviera pensando en darle acceso a cinco personas del equipo en Quantik, la ecuación cambiaba completamente.

De golpe había control real sobre qué modelos habilitar y cuáles no. Había certeza de que nadie se iba a saltar esa decisión con una variable que descubrió en un foro.

Y en las notas de release vi que /usage —por entonces solo en la extensión de VSCode— desglosaba el consumo por skill, agente, plugin y MCP, con cache misses y long context separados.

No era mi flujo (uso el CLI), pero para un equipo que trabajara desde VSCode, saber en qué parte del flujo se iba el dinero no era un dato menor.

Eso, para una empresa que está evaluando desplegar IA a su equipo, no es un feature menor.

Es la diferencia entre “ponemos IA a disposición del equipo” y “ponemos IA a disposición del equipo dentro de lo que decidimos que es admisible, medible y trazable”.

Lo que noté en las notas de release

Por esos días leía los changelogs de Claude Code con más atención de la que probablemente ameritaba para alguien que lo usa solo.

Lo que me llamó la atención en ese release no fue una feature que me afectara entonces. Fue que la mayoría de los cambios de fondo — enforceAvailableModels, el desglose por agente en /usage (por entonces disponible solo en la extensión de VSCode), los títulos de sesión en el idioma de la conversación — estaban pensados para un entorno con múltiples usuarios, con alguien administrando, con políticas de acceso y visibilidad de costos.

No para un hobbyista con una API key.

Hay algo en eso que me sigue pareciendo significativo. Claude Code, que empezó como herramienta de desarrolladores individuales, lleva releases enteros construyendo la infraestructura que necesitan las organizaciones para adoptarla con cierto control.

No fue una transformación anunciada. Fue una feature list que se completó en silencio.

Si tuviera que desplegarlo en Quantik mañana

El ejercicio de pensar en cinco personas del equipo con acceso a Claude Code me dejó, en su momento, con más preguntas que respuestas. Y meses después, siguen siendo las mismas preguntas — lo cual tampoco es un problema: es exactamente el estado en que debería estar alguien que todavía no lo hizo.

Algunas de las que me quedaron:

Qué modelos habilito y con qué criterio. ¿Lo decido por costo, por capacidad, por madurez del modelo? Probablemente alguna combinación de los tres — pero no tengo todavía claro cómo pondero cada variable cuando el que va a usar la herramienta no soy yo sino alguien de mi equipo con un caso de uso diferente al mío.

Cómo gestiono la visibilidad de costos. En la extensión de VSCode, por entonces, ya había desglose por skill, agente y MCP. Pero yo uso el CLI, y en un equipo de cinco necesitaría saber quién gasta qué y en qué parte del flujo — no solo el total. ¿Eso me llega automáticamente o tengo que armar algo encima?

Qué políticas defino antes de dar acceso. No es solo qué modelos habilito. Es qué se puede hacer, qué no, qué queda loggeado, qué se revisa. No tengo esa política escrita para mí mismo, mucho menos para un equipo.

Quién administra esto. En una empresa B2B mediana, ¿le cae a IT, a marketing, a alguien nuevo? Yo soy CMO, no administrador de sistemas. Que existiera enforceAvailableModels no resolvía la pregunta de quién lo configura y quién lo mantiene actualizado cuando cambia el catálogo de modelos.

No tenía respuestas entonces. Tampoco las tengo del todo ahora. Pero tenerlas claras me sigue pareciendo el requisito mínimo antes de presentar el tema internamente.

La lectura que me queda

Hace unos meses la lección fue sobre resiliencia: la herramienta ya asumía que un modelo puede desaparecer de un día para otro, y lo había resuelto antes de que yo lo notara.

Poco después, la lección fue sobre gobernanza: la herramienta ya estaba asumiendo que hay alguien más allá del usuario individual que necesita poder decidir, controlar y medir lo que corre en la organización.

Las dos lecturas juntas me hicieron pensar que Claude Code no se estaba construyendo para mí. Se estaba construyendo para el momento en que empresas como donde trabajo decidieran darlo como herramienta estándar a sus equipos.

Que yo la usara solo era, me parecía, un estado transitorio para ellos.

Meses después, sigo pensando lo mismo — si acaso, con más convicción. Cada release que leo parece sumar otra pieza en la misma dirección: gobernanza, administración, control por equipo. No para el que escribe el prompt solo.

¿Lo ven venir en las herramientas que usan? ¿Ya están pensando en Claude Code para equipos o todavía está en el cajón de “cosas que yo uso solo”?