DEV Community: Alfredo Izquierdo

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

The Missing Layer Between You and Your AI Coding Assistant

Alfredo Izquierdo — Tue, 24 Mar 2026 15:30:00 +0000

The Missing Layer Between You and Your AI Coding Assistant

If you use AI tools like Claude, ChatGPT, Cursor, or GitHub Copilot to help you work, you've probably noticed something frustrating: every time you start a new conversation, your AI has no idea who you are.

It doesn't remember what you worked on yesterday. It doesn't know your project. It doesn't recall that bug you spent three hours fixing last week. You have to explain everything from scratch. Every. Single. Time.

That's the problem I got tired of. And that's why I built ContextForge.

The Problem: Your AI Has Amnesia

Think of it like this. Imagine you hire an incredibly talented assistant. They're fast, smart, and can help you with almost anything. But every morning when they show up to work, they've completely forgotten everything — your name, your company, what you're building, what happened yesterday.

That's exactly what working with AI tools feels like today. The conversation ends, the memory is gone.

For me, this meant:

15-20 minutes wasted at the start of every session re-explaining my project
Repeating the same context about my tech stack, business rules, and decisions
Losing valuable insights — solutions I found yesterday were gone today
Onboarding friction — every team member had to re-teach the AI from zero

It doesn't sound like a lot. But multiply that across every session, every day, across a team — and it adds up to hours of lost productivity every week.

The Solution: Give Your AI a Memory

ContextForge is a memory layer for your AI tools. It works with Claude Code, Cursor, GitHub Copilot, and Claude Desktop. The idea is simple:

Anything you want your AI to remember, you save. Anything you need later, you search.

Here's what that looks like in practice:

Starting your day:

You open your AI tool and ask:

"What were we working on last week?"

Instead of a blank stare, your AI pulls up your recent work — the features you were building, the bugs you fixed, the decisions you made. You're productive in 30 seconds instead of 20 minutes.

Saving what you learn:

You just figured out something important — maybe a tricky business rule, a workaround for a tool, or a decision your team agreed on. You tell your AI:

"Remember this: client invoices must be generated before the 5th of each month, or the billing system flags them as late."

Done. That knowledge is now saved permanently and searchable by anyone on your team.

Switching between projects:

You jump from one project to another. Instead of re-explaining everything, your AI already knows the context for each project — how it's structured, what the priorities are, what's been decided. The switch is instant.

How the Search Works (The Part That Makes It Useful)

Saving knowledge is only half the story. The other half is finding it when you need it.

ContextForge uses smart search. You don't need to remember exact words or file names — you just describe what you're looking for in plain language.

"How do we handle client payments?"

"What was that issue with the email notifications?"

"Find everything related to the onboarding process"

The search understands meaning, not just keywords. So if you saved something titled "Invoice generation workflow" and you search for "billing process," it'll still find it because the concepts are related.

You can also narrow things down:

Search within a specific project or workspace
Filter by tags like "urgent," "design-decision," or "bug"
Set how closely results need to match your question

Everything is organized into Projects (your different initiatives) and Spaces (categories within a project, like "Design," "Bugs," "Architecture"). So your knowledge stays tidy as it grows.

The New Feature: Search That Follows Connections

Here's what we just shipped, and it's a game-changer.

The old way: You search for "onboarding" and you get results that mention "onboarding." But what about that welcome email sequence you saved separately? Or that CRM setup guide that's directly related? If those didn't use the word "onboarding," they wouldn't show up.

The new way: ContextForge now follows the connections between your saved knowledge.

How It Works

When you save knowledge, you can link related items together. Just tell your AI:

"Connect the welcome email sequence to the onboarding process"

"Link the security audit to the payment system architecture"

You're building a web of connected knowledge — like a personal Wikipedia for your projects.

What This Means for Search

Now when you search for "onboarding," ContextForge does something smart:

Finds direct matches — anything that talks about onboarding
Follows the connections — discovers related items that are linked to those matches, even if they never mention "onboarding"

So your search for "onboarding" might return:

Direct results:

Client Onboarding Process (89% match)
Onboarding Checklist (76% match)

Discovered through connections:

Welcome Email Sequence — connected to the onboarding process
CRM Setup Guide — derived from the onboarding checklist

You found things you didn't even know to search for. That's the power of connected knowledge.

Why This Matters for Teams

This is where it gets really powerful. When one person saves knowledge and connects it to related topics, everyone on the team benefits.

Your experienced team member documents how the payment system works and links it to the security requirements, the compliance rules, and the third-party integrations. Now when someone new searches "payment processing," they don't just get one document — they get the full picture, including context they wouldn't have known to look for.

The more connections your team creates, the smarter every search becomes. Knowledge compounds over time.

Real Impact

After three months of using ContextForge in my daily workflow:

Starting a work session: from ~15 minutes of setup to ~30 seconds
Investigating past issues: from ~45 minutes of digging to ~10 minutes of searching
Switching between projects: from ~10 minutes of context loading to instant
Bringing new team members up to speed: from days to hours

