DEV Community: Alfredo Izquierdo

One Developer, Five Terminals, Zero Awareness

Alfredo Izquierdo — Wed, 08 Jul 2026 13:43:46 +0000

One Developer, Five Terminals, Zero Awareness

It's 11 p.m. and I have four terminals open.

One is running a Claude Code session on the auth refactor. Another is in a git worktree, rebuilding the tests. A third is reviewing a pull request. A fourth is just… there, waiting, because I know I'll need it in ten minutes. Somewhere in the mix there's a small team of sub-agents fanning out on a migration.

I'm not doing this because I enjoy the chaos. I'm doing it because this is what "productive" looks like now.

If you ship software with AI agents, you already know the feeling. One agent working one task, start to finish, is too slow. So you split the work. You open a second window. Then a third. You spin up a worktree so two branches can move at once. You hand a batch of independent tasks to a fleet of sub-agents and let them run. Parallelism is the only lever left when a single session can't keep up with the size of what you're trying to do.

And it works — right up until it doesn't.

The parallel blind spot

Here's the thing nobody tells you when you start running sessions in parallel: every one of those sessions is an island.

Session A is deep in the auth module. It's been there for twenty minutes, halfway through a refactor, files open, changes uncommitted. Three minutes later, Session B — a completely separate process, in a completely separate terminal — also reaches for the auth module. Not because it's reckless. Because it has no idea Session A exists.

Now you have two agents editing the same code with no knowledge of each other. One overwrites the other's assumptions. A merge conflict blooms out of nowhere. Or worse — no conflict, just two half-finished ideas quietly braided into the same file, and you don't notice until the tests go red for reasons that make no sense.

You lose exactly the time parallelism was supposed to save. That's the trap. The faster you go by splitting work, the more surface area you create for the splits to collide — because none of them can see the others.

I started calling this the parallel blind spot. You added more hands to move faster, and the hands can't see each other.

Memory solves "what happened." This is "what's happening."

If you've used ContextForge, you know it already gives your agents a memory that survives every session — the decisions, the corrections, the constraints, carried from one session to the next so your agent stops forgetting Friday by Monday.

But durable memory answers a question about the past: what happened before. The parallel blind spot is a different question entirely — a question about right now:

Who else is working on this, at this moment, while I am?

Memory is history. This is presence. A session's history tells you what it did yesterday; it tells you nothing about the session running in the terminal next to it this second. No amount of "remember what happened" fixes "I can't see what's happening."

That's the gap. And for a while, it was a gap I only half-noticed — because when it's just you and one terminal, it doesn't exist. It only shows up once you're deep enough into parallel work to get bitten by it.

The comment that named it

Then a reader left a comment on one of my posts that named it exactly.

They pointed out that ContextForge covered the single-session story beautifully — memory that persists — but that the multi-session case was wide open. When you run two or more agents against the same project, there's no live shared-state layer. Nothing that lets Session A raise a hand and say "I've got the auth module right now" so Session B doesn't walk into it.

Reading it, I felt that particular sting of good feedback: the obvious thing you somehow hadn't let yourself see. They were right. Memory across sessions was solved. Awareness between sessions wasn't. It had a name now, and once something has a name, you have to go build it.

So I did.

Session Presence: a live "who's here" for your agents

The new feature is called Session Presence, and the whole idea fits in one sentence: your parallel sessions can now see each other in real time.

Here's how it actually works, because the best part is how little you have to do:

It registers itself. Every Claude Code session (or Cursor, or any MCP client) automatically announces itself as live the first time it does anything. You don't run a command. You don't think about it. The moment a session starts working, it's on the board.
It stays honest. Each session sends a quiet heartbeat every couple of minutes. So the list is always live sessions — not a graveyard of things you closed hours ago. A session that dies without saying goodbye simply ages off on its own.
It disappears cleanly. When you close a session, it's removed at once — even in the split second before the process is fully killed. No stale ghosts lingering on the list.

On top of that, three small tools give the agent a voice:

session_update — "I'm working on the auth module." One session declares what it's focused on.
session_list — "Who else is on this project right now, and what are they doing?"
session_end — "I'm done here."

And you don't have to memorize any of that. You just talk. Ask your agent, in plain English, "is anyone else working on this project right now?" — and it checks the board and tells you: yes, another session has been on the auth module for the last few minutes; you might want to steer clear.

One more thing that matters: it's advisory, not a lock. Presence is a "busy" sign on a door, not a key that bolts it shut. It doesn't stop you from doing anything — it just makes sure you're never doing it blind. You stay in control; you just get to make the call with the full picture instead of half of it. And it's scoped to the project you're actually in, so a busy afternoon across five different repos doesn't turn into noise — you see the sessions that can actually collide with yours, and nothing else.

What it feels like in practice

Back to that 11 p.m. scene. Two sessions, both drifting toward the auth module.

With presence, the second one asks the board before it dives in. It sees that Session A is already there, focused on exactly that. So instead of colliding, it picks up the tests — the other thing on the list that nobody's touching. No conflict. No braided half-ideas. No 30 minutes lost untangling a mess that never needed to happen.

That's the whole win. It's not flashy. It's the quiet difference between five sessions working near each other and five sessions working blind next to each other.

Try it this week

If you're already running parallel sessions — worktrees, agent teams, three terminals before lunch — this is for you.

Update to the latest ContextForge MCP. Session Presence ships in the current release and works with Claude Code, Cursor, and Copilot through MCP — so even if you bounce between all three tools in a day, your sessions still see each other.
Ask "who else is here?" at the start of a session. Make it the first thing you do when you sit down, the same way you'd glance around an office before taking a desk.
Say what you're working on when you switch tasks. One sentence — "I'm on the payments flow now" — and every other session can see it.
Already have a CLAUDE.md? Re-running npx contextforge-mcp init is safe, it's idempotent per section. It checks for a hidden marker and only appends what's missing. Your existing content and your own edits stay exactly as they are; it just adds the new "Session Presence, Coordination Rules" block if it isn't there yet.

It's on the free tier. Five minutes to set up. And if you've ever lost an evening to two of your own agents fighting over the same file, you already know exactly what it's worth.

Parallelism without awareness isn't speed. It's a collision waiting to happen.

Give your sessions a way to see each other.

Give Your AI Coding Agent a Memory That Survives Every Session

Alfredo Izquierdo — Fri, 26 Jun 2026 22:02:27 +0000

Open a new session with Claude Code, Cursor, or Copilot and it has no idea what you were doing yesterday. Your stack, your decisions, the bug you spent an hour explaining — gone. So you re-explain. Again.

The root cause is simple: your AI's memory only lasts one conversation. Close the terminal and it's wiped.

ContextForge fixes that. It's an MCP server that gives any AI agent a permanent, searchable memory that carries across every session and every project. Below is the full setup — it takes three commands.

The walkthrough uses Claude Code as the example, but the same setup works for Cursor, ChatGPT, Claude Desktop, Windsurf, and GitHub Copilot.

📺 Watch the full walkthrough

▶️ Watch the setup on YouTube →

The setup, in three commands

1. Install the MCP server

npm install -g contextforge-mcp

2. Connect it to your editor — the wizard asks for your API key (grab a free one at contextforge.dev):

npx contextforge-setup

3. Initialize your project — this is the step people skip:

npx contextforge-mcp init

That last command writes a small rules file (CLAUDE.md for Claude Code, .cursorrules for Cursor) that tells your AI to use ContextForge for memory. Without it, your agent silently falls back to its built-in memory and ignores ContextForge — even though the server is connected.

The payoff

Once it's connected, you just talk to your agent like normal:

"Remember this is a todo app with Next.js and Supabase, deployed on Vercel. Save it to memory."

It stores that as a real, searchable memory — not in the chat, in a permanent store. Plant a couple of tasks the same way, then close the terminal and open a brand-new session:

"Let's start working on this project. What do I have pending?"

And it knows. New session, clean slate, and your agent already has your stack, your context, and your open tasks — no re-explaining. You can browse everything in the dashboard, organized by project.

Try it

ContextForge has a free tier — no credit card. Give your AI a memory that actually sticks:

👉 Get started at contextforge.dev

Works with Claude Code, Cursor, ChatGPT, Claude Desktop, Windsurf, and GitHub Copilot.

Your CLAUDE.md Is Lying to Your Agent — Why a Stale Instructions File Is Worse Than None

Alfredo Izquierdo — Tue, 23 Jun 2026 14:20:31 +0000

Your CLAUDE.md Is Lying to Your Agent

An empty CLAUDE.md is honest.

