Why Your AI Assistant Keeps Inventing File Paths

Photo by Ian Ward on Unsplash

Your AI assistant keeps inventing file paths because it doesn't read your project — it predicts plausible-looking text one token at a time. When it needs to reference a file, it doesn't look up where that file actually lives. It guesses the path that statistically appears most often in code like yours, based on millions of other projects in its training data. Most of the time the guess is close. Sometimes it's src/components/Button.tsx when your button is really at platform/components/ui/button.tsx — and the AI states it with total confidence. This is the same mechanism behind every AI code hallucination, and once you understand it, the fix is straightforward.

TL;DR

• AI assistants generate text probabilistically. A file path is just more text to predict, not a lookup against your real folder structure.
• When the real file is outside the model's context window, it fills the gap with a statistically likely guess — often a wrong one.
• A 2025 USENIX study found AI coding models invent packages that don't exist ~20% of the time. File-path invention is the same failure.
• The fix: give the assistant your real structure (a project map / rules file), keep sessions scoped, and verify every path before you run anything.

What's actually happening under the hood

A large language model doesn't have a mental picture of your codebase. It has a statistical model of what code looks like. When you ask it to import a component or edit a file, it produces the sequence of characters that best matches the patterns it learned during training.

The USENIX Security researchers who ran the definitive study on package hallucinations put the mechanism plainly: hallucinations are "a natural by-product of how LLMs operate. These models generate text probabilistically, meaning their outputs are inherently non-deterministic and subject to random sampling errors." The same randomness that lets the model write creative, fluent code is exactly what lets it write a confident, fluent, wrong file path.

Here's the part non-tech founders miss. When the model wrote import { isLoading } from './hooks/useAuth', it didn't check whether useAuth exports isLoading. It wrote isLoading because in roughly 90% of the auth hooks on the public internet, that's what the export is called. It regressed to the average of its training data instead of reading your file — because your file wasn't in front of it. The model filled the gap with the most probable guess.

The USENIX authors reach for a car-navigation analogy that captures the danger well. Picture a GPS that has guided you home reliably for years, so you trust it without thinking. One evening it confidently routes you to an empty field miles from anywhere. The system isn't malfunctioning in an obvious way — it's doing exactly what it always does, just wrong this time, and delivering the wrong turn with the same calm certainty as every right one. That's your coding assistant with an invented path. The confidence is identical whether it's correct or fabricating, which is precisely why it slips past you.

Path invention is that behavior applied to folders. The assistant "knows" that React projects usually put components in src/components/, so when it can't see your actual layout, it writes src/components/. If your project is structured differently — as many boilerplates are, deliberately — the path is fiction. I broke down the broader family of these mistakes in common AI hallucinations in code; file paths are one of the most common and most avoidable.

It's more common than you think

If your instinct is "surely this is rare," the data says otherwise. The 2025 USENIX study tested 16 leading code-generation models across roughly 19,000 prompts in Python and JavaScript, checking whether the packages the models recommended actually existed. The result: an average package hallucination rate of 19.6% — nearly one in five recommended packages simply did not exist.

Commercial models did better, around 5%, while open-source models averaged about 21%. Across all the testing, the models generated 205,474 unique non-existent package names. That's not a rounding error. That's a structural property of the tool.

Package names and file paths aren't the same thing, but they hallucinate for identical reasons: both are identifiers the model predicts rather than verifies. If a frontier model invents a plausible package one in twenty times, it will invent a plausible path under the same conditions — whenever the true answer isn't in its context.

Two more findings from that study matter for founders. First, persistence: about 45% of hallucinated packages reappeared every single time the model was given the same prompt, and roughly 60% showed up again within ten tries. Wrong guesses aren't random noise you can shake off by re-rolling — the model is often reliably wrong in the same way. Second, confidence. The researchers noted that models "are optimized to sound fluent, authoritative, and helpful even when they're wrong," and that "confident errors are far more dangerous than hesitant ones." Your assistant will hand you a fake path with the exact same tone it uses for a correct one.

Why it hits non-tech founders hardest

An experienced developer catches an invented path in seconds. They glance at the import, think "that's not where that lives," and fix it before it costs anything. They have a mental map of the project and years of pattern recognition for what a wrong path looks like.

You might not have either yet. That's not a knock — it's just the situation, and it's the exact situation I was in when I started building Coding Capybaras. When the assistant writes import Button from '@/components/Button' and your button is actually at @/platform/components/ui/button, an engineer sees the error. A first-time founder sees confident code from a tool that's been right all morning, and runs it.

Then one of two things happens. The friendly case: the build fails with "module not found," you paste the error back, and the assistant fixes it. Annoying, but recoverable. The dangerous case is the package version of this bug. The assistant tells you to install a package that doesn't exist — and a malicious actor has already registered that exact hallucinated name on the public registry. Security researcher Seth Larson named this attack "slopsquatting," and it's a real, documented supply-chain risk. You run one install command, and you've imported someone else's code into your app. A founder who can't read the code is the least equipped person to notice.

This is why "just trust the AI" is bad advice for our audience specifically. The tool is genuinely great. But the burden of skepticism, as the USENIX authors put it, "remains entirely on the user." I wrote a whole framework for that judgment call in when to trust your AI assistant.

The fix, in four moves

You can't retrain the model. But you can change the conditions that make it guess. Every fix below works by getting the real answer into the model's context so it never has to fill a gap.

1. Give it a map of your project

The root cause is missing context — the model can't see your structure, so it invents one. So show it. A standing rules file (Claude Code reads a CLAUDE.md; Cursor uses rule files) that describes your directory layout turns guesses into lookups.

