Module 3 · Ask clearly
Improving the result over a few rounds
In short
Do not just say "try again". Find the checklist part that missed, give specific feedback, and test reused prompts on 5 to 10 real examples.
After this lesson you can
- Diagnose which checklist part made the first answer miss
- Give specific feedback, not just try again
- Test an important prompt on 5-10 real examples before relying on it
Terms in this lesson
Understand
The first answer from AI is rarely right on the mark, and that is normal. A new colleague is rarely right on the first try either. What separates people who finish quickly from people who go in circles is how they improve it.
The first step is to diagnose, not to repeat. Before you write anything, ask: which part of the checklist made this answer miss? The symptom usually points to one part. If the content is right but the focus is wrong, the Goal is unclear. If the language is too technical or too shallow, the Reader was not named. If there are facts you do not recognise, Material is missing or the model was not told to add nothing from outside. If it is too long or the tone is off, the Limits are not firm. If you have to rearrange the result, the Shape was not named. If you do not know which part to check, Check was skipped.
The second step is specific feedback. "Not good, try again" almost always produces another version with the same problem, because the model does not know what was wrong. Useful feedback has three parts: what is wrong, what to keep and what to change. For example: "Too long and too formal. Keep the three steps and the start date. Make it at most 120 words with the greeting 'Hi team'." One specific round is worth more than five rounds of "try again". Once a fix works, fold it into your original prompt, so next time you do not have to repeat the same round.
The third step applies to prompts you will use again and again, for example to summarise a weekly report or to group customer questions. Before you rely on one, test it on 5 to 10 real examples, including a few hard ones. A prompt that works on one easy example can fail on a messy one. If something misses, fix the prompt, then run all the examples again, not only the one that failed.
If the conversation is already very long and new rounds make the result worse, start a new conversation with the improved request. The reason is covered in the lesson Tokens and the context window.
We call that collection of 5 to 10 examples a test set. Running it and judging the results is called evaluation. It sounds technical, but for office work it is simple.
Choose the examples on purpose. Take two or three of the most ordinary ones, then add hard ones: a very long one, an almost empty one, one in mixed language, one that holds two requests at once, and one that went wrong before. Mask the personal data. Keep them all in one place so you can use them again.
Write down what a "good result" means before you run the prompt, in three to five yes-or-no statements. For example: every figure comes from the material, no more than 150 words, every complaint lands in one group, gaps are written as "not mentioned". If you only think about the measure after seeing the result, you tend to forgive a result that looks tidy.
Change one thing per round. If you change goal, limits and shape at once, you will not know which change helped. Note each prompt version and its results in a simple document.
Remember too that the same prompt can give different answers each time it runs, as explained in the lesson Answers that change. For important examples, run it twice. If the results differ a lot, the prompt is not clear enough yet.
Before
The prompt
Not good, try again.
What came back
Certainly, here is an improved version: Dear colleagues, With respect, we hereby inform you that, for the orderly administration of personnel matters, as of the 1st of next month the leave request procedure will be adjusted as set out below. First, every employee is expected to fill in the leave request form through the HR system. Second, ...
After
The prompt
The draft is too long and too formal for our own team. Keep the three request steps and the start date. Change: at most 120 words, greeting "Hi team", the steps as a numbered list, drop the opening paragraph about orderly administration. Add one closing sentence: who to ask if unsure, which is the HR team.
What came back
Hi team, From the 1st of next month, leave requests work a new way: 1. Fill in the leave form in the HR system at least 5 working days before your leave. 2. Your line manager approves or declines within 2 working days. 3. Once approved, add your leave to the team calendar. Sudden sick leave is still reported to your manager the same day, with the form following later. If anything is unclear, ask the HR team.
What changed
- "Try again" says nothing about what was wrong, so the model only swaps words and stays formal.
- Good feedback names what is wrong (length, formality), what to keep (steps, date) and what to change.
- The diagnosis is clear: Limits (length, tone) and Shape (numbered list) missed, not Material.
- Checking is still needed: a sick-leave sentence appears in the new version, so match it against the real policy.
Common mistake
- Mistake
- Trying a prompt on one easy example, then using it for all similar work.
- Why it hurts
- Failures show up on examples you never tried: long ones, empty ones, mixed-language ones. Because the result still looks tidy, the mistake is found only after someone else has used it.
- Do this instead
- Prepare a test set of 5 to 10 real, masked examples, hard ones included. Write the measure of a good result first, and rerun every example each time the prompt changes.
Try
You ask AI to summarise a sales report you pasted. The summary mentions "up 12% on last year", but your report has no figures for last year. Which checklist part most needs fixing?
Follow one healthy round of improvement, from the first answer to a prompt ready for reuse.
Step 1 of 5
Read the first result
Mark what missed without rewriting straight away.
Take home
Specific feedback
Works with any AI assistant.
Your prompt
This result is not right yet: ‹yang-salah›. Keep ‹yang-dipertahankan›. Change ‹yang-diubah›. Do not change anything else.
Improving without going in circles
- I first diagnose which checklist part missed.
- My feedback names what is wrong, what to keep and what to change.
- I fold a fix that worked back into the original prompt.
- I test reused prompts on 5 to 10 real examples, hard ones included.
- I change one thing per round and rerun every example.
What went wrong for us
Run the tests that prove the change
- Context
- A large repository has thousands of tests. Running them all for every small change takes a long time.
- What tends to go wrong
- If every small fix waits for the full suite, fixes reach users slowly, and unrelated failures hide the ones that matter.
- What it costs if ignored
- Time is wasted, and the signal from the relevant tests is drowned out.
- Root cause
- More tests feel safer, when what matters is the tests that touch the change.
- How we do it
- We pick the tests relevant to the changed files, plus the type check, lint on changed files, and the real build.
- The rule we keep
- Every task plan names the tests to run.
The lessonPick the tests that prove your change, not every test there is.
What it means for your workWhen checking a small change, pick the checks that actually prove that change, rather than rerunning every check there is.
