Overview

1 Prompt engineering: The blueprint

Prompt engineering is presented as a deliberate design discipline rather than a casual habit of asking a model questions and hoping for the best. The chapter frames prompts as engineered interfaces that connect instructions, context, constraints, inputs, and expected outputs, and argues that this matters because model use in software systems can create real defects when prompts are vague or disposable. In that sense, prompt work belongs alongside the other practices software engineers already rely on: clear specifications, reviewable artifacts, and systematic debugging.

The chapter’s central contrast is between casual prompting and engineered prompting. Casual prompting is reactive, undocumented, and hard to reproduce; prompt engineering instead calls for prompts that can be composed carefully, tested against known cases, iterated on with evidence, and maintained over time. Through examples like pull-request summaries, incident summaries, and bug classification, the chapter shows that changing the prompt structure—not the model—often improves output quality by making the task, evidence, and response shape explicit. It also emphasizes that prompts should be self-contained, with any necessary team knowledge or task conventions spelled out inside the request.

To make prompt work repeatable, the chapter introduces a lifecycle of design, test, iterate, and manage, each with a concrete deliverable such as a draft, evidence, revision, or versioned artifact. It also offers three diagnostic lenses for troubleshooting: treat prompts as specifications, ensure they are self-contained, and inspect the prompt first when outputs vary. Together, these ideas establish the foundation for the rest of the book: prompts fail in diagnosable ways, and the path to reliable model behavior begins with clearer prompt design and stronger engineering discipline.

Prompt engineering mental model: Instructions and context enter a prompt, constraints shape the work, and the model response is evaluated against the expected output.
Chapter dependency map: chapter 1 establishes mental models; chapters 2 through 6 build prompt design vocabulary; chapters 7 through 9 extend that vocabulary; chapters 10 and 11 apply it to security and management.

Summary

  • Prompt engineering is deliberate interface design. It is the practice of composing, evaluating, and refining prompts to produce reliable outputs, not casual trial and error or model-level modification.
  • Prompts in software systems are engineering artifacts. They should be specified, reviewed, tested, versioned, and maintained with the same care as requirements, APIs, and other shared system components.
  • Well-designed prompts make the task explicit. They connect instructions, required context, constraints, input boundaries, and the expected output shape so the model has less room to vary in unhelpful ways.
  • The prompt engineering lifecycle makes prompt work repeatable. Design produces a prompt draft, testing produces evidence, iteration fixes observed failures, and management preserves ownership and change history.
  • Prompt failures are diagnosable. The three diagnostic lenses introduced in this chapter become the foundation for the rest of the book.

FAQ

What is prompt engineering, and how is it different from casual prompting?Prompt engineering is the deliberate composing, evaluating, and refining of prompts to produce reliable, predictable model outputs. Casual prompting is ad hoc, undocumented, and based on trial and error, while prompt engineering treats prompts as designed artifacts with structure and criteria.
Why does the book say prompts should be treated like engineered artifacts?Because prompts can be specified, reviewed, tested, versioned, and maintained like other shared system components. Treating them this way reduces ambiguity, makes failures diagnosable, and helps teams avoid prompt debt.
What are the main parts of a prompt in the chapter’s mental model?The chapter describes prompts as having instructions, context, constraints, inputs, and expected output. Instructions define the task, context supplies missing background, constraints limit unwanted outputs, inputs provide the material to work on, and expected output defines what success looks like.
What is the lifecycle of prompt engineering?The lifecycle has four phases: design, test, iterate, and manage. Design creates the prompt, test evaluates it, iterate fixes failures based on evidence, and manage version-controls and maintains the prompt over time.
Why is prompt engineering important for software engineers?Because prompts used in products, workflows, and internal tools affect reliability just like code or API contracts. If prompts are vague or untested, they can create inconsistent outputs, production defects, and maintenance problems.
How does the chapter distinguish a prompt from a message?A message mainly communicates, while a prompt instructs, constrains, contextualizes, and specifies. If you think of a prompt as a message, you write casually; if you think of it as an artifact, you engineer it deliberately.
What makes a prompt “self-contained”?A self-contained prompt includes everything the model needs to do the task correctly in the prompt itself or in the supplied context. Assumptions that are obvious to humans, such as team conventions or internal taxonomies, must be stated explicitly for the model.
How does the chapter explain inconsistent model output?Inconsistent output is usually treated as a diagnostic signal pointing to an underspecified prompt. The first step is to inspect the prompt for ambiguity, missing context, or too much interpretive freedom before blaming the model.
What are the three diagnostic lenses introduced in the chapter?The three lenses are: prompts as specifications, prompts as self-contained, and inspecting the prompt first when output varies. Together, they help you identify missing constraints, missing context, and sources of variability.
What is the central lesson of the chapter’s examples, such as the pull request and incident summary prompts?The central lesson is that output quality often changes because the prompt was redesigned, not because the model changed. Clear instructions, explicit boundaries, and defined response shapes make prompts more reliable, reviewable, and reusable.

pro $24.99 per month

  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • choose one free eBook per month to keep
  • exclusive 50% discount on all purchases
  • renews monthly, pause or cancel renewal anytime

lite $19.99 per month

  • access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more


choose your plan

team

monthly
annual
$49.99
$499.99
only $41.67 per month
  • five seats for your team
  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • choose another free product every time you renew
  • choose twelve free products per year
  • exclusive 50% discount on all purchases
  • renews monthly, pause or cancel renewal anytime
  • renews annually, pause or cancel renewal anytime
  • Prompt Engineering in Practice ebook for free
choose your plan

team

monthly
annual
$49.99
$499.99
only $41.67 per month
  • five seats for your team
  • access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
  • choose another free product every time you renew
  • choose twelve free products per year
  • exclusive 50% discount on all purchases
  • renews monthly, pause or cancel renewal anytime
  • renews annually, pause or cancel renewal anytime
  • Prompt Engineering in Practice ebook for free