Let me be upfront about who this is for: if you're building one product, this probably won't land. A single CLAUDE.md keeps your agent mostly on track, and the "amnesia" between sessions isn't bad enough to hurt.
It falls apart when you're running several products in parallel — and worse, across several different LLMs.
That's me right now. A handful of products, big and small, built across Claude Code, Cursor, and ChatGPT. At first it was glorious. Two features shipped in a day, some days.
Then this started happening:
- I'd forget, mid-work on product B, a decision I'd made on product A (the human drifting)
- A design I'd locked in via Claude Code, the Cursor session knew nothing about (the LLM drifting)
- Which product, which model, which session, decided what — nobody, human or AI, held the whole picture anymore
One morning I tried to survey all of it and realized: I couldn't say, in one sentence, what any of these products even were anymore.
Every change had been reasonable in the moment. The AI returned something plausible every time. Each step was correct. The whole had quietly drifted from the original design.
Like a boat slipping off course with the current.
This already has a name (several, actually)
Over the last year, this failure mode picked up names in English:
- intent drift — prompts are always underspecified, the model fills in "reasonable" defaults, and those defaults slowly diverge from what you actually wanted (the SDD discussion)
- context decay — once the codebase outgrows the model's effective context, it forgets old decisions and silently contradicts them
- intent debt — proposed as the successor to technical debt, with an actual paper behind it
Different labels, same thing: intent and implementation quietly become two different products.
If technical debt is "code you'll pay for later," drift is "intent you'll pay for later" — and it's far harder to see. The tests pass. It runs. Nobody can describe the whole anymore.
Why parallel work makes drift faster
Here's the counterintuitive part. The faster you go, and the more you juggle, the faster you drift.
When it was just me on one product, drift was slow. There's a limit to what one human writes in a day, and I rebuilt the whole picture in my head as I went. "Wait, this contradicts what we did last week" — my hands hit the brakes automatically.
Every one of those conditions is now gone:
- Speed — dozens of moves a day. A day's worth of drift-distance, in a day.
- Local optima — the agent answers each task optimally. It isn't looking at the product's overall intent.
- No global map — sessions reset every time. Nobody (human or AI) holds a "you are here."
-
It multiplies — with N products and M LLMs, your intent is scattered across N×M places. One
CLAUDE.mdcan't track that.
"Just write the intent into CLAUDE.md / AGENTS.md," you say. Fine for one product. The moment you span several, the context file itself goes stale as the codebase evolves, with no automated way to detect it. A hand-drawn map becomes a lie the moment the territory moves — and now you've got more maps lying to you.
This isn't really a code problem
A small detour — but maybe the most important part.
Drift isn't unique to software:
- A home renovation — keep adding "just one more convenience" and the original floor plan's intent disappears
- An organization — stack individually-correct decisions and you wake up not knowing what the company is
- A life — make reasonable choice after reasonable choice and end up far from what you set out to do
Human endeavors drift from intent when left alone. It's universal. AI just put it on fast-forward — and people running many things in parallel were already drift-prone. That's why "a map that shows your current position and your intended course" suddenly got valuable.
To fight drift, you need a chart
A drifting boat doesn't need a bigger engine. It needs a chart — where you are, and where you meant to go.
So the tool I'm building, Linksee, has three jobs:
-
The chart (Product Map) — you declare the decisions and constraints that define the product as anchors. Linksee never mines them from your code (
declare-don't-mine). It then watches whether the committed reality drifts from what you declared. -
You-are-here (
where_am_i) — every turn, the agent checks where on the map it's standing — and crucially, the blast radius ("change this and what else breaks?"), so it doesn't wander off chasing a local optimum. -
Off-course alarm (
drift_status) — it lists which decisions are 🔴 drift / 🟡 review / ⚪ held / 🔵 aligned right now. Think "Datadog, but for product intent." You can leave it as a warning, or harden it so the agent's drifting action gets blocked on the spot (a PreToolUse gate).
Linksee actually started as a memory layer to fix the "amnesia" I wrote about last time. But running many products across many LLMs taught me the real win isn't the memory itself — it's re-shaping memory into a map that tells you your current position. Memory was the means; the chart was the point.
See your "current position" in 5 minutes
Enough theory. Fastest path is to run it.
npx linksee-memory init
Then add it to Claude Code / Cursor / Claude Desktop:
{
"mcpServers": {
"linksee": {
"command": "npx",
"args": ["linksee-memory", "start"]
}
}
}
That alone gets you:
- The agent checking
where_am_ievery turn — "where am I + what breaks if I change this (blast radius)" -
drift_statuslisting what's currently off-course as 🔴 / 🟡 / ⚪ / 🔵 (the "Intent Datadog") - Memory in a local SQLite file, shared across Claude Code / Cursor / ChatGPT / Codex / Gemini — the same "current position" in every tool
No cloud, no API key, MIT. The first time you run drift_status, you'll probably think what I thought: "oh — my product had drifted that far."
Note: these work as MCP tools today. The visual chart dashboard is rolling out.
See it catch drift
Words are slower than seeing it.
Here's a concrete one: the README promises a --export flag — but the code doesn't have it. That's drift too (intent vs. reality). linksee-memory map catches it, and shows what else a change would touch (the blast radius):
The point: every change passed review on its own. Linksee doesn't judge individual commits — it measures how far the committed reality has moved from the intent you declared (your README, your design). That's how the slow collapse of a feature's shape finally becomes visible.
How this differs from what you already use
Honestly, other tools touch this problem. They aim at different parts of it.
| Tool | What it's good at | What I was missing |
|---|---|---|
CLAUDE.md / AGENTS.md
|
Fine for a single product. One place for intent. Official | Breaks across many products × many LLMs. Per-repo, hand-written, goes stale as the territory moves |
| Spec-Driven Development / spec tools | Treating the spec as source of truth — close in spirit | Assumes you fix the spec up front. Different from measuring drift while you run |
| Mem0 / Letta / Zep (memory) | Storing memory, well | No layer that re-shapes memory into a map + a current position |
Linksee |
Builds a map from reality, reports position and drift | (this is the thing I'm building) |
The point is that "writing intent down" isn't enough. The moment you write it, the territory moves. You need a living chart that follows reality and tells you when it's diverging — especially when you're juggling several products at once.
Try it
npx linksee-memory init
A GitHub star genuinely makes my day 🙏
One honest caveat
To close, the uncomfortable part.
This whole "drift" framing — and the chart as a fix — might just be over-fitted to my own mess (too many products at once). If you're on a single product, maybe you never drift.
So I genuinely want to know:
- Running multiple products / multiple LLMs in parallel, have you hit the "what even is this anymore" moment?
- If so — was it a memory problem, or a map problem?
- Of "6-layer memory," "current position," and "drift detection" — which sounds most (or least) useful?
Find me on X (@michielinksee or open a GitHub issue. I read and reply to all of them.
Solo founder in Singapore, building in public.
Top comments (0)