Some engineering problems are only painful because they happen so rarely. Even with a coding agent, the frustration still feels the same. I’ll wre...
For further actions, you may consider blocking this person and/or reporting abuse
The part about not taking notes because "the problem is fixed" is painfully relatable. I've done this exact thing more times than I'd like to admit. What I find interesting here is the framing around low frequency problems. Those are actually the worst ones to try and automate because by the time you need it again you've forgotten the solution and probably also forgotten how the automation works. A breadcrumb in the repo is honestly a smarter call than a full skill for something you touch twice a year. The institutional knowledge angle at the end is where it gets genuinely interesting though. That "one engineer who knows everything" problem is real and it doesn't go away just because you're using agents now. If anything it gets worse because the context lives in chat windows that disappear. Connecting session history to git history is a pretty elegant way to solve that. Curious how this holds up across team workflows vs solo projects though, like does it get messy when multiple people are running agent sessions against the same repo ?
Should the Entire history reside in individual forks ? I think it'd be overkill to have all committers' agent sessions in the main/upstream repo, but it would be meaningful to upload Entire contexts when PRs are merged into upstream ?
Great question @yvesm and @codecraft154 Entire saves the useful context behind an AI-assisted change as a “checkpoint.” A checkpoint is basically the session history around a commit: what the developer asked, what the agent tried, what files changed, and why the final solution worked.
For solo use, that helps future-you. For teams, the useful part is that those checkpoints can be pushed to a Git remote, so a teammate or future agent can ask “why did we do this?” and recover the context behind committed work.
I agree that you probably don’t want every experimental personal session dumped into the upstream repo forever. The better mental model is: keep local/WIP context local, and share the context behind work that actually lands. Entire stores that shared context separately from the main code history, so your normal branch doesn’t get polluted with extra commits. That branch is called
entire/checkpoints/v1but if you dont push that code, then it doesn't go up.For teams that want more control, Entire can also push checkpoint data to a separate private “checkpoint remote” instead of the main code repository. That seems like the cleaner setup for companies, forks, or open source projects.Docs if you’re curious: Checkpoints and Checkpoint Remote.
I also wrote a related blog post on this: How to Keep your checkpoints separate from your code - dev.to/entire/how-to-keep-entire-c...
The note-versus-Skill split is missing the option that fits here. A note fails because it depends on you, and you've already stopped writing them. A Skill fails because it's code to maintain for a once-a-quarter task. The third thing is capturing the resolution as context the agent re-reads on its own, not a procedure it runs and not a doc you babysit. The difference matters for exactly this problem: a Skill encodes how you did it and breaks when the device-flow steps change; a captured resolution encodes what worked and why, so next time the agent starts the trial-and-error from where you ended instead of from zero. For low-frequency, high-context problems you don't want automation. You want the agent to spare you re-deriving the same hour of guesses.
The reason it failed the first time is the part worth underlining: no commit meant no anchor, so the session had nowhere to live. That's the real lesson independent of any tool! Agent memory needs to hang off something durable, and git history is a natural hook. One honest question on the security side, though: you deliberately kept the token flow out of the markdown and documented the process instead, but the whole value of the breadcrumb is that it links back to the session transcript, which presumably does contain the actual device flow commands and outputs. So who can read that checkpoint? It feels like the sensitive material moved from the file into the transcript rather than going away, and I'd want to know the access boundary on it before committing the breadcrumb.
The repo is private so only me and my agent can read the checkpoint. Still when the checkpoint is available to us, it is not revealing what the token is. Instead, it reveals the commands i need to run to generate a new token. Yes, I just moved it from one place to another but I've found that in the past when I created demos or blog posts to help people understand how to do something it's created a security vulnerabilities for me.
The rare-problem tax is real. I ran into this exact pattern building a knowledge-graph RAG pipeline — an obscure vector store config issue that took me two hours to debug the first time, then nearly two hours again three months later because I'd never written it down. I ended up keeping a small "war log" markdown file committed alongside the code, but having the agent automatically capture session context the way you describe would have saved me both times.
The useful memory layer is not just storing more chat history. It is capturing the solved shape of the work: what failed, what fixed it, what command proved it, and when that pattern should not be reused.
That is the kind of knowledge that belongs in a repo-adjacent terminal workflow, because the next agent needs executable context, not a vague recollection.
The rare-problem tax is real. I started writing the fix into a notes file the agent reads first, and the win wasn't memory, it was being forced to articulate why the fix worked instead of just closing the tab. The writing is the durable part.
The "painful because it happens so rarely" framing is exactly right, and it's the reason most developers don't build memory systems until they've lost two hours to the same problem twice. What I've started doing with Claude is maintaining a running "solutions log," a simple text file where I paste the problem, the working solution, and why it worked. Then I paste the relevant section at the start of any new session where I might hit the same issue. It's low-tech, but it's basically manual agent memory that works across any tool. The interesting question is what the threshold is, how many times do you need to solve the same problem before it's worth automating the memory versus just keeping a well-organized notes file? Curious what patterns you saw in the data on this.
One thing that stood out to me is that the real asset isn't memory. It's decision history. Code shows what happened. Decision history explains why it happened.