Home/ Part IV — AI Studio Deep Dive: Every Knob Matters Eventually/10. Prompt Structure in AI Studio/10.1 System vs developer vs user instructions (practical rules)

10.1 System vs developer vs user instructions (practical rules)

Overview and links for this section of the guide.

On this page

The mental model (instruction hierarchy)

In most LLM systems, instructions have a precedence order. The exact UI names can change, but the concept is stable:

  • System: global behavior rules (highest priority).
  • Developer (project): rules for the project and the assistant role.
  • User: the task request and its acceptance criteria.

When instructions conflict, higher-priority instructions usually win.

Why builders care

If you put critical rules in the wrong layer, you’ll experience “the model ignored me” even when it’s behaving correctly under its instruction hierarchy.

System instructions: what belongs there

System instructions are for rules that should apply across the entire project and across tasks. Examples:

  • “Be concise and output diff-only changes for code edits.”
  • “Never include secrets or credentials in outputs.”
  • “Ask clarifying questions when requirements are ambiguous.”
  • “Prefer tests and verification steps.”
  • “Do not invent APIs; confirm availability first.”

Guideline: keep system instructions short

Long system prompts often become self-contradictory. The best system prompts are:

  • short (fits on one screen),
  • expressed as clear rules,
  • stable over time,
  • focused on behavior and safety.
Don’t put task details in the system layer

If you put a specific feature spec into the system layer, you’ll fight it later. System is for rules; user is for tasks.

Developer/project instructions: what belongs there

Developer instructions are where you put project-specific constraints and working agreements, such as:

  • language/runtime versions,
  • dependency allowlists/forbidden deps,
  • code style and file structure rules,
  • output format requirements (file tree + code blocks, unified diff),
  • scope rules (“only touch these files”),
  • review rules (“plan first, then diff-only steps”).

Think of this as the “project README for the model.”

User/task instructions: what belongs there

User instructions are for the work item you want done right now:

  • the feature request, bug report, or refactor goal,
  • acceptance criteria (tests/examples),
  • inputs and expected outputs,
  • reproduction steps and errors,
  • additional constraints unique to this task.

Task prompts should be as short as possible while still being precise.

Use “plan first” for any risky task

When you put “stop after plan” in the task prompt, you create a checkpoint that prevents the model from committing to a bad direction too early.

How to handle conflicts and drift

Conflicts happen in long sessions. Handle them explicitly:

  • Re-anchor: restate the stable constraints (runtime, deps, diff-only).
  • Resolve contradictions: “This new requirement overrides the earlier rule X.”
  • Reset state: summarize the current spec and ask the model to confirm assumptions.

A practical rule

If you find yourself repeating the same rule (“diff-only”) multiple times, it belongs in a more stable layer.

Copy-paste templates

Template: minimal coding house rules (system-level)

House rules:
- Be concise.
- Ask clarifying questions when requirements are ambiguous.
- Prefer plan-first for non-trivial tasks.
- For code changes: output diff-only changes (no full rewrites).
- Do not introduce new dependencies unless explicitly allowed.
- Do not include secrets in prompts/outputs/logs.
- Provide verification steps (tests/commands) with changes.

Template: task prompt (user-level)

Task:
[Describe change.]

Acceptance criteria:
- [...]

Constraints:
- Files in scope: [...]
- No new dependencies
- Diff-only changes

Process:
1) List assumptions and questions.
2) Propose a short plan.
3) Stop after the plan.

Where to go next