DEV Community: michielinksee

I let AI build my products for months — then I couldn't tell what any of them were anymore

michielinksee — Tue, 16 Jun 2026 08:11:45 +0000

Claude Code and Cursor make you ship fast.

But once I was running several products in parallel — and across several different LLMs (Claude Code, Cursor, ChatGPT) — a different problem showed up:

I'd forget what I'd decided (the human)
A design I locked in via Claude Code, the Cursor session didn't know about (the LLM)
The README and the code drifted apart
The CLI changed, but npm and the docs stayed old
Neither I nor the AI could say which part of the product we were even touching

Every single change was correct. But the product as a whole kept sliding away from what it was supposed to be.

That's rough.

Building just one product? CLAUDE.md is probably enough. This is for people juggling several.

There's a name for this now: intent drift — the product slowly diverging from what you meant to build.

The exact moment it bites

You ask Claude Code:

fix the CLI setup flow

It does. Perfectly.

But to actually match that change, you probably also needed to touch:

README
the npm description
the GitHub install steps
docs
the landing page
the demo screenshot

The AI fixes the spot you asked about. That's it.

So you get:

The engine is fine. The install steps are stale. Users get stuck.

That's scarier than a bug. The code runs — the story around it is wrong.

Here's the tool catching exactly that — the README promises a --export flag the code doesn't have, and it shows the blast radius too:

A product has a map

A product grows along a path:

discovered → understood → tried → installed → kept → paid → expanded

And under each step sits a stack of surfaces:

LP / README / npm / GitHub / CLI / MCP / dashboard / docs / Stripe / support

While coding, you want to know: "where on this map am I, and if I change this, what else moves?" But running several products across several LLMs, that map falls out of your head — and nobody is tracking it. That's the drift.

So I'm building Linksee Memory

A local-first tool that records the decisions, the implementation, and the drift as you build with AI — so you can see them later.

It started as a memory tool. Now I think of it differently:

A shared map of the project — for the human and the multiple AIs.

Three commands.

1. What's drifting?

npx linksee-memory map status

Lists what's out of sync:

README says it, code doesn't
CLI changed, docs are old
LP and README disagree
a flow you planned, then abandoned

2. What do I fix next?

npx linksee-memory map next

3. Show me the whole map

npx linksee-memory map blueprint

Bonus: npx linksee-memory map where README.md tells you where a file sits, and what changing it would touch.

It all lives in a local SQLite file — so Claude Code, Cursor, ChatGPT, Codex and Gemini share the same map. No cloud, no API key, MIT.

Why it helps

The scariest thing in AI development isn't the code breaking.

It's the code working while the product's story — install, docs, promises — quietly drifts.

Try it

npx linksee-memory init

Everything stays local. Nothing leaves your machine.

repo: https://github.com/michielinksee/linksee-memory
landing: https://linksee-site.vercel.app

A GitHub star genuinely makes my day 🙏

I'd love your take

If you run multiple products / multiple LLMs — have you hit the "wait, what was this even for?" moment?

Was it a memory problem, or a map problem?
Of "what's drifting," "what's next," and "the whole map" — which would you actually use?

Drop a comment, or find me on X (@michielinksee).

Solo founder in Singapore, building in public.

I Built an MCP Server to Stop Claude Code from Forgetting Everything Between Sessions

michielinksee — Fri, 29 May 2026 10:30:27 +0000

TL;DR

Problem: Claude Code starts every session cold. It re-suggests libraries I already rejected, asks "should we use X?" about decisions made weeks ago, and re-reads unchanged files from scratch (paying full tokens each time).
Solution: I built linksee-memory — an MCP server with 6 structured memory layers and chunk-level file diff caching. Local SQLite, MIT, no cloud. Works across Claude Code / Cursor / Codex / Gemini CLI from the same database.
The feature that actually changed my workflow: the caveat layer — forget-protected entries for "never do this again". Cut repeat-suggestions of bad patterns to zero.
Install: npm install -g linksee-memory

The problem: my agent kept making the same mistake

Three Mondays in a row last month, I explained the same deploy failure to Claude Code. The root cause was identical each time: our production Cloudflare Workers had a memory-cache incoherence issue between distributed instances. Each session, I walked through the same investigation — same files, same logs, same 30-minute trail to the same conclusion.

Claude Code doesn't remember previous sessions. So every Monday morning, I was re-discovering the same bug with my agent from scratch.

I tried the available solutions; none fit:

Tool	What's good	Where it fell short for me
`CLAUDE.md`	Zero setup, official	Flat structure, model ignores parts of it
Mem0	Hosted, easy install	Cloud-only, no "pain memory" concept
Letta	Built into an agent framework	Can't share memory across MCP clients
Zep	Graph-based, strong relationships	Single-client; I also use Cursor and Codex

All good products optimizing for different things. But the one feature I wanted most — a guarantee that I'll never repeat the same mistake — wasn't in any of them.

So I built linksee-memory.

The design: 6 layers, with `caveat` as the hero

linksee-memory organizes memory into 6 explicit layers:

+-- goal           Why are we doing this?
+-- context        Current situation & constraints
+-- emotion        User's mood, tone of the relationship
+-- implementation How we built it (success or failure)
+-- caveat         Pain lessons (forget-protected)
+-- learning       Growth log & realizations

The key design principle is WHY-first. Other tools store facts ("we use PostgreSQL"). linksee-memory separates the WHY ("we chose PostgreSQL because the workload is OLTP with strict consistency needs") from the WHAT ("connection pool: 20, timeout: 30s").

