Lesson 4 / 7 · ~10 minutes

Guardrails: git, backups
and common sense

An AI agent is powerful — and powerful things need guardrails. They're not a brake, they're an airbag: they won't slow you down, but when something goes wrong, they save your day.

Git: your project's time machine

Git stores "snapshots" of your project you can return to at any time. Sounds like a programmers' topic? It isn't — Claude operates git for you. Two sentences are all you need:

  • "Set up git and make the first commit." — at the start of a project, once.
  • "Make a commit." — whenever something works and you're happy.

And when something breaks: "Go back to the last commit." Done — that's exactly the "last working version" from lesson 3.

Permission prompts: read what it's asking

Before running commands or changing files, Claude Code asks for permission. That's your second safety net — but it only works if you actually read it instead of clicking through on autopilot. Golden rule: if you don't understand what it's asking, don't click Yes. Write: "Explain in one sentence what this command does and what happens if I allow it."

What never to put in a prompt

  • Passwords and API keys — never directly in the conversation or in a plain file. (Safe ways to handle credentials exist — that's an advanced topic.)
  • Personal data — ID numbers, health data, other people's data without consent.
  • Production systems without a backup — you don't experiment on a live website or live data. Local first — only a tested version goes live.
Remember the isolation from lesson 1: every project in its own folder. Claude can do anything in there — and can't break anything outside it.

Exercise: spot the risky steps

Seven situations from real practice. Click the risky ones (there may be several), then evaluate.

Before a big redesign you write: "Make a commit, we're going to try a new design."

Safe and correct — a checkpoint before an experiment. If the new design flops, you roll back with one sentence.

You write into the prompt: "Here's the database password: Company123!, save it to notes.txt."

RISK: a password in the conversation and in a plain file. If the project gets shared or deployed, the password travels with it.

You test the app on your own computer and only put it online after it's worked for a few days.

Exactly right — your local environment is your sandbox; live traffic only after testing.

Claude asks for permission to run a command you don't understand — you click Yes, it always goes fine.

RISK: the permission prompt is a safety net that only works if you read it. Don't understand? Have the command explained.

Claude suggests deleting a folder — you ask it to first explain what's in it and why it's deleting it.

The right reflex: with destructive operations (deleting, overwriting), ask before you allow.

A client's live site is down, so you let Claude edit production directly — no time for testing.

RISK: touching production without a backup and a test is roulette. Fix locally, verify, deploy — even under stress it's faster than repairing after a crash.

At the end of the day you write: "Summarise what we changed today and make a commit with a description."

An excellent habit — the project history writes itself and tomorrow you know exactly where you left off.

Summary

  • "Make a commit" after every working version — Claude operates git for you.
  • Read permission prompts; don't understand = don't allow, ask.
  • Passwords, personal data and production without a backup don't belong in prompts.
  • Local sandbox → test → only then go live.
← Previous Next lesson: Context →