Oliver Zehentleitner

Exactly. That “missing history” is easy to ignore when humans still carry it in their heads. But once agents work across fresh sessions, the cost becomes visible: the same dead ends get investigated again because the repo only shows what survived. That is the part I find most interesting too.

Great points. Yes, entries are sorted by filename within each section. So two additions under the same letter can still collide if they land in the same gap - especially while that section is sparse. As it fills up, the existing entries themselves create more natural merge anchors. So the 36 headings don't eliminate conflicts, they mainly remove the worst case where every new entry competes for the same append position. And funny enough, the “agents will tidy this away” problem is already covered too. The current spec + keep-the-why-lint check that all 36 headings exist, entries are under the correct heading, and entries are sorted (E205, E206, E204). I learned pretty quickly not to rely on an agent politely respecting formatting conventions. :) I really like the git merge-tree --write-tree idea. A comparison of append vs. globally sorted vs. sectioned would be worth measuring - ideally also with a deliberately skewed filename distribution rather than uniform random data. That might become a follow-up to the article. Thanks!

Exactly. The code is only part of the system. If the agent can also see why certain decisions were made - and why some alternatives were rejected — it becomes much more useful as an engineering partner.

Yes. I think that distinction matters a lot. The goal is not to make an agent “remember everything”. It is to make the important project decisions, trade-offs and lessons available when they become relevant again. That is where AI collaboration starts to feel less like repeated prompting and more like continuity.

Yes - I really like that distinction between code state and decision state. And the expiration/revisit condition is an important extension. A rejected approach should not become a permanent “never do this again” rule just because it failed once under a specific set of assumptions. What matters is preserving why it was rejected, under which conditions, and what would have to change before it is worth reconsidering. That makes the recorded rationale much more useful: not just “don’t do this”, but “don’t do this while these constraints still hold”.

Exactly - that’s the part I found most interesting as well. Once I stopped looking at it as a merge problem and started looking at it as a write-allocation problem, the solution became much simpler. And yes, the retrieval benefit for agents was a nice side effect rather than the original goal. I like solutions where one bit of structure helps both humans/tools and Git without introducing another layer of infrastructure. Thanks for putting it that clearly!

Exactly. “Negative knowledge” is a great way to put it. The code tells you what survived, but not what was explored and deliberately discarded. And for agents, that missing history means spending time rediscovering the same boundary over and over again. That was probably the most interesting part of the experiment for me: the agent didn’t need to become smarter — it just needed access to the reasoning that was already there.

What exactly do you mean with Hashnode blocks Google? The sitemap or the entire blog?

I'm glad to hear it! Thanks for the feedback!

❤️