1.2 The difference between knowledge, reasoning, and tools

Three different capabilities

When you work with an LLM, it’s easy to blur three different things into one. Separating them makes your prompts clearer and your verification strategy obvious:

• Knowledge: what the model can recall or approximate from training data.
• Reasoning: what the model can derive by manipulating information in the current context.
• Tools: what the model can do when it’s allowed to call external functions/APIs (including running code, searching, reading files).

Knowledge (stored patterns)

The model’s “knowledge” is the patterns and facts it picked up during training. This includes:

• Common APIs and libraries (sometimes outdated).
• Programming idioms and style conventions.
• General facts and explanations that appear frequently in the data.

Strengths: quick recall, good defaults, good first drafts.

Limits: can be stale, incomplete, or confidently wrong—especially for niche tools, rapidly changing products, or your private codebase.

Reasoning (working through the context)

Reasoning is when the model uses information you provide (specs, examples, code snippets, logs) to infer or derive an answer. In practice this looks like:

• Explaining tradeoffs between designs.
• Finding a bug from an error trace and a small code sample.
• Refactoring logic while preserving behavior (when constraints/tests are clear).
• Deriving edge cases from a spec.

Strengths: can adapt to your specific situation if you provide the right context.

Limits: reasoning quality drops when context is messy, contradictory, or too large; it can also “reason” from wrong premises if you give it incorrect assumptions.

Tools (doing real work in the world)

Tools are how you move from “plausible text” to “verified reality.” Tools can include things like:

• Running tests or linters.
• Reading your repo files.
• Calling an API (search, database, payment provider, etc.).
• Executing a function with structured inputs/outputs (tool calling).

Strengths: tools produce evidence. They reduce hallucination because the model can check facts instead of inventing them.

Limits: tools can fail (timeouts, permissions, network errors), and tool interfaces can be mis-specified.

How to use each mode in vibe coding

A good vibe-coding session usually uses all three modes, in order:

1. Knowledge for speed: “Give me a first-pass plan and scaffolding.”
2. Reasoning for fit: “Given these constraints and examples, refine the design.”
3. Tools for truth: “Run tests / validate schema / reproduce the bug and report results.”

The key is to match your expectations to the mode:

• If you’re in knowledge mode, expect errors and verify aggressively.
• If you’re in reasoning mode, keep context small and structured.
• If you’re in tool mode, design clean interfaces and handle failures explicitly.

Common failure modes and fixes

Failure: stale or invented facts

• Symptom: API calls that don’t exist, settings that aren’t in the UI, “sounds right” but doesn’t run.
• Fix: ask for sources, cross-check docs, or use tools to verify (run/build, inspect real output).

Failure: reasoning beyond provided context

• Symptom: the model assumes details you didn’t specify and builds on them.
• Fix: add a “stop and confirm assumptions” step; provide explicit constraints and examples.

Failure: tool chaos

• Symptom: repeated tool calls, runaway loops, fragile parsing, unclear error handling.
• Fix: enforce budgets, add timeouts/retries, make tool outputs structured, and require confirmation for risky actions.

Prompt patterns that map to the three modes

Knowledge-first prompt

Give me a minimal implementation sketch for X in Y language.
Assume only standard libraries. Keep it small and runnable.

Reasoning prompt

Given this spec + these examples, propose a design and list edge cases.
Stop and ask questions if any assumption is unclear.

Tool/verification prompt

Here’s the failing test and error output.
Propose the smallest diff to make the test pass.
Tell me exactly what to run to verify.

Where to go next

• 1.3 Context windows and why “just add more text” fails
• 1.4 Temperature, randomness, and creativity knobs