Prompt Engineering

A prompt is the model’s entire world for a request, so the craft is mostly about removing ambiguity. State the task plainly, give the constraints the model cannot infer, show the output shape rather than describing it, and put the material the model must reason over where it will actually be read. Long prompts degrade in the middle more than at the ends, which is why instructions repeated briefly after a large block of retrieved context often outperform the same instructions stated only at the top.

The shift that matters as a project matures is from writing prompts to managing them. Prompts belong in the repository, referenced by version, with an evaluation set attached — otherwise a change that fixes today’s complaint silently breaks three behaviours nobody re-checked. Once you can measure, most tuning becomes unglamorous: clarify a term, remove a contradictory instruction, add two examples of the case that keeps failing.

The misconception is that better prompting can compensate for missing information. It cannot. If the answer depends on a document the model was never given, no arrangement of words retrieves it; that is a retrieval problem wearing a prompting costume. Prompting shapes how the model uses what it has — it does not add to what it has.