Cómo uso Claude para trabajar sin perder contexto (ni documentar dos veces)

· 3 min de lectura

Llevo meses usando Claude a diario en mi trabajo como Data Engineer. Y he aprendido una cosa: las conversaciones largas son un problema.

Cuando el contexto se compacta (porque la conversación pesa demasiado), Claude pierde información. De repente no recuerda qué decidimos hace 20 mensajes, o se inventa cosas que no hemos hablado. Es frustrante.

Así que desarrollé un sistema simple que resuelve esto y, de paso, me genera documentación sin esfuerzo extra.

El problema

Estás resolviendo un ticket complejo. Llevas 30 mensajes de ida y vuelta con Claude. Has probado tres approaches, descartado dos, y finalmente tienes algo que funciona.

Entonces pasa una de dos cosas:

  1. La conversación se compacta y Claude “olvida” por qué descartaste los otros approaches
  2. Terminas el ticket y una semana después no recuerdas qué hiciste ni por qué

En ambos casos, el conocimiento se pierde.

La solución: un artifact como memoria externa

Al empezar cualquier tarea no trivial, le pido a Claude que abra un artifact con un archivo .md. Le digo algo como:

“Abre un artifact con un .md donde vayas documentando lo que hacemos: el problema, los approaches que probamos, las decisiones y por qué las tomamos.”

A partir de ahí, en cada respuesta Claude actualiza ese documento. No es un log de la conversación, es un resumen estructurado del trabajo.

Por qué funciona

Cuando el contexto se compacta, Claude pierde mensajes antiguos. Pero el artifact sigue ahí, visible, con toda la información importante.

Es como su propia memoria externa dentro de la conversación. Le obligo a documentar en tiempo real, y eso le salva cuando el contexto se comprime.

El bonus: documentación gratis

Cuando termino el trabajo, le pido dos cosas:

  1. Un .doc para el equipo: Documentación formal que pueden leer mis compañeros, con el formato y tono apropiado para compartir.

  2. El .md para mi Obsidian: El archivo del artifact, que guardo en mi base de conocimiento personal.

De una conversación de trabajo saco:

  • El problema resuelto
  • Documentación para el equipo
  • Documentación para mí
  • Y potencialmente un post si el tema tiene chicha

Cero esfuerzo extra de documentación porque Claude documenta mientras trabaja.

Ejemplo práctico

Digamos que estoy resolviendo un problema de rendimiento en Power BI. El artifact va creciendo así:

## Problema
La medida de % de conversión tarda 45 segundos en cargar.

## Contexto
- Tabla de ventas con 2M de filas
- Relación inactiva con tabla de fechas
- El cliente filtra por región y mes

## Approaches probados

### 1. Medida original
Usaba la relación activa. Rendimiento inaceptable.

### 2. Modificar para usar relación inactiva
Mejor, pero seguía lento en agregaciones grandes.

### 3. Reestructurar para empujar al Storage Engine (SOLUCIÓN)
- Movimos la lógica pesada fuera del iterador
- Rendimiento: 2 segundos

Cuando termino, tengo documentado el proceso de decisión. Si dentro de 6 meses alguien pregunta “¿por qué no usamos la relación activa?”, la respuesta está ahí.

Conclusión

No es nada revolucionario. Es simplemente obligar a Claude a hacer algo que los humanos deberíamos hacer pero no hacemos: documentar mientras trabajamos, no después.

La diferencia es que a Claude no le da pereza. Y si le dices que lo haga, lo hace.

Pruébalo en tu próxima tarea compleja. Peor que lo que haces ahora no va a ser.