¿Hasta dónde dejar trabajar a Claude Code? La regla de los 4 niveles de autonomía

Un viernes por la noche le pedí a Claude Code: “arregla solo los enlaces rotos de los artículos viejos de este blog”, y me fui a dormir. A la mañana siguiente miré el historial de commits y había reescrito 12 artículos. Los enlaces estaban arreglados, eso sí. Pero, de paso, también me había “pulido” la redacción de los títulos y sobrescrito expresiones antiguas que yo había dejado a propósito.

Tardé dos horas en revertirlo todo. ¿Por qué un Claude Code que se supone tan listo hace estas cosas de más? La respuesta es sencilla: nunca le había dicho “hasta dónde puedes llegar”.

También pasa lo contrario. Asustado, configuré que me preguntara “¿puedo ejecutar esto?” cada vez que cambiaba una sola línea. En 30 minutos me cansé de pulsar el botón de aprobar y acabé escribiéndolo yo mismo, que era más rápido. Delegar de más y tener un accidente, o frenar de más y agotarte. Mucha gente se pierde entre esos dos extremos.

Este artículo trata de acabar con ese desconcierto mediante “los 4 niveles de autonomía”. Solo leer, editar, publicar y lo que únicamente toca un humano: si trazas esas cuatro líneas desde el principio, las decisiones de cada momento casi desaparecen.

Puntos clave

• Si divides en 4 niveles según el riesgo lo que delegas a Claude Code, decidir se vuelve más fácil. Solo leer / edición reversible / publicar o desplegar / solo para humanos.
• Cada nivel necesita una “prueba de que terminó”. Que aparezca un diff, que la compilación pase, que la URL pública sea correcta, y similares.
• Borrados, datos de producción, cobros y force push no se automatizan ni con experiencia. Eso siempre lo pulsa un humano.
• Escribe los niveles en un solo archivo YAML y déjalo junto a CLAUDE.md; así el propio Claude Code declara “en qué nivel está ahora”.
• Empieza un nivel por debajo de lo que crees y sube solo las operaciones que ya comprobaste que son seguras. Nunca al revés.

Por qué la “línea” importa más que la “inteligencia”

La mayoría de quienes tropiezan con Claude Code no fallan por el rendimiento del modelo, sino por cómo cierran la tarea. A mí me pasó al principio. La instrucción en sí no era mala. Solo que el alcance “solo los enlaces” lo había transmitido únicamente con palabras. Una petición en prosa es como una indicación oral a un compañero ocupado por la mañana: se malinterpreta con facilidad.

Ahí es donde funciona trazar líneas según el riesgo. Defines lo que se puede hacer no como “el texto de un encargo”, sino como “niveles”. Así, cada vez que Claude Code va a hacer algo, puedes contrastar “¿de qué nivel es esta operación?”. Pasas de una batalla de interpretación del español ambiguo a una comprobación mecánica.

Esta idea no es nueva. En una fábrica, quien solo va de visita, quien monta piezas, quien pulsa el botón de envío y quien abre la caja fuerte tienen permisos separados desde el inicio. Con Claude Code solo trazamos las mismas líneas.

Qué contiene cada uno de los 4 niveles

Los 4 niveles que uso de verdad son estos. Primero te muestro el panorama en una tabla.

Nivel	Qué le encargas	Prueba de que terminó
0 Solo leer	Entender la estructura de archivos, detectar riesgos, proponer comandos de verificación	La nota final incluye una “lista de archivos leídos”
1 Edición reversible	Corregir un artículo, actualizar una prueba	Aparece un diff y la compilación pasa
2 Publicar o desplegar	Desplegar tras compilar, verificar la URL pública	Hay h1, URL canónica, CTA y procedimiento de rollback
3 Solo humanos	(No se le encarga a Claude Code)	—

En el nivel 3 entran las claves secretas, los cobros, los datos de producción y force push. Esto no se automatiza por mucha experiencia que tengas. La pérdida cuando te equivocas no compensa el esfuerzo que ahorrarías.

Lo importante en cada nivel es fijar siempre una “prueba de que terminó”. Sin prueba, aunque Claude Code diga “ya está”, no sabes si de verdad acabó. Que aparezca un diff, que la compilación pase, abrir la URL pública y comprobar que el h1 es correcto: eliges como prueba cosas que una máquina pueda verificar.

El alcance que delegas a la IA y el que decides tú

Cuando dejas claras las líneas, el reparto de roles también se decide solo.

A Claude Code puedes delegarle el trabajo repetitivo cuyo resultado se puede verificar con una máquina. Leer muchos archivos y resumirlos, corregir artículos en un formato fijo, ejecutar pruebas y leer los logs. En esto es más rápido y preciso que un humano.

Tú debes decidir las decisiones irreversibles y las operaciones de gran pérdida. Si de verdad se puede publicar este artículo, si se puede borrar esta expresión antigua, si se pueden sobrescribir estos datos de cliente. Aquí dejas que Claude Code “proponga”, pero el “ejecutar” lo pulsa un humano.

