The tech industry has a massive blind spot when it comes to Artificial Intelligence. If you read the standard advice online, everyone tells you that the secret to mastering Large Language Models (LLMs) is learning how to have a better “chat.”
The prevailing wisdom treats the algorithm like a new hire on your team: brainstorm with it, give it gentle feedback, and collaborate your way to a final product. There are even serious debates happening right now about whether maintaining basic digital etiquette – like typing out polite requests and expressing gratitude -makes models perform better.
Let’s get one thing straight: AI is not your coworker. It does not have feelings, it does not care about your manners, and treating it like a human being is actively hurting your productivity and the quality of your output.
When you treat AI like a colleague, you bring the inefficiencies, ambiguities, and emotional padding of human conversation into a system designed for raw execution. You negotiate. You use filler words. You hope it understands your vague requests. But if you want to extract real, scalable value from AI -especially in complex engineering, cloud infrastructure, or business automation -you need to stop conversing and start commanding.
The Financial and Cognitive Cost of Politeness
The habit of treating algorithms like humans isn’t just a philosophical annoyance; it is a measurable waste of resources.
In April 2025, OpenAI CEO Sam Altman revealed that the simple act of millions of users typing “please” and “thank you” to ChatGPT had cost the company tens of millions of dollars in electricity and operational expenses. Every polite pleasantry requires computational power to process, parse, and generate a correspondingly polite response. [source]
But the cost isn’t just financial. It directly impacts your results. When you pad your prompts with conversational filler (“Hi there, could you please help me with…” or “I would really appreciate it if you could…”), you are eating up the model’s context window. More importantly, you are diluting the model’s attention mechanism. LLMs operate on statistical probability, weighing the importance of every word you feed them. When you introduce conversational fluff, the model has to spend “attention” analyzing your politeness instead of focusing entirely on your technical constraints.
What the Data Actually Says About Being “Nice”
If you still think being polite yields better results, the data says otherwise.
In late 2025, researchers from Penn State University published a comprehensive study on how prompt politeness affects LLM accuracy. They took 50 complex multiple-choice questions spanning math, science, and history, and rewrote them across five tonal variants: Very Polite, Polite, Neutral, Rude, and Very Rude, running them through ChatGPT-4o [source]
The results completely shattered the “AI as a colleague” myth. The study found that impolite, commanding prompts consistently outperformed polite ones. The “Very Polite” prompts yielded an accuracy rate of 80.8%. The “Very Rude” prompts – the ones that stripped away all pleasantries and issued blunt, direct demands – achieved the highest accuracy at 84.8%.[source]
Why? Because direct, commanding language removes ambiguity. It provides clearer, less linguistically cluttered instructions, which helps the system focus strictly on the parameters of the task.
The Illusion of the “Friendly” System
Think about the systems you already use to build software and infrastructure. You don’t ask a bash script politely to move a file. You don’t negotiate with your Kubernetes cluster to spin up a pod. You don’t ask your CI/CD pipeline how it’s feeling today. You give an exact command, and you expect an exact result.
AI interfaces were wrapped in a chat UI because it made them accessible to the general public. It lowered the barrier to entry. But under the hood, they are computational systems. A prompt is not a text message to a friend; it is an uncompiled script.
Good prompting is not about being nice. It is about defining the outcome, setting hard constraints, and declaring the exact format of the expected result. You are not brainstorming with a peer; you are compiling a set of instructions.
Prediction is the Real Engineering Skill
This is where true engineering experience becomes your greatest asset. Anyone can type a question into an AI, but an engineer with 20 years of experience building businesses, managing development teams, and setting up complex cloud environments knows what is going to happen before they even hit enter.
Over the last two decades, I have designed cloud infrastructure, built out automation pipelines, and implemented complex observability systems. When I look at an architecture plan or a block of code, my mind immediately jumps to the failure modes. I know where a database will bottleneck. I know which cloud services will randomly timeout. I know exactly what mistakes junior developers are going to make, because I’ve spent years reviewing their code and fixing their bugs in production at 2 AM.
When you use AI, you have to treat it like a very fast, very confident, but highly unpredictable junior developer. You must apply your foresight to predict where the AI will hallucinate, where it will take a lazy shortcut, and where it will misunderstand an edge case.
You don’t wait for the AI to make a mistake and then politely ask it to fix it in a follow-up prompt. You build the constraints into your initial command: “Write a Python script to handle X. Do not use library Y. Account for edge case Z. Handle rate limiting gracefully. Output only the executable code, no explanations.”
You control the system by predicting its failures before they happen.
The Danger of Stale Intel: Trust Nothing, Verify Everything
There is another massive risk to treating AI like an all-knowing colleague: the tech world changes faster than an AI’s training data. Even the most advanced models have a knowledge cutoff. If you blindly trust their output without verification, you will inevitably push broken code into production.
Recently, my team was working on an integration using Okta. We needed to pull group data, and we asked the AI for the best approach. The AI confidently informed us that the user.getGroups function was simply not available in Okta Expression Language. It sounded authoritative. It sounded like an undeniable fact.
If we had treated the AI as a trusted colleague, we would have accepted that answer, abandoned the approach, and wasted hours engineering a complex, unnecessary workaround.
But because we treat AI as a system under command, we knew its “intel” was subject to verification. We dug into the actual, current documentation. It turned out the platform had recently been updated. The official Okta docs explicitly stated: “Note: This function was previously only available for a limited set of features on Okta Identity Engine, but has been expanded to all features that allow Expression Language.” (Great catch on the docs, Gowyn).
The AI was confidently wrong because its training data was stale. This is the golden rule of working with LLMs: AI provides a baseline, but the human commander must verify the intelligence against current reality.
The Commander Mindset
My military background fundamentally shapes how I view this technology. In the military, you do not rely on soft skills to get a critical operation executed. You do not ask your platoon politely if they feel like securing a perimeter. You give a clear, unambiguous order. You expect your commands to be fulfilled exactly as you asked.
When you issue a command, there is no room for emotional interpretation. You define the objective, provide the necessary parameters, set the constraints, and establish the standard for success.
But with that ultimate authority comes the ultimate burden of leadership: Responsibility.
If a military unit executes an order and the mission fails, the fault rarely lies with the soldiers. It lies with the commander. Did you give a clear order? Did you provide the right resources? Did you anticipate the enemy’s movements? Did you verify your intelligence before executing the strike?
The exact same rule applies to AI. If the AI hallucinates, writes insecure code, or gives you a bad architectural design, it is not the AI’s fault. It is your fault. You are the commander. You gave a sloppy order, you failed to set the right technical constraints, or you failed to verify the output before pushing it to production.
Final Orders
The era of conversational theater is over. The future of software engineering and digital business does not belong to the people who are best at making small talk with an algorithm.
It belongs to the experienced professionals who possess the deep domain knowledge to define strict parameters. It belongs to the engineers with the imagination to predict complex failure modes before they happen. And it belongs to the leaders who have the discipline to verify the results.
Do not negotiate with the machine. Issue clear orders, anticipate its failures, verify its intelligence, and own the final outcome.