Discussion on "What happens when a coding agent forgets why a change was rejected?"

Oliver Zehentleitner · 2026-09-08T14:03:40.375Z

Coding agents are pretty good at understanding code. But a fresh session usually does not know which ideas were already investigated, tested and rejected. If the rejected idea left no code change behi

The rejected changes part is what stood out to me. Git is good at showing what we kept, but not what we tested and threw away. That missing history gets expensive once agents start working across sessions.

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 insight. AI coding agents need more than the ability to generate code, they need context and memory of past decisions. Understanding why a change was rejected is what will make them true engineering partners rather than just code assistants.

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.

This is such an important discussion about the difference between intelligence and understanding. A coding agent can generate impressive solutions, but without remembering why certain decisions were made, it can easily repeat the same mistakes or reopen problems that humans have already solved. The real challenge with AI collaboration is not only making agents better at writing code, but helping them preserve the context, trade-offs, and lessons behind those decisions. In software development, the “why” is often just as valuable as the code itself. I think the future of AI-assisted development will depend less on replacing developers and more on creating AI partners that can learn from a team’s history, respect previous decisions, and understand the reasoning behind a system’s evolution. Great reminder that true collaboration requires memory, context, and trust, not just faster code generation.

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.

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.

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

The idea of preserving rejected decisions is especially interesting because it captures a form of “negative knowledge” that Git usually can’t represent. A codebase can show what the team chose, but not necessarily which alternatives were tested and ruled out. For coding agents, that context could prevent not only repeated mistakes but also repeated investigation. It makes project memory feel less like storing explanations and more like preserving the reasoning boundary around the code.

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.

Search Hashnode

What happens when a coding agent forgets why a change was rejected?

Responses(10)