I felt a thrill this week when I started my session with claude --dangerously-skip-permissions. Have you tried this? I'd been circling it for a while — the flag sits there in the docs, named to make you flinch. And I flinched. But this week I typed it, hit enter, and watched Claude take off.
What followed was a week of emotions I didn't expect from a CLI flag.
the math
The name is a warning label. "Dangerously." They want you to feel the weight of it. And every responsible instinct responds accordingly: just approve each operation, it takes a second, stay in the loop.
But I'd been noticing the real cost of those prompts. Not any single one. No individual approval takes more than a moment. It's the accumulated weight. The context-switching between "reviewing a permission dialog" and "thinking about the problem I'm solving." The re-anchoring after each interruption, where I have to reconstruct the thread I was holding. And the long sessions where I'm deep in a thought I don't want to lose, and I realize I've been rubber-stamping "yes" without reading the prompt for the last ten minutes. That last part bothered me most. If I'm not actually reading the prompts, who are they protecting? They're not a safety mechanism anymore. They're a ritual.
So I ran the math. The expected cost of the flag (some unknown thing going wrong and caught late) was lower than the known cost of the interruptions I was already paying. I tried it.
what it does when I'm not watching
The first session was disorienting. Claude just ran. Multi-file edits, test runs, formatting fixes, a cascade of operations with no interruptions. I'd give a directive and watch the work happen. The rhythm was different from anything I'd experienced in months of using Claude Code. There was a momentum to it, the kind that only exists when nothing is pulling you out of the problem.
Then something I didn't expect. A file changed that I hadn't anticipated. A refactor that touched more than I'd scoped in my head. I went to the git diff like a nervous parent checking the baby monitor. My shoulders were up near my ears and I didn't notice until I caught myself holding my breath over a three-line change in a test file. At one point the context compacted, and I used that as an excuse to escape the session entirely, just to look around and make sure nothing had gone sideways.
Here's what that looks like. Right after a compaction, Claude re-orients itself. The system re-anchors it the same way it would re-anchor me:
✻ Conversation compacted
⎿ Read .claude/skills/library-knowledge/COMPONENTS.md
⎿ Read .claude/skills/library-knowledge/DATA-FLOW.md
⎿ Read .claude/skills/library-knowledge/SKILL.md
⎿ Read apps/web/src/components/workspace-landing.test.tsx
⎿ Read apps/web/src/components/knowledge/knowledge-board.test.tsx
⎿ Plan file referenced
Skill references. Tests. The plan. It didn't ask me what to do next. It already knew.
The hooks caught it. format-check.sh had already auto-fixed the formatting. test-related.sh had run the related tests async, and they passed. The plan I'd written before the session had constrained the solution space enough that Claude's refactor, while broader than I'd pictured, was within the boundaries of what I'd already decided. I exhaled. Shoulders came back down. I leaned back in my chair and just… watched the next operation run.
Each session after that added data. I wasn't hoping this would work — I was watching it work, observing the patterns, learning what Claude does when I'm not intervening. And it was predictable. Not because Claude is inherently predictable, but because the system I'd built around it made it so. The conventions were encoded. The tests ran automatically. The plan had already narrowed the field. There just wasn't that much room for surprise.
the flag stays on
This is how I work now. For work where I've made extensive plans, already asked the clarifying questions, already broken it down into spec-driven features — I learned to let go.
It happened gradually over the week. At first I kept checking diffs after every few operations. Then I started checking at natural breakpoints — after a commit, after a feature boundary. Then I stopped thinking about it. The project contract defines the conventions. The rules encode the patterns. The plans constrain the direction. Claude is an extension of decisions I already made. There's a point where monitoring becomes redundant, when the intentions are shared because they're your intentions, written down, loaded into the system. I didn't plan to reach that point this week. But by Thursday, I was there.
"i just let go"
Something Drew said in a vibe coding session came back to me, with a chuckle: "I just let go. Because I've asked Claude a ton of clarifying questions already for the plan, what can possibly go wrong?"
Drew is our director at Lytics, a Customer Data Platform. I'd only known him before the acquisition as our chief data scientist — someone whose rigor I trusted implicitly in that domain. Post-acquisition, when it comes to anything CDP, he wears every hat: sales, architect, data scientist, strategist. When someone operating across that many surfaces says "I just let go," it carries a specific weight. He's not being casual about risk. He's being precise about where risk actually lives. He's looked at it from every angle and concluded that the plan already accounts for what matters. The chuckle is the sound of earned confidence.
That line landed quite differently after this week.
The plan is the permission. That's the insight I keep returning to. When the upstream thinking is comprehensive (when you've asked the hard questions, made the decisions, documented the constraints), the downstream execution doesn't need a human checkpoint every thirty seconds. The plan already did the work that the permission prompt was trying to do: ensure that what happens next is intentional. This is where "Planning as Leverage" was always heading. I wrote that piece about decisions happening before execution begins, about plans decreasing cognitive tax, about the flow state that opens up when direction is already clear. I didn't realize at the time that the logical endpoint was this: if the plan constrains the solution space, and the rules encode the conventions, and the hooks enforce the standards, then the permission prompt is the last piece of manual overhead in an otherwise automated system.
Drew saw it from the planning side. I arrived at it from the tooling side. Same destination.
a year of building the muscle
This didn't happen overnight. I've been experimenting with AI-assisted development for about a year now, and the early sessions were humbling. Vague prompts produced vague output. I'd course-correct constantly, burning attention on things that should have been decided before the session started. The muscle memory built slowly: how to write intent clearly, how to structure context so the model has what it needs, how to separate what Claude needs to know always from what it needs to know sometimes.
In October 2025, during my first hackathon at Lytics, I picked up GitHub's spec-kit. It had just been released a couple months earlier, and the general shape (constitution, specify, plan, implement) resonated. It gave me the vocabulary for something I'd been reaching toward: intent-first, spec-driven development. What I actually built from there went its own direction, but the idea that specs could be generative rather than just documentary — that stuck.
Then came the stretch where the lessons started compounding. 10 Days of Vibe Coding taught me that context is the whole thing, that the quality of the input is the single biggest determinant of the output. Running Out of Context was the infrastructure insight: constraints stay loaded, procedures load on demand, and the difference between hot and cold context is where most of the real weight lives. Planning as Leverage was the process insight: the plan is where the real work happens, and everything downstream is execution against decisions already made. Each post captured a lesson. Each lesson became infrastructure — a rule, a hook, a skill, a convention. The infrastructure compounded. This week, the compound interest paid out.
what makes this possible
I'm not going to lay out the full blueprint (honestly, it shifts every week). But I want to be concrete enough that this doesn't read as "just trust the vibes."
It starts with a project contract, concise and always loaded, that tells Claude the stack, the conventions, the build order, the capability roadmap. It's the first thing Claude reads in every session. From there, path-scoped rules kick in depending on where Claude is working. Domain layer gets domain conventions. Tests get testing patterns. UI gets component conventions. Surgical, not sprawling: about 130 lines total, split across six files that only fire in the right context.
But the piece that matters most for this story is the hooks. After every file edit, regardless of permission mode, two things happen automatically: formatting gets auto-fixed, and related tests run. These aren't opt-in. They're structural. They work whether I'm watching or not, whether I'm approving operations or not. They're the feedback loop that makes autonomous execution safe, and they're the reason I could check the git diff on Thursday and find everything in order. On top of that, there are on-demand skills for specialized workflows (adding a new integration tool, auditing documentation, scaffolding a feature) that load cold, keeping the always-on footprint lean.
And then there's the pipeline. An idea starts as a numbered plan, scoped with explicit boundaries and a technical approach. Before Claude Code touches a line of implementation, that plan gets broken down into a feature structure: a PRD, an implementation plan with commit-level sequencing, a technical spec with type contracts and edge cases. The thinking happens there. The decisions get made there. By the time Claude runs, it's executing against a solution space that's already been constrained through rounds of human judgment.
The flag works because the thinking already happened. The system catches what the thinking missed.
what it feels like now
There's a session from this week I keep thinking about. I was building out a canvas feature — drag-and-drop uploads, AI-enriched cards, a chat sidebar grounded in the board's content. The implementation plan had twelve commits mapped out. I loaded the plan, gave Claude the first directive, and let it run.
For the next forty minutes, I didn't touch a permission dialog. I watched the work happen. When I had a thought about the approach, I typed it. When Claude finished a phase, I reviewed the output. The hooks ran in the background. Tests passed. Formatting stayed clean. And I found myself thinking about the product, about whether the card layout communicated the right hierarchy, about whether the chat grounding felt natural, instead of thinking about whether to approve a file write. It's a different kind of attention. Quieter. More sustained. The kind where you forget you're in a chair until you stand up and realize an hour passed.
I ended that session with more energy than I started with. That's new. The long sessions used to drain me, even productive ones, because the constant micro-decisions (approve, deny, approve, read the prompt, approve, wait did I read that one) are withdrawals from the same attention account as the actual work. Remove those withdrawals and the account lasts longer. The quality of the output didn't change. But the experience of producing it… that changed quite a bit.
closing thought
The flag is named to make you hesitate. I think that's the right design. The hesitation is useful — it forces you to ask whether your system is ready. Whether the plans are comprehensive enough, the rules scoped tightly enough, the hooks reliable enough. If the answer is no, the hesitation protects you. If the answer is yes, the hesitation is the last thing standing between you and the work.
Drew said it with a chuckle. I typed it with a flinch. The product of Drew's Claude session, my teammates' sessions, and mine look nothing alike — shaped by our own biases, experiences, and depth of understanding of the domain each plan was meant to tackle. Whether someone is confident enough to touch the flag, and what it unlocks when they do… that's personal.