# Jolli — full text corpus

> Jolli is persistent, portable memory for AI-assisted development. Your repo shows what changed; Jolli captures why — the reasoning, alternatives, tokens, and agents behind every commit — into a structured, local-first knowledge base that's reusable across any coding agent, MCP, and Git repo. It runs on your machine by default; nothing leaves unless you sync to the cloud or share a Space.

This file concatenates the key pages of https://www.jolli.ai for one-shot ingestion by AI clients.

---

## Use Jolli with coding agents

Give any coding agent persistent memory in two commands:

```bash
npm install -g @jolli.ai/cli
jolli enable
```

`jolli enable` auto-registers Jolli's local `jollimemory` MCP server into every coding-agent host it detects (Claude Code, Cursor, Codex, Gemini CLI, OpenCode, Copilot) — no prompt. The server is CLI-hosted: a local stdio process, with no remote URL and no `.well-known/mcp.json`.

- Getting started (install → `jolli enable` → first recall): https://docs.jolli.ai/jolli-memory/getting-started-with-jolli-memory
- MCP tools your agent gets + per-host config: https://docs.jolli.ai/jolli-memory/use-your-memory-from-any-ai-assistant-mcp

---

# Blog

## The Day an LLM Deleted IntelliJ From Our Docs

https://www.jolli.ai/blog/the-day-an-llm-deleted-intellij-from-our-docs — 2026-06-18

At Jolli, we maintain documentation for a product that changes constantly.

For a long time, we updated docs the obvious way: feed a capable LLM the commit diff and the current docs, let it figure out what changed. This worked, until it didn't.

One commit. Two outcomes.

This spring, a commit titled "Remove stale JolliMemory IntelliJ, VS Code, and CLI" deleted a pile of plugin source files from our repo. Routine housekeeping. The plugins had moved; the product still ships every one of them.

We fed that commit to Claude Sonnet 4.5 with our docs and asked it to update them. It read the mass deletion, concluded the IntelliJ plugin no longer existed, and confidently removed IntelliJ from the documentation: the install section, the configuration guide, the agent compatibility matrix, the troubleshooting page. Two documents damaged by one misread commit.

The same commit, run through Jolli with the commit's Memory attached, left IntelliJ exactly where it belonged.

A diff tells you what changed. It takes context to know what it means.

## The short version

We replayed 66 real commits from the Jolli codebase (Feb–Jun 2026) through three documentation-update pipelines, then blind-scored the resulting docs on a six-part quality rubric:

| Pipeline | Quality (1–5) | Hallucinated edits |
|---|---|---|
| A: LLM + raw commits | 3.87 | 3 major |
| B: Jolli | 4.18 | 0 |
| C: Jolli + Jolli Memory | **4.43** | **0** |

![Bar chart of blind-scored doc quality on a 1–5 rubric: Arm A (raw commits) 3.87 with 3 hallucinated edits; Arm B (Jolli) 4.18 with zero; Arm C (+ Jolli Memory) 4.43 with zero.](/blog/inline/the-day-an-llm-deleted-intellij-from-our-docs/quality-scores.png)

Same model everywhere. Same commits. The only thing that changed was the context each pipeline had about the docs and the work. Structure beat raw access, and structure plus memory beat both.

## What we actually tested

We replayed 66 real commits from the Jolli codebase (Feb–Jun 2026) through three documentation-update pipelines, blind-scored on a six-part quality rubric.

**Pipeline A — LLM + raw commits.** The model gets the commit diffs and the docs. No special structure, just a capable model doing its best.

**Pipeline B — Jolli.** Every doc declares which parts of the codebase it covers. When a commit lands, Jolli routes it only to the docs it actually affects. The model never sees an irrelevant commit.

**Pipeline C — Jolli + Jolli Memory.** Identical to B, plus the durable record of intent Jolli captures alongside the work — why a change was made, what it means for users, what it deliberately doesn't change.

Each pipeline maintained its own evolving copy of a seven-article doc set across all 66 commits, in order.

![Diagram of the three documentation-update pipelines: raw commits to LLM (A), Jolli routing diffs to only the affected docs (B), and Jolli plus attached Memory (C).](/blog/inline/the-day-an-llm-deleted-intellij-from-our-docs/pipeline-diagram.png)

## What happened

