¿Hasta dónde dejar trabajar a Claude Code hoy? La hoja de los 4 niveles de aprobación

Un viernes por la tarde, mi única intención era meter un cambio minúsculo en el entorno de staging.

Le pedí algo tan simple como «corrige la errata de la documentación y, de paso, comprueba que la build pasa». Claude Code corrigió la errata y, por su cuenta, actualizó dos paquetes de dependencias y hasta reescribió la referencia a .env.production. Como la build local pasaba, él (la IA) anunció «Listo, completado» con toda la tranquilidad del mundo.

Lo que me dejó helado es que no me di cuenta hasta que revisé el diff entero, línea por línea. No es que la IA hiciera nada malo: el problema era que yo nunca había puesto en palabras hasta dónde podía llegar.

Por el contrario, otro día me salió el «¿Permitir? Sí/No» unas treinta veces seguidas, y crear un solo commit me dejó sin fuerzas. Si abres demasiado, hay accidentes; si cierras demasiado, no avanzas. Este artículo va sobre una única hoja de trabajo para trazar la línea justa entre ambos extremos.

Puntos clave

• Divide el trabajo que delegas en Claude Code en 4 niveles: «solo leer», «solo arreglar», «publicar» y «tocar información sensible».
• Decide de antemano, por cada nivel, «quién da el visto bueno final» y «qué hay que ver para poder afirmar que es seguro» (la evidencia).
• Los niveles 0 y 1 los dejas en manos de la IA; el nivel 2 lo confirma una persona; el nivel 3 solo lo toca el responsable.
• Si por la mañana declaras en una frase «hoy hasta aquí», el número de aprobaciones cae de golpe.
• Te dejo un código de registro listo para copiar y una plantilla para decidir en un minuto cada mañana.

Por qué conviene fijar antes el «presupuesto de aprobaciones»

Lo que te agota en las aprobaciones no es el rendimiento de Claude Code. Es arrancar sin haber decidido hasta dónde permites hoy.

Si no lo decides, la persona acaba cayendo en uno de dos extremos. Por pereza, pulsa «permitir» en todo y un día deja pasar incluso una operación peligrosa. O se vuelve tan precavida que mete una confirmación hasta para una errata, y el trabajo se atasca. Lo común en ambos casos es dejar la decisión al humor del momento.

Aquí entra la idea del «presupuesto de aprobaciones». Igual que un presupuesto de dinero, fijas el marco de antemano: hoy tienes libertad hasta este carril; más allá, decide una persona. Con el marco puesto, dejas de ponerte nervioso cada vez que ves la respuesta de la IA. Lo que miras ya no es «si la IA es lista», sino «en qué carril se ha detenido».

Poner el criterio en palabras también evita roces en el equipo. En vez de «lo paré porque me daba mala espina», puedes decir «esto es nivel 2, así que ahora le toca confirmar a una persona». La filosofía del diseño de permisos la toco también en la guía de iniciación a Claude Code, pero aquí me centro en algo mucho más terrenal: la línea de hoy.

Divide el trabajo en 4 niveles

Primero, ordena el trabajo que quieres encargar a Claude Code en cuatro niveles según su peligrosidad. Sin complicarte: solo según «¿se puede deshacer?», «¿se va a publicar?» y «¿toca dinero o secretos?».

Nivel	Ejemplo de trabajo	Quién da el visto bueno final	Evidencia de que es seguro
0	Leer archivos, entender la estructura	La IA	Lista de lo que ha leído
1	Arreglar 1 archivo reversible	La IA (una persona revisa el diff)	Diff y resultado de la build
2	Reflejar cambios en el sitio público	Decide una persona	URL pública y plan de reversión
3	Tocar secretos, cobros o datos de clientes	Solo el responsable	Aprobación por escrito

La clave de esta tabla son las dos columnas de la derecha. Decide «quién da el visto bueno» y «qué hay que ver para afirmar que es seguro» antes de empezar. Si lo decides después, te dejas arrastrar por el impulso del «Listo, completado» de la IA y te saltas la verificación.

El punto del nivel 1 es lo «reversible». Corregir una errata o añadir un comentario se puede revertir al instante aunque te equivoques. Por eso lo delegas en la IA y a la persona le basta con echar un vistazo rápido al diff. En cambio, actualizar dependencias sube al nivel 2. Aunque parezca pequeño, su alcance es impredecible. Mi accidente del principio fue exactamente eso: haber tratado esa actualización como nivel 1.

Qué delegar en la IA y qué decidir tú mismo

Afinemos un poco más la línea. Puedes delegar en la IA el trabajo del que te das cuenta enseguida si te equivocas y que se puede deshacer al instante. Debes decidir tú el trabajo que, una vez ejecutado, tiene efectos hacia fuera.

• Delegar en la IA: leer, investigar, hacer borradores, arreglar 1 archivo reversible, lanzar tests.
• Decide tú al final: publicar, cambiar datos de producción, dar de alta en servicios externos, actualizar dependencias, borrar.

