Prompt engineering in development is a separate discipline, different from "writing a good prompt in chat". Let us cover the differences and what matters: 1) Ordinary prompting (in chat, for yourself): — You write a prompt, see the answer, refine/rewrite on the fly if needed. — A one-off: if the answer is not perfect, you just try again or adjust. — A human reads and interprets the answer (forgives minor format flaws, understands context). — Flexibility: you can have a dialogue, clarify. 2) A prompt in an APPLICATION (production): — SCALE AND INPUT DIVERSITY: a prompt with a template works on THOUSANDS of different user inputs, many of which you did not foresee. It must work not on one example of yours but on all the diversity of real data. What worked on your test may break on an unusual input. — AUTOMATIC OUTPUT PROCESSING: the models answer is read not by a human but by CODE. Code needs a predictable, parseable format (e.g. strictly JSON). If the model returns an answer in a slightly different format or adds "chatter" around it — the code breaks. The format is critical. — RELIABILITY: a prompt failure in production is a BUG users see, not "I will rewrite and try". Robustness to different inputs, handling of failed answers, predictability are needed. — NON-DETERMINISM: the model may give DIFFERENT answers to one input (unlike ordinary code). This complicates things: you cannot rely on exact repeatability, you need to design accounting for variability (output validation, handling deviations). — MAINTENANCE AND EVOLUTION: the prompt lives in code, is changed, improved, versioned. Changing the prompt may unnoticeably break what worked (a regression). A discipline of changes and testing is needed (as in LLMOps). — PART OF A SYSTEM: the prompt is not an isolated thing but part of an application with error handling, cost (tokens), latency, monitoring (from the LLM-API and LLMOps courses). 3) What follows from this (course topics): — Treat the prompt AS CODE: version it, test it, change it disciplinedly (do not edit blindly in production). — Design RELIABLE prompts: robust to different inputs, giving a predictable format, with clear instructions. — System prompts: set the role, rules, constraints, format at the system level (not in each request). — Test prompts: systematically check on a set of examples (like evals from LLMOps), catch regressions on changes. — Reliable structured output: get a predictable format (JSON), validate it, handle failures. — Account for non-determinism, cost, security (injections — from LLMOps). 4) The key mindset shift: a prompt in an app is not "text I write to the model" but a SYSTEM COMPONENT that must reliably work on diverse inputs, give a code-processable result, be maintained and tested. This is an engineering discipline, not only "the art of phrasing". Practical rule: prompt engineering for developers is designing prompts as reliable, predictable, maintainable parts of an application. Unlike prompting in chat (one-off, for a human, flexible), a production prompt works on thousands of different inputs, its output is processed by code (a predictable format is needed), its failure is a bug, and it evolves like code (versions, tests). The course will teach treating prompts as code: designing reliably, setting behavior with system prompts, testing systematically and getting reliable structured output. All this is tied to the LLM-API (integration), LLMOps (operation, evaluation, security) and prompting (phrasing basics) courses — here the focus is on the ENGINEERING side of working with prompts in real applications.