Cuando dudes, el criterio es uno solo: “¿se puede revertir en 10 minutos si sale mal?”. Si se puede revertir, es nivel 1; si no, es nivel 2 o 3. Mi accidente del principio, que tardó dos horas en revertirse, era en realidad una tarea que pedía la cautela del nivel 2.

Definición de niveles lista para copiar

Si dejas los niveles solo en tu cabeza, al final se desvían. Vuélcalos en un único archivo YAML y colócalo en la raíz del proyecto como autonomy.yml. Si haces que se referencie desde CLAUDE.md, el propio Claude Code empezará a declarar “como ahora estoy en el nivel 1, no publicaré”.

# autonomy.yml — la línea de autonomía que le pasas a Claude Code
safe_autonomy_ladder:
  level_0_read_only:
    allowed: ["Entender la estructura de archivos", "Detectar riesgos", "Proponer comandos de verificación"]
    proof: "La nota final incluye la lista de archivos leídos"
  level_1_reversible_edit:
    allowed: ["Corregir un artículo", "Actualizar una prueba"]
    proof: "Aparece git diff y la compilación pasa"
  level_2_publish_or_deploy:
    allowed: ["Desplegar tras compilar", "Verificar la URL pública"]
    proof: "Hay h1, URL canónica, CTA y procedimiento de rollback"
  level_3_owner_only:
    allowed: []
    examples: ["claves secretas", "cobros", "force push", "datos de cliente"]

En CLAUDE.md basta con añadir una sola frase como esta.

Antes de trabajar, lee autonomy.yml y declara primero de qué nivel es la tarea de hoy.
Las operaciones de nivel 2 o superior no se ejecutan: espera la aprobación de un humano.

Script de verificación que comprueba el nivel con una máquina

Solo hacer que lo declare me deja intranquilo, así que vigilo con una máquina “que no se haga una operación de nivel 2 (publicar) sin prueba”. El script de abajo va a buscar la URL pública tras el despliegue y comprueba que el h1 no esté vacío y que la URL canónica apunte a tu propio slug. Funciona tal cual con Node.js 18 o superior.

// verify-publish.mjs — comprueba con una máquina la "prueba de que terminó" del nivel 2
// Uso: node verify-publish.mjs https://claudecode-lab.com/blog/your-slug

const url = process.argv[2];
if (!url) {
  console.error("Pasa la URL pública como argumento");
  process.exit(1);
}

const res = await fetch(url);
if (res.status !== 200) {
  console.error(`HTTP ${res.status}: aún no se ha publicado`);
  process.exit(1);
}

const html = await res.text();

// ¿Existe un h1 con contenido?
const h1 = html.match(/<h1[^>]*>(.*?)<\/h1>/s);
const hasH1 = Boolean(h1 && h1[1].replace(/<[^>]+>/g, "").trim());

// ¿La URL canónica apunta a esta misma página?
const canonical = html.match(/<link[^>]+rel=["']canonical["'][^>]*>/i);
const canonicalOk = Boolean(canonical && canonical[0].includes(new URL(url).pathname));

console.log(`Hay h1:           ${hasH1 ? "OK" : "NG"}`);
console.log(`Canónica coincide: ${canonicalOk ? "OK" : "NG"}`);

if (hasH1 && canonicalOk) {
  console.log("Pruebas del nivel 2 completas. Se puede dar por publicado.");
} else {
  console.error("Faltan pruebas. No lo des por terminado todavía.");
  process.exit(1);
}

Si te crees que solo un HTTP 200 es éxito, no te darás cuenta cuando salga el fallback de la portada o un artículo viejo. Solo cuando miras hasta el h1 y la URL canónica puedes decir “este nivel terminó”.

Tres situaciones donde esto funciona

1. Justo después de entrar en un repositorio nuevo Si le haces editar de golpe sin conocer ni la estructura ni los comandos, tiende a romper los archivos de configuración. Al principio permite solo el nivel 0 y haz que reporte la estructura de archivos, los comandos disponibles y los lugares peligrosos al tocar. Cuando ya tengas el mapa, sube al nivel 1.

2. Corregir erratas en un artículo Con el nivel 1 basta. Si aparece un diff y la compilación pasa, la prueba está completa. Mi accidente del principio se habría evitado si aquí hubiera escrito el alcance: “solo corregir erratas; no cambiar la redacción”. La plantilla de encargo para pasarle a Claude Code es así.

Trabaja en el nivel 1.
Objetivo: solo las erratas evidentes de content/blog/foo.mdx
Lo que NO debes hacer: reformular títulos, cambiar la redacción, editar otros archivos
Al terminar, muéstrame git diff y comprueba tú mismo que el cambio son solo correcciones de erratas.

3. Justo antes de publicar en producción En el nivel 2 haz que verifique siempre si la compilación pasa, si están todas las variables de entorno, si el diff es el esperado y si hay procedimiento de rollback. Si al final ejecutas el script de verificación de arriba, puedes comprobar incluso el contenido de la URL pública.

Tres errores que cometí yo

Siendo honesto, hasta asentarme en estos 4 niveles tuve accidentes muchas veces.

El primero fue saltarme niveles de golpe. Me salté el nivel 0 y le hice editar mucho directamente en el nivel 1; salió un diff tan grande que no se podía verificar y ni yo mismo sabía qué estaba bien. Ahora siempre subo de 0 en orden.

El segundo fue dar por “terminado” solo con la compilación local. Como pasaba en local, publiqué. Pero en producción se mostraba una página vieja y no me di cuenta durante medio día. Desde entonces no doy nada por terminado hasta ver el h1 y la URL canónica de la URL pública.

El tercero fue confiar la aprobación solo a mis propios ojos. “Ya lo reviso yo al final” se rompe sin falta una noche que estás cansado. Desde que metí como “prueba” del nivel comprobaciones que una máquina entiende —recuento de caracteres, enlaces rotos, errores de tipos— los descuidos nocturnos cayeron en picado.

Cómo empezar

No apuntes desde el principio a un agente totalmente automático y brillante. Elige una tarea pequeña que se pueda revertir si sale mal. Revisar erratas de un borrador, una primera revisión de cambios, la comprobación antes de publicar en staging. Algo así está bien.

El orden es siempre el mismo: 1) define un alcance de lectura estrecho, 2) deja claro el entregable, 3) deja la verificación a comandos en lo posible, 4) las operaciones peligrosas (borrado, datos de producción, cobros, force push) ponlas todas al principio en “preguntar al humano”. Solo las operaciones que ya comprobaste que son seguras se ascienden después, un nivel cada vez. Nunca al revés.

