We were standing in the sun after a race, a few of us, drinks in hand, legs still figuring out what just happened. The conversation drifted the way it does in those moments, nothing heavy, just people unwinding. And then someone said it.
“I always say thank you when the AI does something good. Just in case.”
Everyone laughed. Including me. Because we all knew exactly what they meant.
There’s a joke living inside every tech-adjacent social circle right now and it goes something like this: the AI apocalypse is coming, nobody knows exactly when, but it’s probably better not to have been ungrateful to the thing. Say please. Thank it when it helps. Grovel a little. Hedge your existential bets while the sun is still out.
It’s funny because it’s a little bit true. Tomorrow always feels like it might actually come this time.
On the bike home I stopped near the St. Vrain because a blue heron and a duck had landed in the same stretch of water at the same moment. Just there together. Two completely different creatures, existing on completely different terms, neither one asking the other for anything.
I thought about that for a while.
Gratitude isn’t the same thing as giving something what it needs. You can say thank you a hundred times and still hand the tool a prompt with half the context missing. The groveling lands. The structure doesn’t.
That’s the actual problem with the AI manners conversation. Not that it’s wrong to be considerate. It’s that we’re solving for the wrong thing entirely.
That same week, Andy Jordan published Mind Your AI Manners on ProjectManagement.com. The argument is familiar: treat AI like a team member, bring your manners, good things follow. Politeness as cultural safeguard and performance enhancer.
I respect the intent. Jordan wants teams to build healthier habits around AI. That’s a real goal worth taking seriously.
But the framing gets the problem wrong. And wrong framing builds wrong habits.
The question isn’t how you talk to AI. It’s how you work with it.
The “AI manners” conversation treats tone as a meaningful input to output quality. It suggests that saying “please” and “thank you” creates a kind of relational equity, that the system remembers, adapts, and rewards you for being nice.
That isn’t how any of this works.
A large language model doesn’t have a relationship with you. It processes tokens. Every word in your prompt, including “please,” gets converted into a numerical representation, run through layers of pattern matching, and used to predict the most likely next sequence of text. Your politeness doesn’t build goodwill. It adds tokens.
I was building a prompt and Claude generated one with “please” in it. I was using Claude to build prompts for Claude Code. The AI had been polite to the AI. I asked about it. The answer: being direct and specific is what actually matters. Please doesn’t change the output, the code quality, or how the instruction gets parsed.
That’s the structural reality that should shape how teams design their AI interactions. Skip past it to talk about manners and you lose the thread on what actually drives results.
What Jordan gets right, and where the logic breaks
Jordan makes a fair point about behavioral spillover. If teams develop a transactional, curt style with AI, there’s a reasonable concern it bleeds into how people communicate with each other. Culture is shaped by habits. I don’t dismiss that.
But then the argument extends into territory that doesn’t hold up.
Jordan writes that the system “will doubtless add that exchange to the data about this individual,” implying your gratitude becomes a persistent data point shaping future interactions. The reality is more complicated and it matters more than the manners question does.
Whether your input persists depends entirely on the product architecture: what gets logged, what gets retained, what feeds into memory features, what routes into model training. These vary by platform, by plan type, and by user settings. Whether your “thanks” goes anywhere beyond the current conversation is a question of contracts and configurations. Not manners.
This shifts the locus of control in a meaningful way. If you think politeness builds a productive AI relationship, you’ll manage tone. If you understand the actual architecture, you’ll manage structure. Only one of those produces consistent results.
Politeness is a weak proxy for what actually works
There is research suggesting polite prompts can sometimes produce marginally different outputs. A cross-lingual study found that impolite prompts often hurt performance, while overly polite prompts didn’t reliably improve it. Other evaluations found effects were model dependent and washed out in aggregate. Mixed at best.
But there’s a reason polite prompts sometimes correlate with better results, and it has nothing to do with the AI appreciating your manners.
People who write politely tend to write more complete sentences. They add context. They specify what they want. They frame the ask with enough structure that the model has something meaningful to work with.
The politeness isn’t the variable. The clarity is.
That’s the distinction buried in the “AI manners” framing and it’s the one that matters most for teams trying to get real value from these tools. You don’t need to be polite. You need to be precise. Context, constraints, acceptance criteria — that’s what the model actually needs.
A Yeti cooler doesn’t need to be asked nicely. It needs ice.
That’s not a manners problem. That’s an operational discipline problem.
What actually chills the drinks
When I’m advising teams on how to improve their AI interactions, I don’t start with tone. I start with structure. Here’s what actually moves the needle.
Define acceptance criteria before you prompt. What does a useful output look like? What format, what level of detail, what should it not include? The same discipline you’d apply to a project requirement applies here. If you can’t define what good looks like before you ask, the model can’t guess its way there after.
Provide relevant context, not conversational filler. The tokens that matter are the ones carrying information: background, constraints, examples, prior decisions. A prompt with three sentences of context about your stack and your audience will outperform a prompt that opens with “Hey, hope you’re doing well” every single time.
Manage your conversation state deliberately. LLMs don’t have memory the way people assume. In most configurations they work within a context window. As that window fills up, older context gets compressed or dropped. Starting a fresh thread when the task changes isn’t rude. It’s operational hygiene.
Treat data retention and privacy as design decisions. Know what your platform logs, what it retains and what it uses for training. This isn’t a governance checkbox. It’s a first-class constraint, especially when prompts contain sensitive project data, client information, or proprietary strategy.
Evaluate outputs against criteria, not vibes. When the AI gives you something back, check it the way you’d check a deliverable from any contributor. Does it meet the spec? Is it accurate? Is it complete? If your feedback loop is “that feels about right,” your process has a gap.
None of this requires politeness. All of it requires discipline.
The deeper issue with the “team member” metaphor
Jordan’s framing of AI as a team member is designed to make adoption feel less intimidating. I get that instinct completely. But it carries a real risk worth naming.
When you tell people to treat AI like a colleague, you’re encouraging a mental model built on trust and social accountability. Human team members can be held accountable. They can explain their reasoning. They can escalate when something is wrong. AI does none of these things. It produces the most statistically likely next token, with no awareness of whether that output is correct. It doesn’t know when it’s wrong. It doesn’t flag uncertainty. It doesn’t push back when your prompt is headed somewhere unhelpful.
The team member metaphor can actually erode the critical thinking Jordan says he wants to protect. Research on anthropomorphic interfaces suggests that when people feel like they’re in a collaborative relationship with a tool, they’re more likely to over-trust and under-verify. That’s not a safer working environment.
The better framing: AI is a well-built tool with no judgment. Like any well-built tool, it responds to how it’s configured and how it’s used, not to how it’s addressed. It requires governance, not rapport.
This isn’t about being rude. It’s about being intentional.
I’m not arguing for rudeness. Being curt doesn’t help anything, and if saying “please” makes you more comfortable with the tool, that’s completely fine. Comfort matters for adoption.
But comfort is not strategy.
The teams I’ve seen succeed with AI aren’t the politest. They’re the most structured. They define outcomes before they start. They treat prompts like requirements, not conversations. They build feedback loops that catch bad outputs early. They understand what the tool can and can’t do in the specific context of their platform, their data and their workflows.
That’s the discipline that scales. Not manners. Structure.
The heron and the duck were just there together in the same stretch of water. Neither one adjusting its nature for the other. Each one doing exactly what it was built to do.
That’s the relationship worth understanding.
If you’re curious about how I actually use Claude in practice — not theoretically, but day-to-day — that’s what the next post is about. And if you want context on my background with AI integration and operational work, you can find that on the about page.
If you want to bring this kind of operational discipline to your own AI workflows, my consulting work is built around exactly this — structured implementation, not theory.