Large Language Models (LLMs) all predict text, but they differ a lot in how they follow instructions, use context, handle tools, and optimize for safety, speed, or cost. If you treat them as interchangeable, you’ll ship brittle prompts. If you treat them as different runtimes with different affordances, you’ll get reliable results.

This post explains the major differences across model families and gives a practical prompting table you can copy/paste from.

How LLMs Differ (the parts that matter in real engineering)

1) Instruction-following “personality”

Some models are strict about structure (“return JSON exactly”), others are more conversational by default.

• More structured / deterministic (usually better for automation): tends to respect schemas, headings, and explicit constraints.
• More creative / expansive (usually better for ideation): tends to add helpful context, caveats, and extra suggestions unless constrained.

Engineering takeaway: When you want automation, explicitly constrain: output format, allowed fields, length, and failure behavior.

2) Context window and “attention hygiene”

Models have different context windows (how much you can paste in) and different “signal vs noise” behavior (how easily they get distracted by irrelevant text).

Engineering takeaway:

• Put the goal and output contract at the top.
• Put inputs (logs, code, docs) next.
• Put edge cases and style last.
• Use delimiters like --- / triple backticks for long inputs.

3) Reasoning depth vs. latency/cost trade-offs

Some models are optimized for fast responses, others for deeper multi-step reasoning. Even within one provider, there are often “fast” and “thinking” tiers.

Engineering takeaway: Use the cheapest/fastest model that still meets your quality bar, and escalate only when:

• the task needs multi-step planning,
• it’s easy to make expensive mistakes (security, migrations),
• or accuracy matters more than speed.

4) Tool use (function calling / agents)

Many modern LLMs can call tools (search, DB queries, code execution, internal APIs). Providers implement this differently:

• strict JSON tool calls vs. “tool suggestions”
• different schemas / error modes
• different best practices around retries and validation

Engineering takeaway: Treat tool calls like an API contract:

• validate inputs,
• handle partial failures,
• and require the model to cite which tool outputs it used.

5) Multimodality (text + images + audio)

Some model families are stronger at OCR-like tasks, screenshots, UI reasoning, diagrams, or mixed text+image debugging.

Engineering takeaway: If your workflow includes screenshots/logs/UI states, pick a model proven for that modality and describe what matters (“The red error toast says…”) rather than relying on inference.

6) Safety behavior & policy boundaries

Models vary in how they refuse, redact, or soften responses—especially around security, personal data, or regulated domains.

Engineering takeaway: For security work, don’t rely on the model to “do the right thing” implicitly. Provide a scope (what systems, what permission, what’s authorized) and ask for defensive guidance.

Prompting Patterns That Work Almost Everywhere

Use this minimal “contract-first” template:

ROLE: You are a senior <domain> engineer.

GOAL:
- <what success looks like>

CONTEXT:
- <what the model needs to know>
- Inputs: <paste or reference with delimiters>

CONSTRAINTS:
- Must: <requirements>
- Must not: <prohibitions>
- If unsure: <how to behave>

OUTPUT:
- Format: <markdown | JSON schema | bullet list>
- Sections/fields: <exact structure>

Prompting Differences by Model Family (Copy/Paste Table)

Notes:

• “System prompt” = highest-priority instructions (if your platform supports it).
• Some providers expose “developer” vs “system”; some only “system/user”.
• Names evolve quickly—think in families (GPT/Claude/Gemini/Llama/Mistral), not only specific versions.

Practical Prompt Recipes (by task)

A) Code generation (production)

• Do: specify language, framework, file boundaries, and constraints (performance, security, error handling).
• Do: require tests or at least a “test plan”.
• Don’t: ask “write the code” without defining I/O.

Example skeleton:

GOAL: Implement X.
INPUTS: <API contract, data shapes>
CONSTRAINTS: No breaking changes. O(n) time. Handle nulls. Add unit tests.
OUTPUT: Provide <file paths> and code blocks per file. No commentary.

B) Refactoring safely

• Ask for: plan → diff → risk checklist.
• Require: “List behavior changes” and “backward-compatibility notes”.

C) Data extraction / automation

• Use a strict JSON schema.
• Add: “If a field is unknown, set it to null (don’t invent).”

How to Keep Up With New Models (without rewriting your app every month)

1) Track families, not names

Model names change; capability classes persist:

• fast/cheap vs deep/reasoning
• text-only vs multimodal
• short-context vs long-context
• strict tool calling vs free-form

Design your system with capability flags (supports_tools, supports_vision, max_context, strict_json).

2) Maintain a “prompt compatibility suite”

Create a small set of prompts you run on every candidate model:

• JSON extraction correctness
• instruction hierarchy (system vs user)
• refusal/edge cases
• long-context retrieval
• tool-calling compliance

Treat it like unit tests for prompts.

3) Read the right sources on a cadence

• Provider release notes (OpenAI / Anthropic / Google / open-weight vendors)
• Model cards / docs (behavior changes, tool specs, safety changes)
• Independent evals (HELM-style reports, community benchmarks, engineering blogs)
• GitHub repos for your orchestration framework (LangChain/LlamaIndex/etc.) for breaking changes

Create a lightweight monthly ritual: “scan release notes + rerun compatibility suite”.

4) Build guardrails that absorb change

• Validation layer: JSON schema validation + retries with corrective feedback
• Fallbacks: if strict JSON fails, rerun with a constrained re-prompt; if still fails, downgrade task or route to a stronger model
• Observability: log prompt version, model ID, token counts, tool-call success rate, parse failure rate

5) Use “prompt adapters”

Keep a canonical prompt in your product, and generate provider-specific variants:

• token-limit trimming
• tool-call formatting differences
• verbosity controls
• safety/compliance inserts

This way, new models become a configuration change—not a rewrite.

Closing advice from the “AI master”

If you remember one thing: write prompts like API contracts.
Define success, constrain the output, validate it, and measure drift over time. That mindset survives every new model release.