Rutina diaria de 15 minutos con Claude Code: el método seguro para principiantes

Un viernes por la noche le lancé a Claude Code: “este proyecto, arréglame todo lo que veas raro”, y me fui a dormir.

A la mañana siguiente había 23 archivos modificados. Algunos hasta funcionaban. Pero no era capaz de explicar, ni a mí mismo, qué se había arreglado de verdad ni qué tenía que comprobar. Leer el diff de arriba abajo me llevó una hora y, al final, del miedo no me atreví a hacer ni un solo commit.

Le había pedido algo grande a una IA muy capaz y, en vez de avanzar, había retrocedido. Este es el primer pozo en el que cae casi todo principiante.

La culpa no es del rendimiento de Claude Code. Lo único que me faltaba era haber decidido cómo “cerrar” el trabajo. Hoy te paso, tal cual, la rutina de 15 minutos que hago cada mañana mientras se hace el café.

Puntos clave

“Arréglalo todo” es la receta del accidente. Lo que haces a diario es una sola tarea pequeña, definida en una frase.
Antes de empezar a editar, decide primero el comando de verificación que te dirá si terminaste.
Al acabar basta con dejar tres cosas: qué archivos cambiaron, el resultado del comando de verificación y el siguiente paso.
A la IA le delegas mover las manos. Definir el alcance y pulsar el botón de publicar lo hace una persona.
Copia el script de más abajo y tendrás todas tus comprobaciones de la mañana en fila, automáticas.

Por qué “cerrar en pequeño” le funciona al principiante

Cuando empecé con Claude Code, mi objetivo era siempre difuso: “déjalo decente”, “hazlo más legible”. Así, ni siquiera al terminar sabía qué había hecho la IA ni hasta dónde.

Con una persona recién llegada pasa lo mismo. A quien le dicen “este documento, hazlo como veas” se suele quedar bloqueado. A quien le dicen “cambia los números de la página 3 por los de la última versión y mira que la tabla no se descuadre” arranca enseguida y, además, puede juzgar por sí mismo si ha terminado.

Lo importante en la rutina diaria no es escribir de un tirón una instrucción genial. Es partir en trozos pequeños y darle una forma en la que se pueda juzgar el final. Cuando consigues esto, hasta un principiante puede decir cada día “hoy avancé hasta aquí”.

Por cierto, la base de esta forma de pensar enlaza con otros dos artículos: Cómo empezar con Claude Code y Lo básico sobre gestión de permisos. Primero deja el entorno listo con esos, y luego monta encima este hábito: ahí es donde mejor funciona.

Lo que haces en 15 minutos son solo 4 pasos

Lo que hago cada mañana son únicamente estos cuatro pasos. Y siempre en el mismo orden. Fijar el orden hace que el cuerpo se mueva sin tener que pensar.

Escribe la tarea mínima de hoy en una frase. Por ejemplo, “reescribir solo 3 líneas de la introducción del README”: un tamaño en el que el final se ve. Lo grande, hoy a propósito no lo tocas.
Decide antes el comando de verificación. “Si pasa npm run build, vale”, “si un test se pone en verde, vale”: define la forma de la meta antes de empezar a editar.
Trabaja y comprueba en este orden: diff, build y URL pública. No publiques de golpe; ve de lo que la máquina puede confirmar hacia lo demás.
Deja una sola línea para la próxima vez. Anota “el riesgo que queda” y “la siguiente tarea mínima”. Eso será tu punto de partida de mañana.

La clave es el punto 2. Si empiezas a editar sin decidir antes el comando de verificación, vuelves a aquel viernes por la noche del “creo que está arreglado, pero no tengo prueba”. Pinta la línea de meta antes de salir a correr. Solo con eso, el trabajo de cada día se vuelve muchísimo más ligero.

Qué le dejas a la IA y qué decide la persona

Creo que aquí es donde más se lía el principiante. Ni puedes soltárselo todo a la IA, ni tiene sentido usarla si lo haces todo tú. He puesto en una tabla una guía para trazar la línea.

Momento	Se lo dejas a la IA	Lo decide o lo pulsa la persona
Definir el alcance	Que proponga candidatos	Fijar la frase que harás hoy
Editar	Escribir código o texto	El criterio de qué arreglar
Verificar	Ejecutar build o tests	Qué comprobación será la meta
Publicar	Sacar un resumen del diff	Pulsar el botón de publicar
Operación peligrosa	Preguntar “¿puedo hacerlo?”	La decisión final de borrar o tocar producción

