Jenuel Oras Ganawed

Posted on May 22 • Originally published at blog.jenuel.dev

Your AI is not bad, your instructions are

#ai #webdev #tutorial #productivity

Your AI is not bad, your instructions are

Most AI failures are not model failures. They are instruction failures. This guide shows how to write clearer prompts, give better context, use examples, set boundaries, and turn AI from a clever guesser into a reliable collaborator.

Most people judge an AI model too quickly. They type one vague request, get a shallow answer, and conclude the tool is bad.

Sometimes the model really is the problem. It may hallucinate, misunderstand a niche domain, or fail at a task that needs fresh data or exact execution. But a lot of the time, the AI did exactly what it was asked to do. The problem is that the request was incomplete, fuzzy, or missing the information a human coworker would normally ask for before starting.

AI is not magic. It is a prediction system that responds to the shape of your instruction. If the instruction is lazy, the answer usually feels lazy. If the instruction is specific, grounded, and testable, the answer gets much better.

That does not mean you need to write a novel every time you use ChatGPT, Claude, Gemini, Copilot, or any other assistant. It means you need to stop treating prompts like search queries and start treating them like task briefs.

The prompt is the interface

With normal software, the interface gives you buttons, menus, validation, and guardrails. If you fill out a form wrong, the app tells you. With AI, the interface is language. That makes it powerful, but it also makes it easy to be sloppy.

When you ask, "Write me a blog about AI," the model has to guess almost everything: audience, tone, length, point of view, structure, level of technical depth, examples, sources, and what you actually believe. It will usually choose the safest average answer. That is why so much AI writing sounds like a conference brochure.

A better request sounds more like this:

Write a 1,200-word blog for software developers and creators. The argument is that many bad AI outputs come from weak instructions, not weak models. Use a direct, practical tone. Include examples of bad prompts and better prompts. Avoid hype. Include references to prompt engineering research and documentation. End with a reusable checklist.

Same tool. Different interface. Better result.

AI needs context more than clever wording

People often think prompt engineering is about secret phrases. It is not. Most of the value comes from context.

If you hired a designer, developer, editor, or assistant, you would not say, "Make this better" and walk away. You would explain who the work is for, what good looks like, what constraints matter, what has already failed, and what should be avoided.

AI needs the same thing. It needs the background that lives in your head.

Who is the audience?
What is the goal?
What should the output be used for?
What format do you need?
What should it avoid?
What examples should it follow?
What sources or facts should it rely on?

Without that, the model fills in the blanks. Sometimes it guesses well. Sometimes it invents a business-school version of what you meant.

Bad prompts hide the standard of success

The most common instruction mistake is asking for an output without defining success.

"Make this landing page better" is not enough. Better for whom? Better at conversion? Better at clarity? Better for SEO? Better for trust? Better for mobile users? Better for a skeptical buyer who has never heard of you?

Try this instead:

Review this landing page for a first-time visitor. The goal is to make them understand the product in less than 10 seconds and click the download button. Identify confusing copy, missing trust signals, weak calls to action, and anything that may hurt mobile readability. Give the answer as a prioritized list with suggested replacement copy.

That prompt gives the model a job, a user, a goal, evaluation criteria, and an output format. The answer will almost always be more useful because the AI no longer has to invent the target.

Examples beat explanations

If you want a specific style, show it. If you want a certain format, show it. If you want a category of answer, show one good example and one bad example.

This is one reason few-shot prompting works so well. Research and practice both show that models respond strongly to examples in the prompt. You are not just describing the task. You are giving the model a pattern to continue.

For example, instead of saying "write in my style," paste two or three paragraphs you actually wrote and say what you want preserved: short sentences, plain words, personal opinion, no corporate tone. If you want a bug report, show the exact structure. If you want sermon notes, show the rhythm and sections. If you want a product changelog, show a previous changelog that worked.

Examples reduce guessing. That is the whole game.

Give the AI boundaries before it makes a mess

AI assistants are eager. That eagerness is useful when you want momentum, but dangerous when the task has rules.

If the assistant should not invent statistics, say so. If it should ask questions before making assumptions, say so. If it should cite sources, say so. If it should keep the answer under 500 words, say so. If it should not change code outside a certain folder, say so.

Good constraints do not make the model less creative. They keep it pointed in the right direction.

Useful constraints sound like this:

Do not invent facts. If a fact is missing, write "needs source" instead.
Use only the information pasted below.
Ask up to three clarification questions if the task is ambiguous.
Return the answer as JSON matching this schema.
Do not edit files outside the src/components folder.
Prefer simple language over marketing language.

These boundaries are boring. They also save hours.

Ask for the process when the task is complex

For simple tasks, direct prompting is fine. For complex tasks, ask the model to slow down.

Chain-of-thought research showed that large language models often perform better on reasoning tasks when prompted to work through intermediate steps. You do not always need to see a hidden internal reasoning trace, and many modern tools handle reasoning differently now, but the practical lesson still matters: complex work improves when you separate thinking from final output.

Instead of asking, "Build me a marketing plan," ask for stages:

First, identify the audience and assumptions.
Then list possible angles.
Then choose the strongest angle and explain why.
Then draft the plan.
Finally, critique the plan for weak points.

This works because the model is less likely to collapse everything into a polished but shallow answer. It has to make its intermediate choices visible enough for you to correct them.

Treat AI output like a first draft, not a final authority

Even with great instructions, AI can be wrong. It can cite the wrong source, misread your intent, or produce code that looks clean but breaks an edge case.

The point of better instructions is not blind trust. The point is better raw material.

For writing, that means you still edit. For code, you still run tests. For research, you still check sources. For business decisions, you still apply judgment. AI can move the work forward, but it should not quietly replace verification.

A good workflow is simple:

Brief the AI clearly.
Review the output critically.
Ask it to revise against specific feedback.
Verify facts, links, code, and assumptions.
Save the prompt pattern if it works.

A reusable instruction template

When a prompt matters, use this structure:

Role: What perspective should the AI take?

Task: What exactly should it produce?

Context: What background does it need?

Audience: Who is this for?

Constraints: What rules, limits, or preferences matter?

Examples: What should it imitate or avoid?

Output format: Markdown, JSON, bullet list, table, code patch, email, article, or something else?

Verification: How should the result be checked?

Here is a practical version:

You are an experienced technical editor. Rewrite the article below for independent developers who use AI tools. Keep the tone direct and human. Remove hype, vague claims, and filler. Preserve the main argument. Add concrete examples where the draft is abstract. Do not invent sources. Return the result in Markdown with H2 headings, short paragraphs, and a final checklist.

That prompt will not solve every problem. But it gives the model a real assignment instead of a wish.

The better question

When AI gives you a bad answer, do not only ask, "Which model should I use instead?" Sometimes the better question is, "What did I fail to tell it?"

Did you define the audience? Did you include context? Did you show examples? Did you explain what good looks like? Did you set boundaries? Did you ask for sources? Did you verify the result?

Better models help. Better instructions help more often than people want to admit.

Your AI might not be bad. It might just be under-briefed.