Pattern 1 of 10

Be the architect, not the coder

The biggest shift in working well with AI is moving from telling it every keystroke to telling it what a good result looks like, then letting it build.

Describe the outcome and the constraints. Let the model handle the execution.

Being the architect means you specify the outcome, the boundaries, and the definition of done, and you let the model decide the steps. You stop dictating each instruction and start describing the target.

This is the opposite of how most people start. Beginners tend to either under-specify ("write me something about marketing") or over-specify every tiny step. The architect sits in between: precise about the goal, generous about the method.

Why it works

Modern models are strong at filling in method when the goal is clear. What they cannot do is read your mind about the goal. Research and official guidance agree on the core failure mode: most weak outputs come from ambiguity, not from model limitations.

How to do it

Write a brief, not a command. A good brief answers: what is the outcome, who is it for, what must it include, and what must it avoid.

Too vague

"Write something about our product launch."

A clear brief

"Write a 150-word announcement for our product launch, aimed at existing customers, highlighting the new export feature, in a warm and plain tone. No hype words."

Notice the good version never tells the model how to write each sentence. It defines the target and the guardrails, then steps back.

Example you can copy

A clear brief
You are writing a short product announcement.

Goal: announce our new CSV export feature to existing users.
Audience: current customers who already use the dashboard.
Must include: what the feature does, how to find it, one line on why it helps.
Constraints: 120-150 words, warm and plain tone, no marketing buzzwords.
Output: the announcement text only, no preamble.

When it helps

  • Open-ended creative or writing tasks where method should stay flexible
  • Building or coding tasks where you care about the result, not each step
  • Any time you find yourself re-prompting to fix small details

When to skip it

  • When the exact procedure matters and must be followed precisely (then specify the steps)
  • For tiny, single-shot factual questions where a brief is overkill

Common mistakes

  • Under-specifying the goal and blaming the model for guessing wrong
  • Over-specifying every step, which removes the model’s strength and creates brittle prompts
  • Forgetting the constraints, so the model fills gaps with its own defaults

Frequently asked

What does "be the architect, not the coder" mean in prompting?

It means you describe the outcome you want and the constraints to respect, then let the AI handle the detailed execution, rather than dictating every individual step.

Why do vague prompts produce bad results?

When a prompt is vague, the model fills the missing details with its own defaults, which may not match what you wanted. Most weak outputs come from ambiguity rather than model limitations.