La explosión contextual

Paso de reglas dispersas a los primeros sistemas. Trato de automatizar el contexto, choco rápido con los límites de mi máquina, y al final me queda una idea que persiste: una sola fuente, formatos derivados.

Generación automática de contexto

Principios de 2025

Retomo las experimentaciones con IA a fondo, pero con una obsesión más precisa: cómo hacerle entender un proyecto a la IA sin ahogarla, y sin dejarla trabajar a ciegas. Si le doy demasiado poco, pierde la forma del sistema. Si le doy todo, se pierde.

Arranco entonces con una idea simple: cortar el proyecto en partes organizadas, como un libro con capítulos y subcapítulos. Cada carpeta tendría su resumen, y el conjunto formaría una vista global. La IA podría navegar de lo general (vista de conjunto) a lo particular (detalle de un archivo).

Convierto esa idea en un script: una recursión bottom-up inspirada en el patrón visitor (viejo reflejo de cursos de compilación), que recorre el árbol, resume cada parte y vuelve a subir de a poco hacia una vista de conjunto.

Proyecto/
├── src/
│   ├── utils/
│   │   ├── helper.js          → scan + resumen por Ollama
│   │   ├── config.js          → scan + resumen por Ollama
│   │   └── analyzed.yaml      ← "utils/ contiene helpers y config"
│   │
│   ├── components/
│   │   ├── Button.jsx         → scan + resumen por Ollama
│   │   ├── Form.jsx           → scan + resumen por Ollama
│   │   └── analyzed.yaml      ← "components/ contiene UI React"
│   │
│   └── analyzed.yaml          ← agregación: utils/ + components/
│
└── analyzed.yaml              ← vista global: "proyecto React con utils y UI"

Flujo: archivos → Ollama → resúmenes analyzed.yaml → agregación bottom-up

Para cada archivo:
  leer el contenido
  pedirle un resumen estructurado a Ollama
  escribir ese resumen en el analyzed.yaml de la carpeta

Después, subiendo por el árbol:
  leer los analyzed.yaml de las subcarpetas
  agregarlos en el analyzed.yaml de la carpeta padre
  repetir hasta la raíz del proyecto

El principio me gusta: cada archivo deja una traza estructurada (tipo, funciones, dependencias, complejidad), cada carpeta agrega las trazas de sus hijos en un archivo de contexto (un analyzed.yaml), y el proyecto termina produciendo su propio mapa. Puedo bajar de lo global al detalle sin cargar todo de una.

En la práctica, se traba rápido. Todo es secuencial: una llamada HTTP por archivo a Ollama, sobre un modelo de razonamiento (DeepSeek R1 8B) que piensa antes de responder. En un proyecto chico ya espero unos quince minutos. En un proyecto grande, el tiempo explota. El principio sigue siendo interesante, pero no escala con mi máquina. Pongo el proyecto en pausa. El código sigue ahí, congelado en pleno refactor.

Lo que me queda no es el script. Es la idea de un contexto que se puede reconstruir por pasadas: una primera lectura da un mapa grueso, y las siguientes parten de ese mapa para corregir y precisar.

También tenía en mente un pequeño lenguaje para describir el proyecto, con escaneos cada vez más especializados y varios modelos según sus fortalezas: resumen, estructura, semántica. Sobre el papel, cada pasada hacía a la siguiente menos ciega. En los hechos, la primera pasada ya era demasiado lenta. Agregar pasadas volvía el sistema insostenible.

Nunca lo llevo hasta el final, pero la experiencia que me dejó vale la pena. Me clarifica la importancia del corte jerárquico, de la agregación selectiva, y de un contexto que se construye por pasadas sucesivas.

Cursor, Sonnet 3.7 (durante el esfuerzo)

Sigo usando Cursor intensivamente. Sonnet 3.7 (Anthropic) me sorprende en varios aspectos del código: voy migrando de a poco hacia Anthropic para una generación más fiable. Un modelo más potente cambia la experiencia, pero no arregla todo: la robustez sigue dependiendo de las reglas y del contexto que doy.

Empiezo entonces a repartir reglas en el proyecto: .cursorrules, después .cursor/rules. Busco menos el prompt correcto que el lugar correcto donde apoyar las convenciones.

En paralelo, un proyecto personal crece. Al principio es un sitio simple. Después se vuelve una aplicación completa, con assets, workflows, convenciones por carpeta. Las reglas dejan de ser teóricas: veo al toque cuándo ayudan, cuándo faltan y cuándo tengo que reexplicar todo. Ahí entiendo que las reglas Cursor y la organización por carpetas pueden volverse una verdadera superficie de producción.

Las reglas también se vuelven un sistema para mantener: convenciones humanas, restricciones técnicas, ubicación en el árbol, formato esperado por cada herramienta.

Sonnet 4 y Opus 4 (otro salto)

Mayo de 2025

Cuando Anthropic anuncia Claude Sonnet 4 y Claude Opus 4, el salto se siente enseguida. Claude Code ya existía en preview, había escuchado hablar de él, pero me meto en serio recién en ese momento: la herramienta pasa a estar disponible para todo el mundo, llegan las integraciones IDE, y el conjunto entra en mi rutina de dev. Pruebo los modelos apenas salen y me suscribo a Claude Max para poder iterar sin trabas.

En una sesión intensiva, armo un sitio React completo, base de datos incluida (un POC personal, para ver hasta dónde llega la cosa). Que quede claro: sigue siendo código de «vibe coding», rápido y mal hecho. Excelente POC, pero imposible de mantener así en producción.

Más allá de lo técnico, cierta «cultura IA» me empieza a cansar: respuestas llenas de emojis, tono falsamente cool, bla bla inútil. Quiero herramientas sobrias y eficaces, no un chatbot que me palmee la espalda.

Migración Cursor → Claude Code: duplicación, después enlaces simbólicos

Mayo y junio de 2025

Cuando paso a Claude Code, no arranco de cero. Agarro lo que ya tengo: mis reglas Cursor. Copio los .cursorrules, después algunos archivos .cursor/rules, en CLAUDE.md para recuperar el mismo marco del lado de Anthropic.

La duplicación se vuelve molesta rápido. Dos archivos cuentan lo mismo, pero con nombres y formatos distintos. Entonces creo AI.md como fuente neutra: el contexto maestro vive ahí, las herramientas se adaptan alrededor.

Para Claude Code es simple: CLAUDE.md puede apuntar a AI.md por enlace simbólico. Del lado de Cursor, el enlace simbólico no alcanza. Las reglas tienen su formato, sus metadatos, sus globs. Hay que generar archivos .mdc a partir de la misma fuente, en lugar de mantener una segunda versión a mano.

Con este sistema, Cursor carga la regla adaptada a la carpeta, y Claude recupera el mismo contenido por enlace simbólico. Dejo de mantener dos textos en paralelo. La robustez viene de ahí: una fuente, varios formatos derivados.

En Claude Code, también experimento con la autoinclusión de los archivos de contexto. Ahí emerge la idea de una carga llamada «lazy-loading»: cargar solo lo necesario, en el momento justo.

Esta unificación me empuja hacia lo que viene: un sistema que arranca liviano y baja por las capas de contexto cuando la tarea lo pide.