You asked an AI tool for something. A first pass at the client proposal, say, or a summary of what went wrong last quarter. What came back was fast, well organized, complete, and not what you wanted.
Not wrong the way careless work is wrong. Every piece of it is defensible on its own. It answered a question. It just was not quite the question you asked, and it took you a while to find where the two had come apart.
Most leaders have had that experience several times by now and filed it under “the tools are not there yet.” I want to offer a different reading, because a better tool will not fix this one.
The check that used to be free
Every organization runs on requests that are not fully specified. This is not a flaw. It is how people work. You ask for a summary of the regional numbers, or a proposal for the new client, or an assessment of whether we should be in that market at all, and you leave a great deal unsaid, because saying all of it would take longer than the work. The person on the other end fills the gaps from context, from having worked with you before, from having been here a while.
And when a gap is too wide to fill, they come back and ask. What do you mean by regional? Do you want this to include the accounts we inherited? Is this for the board or for us?
The clarifying question is the most efficient error correction any organization has. It costs a minute. It happens in a doorway. No one logs it, no one counts it as a step in any process, and it has never appeared on an org chart. It is close to invisible, and it has been holding a great deal together.
AI does not ask it. Not out of some failure of manners, but because it does not carry the thing that makes people ask. A person who guesses wrong spends their week on the wrong work and then has to explain it to you. That prospect is what produces the question. A system with nothing at stake will return a confident, complete, plausible answer to any request you give it, including the requests you had not finished thinking through.
So the imprecision in your organization did not increase. The thing that used to catch it went away.
This is not a prompting problem
There is a small version of this problem available, which is that people need to get better at writing prompts. I would encourage you to resist it, because it puts the problem in the wrong place and hands it to the wrong people.
The vagueness in most organizations does not originate in a prompt. It originates upstream. In a strategy memo that three departments read three different ways. In an objective that sounded clear in the room. In a piece of feedback like “make it feel more premium.” In a request for a plan that never said what the plan was supposed to accomplish. All of that predates AI by a long way, and most of it has been quietly absorbed by people downstream who worked out what you probably meant.
Your tools did not create the imprecision. They removed the buffer that was hiding it.
That distinction matters for where you put your attention. If this is a prompting problem, it belongs to whoever touches the tools, and it gets solved with training. If it is a specification problem, it belongs to whoever makes requests, which is most of the leadership of most organizations, and it does not get solved with training at all.
What precision actually means
It is worth being clear about what I am asking for, because “be more precise” tends to land as “write more,” and that is not it. Longer requests are frequently vaguer. What matters is whether three things are present, and they are the same three whether the request is going to a person, a team, an outside firm, or a tool.
What outcome, and for whom. Not the deliverable, the outcome the deliverable is meant to produce. “A report on customer attrition” is a deliverable. “I need to know whether our attrition is concentrated in one segment, because I am deciding where next year’s retention budget goes” is an outcome, and it produces a different report. The second version is not longer by much. It is just pointed at something.
What is out of bounds. The constraints so obvious to you that it would not occur to you to say them. The regulatory limit. The client relationship that cannot be disturbed. The approach that was tried in 2023 and did not work, for reasons everyone who was here remembers. The budget no one wrote down. Experienced people fill these in on their own. Nothing else will.
How anyone would know it worked. Said before the work starts, not after. If you cannot describe what would make this a good result, then the work has no target, and you will end up evaluating it on whether it feels impressive. That instrument is the one you can least afford to trust right now, for reasons I went into a few weeks ago.
None of this is new, and it is worth knowing how old it is. Fred Brooks ran one of the most ambitious computing projects of the 1960s and spent the rest of his career writing about why such efforts go wrong. In 1986 he put it about as plainly as it can be put: the hardest single part of the work is deciding precisely what to build. His point was that the difficulty lives in working out what is actually wanted, and that no improvement in the machinery touches it. Forty years on, the machinery has improved almost beyond recognition. That sentence has not moved.
Two things worth looking for
You do not need a survey to find out whether this is happening where you work. There are two signals and both are available to you now.
The first is rework that does not look like rework. Work that has to be done again, not because it was done badly, but because it answered a different question than the one that mattered. That used to surface as a delay. Someone got stuck, someone asked, the schedule slipped and you heard about it. Now it surfaces as a finished piece of work that quietly gets set aside. Ask the people who report to you what share of what their teams produced last quarter was set aside rather than used. The number tends to be higher than anyone expects, and almost no one is tracking it.
The second is quieter and more useful. If people have stopped coming back to you with questions about what you asked for, find out why before you read it as alignment. Sometimes it means your requests got clearer. More often it means the question stopped being necessary, because there is now something that will accept any request at all and hand back something that looks usable. The clarifying question was never a sign of confusion. It was a sign that someone intended to get it right.
What it costs to fix
The uncomfortable part is that precision is slow at the front, and the front is where no one has time. Writing down what you actually want, before you have seen anything, is harder than reacting to a draft. It is genuinely easier to know what you want while looking at something that is not it. That is not a discipline problem. It is how people are built, and any approach that ignores it will fail.
So the failure mode here is predictable. Somebody will turn this into a form. A required template with fields for outcome, constraints, and success criteria, attached to every request of any size. Within two quarters it will be filled in from memory, nobody will read it, and it will have added time without adding clarity. This happens to nearly every good idea that gets turned into a mandatory field.
What actually works is smaller and considerably harder to install. It is a standing permission to say “I do not understand what you are asking me for.” Not as a complaint, and not as an escalation. As an ordinary, unremarkable, career-safe thing to say to someone more senior than you.
That is a property of the culture, not of the process, and it is the part you cannot delegate. If that sentence is expensive to say where you work, no template will save you. If it is cheap, you may not need one.
The larger thing underneath
This points at something bigger than requests, and it deserves a piece of its own.
A great deal of what held organizations together was never designed. It was a by-product of work being slow enough to require conversation. The clarifying question in the doorway, the second person who looked at something before it went out, the pause where somebody said this does not feel right. None of it was on a process map. All of it was doing real work.
As that friction goes away, the conversations it used to produce do not relocate somewhere else. They stop. Which means the places where an organization deliberately makes room for people to say what they did not understand and what is not working matter more now than they did before, not less. Those places used to be a luxury. They are becoming infrastructure.
For now, the practical version is short enough to carry into your next meeting. The request is the work. It always was. The difference is that the cost of getting it wrong used to arrive slowly, as a delay and a conversation, and now it arrives quickly, as something finished and confident that answers a question no one asked.
Nobody is going to ask you what you meant. Which means you have to know.
The observation that deciding precisely what to build is the hardest part of the work comes from Fred Brooks, No Silver Bullet: Essence and Accident in Software Engineering (1986).
