There is a very specific kind of frustration that only developers using AI every day understand. You open a repo, something does not run, and you have already tried the obvious things. The README is either outdated, incomplete, or written with the confidence of someone who has never cloned the project on a fresh machine.

So you do what most of us now do. You open Claude, ChatGPT, Cursor, or whatever agent is currently living rent-free in your workflow and type:

And then the AI tries. It really does. It reads files, guesses the framework, suggests installing dependencies, asks you to run commands, and confidently explains something that is almost correct. Then, twenty minutes later, you are still staring at the same error. Only now you are also annoyed at a machine.

Which is a very modern emotion.

The problem is not always the AI

It is very easy to blame the model. And to be fair, sometimes the model deserves it. AI does hallucinate. It does make assumptions. It does confidently invent package names, environment variables, migration steps, and occasionally an entire alternate universe where your codebase is better organized than it actually is.

But after using AI heavily for development, writing, debugging, planning, and almost every other mildly complicated thing, I have started noticing something uncomfortable. A lot of the time, the AI is not failing because it is stupid. It is failing because I explained the problem badly. Not always. But often enough to hurt.

We say things like:

And then we expect the AI to understand the entire hidden world behind those four words. The context. The intent. The trade-offs. The thing we already tried. The thing we absolutely do not want. The weird production constraint. The reason this bug matters. The fact that "better" means "cleaner but not over-engineered". The fact that "fix" means "minimal change because this is going to prod tomorrow". Hushhhh!

We forget to say all of that. And then we get surprised when the AI wanders off.

We are not writing prompts anymore

When AI tools first became popular, everyone talked about "prompt engineering". It sounded very technical. Almost like there was a secret syntax. Use this structure. Add this role. Mention this constraint. Say "think step by step". Ask it to behave like a senior staff engineer who has seen war.

Some of that works. Prompting techniques are useful, and there are genuinely good frameworks around zero-shot prompting, few-shot prompting, etc. Sites like Prompting Guide explain these ideas well.

But the more I use AI, the more I feel that "prompt engineering" is too small a phrase for what we are actually doing. We are not just writing prompts. We are having conversations. Long ones. Messy ones. Sometimes painfully repetitive ones.

That is not prompt engineering. That is communication!

Context is not the same as understanding

This is where things get interesting. Modern AI tools have become very good at getting context. They can read your repository, inspect files, call tools, use MCP servers, search docs, run terminal commands, remember previous instructions, generate patches, and create summaries of summaries of summaries.

And yet, even with all of that, they still often miss the point. Because context only tells the model what exists. It does not automatically tell the model what matters. That difference is everything.

A repo can have five authentication flows, three deprecated folders, two half-migrated services, one cursed utility file, and a README that still believes it is 2021. If you simply say "add login support", the AI may technically have context, but it does not have judgment. It does not know which auth flow is legacy, which service is preferred, whether you want a quick fix or a long-term refactor, whether the team hates adding new dependencies, or whether this is for a demo, a production release, or a random experiment you will abandon after lunch.

That is your job. Not because AI is weak, but because intent still has to come from somewhere.

The bad prompt is usually missing the story

Let us take the classic developer prompt.

This sounds reasonable. It is also almost useless. Not because it is short, but because it gives the AI no story. A better version would be something like this:

This is not a magic prompt. It is just a better explanation. It includes what you are trying to do, what kind of project it seems to be, what you already tried, what failed, what you care about, what you do not care about, what you want the AI to do first, and what you do not want it to do yet.

That last part is underrated. AI agents are increasingly eager. Sometimes too eager. You ask them to inspect a bug and they start editing eight files like a junior developer on energy drinks. So you have to define the pace of the conversation, not just the task.

Talk to it like a teammate, not a search box

This is where the relationship part starts sounding less stupid. Because the best way to work with AI is often the same way you would work with a new teammate.

You would not walk up to a new engineer and say "fix checkout" and then disappear. You would explain. Checkout is failing only for guest users. It started after the new coupon logic was merged. Stripe is not the issue. The logs point to our own validation layer. Please avoid touching the payment provider code. We need a low-risk patch today and can clean it up later.

That is not over-explaining. That is giving them a map. AI needs the same map. The difference is that with AI, we often skip the map because the tool feels powerful. It can read fast. It can write fast. It does not get tired. It does not complain. It says "Sure!" with dangerous enthusiasm. So we assume it understands.

But speed is not understanding.