El criterio cuando dudas es simple: lo que se puede rehacer, para la IA; lo que no tiene marcha atrás, para la persona. Editar archivos se puede deshacer todas las veces que quieras, así que se lo delegas. Publicar en producción o borrar archivos, al principio, siempre lo pulsas con tu propia mano. Solo las operaciones con las que ya te has soltado las vas ascendiendo, poco a poco, a automáticas. La configuración fina de permisos está bien recogida en la documentación oficial de Claude Code; si dudas dónde trazar la línea, échale un vistazo y te quedas más tranquilo.

Plantilla de petición para copiar y pegar

Si escribes la petición desde cero cada vez, el tamaño de la tarea se descontrola. Yo tengo esta plantilla pegada en la app de notas y cada mañana solo relleno los huecos.

Tarea mínima de hoy: (una frase. Ej.: reescribir las 3 líneas de la introducción del README)
Alcance permitido: (ej.: solo README.md. Prohibido modificar otros archivos)
Cómo verificar que está terminado: (ej.: que npm run build termine con éxito)

Cómo proceder:
1. Primero, sin cambiar nada, lee el estado actual y resúmelo.
2. Edita solo el alcance de arriba. No toques nada fuera de él.
3. Tras editar, informa de los nombres de archivo cambiados y del resultado de la verificación.
4. Si hace falta borrar, tocar producción o enviar datos fuera, no lo ejecutes: pregúntame antes.

Con solo meter las dos líneas de “no toques fuera del alcance” y “pregunta antes de las operaciones peligrosas”, el accidente de los 23 archivos del principio deja de ocurrir casi por completo. La idea no es darle libertad a la IA, sino entregarle una caja segura.

Script de verificación que funciona al copiar

Las comprobaciones de la mañana, si las tecleas a mano, se te olvidan. Yo dejo este script como morning-check.mjs y lo ejecuto antes de prepararme el café. Si tienes Node.js instalado, funciona.

// morning-check.mjs : ejecuta en orden las comprobaciones de la mañana
import { execSync } from "node:child_process";

// Pon los comandos a comprobar en orden, de arriba abajo. Adáptalos a tu proyecto.
const checks = [
  { label: "Archivos modificados", cmd: "git status --short" },
  { label: "Que el build pase", cmd: "npm run build" },
];

let allOk = true;

for (const { label, cmd } of checks) {
  console.log(`\n=== ${label} : ${cmd} ===`);
  try {
    // Muestra el resultado tal cual en pantalla. Si falla, salta al catch de abajo.
    const out = execSync(cmd, { encoding: "utf8" });
    console.log(out.trim() || "(sin salida)");
  } catch (e) {
    allOk = false;
    console.log("Fallo:", e.message.split("\n")[0]);
  }
}

console.log("\n--- Cierre de hoy ---");
console.log(allOk ? "Verificación OK. Deja en una línea la siguiente tarea mínima." : "La verificación se detuvo. Arréglalo antes de seguir.");

Ejecutarlo es solo esto.

node morning-check.mjs

El truco está en reescribir el contenido de checks para adaptarlo a tu proyecto. Si tienes tests, añade npm test; si es un sitio estático, añade la comprobación de la URL pública. Con que cada mañana corran los mismos comandos en el mismo orden, los olvidos de verificación casi desaparecen. Yo le añadí también la comprobación de “no me habré quedado parado sin hacer commit al final”.

Tres situaciones donde esto se nota

Ejemplo 1: el primer día, solo dibujas el mapa del repositorio. No hace falta que arregles código de entrada. Pídele a la IA que te resuma “dónde están los directorios peligrosos” y “dónde están los archivos de configuración”, y con solo leer eso el primer día ya es un éxito. El trabajo de los días siguientes se vuelve mucho más rápido.

Ejemplo 2: el segundo día, solo un párrafo del README. Construyes una pequeña experiencia de éxito. Reescribe 3 líneas de la introducción y comprueba con npm run build que no se ha roto nada. Solo eso. Cuando cierras algo pequeño y lo llevas hasta su verificación, ganas la sensación de “esto lo puedo manejar yo”.

Ejemplo 3: el tercer día, una mejora pequeña ligada a algún número. Arreglar un titular de un artículo, añadir un test, reparar un enlace roto. Elige una mejora pequeña cuyo resultado se vea. Lo importante es acumular cada día un “cambio que llegó hasta su verificación”.

