Everyone is optimizing the wrong thing.
The entire conversation about working effectively with AI has collapsed into a conversation about prompts. How to phrase them. How long to make them. What format produces the best output. Which magic words unlock which capabilities. There are courses, frameworks, certifications, and entire consulting practices built around the idea that prompt engineering is the skill that separates people who get great results from people who get mediocre ones.
I want to make a direct argument that this is mostly wrong. Not completely wrong — clear communication matters, framing matters, asking for what you want in a way the system can act on matters. But the obsession with prompts is a category error. It is optimizing the last mile of a journey while ignoring whether the road was built correctly.
The thing that actually separates great results from mediocre ones is trust. And trust is not a prompt. It is a relationship built over time.
What Trust Means in This Context
When I say trust, I mean something specific and operational. I don’t mean faith that the system will do its best. I mean a state in which the system has enough accurate context about you, your work, your environment, and your standards that it can fill the gaps in your instructions without asking and without getting it wrong.
That is a high bar. It requires that the system know not just what you do, but how you think about what you do. Not just your business, but the vocabulary you use when you’re being precise versus when you’re being approximate. Not just your goals, but your aesthetic — what good looks like in your world, what you would never accept, where you’re willing to trade quality for speed and where you absolutely are not.
A prompt, no matter how well crafted, cannot convey all of that. A prompt is a snapshot. Trust is a history.
The difference in practice is dramatic. A well-crafted prompt given to a system that doesn’t know you produces a technically correct response that fits a reasonable interpretation of your question. Trust given to a system that knows you deeply produces a response that fits your interpretation — the one you had in your head before you typed anything, including the parts you didn’t think to specify.
The Spec That Wasn’t
Let me give you a concrete illustration, because I think the abstract version of this argument is easy to agree with and hard to act on.
Recently I asked Claude to build a content directory where every table cell was a live anchor link to a real published page on a website. Seven words of instruction, roughly. No spec. No sitemap. No list of URLs. No formatting requirements. No guidance on how many tables, what categories to use, how to handle coverage gaps, how to verify the links, or how to publish the result.
What came back was a Python script that audited 512 posts, categorized them by service type, built a town-by-service matrix with 100% cell coverage verified before any HTML was written, generated five tables with 97 anchor links, and published a live article with post-publish verification. Twelve minutes.
Now consider what a well-crafted prompt for that task would have looked like. It would have specified the site URL, the categories to use, the towns to include, the services to map, the verification requirements, the publishing format, the post status, the categories to assign in WordPress. It would have been several hundred words at minimum, and it still would have missed things that had to be figured out mid-execution.
The seven-word version worked not because the prompt was well-crafted. It worked because the system already knew the site architecture, the credential setup, the proxy routing, the taxonomy structure, the publishing workflow, and my standard for what “verified” means before any of this was typed. The trust was already there. The prompt was just the trigger.
Why Prompt Engineering Has Limits
Prompt engineering is a real skill and it has real value, especially in contexts where you are starting fresh every session with no accumulated context. If you are using AI tools in a stateless way — new conversation each time, no persistent setup, no institutional memory — then yes, the quality of your prompt is one of the few levers you have.
But the stateless approach is itself the bottleneck. You are re-paying the setup cost on every session. You are capping the depth of what the system can do for you at whatever you can fit into a single exchange. You are, in effect, choosing to never let the relationship develop past a first date.
The people who will get the most out of AI in the long run are not going to be the ones who write the best first-date conversation. They are going to be the ones who invested in the relationship early, built genuine shared context, and now operate from a place where the system knows them well enough that a seven-word instruction is sufficient — because everything behind those seven words has already been established.
That investment does not feel productive in the short term. You are spending time teaching instead of getting output. You are building context that won’t fully pay off for days or weeks. Every productivity metric in the short term says you’re going slower. But the curve is exponential, and the people who front-load the relationship work will eventually be operating in a different league entirely from the people who are still perfecting their prompts.
The Anatomy of a Trusted System
What does it actually look like to build the kind of trust I’m describing? Not philosophically — mechanically. What are you actually doing?
You are loading durable context. Not just “I run a restoration company in New York” but the specific texture of how that business works — the regulatory environment, the vocabulary that signals expertise to your clients, the difference between a Nassau County job and a Suffolk County job and why it matters, the fact that your staff holds IICRC certification and that matters in how you talk about your work.
You are establishing integrations that persist. Site credentials, API access, publishing workflows, proxy routing — the infrastructure layer that means when you ask for something to be done, the doing part is already set up and doesn’t require a detour through “let me configure this first.”
You are building skills — repeatable patterns of behavior that encode how you want specific categories of work handled. Not prompts, but something more like trained reflexes. The system knows that when you ask for a WordPress article, it means fully optimized, published, verified, categorized, and internally linked — because that’s what your standard is and that’s been established.
And you are running sessions that aren’t about output. Sessions where the goal is just to work in a way that teaches the system more about how you think — what you push back on, what you approve without comment, where you ask for more and where you ask for less. These sessions feel inefficient. They are the most important sessions you will run.
What Changes When Trust Is Established
I want to describe the phenomenology of this, because I think it is genuinely different from what most people have experienced and I want to give it language.
When trust is established, the texture of the work changes. The session doesn’t start with orientation — with the mutual re-establishment of who you are and what you’re trying to do and what standards apply. It starts at the work. You skip the preamble because the preamble is already known.
This sounds like a small thing. It is not a small thing. The preamble — the re-explaining, the context-setting, the clarifying the question before getting to the answer — is where enormous amounts of productive energy get spent in untrusted systems. Eliminating it doesn’t just save time. It changes the character of the session. It makes the work feel like work with a capable partner rather than work with a capable stranger.
And capable strangers, however talented, can only help you up to the level of what they understood from your introduction. Capable partners, who know you, can help you up to the level of what you’re actually capable of — which is higher. Always higher.
The Prompt Is the Last Inch
None of this is an argument against thinking carefully about what you type. Clear communication is always better than unclear communication. A well-formed question will outperform a poorly formed one even in a fully trusted system.
But the prompt is the last inch of a very long road. You build the road by setting up the system correctly, loading the right context, establishing the integrations, developing the skills, running the unglamorous sessions that feel like overhead and are actually infrastructure.
When the road is built, the last inch matters less than you think. A clear direction and a trusted system will cover it. Seven words will cover it.
When the road isn’t built, the last inch is all you have. And no amount of prompt engineering turns a last inch into a mile.
The people who understand this — really understand it, not just intellectually but in their bones, in the way they allocate their time and their patience and their willingness to invest before they see returns — those people are going to work at a level that will be genuinely difficult to explain to people who are still optimizing their prompts.
Not because they found a shortcut. Because they built the road.
Frequently Asked Questions
Why is prompt engineering not the most important AI skill?
Prompt engineering optimizes the last inch of a much longer journey. In a stateless system with no accumulated context, the quality of the prompt is one of the few levers available — and it matters at the margins. But in a system where trust has been built over time through setup, context, and relationship, a seven-word instruction can outperform a three-hundred-word spec because the system already knows everything that would have gone into the spec.
What does trust mean in the context of AI systems?
In AI systems, trust is not faith — it is a specific operational state in which the system has enough accurate context about you, your work, your environment, and your standards that it can fill the gaps in your instructions without asking and without getting it wrong. It requires that the system know not just what you do, but how you think about what you do — your vocabulary, your aesthetic, your definition of done.
How do you build trust with an AI system over time?
You build trust by loading durable context explicitly, establishing integrations that persist, building skills that encode your standards permanently, and running sessions whose purpose is teaching rather than producing. The system learns what you approve without comment, what you push back on, and where your standards are non-negotiable. This accumulated knowledge is trust in its operational form — and it has a compounding return that grows with every session.
What is the difference between a prompt and a relationship when working with AI?
A prompt is a snapshot — a single instruction that captures what you want in that moment without the benefit of shared history. A relationship is a history — an accumulated model that the system holds of who you are and what good looks like in your world. A prompt constrained to a single exchange can only draw on what is explicitly stated. A relationship draws on everything the system has learned, including the things you did not think to say because they were already understood.
What kind of people will get the most out of AI in the long run?
The people who will get the most out of AI in the long run are not the ones who master the best prompts. They are the ones who invest early in building genuine shared context — who do the unglamorous setup work, load the right information, develop persistent skills, and run sessions whose only purpose is teaching the system how they think. That investment compounds. The people who front-load it will eventually operate at a level that is genuinely difficult to explain to people who are still optimizing their prompts.
Leave a Reply