Topic: Learning notes

What Is Prompt Engineering? Turning a Question into a Testable Task

Notes from Practical Prompt Engineering: use a JavaScript closure example to understand prompts, context, output requirements, and repeatable checks.

I recently started Practical Prompt Engineering on Frontend Masters. This first note focuses on one question: when we say we are doing prompt engineering, what are we actually changing?

Prompt engineering is the process of designing, testing, and revising model inputs to help a large language model perform a specific task more reliably. A prompt can include instructions, background material, examples, and requirements for the content and format of the response. The Hugging Face introduction also emphasizes being specific about the task and expected result.

This article covers that definition and an original frontend learning example. It supplements the course’s LLM introduction with the original research paper and official documentation. The example prompts have not been tested against a model, and no accuracy comparison has been measured.

What information belongs in a prompt?

A question typed into a chat interface is one kind of prompt. For a more specific task, the input might also contain a document to summarize, some code, or an example of the desired output.

“Explain closures” identifies a topic, but leaves several choices open: how much JavaScript does the reader know, what example would help, and how detailed should the answer be? The model can still respond. Its choice of explanation may simply differ from what I need.

I start by asking what information the task requires: what should be done, what background matters, and how should the result be presented? Include as much as the task needs. A short question may already be sufficient; a full template is not necessary every time.

Why does changing the prompt affect the answer?

The course introduces LLMs through next-token prediction. A typical autoregressive text model uses its available input and previously generated content to compute probabilities for the next token, then continues according to a decoding strategy. Tokens are units used to process text and do not necessarily correspond to whole words. Section 3 of the Transformer paper describes generating output step by step using earlier output; the Hugging Face generation guide distinguishes selecting the most likely token from sampling and other strategies.

For prompt design, that means “the reader has just learned functions” and “include a counter example” become conditions available during generation. They may help the response fit its audience and purpose. The result still needs checking; a prompt that looks complete has not yet demonstrated that it works.

The course also references the 2017 paper Attention Is All You Need. It introduced the Transformer architecture, built around attention, improving parallelization and the learning of long-range dependencies. Attention mechanisms existed before that paper. For this introduction, I keep that historical connection without going further into the architecture. Original paper

Make the desired explanation explicit: a closure example

The initial prompt can be short:

Explain JavaScript closures.

If the goal is to help someone who has just learned functions understand an example that preserves state, I can revise it:

Explain closures in Traditional Chinese as used in Taiwan, for someone
who has just learned JavaScript functions.

Answer in this order:
1. Explain the core idea in two sentences, defining any necessary terminology.
2. Provide a simple counter written in plain JavaScript.
3. Show three consecutive calls to the counter and their expected output.
4. Explain why the inner function can still access count after the outer
   function has returned.

The example should run directly in a browser console.

The article is translated into English, while the example retains its original requirement to produce Traditional Chinese. The second prompt makes several choices explicit:

The observable difference between these prompts is that the second supplies more requirements that can be checked. Whether it produces better answers from a particular model requires testing both versions. This note includes no imagined model responses and does not treat the prompt itself as an experimental result.

The engineering includes testing and revision

After writing a first prompt, I need a way to judge the response. For this closure example, I would record three success criteria: the code runs directly, the three outputs agree with the code, and the explanation accounts for the inner function retaining access to its outer bindings.

Those criteria make a round of revision concrete:

1. Save the prompt version, model name, available version information, and generation settings to support comparison.
2. Obtain a response and check each criterion, including actually running the code.
3. Record a specific gap, such as working code that never explains the scope of count.
4. Revise the prompt to address that gap, then check the original case and a related new case.

This is a proposed check for the article’s example; it has not been run. It follows the starting point in Anthropic’s prompt engineering overview: establish success criteria, a way to test them, and an initial prompt before optimizing it.

When comparing versions, output variation matters too. Sampling can produce different responses to the same prompt. One successful response establishes that the particular response met the requirements. Keeping multiple results and test cases helps assess how consistently that happens. Generation strategies

Clear prompts still face capability and information limits

A prompt can specify a need, but whether the model can meet it also depends on its capabilities and available information. “Make sure this is correct” supplies no supporting evidence. Asking about a newly updated API does not automatically give the model its latest documentation.

For recent information, I would provide the relevant document or use a search tool that can retrieve external material, then check whether the response is supported by those sources. Google’s search grounding documentation describes retrieving information beyond a model’s knowledge cutoff. Information from before the cutoff can still be wrong; its date alone does not establish correctness.

To begin this exercise, I would write down the task and success criteria, then decide which information belongs in the prompt. Once there is an actual response, those criteria provide a way to identify gaps. Each revision can then have a recorded reason that can be revisited and tested again.

The next note covers Temperature and Top P, using probability distributions to explain sampling settings alongside prompt design.

References and scope

• Sabrina Goldfarb, Practical Prompt Engineering slides: this article covers the opening “What Is Prompt Engineering” and introductory LLM material.
• Course companion site, Introduction to LLMs: the course’s introduction to generation and Transformers.
• Vaswani et al., Attention Is All You Need: the original Transformer paper and its description of autoregressive generation.
• Hugging Face, Prompt engineering and Generation strategies: supplementary material on prompting, decoding, and sampling.
• Anthropic, Prompt engineering overview: success criteria and testing.
• Google, Grounding with Google Search: external search and recent information.

Sources consulted on 2026-10-15. The closure prompts and success criteria are original examples. This article contains no model experiment, accuracy comparison, or assessment of personal proficiency.