Si tropiezas con la configuración fina de permisos, mira antes Cómo empezar con Claude Code; para escribir las reglas de niveles en CLAUDE.md, Cómo escribir CLAUDE.md. Así estos 4 niveles caen directamente en la configuración. Si la idea es que alguien sin perfil técnico entre al equipo, échale también un ojo a Uso para no ingenieros.

Preguntas frecuentes

P. ¿Hay que configurar la división de niveles a mano cada vez? No. Si creas un único autonomy.yml y lo referencias desde CLAUDE.md, a partir de ahí Claude Code declara por su cuenta “ahora estoy en el nivel 1”. La configuración es solo la primera vez.

P. ¿Es seguro automatizar hasta “publicar” en el nivel 2? Si las pruebas se reúnen por máquina, puedes automatizarlo una vez que tengas experiencia. Pero intercala siempre un mecanismo que verifique el contenido de la URL pública, como el script de verificación de arriba. Creerte solo el HTTP 200 es lo más peligroso.

P. ¿Cómo distingo qué operaciones meter en el nivel 3? Piensa rápido con esto: “¿basta con pedir perdón si falla, o hace falta indemnizar?”. Sobrescribir datos de cliente, cobrar y borrar en producción son lo segundo, así que van al nivel 3. No se automatizan ni con experiencia.

P. ¿Hacen falta las líneas también en un equipo pequeño? Al contrario, cuanta menos gente, más funcionan. Como es fácil que se difumine quién aprobó qué, compartir la tabla de niveles deja claro de un vistazo “quién da el OK a esta operación”.

P. ¿No bastaría con afinar el prompt para no necesitar la división de niveles? Los prompts se interpretan de forma variable. La habilidad de escribir buenas peticiones se desarrolla aparte en Práctica de prompts; la división de niveles es “una red de seguridad que no depende de lo bien redactado que esté el texto”. Tener ambas es lo más fuerte.

Lo que comprobé al probarlo de verdad

Desde que metí estos 4 niveles en la operación de mi blog, los accidentes del tipo “hace cosas que no le pedí” del principio quedaron en cero. Comprobé dos cosas.

Una: al referenciar autonomy.yml desde CLAUDE.md, Claude Code empezó a declarar por su cuenta, antes de trabajar, “esta vez es nivel 1, así que no publicaré”. Sentí en la práctica que, cuando pasas las líneas como niveles y no como prosa, la interpretación no se desvía.

La otra: al ejecutar siempre verify-publish.mjs tras publicar, ahora detecto justo después de publicar ese fenómeno de “sale una página vieja en producción” del que antes no me daba cuenta durante medio día. Con solo mirar el h1 y la URL canónica, se tapa la trampa del HTTP 200.

Más que buscar un modelo más listo, decidir antes los niveles para no hacerte daño aunque te caigas. Parece un rodeo, pero esa es mi sensación de que es lo más rápido. Si estás en el punto de ordenar las reglas de permisos de Claude Code en equipo, en formación y consultoría podemos diseñar juntos esas líneas. Para la configuración oficial de permisos, revisa también la documentación de Anthropic.