title: "Exercises — Prompting for Agents" last_updated: 2026-03-21 status: proven difficulty: beginner prerequisites: [02-project-memory]

Exercises — Prompting for Agents

These exercises build practical prompting skills through hands-on experimentation. Each one is designed to reveal something specific about how agents interpret and respond to different kinds of instructions.

You will need a project to work with. If you do not have one available, create a small Express or Fastify API with a few endpoints, or use any existing project you are comfortable experimenting with.

Exercise 1: The Decomposition Challenge

Objective

Learn to break complex tasks into well-scoped agent subtasks and develop an intuition for the right task size.

Steps

  1. Start with this complex task: "Add user authentication to this app." (If your project already has auth, substitute another large feature: "Add a notification system," "Add role-based access control," or "Add full-text search.")

  2. Decompose the task into 5-7 subtasks. For each subtask, write a single-sentence prompt that you would give to a coding agent. Aim for prompts that are self-contained — each one should make sense on its own, even though they form a sequence.

  3. Review your list. For each subtask, evaluate:

    • Is it too big? Could the agent drift from your intent before you get to review? Does it require too many sequential decisions? A task is too big if you cannot review the full output in under five minutes.
    • Is it too small? Would it be faster to just do it yourself? Does the overhead of prompting and reviewing exceed the work itself? A task is too small if it takes longer to describe than to do.
    • Is it well-scoped? Does it have a clear, verifiable outcome? Could you tell whether the agent succeeded just by looking at the result?

  4. Rewrite any subtasks that are too big or too small. Aim for the sweet spot described in the concepts module.

  5. (Optional) Actually run your prompts sequentially. After each one, review the result before sending the next. Note where you needed to give corrections and whether those corrections suggest the task was mis-scoped.

Expected Outcome

You should have a list of 5-7 subtasks, each with a clean one-sentence prompt and a clear deliverable. At least one of your original subtasks should have been too big (requiring further decomposition) and at least one should have been too small (better merged with another subtask or done manually).

Hints

  • A good subtask often maps to a single file, module, or concept. "Create the user model and migration" is a natural unit. "Create the user model, migration, and all API endpoints" is probably too large.
  • Think about dependency order. Some subtasks must complete before others can start. Your sequence should reflect this.
  • If a subtask prompt requires more than two sentences to be clear, the task may be too big.

Exercise 2: Vague vs. Precise

Objective

Develop a feel for the intent-vs-instruction spectrum by writing three versions of the same prompt and observing how the agent responds to each.

Steps

  1. Choose a concrete task in your project. Good candidates:

    • Improving error handling in a specific file
    • Adding input validation to a form or API endpoint
    • Refactoring a function that is too long or complex
    • Adding tests to an untested module

  2. Write three prompts for this task:

    Prompt A — Too Vague: Write a prompt that is genuinely too vague. Omit the file name, omit specifics about what "better" means, and use hand-wavy language. Example: "Make the error handling better."

    Prompt B — Too Prescriptive: Write a prompt that dictates exact implementation details. Specify line numbers, variable names, exact code to write. Leave the agent no room to use its own judgment. Example: "On line 23 of src/api/users.ts, wrap the existing code in a try-catch. In the catch block, create a variable called errMsg set to error.message, then call res.status(500).json({ error: errMsg })."

    Prompt C — Balanced: Write a prompt that specifies intent, points to the relevant file, states the desired outcome, and includes any constraints — but lets the agent choose the implementation. Example: "The error handling in src/api/users.ts returns generic 500 errors for all failures. Refactor it to return appropriate HTTP status codes (400 for validation errors, 404 for not found, 500 for unexpected errors) with descriptive error messages. Keep the response format consistent with the other API endpoints."

  3. Run all three prompts in separate sessions (use /clear or start new sessions between them). Do not modify or guide the agent after the initial prompt — let each prompt stand on its own.

  4. Compare the three results:

    • Which prompt produced the best code?
    • Which one required the least follow-up to be production-ready?
    • Where did the vague prompt go wrong? Was the result bad, or just not what you wanted?
    • Where did the prescriptive prompt go wrong? Did the agent follow your instructions even when they were suboptimal?

  5. Document your findings. Write a paragraph about what made the balanced prompt work better than the other two.

Expected Outcome

The vague prompt should produce something that technically works but misses your actual intent — it will "improve" something, but not necessarily the dimension you cared about. The prescriptive prompt should produce exactly what you described, which may be worse than what the agent would have chosen on its own. The balanced prompt should produce the best result because it combines your domain knowledge (what needs to change and why) with the agent's implementation skill (how to change it).

Hints

  • For the vague prompt, resist the urge to be helpful. The goal is to see what happens when the agent lacks guidance.
  • For the prescriptive prompt, try to dictate code from memory without looking at the file. Notice how the agent handles instructions that do not quite match the actual code.
  • The balanced prompt should be shorter than the prescriptive one. If it is longer, you are probably over-specifying.

Exercise 3: The Correction Loop

Objective

Practice giving effective iterative feedback and experience how corrections compound within a session.

