Getting Better AI Results by Being Specific

People who give clear instructions get better results, because there is less room to interpret them the wrong way. The same is true of an AI, with one difference: a person can ask what you meant, and an AI usually just picks an interpretation and carries on.

Our goal: understand why specific instructions get better answers from an AI, and learn the main tool for it in this course: naming the hat, or role, you want it to wear.

Here is the route:

1. One instruction, many interpretations: a story about a husband and wife.
2. The same thing with AI, on a note-taking app.
3. Hats: what they are, and how to ask for one well.
4. The hats you will meet in this course, software ones first.
5. Hats outside software.

We leave out agents that act on their own (lesson 04) and the full development process (lesson 06).

One instruction, many interpretations

A modern AI model is trained to follow instructions across a wide variety of work: answering questions, writing, summarising, explaining, planning, writing code. So one model has broad skill. It can write like an editor, think like an analyst and read code like an engineer.

Model builders also train for particular kinds of work. After a model has learned from lots of text, it can get extra training, with its own examples and feedback, on answering questions, on writing code, on reasoning step by step, or on doing multi-step tasks with tools (lesson 04). Each kind of training builds habits. A model that has had a lot of coding practice is quick to start coding.

This is general, and the details differ between builders. Keep the idea: a model comes with habits, and some of them are strong.

Broad skill, and strong habits, have a catch. With so many things it can do, the model has to guess which one you want. People have the same problem, so start there.

A husband and wife have a child who has lied about homework, for the third time. The wife asks the husband:

"Can you talk to our child about it?"

That sounds clear, and it is not. The husband could be:

• Strict: take the games away for a week.
• Gentle: explain why lying hurts trust, and what could follow if it carries on.
• A listener: ask why the child lied, and say very little.

All three are reasonable talks. The wife had one in mind and never said which.

The husband does what seems most natural to him. He is not careless. The instruction left room. If the wife wanted a firm response because it keeps happening, and he has a gentle chat, nothing changes. If she wanted the gentle talk and he is strict, the child is punished and the wife is upset. The words were the same, and each result is wrong in a different way.

Now see what a clearer instruction does:

"This is the third time. Be firm, and agree one consequence."

Notice what the fix did not do. It did not give the husband a new skill, because he could already do all three. It also was not an essay, only two short sentences. Specific does not mean long. It means closing the gap where a wrong interpretation would hurt. It said which path to take, and why.

In lesson 02, a fork was a decision about your shop. This is a fork too, but inside a single request: which way to look at it.

The same thing with AI

An AI is not careless either. It picks the most likely interpretation of your words, answers well on that one, and says nothing about the others.

There is one difference from the husband. He could ask, "Do you want me to be strict or gentle?" An AI usually does not ask. It picks an interpretation, and its tone is just as confident whichever one it picked (lesson 02: it does not flag its guesses). So more of the work of being specific falls on you.

The AI jumps straight to coding

Here is the most common case in software. You tell an AI:

I want to write a note-taking app with tags and search.

You want to talk it over first: what to build it with, how to store the notes, what to leave out. The AI takes the most likely interpretation. In software, the most likely interpretation of "I want to write an app" is "write the app". So it puts on the software engineer hat and starts producing code.

To write code, it has to choose a language, a front end and a place to store the notes. Say it picks Java, with a front-end framework and a database you would not have chosen. Those are real decisions, about what your team knows, where the app will run and what you can maintain. The AI made them silently, and because the code looks finished, the choices are easy to miss. These are forks (lesson 02): decisions only you can make, taken for you.

Java is only an example of a language you did not pick. A model will not always choose it. The point is that someone chose, and it was not you.

The AI is not wrong to try. It guessed, and you did not say. The fix is the one the wife used: name the hat. Ask for a solution architect, and ask for no code yet. Now the AI puts the choices in front of you instead of making them:

Asking about only one angle

Naming the hat fixes one problem. A second hides in the answer. Say you ask the architect only:

Which front-end framework should I use?

You get a good comparison of React and a few others. Nobody asked, and so nobody told you, whether you need a framework at all, where the app will be hosted, what it will cost, or how notes will be kept private.

Why does an assistant not simply cover everything? Two honest reasons:

1. It does not know what you care about. Hosting matters hugely for a business and hardly at all for a personal tool. It cannot tell which, so it takes the most likely interpretation, as the husband did.
2. Covering everything makes a long answer. The model produces its answer one piece at a time, as in lesson 01, so a thorough look at five angles takes longer and costs more. It also buries the one thing you wanted to know.

So by default the AI answers the angle your words suggest, and stops there. Silence is not a clean bill of health. If it did not mention privacy, you cannot conclude that privacy is fine. You may simply not have asked.

Hats

Back to the wife. The fix was to say which role the husband should play ("be firm") and what to aim for ("one consequence"). Doing that for an AI has a name.

A hat is a perspective you ask the AI to take: a role, plus the angle that role cares about. Think of a good senior colleague. On Monday they sketch the structure of a system with you. On Tuesday they review your code. On Wednesday they try to break it. It is one person wearing different hats.

