4.3 Supporting Solution Design Through Iteration
4.3.1 Prefer the Simplest Approach That Solves the Problem
Anthropic's *Building Effective AI Agents* guidance carries a lesson that applies well beyond developers: **prefer the simplest approach that solves the problem.** Many business tasks are handled well by a single well-structured prompt, or a short chain of a few prompts — an elaborate multi-step "system" is frequently unnecessary, even when it sounds more impressive to propose.
Simplicity wins because added complexity adds failure points. Every extra step, handoff, or piece of tooling in a solution is another place something can go wrong, another thing to maintain, and another thing to explain to a stakeholder who just wants the client update to go out on time. If a single prompt or a Project already solves the problem reliably, a more elaborate design is a cost with no offsetting benefit.
4.3.1 — Key Concept
Prefer the simplest approach that solves the problem — a single well-structured prompt or short chain, not an elaborate system, by default. Escalate only when the simple version demonstrably falls short.
4.3.2 When to Escalate Beyond a Single Prompt
"Prefer simplicity" doesn't mean "never escalate" — it means escalation is earned, not assumed. Before designing anything elaborate, ask whether a well-structured prompt, or a short sequence of prompts, already solves this. If the answer is genuinely no — the simple version demonstrably falls short on some real requirement — that's the point at which a more complex structure becomes justified, not before.
- •Default assumption: a single well-structured prompt or short chain solves most business tasks.
- •Escalate only when that default demonstrably fails against a real requirement, not because a more sophisticated design "sounds" better.
- •Every added step or handoff is a new failure point and a new maintenance burden — weigh it against the actual benefit gained.
4.3.2 — Exam Trap
Common exam trap: assuming "more sophisticated" (multi-step, multi-tool) is automatically "better." The correct default is the simplest structure that solves the problem, escalating only when needed — this is explicitly called out as over-engineering when it isn't.
4.3.3 The Iterative Loop: Propose, Review, Refine, Re-check
Once you've settled on an appropriately simple structure, Claude helps design and refine it iteratively rather than in one shot: draft an approach, critique it, generate alternatives, and improve. The loop has four repeating moves — propose an approach, review it against the actual needs, refine based on that review, and re-check the refined version.
Propose, review, refine, and re-check repeat as a loop — a first draft is a starting point, not a finished solution.
A first draft — a plan, a workflow redesign, or a piece of written output — is a starting point, not a finished solution. Skipping the review and refine steps and shipping the first draft forfeits the main benefit of running this loop at all.
4.3.4 Claude as Design Collaborator, Human as Decision-Maker
The review step is where Claude becomes a genuine design collaborator rather than just a drafting tool. Useful prompts for this role include "compare these two options and list tradeoffs" or "poke holes in this plan." Critically, the human keeps decision authority throughout the loop: Claude generates comparisons and critiques, and the person decides which option to run with.
4.3.4 — Exam Trap
Two traps to watch: accepting the first design instead of iterating and comparing alternatives — the value of the loop is in the critique and refinement, not the first pass. And letting Claude's comparison or critique become the decision itself, rather than input to a decision the human still makes.
Key Takeaways
- ✓Prefer the simplest approach that solves the problem — a single well-structured prompt or short chain, not an elaborate system, by default.
- ✓Added complexity adds failure points and maintenance burden without guaranteed benefit; escalate only when the simple version demonstrably falls short.
- ✓The Building Effective AI Agents guidance to prefer simplicity applies to non-developers designing business solutions too, not just engineers.
- ✓The iterative design loop is propose → review against needs → refine → re-check, repeated rather than run once.
- ✓Ask Claude to compare options and list tradeoffs, or poke holes in a plan, to use it as a design collaborator during the review step.
- ✓The human keeps decision authority throughout the loop; Claude's role is critique and alternatives, not the final call.
- ✓Accepting the first draft without iterating forfeits the main value of using Claude as a design collaborator.
Check Your Understanding
Test what you learned in this lesson.
Q1.A task can be solved reliably with a single well-structured prompt, but a colleague proposes building a five-stage multi-tool pipeline for it because it "sounds more robust." What does the simplest-approach principle say?
Q2.According to this lesson, when is escalating beyond a single prompt or short chain justified?
Q3.Which sequence correctly describes the iterative design loop from this lesson?
Q4.During the review step, a team asks Claude to "compare these two rollout plans and list tradeoffs," then adopts Claude's stated preference without further discussion. What's the issue?
Practice This Lesson