One-Shot Prompting: Better AI Answers With One Example

When AI gives me a vague answer, I first check what I asked for and what context I provided.

Two techniques you can test are one-shot prompting (give the model one good example) and context placement (put critical instructions at the beginning or end). Neither requires a framework or fine-tuning; results depend on the model and task.

One good example beats a paragraph of instructions

One-shot prompting means exactly what it sounds like: you include one high-quality example in your prompt and let the model generalize from it.

Think of pair programming with a coworker. You don’t hand them a spec on “how we format things here”. You say: look at how we did this last time, now build the new one the same way.

An example gives the model a concrete pattern for format, tone or transformation. It can clarify what a description leaves ambiguous, but it does not replace test cases: check inputs that differ from the example too.

Sentiment analysis: show the format once

Say you want customer reviews classified as positive, negative, or neutral. The example shows how to handle a review with mixed opinions.

Prompt:

You are a sentiment analysis expert. Classify the following customer review into one of three categories: “Positive”, “Negative”, or “Neutral”.

Example: Review: “The product arrived quickly, but the packaging was damaged. The item itself works perfectly.” Sentiment: “Neutral”

Now, classify the sentiment of this review:

Review to Classify: “This software update is terrible! It broke half my features and is incredibly slow now.”

The example does the heavy lifting, so pick it well

• Choose it carefully: it sets the pattern for everything that follows.
• Make it representative. An edge case as your only example teaches the model the edge case.
• Include every element you want in the output.
• Add explicit instructions where the example alone is ambiguous.
• Don’t overcomplicate it. The model generalizes the pattern.

Code refactoring: the pattern is the prompt

Here’s a one-shot prompt that refactors JavaScript from promise chains to async/await.

Prompt:

You are an expert JavaScript developer. Refactor the following function to use async/await syntax while keeping the logic identical.

Example: Original Code:

function fetchData(url) {
  return fetch(url)
    .then((response) => {
      if (!response.ok) {
        throw new Error("Network response was not ok");
      }
      return response.json();
    })
    .then((data) => {
      console.log("Data received:", data);
      return data;
    })
    .catch((error) => {
      console.error("Fetch error:", error);
      throw error;
    });
}

Refactored Code:

async function fetchData(url) {
  try {
    const response = await fetch(url);
    if (!response.ok) {
      throw new Error("Network response was not ok");
    }
    const data = await response.json();
    console.log("Data received:", data);
    return data;
  } catch (error) {
    console.error("Fetch error:", error);
    throw error;
  }
}

Now, refactor this function:

Function to Refactor:

function getUser(id) {
  return database.findUser(id).then((user) => {
    return getPermissions(user.role).then((permissions) => {
      user.permissions = permissions;
      return user;
    });
  });
}

Data extraction: an example to define the structure

This is where one-shot earns its keep. Show the model the input text and the exact JSON you want back, and you turn unstructured text into something your code can parse without ceremony.

The example clarifies the expected structure, but it guarantees neither valid JSON nor correct data. Parse the response and validate its fields against a schema before storing it. Avoid filling missing data with guesses.

Prompt:

You are a data extraction specialist. Your task is to extract specific information from a user’s message and format it as a JSON object.

EXAMPLE: Text: “Hi, I’d like to book a flight for two adults from New York (JFK) to Los Angeles (LAX) on December 25th, 2025. I’d prefer a morning flight on Delta.”

JSON Output:

{
  "intent": "book_flight",
  "passengers": {
    "adults": 2,
    "children": 0
  },
  "origin": {
    "city": "New York",
    "airport_code": "JFK"
  },
  "destination": {
    "city": "Los Angeles",
    "airport_code": "LAX"
  },
  "date": "2025-12-25",
  "preferences": {
    "time_of_day": "morning",
    "airline": "Delta"
  }
}

---

YOUR TASK: Extract the relevant information from the following text and format it as a JSON object, following the example’s structure.

Text to Process: “Hi, I’d like to book a flight for three adults from Austin (AUS) to New York (JFK) on March 10th, 2026. We’d prefer an afternoon flight with American Airlines.”

Information in the middle of a long context can get lost

Context windows keep growing, and the marketing implies you can throw anything at them and the model will sort it out. The research says otherwise. “Lost in the Middle: How Language Models Use Long Contexts” found that models perform best when the critical information sits at the beginning or end of the context window.

For the tasks and models in the study, performance could fall when relevant information sat in the middle of the context. That does not show that every current model ignores that part of a prompt: test the model you use with your own documents.

If you build a RAG pipeline that adds documents to a prompt, test different positions for relevant information. A large window lets you include more text; it does not guarantee that the model uses every passage well.

A constraint buried mid-document gets silently dropped

Picture a task where you summarize a long document under one specific constraint: the summary must include a particular piece of information (a product code, a key date, someone’s name) that might appear exactly once, in the middle of the text.

Put the constraint (“Include product code XYZ123 in the summary”) in the middle of a long document and the model may skate right past it, handing you a summary that misses the one detail you needed.

To make it stick, place it at the beginning or end of your prompt, clearly separated from the document itself.

Prompt:

IMPORTANT CONSTRAINT: Your summary MUST include the product code “PROD-789”.

Summarize the following document in 3-4 sentences, focusing on the key features and benefits.

[Long Document Content Here, where “PROD-789” might be mentioned once in the middle]

Alternatively, you could place the constraint at the very end:

Summarize the following document in 3-4 sentences, focusing on the key features and benefits.

[Long Document Content Here]

IMPORTANT CONSTRAINT: Ensure the summary mentions product code “PROD-789”.

Where to put what

• Start fresh when you can: a new chat is a focused context.
• Front-load the critical instructions, data, or questions.
• New important information? Append it to the end. Don’t splice it into the middle.
• The middle is for the supplementary stuff the model can afford to skim.

Test the same case with and without an example, and move the critical instruction to the beginning or end. Compare the answers and check whether they meet the task before using the prompt in your application.

Related reading: once your prompts behave, the next rung is not writing them at all: stop prompting your agent, start writing loops.

P.S. Got a prompt that refuses to behave no matter where you put the context? Show me on LinkedIn.