Prompt engineering is the deliberate design of instructions, context, constraints, examples, and expected output for an AI model. It turns a vague request into a useful working brief: tell the model what problem it is solving, what it should produce, and what limits matter. Strong prompts improve relevance and accuracy, but they do not remove the need for developer judgment. section 9.1 section 9.1.1 section 8.1
Start with the task, then add only the information that helps: relevant project context, clear active instructions, technical requirements, edge cases, examples, and a requested format. Break complicated work into manageable steps rather than asking for an entire solution at once. If the response misses the target, continue the conversation: clarify, constrain, provide an example, or ask for a revision. section 9.2 section 9.5.1
A practical prompt can include these parts:
- A role or perspective when it meaningfully shapes the response, such as a software design expert. section 3.3
- A specific task with explicit deliverables, such as code, a docstring, test cases, or a structured design document. section 9.1
- Context and constraints, including the application goal, existing environment, audience, tools, and nonfunctional needs. section 3.3 section 9.3.1
- Examples or sample input and output when format, style, or edge cases need to be made concrete. section 9.1
- A review loop that evaluates generated results and refines the request until they are useful. section 9.4.5
From vague request to implementation brief
Instead of “Write a function to validate email addresses,” request a Python function that accepts one string, checks @ placement, domain format, and allowed characters, returns a Boolean, handles errors, includes a docstring, supplies three tests, and covers common edge cases. The second request makes both the requirements and the expected artifacts visible, giving the model less room to guess. section 9.1
Prompting is also useful before code exists. Ask for common edge cases, regulatory considerations, nonfunctional requirements, or pitfalls to expose design blind spots. For requirements extraction, define scope, request categorized output, ask for pitfalls, follow up on uncertain areas, and validate the result with stakeholders or domain experts. AI can invent plausible but unnecessary requirements. section 3.2 section 4.2
Refinement favors precision over ornament. Use specific examples, numbers where useful, direct active language, and no filler tokens. It is fine to begin with an abstract request, but add detail when output is unsuitable. Prompt engineering can itself be prompted: ask a model to identify missing context, ask clarifying questions, and rewrite a draft prompt for the intended audience and constraints. section 7.1.3 section 9.3
Treat AI as a collaborator, not an authority. Generated code and requirements can be incomplete, insecure, inefficient, or poorly matched to the project. Review outputs, understand changes, test them, and refactor where needed. Prompt quality improves the starting point; validation keeps control with the developer. section 2.5.2 section 5.0
