There's a version of AI-assisted work where the assistant just handles things. You describe a goal, it executes, you review the result. Fast, frictionless, and — if you've set it up right — genuinely effective.
There's another version where the assistant also just handles things. Except this time it pushes a release you weren't quite ready to push, or deletes something you wanted to review first, or runs the thing you said out loud but didn't actually mean yet.
The difference between those two versions is one question: which actions does the AI ask about before it does them, and which ones does it do on its own authority? Getting that line right took me longer than I expected. The instinct is to either ask about everything (exhausting) or trust it with everything (occasionally catastrophic). The working answer is neither.
1.The skill that fired when I wasn't ready
I use a library of named skills — specialised commands that run particular workflows. Some of them exist because I kept forgetting to run them manually; the whole point is that they fire automatically at the right moment, without me having to remember.
One of them is a design quality check. During any UI session — a landing page, a dashboard, a widget — it runs at trigger points I've pre-defined: before a push, after a major layout pass, when starting something new. I don't ask for it; it just runs. And that's correct. I specifically wanted it to run without asking, because I knew I'd skip it if I had to remember it every time.
But other skills — deeper strategy tools, release automation, multi-app deployment sweeps — I do not want firing automatically. When I set one of those up, I want it to name itself, tell me what it's about to do, and wait for a yes. Not because I don't trust it, but because those actions have blast radius. Running the wrong release flow on the wrong branch, or sweeping a change across four apps at once when I only meant one, is exactly the kind of mistake that takes an afternoon to undo.
The rule I arrived at came directly from a session where I had to have an explicit conversation to establish it: impeccable runs automatically; everything else suggests and confirms. One skill. One exception. Everything else: name it, say what it does, wait.
2.The commit that went up bare
Before I had a rule about commit messages, Claude would sometimes commit work without a message. Not as sabotage — just as the natural end of a work block, the same way a human might hit save without thinking about the save. The git log would accumulate a trail of timestamps with no story attached.
The issue with a bare commit isn't that the work is lost — it isn't. The issue is that every future session has to reconstruct the reason for that change from the code itself, rather than the one-line summary that would take ten seconds to write. Multiply that by a few dozen commits and the history becomes archaeology.
The rule I added was straightforward: every commit must have a descriptive message, written in conventional commit style when it fits. But the interesting thing I noticed was that the AI was perfectly happy to write good commit messages — it just hadn't been told to. It wasn't being lazy; it was waiting for the expectation to be stated. Once the rule existed in the system, it followed it consistently.
This is a recurring pattern. The AI will do things the way you've specified, to the extent you've specified them. Vague expectations produce vague outputs. Explicit rules produce explicit behaviour. The commit message issue was a reminder that "do what makes sense" is not an instruction — it's an invitation to guess.
3.The destructive action that needed a second voice
Somewhere in the middle of a multi-project session, a sweep was proposed: park nine products. Collapse overlapping apps. Stop maintaining things that weren't earning their keep. Good strategic thinking, well-reasoned — but the action being proposed was to remove active projects from the working portfolio.
That's an irreversible edit to your own strategy. Not code you can roll back with a revert. Not a file you can restore from git. A decision about what you're building and what you're not.
The right thing, and what happened, was a proper pause. Not the AI deciding to do it and reporting back. A genuine "here's what I think, here's the reasoning, do you want to proceed?" — and then a deliberate yes from me, having read it, agreed with it, and owned the decision.
The portfolio got pruned. Nine things parked. It was right. But the reason it felt right rather than alarming was that I'd been the one to pull the trigger, not found out after the fact.
The pattern underneath
Autonomy is the point of working with AI. If you're manually approving every trivial action, you've built yourself an expensive autocomplete. But autonomy without a clear boundary between "proceed" and "ask" is how you end up surprised by things you didn't intend.
The useful mental model is two buckets:
- Proceed — reversible, in-scope, explicitly defined. The AI does it, tells
you what it did. Design polish, formatting, draft writing, lint passes, well-scoped code changes.
- Confirm — irreversible, high blast radius, or first time in new territory.
The AI proposes, you decide. Releases, deploys, bulk changes, strategic moves, anything that touches what goes out the door.
The default when you're unsure which bucket something falls into is to confirm. That's a one-line question and a one-word answer. The cost is two seconds. The cost of guessing wrong in the other direction can be much higher.
Build the autonomy you want. Just know where the lines are.