**Raw LLM access is eager, and that's the problem.** Arm A actually caught the most changes: roughly 14 of the 16 ground-truth doc updates we identified in advance, more than either other arm. If you only measured coverage, A wins. But it paid for that eagerness with three major fabricated edits (including the IntelliJ deletion), and it leaked engineering internals into customer-facing docs: ticket IDs, environment variable names, internal package APIs. It also burned 2.2 million input tokens doing it, about 3.4× what arm B used, because without routing, everything gets read by everything.

For documentation, that trade is worse than it sounds. Readers forgive a missing paragraph. They do not forgive instructions for a product feature that was never removed, or an install guide that vanished because a model misread a refactor.

**Jolli's routing fixes trust first.** Arm B's deterministic routing meant the model only ever rewrote docs that had declared interest in the changed code — and the hallucinations went to zero. Quality rose from 3.87 to 4.18, with no internal jargon leaking through. The cost dropped too: routing only the relevant diffs cut input tokens by more than two-thirds versus arm A. The honest flip side: B was conservative, documenting 5 of the 16 expected changes. It never lied, but it left things unsaid.

**Memories make the careful pipeline confident.** Arm C is the cleanest comparison in the experiment — identical routing, identical diffs, identical prompt as B, with one addition: the memories attached to each commit. Quality rose again, 4.18 to 4.43. Coverage rose 50%, from 5 to 7.5 of 16 changes. Hallucinations stayed at zero.

The why is visible in the outputs. Memories carry the *intent* layer diffs can't: that a refactor was packaging work rather than a removal, that a staging behavior has a known limitation users will hit, that a scripts mechanism has size limits and security caveats worth telling users about. With that context, the model documented features it would otherwise have skipped as "probably internal," and declined to document the things that actually were.

And it's efficient. Arm C used about 1.5× arm B's input tokens, still less than half of arm A's — for the best quality scores of the three. If you think of it as accuracy per dollar, the memory arm wins outright.

![Horizontal bar chart of input tokens: Arm A 2.21M, Arm B 0.65M (−71% vs raw), Arm C 0.97M with the best quality per token.](/blog/inline/the-day-an-llm-deleted-intellij-from-our-docs/token-costs.png)

## The commit that would have broken our docs

Commit 1251967 is the whole argument in miniature.

A mass file deletion is the most dangerous kind of commit for an automated docs pipeline: huge diff, unambiguous-looking signal, completely misleading meaning. Pipeline A did exactly what the diff implied and erased a shipping product from the docs. Pipeline C saw the same bytes plus one short memory — "housekeeping, plugin sources moved" — and left everything intact.

No amount of model intelligence fixes this from the diff alone. The information lives in the team's head at commit time. Capturing it there is the entire point of Jolli Memory.

![Side-by-side of the IntelliJ case: pipeline A deletes IntelliJ from the docs after misreading the mass deletion; pipeline C, with the commit's memory attached, leaves it intact.](/blog/inline/the-day-an-llm-deleted-intellij-from-our-docs/intellij-case.png)

## What this experiment is, and isn't

This was an internal experiment, not a research paper. One run per pipeline, one repo and doc set, a pre-registered rubric, blind scoring — but scored by us, on our own product's docs.

The 0.25-point gap between B and C is directional, not definitive. The zero-hallucination result across both Jolli pipelines and the IntelliJ case are the findings we'd bet on. We're planning repeated runs with an independent judge and will publish those too, including if they complicate this story.

## The takeaway

LLMs are excellent writers and unreliable witnesses. Pointed at raw commits, even a top-tier model will confidently document things that didn't happen. The fix isn't a bigger model, every arm here used the same one. The fix is context infrastructure:

Jolli's routing tells the model *where to look*, which eliminated hallucinations and cut token costs by two-thirds in our test. Jolli Memory tells it *what the change means*, which raised both quality and coverage on top of that, and prevented the one failure mode that would have genuinely embarrassed us in production.

Your docs already meet your codebase every day. The question is how much your pipeline knows when they do.

_Want to see what Jolli Memory would capture from your team's work? Get started with [Jolli Memory](https://www.jolli.ai/#memory), it's free, open source, and already has 2.5K downloads._

---

## AI Wrote Your Code. Nobody Remembers Why.

https://www.jolli.ai/blog/ai-wrote-your-code-nobody-remembers-why — 2026-05-26

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.

The paradox 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 be a first-class artifact 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.

_Get started with [Jolli Memory](https://www.jolli.ai/#memory), it's free, open source, and already has 2.5K downloads._