Key Points

Before We Use AI: What Are We Practising?

This lesson teaches you to inspect, question, constrain, and validate AI output, not to delegate your thinking.
Generation, understanding, and validation are different skills. Generation is the easy one.
For a novice, verifying generated code can cost more effort than writing it.
Working code is not the same as trustworthy code. Use the run / revise / reject checkpoint every time.

Different AI tools see and change different things; always ask what a tool can see and do before trusting it.
A CLI agent can read, run, and edit your real files, which makes verifying what it changed part of the workflow.
Run /init inside Claude Code to create a CLAUDE.md Living Spec that reduces context drift.
A portable AGENTS.md lets the same spec travel across different AI tools, but auto-loading it isn’t universal; check per tool (Claude Code needs an explicit @AGENTS.md import).
The shift is from writing syntax to actively reviewing intent, assumptions, and evidence; it does not remove your responsibility.

Be specific and provide context.
Plan before you act: use plan mode so the agent can’t write files until you approve its approach, not just a prompt asking it to wait.
Prefer prompts that preserve learning: ask for plans, hints, and the simplest version, not the finished answer.
Always validate AI outputs, and never ship a line you cannot explain.
Introspection can surface issues the first draft missed, but it is not a guarantee of correctness; treat what it finds as something to verify, not proof.

Predict the inconsistencies yourself before prompting, so you can judge the AI’s plan.
Ask for a plan first, put constraints in the spec, then generate code.
Explain the script before you run it; you cannot validate what you cannot explain.
Validate with concrete checks (row count, missing values, date format), not because it ran.

The approval gate separates experimental prototypes from validated research.
Rewrite time is a local, formative signal about your workflow, not a productivity score.
Immutable requirements prevent the AI from drifting away from research specs.
A multi-model critique, run in a fresh session, is a reviewer, not an authority.
You cannot validate what you cannot explain.

Avoid AI for security-critical tasks, sensitive data, and basic syntax practice.
Know when AI supports learning and when it gets in the way.
You are responsible for the final output.
Open-weight models offer better reproducibility (a pinned revision); the right choice for a task still depends on data sensitivity, auditability, and cost, not a default.

Review-ready means spec, plan, code, validation, a result, provenance, and a decision, not just a script that runs — a descriptive plot is not itself a statistical finding.
The same checkpoint pattern scales from one script to a whole small project.
A plot can render cleanly and still be wrong; domain plausibility is your job.
“Revise” is a valid, honest outcome when the evidence does not yet cover the claim.

The workflow transfers across tools; match the tool and backend to the task and data sensitivity.
Attribute AI use transparently; it cannot be an author.
Leave with a concrete plan for your own data, including the one check that would catch a silent error.
Before adopting a new tool, check its scope claims, transparency, citations, and data-privacy terms; new tools appear daily, and many are more marketing than substance.