Warum AI Coding Agents fruehere Entscheidungen uebergehen
Entscheidungen aus vergangenen Sessions geraten Coding Agents schnell wieder aus dem Blick, sodass sie früh gefällte Architekturbeschlüsse widersprechen. Mit klaren, zentral dokumentierten Entscheidungen lässt sich das verhindern.
Veröffentlicht am 15. Oktober • Zuerst erschienen auf contextforge.dev
Zuerst veröffentlicht auf contextforge.dev.
Vor zwei Wochen haben Claude Code und ich einen Nachmittag an der ContextForge-Landingpage verbracht. Wir entschieden, dass sie vollständig statisch sein sollte, im Hintergrund neu generiert wird und dass die Live-Zahlen nur im Admin-Bereich gestreamt werden. Wir haben es gemessen, es war schneller, und ich schrieb die Begründung in den Pull Request. Am darauffolgenden Dienstag schaute sich eine frische Session dieselbe Seite an und schlug vor, sie dynamisch zu machen, "damit die Statistiken immer aktuell sind." Gleiches Modell, gleiches Repository, gegenteilige Entscheidung, präsentiert mit voller Selbstsicherheit.
Wenn Sie schon einmal danach gesucht haben, warum KI-Coding-Agents früheren Entscheidungen widersprechen, dann hatten Sie einen solchen Dienstag. Hier ist die ehrliche Antwort, und es ist nicht die, die ich erwartet hatte, als ich anfing zu graben.
TL;DR: Der Agent ändert nicht seine Meinung. Entweder ist die Entscheidung nie in der Session angekommen, in der Sie sich befinden, oder sie kam ohne die Begründung dahinter an. Es gibt fünf Wege, wie das passiert, und jeder hat eine billige Lösung. Der teure Teil ist, aus der Lösung eine Gewohnheit zu machen.
Ein Sprachmodell hält keine Meinungen zwischen Aufrufen fest. Jede Antwort wird aus dem berechnet, was gerade davor liegt: Ihrem Prompt, den geöffneten Dateien, dem bisherigen Gespräch. Wenn eine Entscheidung nicht in dieser Eingabe enthalten ist, ignoriert der Agent sie nicht. Er schließt aus dem Code, wie er heute ist, und in dem Code, wie er heute ist, wirkt die dynamische Version meiner Landingpage vollkommen sinnvoll.
Die frustrierende Frage "Warum widerspricht er mir ständig?" wird also zu einer nützlicheren: "Warum war die Entscheidung nicht in seiner Eingabe?" Ich fand fünf Gründe. Hier sind sie in der Reihenfolge, in der ich auf sie gestoßen bin.
Der offensichtliche. Sie und der Agent haben in einem Gespräch etwas geklärt, das Gespräch endete, und die nächste Session begann bei null. Claude Code kann mit --resume eine frühere Session wieder öffnen, und bei derselben Maschine und demselben Repository reicht das oft aus. Ich habe beschrieben, wo das aufhört, in Claude Code session handoff.
Lösung: Alles, was Sie ungern zweimal erklären würden, schreiben Sie an einen Ort, den die nächste Session liest, bevor sie anfängt zu arbeiten.
Dieser hier trifft innerhalb einer einzigen Session. Wenn das Kontextfenster voll wird, fasst Claude Code das Gespräch zusammen und fährt mit der Zusammenfassung fort. Die Zusammenfassung behält "wir arbeiten an der Landingpage". Sie verwirft "statisch, weil Streaming 40 ms kostete und niemand Live-Statistiken auf einer Marketingseite braucht." Zehn Minuten später schlägt der Agent fröhlich die Sache vor, die Sie ausgeschlossen hatten, und von innerhalb der Session gibt es keine erkennbare Nahtstelle. Die Mechanik habe ich in why your session forgets mid-task untersucht.
Lösung: Halten Sie Entscheidungen außerhalb des Transkripts fest und bringen Sie sie nach jeder Komprimierung zurück in den Kontext. Claude Code hat genau für diesen Moment einen Hook.
Cursor am Morgen, Claude Code am Nachmittag, Copilot für das Review. Jedes hat seinen eigenen Kontext, seine eigene Regeldatei, seine eigene Vorstellung von Ihrem Projekt. Eine Entscheidung, die in einem davon getroffen wurde, besucht nie die anderen. Deshalb zeigt sich der Widerspruch so oft als "aber das hatten wir doch gestern vereinbart", wobei gestern ein anderes Tool war. Mehr dazu in how to share context between Claude Code and Cursor.
Lösung: Ein Ort, aus dem jedes Tool liest, statt einer Notizdatei pro Tool.
CLAUDE.md,.cursor/rules, copilot-instructions.md. Sie schreiben sie einmal, sorgfältig, und dann bewegt sich der Code weiter, ohne sie. Wenn die Datei sagt "wir nutzen Bibliothek X" und der Code still zu Y migriert ist, muss der Agent sich für eine Seite entscheiden, und er entscheidet an verschiedenen Tagen unterschiedlich. Eine veraltete Regeldatei ist schlimmer als keine, weil der Agent ihr vertraut. Ich habe diesen Fehler genug oft gemacht, um why your CLAUDE.md goes stale darüber zu schreiben.
Lösung: Behandeln Sie Regeldateien als lebendige Dokumente. Entfernen Sie veraltete Einträge, wenn sich eine Entscheidung ändert, und datieren Sie die Entscheidungen, die Sie dort behalten.
Das ist der hinterhältige, und der, den ich am häufigsten sehe. Der Commit sagt "Cache-Schicht entfernen". Ein Agent, der das liest, erfährt, dass es einen Cache gab und jetzt nicht mehr. Er erfährt nicht, dass der Cache Latenz ohne Nutzen hinzufügte. Wenn er also das nächste Mal auf einen langsamen Endpunkt trifft, tut er, was jeder gute Ingenieur tun würde: Er fügt einen Cache hinzu. Er widerspricht Ihnen nicht. Er folgt der einzigen Begründung, die er sehen kann.
Eine Entscheidung ohne ihre Begründung ist nur eine Tatsache, die darauf wartet, umgestoßen zu werden.
Lösung: Ein Satz mit dem Warum, jedes Mal. "Cache-Schicht entfernt: sie fügte 40 ms hinzu und niemand las zweimal daraus." Dieser Satz ist es, der die erneute Debatte verhindert.
Keiner davon ist falsch. Der Fehler ist zu erwarten, dass eine Regeldatei Entscheidungen trägt, oder ein Commit-Log Begründungen.
Ich habe ContextForge gebaut, weil ich diesen Streit mit meinen eigenen Agents mehrmals pro Woche verlor. Die Idee ist klein: Wenn wir etwas entscheiden, speichert der Agent die Entscheidung mit der Begründung im Gedächtnis des Projekts. Die nächste Session, in Claude Code, Cursor oder Copilot, lädt dieses Gedächtnis über MCP (Model Context Protocol) und kann es nach Bedeutung durchsuchen, sodass "Landingpage-Rendering" die Entscheidung für die statische Seite findet, auch wenn niemand diese Worte benutzt hat.
Nach einer Komprimierung druckt ein Hook die letzten Entscheidungen und offenen Aufgaben zurück in den Kontext. Und wenn sich der Code hinter einem Gedächtniseintrag ändert, markiert eine Frische-Prüfung das, sodass der Agent ihn bestätigen, korrigieren oder vergessen kann, statt etwas zu verteidigen, das nicht mehr stimmt.
claude mcp add contextforge -s user \ -e CONTEXTFORGE_API_KEY = your-key \ -- npx -y contextforge-mcp Enter fullscreen mode Exit fullscreen mode Nun der ehrliche Teil.
Würde ein größeres Kontextfenster das beheben? Nein. Ein größeres Fenster lässt eine Session mehr halten, und es endet trotzdem, wenn die Session endet. Die meisten der fünf Ursachen oben passieren zwischen Sessions oder zwischen Tools. Eine längere Antwort habe ich in bigger windows won't save you geschrieben.
Behandelt Claude Codes Auto-Memory das nicht bereits? Teilweise. Es ist nützlich für die Notizen des Agents selbst, und es bleibt auf dieser Maschine, in diesem Tool. Sobald Sie Cursor öffnen oder einen Laptop zu Hause, ist es nicht mehr da.
Sollte ich nicht einfach jede Entscheidung in die CLAUDE.md schreiben? Das funktioniert eine Weile. Dann wächst die Datei, bis der Agent die Hälfte davon nicht mehr beachtet, und Sie sind zurück bei Ursache Nummer vier. Behalten Sie Konventionen in der Regeldatei und Entscheidungen, mit ihren Begründungen, an einem durchsuchbaren Ort.
Schreiben Sie die letzten drei Entscheidungen auf, die Sie mit einem Agenten getroffen haben, jeweils mit einem Satz zum Warum. Legen Sie sie dort ab, wo die nächste Session sie liest: mindestens in Ihrer Regeldatei, in einer Memory-Schicht, falls Sie eine haben. Fragen Sie morgen, bevor Sie den Agenten etwas bauen lassen: "Was haben wir über X entschieden?" Wenn er richtig antwortet, haben Sie gerade alle fünf Ursachen für diese Entscheidung geschlossen. Dann machen Sie es mit den nächsten drei.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 15 • Originally published at contextforge.dev
Originally published on contextforge.dev.
Two weeks ago Claude Code and I spent an afternoon on the ContextForge landing page. We decided it would be fully static, regenerated in the background, and that the live numbers would stream only in the admin. We measured it, it was faster, and I wrote the reasoning into the pull request. The following Tuesday a fresh session looked at the same page and proposed making it dynamic "so the stats are always fresh." Same model, same repo, opposite decision, delivered with total confidence.
If you've searched for why AI coding agents contradict earlier decisions, you've had a Tuesday like that. Here's the honest answer, and it isn't the one I expected when I started digging.
TL;DR: The agent isn't changing its mind. Either the decision never reached the session you're in, or it arrived stripped of the reason behind it. There are five ways that happens, and each one has a cheap fix. The expensive part is turning the fix into a habit.
A language model doesn't hold opinions between calls. Every answer is computed from what's in front of it right now: your prompt, the files it opened, the conversation so far. If a decision isn't in that input, the agent isn't ignoring it. It's reasoning from the code as it is today, and in the code as it is today, the dynamic version of my landing page looks perfectly sensible.
So the frustrating question, "why does it keep contradicting me?", turns into a more useful one: "why wasn't the decision in its input?" I found five reasons. Here they are in the order I hit them.
The obvious one. You and the agent worked something out in a conversation, the conversation ended, and the next session started from nothing. Claude Code can reopen a past session with --resume, and for the same machine and the same repo that's often enough. I wrote about where that stops in Claude Code session handoff.
Fix: anything you'd be annoyed to explain twice, write down somewhere the next session will read before it starts working.
This one bites inside a single session. When the context window fills up, Claude Code summarizes the conversation and continues from the summary. The summary keeps "we're working on the landing page." It drops "static, because streaming cost 40 ms and nobody needs live stats on a marketing page." Ten minutes later the agent is cheerfully proposing the thing you ruled out, and from inside the session there's no seam to notice. I dug into the mechanics in why your session forgets mid-task.
Fix: keep decisions outside the transcript and put them back after every compaction. Claude Code has a hook for exactly that moment.
Cursor in the morning, Claude Code in the afternoon, Copilot for the review. Each one has its own context, its own rules file, its own idea of your project. A decision made in one of them never visits the others. This is why the contradiction so often shows up as "but we agreed on this yesterday," when yesterday was a different tool. More on that in how to share context between Claude Code and Cursor.
Fix: one place every tool reads from, instead of one notes file per tool.
CLAUDE.md,.cursor/rules, copilot-instructions.md. You write them once, carefully, and then the code moves on without them. When the file says "we use library X" and the code has quietly migrated to Y, the agent has to pick a side, and it picks differently on different days. A stale instructions file is worse than none, because the agent trusts it. I've made this mistake enough times to write why your CLAUDE.md goes stale about it.
Fix: treat rules files as living documents. Prune them when a decision changes, and date the decisions you keep there.
This is the sneaky one, and the one I see most. The commit says "remove cache layer." An agent reading that learns there was a cache and now there isn't. It does not learn that the cache added latency for nothing. So the next time it meets a slow endpoint it does what any good engineer would do: it adds a cache. It isn't contradicting you. It's following the only reasoning it can see.
A decision without its reason is just a fact waiting to be overturned.
Fix: one sentence of why, every time. "Removed the cache layer: it added 40 ms and nothing read it twice." That sentence is what stops the re-litigation.
None of these is wrong. The mistake is expecting a rules file to carry decisions, or a commit log to carry reasons.
I built ContextForge because I was losing this argument with my own agents several times a week. The idea is small: when we decide something, the agent saves the decision with the reason, in the project's memory. The next session, in Claude Code, Cursor or Copilot, loads that memory over MCP (Model Context Protocol) and can search it by meaning, so "landing page rendering" finds the static-page decision even if nobody used those words. After a compaction, a hook prints the latest decisions and open tasks back into the context. And when the code behind a memory changes, a freshness check flags it so the agent can confirm, correct or forget it instead of defending something that's no longer true.
claude mcp add contextforge -s user \ -e CONTEXTFORGE_API_KEY = your-key \ -- npx -y contextforge-mcp Enter fullscreen mode Exit fullscreen mode Now the honest part.
Would a bigger context window fix this? No. A bigger window lets one session hold more, and it still ends when the session ends. Most of the five causes above happen between sessions or between tools. I wrote a longer answer in bigger windows won't save you.
Doesn't Claude Code's auto-memory already handle this? Partly. It's useful for the agent's own notes, and it stays on that machine, inside that tool. The moment you open Cursor or a laptop at home, it's not there.
Should I just put every decision in CLAUDE.md? It'll work for a while. Then the file grows until the agent stops honoring half of it, and you're back to cause number four. Keep conventions in the rules file and decisions, with their reasons, somewhere searchable.
Write down the last three decisions you made with an agent, each with a single sentence of why. Put them where the next session will read them: your rules file at minimum, a memory layer if you have one. Tomorrow, before you ask the agent to build anything, ask it "what did we decide about X?" If it answers correctly, you've just closed all five causes for that decision. Then do it for the next three.