That's roughly 1-2 hours saved every day. Not through any trick — just by not having to repeat myself.

Getting Started

If you want to try it:

Create a free account at contextforge.dev
Get your API key from the dashboard
Install it with one command: npx contextforge-mcp
Connect it to your AI tool (Claude Code, Cursor, Copilot, or Claude Desktop)
Start saving knowledge and let it build up over time

The free plan includes 50 saved items, 100 searches per month, and 3 workspaces. That's enough to see the difference in your first week.

The Bottom Line

AI tools are incredibly powerful, but they have a fundamental gap: they forget everything between conversations.

ContextForge fills that gap. Save what matters. Connect related knowledge. Search it naturally. And let it grow smarter over time — for you and your whole team.

The relationship-aware search we just launched makes this even better. Now when you search, you don't just find what matches your words — you find everything that's connected to it.

Because the best knowledge isn't just the thing you searched for. It's the thing you didn't know you needed.

ContextForge Memory works with Claude Code, Cursor, GitHub Copilot, and Claude Desktop. It's free to start.

contextforge.dev | GitHub | npm

GitHub Copilot Now Supports MCP — Here's How to Give It Persistent Memory

Alfredo Izquierdo — Tue, 17 Mar 2026 16:00:00 +0000

GitHub Copilot just got MCP support. That means you can now connect external tools directly to Copilot's Agent Mode in VS Code.

One thing you can do with this: give Copilot memory that persists across sessions.

The problem

Every time you start a new Copilot chat, it starts from zero. It doesn't know your architecture. It doesn't remember the decision you made last week about the auth flow. It doesn't know that your team uses Zustand instead of Redux, or that the billing module has a quirk with European tax codes.

You explain. Again. And again.

This isn't a minor inconvenience. For complex projects, re-establishing context is the biggest time sink when working with AI coding agents.

What changed

GitHub shipped MCP (Model Context Protocol) support for Copilot in VS Code. MCP is an open protocol that lets AI tools connect to external servers — databases, APIs, custom tools.

This means Copilot can now use tools beyond its built-in capabilities. Including tools that give it memory.

How it works

I built ContextForge, an MCP server that gives AI agents persistent memory. It works with Claude Code, Claude Desktop, Cursor, and now GitHub Copilot.

The setup takes about 3 minutes.

Step 1: Create a free account

Go to contextforge.dev and sign up. Create an API key from the dashboard.

Step 2: Add the MCP config

Create a .mcp.json file in your project root:

{
  "servers": {
    "contextforge": {
      "command": "npx",
      "args": ["-y", "contextforge-mcp"],
      "env": {
        "CONTEXTFORGE_API_KEY": "your-api-key-here"
      }
    }
  }
}

Or add it globally in your VS Code settings.json:

{
  "mcp": {
    "servers": {
      "contextforge": {
        "command": "npx",
        "args": ["-y", "contextforge-mcp"],
        "env": {
          "CONTEXTFORGE_API_KEY": "your-api-key-here"
        }
      }
    }
  }
}

Step 3: Use Agent Mode

Open Copilot Chat in VS Code and switch to Agent Mode. ContextForge tools are now available.

That's it.

What you can do with it

Once connected, Copilot can:

Save context as you work:

"Remember that our auth uses JWT with 1-hour token expiration and refresh tokens stored in HTTP-only cookies"

Recall it in any future session:

"How does our authentication work?"
→ Found 3 results: JWT auth with refresh tokens in HTTP-only cookies... (94% match)

Sync your Git history:

"Sync my recent commits to memory"
→ Synced 47 commits and 8 PRs

Track tasks:

"Create a task: Fix auth token refresh bug, priority high"

Search with natural language:

"What decisions did we make about the database schema?"

The key insight: this memory persists. Close VS Code, switch machines, start a new chat — the context is still there.

Why this matters

Large context windows help, but they don't solve the persistence problem. Claude's 1M token window is impressive. But when the session ends, that context is gone.

Persistent memory is different. It's the accumulated knowledge about your project — architecture decisions, naming conventions, debugging notes, deployment quirks — that you build up over weeks and months.

Think of it as the difference between RAM and a hard drive. You need both.

Works everywhere

The same memory syncs across all your tools:

GitHub Copilot — Agent Mode in VS Code
Claude Code — Terminal workflow
Claude Desktop — Rich conversations
Cursor — AI-assisted editing

Save a decision in Claude Code, recall it in Copilot. The memory follows you, not the tool.

Try it

ContextForge has a free tier — no credit card required. Setup takes under 3 minutes.

Website: contextforge.dev
Docs: contextforge.dev/docs
npm: npm install -g contextforge-mcp

If you're already using Copilot with Agent Mode, adding persistent memory is one .mcp.json file away.

I built ContextForge because I got tired of re-explaining my codebase to my AI agent every morning. If you've felt the same frustration, give it a try.

Claude Now Remembers 5x More — But It Still Forgets You Tomorrow

Alfredo Izquierdo — Sat, 14 Mar 2026 02:27:00 +0000

