Using coding assistants without losing control

Coding assistants can now read a whole project, run commands and suggest changes across many files. Used well, they save hours every week. Used carelessly, they run things nobody checked, spend money nobody planned for and say the tests passed when they never ran.

Staying in control does not mean approving every keystroke. It means being relaxed about small things and strict about big ones.

Sort actions by how much they matter

• Reading and searching the code: let it happen.
• Editing files on an engineer's own copy: show the changes and let people review them together.
• Running commands or installing software: ask first, and show exactly what will run.
• Anything touching the live product, passwords or shared code: needs a clear yes from a named person.

Show exactly what will happen

A request that just says "run the tests" is not enough. Show the exact command and the files that will change. People can only approve what they can actually see.

Set a spending limit

Every request to a coding assistant costs money. Set a limit for each session, show it next to the work and stop when it is reached. A clear note such as "Stopped at your $5.00 limit" is far better than a surprise bill.

Only claim what can be proven

A coding assistant should only say the tests passed when it actually ran them and can show the result. If it could not run them, it should say so. Honest updates are what make the rest of the report worth trusting.

Keep a record

Write down what was suggested, who approved it and what actually ran. When something goes wrong, that record turns a long investigation into a five-minute read.