Las líneas importantes las escribes tú

Qué es y por qué importa

Si haces tu app con Claude y no entiendes el código, el día que se rompe te quedas bloqueado. No sabes dónde mirar y pides que arregle algo que ni siquiera sabes describir. Cuanto más crece la app, más pesa.

Claude Code ya trae una respuesta dentro: los estilos de salida. Un estilo es un conjunto de instrucciones que cambia cómo te responde Claude durante toda la sesión. Además del básico, que se llama Default, incluye cuatro: Proactive, Concise, Explanatory y Learning. Learning es el pensado para aprender.

Con Learning el trabajo rutinario lo sigue haciendo él. Pero cuando llega a una parte con una decisión real, te deja escribir unas líneas y mientras tanto te explica sus decisiones. La app la terminas igual, pero algunas líneas clave las has escrito tú. Es para quien construye solo con Claude y quiere entender su código lo bastante como para arreglarlo.

1. Cómo se activa

Hay un camino para cada sitio donde usas Claude Code. El comando y los dos menús guardan tu elección en el archivo .claude/settings.local.json del proyecto: vale solo en ese proyecto, y solo para ti.

1. En la terminal: escribe /output-style learning. El comando no distingue mayúsculas y minúsculas. Si escribes solo /output-style, te muestra los estilos y marca el activo.
2. También en la terminal, con el menú: escribe /config y elige Output style.
3. En la extensión de VS Code: escribe / en el cuadro de mensajes y elige Output styles.
4. En la app de escritorio: aquí /config abre los ajustes de la app, no el menú. Escribe tú el campo outputStyle en el archivo .claude/settings.local.json del proyecto, como aquí abajo, y luego abre una sesión nueva.

{
  "outputStyle": "Learning"
}

En el archivo cuenta la mayúscula: se escribe Learning, no learning. Un nombre mal escrito no da error: te deja en el estilo Default sin avisarte. Si el archivo ya tiene otros ajustes, añade solo la línea outputStyle dentro de las llaves que ya hay.

Si quieres Learning en todos los proyectos, pon el mismo campo en el archivo de tu usuario, ~/.claude/settings.json. Pero los ajustes de un proyecto ganan a los del usuario: si un proyecto tiene su propio outputStyle, allí vale ese.

Si cambias de estilo a mitad de sesión, en la última versión de Claude Code el nuevo estilo vale desde tu siguiente mensaje: no hace falta empezar de nuevo.

2. Qué pasa mientras trabaja

Le das una tarea como siempre. A partir de ahí, va así:

1. El trabajo rutinario lo hace él: los archivos que hay que crear, las conexiones, las partes que solo se escriben de una manera.
2. Cuando llega a una parte con una decisión real, se para. La documentación da tres ejemplos: cómo gestionar un error, cómo organizar los datos, una regla de tu app que se puede escribir de más de una forma correcta.
3. En el archivo, en el punto exacto, deja un comentario de marcador: la palabra inglesa para «por hacer» seguida de (human), es decir, «persona». Para encontrarlo, busca (human) en el archivo.
4. Te manda una petición Learn by Doing en tres partes: Context, lo que ya está hecho; Your Task, qué tienes que escribir y dónde; Guidance, en qué pensar mientras escribes.
5. Luego se para y espera. Tú escribes esas pocas líneas en lugar del marcador y le dices que has terminado.
6. Lee tu código, responde con un recuadro Insight sobre lo que has escrito y retoma el trabajo.

Mientras tanto, antes o después del código que escribe, añade recuadros Insight: dos o tres puntos sobre por qué ha decidido así, ligados a tu proyecto. Se quedan en la conversación: no acaban en tus archivos como comentarios.

Una cosa que conviene saber ya: un estilo es una instrucción, no una garantía. Claude decide qué partes dejarte, y en una tarea sin decisiones reales puede no dejarte nada. Si quieres una parte concreta, pídesela: es la sección siguiente.

3. Úsalo en una función real

Rinde más en una función que de verdad necesitas que en un ejercicio. Las líneas que conviene quedarte tú son las reglas de tu app: son las que cambiarás cuando cambie la idea, y las primeras que mirarás cuando algo no cuadre. Escríbele así:

Estoy añadiendo [la función, por ejemplo: máximo 3 proyectos para quien usa la versión gratis]. Escribe tú la parte rutinaria: archivos, conexiones, interfaz. Las reglas de mi app, es decir, qué pasa en cada caso y cómo gestionar los errores, déjamelas a mí con el marcador (human), de una en una. Para cada una dime en qué archivo está, qué recibo y qué tengo que devolver.

Cuando hayas escrito tus líneas:

He terminado el marcador (human) en [nombre del archivo]. Lee mi código y dime si hay algún caso que no gestiono, sin reescribirlo tú. Luego sigue.

4. Cuando te atascas, pide una pista

A veces miras el marcador y no sabes por dónde empezar. No le pidas la solución enseguida: si la lees ya hecha, la próxima vez estás otra vez igual. Pídele una pista:

Estoy atascado en el marcador (human) en [nombre del archivo]. No escribas el código. Dame una sola pista: lo primero que debo comprobar o la pregunta que me tengo que hacer. Si después de dos pistas sigo parado, enséñame un ejemplo parecido, pero no igual.

Si de verdad no es el momento, siempre puedes decirle que escriba él esa parte. Pero prueba antes con las pistas: es ahí donde el código se vuelve tuyo.

5. Cuando tienes prisa, vuelve a Default

Learning te frena, y está bien que sea así. Las respuestas son más largas que en Default por cómo está hecho el estilo, así que gastas más tokens de salida. Cuando solo necesitas cerrar algo, vuelve al estilo básico:

/output-style default

Default está en la lista con los otros estilos, así que también lo encuentras en /config y en el menú de VS Code. En la app de escritorio, quita la línea outputStyle del archivo. Cuando vuelvas a tener tiempo, vuelve a poner Learning.

6. Si solo quieres las explicaciones: Explanatory

Si no te apetece escribir código pero quieres entender qué pasa, está Explanatory. Hace el trabajo como Default y añade los mismos recuadros Insight, con el porqué de sus decisiones. No te deja nada que escribir y no se para a esperarte.

Se activa igual: /output-style explanatory en la terminal, o Explanatory en el archivo, con la E mayúscula. Aquí también las respuestas son más largas que en Default, así que más tokens. Explanatory va bien cuando entras en un código que no conoces; Learning, cuando escribes una función que tendrás que mantener tú.

Errores comunes

• Escribir learning en minúscula en el archivo. En el archivo va Learning: con un nombre equivocado te quedas en Default y nada te avisa.
• Esperar un marcador (human) en cada respuesta. Claude decide qué partes dejarte: si quieres una, pídesela.
• Dejarlo activado cuando tienes prisa. Las respuestas largas gastan más tokens: vuelve a Default y actívalo de nuevo después.
• Poner Learning en ~/.claude/settings.json y no entender por qué en un proyecto no arranca. Los ajustes del proyecto ganan: mira si allí hay otro outputStyle.
• Crear a mano .claude/settings.local.json y acabar subiéndolo a git. Cuando lo crea Claude Code, lo deja fuera de git él solo; si lo creas tú, añádelo al .gitignore.

Lista de comprobación

• Learning está activado en el proyecto en el que trabajo
• Si lo he puesto en el archivo, pone Learning con la L mayúscula
• Le he pedido que me deje las reglas de mi app con el marcador (human)
• He escrito mis líneas y le he dicho que he terminado
• He leído el Insight sobre mi código
• Sé cómo volver a Default cuando tengo prisa

Preguntas frecuentes