---
title: "Comment by Mateo Ruiz on \"What happens when a coding agent forgets why a change was rejected?\" | Hashnode"
description: "The most useful distinction here is between code state and decision state . Git tells the next agent what survived, but it often cannot tell it which alternativ"
url: "https://hashnode.com/posts/what-happens-when-a-coding-agent-forgets-why-a-change-was-rejected/6aa015bcbe03d2ac71a46645/comment/6aa235071603e518a15f07f9"
---

[Discussion](https://hashnode.com/posts/what-happens-when-a-coding-agent-forgets-why-a-change-was-rejected/6aa015bcbe03d2ac71a46645)

Comment [What happens when a coding agent forgets why a change was rejected?](https://hashnode.com/posts/what-happens-when-a-coding-agent-forgets-why-a-change-was-rejected/6aa015bcbe03d2ac71a46645)

[Mateo Ruiz](https://hashnode.com/@mateoruiz)

[Sep 10](https://hashnode.com/posts/what-happens-when-a-coding-agent-forgets-why-a-change-was-rejected/6aa015bcbe03d2ac71a46645/comment/6aa235071603e518a15f07f9)

The most useful distinction here is between **code state and decision state**. Git tells the next agent what survived, but it often cannot tell it which alternatives were deliberately killed along the way.

I’d take this one step further and treat rejected approaches as constraints with an expiration condition. A workaround may be rejected because of a production incident today, but that reason can become invalid after a dependency, architecture, or traffic pattern changes. Recording not just “don’t do this” but _why, under which conditions, and when to revisit it_ would make project memory much more actionable.

That turns a simple Markdown file into something more valuable than context it becomes a lightweight record of architectural decisions and their assumptions.

[Oliver Zehentleitner](https://hashnode.com/@oliver-zehentleitner)

[Sep 10](https://hashnode.com/posts/what-happens-when-a-coding-agent-forgets-why-a-change-was-rejected/6aa015bcbe03d2ac71a46645/comment/6aa235071603e518a15f07f9#reply-6aa23c20bb190d0950f94a90)

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”.