A useful pattern for technical prompts

I have started using a simple structure when asking AI for technical help. Not always formally, but mentally, this is the shape:

For example:

This kind of prompt does not make the AI perfect. But it reduces the number of ways it can be wrong. And that is most of the game.

Prompt engineering is really ambiguity engineering

A lot of prompting advice is basically about reducing ambiguity. Few-shot examples reduce ambiguity by showing the expected pattern. Role prompting reduces it by setting the lens. Structured output reduces it by defining the shape of the answer. MCPs reduce it by giving the model access to real systems and real context.

But none of these fully remove ambiguity if your actual request is unclear. You can connect the AI to your GitHub, Jira, Slack, Notion and maybe your soul. Still, if you say "make it better", it has to guess what "better" means.

Better can mean faster. Better can mean cleaner. Better can mean simpler. Better can mean more scalable.

The word "better" is carrying too much emotional load. So the AI guesses. And when it guesses wrong, we call it hallucination. Sometimes it is. Sometimes we just gave it fog and expected architecture.

Your AI agent has no taste unless you give it taste

Ask an AI to "write a blog on AI", and you will probably get something polished, generic, and spiritually dead. Ask it instead to "write a technical blog about how developers are learning to communicate with AI agents, with a reflective and slightly funny tone, not LinkedIn-ish, grounded in real developer workflows, avoiding hype and generic lines like 'AI is changing the world', and using examples from debugging, running repos, MCPs, and prompt clarity", and now you are giving it taste.

Taste is context too. Developers often think taste only matters in writing or design, but it matters in code as well. When you ask AI to write code, you are also asking it to make taste decisions. Should this be abstracted? Should this be inline? Should this be a helper, a hook, a service?

The AI can answer all of those. But it needs to know what kind of engineering culture it is operating inside. Some teams love abstractions. Some teams fear them.

The model does not know your team's taste unless you tell it.

Hallucination loves silence

AI hallucination is not only a model problem. It is also a silence problem. When important details are missing, the model fills gaps. That is basically what it does.

Sometimes this is useful. When writing, gap-filling can feel like creativity. When coding, gap-filling can become a fake API, a wrong assumption, or a solution to a problem you do not have.

So one of the most useful things you can say to AI is something like:

This sounds simple. But it changes the conversation. You are no longer asking the AI to perform confidence. You are asking it to expose uncertainty. And that is where useful work begins.

The best prompts create a small world

A good prompt does not need to be long. It needs to create a small world where the AI knows how to behave.

For example:

This creates a world. The AI now knows the mood. It knows this is a production issue, the kind where you move carefully, where brainstorming, rewrites, tutorials, and casual framework migration suggestions all stay outside the room.

That is what good communication does. It sets the room.

Maybe AI is teaching us to explain ourselves

This is the part I did not expect. Working with AI has made me more aware of how badly I sometimes explain things. Not just to machines. To people too.

I notice when I ask vague questions. I notice when I hide the real constraint. I notice when I say "simple" but mean "low maintenance".

AI reflects that back brutally. It does not understand the unsaid thing unless it gets lucky. And when it gets lucky, we call it magic. When it does not, we call it dumb. But somewhere between those two reactions is a more useful lesson.

The quality of AI output is often a mirror of the quality of our own thinking. Not always. But enough.

So, how do you actually talk to AI?

Talk to it like a very fast teammate who has read a lot, forgets common sense occasionally, and needs clear boundaries.

Give it the problem, not just the task. Give it the reason, not just the command. Give it constraints, not just goals. Give it examples when taste matters. Tell it what to avoid. Ask it to state assumptions.

And most importantly, do not confuse politeness with clarity. Saying "please" is nice. But saying what you actually mean is kinder.

The new language

All of this may sound slightly cringe. A relationship with AI. A rapport with your agent. A shared language between you and a machine. Fair. But anyone who uses these tools seriously knows there is some truth in it.

You start developing patterns. The AI starts becoming part of how you think through work. You learn when to ask for code, when to ask for options, when to ask for critique, when to ask for a smaller diff, when to stop and think yourself. At some point, the tool stops feeling like a search box. It becomes a conversation layer between your half-formed thought and the thing you are trying to build.

And maybe that is the real skill. The real skill is learning how to express intent clearly. Because no matter how good the models become, no matter how many MCPs we connect, no matter how much context we throw at them, one thing remains painfully true.

AI can help us build what we mean. But first, we have to know how to say it.