Before you run an agent, understand what you are agreeing to.

The four powers

Read files. Usually safe. Remember it can read any file it is pointed at, including
one with passwords in it.

Write files. It can change and delete your work. Safe only if you can undo it.

Run commands. The big one. A command can install software, delete folders, send data
over the internet, or change settings. Anything you can type, it can type.

Use the internet. It can fetch pages and download things. This is how it looks up
current documentation. It is also how information leaves your machine.

The three settings

Every tool offers roughly the same three choices:

Ask every time. It stops and waits before each action. Safest, slowest, and honestly a
little tiring after the tenth approval.

Allow a list. You say “running tests is always fine, deleting files always asks”. Good
balance. This is where you will end up.

Allow everything. It runs without stopping. Fast, and occasionally very expensive.

Start here

For your first week, ask every time. Not because agents are reckless, but because you
need to see what a normal session looks like before you can tell when one is not normal.

Then move to a list, adding the safe repeated actions as they annoy you.

The safety rules

These are short and they matter.

1. Always work inside a git repository, and commit before you start.
This is the single most important habit in the course. If the agent makes a mess, one
command puts everything back. Without git, there is no undo.

2. Never point an agent at a folder containing passwords or keys.
Not your home folder. Not a folder with a .env file full of live credentials. Anything it
reads goes into the context window, and the context window is sent to a company’s servers.

3. Read commands before approving them.
Especially anything with rm, sudo, curl, chmod, or a password in it. Approving
without reading is the same as not having the setting at all.

4. Be more careful on work projects than on your own.
Your own project, broken, is a lesson. Your employer’s project, broken, is a meeting.

5. Watch what it wants to install.
“I will add a small library for this” is normal and usually fine. It is still a decision
somebody should make on purpose.

What actually goes wrong

Not dramatic things, mostly. In real use the common problems are:

  • It changes a file you did not want touched, and you notice three steps later.
  • It installs three libraries when you wanted zero.
  • It “fixes” a failing test by changing the test instead of the code.
  • It rewrites a working file to a slightly different style, creating a huge change to review
    for no benefit.

Every one of these is undone by rule 1. Commit first.

Try this before the next lesson

  1. Run git status in a folder you care about. If it says this is not a repository, that
    folder is not ready for an agent.
  2. Search your project for files holding passwords or keys. Would you be comfortable if
    their contents were sent to a server?
  3. Write down which three commands you would put on your “always allow” list, and why.
PreviousNext