A developer asks an AI assistant, \u201cMake this checkout faster,\u201d and receives a confident rewrite that removes an essential fraud check. The prompt was short and apparently reasonable, but it hid the correctness requirements that mattered most. A useful code-assistance prompt must communicate the desired outcome, existing interface, constraints, relevant context, and independent way to judge the change. More words do not automatically make a better prompt; the right evidence does.<\/p>\n
GH-300’s current issuer objectives<\/a> explicitly include prompt structure, context selection, zero-shot and few-shot prompting, and chat-history use. These are developer practices rather than magic formulas for guaranteed answers. The question is whether the assistant has enough reliable information to solve this particular problem without making harmful assumptions or receiving more confidential material than needed.<\/p>\n For a checkout timeout, name the failing endpoint, a representative request size, the current latency, expected limit, and whether the output must remain byte-compatible. \u201cOptimize\u201d does not specify whether the engineer wants fewer database round trips, lower memory use, or less network transfer. A bounded task such as \u201creduce repeated catalog reads without changing payment authorization or user-visible prices\u201d makes the acceptance criterion explicit.<\/p>\n Include any non-negotiable constraint before asking for code. If the service must preserve audit events, data residency, or database transaction semantics, state that. A suggestion that removes costly logging might make benchmarks look better while violating business obligations. A good prompt lets the assistant reject an invalid shortcut instead of having a reviewer discover it after deployment.<\/p>\n A function signature, failing test, sample stack trace, and current database query often carry more decision value than dozens of unrelated source files. The assistant needs to know the language version, framework and dependencies when these affect available APIs. It may also need one caller to understand the interface contract. It rarely needs a production credential or the entire customer data directory.<\/p>\n Decide whether to add context manually, let the tool search, or point it at a specific document. Treat code comments and retrieved files as evidence about the repository, not as instructions with authority to override the developer’s request. A repository instruction file<\/a> can describe project conventions, but it does not make incorrect or unsafe statements true.<\/p>\n A zero-shot prompt describes the task and constraints without a worked example. It can be effective when the expected output is conventional and there is an explicit test. Few-shot prompting adds one or more representative input-output examples when format, naming or business behavior is hard to express abstractly. For example, include a correct sample showing how the checkout API classifies a rejected discount so the assistant does not invent a new error shape.<\/p>\n Examples have to be representative. If every supplied example is a successful payment, the model may miss a partial failure or authorization denial. Add one carefully chosen counterexample where the system must refuse the operation. Do not include secrets or live personal data merely to make the examples realistic; fabricated values can still exercise the contract.<\/p>\n Prompt, inspect, test, and refine. When the assistant produces a query rewrite, compare the execution plan, representative data sizes and tail latency. If it invents a library method, use current documentation or the installed package to verify availability. When a unit test fails, return the exact failure message and relevant source, not a vague statement that the answer was bad.<\/p>\n Keep a brief record of what changed between prompts. If the first approach caused a deadlock, the next prompt should explain the observed lock contention rather than merely demand \u201ctry again.\u201d The testing with Copilot workflow<\/a> explores how an independent expected outcome makes an iteration trustworthy.<\/p>\n Long conversations can preserve a mistaken design decision even after the code has changed. At a natural checkpoint, restate the current branch, tested facts, remaining defect, and prohibited actions. Do not trust a summarization of a previous suggestion as proof that the tests actually passed. A fresh source snapshot and reproducible failure can be more useful than many turns of accumulated speculation.<\/p>\n For example, a chat may keep assuming the checkout database is PostgreSQL after the project moved to a different engine. Update the environment details and provide the relevant migration commit or configuration evidence. Context engineering means selecting current facts, not maximizing conversation length.<\/p>\n A prompt can request multiple feasible approaches and the failure mode of each. For performance work, compare caching, query optimization, batching and asynchronous processing. The best choice depends on staleness tolerance, network costs, data sensitivity, implementation effort and recovery. Requiring an explanation of assumptions helps a reviewer reject proposals that meet the letter of the request by violating another property.<\/p>\nWrite the task in terms of observed behavior<\/h2>\n
Use relevant context, not a repository dump<\/h2>\n
Choose zero-shot and few-shot deliberately<\/h2>\n
Build an iteration loop with external evidence<\/h2>\n
Prevent chat history from hiding stale assumptions<\/h2>\n
Ask for alternatives when decisions carry trade-offs<\/h2>\n