Solving a hallucinated dependency bug with Aider CLI coding

A developer reported that Aider CLI, paired with Anthropic's Claude 3.5 Sonnet, repeatedly hallucinated a dependency on the library 'fastapi-utils' during a FastAPI refactor, rewriting requirements.txt and crashing the test suite with a ModuleNotFoundError over a four-hour session. The developer resolved the loop by adding a session rule barring new dependencies without explicit approval, resetting the environment with 'pip freeze > requirements.txt', and using Aider's '/drop' command to clear the files from active context. The account highlights how a hallucinated dependency entering an AI coding assistant's chat history can persist and steer subsequent suggestions.

Solving a hallucinated dependency bug with Aider CLI coding I spent four hours last Thursday fighting a ModuleNotFoundError that shouldn't have existed. I was using Aider with Claude /en/tags/claude/ 3.5 Sonnet to refactor a FastAPI project, and for some reason, the AI kept insisting I install a library called fastapi-utils for a task that the core FastAPI package already handles. It wasn't just a suggestion; Aider kept rewriting my requirements.txt and then crashing when it tried to run the test suite. The fix was a simple prompt change and a hard reset of the environment, but it highlighted a massive gap in how we trust AI-driven CLI edits. Why did Aider keep installing the wrong package? The loop looked like this: Aider would suggest a feature, realize it needed a specific utility, "remember" an old pattern from its training data where fastapi-utils was common , and blindly add it to the dependencies. When I ran the tests, I got this: ModuleNotFoundError: No module named 'fastapi utils' I told Aider, "You don't need that library, use the built-in dependency." It would apologize, remove the line, rewrite the code—and then, three prompts later, it would re-add the library because it "thought" it was the most efficient way to handle the logic. The problem wasn't the model's intelligence; it was the context window and the way Aider manages the "chat" history versus the actual file state. It was hallucinating a dependency based on a pattern it liked, ignoring the fact that the current environment didn't support it. How I broke the hallucination loop I stopped trying to "convince" the AI and started using constraints. Instead of saying "Don't use that," I gave it a strict rule for the session. I created a .aider.conf.yml or just pasted this into the chat as a system instruction specifying: Strictly avoid adding new dependencies to requirements.txt unless I explicitly approve them in a separate prompt. Once the boundaries were set, I did a surgical cleanup. I ran: pip freeze requirements.txt to reset the state to a known-good version. Then, I used the /drop command in Aider to clear the specific files from its active context that were triggering the hallucination. The wild part? After clearing the context, the AI suddenly "remembered" how to do the task using only standard FastAPI. It turns out that once a hallucination enters the chat history, it acts like a gravity well—every subsequent suggestion gets pulled toward that error. Aider vs Cursor /en/tags/cursor/ for heavy refactoring I use both, but they serve different psychological needs. Cursor is great for when I'm "exploring" code—highlighting a block and asking "what is this doing?" Aider is for when I'm in "execution" mode. Because Aider works directly in the terminal and handles git commits automatically with those surprisingly decent auto-commit messages , it's faster for sweeping changes across ten files. Here is how they stack up for me in a real workflow: | Feature | Aider CLI | Cursor | | :--- | :--- | :--- | | Context Management | Manual /add and /drop | Automatic codebase indexing | | Commit Workflow | Automatic git commits per change | Manual git commits | | Speed | Fast no GUI overhead | Medium UI can lag on large files | | Precision | High specific file targeting | High Composer mode | If you're doing a massive migration, Aider's ability to target specific files and then commit them incrementally is a lifesaver. If you mess up, you just git reset --hard and try a different prompt. Getting better results through community patterns The biggest mistake I made early on was treating the AI like a magic wand. Now, I treat it like a junior dev who is incredibly fast but occasionally lies about what's possible. I've found that the most effective way to stop the "hallucination loop" is to reference proven patterns. I spend a lot of time browsing Prompt Sharing /en/category/prompts/ to see how others structure their "system" prompts to keep the AI on track. For example, telling the AI to "think step-by-step in a hidden scratchpad before writing code" drastically reduces those weird dependency errors. The "too many files" bottleneck Another wall I hit last week was context overflow. Aider lets you add files to the chat, but if you add 20 files, the quality of the code generation plummets. The AI starts forgetting the logic in file A while editing file B. My current rule: Never have more than 5 files in the Aider context at once. If I need to change a function that affects five other files, I do it in stages. 1. Add the core logic file + the target file. 2. Apply the change. 3. /drop the core file. 4. Add the next target file. It's tedious, but it prevents the AI from getting "confused" by too much noise. When to ditch the AI and go manual There's a point of diminishing returns. If I've spent more than 15 minutes prompting an AI to fix a bug and it's still giving me the same wrong answer, I stop. AI tools are great for boilerplate and refactoring, but they suck at "deep" debugging where the error isn't in the code, but in the architecture. If you're fighting a race condition or a memory leak, the AI will often suggest "standard" fixes that don't apply to your specific edge case. At that point, I turn off the AI, open the debugger, and actually read the stack trace. Joining the PromptCube community If you're tired of fighting these same loops, joining a community like PromptCube is the fastest way to level up. It's not about finding a "perfect" prompt—those don't exist because models change every few months. It's about sharing the process of debugging. You can join by signing up on the platform, where you can test different models side-by-side and see which one handles your specific codebase better. Whether you're using Aider, Cursor, or building your own agentic workflow, having a place to verify your prompts against real-world results saves hours of frustration. Next LoRA rank 4 is the sweet spot for diffusion fine-tuning → /en/threads/9280/