How AI Assistants Confidently Work on the Wrong Project

I asked an AI assistant for the build output directory for "this project."

It inspected a repository, found a build process, and gave me a specific answer: dist.

The answer was clear, confident, and completely wrong.

I was asking about ironcodestudios.com, a static site that publishes from public_html. The assistant had inspected a neighbouring project called dnddiceroller.com.

Nothing was wrong with its analysis of that other project. It had solved the wrong problem perfectly.

"This project" contains more ambiguity than it seems

On my machine, several projects live under the same development folder. That is normal for most developers. It is also an easy trap for an AI tool.

Depending on the product and session, the assistant may infer the active project from:

• the current working directory
• the nearest Git repository
• recently opened files
• a previous conversation
• the first familiar configuration file it discovers

Any one of those signals can be stale or misleading.

When I wrote "this project," I knew exactly what I meant because I had the website in mind. The model had no access to that thought. It searched, found a plausible repository, and carried on.

The confidence came from having found good evidence. The evidence just belonged to the wrong codebase.

Why this mistake is dangerous

A wrong answer in chat is annoying. A wrong action in a project can be expensive.

Imagine the same context error applied to:

• a deployment command
• a production environment file
• an app-store identifier
• a database migration
• a cleanup of "unused" assets
• a Git push

The more capable the agent, the more important target verification becomes. An agent that can only explain a command may waste a few minutes. An agent that can edit, deploy, and delete can make the wrong assumption real.

This is not an argument against agentic tools. It is an argument for giving them an unambiguous target.

The simple fix

I could have avoided the entire problem by naming the project:

In C:\Users\Admin\Desktop\dev\ironcodestudios.com, what directory should Cloudflare Pages use as the build output?

Even this shorter version would have been enough:

For the ironcodestudios.com project, what is the build output directory?

Naming the repository costs a few words and removes a large category of guesswork.

For anything involving deployment, credentials, deletion, or release settings, I now expect the assistant to confirm:

1. the absolute project path
2. the repository or remote name
3. the relevant configuration file
4. the command or target it intends to use

That confirmation should happen before the change, not in the explanation afterwards.

Evidence should include location

One habit I find useful is asking the agent to cite the file that supports its answer.

Instead of:

The output directory is public_html.

I want:

The project at C:\Users\Admin\Desktop\dev\ironcodestudios.com deploys public_html, based on its .gitlab-ci.yml and the static files inside that directory.

Now I can spot a context error immediately. If the path or filename is wrong, I do not have to evaluate the rest of the answer.

This is particularly helpful when two projects use similar technology. Both of my sites used Cloudflare, but one produced dist through a build and the other served public_html directly. General knowledge could not distinguish them. Only project-specific evidence could.

The assistant should verify too

The responsibility is not entirely on the person writing the prompt. A good coding agent should treat ambiguous project references as a reason to inspect its environment carefully.

Before acting, it can check:

• Where am I currently working?
• Is this directory the project the user named?
• Are there sibling repositories that also match the request?
• Does the Git remote agree with the expected project?
• Which file actually defines the deployment?

If the answer remains unclear and the action matters, that is the point to ask a question.

Confidence is not context

The uncomfortable part of this incident was how reasonable the wrong answer looked. dist is a common build output directory. The assistant had inspected real code. There was no obvious hallucination.

That is why these errors survive. We tend to challenge bizarre answers, but plausible ones slide through.

The lesson I kept is simple:

Never use "this project" when the machine contains more than one project and the answer could trigger a real change.

Name the target. Confirm the path. Ask for the evidence.

An AI can be completely right about the wrong repository.