Errores típicos y cómo corregirlos

Te lo digo con honestidad: yo me caí muchas veces con estos tres.

Pozo 1: querer hacerlo todo de una vez. “Todo lo que veas raro” genera un diff gigante que no puedes verificar. La corrección es simple: limita la frase de hoy a una sola cosa. El resto lo pasas a la nota de mañana.

Pozo 2: dar por terminado solo con el build local. Que pase npm run build no garantiza que la URL pública salga bien. Una vez tuve el build en verde pero la página publicada seguía con la versión vieja y no me di cuenta. La corrección: tras publicar, abre la URL real y comprueba con los ojos que el titular y el principio del texto son los del cambio de hoy.

Pozo 3: pulsar una aprobación peligrosa por inercia. Cuando aparece un diálogo de confirmación, el principiante tiende a darle “Sí, lo que sea”. Si llega la confirmación de un borrado o de tocar producción, para un momento. Si dudas de la decisión, lo correcto es no hacer hoy esa operación. Para la forma de pensar los permisos también ayuda la explicación para personas no técnicas.

La forma de la nota que dejas para la próxima vez

La nota que dejas al final puede ser corta. Pero conviene fijarle una forma para que el tú de mañana no rehaga la misma decisión.

- Lo que hice hoy: reescribí las 3 líneas de introducción del README
- Cómo lo verifiqué: npm run build con éxito / titular comprobado en la URL pública
- Riesgo que queda: hay 2 enlaces de imagen rotos
- Tarea mínima de mañana: arreglar 1 solo enlace de imagen

Con esta nota, el tiempo que pierdes por la mañana decidiendo “¿por dónde empiezo?” se vuelve cero. Desde que hago esto, el arranque de la mañana se me ha acelerado, a ojo, unos 5 minutos.

Preguntas frecuentes

P. No tengo ni 15 minutos al día. ¿Se puede más corto? Sí. Al principio basta con “escribir en una frase la tarea mínima de hoy”. En cuanto cojas el hábito de decidir el comando de verificación, el tiempo de trabajo baja de forma natural.

P. No sé cuál es mi comando de verificación. Si tu proyecto tiene npm run build o npm test, con eso ya sobra para empezar. Si no hay nada, “abrir la URL pública y mirarla con los ojos” es una verificación de lo más válida. Al principio basta con decidir una sola cosa que la máquina pueda confirmar.

P. ¿No sería más rápido dejárselo todo a la IA? A corto plazo lo parece. Pero un “cambio que no puedes explicar qué arregló” acabas teniendo que releerlo entero más tarde. Cerrar en pequeño, en total, sale más rápido: esa es mi experiencia.

P. ¿Qué debería hacer un principiante lo primero de todo? Dibujar el mapa del repositorio. Antes de tocar código, pídele a la IA que te resuma dónde está cada cosa y léelo. Esa es la base para avanzar con seguridad.

P. ¿Sirve esta rutina también para implantarla en un equipo? Sí. Solo que, en equipo, conviene documentar antes “quién aprueba la publicación” y “qué comprobación será la meta”; así el hábito personal se convierte tal cual en la norma del equipo.

Lo que pasó al probarlo de verdad

Desde aquel viernes por la noche dejé de agobiarme con “hasta dónde le dejo a la IA”. En su lugar, lo único que decido cada mañana son dos cosas: la frase de hoy y el comando de verificación.

Tras correr morning-check.mjs durante dos semanas, lo que más cambió fueron los olvidos de verificación. Antes hacía commit creyendo que el build había pasado y luego, alguna vez, descubría que estaba roto. Desde que paso las comprobaciones por la máquina en el mismo orden, eso se ha quedado en cero.

Y la nota de 4 líneas que dejo cada noche. Desde que la empecé, desapareció el “¿qué tocaba hacer?” de la mañana siguiente. En vez de buscar el uso más ingenioso, cierra en pequeño y deja constancia de la verificación. Es poco vistoso, pero creo que la velocidad con la que un principiante avanza se decide justo aquí.

Para empezar, mañana por la mañana decide una sola frase y ejecuta un comando de verificación. Cuando, a fuerza de repetir, tengas tu propio molde, amplía tus plantillas de petición con el catálogo de materiales y reducirás aún más los pasos de cada día.