Last Tuesday I was three hours deep into a refactor. Not the fun kind — the kind where you're untangling years of tech debt and every file you touch reveals two more that need fixing.

But Claude and I were in the zone. We'd mapped out the dependency chain, figured out the migration order, and even caught a subtle race condition that would've blown up in production. It was one of those sessions where you feel like you're pair programming with someone who genuinely gets it.

Then my laptop died.

I plugged it in, reopened Claude, and typed "ok where were we?"

"I'd be happy to help! What are you working on?"

Three hours. Gone. Not because Claude isn't smart enough to remember — but because that's just how conversations work. They end.

So About That 1 Million Token Thing

You've probably seen the news. Opus 4.6 now ships with a 1M token context window. Five times bigger than before, same price. And honestly? It's a massive deal.

With a million tokens you can hand Claude your entire codebase and it won't blink. It can hold the frontend, the backend, the tests, the deployment configs, and still have room for a lengthy conversation about all of it.

But I want to tell you about something that happened to me after the announcement.

I was scrolling through Twitter and saw someone post: "1M context window means memory tools are officially dead. Why would you need persistent storage when you can just load everything?"

And I laughed. Not because they're wrong about the power of 1M tokens — they're absolutely right. I laughed because I've heard that exact take every single time context windows got bigger. At 8K. At 100K. At 200K. And every time, three weeks later, those same people are frustrated again.

The Filing Cabinet on Your Desk

Let me tell you why.

Last week a developer on our Discord shared something that stuck with me. He said: "I upgraded my desk to one of those giant L-shaped ones. I can spread out every document I need. But I still need my filing cabinet because at 6 PM I have to clear the desk."

That's it. That's the whole thing.

A bigger context window is a bigger desk. You can spread out more. You can see more at once. You can make connections between things that used to require flipping back and forth. All of that is genuinely useful.

But when you close the tab — and you will close the tab — the desk gets cleared.

Your filing cabinet is what makes Monday morning bearable. It's what lets you pick up a project after a week of vacation without spending an hour figuring out where you left off. It's what keeps tribal knowledge from evaporating when someone goes on PTO.

A Wednesday That Changed How I Think About This

Three weeks ago, on a Wednesday, I hit a bug that made no sense. A webhook handler was silently dropping events, but only for one specific customer. The logs showed nothing. The code looked correct.

I was about to start a fresh debugging session when Claude pulled something up from my ContextForge space — a note from January where I'd documented a nearly identical issue. Turns out, that customer's account had been created during a migration window where a timezone offset was slightly wrong, causing their webhook signatures to validate with a one-second drift.

January. Two months ago. In a conversation I'd completely forgotten about.

I fixed the bug in fifteen minutes. Without that note, I would've burned the afternoon — and maybe part of Thursday — tracing through the same path I'd already walked.

That's not something a bigger context window gives you. That's accumulated knowledge paying dividends over time.

What I Didn't Expect

When I first built ContextForge, I thought of it as a note-taking tool for AI. Save stuff, recall stuff. Simple.

But something unexpected happened once teams started using it.

A developer in São Paulo joined a project that three people had been building for four months. Instead of the usual two-hour onboarding call, she connected to the shared ContextForge space and started asking Claude questions. "Why did we choose this auth pattern?" "What's the deal with the legacy billing endpoint?" "Are there any known gotchas with the rate limiter?"

Claude answered all of them. Not from documentation — most of it wasn't documented. From the accumulated memory of four months of conversations, decisions, and debugging sessions that the team had been naturally building up.

She shipped her first PR that afternoon.

That's not a feature. That's a side effect of giving AI a way to accumulate knowledge over time. And it has nothing to do with how big the context window is.

Why 1M Actually Makes Memory Better

Here's the part that surprises people: a bigger context window doesn't make persistent memory obsolete. It makes it more powerful.

Before, with a 200K window, ContextForge had to be surgical about what it surfaced. Only the top 5 most relevant memories could fit alongside your code. Tough choices had to be made.

With 1M tokens? Claude can load your recent commits, your architectural decisions, the debugging notes from last month, AND the full code you're working on — all at once. The memory has room to breathe. Context and memory stop competing for space and start complementing each other.

Bigger desk. Same filing cabinet. Better workflow.

The Honest Take

I'm not going to pretend this article isn't partly about ContextForge. It is. I built the thing, I believe in it.

But the honest truth is this: I've watched developers go through the same cycle over and over. A new model drops, context gets bigger, everyone celebrates, and then slowly the frustration creeps back in. Because the underlying problem — that conversations are temporary but projects are not — never actually goes away with a bigger window.

A million tokens is extraordinary. I genuinely mean that. For the first time, you can have a conversation with Claude where it truly understands your entire codebase at once. That changes what's possible in a single session.

But your project isn't a single session. It's hundreds of sessions spread across months. And somewhere between session 47 and session 48, there's a gap where knowledge falls through. That gap is what persistent memory fills.

ContextForge is free to start. If you've never experienced a Claude that remembers your last conversation, try it once. That's all I ask.