learnlesson90 minbeginner

Prompt Engineering & Critical Thinking

claude-codev1.0.32cursorv0.48

Module 2: Prompt Engineering & Critical Thinking

Tier 1: Foundations | Estimated time: 4–6 hours | Prerequisites: Module 1

What You'll Get Out of This

This is the most important module in the course. Everything you build from here forward — tools, data products, automations, presentations — will be better or worse depending on the skills you develop in this module.

You'll learn two things: how to make AI output dramatically better through better inputs, and how to critically evaluate what AI gives you instead of blindly accepting it.

The central principle: AI produces average output. Your inputs and judgment make it exceptional. This isn't a platitude. It's a measurable, observable phenomenon, and this module teaches you to see it and act on it.

Part 1: Why the First Output Is Never the Final Output

In Module 1, you probably noticed that the AI's first response to your prompt was... fine. It worked (mostly). But it wasn't great. Maybe the design was generic, the logic had bugs, or the features didn't quite match what you had in your head.

That's not a failure of the tool. That's the tool doing exactly what it was designed to do: produce a competent, middle-of-the-road interpretation of your description.

Think of it this way: if you asked 100 software engineers to build a "daily habit tracker," you'd get 100 different implementations. Some would be brilliant. Some would be terrible. Most would be competent but unremarkable. AI gives you something close to the average of those 100 implementations.

Your job is not to accept the average. Your job is to push it toward exceptional through two mechanisms:

  1. Better inputs — describing what you want with enough precision and context that the AI's "average" is already close to what you need
  2. Critical evaluation — recognizing what's wrong, weak, or missing in the output and directing the AI to fix it

Both are learnable skills. Let's start with inputs.

Part 2: The Anatomy of a Good Prompt

A prompt is not a wish. It's a set of instructions. The more complete your instructions, the closer the output is to what you want on the first try.

The Five Elements

Every effective prompt has some combination of these five elements. Not every prompt needs all five, but knowing they exist lets you add precision where it matters.

1. Context — What the AI needs to know

Context is the background information that shapes how the AI interprets your request. Without it, the AI guesses — and it guesses toward the average.

Bad:  Build me a dashboard.
Good: Build me a dashboard for a product team that tracks feature 
      requests from stakeholders. The team uses weekly planning 
      meetings to prioritize, so the dashboard needs to support 
      sorting and filtering by priority, submitter, and status.

The difference: the "good" version tells the AI who uses this, how they use it, and what decisions it supports. The AI can now make informed choices about layout, fields, and functionality.

2. Constraints — What the AI should NOT do

Constraints are often more powerful than instructions. Telling AI what to avoid prevents the most common ways it goes wrong.

Without constraints: Build a landing page for a productivity app.
With constraints:    Build a landing page for a productivity app.
                     Do NOT use any stock photo placeholder images.
                     Do NOT add a pricing section.
                     Do NOT use more than 3 colors.
                     Keep it to a single scrollable page — no navigation menu.

The constrained version eliminates the generic elements that make AI output look like every other AI output.

3. Examples — What "good" looks like

If you can show the AI what you want, it performs dramatically better than if you only describe it.

Without examples: Make the table sortable.
With examples:    Make the table sortable. When the user clicks a column 
                  header, it should sort ascending. Clicking again sorts 
                  descending. Clicking a third time removes the sort. 
                  Show a small arrow icon (↑ or ↓) next to the sorted 
                  column header. The default sort should be by date, 
                  newest first.

You're not writing code — you're describing the specific behavior you've seen in tools you like.

4. Definition of Done — What "finished" looks like

Tell the AI when you'll consider this complete. This prevents scope creep in the output and keeps things focused.

Without: Build a meeting notes tool.
With:    Build a meeting notes tool. It's done when I can:
         1. Type notes in a text area with markdown support
         2. Add action items with an assignee and due date
         3. Export the notes as formatted markdown
         4. Save and load notes from browser local storage
         That's it. Nothing else.

"That's it. Nothing else." is one of the most powerful phrases in prompt engineering. It stops the AI from adding features you didn't ask for.

5. Format — How the output should be structured

When you care about the structure of the output (not just what it does), say so.

Without: Build this as a web app.
With:    Build this as a single HTML file with inline CSS and JavaScript.
         No external dependencies. No build step. I should be able to 
         open the file in a browser and it works.

Putting It Together

Here's a full prompt using all five elements:

Context: I lead a team of 8 product people. Each week, stakeholders 
from across the organization submit feature requests via email and Slack. 
I need a central place to track and triage these requests.

Build a Feature Request Tracker as a single-page web application.

Requirements:
- A form to add new requests: title, description, submitter name, 
  priority (P0/P1/P2/P3), status (New/In Review/Approved/Declined)