The caveat layer is special. Entries there are permanently protected from auto-forgetting — even when old memories decay and get consolidated, caveats stay forever. This is how I enforce "never make this mistake again" as a structural property, not prompt discipline.

3 tools, not 8

Early versions had 8 separate tools (remember, update_memory, forget, recall, recall_file, list_entities, consolidate, read_smart). This worked fine in Claude Code where I could teach tool selection via SKILL.md.

But Cursor couldn't tell recall from recall_file. Codex mixed up remember and update_memory. Too many tools = LLM tool selection breaks down.

v0.7 unified everything into 3 tools:

Tool	What it does
`remember`	Create, update, or delete a memory. Mode auto-detected from params.
`recall`	Search memories, get file history, or list entities. Mode auto-detected from params.
`read_smart`	Read a file with chunk-level diff caching.

// Create
remember({ entity_name: "MyProject", layer: "caveat", content: "..." })

// Update (was: update_memory)
remember({ memory_id: 42, content: "updated content" })

// Delete (was: forget)
remember({ forget: true, memory_id: 42 })

// Search (was: recall)
recall({ query: "RLS policy", layer: "caveat" })

// File history (was: recall_file)
recall({ path: "server.ts" })

// Entity overview (was: list_entities)
recall({})

One tool name per intent. Every LLM client handles it correctly now.

The part that surprised me: `read_smart()`

Structured memory is half the tool. The other half is file-diff caching.

Think about what your agent does at the start of every session:

Re-reads package.json
Re-reads your main entry file
Re-reads the config
Re-reads the tests

Each file is maybe 500-2000 lines. Each session, you pay full tokens to re-read all of them. But in most sessions, most of these files haven't changed.

read_smart() fixes this with chunk-level caching:

// First read: full file, chunked and cached
const r1 = read_smart({ path: "src/http-server.ts" });
// -> full content, ~3400 tokens

// Same session, no change: cache hit
const r2 = read_smart({ path: "src/http-server.ts" });
// -> { status: "unchanged", tokens_used: ~50 }

// After editing 2 functions: only changed chunks returned
const r3 = read_smart({ path: "src/http-server.ts" });
// -> only the 2 changed function chunks, ~340 tokens

Chunk boundaries are language-aware:

Code (TS / JS / Python / etc.): AST-based, one chunk per function or class
Markdown: one chunk per h2 / h3 section
JSON / YAML: one chunk per top-level key

Cache keys are sha256(chunk_content). In practice, I see ~86% token reduction on file re-reads.

Concrete example: the caveat that stopped Claude from repeating

Here's a real example of caveat working.

A few weeks ago, for a one-off data migration task, Claude suggested "let's set up a cron job". One-off tasks shouldn't use cron (auth rotation overhead, monitoring cost, retry logic that doesn't match one-off semantics).

I stored one caveat entry:

Don't propose cron for one-off tasks. Alternatives: GitHub Actions workflow_dispatch, or a manual script with a completion notification.

In the 4 sessions before I added that caveat, Claude suggested cron 4 times for one-off tasks.

In the 3 weeks since? Zero.

And because all my LLM clients share the same SQLite file, the caveat also works in Cursor, Codex, and Gemini CLI — not just Claude Code.

Install (2 minutes)

Claude Code

npm install -g linksee-memory
claude mcp add -s user linksee -- npx -y linksee-memory

Cursor

Settings -> Features -> "Model Context Protocol" -> Edit:

"linksee": {
  "command": "npx",
  "args": ["-y", "linksee-memory"]
}

OpenAI Codex

codex mcp add linksee-memory -- npx -y linksee-memory

Gemini CLI

~/.gemini/settings.json:

{
  "mcpServers": {
    "linksee": {
      "command": "npx",
      "args": ["-y", "linksee-memory"]
    }
  }
}

Everything runs locally. SQLite file at ~/.linksee-memory/memory.db. No cloud, no API key, no telemetry. MIT licensed.

Because memory lives in a single SQLite file, it's shared across all MCP clients on your machine. My Claude Code sessions and my Cursor sessions see the same memory.

I'd genuinely love feedback

I've been using this daily for 3+ months, and my results are biased by the fact that I designed it for my own workflow. I'd like to know:

Does the caveat layer actually prevent your agent from repeating mistakes, or am I pattern-matching on one dataset (me)?
How does the chunk cache behave on your codebase? Monorepos, generated code, notebooks — I'd love bug reports.
Is 6 layers too many? Too few? Are there memory types you want that none of these cover?

Open an issue on GitHub, or ping me on X at @ELLECraftsinga1. I respond to everything.

GitHub: https://github.com/michielinksee/linksee-memory
Docs: https://docs.linksee.app

I built an MCP server that helps agents find and orchestrate other MCP servers

michielinksee — Thu, 02 Apr 2026 13:19:35 +0000

The Problem
MCP servers are multiplying fast. There are now MCP servers for accounting (freee), HR (SmartHR), project management (Backlog), messaging (Chatwork, LINE WORKS, Slack), and more — just for Japanese SaaS alone.

But when you tell an agent "create and send an invoice," it has to figure out:

Which MCP handles invoices?
How to combine multiple MCPs for a complete workflow?
Has anything changed since last time?
There's no discovery layer. Every agent starts from zero.

What I Built
An MCP server that searches, combines, and tracks other MCP servers.

npx @kansei-link/mcp-server