A hat does not give the AI new knowledge. It tells the AI which part of what it has learned to bring forward first. It is a focus dial, not a capability upgrade. Asking for a security reviewer does not make the model know something it never learned. It makes the model look at security first.

The words you use for it do not matter much. "Act as a tester", "look at this the way a tester would" and "from a tester's point of view" all work. What matters is that you name an angle.

💡 Rule of thumb: a large part of getting better at working with AI is deciding which hat you need for your next question, and saying so. The AI cannot know what you prefer, so you choose.

Asking for a hat well

Naming a hat alone is not enough. "Act as a security expert and review this" still leaves the AI guessing what you care about. A good request for a hat has three parts:

The wife's second sentence had the same shape: the role ("be firm"), what to aim for ("one consequence") and the situation ("the third time"). Here is a weak request and a better one for the note-taking app.

Help me with my note-taking app.

Act as a solution architect. I want to build a note-taking app with
tags and search, for about 50 users, hosted cheaply. I know C# and a
little JavaScript.
Give me two or three ways to build it, covering the server language,
the front end and the storage. List the good and bad of each, and
recommend one.
Do not write any code yet.

We do not paste an AI answer here. Answers differ every time you ask, and yours will depend on the model you use. Try the second request yourself. Did it ask about your users? Did it give you options, or start coding anyway? Did it recommend one, and say why?

One hat per pass

It is tempting to ask for everything at once: "Review this for correctness, security, performance, readability and style." The answer tends to be shallow on all five. Four passes with one hat each tend to give four real answers.

Switching hats on the same material is normal. Developer, then tester, then reviewer on the same code is not a trick. It is the shape of the process this course teaches.

The hats you will meet

Here are the hats the course uses most, as a picture. It is a set of examples, not a complete set. You can invent others.

Each card below says what the hat looks at, with a short sample request. The architect is the hat from the story above, so it has no card.

Prompt writer

Looks at: the request itself. Its output is not an answer. It is a request for another hat.

Sometimes you know what you need but not how to word it. Tell the prompt writer what you want, and ask it to question you and draft the request. People sometimes call this prompt engineering. It is the same thing.

Act as a prompt writer. Help me write a request for an architect, for a
note-taking app with tags and search. Ask me questions first.

Read and edit the draft, because it carries the prompt writer's own defaults. One level is enough: a prompt that writes a prompt that writes a prompt only adds layers. And when a request works well, keep it. That is rule 2 from lesson 02 in practice.

Analyst

Looks at: what the tool must do, who it is for, and what has not been said yet.

Act as a business analyst. I want a note-taking app with tags and
search. Ask me who will use it and what is out of scope. No design yet.

Project manager

Looks at: small tasks, in a sensible order, with a line around what is in and out.

Act as a project manager. Break the note-taking app into small,
ordered tasks. Mark anything unclear instead of guessing.

Software engineer

Looks at: writing code to a clear description. It is the hat the AI wears when you do not say.

Act as a developer. In the stack we chose, write the part that saves
a note with its tags.

Tester

Looks at: inputs that break the code, and cases to cover.

Act as a tester. Find searches and notes that break the search feature,
such as an empty search, a very long note or odd characters in a tag.

Reviewer

Looks at: one angle per pass: security, speed, readability, or whatever you name.

Act as a security reviewer. Look only at how a shared note link could
be abused. Do not comment on style.

Hats outside software

Hats are not only about code. Lesson 02 had a support desk, and the same idea works there. The three-part request is the same: who, what to look for, what it is looking at.

The sceptic is useful anywhere, including software, as an extra pass that asks "what could go wrong?" after the other hats are done.

One more point, the same as before. A hat brings one angle forward. It does not promise to find everything, and it does not replace a person who reads the result.

Recap

• One model has broad skill, so one instruction can be interpreted many ways, as "talk to our child" can. The AI picks the most likely interpretation unless you say.
• With no hat named, an AI often wears the software engineer hat: it starts coding, and picks a language and tools you did not choose.
• An assistant answers the question you asked, from the angle you implied. Silence is not a clean bill of health.
• A hat is a perspective you ask the AI to take. It is a focus dial, not a capability upgrade, and you choose it.
• A good request has three parts: who, what to look for, what it is looking at.
• One hat per pass gives deeper answers than one request for everything.
• The prompt writer hat drafts the request for another hat. Read and edit its draft, and keep requests that work.
• Hats work outside software too: a support lead, an editor, a teacher, an accountant, a sceptic.

Questions to think about

The answers are left out on purpose. Try them in your own words first.

1. Why can one clear-sounding instruction lead to different results, even when the worker is capable?
2. You say "I want a note-taking app" and the AI starts coding. Which hat did it assume, and which did you want?
3. Why is silence from an AI not a clean bill of health?
4. Why are four separate hat passes better than one request for everything?
5. You are unsure how to word a request. Which hat do you ask for, and what must you still do yourself?

Next lesson: what changes when the AI can do things as well as say things, which is what "agentic" means.