What Prompt Engineering Actually Is: A Task, a Test, and a Revision

If you have ever typed “help me code” and received a polished answer you could not use, you have already met the central problem in prompt engineering. The model responded to the words you gave it, but the words did not define a useful job. I like to think of a prompt as a small work order. A work order does not need to be long. It needs to say what to do, what information matters, and how we will know whether the result is usable. Then we test it. If it fails, we revise it. That is the whole loop. To decide whether a polished answer is actually usable, read How to Tell Whether an AI Answer Is Any Good and define the checks before you prompt.

Suppose I want help with a Python function that sorts a list of game scores. This first prompt sounds normal: Help me sort my scores. It leaves almost everything open. Are higher scores better? Should equal scores keep their original order? What should happen with an empty list? Does the model need to explain code, write code, or review existing code? A plausible answer may still be the wrong answer for my program. I can make the job testable: Write a Python function rank_scores(scores) that returns a new list of integer scores in descending order. Do not mutate the input list. The input may be empty. Show the function and three tests: a normal list, an empty list, and repeated scores. Use only the Python standard library. Now I know what to inspect. This prompt gives the task, relevant context, constraints, and output. It also asks for tests. Google’s prompt design guidance recommends clear instructions and treating prompt design as iterative; Anthropic’s prompting guidance likewise emphasizes specifying the task and using examples where they help.

The model may produce a function and tests, but those tests are only suggestions until you run them. I would check at least these properties: rank_scores([10, 40, 20]) returns [40, 20, 10]. rank_scores([]) returns []. rank_scores([20, 20, 10]) preserves both 20s. The original list is unchanged after the function call. The fourth check matters because “returns a new list” is easy to miss in code that sorts in place. If the code fails there, I do not ask the model to “make it better.” I point to the observable failure: Your function changes the input list. Keep the same function signature, return a separately sorted list, and add a test that proves the original list stays unchanged. That is a revision with a reason. It changes one thing and keeps the rest stable.

An answer can be clear, confident, and formatted beautifully while still failing the job. A test is not always automated code. If the task is a summary, your test might be: does it accurately include the three decisions in the meeting notes without inventing a fourth? If the task is a travel plan, it might be: are the places open on the proposed day, and is the route feasible? The test has to match the task. For factual work, check important claims against the original source. For code, run the program. For creative work, compare the output against a brief or ask real users. The model is a collaborator in drafting, not the final authority.

Choose a task you asked AI to do this week. Write four lines before you prompt it: Task: What action should the model take? Context: What details would change the answer? Output: What form would let you use it? Test: What would make you reject it? Run your first version. Note one failure. Revise only the part that caused that failure and test again. Save both prompts and results. The difference teaches you more than a list of “perfect prompts” ever will. Keep learning: Make a Bad Prompt Better in Three Edits, How to Tell Whether an AI Answer Is Any Good, and How to Test a Prompt on More Than One Example.