Prompt Engineering Essentials for Computer Science Students: A Practical Guide to AI-Assisted Programming, Debugging, and System Design

Almost everything written about prompt engineering is a list of tricks with no account of why any of them work. A list cannot be reasoned from: when a trick fails, the reader has nothing to fall back on, and when a new model arrives, the list expires.

This textbook is built on the observation that there is a theory underneath, that it is four sentences long, and that it predicts which tricks work and when. A language model is a conditional probability distribution over tokens. A prompt is the conditioning. You cannot control the distribution — so the discipline is not really about producing text at all. It is about controlling what you accept from it.

The central result is a cost model, derived in Chapter 9, that turns "does AI assistance help?" into a calculation with an answer. Measure five numbers for a task — how long it takes to write, to check your own work, to write the prompt, to verify what came back, and to fix it when it is wrong — and the model returns the exact accuracy at which delegating begins to pay. It also returns something less comfortable: a perfect model would not make programming arbitrarily faster. It would make it (w + v)/(g + v) times faster and no faster, because the human must still specify the task and check the answer. That single quantity reconciles benchmark scores that rise steeply with measured developer productivity that does not.

What is inside

Twenty chapters in five parts. Part I derives what a language model is and what follows: conditioning, the context window as a budget whose cost grows as the square of a conversation's length, sampling, and a taxonomy of failure derived from the training objective. Part II treats the prompt as a specification — anatomy, few-shot learning, chain of thought as serial depth rather than deliberation, and structured output as a four-rung ladder ending in constrained decoding. Part III is the longest and the reason for the book: the cost model, the pass@k estimator derived in full, property-based and metamorphic testing, and a review protocol for code you did not write. Part IV applies all of it to four tasks students actually do — multi-language generation, AST-verified refactoring, debugging, and algorithm optimisation measured rather than claimed. Part V covers context engineering, agents and their four failure modes, evaluation with error bars, and the judgement to decline the right tasks.

Twenty-one complete programs, each executed, each printing the output reproduced beneath it. Python, the standard library and NumPy — nothing else, and no model is called: a seeded stand-in with a stated accuracy takes its place, so that a claim about a workflow can be measured rather than asserted. Fifty computed figures, where every curve is the model beside it evaluated. Twelve prompts shown in full, never paraphrased. Appendix B re-derives eight of the book's headline numbers as a reproducibility check on the reader's own machine.

For undergraduate computer science students who can already program, are already using a language model to write code, and have no way of telling when it is working. No machine learning is assumed — not backpropagation, not attention, not the transformer architecture.

The tone is optimistic and the optimism is meant to be earned. A student in 2026 has access to a tool that removes a genuine and previously irreducible cost from programming. What that student does not yet have is a way of telling when the tool is working — and that is a solvable problem, solvable with arithmetic and a test suite rather than with better prompts.