The Contextual Explosion

Early 2025 — Return to AI

Early 2025 — automatic context generation (“visitor” pattern)

In 2025, I resume AI experiments fully. Since the beginning of 2025, these subjects have become the center of gravity of my self-training and personal R&D work.

My central problem: how to make AI understand my project? If I give it all the code at once, it’s too much: it gets lost. If I only give it bits, it lacks the big picture.

I start from a simple idea: break the project into organized pieces, like a book with chapters and sub-chapters. Each folder would have a summary, and those summaries would build a global view. AI could then move from general (project overview) to specific (single-file detail).

My idea: automatically generate context files by traversing the project tree. Inspired by a compilation course (visitor pattern), I design a script that scans the codebase in depth:

Project/
├── src/
│   ├── utils/
│   │   ├── helper.js       → scan + summary by LLaMA
│   │   ├── config.js       → scan + summary by LLaMA
│   │   └── .context        ← "utils/ contains helpers and config"
│   │
│   ├── components/
│   │   ├── Button.jsx      → scan + summary by LLaMA
│   │   ├── Form.jsx        → scan + summary by LLaMA
│   │   └── .context        ← "components/ contains UI React"
│   │
│   └── .context            ← aggregation: utils/ + components/
│
└── .context                ← global view: "React project with utils and UI"

Flow: files → LLaMA → .context summaries → bottom-up aggregation

The principle:

• Each file is analyzed by LLaMA (local model on my machine)
• A summary of 2-3 sentences is generated and stored in a .context file
• The summaries go up the tree: the .context of a folder aggregates the .context of its subfolders

On paper, it looks great: a multi-scale view of the project, from global to detail.

In practice, it hits limits fast. My machine processes files sequentially 1 Sequentially: one by one, in order. Unlike parallel processing where multiple files would be analyzed at the same time. with LLaMA. Small project: ~15 minutes. Big project: complexity becomes exponential 2 Exponential complexity: processing time explodes non-linearly. If 100 files take 15 minutes, 200 files won’t take 30 minutes but much more (like several hours). It’s the classic problem of algorithms in O(n²) or worse. , so it becomes unusable for real projects. The approach is interesting, but not scalable 3 Scalable: capable of scaling up, of handling increasing volumes without collapsing. on my machine. I paused the project.

In fact, I wanted to go further. Not just generate one raw context file, but define a dedicated DSL 4 DSL (Domain Specific Language): a custom mini-language to describe something precise. For example, instead of writing “this file manages authentication”, I could have defined keywords like @auth, @route, @db to structure descriptions in a standardized way. for describing the project, then run multiple analysis passes. First, a rough pass to scan everything and get an overview. Then a finer pass to inject first-pass results and refine context. Longer term, I imagined iterative scans, increasingly specialized, with different AI models based on strengths (summary, structure, semantics, etc.). In theory, this was strong: evolving context that improves with each pass. In practice, since the first scan was already long, the multi-pass approach became computationally unsustainable on my machine. I never completed it, but it changed how I think about what future AI systems could do through iterative re-contextualization.

The takeaway is still valuable: I clarified for myself how important hierarchical breakdown and selective context aggregation are.

Early 2025 — Cursor, Sonnet 3.7 — during the effort

I continue to use Cursor intensively. At the same time, Sonnet 3.7 (Anthropic) blows me away on certain aspects of code — I gradually switch to Anthropic for more reliable generation. Very quickly, I realize that a more capable model changes the experience, but does not solve all problems: robustness always depends on the rules and context I provide.

I then start multiplying .cursorrules files and .cursor/rules directories across the tree to harmonize conventions and centralize context.

At the same time, I launch a personal project, initially a simple website, that quickly turns into a full application. It becomes a real test ground: I have to apply and validate context rules on concrete cases (asset management, workflows, lightweight multi-tenant). That’s where I realize how critical cursorrules and folder-based context organization are in production workflows. The goal is a coherent base that guides Cursor without re-explaining everything every time. That’s also when I realize both human and technical rules must be formalized in files AI can read.

Spring 2025 — Sonnet 4.0 & Opus 4.0 — another leap

On May 22, 2025, Anthropic officially announces Claude Sonnet 4 and Claude Opus 4. For me, it’s a new turning point. Upon release, I tested the models and, convinced by the reasoning and coding capabilities, I started using Claude Code, Anthropic’s tool for working directly from the terminal / IDE. I subscribed to the Claude MAX offer to be able to iterate without constraint.

In one intensive session, I build a complete React site with the DB included, a personal proof of concept of what aligned models and prompts can produce. To be clear: it’s still “vibe coding” output, quick and dirty. Great POC, not maintainable in production as-is.

Beyond the technical side, some parts of “AI culture” start to wear on me: emoji-heavy answers, fake-cool tone, unnecessary verbosity. I want sober, effective tools, not a chatbot patting me on the back.

Late May–June 2025 — Migration Cursor → Claude Code: duplication then symbolic links

At the beginning with Claude Code, I start from what I already have: my Cursor rules. Very quickly, I copy/paste my .cursorrules (and some important .cursor/rules) into Claude.md to keep the same framework for Anthropic. Result: two versions of the same directives in the repo, one for Cursor and one for Claude, with only names/paths changed.

This duplication didn’t sit well with me. I want a single source of truth: I therefore create an AI.md file (neutral format) which contains the “master” context. For Claude Code, it’s simple: I put a symlink Claude.md → AI.md. For Cursor, on the other hand, a simple symbolic link is not enough: the rules are .mdc files with frontmatter and specific constraints (globs, scope, rule types, etc.).

With this system, Cursor loads the right rule by folder (via patterns/regex), and Claude gets the same content through the symlink, without duplication. It wasn’t fragile in itself; robustness came from standardizing on AI.md plus .mdc generation.

In parallel, inside Claude Code, I test auto-inclusion of context files. That’s when the idea of what is called “lazy-loading” appears: load only what is needed, when it’s needed. That path, combined with AI.md unification across Claude and Cursor, leads to the next phase, much more ambitious and time-consuming: building a multi-layer system (see section L0 / L1 / L2) with successive passes to refine context.