What would you never let your agent approve for itself?

Most of us have a line. mine is anything that changes what the agent is allowed to do next.. new tools, new permissions, a new API key. the agent can do the work, but the yes has to come from me at the keyboard.

someone in my last thread locks test files so the grader sits outside what the agent can touch. same idea.

Where's your line, and is it enforced or just a habit?

27 views

Add a comment

Replies

Best

Mine is two things: destroying data, and anything that reaches real users. Dropping a database collection, deleting stored files, a force push, publishing a store build, all of those wait for my yes. Everything else is the agent's to just do, routine backend deploys included, and it tells me what it shipped afterwards. Honestly it is a written rule more than an enforced one. The one part that is enforced by setup is secrets: I set those myself. Your line about permissions is a sharper version of mine, I like that it is about what the agent can do next rather than what it is doing now.

 same list here more or less. what stood out is that secrets are the only one you actually enforce and that is because it was set up once and the agent never gets to ask. the rest depends on you reading what it shipped. that is why I keep permissions as the hard line. if that moves the rest of the list does not mean much.

 Fair point, a yes after the fact is weaker than a yes before it. The one check I have that is more than reading what shipped: before a deploy that bundles the working tree, the agent looks for changes that are not its own and says so instead of shipping them, since other sessions share the repo. Still a rule rather than a lock though, so I take your point that permissions are the line everything else rests on.

  the edits-i-didn't-make check before a bundle deploy is a good one.. it's the same thing i do with tools really, look for what changed that nobody asked for before it ships.

 Same instinct, yes. The diff nobody asked for is the cheapest place to catch it, before it ships rather than in the logs after. The part I like most is that the agent says so out loud instead of quietly leaving those changes out, so I get to decide whose they were.

fake json in the tests. killed the mocks in that suite after.