I was debugging a Stripe webhook handler in a side project I'd vibe-coded over a weekend. The app was simple, a subscription billing tool I'd built with Claude Code. It featured user auth, payments and a dashboard. It worked. Users signed up. Money moved.

Then a user reported getting charged twice after upgrading their plan. I opened the webhook handler and stared at it. There were no obvious bugs.

It handled customer.subscription.updated events, checked for idempotency, and updated the user record. All correct. But there was a conditional branch I didn't recognize, a check for overlapping billing cycles that I couldn't explain. I knew I'd discussed this with Claude during the session. I vaguely remembered rejecting a simpler approach because of a race condition. But which approach? Why this one?

The session was gone. The commit message said Add Stripe webhook handler. The git diff showed me what changed. Nothing showed me why.

I spent almost two hours reverse-engineering my own code before I found the bug. The fix took four minutes.

That wasn't the first time. A week earlier I'd spent most of a morning trying to pick up a feature I'd started with Cursor the Friday before. I knew I'd made progress, the commit history showed four clean commits. But I couldn't remember the approach I'd landed on for handling rate limits, or why I'd structured the retry logic the way I did. So I did what I always end up doing: started a new session and re-explained everything from scratch.

The thing is, AI coding tools are great at the building part. Describe what you need, iterate, ship. But they don't remember anything. Every session starts from zero. Close the terminal and the thinking behind the code is gone. Git tracks what changed. Nothing tracks why. You don't notice how much that costs you until you add it up.

It shows up everywhere once you start paying attention

The debugging session was bad enough. But context loss compounds in ways I didn't expect.

I review PRs from teammates who use Claude Code and Cursor. The diffs are clean, well-structured, tests pass. But I can't review them because I don't know why these decisions were made. Was there a reason they used a queue instead of a direct API call? Was that an intentional choice or just what the AI suggested first? I spend twenty minutes reverse-engineering intent before I can even start the actual review. And I know they're doing the same thing with my PRs.

I've hit the compaction wall mid-session more times than I can count. Two hours in, Claude understands my codebase, my constraints, my preferences. Then the context window fills up. It summarizes the conversation to make room and loses the critical details. It starts contradicting itself, forgetting constraints I set an hour ago, suggesting approaches I already rejected. It's like your collaborator got swapped out mid-conversation and nobody told you.

I've watched a teammate try to onboard onto a codebase I'd built mostly with AI. Half the files were decisions I couldn't fully explain anymore, not because the decisions were bad, but because the reasoning existed in a Claude session I'd closed weeks ago. The code worked. The why was gone.

It hit me: the tools that made me faster at writing code were making me slower at everything that comes after, reviewing, debugging, onboarding, maintaining. I was generating code at 10x speed and paying for it later at 0.5x.

The workarounds I tried

I tried fixing this myself.

I set up a CLAUDE.md file in my repo, a static context file that gets loaded into every AI session. It helped. But it's manual, it goes stale the moment my codebase evolves, and it caps out at a couple hundred lines before it starts bloating every session. More importantly, it captures project-level context, not session-level context. It can tell Claude "we use Zustand for state management." It can't tell Claude "last Tuesday we discussed three different approaches to the auth flow and here's why we chose this one."

I tried keeping manual session notes. That lasted about a week. I'd skip them when I was tired, or when a session ended in frustration, which is exactly when the context matters most.

I looked into custom MCP memory servers, SQLite-based solutions, personal scripts. Some of them are impressive. But they're fragile, they're individual, and they don't solve the fundamental problem: context should live in my development workflow, not a side project I maintain on my own time.

Every workaround I tried had the same flaw. They depend on me being disciplined enough to do the thing, every time, without fail. And I'm not. Nobody is. That's the whole reason we have CI/CD, linters, and formatters.

Context as Code

After all the workarounds failed, I kept coming back to the same question: why is context something I have to manually maintain in the first place? My code lives in the repo. My tests live in the repo. My CI config lives in the repo. But the reasoning behind my AI-generated code lives in a chat window that disappears?

That's when I remembered we've already solved this exact problem before, with Docs as Code. Documentation was always stale because it lived in a separate system. The fix was simple: bring it into the repo, use Git and Markdown, treat it as part of the workflow. It worked because it stopped depending on people remembering to update a wiki.

AI coding has created a new version of the same gap. But it's not the documentation that's falling behind, it's the context. The reasoning behind why code was written. The decisions made during the session. The alternatives considered and rejected. All of it living in a chat window that gets destroyed after every commit.

I've started thinking about this as Context as Code. Capture the reasoning alongside your code, store it in version control, write it in a format anyone can read. A durable record of why your codebase looks the way it does. Not in a separate tool. Not in a wiki. Not in your head. In your repo, connected to the commit it belongs to.

If Docs as Code made stale documentation unacceptable, Context as Code should make undocumented AI commits feel just as incomplete.

How to start practicing Context as Code

You can try this on your next commit without installing anything.

After your next AI coding session, create a file in your repo, something like context/2026-05-22-stripe-webhook.md. Fill in three things:

What I asked the AI to do. The goal of the session in a sentence or two. "Build a Stripe webhook handler that processes subscription upgrades and handles idempotency."

What approach it took and why. The pattern or solution the AI landed on, and the reasoning behind it. "Used a two-step verification that checks both the event ID and the subscription period to prevent duplicate charges during overlapping billing cycles."

What I rejected and why. The approaches you discussed and decided against. This is the part you'll be most grateful for later. "Rejected a simpler idempotency check using only the event ID — Claude flagged a race condition where two events could fire within the same billing cycle transition."

That's it. One file. Five minutes.

It won't feel worth it the first time. Then three weeks later you'll be debugging a file you can't explain, check the context folder, and find the exact reasoning in front of you. The two-hour debugging session takes ten minutes.

If the manual version clicks but the discipline doesn't stick, that's why we built Jolli Memory. It captures context as you work, stores it in its own Git-backed project store, and never touches your code repo. Works with Claude Code, Cursor, Codex CLI, Gemini CLI, and Copilot. Local-first, free, and open source.

The reasoning should survive

I'm not going to stop vibe coding, it's genuinely changed how I build things. But I'm done accepting that the thinking behind my code disappears every time I close the terminal.

Try it on your next commit. One file. Five minutes. See if it changes how your Monday morning goes.