The Biggest AI Prompting Mistake Is Asking for Too Much at Once
Two people, same week, same kind of task. Both are asked to turn a year's worth of notes into a year-end review presentation covering objectives, budget, staffing, risk and recommendations for the executive team. Both have the data. Both open the same AI tool. One types a single request: "Create a year-end review presentation covering these topics." The other spends a few minutes first, then makes five separate requests, each tied to one section and one job.
The first gets something that looks like a presentation and reads like a form letter. The budget section treats every line item with equal weight. The staffing section is a table with no interpretation behind it. The recommendations are generic enough to belong to any department in any company. He spends the next two days rewriting most of it and still falls short of what the executive team expects. He concludes that AI is not ready for this kind of work.
The second gets five pieces of directed, reviewable material and a final deck that took a few hours of editing rather than a day. The tool did not change between Monday and Wednesday. The task did.
Why one big request produces a little of everything
A single prompt that covers five different jobs is not one task with extra length. It is five tasks wearing one coat. Extracting the strongest results from a year of notes is a different cognitive operation from summarising budget variance for an audience that cares about allocation decisions rather than line items. Writing a staffing update that focuses on capacity and delivery is different again from framing three recommendations as resource decisions rather than aspirational goals. Each of those jobs has its own purpose, its own intended reader and its own idea of what a good answer looks like.
Fold all of that into one instruction and the model has to guess which purpose governs which paragraph. It cannot ask for clarification, so it does the only sensible thing available to it: it averages. Every section gets roughly equal attention, roughly equal detail, and none of the specificity that would come from being written for one clear job. The output is not wrong so much as evenly, unhelpfully competent everywhere at once. That flatness is often mistaken for a limitation of the model, when it is really a symptom of a request that never separated into its component parts before it reached the model at all.
This is worth sitting with, because the instinct to treat one deliverable as one AI task feels efficient. Why break something into five pieces when you could just ask for the whole thing? The honest answer is that the whole thing was never really one thing. The deliverable is the finished shape the work takes at the end. The task, in the sense that matters for briefing AI well, is whatever distinct operation you are asking it to perform in a given moment, and most substantial deliverables contain several.
Finding the seams
The useful skill here is not decomposition as a formal technique so much as noticing where a piece of work quietly changes character partway through. A board pack, a client proposal, an internal update, most professional documents contain a handful of purpose-changing transitions: a point where you stop gathering and start interpreting, or stop interpreting and start recommending, or shift from writing for one audience's concerns to another's. Those transitions are the seams. Ask AI to work across a seam without acknowledging it and you get exactly the kind of generic middle ground that satisfies no single purpose particularly well.
Spotting the seams is mostly a matter of asking, before you write anything, what this deliverable is actually made of. A quarterly report might separate into pulling out what changed, explaining why it changed, and deciding what to do about it. A client summary might separate into the facts the client already knows, the interpretation they are paying you for, and the recommendation they are waiting on. None of that requires new vocabulary or a formal framework. It requires pausing long enough to name the parts before typing the first thing that comes to mind.
The program director's five-step version of the year-end presentation illustrates what this looks like in practice, without turning it into a rigid template. She asked AI to pull the three strongest results from her notes and explain their strategic weight, not just their numbers. She asked for a budget variance summary aimed at people weighing allocation decisions rather than reading a spreadsheet. She asked for a staffing section built around capacity and delivery impact rather than headcount. She asked for a risk summary that separated what had already been mitigated from what was still live. And she asked, separately, for three recommendations framed as resource decisions rather than wish-list goals. Each request was small enough to describe its output before she saw it, which is a fair test of whether a task has actually been defined.
None of this made the first draft finished. It rarely is. What it did was make each piece close enough to useful that editing dropped from a full day to a few hours, and it meant the final document told one coherent story instead of reading like five paragraphs stitched loosely together.
Small tasks do not mean small effort saved on everything
It would be a mistake to conclude from this that every request should be broken into as many pieces as possible, or that a shorter task automatically beats a longer one. A quick internal note or a routine status update rarely hides more than one job, and decomposing something that simple just adds friction without adding value. The habit worth building is not "always break things down" but "check whether this deliverable is secretly several deliverables before deciding how many requests it needs."
There is a second benefit that only becomes visible once work has been separated this way. When a task is still bundled, it is genuinely difficult to tell which parts of it actually benefit from AI involvement and which parts need a person's judgement, because everything arrives mixed together in one response. Once the budget summary, the staffing section and the recommendations exist as separate, nameable pieces, it becomes far easier to see that the structured, verifiable sections are strong candidates for AI drafting, while the recommendations, which depend on institutional knowledge and a sense of what the room is ready to hear, are better written by the person who has to stand behind them. Decomposition does not settle that question by itself. It simply makes the question visible enough to answer deliberately, rather than by default.
The mistake, in the end, rarely lives in the wording of the request. It lives earlier, in the decision to treat five different jobs as though they were one. Separate the jobs first, and the prompting problem that seemed to need cleverer phrasing usually turns out not to have been a wording problem at all.
Anthony Velland
Interested in going further?
If breaking a deliverable into its real components sounds like the missing step in your own AI use, AI Without Guesswork builds decomposition into a repeatable part of a complete, structured workflow.
Ad · Amazon affiliate link.