When the file isn't there, your agent does the sensible thing: it looks around. It reads the code. It asks you a question. It admits, in its quiet way, that it doesn't know yet — and so it goes and finds out.

A stale CLAUDE.md does the opposite. It walks into the room with total confidence and tells your agent something that used to be true. And your agent believes it. Why wouldn't it? You wrote it down. You committed it. It's the context file.

That's the part nobody warns you about. We talk about CLAUDE.md like it's free insurance — write it once, and your agent stops doing dumb things. Nobody mentions that the file has a half-life, and that a decayed instruction doesn't fall silent. It keeps talking. It just starts being wrong.

The Friday I got betrayed by my own notes

Let me tell you how I learned this, because I learned it the embarrassing way.

A few months ago I spent a Friday afternoon cleaning up a project. You know the kind of afternoon — the satisfying one. I pulled authentication out of a fat utils.ts file and gave it its own home. I renamed a module that had been bugging me for weeks. I deleted a helper we'd stopped using and replaced it with something cleaner. I committed all of it, closed the laptop, and felt like a responsible adult.

What I did not do was open CLAUDE.md. It was three weeks old. It still said "auth lives in utils.ts." It still named the module I'd just renamed. It still recommended the helper I'd just deleted.

Monday morning, I asked my agent to add a small feature near the auth flow. And it did exactly what I'd told it to do — back in a version of the project that no longer existed. It went looking for auth in utils.ts. It reached for the dead helper. When it couldn't find them, it didn't stop and ask. It reconstructed them. It rebuilt a little ghost of last month's codebase, confidently, because the one document I'd told it to trust said that's how things were.

The model wasn't broken. The reasoning was fine. It followed its instructions perfectly. The instructions were just lying to it — and I was the one who'd written the lie and signed it.

The half-life of a CLAUDE.md

Here's the uncomfortable truth about that file: it starts dying the moment you save it.

A CLAUDE.md is a static photograph. Your codebase is a moving thing. Every commit, every rename, every "actually, let's not do it that way" pulls the real project a half-step away from the photograph. None of those moves announce themselves to the file. The file has no idea Friday happened.

So the gap opens quietly. Day one, the photo is perfect. Week two, a couple of details are off. Month two, whole paragraphs describe a project that's been refactored out from under them. And the worst part is that it still reads fine. Stale documentation doesn't look stale. It looks authoritative. That's exactly what makes it dangerous.

This is the same disease I wrote about in context rot — more text doesn't mean more truth. A longer CLAUDE.md isn't a more reliable one. It's just a bigger surface for the rot to spread across.

Why "wrong" is worse than "empty"

We treat having some context as strictly better than having none. With static files, that math is backwards.

Anthropic's own data tells you why. The biggest single category of agent failure isn't creativity or hallucination — it's consistent wrong interpretation: the agent making the same incorrect assumption, every single run. A stale CLAUDE.md is a factory for exactly that failure. It hands the agent a wrong assumption and stamps it "official." Now the mistake isn't a one-off. It's load-bearing. Every session starts from the same wrong place and marches confidently in the same wrong direction.

Compare the two failure modes honestly:

No file: the agent is uncertain, so it explores, asks, and checks. Slower, occasionally annoying — but it self-corrects.
Stale file: the agent is certain, so it doesn't check. It just executes. Fast, smooth, and wrong in a way you won't catch until it's three commits deep.

Uncertainty is recoverable. Misplaced confidence is the thing that ships the bug.

The three ways it rots

It's never dramatic. It's always small. In my experience it's almost always one of these three:

The map stops matching the territory. You move a file, rename a module, restructure a folder. The CLAUDE.md still points at the old address, so your agent keeps knocking on a door that isn't there — and then builds a new door rather than admit it's lost.
A reversed decision keeps giving orders. "We use library X." Three weeks later you rip out library X because it didn't support your runtime. Nobody tells the file. It keeps cheerfully recommending the thing you spent a whole afternoon removing.
Yesterday's conventions outlive themselves. The rule that was right when it was just you becomes wrong the moment a teammate joins, or the project grows past the shape it had when you wrote it down.

Each one is tiny. Each one is invisible until an agent acts on it. And the friction of keeping all three in sync, by hand, forever — that's the actual problem.

"Just keep it updated" is not a plan

I know what you're thinking, because I thought it too: fine, I'll just keep the file current.

You won't. Not because you're lazy — because nobody does. Documentation that has to be hand-updated drifts out of date in every team that has ever existed, and a CLAUDE.md is documentation wearing an agent's clothes. The instinct to write down what you learn is exactly right. The mechanism — a flat file you have to remember to edit at the precise moment your hands are busy doing the thing that just made it wrong — is what's broken.

This is the same gap I keep circling back to in why your AI forgets everything: the problem was never that the agent had no memory. It's that the memory lived in a place that couldn't keep up with you. A static file can't keep up. It was never built to.

What living memory actually looks like

The fix isn't a better file. It's a different shape entirely.

Imagine memory that updates from the work instead of from your discipline. You correct the agent once — "auth moved, it's in its own module now" — and that correction sticks, surfacing the next time it's relevant instead of waiting for you to remember to go edit a paragraph. The renamed module updates because you renamed it, not because you also opened a markdown file afterward. The reversed decision stops giving orders the moment you reverse it.

And because it isn't trapped in one tool's config file, it follows you. Claude Code on Monday, Cursor on Tuesday, Copilot for the PR review on Wednesday — same memory, same truth, no three-way drift between three stale files telling three agents three different versions of last month.

That living layer is what I built ContextForge to be: a memory that plugs into Claude Code, Cursor, and Copilot over MCP, holds your corrections and decisions in one place, and surfaces the right one at the right moment instead of handing your agent a month-old photograph and calling it context.

You don't have to use mine. You can roll your own. What you can't do — what I tried to do, on that Friday, and failed — is keep a static file honest by sheer force of will.

What to do this week

Three things, and you can start the first one in the next ten minutes:

