How to Improve AI Answers with One-Shot Prompting and Context Placement?

Most vague AI answers are not a model problem. They’re an input problem.

Two techniques fix a surprising share of them: one-shot prompting (give the model a single good example) and context placement (put the critical information where the model actually looks). No framework, no fine-tuning. They work on any LLM, today.

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.

It’s efficient because you skip enumerating edge cases. It’s more reliable than zero-shot (no example) because the model gets a concrete pattern to copy instead of a description to interpret. Instructions tell the model what you want; an example shows it. For anything that hinges on format, tone, or a specific transformation, that input-output pair is the anchor that keeps the model from improvising.

Sentiment analysis: show the format once

Say you want customer reviews classified as positive, negative, or neutral. One example teaches the whole task.

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: one example, parseable output every time

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.

Consistency is the whole prize. When the output always has the same shape, it plugs straight into databases, analytics tools, or whatever pipeline you’ve got, with no regex graveyard between the model and your code.

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: “Hey, can you find me a hotel in downtown Austin for 3 nights, checking in on March 10th, 2026? I need a room with a king-size bed and free Wi-Fi.”

Your model ignores the middle of your prompt

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.

The uncomfortable part of the study: when the important information was buried in the middle of a long context, performance didn’t just dip. In some cases the model did worse than with no context at all. More context, worse answer.

Sit with that before celebrating the next million-token announcement. A bigger window makes it easier to drown the one instruction that matters in pages of filler. If you build on top of LLMs, especially RAG pipelines that inject retrieved documents straight into the prompt, this is the failure mode to design against, because the model will happily act on everything except the detail you cared about.

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.

Next time an answer comes back vague, don’t reach for a bigger model. Audit the prompt first: is there an example in it, and is the critical instruction at an edge or drowning in the middle? Those two checks fix most of the answers you were about to complain about.

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 Twitter/X.