Skip to main content
What this unit solvesYou already use AI to write code, look things up, and run analyses. This unit doesn’t teach you “how to use it”; it first makes one thing clear: opening a tool and using it correctly are separated by an entire layer of mental models and configuration engineering. Without crossing that gap, no matter how strong the model is, what you get is fluctuating, irreproducible output that sometimes errs without your noticing.

Learning objectives

After this unit, you should be able to:
  • Explain in your own words the concrete difference between “using AI” and “using AI correctly”, and name at least three costs of the gap.
  • Distinguish the “chat-box mental model” from the “collaborating-agent mental model”, and know which one you are currently in.
  • Explain why configuration is the core lever of an AI tool, not an optional advanced feature.
  • Understand how this training’s four dimensions form a single path from cognition to automation.

1. A scene you probably know

You open a coding agent in the terminal and toss in “refactor this function to be a bit cleaner”. It runs, changes five files, the tests are still green, and you hit accept. Three weeks later some edge case breaks; you go back to that change and find it quietly removed a side effect you depended on, because you never told it that side effect was intentional. This is not the model being “dumb”. This is you treating an engineering task that needs context, constraints, and verification as a wishing well. The model doesn’t have your project conventions, your implicit requirements, or your definition of “clean”; it can only guess from the average of its training data. Guessing right is luck; guessing wrong is the norm.
The core stanceAn AI tool is not a clairvoyant oracle, nor a smarter autocomplete. It is a collaborating agent you can configure, constrain, teach, and automate. Every minute you put into configuration compounds across every later interaction.

2. The gap between “using it” and “using it correctly”

Put two kinds of user side by side and the gap is clear. Note: the difference is almost never “what prompt was given”, but “what was configured beforehand and verified afterward”.
DimensionOrdinary use (using AI)Correct use (using AI correctly)
ContextRe-explain the background each time, or assume the model remembersPin project conventions, roles, and constraints into memory and rule files
PrivacyAccept defaults wholesale, unaware whether conversations are used for trainingExplicitly set training opt-out, retention period, temporary chats
Output qualityFluctuates with the day’s luckRaise the quality floor and make it reproducible via rules and examples
TrustAccept what looks reasonableVerify every verifiable claim (run tests, check sources)
Repeated workRedo the same flow by hand each timeAutomate the flow with Skills / Hooks / templates
Tool choiceGo by GitHub stars or someone’s recommendationJudge real usefulness with your own task benchmark
The cost of the gap is hiddenThe dangerous part is not the obvious error (you’ll catch that), but the output that looks right and is actually off: a quietly removed side effect, a plausible-but-wrong citation, a command run outside your security boundary, sensitive data uploaded for training. These costs don’t surface on the spot; they settle three weeks later, in a reviewer’s comments, in a data-breach notice.

3. Two mental models

How you use a tool depends on what you picture it as. Most people are stuck because they’re still in the first two models.
The evolution of the mental model
  1. Search-engine model: treat AI as Google. Ask once, get an answer, ask again if it’s wrong. Problem: no context accumulation, treating the model as a static knowledge base, completely missing its ability to reason within your situation.
  2. Autocomplete model: treat AI as a stronger Tab completion. It writes after you; you passively accept. Problem: you surrender control, and the model’s default assumptions replace your engineering judgment.
  3. Collaborating-agent model (this training’s target): treat AI as a strong senior collaborator who needs onboarding. You give it a role, conventions, constraints, available tools, and verification criteria; it works autonomously within that frame, and you design the frame and review the results.
Jumping from the second model to the third is not about getting better at prompting; it’s about starting to treat configuration as a first-class citizen. On a senior collaborator’s first day, you hand them the team-conventions doc, the scope of permissions, the code-review standard. For an AI agent, those map to CLAUDE.md, permission settings, Hooks, and verification flows.

4. Why configuration is the core lever

