Comment by Ahmet Özel on "Prompt Engineering: Designing Effective LLM Prompts"

Ahmet Özel

AI Engineer. Computer Vision, RAG and LLM agents.

Worth adding the operational half to this: a prompt is a production artifact, so it needs the same handling as code. Version it in the repo rather than editing it in a console, and keep a small fixed set of examples you rerun after every edit - otherwise the only way anyone discovers a prompt change was bad is a user complaint two weeks later. The smart-contract example makes another point implicitly. When the output feeds code rather than a person, the highest-leverage instruction is usually the output contract: give it a schema and validate against it, so a malformed response fails loudly at the boundary instead of flowing downstream as a plausible-looking value.

Sundarapandy

5d ago

Absolutely. Treating prompts as production artifacts is an important part of making prompt engineering reliable. Versioning prompts and rerunning a fixed evaluation set after every change gives teams a much better way to catch regressions before users do. I also agree on the output contract. When LLM output feeds another system or code path, schema validation creates a clear boundary where malformed responses can fail loudly instead of becoming downstream issues. Great point!

One small addition on the eval set, since it is the part that decays: keep a couple of cases in it that the current prompt gets wrong on purpose. A suite that is all green stops telling you anything, and the failing cases are what show you whether an edit moved the boundary or just reshuffled the wording.

Search Hashnode