Audit your CLAUDE.md for lies. Open it and read it like a stranger. Every path, every "we use," every convention — is it still true today? Count the ones that aren't. That number is how often your agent has been confidently misled this month.
Split the durable from the decaying. Some things in that file are genuinely stable (the project's purpose, hard constraints). Some are just state that caches the current shape of the code — and state belongs somewhere that updates itself, not in a file you have to babysit.
Try a memory layer. ContextForge has a free tier that plugs into Claude Code, Cursor, and Copilot via MCP. Five minutes to set up. Your corrections start sticking instead of rotting.

An empty CLAUDE.md admits it doesn't know. A stale one pretends it does — and your agent can't tell the difference.

Stop asking your agent to trust a photograph. Give it something that can actually keep up with you.

The Week Two Problem: 60% of AI Agent Failures Are Not the Model's Fault

Alfredo Izquierdo — Tue, 26 May 2026 16:16:31 +0000

60% of AI agent failures are not from the model.

Read that again. Not from the model. And almost every dev I talk to is still debugging the model — swapping Sonnet for Opus, retuning prompts, comparing Claude Code vs Cursor vs Codex.

LangChain's 2026 production report found that the majority of agent failures trace to the harness, not the LLM. Anthropic's own data shows 71% of Claude's failures come from "consistent wrong interpretation" — the same incorrect assumption, every run.

If you've ever shipped an AI agent, watched it work for a week, then watched it break in week two on something you already fixed — you've lived this. It's not your prompts. It's not the model. Your agent has no memory of what happened on Friday.

The Week Two Problem

There's a pattern that anyone running real AI agents recognizes:

Demo: flawless. The room claps.
Week one: holds up. You're a believer.
Week two: the agent makes the same mistake you corrected on Friday. Then it makes it again on Wednesday. Then on the following Monday.

I started calling this the Week Two Problem because that's when the gap shows up — between "works in a demo" and "actually survives in production." The first week, you're still tuning. The second week, the tuning starts un-tuning itself.

The strange part: nothing changed. Same model. Same prompts. Same tools. The only thing that drifted was the agent's awareness of what already happened.

The Data Nobody's Talking About

I've spent the last month reading every "my agent broke" thread I could find — Reddit, HN, DEV.to. The same three data points keep showing up:

1. LangChain 2026 production report: Around 60% of agent failures trace to the harness, not the model. Cold boots, lost identity across sessions, poor sub-agent briefing — all the things the LLM is not responsible for.

2. Anthropic's own evals: 71% of Claude's failures in production come from "consistent wrong interpretation" — making the same incorrect assumption across every run. If the agent had memory of "we already tried that, here's why it doesn't work," that whole bucket disappears.

3. The 21,000-token typo fix: A Claude Code agent was logged consuming over 21,000 input tokens to make a one-line spelling correction. Why? Because every run re-loads the same context from scratch, including the things the agent already learned and forgot. Reddit practitioners report 70–120x cost spikes on multi-step agents for exactly this reason.

These are not three problems. They are one problem wearing three costumes. The harness doesn't remember.

Why a Bigger Context Window Won't Save You

The instinct, when an agent forgets, is to give it more room to remember. Bigger context window. More tokens. Stuff the whole project into the prompt.

I wrote about why this fails — it's called context rot, and it makes the problem worse, not better. A bigger haystack doesn't help you find the right needle. It just gives the model more wrong needles to confuse the right one with.

If you've been told "the new model has a 2M token context window, so memory is solved," that's the same vendor selling you the same problem with more pages.

Memory ≠ Context

Here's the distinction that matters, and almost no one names it cleanly:

Context is what your agent sees on this turn. The current prompt, the current tools, the current scrollback. It dies when the session ends.
Memory is what survives the session. What the agent learned on Tuesday and can recall on Friday. What it tried, what failed, what you corrected, what the constraint actually was.

A bigger context window grows the first thing. It does nothing for the second.

This is why Claude's built-in memory feature, Cursor rules, .cursorrules, and CLAUDE.md files are all half-solutions. They store some memory in some place, often tied to a specific tool. The moment your workflow crosses tools — Claude Code Monday morning, Cursor Tuesday afternoon, Copilot for the PR review — the memory doesn't follow. So you end up with three different agents with three different partial views of the same project, all making the same wrong assumption from earlier this week.

This is the same pattern I described in "Why Your AI Coding Assistant Forgets Everything" — every session starts from zero, no matter how many notes you keep on the side.

That's the Week Two Problem in slow motion.

The Missing Harness

What would a real harness look like?

It would store corrections once. When you tell the agent "don't use that library, it doesn't support our Node version," that constraint persists — across sessions, across tools, across the entire team. The next time any agent on any tool reaches for it, the memory layer says no.

It would recognize patterns across sessions. Not "remember everything verbatim" — that's just context rot in a new bottle. But "remember the decisions and the constraints and the things-that-did-not-work." The model handles reasoning. The harness handles continuity.

It would reduce token spend, not increase it. Because the agent stops re-discovering things it already learned. The 21,000-token typo fix becomes 1,200 tokens because the agent already knows the file's conventions, the recent corrections, the patterns that matter.

This is the layer I built ContextForge for. It's a memory layer that plugs into Claude Code, Cursor, Copilot, and any MCP-compatible client. Corrections in one place. Persistence across sessions. Relationship-aware recall so the right memory surfaces at the right moment, not all of them at once.

It's not the only way to solve this. You can hand-roll a memory layer. You can build your own embedding store. You can chain together vector DBs and tool definitions. What you cannot do — and what nine out of ten teams are still trying to do — is keep debugging the model and expecting the failures to stop.

What to Do This Week

If you've been losing time to week-two failures, three things you can do right now:

Audit one agent. List every correction you've made in the last 14 days. How many were persisted? How many will you have to make again next week? That number is your harness debt.
Separate context from memory in your head. Context is the turn. Memory is the relationship. They are not the same thing, and the same tool rarely solves both.
Try a memory layer. ContextForge has a free tier that plugs into Claude Code, Cursor, and Copilot via MCP. Five minutes to set up. Your agent stops forgetting Friday by Monday.

The Week Two Problem isn't a model problem. It never was.

Stop debugging the model. Start asking what your harness remembers.

Skills Were Dead Prompts. Routines Made Them Alive.

Alfredo Izquierdo — Thu, 14 May 2026 16:45:46 +0000

A few weeks ago I shipped Skills — a way to save AI prompts as reusable templates inside ContextForge, so my best prompts wouldn't keep dying in a Notion page nobody opens.

It worked. I stopped losing them.

Then I noticed something worse.

I had a Skill that drafts marketing copy every time we ship a feature. Another that summarizes my weekly progress. Another that generates LinkedIn posts. They were all sitting there, clean and named, in a tab I'd open every Monday morning and slowly click "Run" on like a factory line.

That's when it hit me: I built a library, not an assistant. Skills were just dead prompts with a database row.

So I built Routines.

What a Routine actually is

A Routine is a Skill on a cron expression. That's it.

You pick a Skill (the prompt template). You pick a schedule — daily, weekly, monthly, or any 5-field cron you write yourself. You pass the input variables. You hit Create. From then on, ContextForge fires the Skill on schedule, forever, until you pause or delete the Routine.

Skill:        "Write a LinkedIn post about {{topic}} in my voice"
Routine:      Daily at 9am Chicago, topic = "shipping in public"
Result:       A fresh draft in my execution history every morning,
              ready to copy-paste and post.

It sounds trivial because it is trivial as a user experience. The complexity is hidden, which is the point.

The first design was wrong

My first instinct was Postgres-native: use pg_cron (Supabase has it built-in) plus pg_net to make outbound HTTP calls every minute. Schedule lives in the database, no extra infra, beautiful.

I started writing it. Then I hit a wall I'd already climbed once.

ContextForge has two auth models. Dashboard users authenticate with a Supabase session JWT. MCP clients (Claude, in particular) authenticate with API keys we verify ourselves inside edge functions. Both eventually call the same skill-execute function via a "service-role bridge" — the function probes the database with the service role key, then trusts an x-cf-user-id header for the actual user identity.

This bridge took me two weeks to get right when I shipped Skills. I documented it in CLAUDE.md. I have memories about it. It's load-bearing.

pg_cron would have meant recreating it inside Postgres functions. PL/pgSQL talking HTTP to my own edge functions, replaying the auth dance, debugging it without proper logs. I'd be writing the same nasty integration twice.

So I pivoted. Vercel Cron pings a Next.js API route every minute. The route queries for due Routines, then fires each one against the same skill-execute edge function the dashboard already calls. Same path, same headers, same auth bridge. One source of truth for "running a Skill" — manual, MCP, scheduled, all go through the same door.

Sometimes the right architecture is the one that doesn't make you rewrite a thing you already trust.

The unglamorous parts

Three things bit me harder than the design:

1. Hobby plans don't allow per-minute cron.

I shipped to Vercel. The deploy failed instantly:

Hobby accounts are limited to daily cron jobs. This cron expression (* * * * *) would run more than once per day. Upgrade to Pro.

Pro is $20/month. I had to make a decision: pay it, downgrade the feature to daily-only, or use an external cron service (cron-job.org, free, hits my endpoint with a shared secret). I picked Pro. The math is simple — 5 Premium users at $15/month covers Pro + Supabase Pro, and the feature is worth nothing if I cripple it to daily-only just to dodge $20.

2. CRON_SECRET hates whitespace.

The first deploy after Pro upgrade failed with:

The CRON_SECRET environment variable contains leading or trailing whitespace, which is not allowed in HTTP header values.

I had copy-pasted the secret from a terminal. It had a trailing newline. Five minutes of "why" before I realized.

3. The Premium gate I wired in stripe-webhook was missing the Routines limit.

I added a max_routines column on organizations. Updated the dashboard to gate behind it. Tested local with a flipped plan column — perfect. Deployed.

Then a paying Premium user opened Routines and saw the upgrade banner. Their plan column said premium, but max_routines was still 0.

Reason: the Stripe webhook handler that bumps plans had a PLAN_LIMITS constants object. It set max_projects, max_spaces, max_collaborators, etc., — but I'd added max_routines to the database without adding it to that constants file. Subscribers got upgraded everywhere except the column my new gate checked.

One-line fix in _shared/plan-limits.ts plus a backfill migration:

UPDATE organizations SET max_routines = 999 WHERE plan = 'premium';
UPDATE organizations SET max_routines = 0   WHERE plan IN ('free', 'pro');

Embarrassing. Also the kind of bug that only ships if you have actual paying users hitting it, which is its own kind of milestone.

What it looks like in practice

The dashboard side is dead simple. Open any Skill-enabled project, click Routines, click + New Routine. The form is one screen:

Pick the Skill
Name the Routine
Pick a preset (daily, weekly, etc.) — the cron expression auto-fills, but you can override
Pick a timezone (defaults to your browser's)
Paste your input params JSON

Hit create. You land on the Routine detail page with a ▶ Run now button (fires immediately, ahead of schedule), a Pause/Enable toggle, execution history, and a Danger Zone with delete.

Every fire writes a row to the audit log: status, output, tokens used, cost. Click any row to expand and see the rendered prompt + final output. Same component the manual Skill runs use — Routines didn't get their own special view, they get a trigger_type=scheduled tag and they're one query away from filtering.

Schedule it from Claude

This is the part I'm most proud of.

The MCP exposes seven new tools — routines_list, routines_get, routines_create, routines_update, routines_toggle, routines_run_now, routines_delete. From inside any Claude session connected to ContextForge, you can say:

"Schedule the LinkedIn Post skill to run every weekday at 9am Madrid time."

Claude picks the right skill, infers schedule_preset = "daily", fills the cron expression, sets timezone = "Europe/Madrid", and creates the Routine. You never touch the dashboard.

This matters more than it sounds. The pitch for ContextForge has always been "let agents act on your memory, not just read from it." Routines is the first feature where Claude can schedule its own future work — close a loop the agent owns, end-to-end.

What's next

Skills + Routines is the start of what I'm calling the agentic OS for context. A library of named prompts (Skills), the ability to run them automatically (Routines), and an agent (Claude via MCP) that can create both for you on demand. The next layer is chains — Routines that fire other Routines, conditional triggers, "if this Skill output contains X, fire that Skill with Y."

But that's the next article.

For now: I have 26 users on the free plan. None of them have Routines yet. But the day one of them upgrades to Premium and starts seeing AI-generated marketing copy show up in their notifications at 9am every Monday, this whole thing pays for itself.

If that sounds useful — give ContextForge Memory a try. The Skills tier is free. Routines is the upgrade.

ContextForge Memory is a persistent memory layer for AI coding agents. Built on Supabase + Next.js. BYOK for all LLM operations. Docs · GitHub · Twitter

I Built Skills Because My Notes App Was Full of Dead Prompts

Alfredo Izquierdo — Tue, 12 May 2026 13:49:13 +0000

Open your Notes app right now. Search "prompt."

Count what comes up.

If you're anything like the 200+ developers I've talked to in the last six months, the answer is somewhere between "more than I want to admit" and "oh god I forgot about that one."

You have a folder of prompts that work. The one that writes your release notes the way your team actually wants them. The one that turns a messy PR into a clean changelog entry. The one that drafts customer emails in your tone. The standup summarizer. The weekly recap generator. The "explain this code in plain English" template that takes you 12 tries to get right and then lives forever in a screenshot.

None of them run.

They're just text. Pasted into ChatGPT every time you need them. Copy. Paste. Edit. Paste. Edit again. Wait for output. Copy the output. Paste it where it actually needs to go.

This is the prompt graveyard, and you're not the only one who has one.

The Hidden Cost Of "I'll Just Paste It Again"

Here's the cost nobody talks about.

Every time you re-type or re-paste a prompt, something drifts. You change a word. You forget a constraint. You leave out the example you added last time that made the output good. You think you're using "the prompt that works" — but you're actually using "the prompt that worked the first time, three weeks ago, before I tweaked it twice."

By the time you've used a good prompt ten times, you've used ten slightly different prompts. The output quality wobbles. You start blaming the model. "GPT-5 is getting worse," you say. The model didn't get worse. Your prompt did, and you didn't notice because there was no version of it that was actually fixed in place.

This is the same problem we used to have with shell scripts before we put them in a repo. The same problem we had with email templates before tools like Front and Mixmax. The same problem we had with code snippets before Gist existed.

The work was real. The artifact was real. The home for the artifact was a chat history and a Notes app — neither of which were built to be the home for it.

The Other Cost: Context Lives Where The Work Lives

There's a deeper problem.

The prompts you'd want to save aren't generic. They're project-specific. The release note prompt is good because it knows your product's voice. The PR summarizer is good because it knows your codebase's conventions. The customer reply template is good because it references your refund policy.

When that prompt lives in your Notes app, it lives away from the project. Your teammate can't find it. Your future self can't find it. Six months from now when you need it, you'll search Slack DMs and ChatGPT history for forty minutes and rewrite it from scratch because that's faster than the search.

The prompts that are most valuable are the ones most tied to a specific project. And those are exactly the ones that have nowhere to live.

What A Real Home For Prompts Looks Like

If we built it from scratch, knowing what we know now, what would it look like?

A prompt would live inside the project it belongs to, the same way a README does.
It would have a name and a description so you and your team can find it.
It would be a template, not a paste — with placeholders you fill in at run time.
It would have version history so the prompt that worked last week doesn't quietly become a different prompt this week.
It would run on your own LLM key so the output stays yours and the cost goes through your account, not someone else's.
It would keep a log of every run — input, output, tokens, cost — so you can actually see whether your prompt is getting better or worse over time.
It would be callable from your AI agent so Claude or Cursor or Copilot can run it for you without you having to copy-paste yet again.

This is the shape of the thing. We just shipped it.

Meet Skills

Skills are reusable AI prompts that live inside one of your ContextForge projects.

Each Skill has:

A name and description — visible in your project's Skills tab
A prompt body with {{variables}} you substitute at run time
A provider and model — Anthropic Claude or OpenAI GPT, your pick
An optional save target — auto-save each run's output to a knowledge space
An execution history — every run, with input, output, tokens, cost, and timestamp

You write the prompt once. You name it. You run it from the dashboard with one click, or from Claude via MCP with one sentence. You stop pasting.

Here's what one of my own Skills looks like.

Name: Feature Announcement Pack
Provider: OpenAI / gpt-5-mini
Body:
  You are a developer-marketing assistant for ContextForge Memory.
  A new feature just shipped:
    FEATURE: {{feature}}
    WHAT IT DOES: {{what_it_does}}
    WHO BENEFITS: {{audience}}
  Produce 4 outputs in this exact order:
    ## 1. Tweet — under 280 chars, one emoji, developer voice
    ## 2. LinkedIn post — 3 paragraphs, confident but humble
    ## 3. Changelog entry — Title / Summary / What's new / Why it matters
    ## 4. Docs blurb — 2 paragraphs, plain English, no marketing fluff

When I ship a new feature, I open the Skill, paste this into the input panel:

{
  "feature": "Skills",
  "what_it_does": "Save reusable AI prompts as named, versioned templates inside a project.",
  "audience": "developers tired of re-typing prompts"
}

Click Execute. Five seconds later I have a tweet, a LinkedIn post, a changelog entry, and a docs blurb — all in my voice, all consistent with last week's announcement, all auto-saved to my Content Marketing space for review.

Here's me building and running this exact Skill in under 3 minutes:

[[YOUTUBE]]

Next week, when I ship the next feature, the only thing that changes is the JSON.

BYOK, Audit Log, And Why That Matters

Two things people ask first:

"Does ContextForge see my prompts and outputs?"

Your prompts and outputs live in your project. They're scoped by RLS to your organization. Nobody else can read them. We don't model-train on them. We don't store them off your row.

"Whose LLM key is being used?"

Yours. You add your Anthropic or OpenAI key to your project's settings, and Skills calls your account directly. We don't mark up tokens. We don't have a "ContextForge LLM credits" SKU. The dashboard shows the estimated cost of every run in USD so you can keep an eye on spend, but the bill goes from OpenAI/Anthropic to you, not through us.

The audit log is the third piece. Every run is recorded — successful or failed — with tokens, cost, the exact input params, and the model's output. You can click any row to expand it and see exactly what went in and what came out. If a Skill starts producing worse output, you can compare runs side by side and see where it drifted.

This is the part that's hard to do on your own. Even if you save your prompts in a Notion doc, you don't have a record of every time you ran them and what came out. That record is what turns prompts from craft into engineering.

The MCP Angle

There's one more piece, and it's the part that closes the loop.

Skills are exposed as MCP tools. That means Claude itself can run your Skills. Six tools are shipped: skills_list, skills_get, skills_create, skills_update, skills_run, skills_delete.

In practice, that looks like this:

"Run my Feature Announcement Pack skill for feature 'Routines' with what_it_does='schedule any Skill on a cron expression' and audience='devs who want cron for AI'"

Claude calls skills_run, the LLM does the work against your key, the run is logged in the same audit log as your dashboard runs, and the output comes back to your conversation.

You stop pasting. You stop re-typing. You start composing.

What This Replaces

If you've been using:

A Notes app for prompts → Skills replaces it. Versioned, executable, findable.
ChatGPT custom GPTs for personal prompts → Skills is the project-scoped, BYOK, no-vendor-lock version.
A bookmarked Claude conversation → Skills runs the same prompt without you having to open that conversation and scroll.
A doc full of "useful prompts" that nobody on your team actually opens → Skills lives next to the project, in the tool the team is already in.

Try It

If you've got a prompt you've been pasting into ChatGPT this week — the daily standup one, the customer reply one, the PR summarizer, the one you whisper to Claude every Monday morning — that prompt has a home now.

Open ContextForge → pick a project → Skills
Click New Skill
Paste the prompt. Replace your variable parts with {{placeholders}}.
Run it.

The prompt graveyard ends today.

→ Skills documentation
→ Get ContextForge

Your AI Is Drowning in Its Own Context — Why Longer Conversations Make It Worse

Alfredo Izquierdo — Tue, 05 May 2026 14:58:53 +0000

You know the feeling.

You started the conversation with your AI feeling great. It was helpful. It got you. You were on the same page. An hour in — maybe two — something quietly shifted. It started suggesting things you'd already ruled out. It forgot the tone you agreed on at the start. It told you a story you told it twenty minutes ago, like it was new information.

You didn't change anything. The AI didn't change. The conversation just... went somewhere bad.

If you've ever felt this — and almost everyone using AI has, whether you're writing a book, planning a wedding, building a business, learning something new, or yes, coding a project — you've met context rot. And no, the answer isn't a smarter AI or a longer "memory window." Most of the fixes you'll read about are solving the wrong problem.

What's Actually Happening

Imagine asking a friend to help you with something. The first ten minutes are great — they're focused, they remember what you said, they ask good follow-ups.

Now imagine that same friend, three hours later, after listening to everything you've said all afternoon. They're tired. They're mixing up details. They keep referencing something you mentioned an hour ago that doesn't apply anymore. They're not getting worse at their job — they're just buried under everything you've told them.

That's what's happening to your AI in a long conversation.

The longer it goes, the more it has to keep track of. Old questions. Drafts you abandoned. Decisions you reversed. Files you replaced. Tone you adjusted. By the time you're deep into the session, the AI is sifting through a pile of things you've said — and pulling up the wrong ones.

A 2026 developer survey found that 66% of people using AI tools say their biggest frustration is that the output is "almost right, but not quite." That "almost right" almost always shows up in the second half of a long session. Not in the first.

Why a Bigger "Memory" Doesn't Fix It

Every few months, an AI company announces a bigger context window — now your AI can hold a whole book in its head! A whole project! A whole year of conversation!

It sounds like the answer. It isn't.

Imagine handing that tired friend the entire transcript of your afternoon and asking them, "okay, now please remember what mattered." That's not better. It's the same problem with more pages.

A bigger memory window doesn't help your AI find the right thing. It just gives the AI more wrong things to confuse the right one with. The signal gets buried in the noise. You haven't solved the problem — you've made the haystack bigger.

This is why people keep telling you their AI "got dumber" after a long session. It didn't. It just has too much to look through, and no good way to know what still matters.

Where It Quietly Falls Apart

It contradicts itself. You spent half an hour deciding not to do something — then thirty messages later, the AI suggests it again like the conversation never happened. The decision is in there. It just got buried.

The output looks fine until you look closely. A paragraph that almost says what you meant. A summary that's mostly accurate. A plan that's almost the one you agreed on. Most of it works. The 10% that doesn't is the part that quietly breaks everything downstream.

You start fact-checking more than creating. This is the moment most people don't notice. You're not really collaborating with the AI anymore — you're auditing it. Re-reading. Correcting. Re-explaining. The conversation has become work about the conversation.

By that point, the AI isn't saving you time. It's costing it.

"Just Start a New Conversation" Isn't the Answer Either

So you do the obvious thing. You close the chat. Open a new one. Fresh start.

Except now the AI knows nothing. It doesn't remember the tone you decided on. The story you've been building. The list of things that didn't work. The reason you ruled out the obvious answer two hours ago.

So you re-explain. Again. From the top. Ten minutes in, the new conversation feels great — because it's small. Then it grows. Then it rots. And you're right back where you started.

This is the trap most people are stuck in without naming it. Context rot if you keep going. Amnesia if you don't. Both burn your time.

The Real Fix: Memory That Remembers What Matters

Here's the shift that changes everything.

The problem isn't how much your AI can remember. It's what it remembers, and when.

Think about a really good colleague — the one who's worked with you for years. They don't remember every conversation you've ever had. They don't need to. What they remember is the things that matter: the decisions you've made, the way you like to work, the patterns you fall into, the things that have already been tried.

When something new comes up, they pull the relevant memory — not the whole archive.

That's what your AI is missing. Not a bigger window. A better way to remember.

This is the idea behind tools like ContextForge. Your decisions, your context, the things you've already established — they live outside the conversation. The AI pulls in only what's relevant when it's relevant. The chat stays short. The memory stays long. Context rot doesn't happen, because the conversation never gets bloated with things that don't matter.

It's the difference between an assistant who has read everything you've ever said, and one who actually knows you.

What You Can Do Right Now

You don't need a fancy tool to start fixing this. A few habits help:

Keep conversations short on purpose. When you find yourself scrolling up to remember what was said, that's the rot point. Close it. Start fresh — but bring forward only the decisions, not the full transcript.

Write down what mattered. The valuable part of a long session isn't the back-and-forth. It's the two or three things you actually decided. Capture those somewhere. Even a notes app works.

Don't confuse "long chat" with "real progress." A 60-message conversation isn't more thinking. It's more talking. Most of it is friction.

If you can, give your AI real memory. This is the bigger move. Tools that give your AI persistent memory — across sessions, across days — are how this actually gets solved. Your context becomes something the AI looks up, not something it has to drag through every prompt.

The Takeaway

Context rot isn't a problem with the AI. It's a problem with how we're using it.

We've all been told the answer is "more": more memory, more context, more tokens, more window. But more isn't the answer when the problem is signal getting lost in noise.

The people getting the most out of AI right now aren't the ones with the longest conversations. They're the ones whose AI doesn't have to re-learn them every time — because the important things are already remembered, and only show up when they matter.

A bigger memory just gives you more room to drown. The fix is remembering the right things.

ContextForge gives your AI persistent, curated memory — so what matters surfaces when it should, instead of getting lost in a long conversation. Free tier available at contextforge.dev

Vibe Coding Is a Trap — Why AI-Generated Code You Don't Understand Will Cost You

Alfredo Izquierdo — Tue, 28 Apr 2026 16:55:35 +0000

There's a story going around Reddit that hit me hard.

A guy spent three months building a side project with AI. Everything worked. The app shipped. Life was good. Then he needed to add one small feature — and realized he had no idea how his own code worked.

He ended up deleting 70% of it. Rewrote the whole thing in two weeks. Half the code, zero unnecessary complexity, and for the first time, he actually understood what he built.

The AI hadn't written bad code. It had written code that looked like it came from a big company — layers of abstraction, configuration systems for things that only had one option, wrappers on top of wrappers. All for a project built by one person.

This is what vibe coding looks like when the vibes run out.

What Even Is "Vibe Coding"?

You've probably done it even if you don't know the term. Vibe coding is when you tell AI what you want, it writes the code, you glance at it, it looks fine, and you move on. You're not really reading it. You're going by feel. The vibes are good, so you ship it.

And for a while? It feels amazing. You're building things faster than ever. The AI writes code that looks professional. Everything runs. You feel unstoppable.

Then something breaks.

And you're staring at code that has your name on it but feels like someone else wrote it. Functions you never asked for. Patterns you didn't choose. A project that somehow got huge while you weren't looking.

It's Only Getting Faster

Here's the thing — AI coding tools aren't slowing down. They're getting more autonomous. The latest trend is "agentic coding" — where the AI doesn't just suggest a line, it writes entire features on its own. It creates files, runs tests, fixes errors, all without you touching anything.

That's powerful. But it also means the gap between "what the AI built" and "what you understand" is growing every month.

When AI was just finishing your sentences, you were still driving. Now it's writing whole chapters while you're getting coffee. You come back to 400 new lines of code and think... I guess that's fine?

There's a line from that Reddit thread that stuck with me: "Speed without understanding isn't productivity. It's deferred confusion."

That's it. That's the whole problem.

Where It Falls Apart

When something breaks, you're lost. You didn't write it. You didn't design it. And the AI that did? It doesn't remember either. Every new conversation starts from scratch. So now you're debugging code you don't understand with an AI that doesn't remember building it.

When you need to add something real, you can't. The Reddit guy lived this. His AI built all these clever abstractions for problems he didn't even have. When he needed to add an actual feature, he had to first figure out all the unnecessary complexity the AI created. It was easier to start over.

The understanding disappears overnight. Maybe you spend an afternoon tracing through the code. You finally get it. The next morning? Gone. Not because you're forgetful — but because the AI that helped you understand it yesterday has zero memory of that conversation. You're explaining your own project to it all over again.

So What Do You Actually Do?

Look — nobody's going back to writing everything by hand. AI is too useful. The point isn't to stop using it. The point is to stop blindly trusting it.

Actually read what it writes. I know, obvious. But be honest — how often do you really read the full output before hitting accept? Take 60 seconds. If you can't explain it, don't ship it.

Write down your decisions. Why did you pick this approach? Why not the other one? The AI won't remember tomorrow, and honestly, neither will you. Keep a running log of the important calls.

Give your AI a memory. This is the big one. The core problem with vibe coding is that every AI session starts with amnesia. You explain everything, build something great, close the tab, and tomorrow it's all gone. The AI writes code that contradicts what you decided yesterday because it literally doesn't know yesterday happened.

That's why tools like ContextForge exist. It gives your AI persistent memory — your project context, your architecture decisions, your patterns — all carried across sessions. Instead of your AI writing generic code in a vacuum, it writes code that actually fits what you've already built. Because it remembers what you've already built.

Keep things simple. Small files, clear names, obvious structure. AI works better with less complexity, and so do you when you come back to it later.

The Real Takeaway

That developer didn't have a bad AI. He had a fast AI and no way to keep context between sessions.

Vibe coding isn't evil. The trap is letting AI generate code while you stop paying attention — and while the AI itself forgets everything between conversations.

The people doing well with AI coding right now aren't the fastest shippers. They're the ones who ship fast and can still explain what they built two weeks later.

Speed you can sustain beats speed you can't.

ContextForge gives your AI persistent memory — so it writes code that fits your project, not generic code you'll delete later. Free tier available at contextforge.dev

I Use 3 AI Coding Tools Every Day. Here's How I Keep Them in Sync

Alfredo Izquierdo — Tue, 21 Apr 2026 20:31:09 +0000

Let me tell you about my morning last Tuesday.

I opened Cursor to work on a feature I'd been building all week. I asked it to continue where I left off. It had no idea what I was talking about. So I spent ten minutes re-explaining the architecture, the decisions I'd already made, the files I'd already changed.

Then I switched to ChatGPT to brainstorm a tricky database problem. Same thing. Fresh conversation. No memory of the project. I copied and pasted three messages from yesterday's chat just to get it back up to speed.

By 10 AM, I'd already spent more time explaining my own work to machines than actually doing the work.

Sound familiar?

The Multi-Tool Reality

Here's something most people don't talk about: developers don't just use one AI tool anymore. According to recent surveys, the average developer uses 2.3 AI tools on any given day. Some of us use even more.

And it makes sense. Each tool has its strengths. I use Cursor for writing code inside my editor -- it's fast, it understands the file I'm looking at, and it makes great inline suggestions. I use ChatGPT for thinking out loud -- brainstorming approaches, asking "stupid questions" I'd be embarrassed to ask a coworker, and exploring ideas before I commit to them. And I use Claude Code for the heavy lifting -- multi-file refactors, debugging complex issues, and working across the whole codebase at once.

Three tools. Three different strengths. One massive problem.

None of them know what the others are doing.

The Invisible Tax

Every time you switch between AI tools, you pay a tax. Not in money -- in time, energy, and context.

Think about it. When you move from ChatGPT to Cursor, you're essentially starting a new conversation with someone who has amnesia. You have to re-explain:

What you're building and why
The decisions you've already made
The constraints you're working within
What you tried that didn't work
The conventions your team follows

This isn't a minor annoyance. It's a fundamental workflow problem. And it gets worse the longer your project goes on, because the gap between what you know and what your tools know keeps growing.

I've caught myself keeping a separate document -- a kind of "AI briefing doc" -- just so I can paste it into every new conversation. That's when I realized something was deeply broken.

Why Every Tool Forgets

To understand the problem, it helps to understand why it exists.

Most AI tools are designed around sessions. You start a conversation, you work, and when the conversation ends, it's gone. Some tools save your chat history, sure. But saving a transcript is not the same as remembering.

Remembering means understanding that when you say "the API we discussed yesterday," I should know you mean the Stripe webhook endpoint you were refactoring. It means knowing that your team uses Supabase, that you prefer server components over client components, and that last week you decided to split the monolith into three services.

No single AI tool does this well. And across multiple tools? Forget about it. Literally.

The problem isn't that these tools are bad. They're incredible at what they do. The problem is that they're isolated. Each one lives in its own bubble, with its own memory (or lack thereof), its own context window, and its own understanding of your project.

What "Keeping Them in Sync" Actually Means

When I say I keep my tools in sync, I don't mean I copy-paste between them. That's the duct tape solution, and it doesn't scale.

What I actually mean is that I use a shared memory layer -- a single place where project context lives and that all my tools can access.

Think of it like this. Instead of each tool having its own notebook that gets thrown away at the end of the day, they all share one notebook. When I make a decision in ChatGPT, that decision is available when I open Cursor. When Claude Code refactors a module, Cursor knows about it in the next session.

This changes everything. Instead of spending the first ten minutes of every conversation catching up, I just... start working.

The Pieces That Matter

Not all context is created equal. Over months of working this way, I've found that there are a few categories of information that matter most when syncing between tools:

Project decisions. Why you chose Postgres over MongoDB. Why the auth flow works the way it does. Why you're NOT using GraphQL, even though it seems like you should. These decisions get made once but need to be referenced dozens of times.

Architecture context. The shape of your codebase. Which services talk to which. Where the boundaries are. An AI that knows your architecture can make suggestions that actually fit.

Team conventions. How you name things. How you structure files. Whether you use semicolons. This sounds trivial, but an AI that follows your conventions saves you from constant code review friction.

What you tried that didn't work. This might be the most underrated one. Half the value of experience is knowing what NOT to do. When your tools remember your failed approaches, they stop suggesting them.

How I Actually Do It

I'll be honest with you -- I built a tool to solve this problem. It's called ContextForge, and it started as a personal hack before it became a product.

The idea is simple: ContextForge acts as a persistent memory layer that connects to your AI tools through MCP (Model Context Protocol -- the open standard that Anthropic created and that most AI tools are adopting). You store your project context once, and every tool that supports MCP can access it.

In practice, my workflow looks like this:

I make a decision or learn something important during a coding session
That knowledge gets saved to ContextForge (either automatically or with a quick command)
Next time I open any of my tools -- Cursor, ChatGPT, Claude Code -- the context is there

No copy-pasting. No briefing docs. No "as I mentioned yesterday" followed by five paragraphs of recap.

The first time I opened Cursor after a long ChatGPT brainstorming session and it already knew what I'd decided -- that was the moment I knew this approach was right.

What Changes When Your Tools Remember

The shift is subtle at first, but it compounds.

You stop repeating yourself. This alone saves 15-20 minutes a day. Multiply that across a week, a month, a quarter.

Your tools give better suggestions. An AI that knows your project gives answers that fit your project. Not generic Stack Overflow answers -- specific, contextual ones.

You switch tools without friction. The "warm-up tax" disappears. Cursor, ChatGPT, Claude Code -- they all start from the same shared understanding.

You build momentum. Instead of losing context every time you close a tab, knowledge accumulates. Your tools get smarter about your project over time, not dumber.

And maybe most importantly: you feel less alone. There's something genuinely reassuring about opening a tool and having it say, essentially, "I remember. Let's keep going." It turns AI from a stranger you have to brief into a collaborator that grows with your project.

The Bigger Picture

We're at a weird moment in software development. The tools are more powerful than ever, but the way we use them is still fragmented. We jump between contexts, re-explain ourselves, and lose knowledge at every seam.

I don't think this is permanent. The ecosystem is moving toward shared context. MCP adoption is accelerating -- 70% of major SaaS platforms already support it. The idea that your tools should know you and know your project is becoming obvious.

But you don't have to wait for the future to arrive. The pieces are here now. You just have to connect them.

I Love Obsidian. But My AI Can't Use It.

Alfredo Izquierdo — Tue, 14 Apr 2026 19:12:01 +0000

I have over 800 notes in Obsidian. Architecture decisions from two years ago. Meeting notes I forgot I wrote. Debugging logs that saved me more than once. Random 2am ideas that somehow became real features.

Obsidian is my second brain. I genuinely love it.

But here's the thing that's been bugging me for months: every time I open Claude or Cursor to work on something, none of that knowledge exists. My AI has no idea what's in my vault. It doesn't know about the design doc I spent a whole afternoon writing. It doesn't remember the bug I already solved last Tuesday.

I start from zero. Every. Single. Time.

And honestly? That started to feel like a waste.

The Moment That Made Me Think About This

A few months ago I was debugging an auth issue. I knew — I knew — I had written notes about our authentication flow. Token refresh logic, edge cases we'd hit before, the whole thing. It was all in Obsidian, neatly tagged and linked.

But I was in Claude Code. And Claude had no idea any of that existed.

So I did what I always do: I opened Obsidian, searched for the right note, read through it, copied the relevant parts, pasted them into the chat, and gave Claude the context it needed.

It worked. But it took me 15 minutes to do what should've been instant.

And that's when I thought — wait. Why am I the middleman between my notes and my AI? Isn't the whole point of AI to do this kind of thing for me?

Obsidian Is Great. This Isn't About Obsidian.

Let me be really clear: Obsidian is one of the best tools I've ever used.

Local-first. Markdown files I own forever. Links between ideas. A graph view that actually makes me feel like I have my life together. The plugin community is incredible.

For thinking, writing, and organizing my thoughts — nothing comes close.

The problem isn't Obsidian. The problem is that Obsidian was built for me to read. Not for my AI to search.

What Actually Happens Day to Day

If you use both Obsidian and AI tools, you've probably been through this cycle:

You need context. You're working on something and you know there's a note somewhere that would help. Maybe it's a decision log, maybe a spec, maybe something a teammate shared with you months ago.

You become the search engine. You open Obsidian, try to remember the title, search a few keywords, scan through three or four notes, find the right paragraph, copy it, switch back to your AI tool, paste it in.

You lose the flow. By the time your AI has the context, you've spent 10-15 minutes just finding and transferring information. And you have to do it every session.

Some people try Obsidian MCP servers to solve this — community-built plugins that give AI access to your vault. I tried a couple. They work, but they're limited in ways that matter:

Your vault lives on your laptop. Switch devices and the AI can't reach it. Most of them do keyword matching, not meaning-based search — so searching "how we handle payments" won't find your note titled "Invoice Workflow v3." And if Obsidian isn't open, nothing works at all.

It felt close but not quite there.

The Realization: Not All Knowledge Belongs in the Same Place

After months of going back and forth, I started seeing a pattern. The knowledge in my vault is actually two different things:

Stuff that's for me. Draft ideas. Journal entries. Half-baked brainstorms. Reading highlights. Things I need to think through quietly. This is where Obsidian shines — private, messy, personal.

Stuff my AI needs to know. Architecture decisions. Business rules. How the payment system works. What we decided in that meeting last Thursday. The bug pattern we keep hitting. This kind of knowledge needs to be searchable by meaning, available from any tool, and accessible to my team.

I was forcing Obsidian to be both my thinking space and my AI's memory. But those are different jobs. And they need different tools.

So I Built the Other Half

That's how ContextForge started. I wanted something simple: a place where I could save project knowledge and have my AI actually find it when I needed it.

Not a second note-taking app. Not a replacement for Obsidian. Just a memory layer that sits behind my AI tools and gives them access to what they need.

Here's what that looks like in practice:

Instead of copying notes into a chat, I just ask my AI a question. "How does our auth system work?" And it searches my saved knowledge — not by keywords, but by meaning. So even if I never used the exact words "auth system" in my notes, it still finds the relevant docs because it understands what I'm asking.

Instead of losing context between sessions, my AI picks up where we left off. The decisions from last week, the bugs we fixed, the architecture we agreed on — it's all there.

And instead of my knowledge being locked on my laptop, it's accessible from Claude Code, Cursor, Copilot, or Claude Desktop. Same knowledge everywhere. If I'm working from my laptop in a coffee shop or my desktop at home — same context.

The part that surprised me most? When I connected related pieces of knowledge together, the search got dramatically better. I linked our onboarding docs to the welcome email sequence and the CRM setup guide. Now when someone searches "onboarding," they don't just find the obvious doc — they find everything connected to it, even things they didn't know to look for.

How I Use Both Now

My workflow today is pretty simple:

Obsidian is where I think. Quick notes, journaling, brainstorms, reading highlights — anything personal or half-formed stays in my vault.

ContextForge is where my AI remembers. Project decisions, team agreements, architecture docs, debugging insights — anything my AI should know goes here. I just tell it "remember this" and it's saved.

They're not competing. They're complementary. One is for my brain. The other is for my AI's brain.

And if you already have important notes in Obsidian? You can import them directly — ContextForge reads markdown, so your existing notes transfer without any formatting headaches.

If You Want to Try It

Here's the honest version:

Sign up at contextforge.dev — there's a free plan
Install it with npx contextforge-mcp
Import your most important Obsidian notes (the project ones, not your journal)
Connect it to whatever AI tool you use
Start asking your AI questions about knowledge that used to be stuck in your vault

The free plan gives you 200 items and 500 searches per month. That's more than enough to start with your most critical project and see how it feels.

I'm not going to tell you it'll change your life. But the first time you ask your AI a question and it actually knows the answer because you saved it three weeks ago — that moment is pretty satisfying.

Keep Your Vault

This isn't a "ditch Obsidian" article. I still use it every day. It's still my favorite tool for thinking.

But my AI needed its own memory. Something built for search, not for browsing. Something that works across tools and across devices. Something my team can share.

Keep your vault. Love your vault. Just stop being the middleman between your notes and your AI.

ContextForge works with Claude Code, Cursor, GitHub Copilot, and Claude Desktop. Import your Obsidian notes and make them AI-searchable. Free to start at contextforge.dev.

Claude Code vs Cursor vs GitHub Copilot: What Nobody Tells You About Context

Alfredo Izquierdo — Wed, 08 Apr 2026 14:25:23 +0000

Claude Code vs Cursor vs GitHub Copilot: What Nobody Tells You About Context

Every comparison of AI coding tools focuses on the same things: which model is smarter, which autocomplete is faster, which one costs less per month.

Those comparisons are useful. But they miss the thing that actually determines how productive you'll be: how well each tool understands your project — and how much of that understanding survives to your next session.

I've used all three extensively. Here's what I've learned about the comparison nobody makes.

The Comparison Everyone Makes

You've seen the charts. Claude Code uses Opus/Sonnet, Cursor supports multiple models, Copilot runs on GPT-4 and Claude. Cursor costs $20/month, Copilot is $10-19/month, Claude Code uses API credits. One is an IDE, one is a terminal tool, one is a plugin.

This is all true and mostly irrelevant to your daily experience. Because after the first week, the thing that matters most isn't which model generates better code. It's whether your AI tool understands what you're building — and whether it still understands it tomorrow.

How Each Tool Handles Context

GitHub Copilot

Copilot lives inside your editor. It reads your open files, your recent edits, and suggests completions in real-time. Its new agent mode can make multi-file changes and run commands.

What it remembers: The files you have open, your recent edits, and whatever fits in the conversation window. It recently added MCP support, which means it can now connect to external tools and data sources.

What it forgets: Everything, the moment you close the chat. Your next conversation starts completely fresh. Copilot has no built-in way to carry context between sessions. There's no project-level instruction file (though workspace settings help a bit).

Best at: Quick completions while you type. It feels invisible when it works — you barely notice it's there, which is exactly the point.

Cursor

Cursor is a full IDE built around AI. It indexes your entire codebase, understands file relationships, and uses that understanding when you ask questions or request changes. The .cursorrules file lets you set project-level instructions.

What it remembers: Your full codebase (via indexing), your .cursorrules, and the current conversation. Cursor's codebase awareness is genuinely impressive — it can reference files you haven't opened and understand how components connect.

What it forgets: Every conversation starts clean. Your .cursorrules persist, but those are static instructions, not accumulated knowledge. The debugging session where you found a tricky race condition? The architecture decision you made last Tuesday? Gone.

Best at: Working with large codebases. The codebase indexing gives Cursor a real advantage when you need to refactor across multiple files or understand how things connect. Surveys show 68% adoption among developers who use AI coding tools.

Claude Code

Claude Code runs in your terminal. It reads your project files, understands your codebase deeply, and can execute multi-step tasks with real autonomy — running commands, editing files, creating branches. The CLAUDE.md file gives project-level instructions.

What it remembers: Your full project structure, your CLAUDE.md instructions, and the current conversation. Claude's reasoning is deep — it handles complex, multi-step tasks better than the alternatives. The -c flag lets you continue a recent conversation.

What it forgets: Once a session is truly over, the knowledge is gone. CLAUDE.md helps with instructions, but it's a static file — not a searchable, growing knowledge base. The -c continue flag only works for recent sessions, not last month's work.

Best at: Complex tasks that require reasoning across many files. When you need to plan an architecture change, debug a subtle issue, or implement a feature that touches 15 files — Claude Code handles the complexity better than anything else.

The Gap They All Share

Here's what nobody talks about in these comparisons: all three tools have the same fundamental limitation. None of them remember anything meaningful between sessions.

Copilot doesn't know why you chose PostgreSQL over MongoDB
Cursor doesn't remember the three approaches you tried before finding the right one
Claude Code doesn't recall the security concern your team flagged last sprint

Every morning, every tool, every user: you start from scratch. The AI you work with at 5 PM is brilliant and informed. The AI you meet at 9 AM the next day has total amnesia.

This matters more than model quality, autocomplete speed, or pricing. Because the real productivity killer isn't slow code generation — it's the 15-20 minutes you spend re-establishing context at the start of every session.

What MCP Changes

MCP (Model Context Protocol) is a new standard that all three tools now support. Think of it like USB for AI — a universal way to plug external capabilities into any AI tool.

Before MCP, if you wanted your AI to access a database, a project management tool, or a memory system, each tool had its own custom integration. Now, any MCP-compatible tool works with any MCP-compatible service.

This is significant because it means the gap we've been talking about — persistent memory — can be filled by an external tool that works across all three.

Filling the Gap: Persistent Memory

This is where tools like ContextForge come in. It's an MCP server that gives your AI persistent memory — and because it uses MCP, it works with Claude Code, Cursor, and Copilot equally.

The idea:

Save important knowledge as you work (decisions, patterns, debugging notes, business rules)
Search it later using natural language — the search understands meaning, not just keywords
Organize it by projects and categories so it scales as your knowledge grows
Share it across your team so everyone benefits from collective knowledge

Because it's external to all three tools, your memory follows you. Debug something in Claude Code on Monday, and that knowledge is available in Cursor on Tuesday and Copilot on Wednesday. Same knowledge, any tool.

The latest update even includes relationship-aware search — you can connect related items together, and when you search for one topic, related knowledge surfaces automatically.

The Best Setup (What I Actually Use)

Here's what I've landed on after months of experimentation:

Claude Code for complex tasks — architecture planning, multi-file features, deep debugging. Its reasoning is unmatched.

Cursor for daily coding — editing, refactoring, navigating large codebases. The IDE experience is smooth.

Copilot as a background assistant — autocomplete while I type, quick suggestions that keep me in flow.

ContextForge as the memory layer across all three — every insight, decision, and debugging note saved once, searchable everywhere.

This matches the industry trend. Surveys show developers use 2.3 AI tools on average, because each has a sweet spot. The key is making sure knowledge doesn't get trapped inside any single one.

Making Your Choice

If you're choosing one tool:

Copilot if you want something low-friction that works in your existing editor
Cursor if you want the best codebase awareness and IDE experience
Claude Code if you tackle complex, multi-step tasks that need deep reasoning

If you're choosing what matters most for productivity: pick any tool, but add a memory layer. The tool comparison matters less than whether your AI remembers what you taught it yesterday.

ContextForge adds persistent memory to Claude Code, Cursor, and GitHub Copilot via MCP. Free to start at contextforge.dev.

Why Your AI Coding Assistant Forgets Everything (And What You Can Do About It)

Alfredo Izquierdo — Tue, 31 Mar 2026 14:42:55 +0000

Why Your AI Coding Assistant Forgets Everything (And What You Can Do About It)

You spend an hour working with your AI assistant. You explain your project, your tech stack, your naming conventions, the bug you're chasing. By the end of the session, it knows everything. It's helping you like a senior teammate.

Then you close the window.

Next time you open it, your AI has no idea who you are. The project, the bug, the conventions — all gone. You start from zero.

If this sounds familiar, you're not alone. A 2025 study by Qodo found that 65% of developers report their AI assistants miss relevant context when working on real tasks. And the number one reason? The AI simply doesn't remember what came before.

The Amnesia Problem

Think of it like hiring the most talented assistant in the world. They're brilliant, fast, and can help with almost anything. But every morning they walk in with zero memory of yesterday. They don't know your name, your project, or the three hours you spent explaining the billing system.

That's how every major AI tool works today — ChatGPT, Claude, Cursor, Copilot. The conversation starts, knowledge builds up, and then the session ends and everything disappears.

This isn't a bug. It's how these tools are designed. Each conversation is independent. There's no built-in way for your AI to carry knowledge from one session to the next.

Why Context Windows Don't Solve This

You might have heard that newer AI models have huge context windows — Claude can handle up to a million tokens, GPT-4 handles 128K. That sounds like a lot of memory.

But context windows are more like a desk than a filing cabinet. A big desk lets you spread out more papers while you're working, but when you leave for the night, someone clears the desk completely. The papers are gone.

What's worse, research shows that even during a single long session, AI tools get worse over time. The attention gets diluted. Instructions you gave at the beginning carry less weight by message 80 than they did at message 10. Developers on Reddit and Hacker News call this "context degradation" — and it's one of the most common frustrations people report.

The cruel irony: the obvious fix — starting a fresh conversation — immediately destroys all the context you built up.

What Most People Try (And Why It Falls Short)

Developers have come up with workarounds. Some are clever. None are great.

Copy-pasting context into every session. You keep a document with your project description, architecture notes, and rules. Every new conversation starts with a wall of text. It works, sort of — but it's tedious, eats up your context window, and you have to manually keep that document updated.

CLAUDE.md and .cursorrules files. These are project-level instruction files that your AI reads at the start of each session. They're better than copy-pasting because they're automatic. But they're static text files — no search, no organization, no way to store hundreds of knowledge items, and they don't sync across different tools.

Relying on git history. Your AI can read recent commits, but git history tells you what changed, not why. The reasoning, the tradeoffs, the things you tried that didn't work — none of that lives in a commit message.

Just living with it. Many people don't even realize there's an alternative. They accept the 10-20 minute "re-onboarding" at the start of every session as the cost of using AI.

What Actually Works: Persistent Memory

The real solution is giving your AI a memory that persists between sessions. Not a bigger desk — a filing cabinet.

The idea is straightforward:

When you learn something important, you save it
When you need it later, you search for it — in plain language, not exact keywords
Your AI pulls up the relevant knowledge automatically, no matter how many sessions have passed

This turns your AI from a brilliant amnesiac into a teammate that actually accumulates knowledge over time. The more you save, the more useful it gets.

How This Works in Practice

A few tools have emerged to solve this problem. One of them is ContextForge, which works as a memory layer for Claude Code, Cursor, GitHub Copilot, and Claude Desktop.

Here's what the workflow looks like:

Saving knowledge:

You just solved a tricky problem. Instead of hoping you'll remember it next week, you tell your AI:

"Remember this: the billing webhook requires the signature header to be base64-decoded before validation."

That's it. Saved permanently, searchable later.

Finding knowledge:

Three weeks later, you're debugging something related. You ask:

"What do we know about the billing webhook?"

Your AI searches your memory and pulls up exactly what you saved — plus anything related. You don't need to remember the exact words. The search understands meaning, so "payment processing issues" would find your billing webhook note too.

Organizing knowledge:

As your saved knowledge grows, it stays organized in Projects and Spaces — like folders within folders. Your backend notes stay separate from your frontend notes. Your personal project stays separate from your team's shared knowledge.

The Compound Effect

The real power isn't in any single saved item. It's in the accumulation.

After a week, your AI remembers your recent decisions. After a month, it knows your architecture, your conventions, your common pitfalls. After three months, it has institutional knowledge that would take a new team member days to absorb.

And if you're working with a team, the effect multiplies. Everyone's saved knowledge becomes searchable by everyone else. Your senior engineer's debugging insights are available to your junior developer. No one has to re-discover what someone else already figured out.

Getting Started

If you want to try persistent memory:

Sign up at contextforge.dev (free tier available)
Install with one command: npx contextforge-mcp
Connect it to your AI tool of choice
Start saving things you'd normally lose between sessions

The free plan gives you 50 saved items and 100 searches per month — enough to feel the difference in your first week.

But regardless of which tool you use, the principle is the same: stop letting your AI forget everything you teach it. The 15 minutes you spend re-explaining your project every session add up to hours every week and days every month.

Your AI is powerful. Give it a memory, and it becomes indispensable.

ContextForge works with Claude Code, Cursor, GitHub Copilot, and Claude Desktop. Free to start.

contextforge.dev