Principios de 2025: la explosión contextual
Regreso intensivo y primeras arquitecturas de contexto.
Principios de 2025 : regreso a la IA
Principios de 2025 : generación automática de contexto (patrón “visitor”)
En 2025, retomo las experimentaciones con IA a fondo. Desde principios de 2025, estos temas se han convertido en el centro de gravedad de mi trabajo de autoformación e I+D personal.
Mi problema central: ¿cómo hacer entender mi proyecto a la IA? Si le doy todo el código de golpe, es demasiado: se pierde. Si solo le doy trozos, le falta visión de conjunto.
Parto de una idea simple: dividir el proyecto en partes organizadas, como un libro con capítulos y subcapítulos. Cada carpeta tendría su resumen y, juntas, formarían una vista global. La IA podría navegar de lo general (visión de conjunto) a lo particular (detalle de un archivo).
Mi idea: generar automáticamente archivos de contexto recorriendo la estructura del proyecto. Inspirado en un curso de compilación (patrón visitor), diseño un script que escanea la base de código en profundidad:
Projet/
├── src/
│ ├── utils/
│ │ ├── helper.js → scan + resumen por LLaMA
│ │ ├── config.js → scan + resumen por LLaMA
│ │ └── .context ← "utils/ contiene helpers y config"
│ │
│ ├── components/
│ │ ├── Button.jsx → scan + resumen por LLaMA
│ │ ├── Form.jsx → scan + resumen por LLaMA
│ │ └── .context ← "components/ contiene UI React"
│ │
│ └── .context ← agregación: utils/ + components/
│
└── .context ← vista global: "proyecto React con utils y UI"
Flujo: archivos → LLaMA → resúmenes .context → agregación bottom-up
El principio:
- Cada archivo es analizado por LLaMA (modelo local en mi máquina)
- Se genera un resumen de 2-3 frases y se almacena en un archivo
.context - Los resúmenes remontan el árbol: el
.contextde una carpeta agrega los.contextde sus subcarpetas
Sobre el papel, suena genial: una visión multiescala del proyecto, de lo global al detalle.
En la práctica, se traba rápido. Mi máquina procesa los archivos secuencialmente Secuencialmente: uno por uno, en orden. Al contrario del procesamiento paralelo donde varios archivos serían analizados al mismo tiempo. con LLaMA. Proyecto chico: ~15 minutos. Proyecto grande: la complejidad se vuelve exponencial Complejidad exponencial: el tiempo de procesamiento explota de forma no lineal. Si 100 archivos toman 15 minutos, 200 archivos no tomarán 30 minutos sino mucho más (tipo varias horas). Es el problema clásico de los algoritmos en O(n²) o peor. , así que en proyectos reales no sirve. El enfoque es interesante, pero no escalable Escalable: capaz de pasar a escala, de manejar volúmenes crecientes sin colapsar. en mi máquina. Terminé pausando el proyecto.
En realidad, quería llevar la idea más lejos. No buscaba solo un archivo de contexto bruto, sino un DSL DSL (Domain Specific Language): un mini-lenguaje a medida para describir algo preciso. Por ejemplo, en lugar de escribir “este archivo gestiona la autenticación”, podría haber definido palabras clave como @auth, @route, @db para estructurar las descripciones de forma estandarizada. específico para describir el proyecto y después encadenar varias pasadas de análisis. Primero, una pasada gruesa para barrer todo el código y sacar una vista general. Luego, una segunda más fina para reinyectar los resultados y refinar el contexto. A largo plazo, incluso imaginaba escaneos iterativos cada vez más especializados, usando varios modelos de IA según fortalezas (resumen, estructura, semántica, etc.). En teoría, era sólido: un contexto evolutivo que se corrige y enriquece en cada pasada. En la práctica, como la primera pasada ya tardaba mucho, el enfoque multipasada se volvió materialmente insostenible en mi máquina. Nunca lo implementé hasta el final, pero me abrió los ojos sobre lo que podría hacer una IA capaz de recontextualizarse por iteraciones sucesivas.
La lección igual fue valiosa: clarifiqué para mí la importancia de la división jerárquica y de la agregación selectiva del contexto.
Principios de 2025 : Cursor, Sonnet 3.7 (durante el esfuerzo)
Sigo usando Cursor de forma intensiva. En paralelo, Sonnet 3.7 (Anthropic) me impresiona en varios aspectos del código, así que voy migrando hacia Anthropic para una generación más fiable. Muy rápido veo que un modelo más potente mejora la experiencia, pero no arregla todo: la robustez sigue dependiendo de las reglas y del contexto que doy.
Empiezo entonces a multiplicar .cursorrules y directorios .cursor/rules por toda la estructura para armonizar convenciones y centralizar contexto.
En paralelo, lanzo un proyecto personal (al principio, un sitio simple) que evoluciona rápido hacia una aplicación completa. Ese proyecto se vuelve un terreno de prueba real: me obliga a aplicar y validar reglas de contexto en casos concretos (gestión de assets, workflows, multi-tenant ligero). Ahí termino de confirmar lo críticas que son las cursorrules y la organización por carpetas en un workflow de producción. La idea es tener una base coherente que guíe a Cursor sin reexplicar todo en cada interacción. También ahí veo claro que hay que formalizar reglas humanas y técnicas en archivos que la IA pueda leer.
Primavera 2025 : Sonnet 4.0 & Opus 4.0 (otro salto)
El 22 de mayo de 2025, Anthropic anuncia oficialmente Claude Sonnet 4 y Claude Opus 4. Para mí, es un nuevo punto de inflexión. Desde el lanzamiento, probé los modelos y, convencido por las capacidades de razonamiento y codificación, empecé a usar Claude Code, la herramienta de Anthropic para trabajar directamente desde la terminal / IDE. Me suscribí a la oferta Claude MAX para poder iterar sin restricciones.
En una sesión intensiva, construyo un sitio React completo con BDD incluida (una prueba de concepto personal de lo que sale cuando modelos y prompts están alineados). Seamos claros: sigue siendo “vibe coding”, rápido y sucio. Buen POC, pero inviable de mantener en producción tal cual.
Más allá de lo técnico, cierta “cultura IA” me empieza a cansar: respuestas llenas de emojis, tono falsamente cool y verborrea innecesaria. Busco herramientas sobrias y eficaces, no un chatbot que me dé palmaditas en la espalda.
Finales de mayo-junio 2025 : Migración Cursor → Claude Code: duplicación luego enlaces simbólicos
Al principio con Claude Code, parto de lo que ya tengo: mis reglas de Cursor. Muy rápido, copio/pego mis .cursorrules (y algunos .cursor/rules importantes) en Claude.md para mantener el mismo marco en Anthropic. Resultado: dos versiones de las mismas directivas en el repo (una para Cursor y otra para Claude), cambiando solo nombres/rutas.
Esta duplicación no me conviene. Quiero una sola fuente de verdad: creo entonces un archivo AI.md (formato neutro) que contiene el contexto «maestro». Para Claude Code, es simple: pongo un symlink Claude.md → AI.md. Para Cursor, en cambio, un simple enlace simbólico no basta: las reglas son archivos .mdc con frontmatter y restricciones propias (globs, scope, tipos de reglas, etc.).
Implemento entonces un script de generación:
- según la ubicación de un
AI.mden la estructura, el script construye un.mdccon el frontmatter correcto (globs, alcance local, tipo de regla); - en el cuerpo del
.mdc, inserto una referencia (incl./import) apuntando hacia el contenido delAI.md(que sigue siendo la fuente única); - despliego symlinks para
Claude.mden los lugares correctos para que Claude cargue el mismo contexto.
Con este sistema, Cursor carga la regla adecuada según la carpeta (vía patrones/regex), y Claude recupera el mismo contenido vía symlink, sin duplicación. No era frágil en sí; la robustez venía de estandarizar en AI.md + generar los .mdc.
En paralelo, en Claude Code, experimento la autoinclusión de archivos de contexto. Ahí aparece la idea de lo que se llama “lazy-loading”: cargar solo lo necesario, cuando hace falta. Esa línea, combinada con la unificación AI.md para Claude y Cursor, me lleva a la siguiente fase, mucho más ambiciosa y demandante: construir un sistema multicapas (ver la sección L0 / L1 / L2) con pasadas sucesivas para refinar el contexto.