Your LLM Output Is Only as Good as Your Context
Weak LLM output usually traces back to thin input. Here’s what good context includes, a before-and-after prompt example, and a five-point checklist.
Most people unhappy with their LLM output share the same complaint. It's generic. It sounds like everyone else. It misses the point.
They usually blame the model. In my experience, the model is rarely the problem. The input is.
I've written more than 2,500 articles and helped train and evaluate language models for Google and Meta. The pattern is the same every time. When the output is good, someone gave the model enough to work with. When it's weak, someone gave it a sentence and hoped.
What thin input looks like
A one-line request leaves the model guessing. Who is the reader? What is the goal? What voice should it use? What should it avoid? What does "good" look like?
A person would ask those questions before starting. A model can't ask. It fills the gaps with the safest, most average answer it can find. That's why thin prompts produce bland results.
It's the same thing that happens when you hand a freelancer a one-line brief. You get something. It just isn't what you wanted.
What context actually includes
Good context isn't a longer prompt. It's the right information, in the right order. For most writing and analysis tasks, I cover these:
Audience. Who will read this, and what do they already know?
Goal. What should the reader think or do afterward?
Source material. The facts, quotes, data, or draft the model should work from, so it doesn't invent them.
Voice and style rules. Sentence length, words to avoid, level of formality.
Prior decisions. What you've already settled, so the model doesn't reopen it.
Examples. One good sample teaches more than a paragraph of description.
Constraints. Length, format, and what to leave out.
None of this is new. It's what a good editor puts in a brief. Models just make the cost of skipping it visible.
Same task, two prompts
Here's an example with a made-up company. The task is a short announcement of a new feature.
Thin prompt
Write a short announcement for our new reporting feature.
The model will give you something upbeat and vague. Words like "powerful," "seamless," and "unlock" will show up. It could be about any product from any company.
Full-context prompt
You're writing for DevOps engineers and platform architects at mid-size companies. They're skeptical of marketing language and want to know what changed and what it costs them in setup time.Announce the new reporting feature in under 150 words. Lead with the problem it solves: teams currently export logs by hand each week. Use the three facts below and nothing else. Don't use "powerful," "seamless," or "unlock." Write in short, plain sentences. End with a link to the docs.Facts: reports build automatically every Monday; setup takes about ten minutes; it works with the three existing log formats.Here's a sample of our tone: [paste a paragraph of past work].
The second prompt takes two minutes longer to write. The output needs far less rework. The model has an audience, a goal, source facts, a style, and limits. It isn't guessing.
Context isn't the whole story
Good context gets you closer. It doesn't finish the job.
You still have to know what good looks like. That's how you catch the claim the model got wrong, the paragraph that drifts off the audience, or the sentence that sounds right and says nothing. Someone who writes a detailed prompt but can't judge the result will accept weak work. Someone with 25 years of editing will send it back.
That's also why I keep a person in the loop on anything that goes out under my name. The model drafts. I decide.
The skill is two things together: giving the model what it needs, and knowing when it still got it wrong.
Try this on your next prompt
Before you hit enter, check five things:
Did I say who the reader is?
Did I say what the piece should accomplish?
Did I give the model the facts, instead of asking it to find them?
Did I set the voice and the limits, including what to avoid?
Did I include an example of what good looks like?
If the answer to most of these is no, the weak output isn't a model problem. Fix the input first. Then judge the result critically.
Comments