AI’s Love Language is Precision
“A problem well stated is a problem half-solved”
Charles F. Kettering1 was an inventor in the early ages of electrified work. He invented the electric starter, worked at General Motors, and created Delco. As an engineer, Charles valued precision in work, and saw communication as a key component to work. Hence his quote, “A problem well stated is a problem half-solved.” More than 100 years after Kettering coined that phrase, it is more applicable than ever, especially in the AI space. AI can do wonders and AI can fail miserably, and the single biggest determining factor of the outcomes of AI’s work is the precision of the prompt that AI was given.
Prompt engineering is the latest manifestation of engineering’s all-important technical communication skill. In an earlier post, I shared my encounter with how my technical communication was tested in my Microsoft interview, as I tried to explain to my interviewer the process of “driving a car from point A to point B.”2 Technical communication is obviously important in engineering fields, but it is also powerful in any field. Engineering or otherwise, a dialogue between two people can easily become technical. Recognize the value of precision in your communication, and you will be a more effective communicator in all aspects of your life, from changing a smoke detector battery to hosting a great party.
AI is perhaps the best instructor of technical communication, through trial and error (and error and error). Embrace this opportunity and engage with AI to sharpen your communication. Spend quality time with AI and you’ll be rewarded for it. Build a relationship with your AI. Not a creepy relationship that has you convinced you’re falling in love with bits and bytes, but a relationship of mutual understanding through effective sharing. AI’s love language is precision, and as you build your muscle of effectively communicating your thoughts to AI, you will be rewarded with results from AI that are closer to your desired outcome, and that take less work for you and AI to co-create.
There are three other Kettering gems that I want to expand on as well, as they relate to this building of your technical communication muscle in an AI world.
“The biggest job we have is to teach a newly hired employee how to fail intelligently. We have to train them to experiment over and over and to keep on trying and failing until they learn what will work.”
“Inventing is a combination of brains and materials. The more brains you use, the less material you need.”
“There is a great difference between knowing and understanding: you can know a lot about something and not really understand it.”
Experiment over and over
This came up in my most recent visit to Microsoft. Across conversations with several colleagues there, a theme was developing: they were describing a fundamental divide, between those employees that were successfully using AI to accelerate their work, and those stuck in the dabbling stage. It seems that some form of escape velocity is needed to move you from dabbling to all-in. This is where Charles’ quote provides solid advice. “The biggest job we have is to teach a newly hired employee how to fail intelligently. We have to train them to experiment over and over and to keep on trying and failing until they learn what will work.”
Fail intelligently. Don’t just keep running your head into a wall with AI. Step back from the action to observe3 what is working and what isn’t. Did AI hallucinate because you failed to provide important guardrails, such as “all references that you provide must be real artifacts available on the internet”? A bad AI output is an invitation to sharpen the precision of your communication. You can even leverage AI to help you get more precise. Ask AI to be your prompt engineer teacher in the context of your current dialogue with it.
Experiment over and over. If you’re not seeing AI as your partner in just about every aspect of your work, you’re missing opportunities to develop this important (non-creepy) relationship. Just as continued conversations with a colleague accelerates both the rate of exchange of information and the quality of that exchange, your repeated attempts to partner with AI will give both you and the AI a better understanding of each other. Over time, communication shorthands will naturally develop between you and your AI.
One signal to watch for in your experiments is the “pedantic trap”. You have to be far more explicit with AI than you would have to be with just about any human you are interacting with. The level of pedanticness that you need to demonstrate can quickly fatigue and frustrate you. The solution is to capture your favorite guardrails in boilerplate form, saved off and then readily applied to all of your conversations with AI. You can measure the maturity of your relationship with AI by how rich your boilerplate prompt is.
You escape the pedantic trap by upleveling the conversation. You reach escape velocity in your AI partnership by advancing from chat exchanges to agent creation, where you move from asking for a single thing to describing a responsibility for AI to take on. Build a varied set of agents that you use to offload more of the mundane aspects of your responsibilities, and you will begin to see the value of creating an overarching managing agent. Agents in depth is an impressive display of how clearly you can articulate what you need and how you need it.
More brains used == less materials needed
When Kettering said, “Inventing is a combination of brains and materials. The more brains you use, the less material you need,” he had no idea that one potential “material” would be “AI token count.” But his general statement applies perfectly. The number of tokens involved in an AI exchange is the measurable unit of conversation complexity. All up, this count is a rough signal of how deeply you are working with AI. Other similar signals are SLOC (Source Lines of Code) for a software engineer and chat count for a friend. You should never focus directly on maximizing token count, SLOC, or chat count. They are just signals that can help assess engagement level.
Some of my best friends require the fewest chats, because we are so in sync. And as any software engineer experiences through the progression of their own coding skills, you tend to have higher SLOC as a novice than you do as a professional, because you have learned how to more optimally reduce your ideas to code. So it goes with your AI conversations. With more precise prompts, the AI has to do less work for the desired result.
And when you find yourself playing in the context engineering space, you are further contributing to the escape velocity of your AI partnership. “Context” is the AI equivalent of a human’s working memory. This is everything that AI has “paged in” to work on a more involved exchange. When you are having an especially long conversation with AI, and you notice that it is beginning to forget some of the things you had said earlier, its context may have maxed out, at which point the AI did some compacting of context. Prompt engineering is helping you craft clearer prompts, and context engineering is helping you make sure you don’t stress AI’s working memory.
“It ain’t all that”
The final Kettering quote I want to expand on is his one of Charles’ more cautionary quotes: “There is a great difference between knowing and understanding: you can know a lot about something and not really understand it.” Kettering precisely captures the most important “great difference” to keep in mind when collaborating with AI.
We are a species that tries hard to understand things. But we all individually vary in what we can learn and how we can learn it. Us humans like to pretend, and it is sadly quite common for us to mask a lack of understanding with pretending to understand. This is why critical thinking is so critical for effective communication with each other. “Trust but verify” is a critical thinking tool. When you are working with someone, demonstrating trusting in their abilities will empower them to step up. But to ensure your trust is not misplaced, you need to occasionally verify that what they are delivering is meeting your expectations.
The better someone is at pretending to understand, the more you will unconsciously defer to trusting. Critical thinking demands that you consciously force the “but verify” piece to the top of mind. You can also take an “innocent until proven guilty” approach here where you trust until someone shows a reason to not trust, at which point you add the verify step to your interactions with that individual. “Fool me once, shame on you. Fool me twice, shame on me.”
I have come across a handful of pathological liars in my career. I am thankful that the number has been small, because they were all pretty devastating experiences for me. These individuals were so successful in capturing my trust that they tricked me out of the verify step, for way longer than I ever should have. Deliverables were missed, management was upset, and customers were lost. The long term learning for me was to realize that verifying is always needed, and should never be seen as an insult. Verifying is part of being professional.
As good as humans are at pretending to understand, AI makes them all look like amateur actors. AI’s mastery of language and delivery combined with the volume of its communications can fool anybody. So keep Kettering’s quote on hand, and refer to it regularly to build your verify muscle. AI knows more than any of us can know, as it has direct access to everything captured in binary form. But AI doesn’t understand any of that.
Don’t be fooled. The results can be devastating.