The Coding Capybaras boilerplate ships one of these in every region. Mine literally says which folders exist and what belongs in each: /platform for locked infrastructure, /website for marketing, /product for the app, with the rule that components come from @/platform/components/ui/*. When the assistant has that in context, it stops writing src/components/ — it writes the path that's actually true. This is the single highest-leverage fix, and I go deep on it in prompt engineering for non-developers.

2. Keep the real files in the window

The model can only reference what it can see. If you're editing a file, make sure the assistant has actually read it in this session, not "remembered" it from earlier. In tools like Claude Code, opening or referencing the specific file pulls its real contents — including the real export names and the real path — into context. A path the model just read is far more likely to be correct than one it's reconstructing from memory.

3. Scope your sessions

Long, sprawling sessions are where invention creeps in. As the conversation grows, older facts get pushed out of the working context and the model leans harder on its training-data averages. Start a fresh session for a distinct task, restate the relevant structure, and keep each session focused. Shorter, tighter context means fewer gaps to fill with guesses.

4. Verify before you run

Never run an install command or trust a new file path just because it looks right. For paths, the tool will usually tell you immediately — a wrong path throws "module not found." For packages, check that the name actually exists before installing: look it up on the real registry, or ask the assistant to confirm it and cite the source. Notably, the USENIX study found that models like ChatGPT could identify their own hallucinated packages about 80% of the time when asked to re-examine — so a simple "does this package actually exist? double-check" catches a lot. Building that verify-first habit is the core of a debugging workflow with Claude Code. It feels slow the first week and becomes automatic by the second — and it's the single behavior that separates founders who ship steadily from ones who get stuck chasing phantom errors they can't diagnose.

A worked example: watching it happen in real time

Let me make this concrete, because the abstract version ("it predicts tokens") is hard to act on. Here's the exact shape of the bug as it shows up in a real session.

You ask your assistant to add a "loading" spinner to your sign-in button. It responds confidently:

import { Button } from '@/components/ui/button'
import { useAuth } from '@/hooks/useAuth'

Every line of that looks reasonable. It compiles in your head. And in a stock Next.js starter, it might even be correct. But in a project with a deliberate structure — like the three-region layout Coding Capybaras uses — the real imports are @/platform/components/ui/button and there is no @/hooks/useAuth at all; auth lives somewhere else entirely. The assistant didn't check. It pattern-matched against the thousands of tutorials where those exact paths are correct.

Watch what determines the outcome from here. If you have a rules file loaded that spells out your structure, the assistant never writes those lines — it writes the true paths, because the true answer is in its context. If you don't, you run the code and get Module not found: Can't resolve '@/hooks/useAuth'. For a developer that's a two-second fix. For a first-timer it's a confusing wall of red text at the exact moment you thought you were done.

The instructive part is what you do next. The right move is to paste the error straight back and ask, "this path doesn't exist — what's the real location of the auth hook in this project?" That forces the assistant to look rather than guess. The wrong move is to start hand-editing paths yourself by trial and error, because you'll often "fix" a symptom while the underlying wrong assumption stays in the conversation and resurfaces two edits later. Remember the persistence finding: the model is often reliably wrong in the same way, so you have to correct the assumption, not just the one line. This is the whole reason I lean on a tight feedback loop with the assistant, which I wrote about in building a feedback loop with your AI.

One more habit worth building: when a path matters, ask the assistant to show you it exists before relying on it. "List the files in the components directory" or "read the auth file and tell me its exact export names" costs you ten seconds and replaces a guess with a fact. You don't need to read code fluently to do this. You just need to make the tool prove its claim instead of asserting it.

Frequently asked questions

Why does my AI assistant confidently give wrong file paths?

Because it generates paths by predicting likely text, not by reading your folder structure. If the real file isn't in its context, it produces the path that's statistically most common in similar projects. It sounds confident because language models are tuned to sound fluent and authoritative regardless of whether they're correct.

Is inventing file paths the same as hallucinating packages?

Yes, mechanically. Both are identifiers the model predicts rather than verifies. A 2025 USENIX study found leading models recommend non-existent packages about 20% of the time. File paths fail the same way and for the same reason: the true value wasn't in the model's context, so it guessed a plausible one.

How do I stop Claude Code or Cursor from making up paths?

Give it your real project structure in a rules file (like CLAUDE.md), make sure the actual files are loaded into the session before editing, keep sessions scoped to one task, and verify paths before running anything. The goal is to remove the gaps the model would otherwise fill with a guess.

Are invented package names dangerous?

They can be. Attackers register commonly-hallucinated package names on public registries — a practice called "slopsquatting" — so that when your assistant recommends the fake name and you install it, you get malware. Always confirm a package exists on the real registry before installing, especially one you don't recognize.

Will better AI models fix this completely?

They'll reduce it, not eliminate it. The USENIX researchers describe hallucination as "a structural consequence of how these systems operate," not a bug to be patched. Newer models and techniques like retrieval shrink the error rate but can't zero it out. Verification stays part of the workflow for the foreseeable future.

The takeaway

Your AI assistant invents file paths for the same reason it invents package names and citations: it predicts plausible text instead of checking reality, and it does it with a confident voice that gives you no reason to doubt it. The behavior is baked into how the tool works — but the conditions that trigger it are entirely in your control. Give the model your real structure, keep the real files in view, scope your sessions, and verify before you run. Do that and path invention drops from a daily headache to a rare, obvious blip. It's the same root problem that makes a well-structured boilerplate matter so much for non-tech founders.

If you're shipping a SaaS with AI coding tools, Coding Capybaras is the free boilerplate I built with rules files in every region — specifically so your assistant stops guessing and starts following your actual architecture.