I've just had the most amount of hallucinations ever in one session. My model is completely making shit up. I have no idea where is this coming from, because I have not modified any of the foundational/instruction files or changed my processes. It's undertaking tasks or modifying files in ways I didn't ask for and it seems to be 'assuming' what I want instead of listening to instructions and its constantly forgetting context now. I'm thinking of removing and reloading Claude Code too if its a potential caching issue similar to the old 'memory' files issue I was having where it was generating custom instruction files outside of our working directory which were negating my claude.md, etc. Anyone else seeing issues increase lately?

Most people drive AI like a slot machine. Type a vague wish, pull the lever, hope. Wrong output, pull again. Three hours later: forty messages, half right code, no idea which version was good. That is not building. That is gambling with extra steps. The fix is not a cleverer prompt. It is a plan. Here is the exact habit, start to finish. The one idea Stop prompting. Start defining outcomes. A prompt is a wish. An outcome is a result you can check. AI accelerates, it does not generate. Point it at a clear target and it closes the gap fast. Point it at a vague one and it just gets lost faster. ———————————————————————— The chain (this is the whole method) 1. Brainstorm first. Do not open a chat and start barking instructions. Open a conversation whose only job is to decide what you are building. What does done look like. What must be true. What is out of scope. I use `/brainstorm` and answer one question at a time until the fog clears. 2. Freeze it in a spec. A spec is the brainstorm written down and made hard to argue with. Three parts: - Objective, in one sentence you could prove true or false. - Constraints, the rules that bound the solution. - Definition of done, where every item can be checked with a single action. If you cannot write the objective sentence, you are not ready to build. Better to learn that now, for free. 3. Break it into a phased plan. Turn the spec into ordered, bite sized phases. The rule that matters most: each phase must be small enough to finish in one sitting, with room to spare. 4. Hand each phase over as a typed brief. This is the part that does the heavy lifting. Read the next section. ———————————————————————— Think in PRDs A typed brief is a product requirements document, scaled to whatever you are making. It is the difference between "build me a settings page" and a short doc with a goal, constraints, acceptance criteria, and phases. It feels like bureaucracy. It is the opposite. The brief is a forcing function: - You cannot write acceptance criteria for a feature you do not understand.