Steps

  1. Choose a moderately complex task. Good candidates:

    • "Add a search feature to the users API endpoint with filtering by name and email"
    • "Create a logging middleware that logs request method, path, status code, and response time"
    • "Add pagination to the list endpoint with page and limit query parameters"

  2. Send your initial prompt. Use the balanced prompting style from Exercise 2 — clear intent, specific file references, stated outcome. Do NOT try to anticipate every edge case.

  3. Review the first result. Find something that is not quite right. It might be:

    • A missing edge case
    • A suboptimal implementation choice
    • A style inconsistency with the rest of the codebase
    • Missing error handling
    • Missing tests

  4. Round 1 correction: Give specific feedback. Use this format: "This is close, but [specific observation]. [Specific change you want]."

    Example: "This is close, but the search is case-sensitive. Make the name and email filters case-insensitive using a lower-case comparison."

  5. Review the updated result. Find another issue.

  6. Round 2 correction: Build on the previous context. You do not need to re-explain the task.

    Example: "Good. Now the search query parameter should also support partial matches — if I search for 'john', it should match 'Johnson' and 'johnny'."

  7. Review again and do one more round.

  8. Round 3 correction: This round should address a more nuanced concern — something the agent could not have known from the original prompt.

    Example: "The search works well. One more thing: add a maximum limit of 100 results per page to prevent clients from requesting the entire dataset. Return a 400 error if the client requests more than 100."

  9. After three rounds, review the final result. Compare it to what the initial prompt produced.

Expected Outcome

The final result after three rounds of feedback should be substantially better than the initial result. Each correction should have been short (one to two sentences) and specific. The agent should have preserved its previous good work while incorporating each correction. By round three, the agent should have a rich understanding of your preferences and intent that no single prompt could have conveyed.

Hints

  • Resist the urge to list all corrections at once. The point of this exercise is to practice the iterative loop, where each round builds on the last.
  • If the agent does not preserve previous corrections when applying new ones, be explicit: "Keep the case-insensitive matching from the previous change."
  • Notice how your corrections get more nuanced with each round. The first round catches obvious issues. The third round catches subtleties. This is the natural rhythm of the feedback loop.
  • If the agent nails it on the first try, choose a harder task. The exercise works best when the initial result is good but imperfect.

Exercise 4: Plan Mode Practice

Objective

Experience the difference between planned and unplanned execution, and learn when planning ahead improves outcomes.

Steps

  1. Choose a complex task that touches multiple files. Good candidates:

    • "Add request validation using a schema library (like Zod or Joi) to all API endpoints"
    • "Refactor the data access layer to use the repository pattern"
    • "Add comprehensive error handling with custom error classes and a centralized error handler"

  2. Phase A — Plan first. Use plan mode (in Claude Code) or suggest mode (in Codex CLI).

    Claude Code: Toggle to plan mode with Shift+Tab, or include "plan" in your prompt:

    Plan how to add request validation using Zod to all the API endpoints in src/api/. Don't make changes yet.

    Codex CLI: Use suggest mode so the agent proposes without executing:

    Suggest how to add request validation using Zod to all the API endpoints in src/api/.

  3. Review the plan. Look for:

    • Does the agent's approach make sense?
    • Is the order of operations logical?
    • Are there steps you disagree with?
    • Did the agent miss something important?

  4. Modify the plan if needed:

    Good plan, but two changes: (1) Start with the users endpoint as a prototype before doing the others.
(2) Put the Zod schemas in a separate schemas/ directory, not inline in the route files.

  5. Execute the (modified) plan:

    Go ahead and implement this plan.

  6. Review the result from Phase A. Note the quality and how well it matched your expectations.

  7. Phase B — Direct execution. Start a fresh session (/clear or new terminal). Give the same task as a direct prompt without plan mode:

    Add request validation using Zod to all the API endpoints in src/api/. Put Zod schemas in a separate schemas/ directory.

  8. Compare the results from Phase A and Phase B:

    • Which produced better code?
    • Which was faster end-to-end (including the time you spent reviewing the plan)?
    • Did the plan catch anything that direct execution got wrong?
    • Did direct execution produce anything surprising — good or bad?

Expected Outcome

For a complex, multi-file task, the planned approach should produce a more coherent result because you had a chance to shape the strategy before execution. The direct approach might be faster for simple tasks but could produce inconsistencies across files for complex ones — for example, using slightly different patterns in different files because the agent made ad-hoc decisions at each step.

You should come away with a feel for the complexity threshold where planning pays off. Simple tasks (one file, clear outcome) do not need a plan. Complex tasks (multiple files, architectural decisions, new patterns) benefit from one.

Hints

  • If using Codex CLI in suggest mode, remember that you need to approve or direct the agent to actually make changes after reviewing the suggestions.
  • When modifying the plan, be specific about what to change. "Make it better" is as unhelpful in plan feedback as it is in task prompts.
  • Phase B should use the same constraints you added during plan review (like the schemas/ directory). The comparison should be between planned vs. unplanned execution, not between different requirements.
  • If both approaches produce identical results, your task might not be complex enough. Try something that requires more cross-file coordination.
  • Time both approaches. The overhead of planning is worth it only when it prevents rework. For a five-minute task, spending three minutes planning is not efficient. For a thirty-minute task, a five-minute plan that prevents a fifteen-minute redo is very efficient.

What to Take Away

After completing these exercises, you should have practical experience with:

  • Decomposition: Breaking large tasks into well-scoped subtasks with clear deliverables
  • Prompt calibration: Finding the sweet spot between too vague and too prescriptive
  • Iterative feedback: Using targeted corrections to refine results across multiple turns
  • Strategic planning: Knowing when to plan ahead and when to execute directly

These are not abstract skills — they are the daily mechanics of working effectively with coding agents. The more you practice them, the more intuitive they become.