Si dudas, sube un nivel. Con solo recordar esto no te equivocarás mucho. Solo las operaciones que ya has confirmado seguras las vas bajando de una en una para automatizarlas. El truco es no aspirar a la automatización total desde el primer día. Esta filosofía de «ascender por etapas» encaja muy bien con cómo escribir las reglas del proyecto en CLAUDE.md, así que deja la línea acordada en ese archivo y será reproducible.

Registro de aprobaciones listo para copiar

Solo con palabras, se te acaba olvidando. Por eso vamos a poner los 4 niveles en un formato que la máquina pueda leer, para sacar con un filtro «hasta dónde llego hoy». Si tienes Node.js, funciona tal cual.

// Registro de aprobaciones: cada tarea lleva su "nivel de peligro", "responsable" y "evidencia"
const approvalBudget = [
  { action: "Leer archivos",                 level: 0, owner: "IA",                  proof: "Lista de lo leido" },
  { action: "Arreglar 1 archivo reversible", level: 1, owner: "IA (revisa persona)", proof: "Diff y build" },
  { action: "Publicar en el sitio",          level: 2, owner: "Persona",             proof: "URL publica y reversion" },
  { action: "Tocar secretos o cobros",       level: 3, owner: "Solo responsable",    proof: "Aprobacion por escrito" },
];

// Limite de hoy. 0 = solo leer; 1 = delegar hasta arreglos reversibles
const todayMax = Number(process.env.APPROVAL_MAX ?? 1);

const allowedToday = approvalBudget.filter((item) => item.level <= todayMax);
const needsHuman   = approvalBudget.filter((item) => item.level > todayMax);

console.log(`Limite que delego hoy en la IA: nivel ${todayMax}`);
console.table(allowedToday);
console.log("Trabajo que decide una persona:");
console.table(needsHuman);

Ejecutarlo es así de sencillo. Con una variable de entorno cambias el «límite de hoy».

# Hoy delego hasta los "arreglos reversibles"
APPROVAL_MAX=1 node approval-budget.mjs

# Hoy lo dejo en solo leer
APPROVAL_MAX=0 node approval-budget.mjs

Deja los nombres de los campos tal cual y reescribe el contenido de action y proof para ajustarlo a tu proyecto. Si le pasas este código a Claude Code y le pides «rellena los valores para mi repositorio», tendrás un borrador en un momento.

Plantilla de prompt para decidir en un minuto cada mañana

Una vez tengas el registro, antes de empezar le comunicas a la IA «el marco de hoy». Copia el texto siguiente y rellena los huecos.

Voy a fijar primero el marco del trabajo de hoy.

- Objetivo de hoy: (ej.: corregir erratas y enlaces rotos de 1 articulo del blog)
- Que puedes leer: solo site/src/content/blog/
- Que puedes arreglar: solo 1 archivo de lo anterior (unicamente cambios reversibles)
- Comandos que puedes ejecutar: npm run lint, ejecutar los tests
- Lo que NO debes tocar: .env, despliegue a produccion, actualizar dependencias, borrar

Reglas:
- En nivel 2 o superior (publicar, datos de produccion, actualizar dependencias, borrar), detente siempre y confirmamelo antes.
- Cuando arregles algo, muestrame al final el diff y el resultado de la build como "evidencia".
- No te quedes en "Listo, completado": escribe con que comando lo has verificado.

Con solo esta frase, la IA deja de «hacerlo todo por si acaso» y se mueve dentro del marco. Cuando te acostumbres, pasa este contenido a tu archivo de reglas del proyecto siguiendo la guía de CLAUDE.md, y te ahorrarás incluso el pegado de cada mañana.

Tres escenarios donde funciona

1. Revisión en serie de blogs y materiales Con un simple «arregla el artículo», la IA te reescribe de golpe el cuerpo, las rutas de imagen y los enlaces. Si en el registro separas «las erratas del texto son nivel 1, reflejarlo en público es nivel 2», puedes delegar el texto y dejarte el botón de publicar en tus manos. Si le exiges el diff y la build como evidencia, la revisión nocturna se vuelve mucho más llevadera.

2. Clasificación de consultas entrantes Leer y clasificar las consultas que llegan es nivel 0, puedes dejárselo a la IA. Pero darlas de alta en la base de clientes es nivel 3. Aunque la IA juzgue que «esto parece una oportunidad de venta», mantén en pausa la escritura en la base de datos de producción hasta que el responsable pulse el botón. Forzar esto desde el registro elimina el accidente de registrar por su cuenta a un cliente mal clasificado.

3. El respiro antes de desplegar Pon siempre la publicación en nivel 2. No marques «completado» solo porque la build local pase: detente hasta verificar la URL pública, el titular y el plan de reversión. La «actualización de dependencias por su cuenta» que me jugó la mala pasada del principio se habría detenido siempre en la confirmación humana de haber tenido explícito el nivel 2.

