Giving AI Useful Context

Describe a coding task with the right goal, code, constraints, and checks without burying it in unrelated material.

On this page

A starting question

“Fix my app” gives an assistant almost no way to tell which behavior is wrong. What would help it propose a smaller, checkable change?

State the behavior you expected, what happened instead, how to reproduce it, and the relevant boundary. Then add only the code and constraints needed to investigate. Better context does not mean sending every file.

Mental model

A useful task has goal + evidence + scope + constraints + acceptance checks. That structure helps a human teammate too. The assistant’s response is still a proposal to review, not a completed requirement.

Give the task a clear boundary

Suppose a search box shows results for an older query. A useful request might say: “When I type cat after ca, the older ca response can replace the newer results. The search handler is in the attached file. Keep the current UI and API contract. Add a test that covers responses finishing out of order, then propose the smallest fix.”

That tells the tool what failed, where to look, what must not change, and how to check the result. GitHub’s agent guidance recommends clear, well-scoped tasks with acceptance criteria and relevant file hints.This is guidance for one product, but the task-shaping principle is general.1

Provide evidence, not a guessed diagnosis

Share the error message, a minimal reproduction, or the failing test before declaring a cause. “This is a React bug” could steer the assistant away from an out-of-order network response. Relevant context may include the call site, data shape, framework version when behavior depends on it, and project conventions.

Ask the assistant to identify assumptions it cannot verify. If it needs another file, review why. Do not paste credentials, customer data, or an entire private repository merely to be thorough; OWASP’s guidance treats data access as a security boundary.More context is not automatically safer or more accurate.2

Work in reviewable steps

For a broad task, separate diagnosis, proposed change, tests, and review. After each step, compare the result with the goal. A small correction can then stay small. If the assistant edits unrelated files, stop and inspect the diff before adding more instructions.

The best prompt cannot make an incorrect result correct. Its job is to make the work easier to evaluate.

Recap and try it

Describe the observable problem, relevant context, limits, and success check. Share only what the task requires, then review each result.

Reflect, then reveal each answer.

  1. Rewrite ‘Fix the login page’ as a checkable task. What information belongs in it?

    Include the expected and observed behavior, reproduction steps, relevant files or error, constraints such as preserving the API, and a test or manual check that would show the fix works. Exclude secrets.

How this connects

  1. Software Fundamentals That Still Matter

    Next: know enough about the system to judge whether a proposed fix belongs at the right boundary.

  2. The JavaScript Runtime, Event Loop, and Async Code

    A deeper example of out-of-order asynchronous responses.

References & further reading

References & further reading2 sourcesPrimary standards and official documentation used for this lesson.
  1. Application card: GitHub Copilot Agents (opens in a new tab)

    GitHub Docs

    Well-scoped tasks, acceptance criteria, relevant repository context, and verification

  2. Secure Coding with AI Cheat Sheet (opens in a new tab)

    OWASP Cheat Sheet Series

    Limiting sensitive context and reviewing tool access

Return to the learning path