Lesson 12.312.3 Permissions, and plan before you act

In everyday life. When a new hire starts, you do not give them every key on the first day. They can read the files, but they ask before they change the price list, and they never approve payments. As you learn to trust them, you let them do more without asking. You set those limits by how much damage a mistake could do.

What you will learn. How to decide what the agent may do without asking you, and how to read its plan against your own check before any code exists.

Why it matters. A mistake that is easy to undo can run alone. One that is hard to undo should wait for your yes, and a plan shows the mistake before it happens.

What may it do without asking?

A coding agent's permissions are the new hire's keys. They decide which actions the agent may take on its own and which ones need your yes. Every product names its settings differently, but they fall on one ladder.

How do I choose a rung?

By how hard a mistake would be to undo. An action's blast radius is everything a mistake there could affect, so ask what the worst mistake would cost. Editing a file in a git repository is easy to undo, because git's save points, called commits, let the agent go back. It can also show you a diff, exactly which lines changed. Deleting files outside the folder, pushing (sending your commits to the shared copy online), sending an email or running a payment is hard to undo. The harder an action is to undo, the more the agent should ask. Derek, in this chapter's overview, chose the top rung with no git, so one wrong delete cost him a day.

Figure 12.3. The permission ladder. Choose the lowest rung that gets the job done, and climb only as far as the blast radius allows. Mode names and exceptions vary by tool.

What do I check before I say yes?

The command itself. When the agent asks to run a command, the prompt shows the exact command. Read it. npm test only runs the project's tests, so saying yes is safe. rm -rf data/ deletes a whole folder, so it is not. A command that installs a package (ready-made code from the internet), deletes files, changes a setting outside the folder or sends data over the network needs a closer look. If you do not understand it, ask the agent what it does before you say yes.

When do I ask for a plan?

For any task bigger than a one-line fix. A plan is a brief in reverse. In Part II you wrote the brief and the AI did the work. In plan mode the agent reads the files, writes out what it will change and why, then stops. You read the plan, correct it, and only then let it act. A plan costs a minute. A wrong change across ten files costs an afternoon.

Plan first when:

• the task touches several files, or files you do not know well
• there is more than one reasonable way to do it
• the change is hard to undo
• you cannot yet say what "done" looks like

Act directly when the task is clear and easy to check, such as fixing a typo or changing a label in one file.

How do I read a plan?

Against your check, which holds the cases you know, such as which invoices belong on the list and why. Take your cases one at a time, and find each one in the plan. A case the plan handles wrongly is a correction to send now. A case the plan never mentions is a question to ask now.

At work. Ana asks for the Friday due-invoices script in plan mode, and reads the plan with her check from 12.1 beside it. The plan says the agent will read data/invoices.csv, add src/due-by-friday.ts and a test, and add a command to run it. It also names a rule Ana forgot to give. Some old rows have an empty due_date, so the agent will work out the date from invoice_date and the payment terms in the terms column. The file cannot say whether that is Brightline's rule, but Ana can. She finds it in her check, along with her other cases, and tells the agent the plan is right. Only then does she switch to accepting edits and let it work. Had the rule been wrong, one sentence here would have fixed it, before any code existed.

A plan says what the agent means to do. It cannot show what the finished script will do with the real file. Only running the script shows that, and your check catches it.

The operating rule: set permissions by blast radius, read every command before you approve it, ask for a plan before any change you cannot check in a minute, and read the plan against your check.

Practice it. Practice: permissions, and a plan, in your own tool, twenty minutes.