Prompt Engineering

A vague request forces a language model to guess what success means. The result may be fluent but aimed at the wrong audience, missing required constraints, or formatted so it cannot be used.

Prompt engineering is the practice of making the task and its evaluation criteria visible in the input.

A Practical Prompt Structure

A useful prompt can state:

the goal;
relevant context and source material;
constraints and boundaries;
the specific input to transform or analyze;
the required output format; and
examples when the desired pattern is otherwise ambiguous.

Not every task needs all six parts. Add information that changes the answer, not ceremony.

Examples Change the Contract

A prompt with no worked example is often called zero-shot. One example is one-shot, and several are few-shot. Examples are especially useful when the output must follow a classification scheme, tone, or exact structure.

Examples also create risk: the model may copy incidental details or infer a rule that was not intended. Use representative examples and accompany them with an explicit rule when correctness matters.

Roles Are Context, Not Guarantees

“Act as a cloud architect” can suggest vocabulary and perspective, but it does not grant expertise or make an answer correct. A more useful instruction describes the actual audience, decision, constraints, and evidence available.

Compare:

Act as an architect. Design a network.

with:

Propose two network layouts for three regional services.
The operations team needs one place to maintain firewall policy.
Compare failure isolation and administrative complexity in a table.
State assumptions and flag any missing information.

The second prompt gives the result an inspectable shape.

Provide Repository Context for Code Work

A coding assistant cannot reliably infer conventions that are visible only elsewhere in a repository. Supply the context that changes the implementation:

the language, framework, and supported versions;
relevant directories and architectural boundaries;
naming and formatting conventions;
business rules;
the expected testing strategy; and
a nearby implementation that demonstrates the desired pattern.

Prefer pointing to small, representative files over dumping an entire repository into the prompt. State which details are requirements and which are merely examples.

For a code review, define both the scope and the evidence expected. Asking for findings about correctness, security, performance, readability, or test coverage is more useful when each finding must identify the affected location, explain the risk, and suggest a verification method.

Handle Uncertainty Explicitly

A language model generates plausible output and can produce unsupported claims. Instructions can reduce ambiguity, but they cannot prove factual accuracy.

For consequential work:

provide the authoritative material the answer may use;
ask the model to distinguish facts, assumptions, and recommendations;
require it to identify missing context;
verify claims, commands, and generated changes independently; and
keep a human responsible for the final decision.