AI memory tips for solo operators: Lessons from 60+ entries
One sysadmin running a paid infrastructure service alone has learned the hard way that AI memory entries can outlive runbooks—but only if they’re written the right way. After a year of solo ops, 60+ persistent memory entries became more valuable than any static manual. The catch? Most early entries were useless. The difference came down to five rules the author wishes they’d followed from day one.
Why context beats history
The first mistake was logging what was done instead of why. A terse note like “Switched service X from Docker to systemd” told nothing the git log didn’t already reveal. Rewriting it to include the root cause changed everything: “systemd on host instead of containers—provider OOM-killer was reaping tenant workloads; systemd processes survive.” That single entry has prevented three rebuilds by stopping the same bad choice from resurfacing.
Prune or pay: memory rots fast
About six months in, an audit found 14 of 60 entries pointing to dead files, renamed paths, or scrapped architectures. Worse, the agent sometimes surfaced missing files and either stalled or invented details. Scheduled clean-ups failed; the only reliable fix was reviewing entries in the moment. If a memory entry can’t answer “still true?”, edit or delete it right away—memory isn’t backup, it’s a live dependency.
Trap memories save the most time
The highest-leverage entries don’t describe systems; they warn what not to do. “Don’t run X on Y,” “Avoid this approach, cost three debugging nights,” or “Shortcut Z breaks under condition W” prevent rediscovering the same pain. Yet these are the hardest to write. After a frustrating debugging session, the impulse is to ship the fix, not document the trap. The new habit: ask, “Did I just learn something my past self needed to know?” If yes, write it down—even if it costs five extra minutes.
Source: DEV Community. AI-assisted editorial synthesis — TechnoExpress.