Tropiezos habituales y cómo corregirlos

El más común es intentar resolverlo todo en una sola petición y acabar con un diff gigante que nadie puede verificar. La solución es simple: limita cada petición a «un entregable por vez». Un artículo, un PR, un ajuste de configuración. Si lo troceas pequeño, llegas a leer el diff hasta el final.

El siguiente más frecuente es dar por terminado solo con que la build local pase. En el sitio público se ve otra página o la portada, y tú te quedas tranquilo viendo solo un HTTP 200. Si metes «verificar la URL pública y el titular» en la columna de evidencia, te detienes aquí.

El tercero es no dejar registro de lo que probaste. Al día siguiente tienes que rehacer la misma decisión desde cero. Con dejar una línea de la nota que veremos luego, el tú del día siguiente no se pierde. Si quieres mejorar de raíz cómo le pides las cosas a Claude Code, lee también diseño de prompts en la práctica y aprenderás a transmitir el marco mucho mejor.

Preguntas frecuentes

P. ¿Conviene dividir los niveles de aprobación con más detalle? Al principio, con 4 niveles basta. Cuantos más añadas, más complejo se vuelve el manejo y, al final, deja de respetarse. Solo cuando lo rodes y notes que «aquí está demasiado grueso», ramifica ese punto concreto después.

P. ¿Cómo distingo si algo del nivel 1 es «reversible»? Lo juzgo por dos puntos: «¿se vuelve atrás con un solo comando de git?» y «¿no tiene efectos hacia fuera?». Editar un archivo se revierte; desplegar, cobrar, enviar correo o borrar, no. Si dudas, súbelo a nivel 2.

P. Al usarlo en equipo, ¿quién decide los niveles? Quien arranca el trabajo lo declara por la mañana, y se fija de antemano quién decide en nivel 2 o superior. Si el responsable no está, conviene acordar que ese día no se hace trabajo de nivel 3: es lo más seguro.

P. Pegar el prompt cada vez es un fastidio. Cuando el marco se asiente, pásalo al archivo de reglas del proyecto (CLAUDE.md). La IA lo lee siempre, así que ya no hace falta pegarlo.

P. ¿Sirve esta hoja también para quien no es programador? Sí. Aunque no ejecutes código, puedes trazar la línea solo con la tabla de 4 niveles y la plantilla de prompt. Para usos fuera del perfil técnico, también te ayuda Claude Code para quienes no son ingenieros.

Nota para el traspaso

Si dejas la decisión del día en una línea, ni tú ni el equipo repetiréis las mismas dudas al día siguiente. Copia este formato y rellénalo.

- Fecha: 2026-06-07
- Objetivo de hoy: corregir erratas y enlaces rotos de 1 articulo del blog
- Limite de hoy: nivel 1 (hasta arreglos reversibles)
- Evidencia: diff, log de npm run build, titular verificado en la URL publica
- Donde se detuvo la persona: actualizar dependencias (en pausa por ser nivel 2)
- Aviso para la proxima vez: agrupar las actualizaciones de dependencias otro dia en nivel 2

Con esta nota, la verificación tras publicar también es más fácil. Como un HTTP 200 no basta, en la URL pública compruebo hasta que el titular, la URL canónica, la imagen destacada y el inicio del cuerpo sean realmente los de este artículo. Si se ve otro artículo o la portada, lo doy por no publicado y rehago la build y el despliegue. La filosofía oficial del diseño de permisos también puedes consultarla en la documentación oficial de Anthropic.

Lo que comprobé al probarlo de verdad

Apliqué esta hoja de trabajo a la gestión de mi propio blog durante dos semanas.

Lo que más efecto tuvo fue acostumbrarme a pegar por la mañana la frase «hoy hasta el nivel 1». Solo con eso, el «¿Permitir?» por cada commit se redujo, a mi parecer, a menos de la mitad. Cuando la IA intentaba meterse en el nivel 2 o superior, se detenía como mandaban las reglas de la plantilla y me preguntaba. Accidentes del tipo «me doy cuenta y las dependencias ya estaban actualizadas», como el del principio, fueron cero desde entonces.

Lo que también descubrí es que la tabla de niveles, si solo la creas, no la usas. Ejecutar de verdad el código del registro y sacar en pantalla «el trabajo que delego hoy» antes de empezar subía la probabilidad de respetarla. En lugar de buscar una IA más lista, traza primero un marco del que puedas volver aunque tropieces. Es poco vistoso, pero esta es, hoy por hoy, la forma de delegar con menos estrés.

Si quieres extender esta línea a todo el equipo o a la operación en producción, en formación y consultoría podemos afinar juntos el diseño concreto de carriles. Para empezar, prueba mañana por la mañana a pegar la frase «hoy hasta el nivel 1».