You open ChatGPT, Claude, or Gemini because you need a blog post. Say you make project management software and you want something about meetings. You know the subject and audience, so you write a prompt along these lines:
Write a 1,000-word blog post called "Why your team's meetings run long." The audience is managers at small software teams. Keep the tone practical and relaxed, explain the problem clearly, and end with advice the reader can apply.
The model returns a sensible overview. It might explain that meetings without agendas drift and that too many people get invited, then recommend a named owner and a hard stop. Nothing is obviously broken, and after cleaning up a few phrases, you could publish it.
Before you do, ask which company wrote it. The article gives you no answer because it doesn't reveal what the company believes, how its product approaches the problem, or what its team has learned from customers. Any project management tool could publish the same article after changing the logo and link at the end.
The draft looks fine, so why does it feel wrong?
The first prompt contains enough information to produce a decent article. It names the topic, audience, length, tone, and intended takeaway. Those instructions help the model create the right kind of document, which is why the result looks finished.
They don't help the model identify which ideas belong to your company and which ones could belong to anyone. It has no reason to emphasize your product's approach or argue for your view of the problem, so it reaches for safe advice that fits the category.
Editing can fix awkward wording and tighten the introduction, but it can't add the company knowledge that was absent from the task. A generic draft can survive several rounds of perfectly competent editing.
Generic doesn't mean badly written
A generic draft can be clear and accurate, and it may still be useful at a basic level. Its weakness is specificity, not readability. To check whether a polished draft is still generic, ask:
What does this company believe that others in the category might not?
How does its product solve the problem differently?
Which customer situation does the company understand firsthand?
What message should the reader associate with this company?
A draft doesn't need to answer every question in every paragraph, only the ones that matter to the article. If it answers none of them, the article may earn a nod of agreement without giving the reader a new idea or a reason to remember the source.
Judging generic AI content this way is more useful than searching for suspicious words. You can see and edit style problems, while missing company knowledge can hide underneath polished prose.
The model can't use context it never received
The original prompt leaves out four types of context, and each one affects the article differently:
Company context includes what you believe, the language you use, and the positions you will defend. Without it, the article defaults to category consensus.
Product context explains what you have built, how it works, and why you made particular choices. Without it, any mention of a solution stays vague.
Customer context captures who experiences the problem, how it appears in their work, and what they have already tried. Without it, the pain points come from a general audience profile rather than your real understanding of customers.
Article context sets the angle, key message, boundaries, and relationship to other content. Without it, the model covers the subject instead of making a deliberate argument.
Changing models doesn't fill those gaps. GPT, Claude, and Gemini may choose different words or organize the material differently, but each model still has to work with the information available. If the task contains only a topic and writing instructions, the result will draw mostly from broad patterns associated with that topic.
Instructions and knowledge do different jobs
Most advice on improving prompts mixes two things: clearer instructions and more knowledge. A longer prompt may work because it includes both, not because length itself makes it better.
Instructions describe the answer you want. They cover length, structure, tone, formatting, and the task itself. You can ask for a relaxed 1,000-word article with six sections and no jargon, and the model can follow those directions without knowing anything meaningful about your company.
Knowledge gives the model material to reason and write from. For the meetings article, that knowledge includes what the company actually believes about meetings, what its customers have already tried and abandoned, and the one idea it wants readers to remember.
Both belong in a useful prompt, but adding more instructions can't make up for missing knowledge. "Take a bold position" is an instruction, while "long meetings are a symptom of not writing things down" gives the model a position it can actually develop.
Add an opinion and the draft starts to sound like yours
You don't need an elaborate prompt framework to test the difference. Add the company knowledge and editorial decisions that belong to the article, either in the task itself or in reusable system instructions.
Go back to the meetings article and hand the model what the first prompt left out. Not more direction about tone and length, but the things only the company knows: what it actually believes about meetings, what it has built, and who it is talking to. For the project management company above, that context could look something like this:
Company and product:
We make project management software for small teams. It is built around written, asynchronous work: long-form posts and pitches instead of standing meetings, and notifications you can switch off outside working hours.Audience:
Managers at small software teams who already run plenty of meetings and have already tried agendas, invite lists, and time limits. Do not explain meeting hygiene to them.Our point of view:
Long meetings are not a scheduling failure, they are what happens when a company has no habit of writing things down. Most of what gets talked through live should have been a written pitch that people read and respond to on their own time.Key message:
If your calendar is full, the problem is upstream of your calendar.Voice:
Direct and opinionated, no hype. Say plainly what we do not do and who this is not for. Use "we" naturally and be honest about the tradeoffs.Do:
Start from a meeting the reader sat through this week. Make the argument for writing over talking. Admit what you give up when you move work into writing.Don't:
Offer a listicle of meeting tips, or pretend this works at every company at every size.
The draft still needs editing, but the model no longer has to invent the company's position or choose the safest possible angle. This is prompt engineering: keep improving the prompt until the output improves. A lot of people still work this way because it's a practical fix for one task.
If your latest draft feels polished but anonymous, try adding the opinion, key message, and relevant company knowledge before changing models or rewriting the instructions again.
The next problem is doing this every time
That prompt-engineering fix works for one article. The next one may need a different customer insight, newer product details, another part of the voice guidance, and a separate opinion. Someone has to find those inputs, check that they're current, and decide which ones belong in the prompt.
Context engineering takes on this repeated-work problem. It shifts attention from perfecting one prompt to organizing, maintaining, and supplying company knowledge across tasks. A prompt can carry the context, and a custom GPT or a project workspace can hold onto it, but neither keeps that context current nor decides which parts belong in the next article.
That shift is the subject of the next article in this series, "What fixes generic AI content: context engineering, not better prompts". It looks at why pasting and saving context helps, where the workaround begins to break, and what a more durable practice looks like.