Skip to main content
In this lesson we introduce prompt engineering with a short, practical demonstration you can reproduce in the Amazon Bedrock Playground. The goal is to move from ad-hoc, inconsistent prompts to a repeatable, measurable process that yields reliable, application-ready outputs. What you’ll learn
  • The common pain point: developers wasting time on random prompts and inconsistent results.
  • What prompt engineering is and the core techniques to apply.
  • A hands-on demonstration in the Bedrock Playground showing iterative prompt improvements.
  • The expected improvements and a concise summary to apply in your projects.
Jump in — we start with the problem.

​
The problem: unstructured experimentation wastes time

Many teams iterate by randomly rewording prompts until something “sounds right.” Without a method to compare changes, it’s hard to know which tweak actually improved the result. Vague prompts produce vague results, and small wording changes can dramatically affect the output. Applying a structured, iterative approach reduces wasted cycles and produces consistent outputs suitable for downstream systems.

​
What is prompt engineering?

Prompt engineering is the process of designing, testing, and refining prompts to get predictable, useful model outputs. It’s an iterative, measured approach:
  1. Create a baseline prompt.
  2. Observe outputs and identify gaps.
  3. Modify the prompt to address those gaps.
  4. Test again and repeat.
Foundation models (for example, those available through Amazon Bedrock) often follow instructions quite literally, so clarity — audience, role, constraints, and output format — matters. Example:
  • Weak: “Explain AWS security.”
  • Engineered: “Explain AWS security to a non‑technical executive in five bullet points.”
The engineered prompt adds audience, context, and output constraints, making the response more predictable and actionable.

​
Common prompt engineering techniques

Each technique can be used alone or combined to increase consistency and control.
An infographic titled "Workflow: Common Prompt Engineering Techniques" showing a two-column table of prompt methods (few-shot, step-by-step, role prompting, chain-of-thought, output format specification) with brief explanations of how each works. The table matches each technique to its purpose, e.g., "few-shot prompting — provide examples" and "chain-of-thought — encourage structured reasoning."
Remember: prompt engineering is iterative. Start simple, evaluate, and add constraints that solve observed weaknesses.
A dark infographic titled "Workflow: Prompt Engineering Is Iterative" showing a circular flow of colorful icons and arrows. The steps read: "Start simple," "Observe output," "Adjust prompt," "Test again," and "Improve gradually."
The iterative flow produces continuous, stepwise improvement in quality.

​
Demonstration: classify IT support tickets in the Bedrock Playground

We’ll apply the techniques above in the Amazon Bedrock Playground. The use case: classify support tickets into categories and priorities, and return a short, standardized description. Setup
  • Open the Amazon Bedrock console and go to the Playgrounds.
  • Choose a model (for example, a Titan-family model available in Bedrock).
  • Switch the Playground to single-prompt mode to evaluate prompts in isolation (no multi-turn state).
Use case specifics
  • Categories: billing, login, performance, security, general
  • Priorities: low, medium, high, critical
  • Output: strict JSON matching your API schema so downstream services can parse it directly
Walkthrough — progressively constrain and improve the prompt:
  1. Naive starting prompt This is a minimal prompt many developers try first. It’s ambiguous and unconstrained.
Problems with this prompt:
  • No role or audience.
  • No constrained label set for categories or priorities.
  • No machine-readable output format.
  1. Add role/context Adding a role primes the model for a practical, operational response.
Improvement: output will be more operational in tone, but field names and values still vary.
  1. Constrain allowed labels (reduce freedom) Specify the exact categories and priorities so the model must choose from them.
With those constraints, the model is more likely to pick consistent labels. Example model response (structured but not yet strictly machine-only):
  1. Constrain output format to strict JSON schema If your system ingests the model output directly, require a precise JSON schema and instruct the model to respond only with that JSON and nothing else.
Final prompt example:
Expected strict JSON output:
That output is predictable and directly usable by downstream APIs or workflows.

​
Practical tips and callouts

Start simple and iterate. Use role prompting, constrained label sets, and an explicit output format (for example, a JSON schema) to move from ambiguous, free-form results to consistent, machine-ready responses.
Additional recommendations
  • Few-shot prompting: Include 1–3 annotated examples when you have representative tickets and desired outputs. This improves generalization.
  • Chain-of-thought / step-by-step: Use when you need intermediate reasoning (e.g., triage logic), but avoid combining verbose chains-of-thought with strict machine-only outputs.
  • Test consistently: Try prompts in the same Playground mode (single-prompt vs. multi-turn) to avoid behavior differences.
  • Measure incremental changes: Add one constraint at a time and evaluate — this reveals which change caused the improvement.

​
Summary and next steps

  • Prompt engineering is an iterative, structured discipline that reduces ambiguity and produces reliable outputs.
  • Key techniques: role prompting, few-shot examples, step-by-step instructions, chain-of-thought (when needed), and strict output format specification.
  • In practice: begin with a simple prompt, observe the output, then incrementally add role context, label constraints, and an exact output format (JSON) to obtain application-ready results.
Further reading and references
  • Amazon Bedrock Playground
  • Kubernetes Basics (for deploying systems that might consume model outputs)
  • Consider logging prompt variants and results to measure improvements over time (A/B-style testing for prompts).
Future lessons will build on these foundations with more complex examples, evaluation metrics, and automated prompt testing strategies.

Watch Video