Engineering-minded people tend to underrate configuration, because it looks like “admin work” rather than “real skill”. That’s a misjudgment. On agentic tools, configuration is your programmatic control interface over model behavior. Break it into four layers, which map exactly to this training’s four dimensions: With the same underlying model, whether these four layers are configured correctly makes an order-of-magnitude difference in output. A well-written CLAUDE.md lets the model use your lab’s terminology directly, follow your code style, and automatically avoid the anti-patterns you’ve listed; a correct privacy setting lets you hand it research data with confidence; a Hook can run a type check on every save and block errors before they enter version control.
Why Claude is the primary referenceAnthropic’s Claude family (Claude Code especially) exposes all four layers as explicit config files and mechanisms, and is one of the most complete implementations of “configuration as interface” available today. We go deep on it as the backbone, then map other tools across: you’ll find ChatGPT’s custom instructions, Gemini’s Gems, Copilot’s instructions files, and Cursor’s rules are all the same set of concepts in different packaging.
Example: which line separates “using it” from “using it correctly” Back to the refactoring scene at the top. Same sentence; the difference is not a smarter prompt, but that you wrote the constraint into configuration. Before (bare prompt, no constraints):
refactor this function to be a bit cleaner
After (pin the constraint in CLAUDE.md first, then say the same sentence):
# CLAUDE.md
- Before refactoring, list the behaviors you intend to remove or change, and wait for my confirmation.
- Treat any side effect as intentional by default; do not remove it without my consent.
The After version first hands you a “here’s what I plan to touch” list, letting you intercept that quietly removed side effect instead of discovering it in production three weeks later. The extra cost is writing those two rule lines once; the saving is the rework debt on every future refactor.

5. The shared skeleton across tools

Vendors differ, names and folder names change, but the underlying concepts are highly consistent. Build the “concept column” of this table first, and learning any tool later is just filling in the blanks.
ConceptAnthropic Claude (primary)OpenAIGoogleGitHub CopilotCursor
Personalization instructionsClaude.ai “Instructions for Claude” / CLAUDE.mdChatGPT custom instructionsGemini “Instructions for Gemini”VS Code personal instructionsUser Rules
Project-level rules./CLAUDE.md, .claude/rules/AGENTS.mdAGENTS.md, .agent/rules/ (singular; .agents/ is a third-party misspelling).github/copilot-instructions.md.cursor/rules/*.mdc
Reusable flowSkill (SKILL.md)Custom GPT / Codex promptGem / workflow.prompt.md/create-rule
Privacy training opt-out”Help Improve Claude” toggle”Improve the model for everyone” toggle”Keep Activity” toggleenterprise/personal data settingsaccount privacy settings
Automation hookHooksCodex hooksAntigravity workflowCopilot hooks (preview)(no equivalent yet)
Self-check (stop here for a moment)Take the tool you use most and ask yourself:
  • Where are my personalization instructions set? Or are they not set at all, re-explained each time?
  • Do I know whether my conversations are used for training? Where is the toggle?
  • Have I pinned any “flow I repeat” into something reusable?
If you can’t answer two of the three, you’re in the “ordinary use” column from Section 2.

6. How to cross the gap

Four dimensions, one path:
  1. Foundations (Part I): first make the mental models and mechanics clear (tokens, context window, agentic loop, context engineering). Without the principles, configuration is just copying.
  2. Configuration (Part II): with Claude as the primary reference, walk through personalization, privacy, CLAUDE.md, Skills, Hooks, Subagents, Plugins, then map other tools across.
  3. Judgment (Part III): train yourself to judge independently whether a tool, a Skill, or a GitHub repo actually fits you, rather than going by stars or recommendations. Build security, privacy, and supply-chain risk awareness at the same time.
  4. Customization (Part IV): teach you to generate your own content: write your own rule files, develop dedicated Skills and Subagents, automate flows with Hooks, wire up your environment with MCP.
A note on learning methodDon’t read everything before acting. After each Part II configuration unit, do it once on your own tool, then return to Part III and ask “is this actually useful to me?” The value of configuration only proves out inside your real workflow.

7. Common pitfalls

Anti-pattern list
  • Treating defaults as optimal: defaults are tuned for the “average user”, not for your research field or team conventions.
  • Chasing the “strongest prompt” while ignoring configuration: even the best prompt is one-off; configuration compounds.
  • Blindly trusting green tests / a reasonable look: green tests don’t mean semantic correctness, and reasonable output doesn’t mean factual correctness. Verify what’s verifiable.
  • Copying someone else’s CLAUDE.md or Skill: someone else’s configuration reflects their workflow. Copying often imports constraints you don’t need, and even security risks (see 03-3).
  • Ignoring privacy settings until something goes wrong: training opt-out, retention period, temporary chats: set these before you hand over sensitive data.

Self-check

The bar for passing this unit
  1. Can you explain to a colleague “why configuration matters more than the prompt”?
  2. Can you point out which mental model you’re currently in, and where to move next?
  3. Can you fill in your main tool’s column in the Section 5 table?

Sources and further reading