How 60+ AI memory entries transformed my solo dev workflow

Running a solo infrastructure service means every decision lands on your shoulders. No teammates to bounce ideas off, no senior engineers to escalate to—just you, your terminal, and the occasional assist from an AI coding partner. After a year of using persistent AI memory entries, I’ve built a system that captures not just what I did, but why, how to apply it, and what to avoid entirely. These 60-plus entries have become more valuable than any runbook I ever wrote, but only after I learned what actually makes them work—and where they quietly fall apart.

Here are the five lessons that reshaped how I use AI memory for solo operations, lessons I wish I’d internalized from day one.

Document the reasoning, not the action

The first mistake every solo operator makes is treating AI memory like a glorified changelog. You log what you did—"Migrated database from MySQL to PostgreSQL"—and six months later, when something breaks, you realize the entry tells you nothing your version control already does. The real value lies in the why: the constraints that forced the change, the alternatives you considered, and the scenarios where this approach fails.

Take a recent example from my setup. My original memory entry read:

Switched from Docker containers to systemd units on host.

That’s information I could pull from git log in seconds. The rewritten version tells a different story:

Why: Our VPS provider aggressively kills containers via kernel OOM scoring triggered by other customers’ workloads. Systemd processes survive because they’re scored as system processes.
How to apply: If `dmesg | grep -i oom` shows kills from unknown PIDs, avoid containers—use systemd instead.

That single entry has prevented three rebuilds. The next time I’m tempted to "just dockerize it," the memory entry stops me cold: I already learned this the hard way.

The rule is simple: every memory entry must include Why and How to apply lines. If it can’t answer those two questions, delete it.

Memory decays—prune early or pay the cost

About six months into using AI memory, I ran an audit. Out of 60 entries, 14 referenced things that no longer existed—a renamed file path, a deleted function, an architecture I’d replaced. The damage wasn’t just clutter; it was actively misleading. The AI would surface an entry pointing to a non-existent path, dead-end, or fabricate a response.

Scheduled audits didn’t stick. What worked was a simple habit: every time I reference a memory entry mid-task, I ask: is this still true? If not, edit or delete it on the spot.

Memory isn’t a backup—it’s a live dependency. Treat outdated entries like stale feature flags: they create noise, waste cycles, and erode trust in the system.

The most valuable memories are the traps you avoided

The highest-leverage memory entries don’t describe systems—they describe what not to do. "Don’t run X on Y." "This approach cost three debugging nights last quarter." "That UI shortcut looks fast until condition Z breaks it."

These entries save the most time because they prevent rediscovering the same pain. But they’re also the hardest to write. When you’ve just spent four hours debugging a problem, the impulse is to move on—to ship the fix and call it done. The real work begins after the fix: sitting down for five more minutes to document what almost broke you.

I now ask myself after every frustrating debugging session: Did I just learn something my past self would have wanted to know? If the answer is yes, I write the entry—even if it’s just two lines.

These are the entries with the highest savings per character written. They’re also the easiest to skip.

Retrieval depends on the index, not the file

I maintain a MEMORY.md file that serves as an index—each line is a title plus a one-line hook describing the content. After dozens of entries, I realized something counterintuitive:

The index entry determines retrieval, not the file content.

The AI first sees the index line. Only if the hook is relevant does it load the full memory file. If webhook_replay.md is labeled "webhook stuff," the AI ignores it. But if it reads:

Stripe webhook replay: idempotency-key collisions vs. event_id reuse; partial DB failures leaving workers in unknown states; the one query to check if it’s safe to re-fire

…the AI opens the file at exactly the right moments.

The memory file might contain 500 words. The index line might be 100 characters. That 100 characters does all the retrieval work.

When I write a new entry now, I spend more time crafting the index line than drafting the file body. It feels backwards. It isn’t.

Indexes have a limited context budget

This lesson came at a cost: my agent truncates MEMORY.md after a certain line count. For me, lines beyond 200 silently drop out of context—they might as well not exist.

That means MEMORY.md isn’t just an index—it’s a layout problem. Which 200 lines earn a permanent spot in every conversation? Which entries are worth keeping on disk but not critical enough to load every time?

Pruning isn’t only about deleting outdated entries. It’s about deciding what earns context. My rule now: if I haven’t referenced an entry in two months and it’s not load-bearing, its index line moves down or out. The file stays on disk for reference. The index line is sacred real estate.

The system I wish I’d had on day one

I’m now packaging the schema I’ve refined—the memory templates, the MEMORY.md layout, the prompts I use to trigger high-signal writes, the audit rituals—into a kit for solo operators using Claude Code. It’s the system I wish I’d had from the start.

This isn’t about chasing the latest AI tooling. It’s about turning solitary operations from a high-wire act into a repeatable process—one where the AI remembers what you’ve learned, so you don’t have to rediscover it every time.