- A filterable table showing all requests, sortable by any column
- Click a row to expand and see the full description
- Status can be changed via a dropdown directly in the table
- Request count badges at the top showing how many are in each status

Constraints:
- Single HTML file, inline CSS and JavaScript, no external dependencies
- Do NOT add authentication, user accounts, or multi-user features
- Do NOT add a kanban board view — just the table
- Use local storage for data persistence

Definition of done: I can add requests, filter and sort the table, 
change statuses, and the data survives a page refresh. That's it.

Design: Clean, professional, minimal. White background. Use a blue 
accent color (#2563EB). No decorative elements.

Compare this to "build me a feature tracker." Same idea. Wildly different output quality.

Part 3: Prompt Patterns

Beyond the five elements, there are specific patterns that consistently improve output. These aren't tricks — they're thinking tools that help you communicate more precisely.

Pattern 1: Role Assignment

Tell the AI who it is before telling it what to do. This shapes the lens through which it interprets your request.

You are a senior frontend developer who specializes in building 
clean, minimal internal tools. You care deeply about usability 
and you hate unnecessary features.

Build me a...

The role doesn't have to be "developer." For research tasks: "You are a market analyst who specializes in data platform companies." For writing: "You are a technical writer who explains complex topics to non-engineers."

Pattern 2: Step-by-Step Decomposition

For complex tasks, break them into sequential steps rather than one big ask.

Instead of: "Build me a complete project management tool"

Try:

Step 1: Build the data model first. I need to track projects, tasks, 
and team members. Show me the structure before writing any UI code.

Step 2: [After reviewing the data model] Good, but add a "dependencies" 
field to tasks. Now build the task list view — just the table, no 
other pages yet.

Step 3: [After reviewing the table] Now add the ability to create a 
new task from this view. Inline form, not a separate page.

Building in steps gives you review points. You can catch mistakes early instead of debugging a complex, fully-built application.

Pattern 3: Example-Driven Prompting

When you have a mental image of what you want, describe the closest existing thing.

Build a status page similar to status.github.com — a list of services, 
each with a green/yellow/red indicator, a brief status message, and 
an expandable section showing the last 7 days of uptime history 
as small colored bars.

You're not asking the AI to copy GitHub's status page. You're giving it a concrete reference point that's worth a thousand words of description.

Pattern 4: The "Improve This" Pattern

When you have working code that isn't good enough, tell the AI what's wrong rather than re-describing the whole thing.

This works, but three things bother me:
1. The table feels cramped — add more padding and increase row height
2. The filter dropdown resets when I change the sort order — it should 
   remember the active filter
3. The empty state just shows a blank table — add a message like 
   "No requests yet. Add one above."

Specific criticism produces better results than "make it better."

Pattern 5: Plan Before Build

Ask the AI to outline its approach before writing code. This lets you catch wrong assumptions before they become wrong implementations.

Before writing any code, outline your approach:
- What files will you create?
- What's the component structure?
- What data model will you use?
- What libraries (if any) do you plan to import?

Show me the plan first. I'll approve it before you start building.

Both Cursor and Claude Code support this — ask your AI tool to plan before building. In Cursor, you can use "Plan Mode." In Claude Code, just say "plan this before writing any code."

Part 4: Critical Evaluation — Reading Output Like a Product Leader

Knowing how to prompt well is half the skill. The other half is evaluating what comes back. This is where your product judgment — the skill you already have — meets a new medium.

The Evaluation Framework

After every AI output, run through these five questions:

1. Does it work? Open it. Click everything. Enter data. Refresh. Does the basic functionality operate as described? This is the minimum bar.

2. Does it solve the real problem? Working isn't the same as useful. A perfectly functional habit tracker that requires 6 clicks to log one habit doesn't solve the problem of "I want to quickly track habits." Step back and ask: would I actually use this? Would my target user?

3. Is it correct? This matters most for data, logic, and calculations. If the tool is computing averages, sorting data, or displaying statistics — are the numbers right? AI is notorious for writing confident code that produces subtly wrong results.

How to check: Use simple, manually-verifiable test cases. If the tool says your average is 42.3, can you calculate that by hand from the input data? If it can't handle the simple case correctly, it won't handle the complex case.

4. Is it complete? Did it implement everything you asked for? AI often drops requirements, especially from longer prompts. Cross-reference your prompt against the output — are any features missing? Are edge cases handled?

5. Would I put my name on this? This is the gut check. If you showed this to your VP, your stakeholders, or your engineering team — would it represent you well? If the answer is "it's fine but not great," that's a signal to iterate.

Common Patterns of AI Failure

Learn to recognize these — they happen constantly:

Confident wrongness. The code runs, the UI looks polished, but the underlying logic is incorrect. A chart that aggregates data wrong. A filter that silently excludes records. A calculation that seems right on small datasets but breaks at scale.

The 80% implementation. AI nails the main flow but ignores edge cases. What happens with empty data? With one record? With a thousand? With special characters in a text field? With a very long title? Test the boundaries, not just the happy path.

Hallucinated features. Sometimes AI adds things you didn't ask for — extra buttons, navigation elements, settings panels. If you didn't ask for it, question whether it belongs. Unnecessary features add complexity and potential bugs.

Generic design. AI defaults to a look that screams "AI-generated": rounded cards with shadows, blue gradient buttons, lots of whitespace, generic placeholder text. It's technically fine but lacks personality or intentionality. Module 11 addresses this in depth.

Copy-paste architecture. For larger projects, AI sometimes produces code that works but is poorly organized — duplicated logic, inconsistent naming, no clear structure. It works today but would be nightmare to modify tomorrow. Module 6 (Blueprints) helps prevent this.

Part 5: When NOT to Use AI

This might be the most counterintuitive section in the course. You're here to learn to build with AI — but part of building well is knowing when to put the AI down.

Tasks Where AI Hurts More Than It Helps

High-stakes decisions with insufficient context. AI doesn't know your organization's politics, your stakeholders' unspoken preferences, or the history behind a contentious decision. Using AI to draft a strategy recommendation without giving it this context produces something that sounds smart but misses the point.

Work that requires trust and authenticity. If your VP asks for your take on a problem, and you hand back an AI-generated response, you've undermined the trust they placed in you. Some work needs your voice, your thinking, your judgment — unmediated by a tool.

Tasks where errors are invisible and catastrophic. If a data calculation is wrong in a prototype, that's fine — you'll catch it. If a data calculation is wrong in a report that goes to the board, that's career-damaging. The higher the stakes of an error, the less you should rely on AI's first output and the more verification you need.

Original strategic thinking. AI is excellent at synthesizing existing ideas and mediocre at generating truly novel ones. If your job is to see something nobody else sees — a market opportunity, a product insight, a strategic pivot — AI can help you organize your thinking but shouldn't replace it.

The Litmus Test

Before using AI for any task, ask: "If the output is subtly wrong and I don't catch it, what happens?"

If the answer is "nothing much — I'll iterate," use AI. If the answer is "I'll look stupid" or "we'll make a bad decision," use AI cautiously with rigorous verification. If the answer is "someone could be harmed," don't use AI — or use it only as one input among many human-verified sources.

Part 6: Building on Top of AI Output

The most valuable skill in AI-assisted building isn't prompting — it's what you do after the first output. The best builders treat AI output as raw material, not a finished product.

The Reshape Workflow

  1. Generate — Prompt the AI for a first draft
  2. Evaluate — Run through the five-question framework
  3. Identify gaps — What's missing? What's wrong? What's generic?
  4. Reshape — Don't just fix bugs. Restructure. Remove unnecessary elements. Add the specific details only you know. Make it yours.
  5. Verify — Test the reshaped version. Did your changes break anything?

Reshaping vs. Accepting

Here's the difference between someone who accepts AI output and someone who reshapes it:

Accepts: AI generates a stakeholder request tracker. It works. They ship it.

Reshapes: AI generates a stakeholder request tracker. They notice the priority levels are P1-P5 but their organization uses High/Medium/Low. They notice there's no "submitted by" field (which matters for follow-up). They notice the table defaults to alphabetical sort (useless — it should sort by priority, then date). They notice the empty state says "No data" (it should say "No open requests — nice work"). They fix all of these. Now it's their tool, not AI's tool.

The reshaped version took 15 extra minutes. It's the one people actually use.

Lab: The Three-Prompt Experiment

This is the core exercise for this module. You'll see the "AI is average" principle in action.

Setup

You're going to build the same thing three times with three different prompts. Same idea. Different levels of input quality.

The idea: A meeting action item tracker — a tool where you paste meeting notes and it extracts action items with owners and due dates.

Prompt A: Vague

Open a new AI conversation and use this prompt exactly:

In Cursor: Start a new Agent session (Cmd+I / Ctrl+I). In Claude Code: Start a fresh session with claude in your terminal.

Build me a meeting action item tracker.

That's it. Accept whatever the AI produces. Take a screenshot. Save the file as version-a.html.

Prompt B: Moderate

New AI conversation:

Build a meeting action item tracker as a single HTML file. 
It should have a text area where I paste meeting notes, a button to 
extract action items, and a table showing the results.
Each action item should have: task description, owner, due date, and status.
Use a clean design with a white background.

Accept the output. Screenshot. Save as version-b.html.

Prompt C: Precise

New AI conversation:

Context: I'm a product manager who runs 4-5 meetings per week. After each 
meeting, I spend 15 minutes manually extracting action items from my notes. 
I want to paste my raw notes into a tool and get structured action items back.

Build a Meeting Action Item Tracker as a single HTML file with inline 
CSS and JavaScript.

Layout (top to bottom):
1. Header: "Action Item Tracker" in a simple sans-serif font
2. Input section: A large text area (at least 8 rows) with placeholder 
   text showing an example of meeting notes with action items embedded
3. An "Extract Action Items" button (blue, prominent)
4. Results section: A table with columns: Action Item, Owner, Due Date, 
   Priority (High/Medium/Low), Status (Open/Complete)

Behavior:
- Parsing should look for patterns like "[Name] will [task] by [date]" 
  or "Action: [task] - [Name]" or "TODO: [task]"
- If parsing can't identify an owner, default to "Unassigned"
- If parsing can't identify a date, default to "No date set"
- Each row should have an inline status dropdown to mark items complete
- Completed items should have a strikethrough on the task text
- Include a count badge: "3 open / 2 complete"

Constraints:
- No external dependencies
- No AI/LLM API calls — parsing should use pattern matching, not AI
- Do NOT add a save/load feature
- Do NOT add tabs or multiple pages

Design:
- White background, dark gray text (#1F2937)
- Blue accent (#2563EB) for buttons and links
- Table rows should have alternating subtle gray backgrounds
- Generous padding — nothing should feel cramped

Done when: I can paste meeting notes, click extract, see a table of 
action items, and change their status. That's it.

Accept the output. Screenshot. Save as version-c.html.

Compare

Open all three in your browser side by side. Answer these questions (write them down):

  1. Which looks most professional? Why?
  2. Which handles your actual workflow best? What specific features make the difference?
  3. Which has the most bugs or missing features? What's missing?
  4. How much of the difference is attributable to the prompt vs. the AI? If you gave Prompt C to a different AI tool, would it still produce better output than Prompt A?
  5. What would you change about even Version C? What did the AI get wrong or miss despite the detailed prompt?

The Point

The difference between Version A and Version C isn't about AI capability. The AI is the same. The difference is entirely in your input quality. This is what "AI is average, you make it exceptional" means in practice.

Lab: The Reflection Exercise

Write a 1-page reflection (in a markdown file, a doc, or just a text file — whatever you prefer) addressing:

  1. One time AI output looked right but was wrong. This could be from Module 1, from the three-prompt experiment, or from your prior experience with any AI tool. What happened? How did you catch it? How would you catch it earlier next time?

  2. Your current default prompting style. Are you naturally vague or precise? Do you tend to over-specify or under-specify? What's your biggest gap based on this module?

  3. One task from your actual work where you think AI would help and one where you think it would hurt. Why?

This reflection isn't graded. It's for you — to articulate your own thinking about when and how to use these tools. The people who do this exercise well build better things for the rest of the course.

Go Deeper

Try these prompts in your AI tool to sharpen your prompt engineering:

  • "I'm going to give you a vague prompt. Before building anything, tell me what assumptions you'd make and what clarifying questions you'd ask."
  • "Here's my prompt: [paste it]. Rewrite it to be more specific. Explain what you changed and why each change improves the output."
  • "Build this, then critique your own output. What did you get right? What's mediocre? What's wrong?"

If You Get Stuck

All three versions look the same: Your prompts might not be different enough. Make the gap more dramatic — Version A should be truly vague (5 words), Version C should be exhaustively detailed (20+ lines with constraints, examples, and a definition of done).

Can't tell which version is "better": Show all three to someone who wasn't involved. Ask them: "Which one would you actually use?" Outside perspective cuts through your bias.

AI keeps ignoring your constraints: Put constraints at the end of your prompt, not buried in the middle. Use explicit "Do NOT" language. If it still ignores them, try a fresh conversation.

Checkpoint

You've completed Module 2 when:

  • You built the same application three times with three different prompt quality levels
  • You can identify the five elements of a good prompt (context, constraints, examples, definition of done, format)
  • You saved all three versions and documented the differences
  • You can articulate the critical evaluation framework (works? solves the problem? correct? complete? would you put your name on it?)
  • You've written the 1-page reflection
  • You can name at least 2 situations where you should NOT use AI

What's Next

You can build things and you can prompt well. But when something breaks, you're still flying blind — you can't look at the code and understand why. Module 3 fixes that: How Code Actually Works — enough code literacy to read, evaluate, and debug what Cursor generates.

Previous: ← Module 1: Setup & First Build Next: Module 3: How Code Actually Works →