I was driving a Claude Code planning session in front of my product engineering team — deep in a multi-sprint RBAC initiative, granular roles, permission enforcement across the UI, the kind of project that touches everything. I'd been shipping components, fixing edge cases, building momentum. The room had that charged feeling you get when a team is watching someone work in real time, half curious and half waiting to see where the cracks are. I thought I was close to done.
My manager, Mark, asked me a simple question: "Do you have a plan for closing the gap?"
I said what felt honest in the moment: "Well, I have concepts of a plan."
I laughed. The team laughed. But the truth behind that joke stuck with me long after the call ended. I did have a plan — I'd been working from one the whole time. But it lived mostly in my head, scattered across tickets and Slack threads and half-finished conversations. It wasn't something the team could point at and say, "This is where we're going, here's the remaining gap, and here's how we'll close it." So we did something we hadn't done before: we built the high-level plan together, right there in that session. And that small shift — from a plan I held to a plan we could all see — turned out to be the thing that changed how I think about the work.
the real currency
This happened in early February, 2026. Into the new year, our team had been getting quite a bit more productive, and AI tooling was accelerating everyone's output. The result was an explosion of pull requests — more code moving faster than ever, which sounds like a good problem to have until you feel the friction underneath. There was this low-grade drag in the workflow, something we all sensed but hadn't named yet. Reviews were backing up. Decisions that should've been made two weeks earlier were surfacing in PR comments. People were building in slightly different directions, not because they disagreed, but because nobody had written down the shared picture clearly enough to disagree with.
Planning turned out to be where we started. That conversation with Mark made something click — the gap wasn't in execution. It was in clarity.
And really… this is about attention. Attention is the most precious currency an engineer has. Every micro-decision during execution — "should this be a hook or a component?", "what's the naming convention here?", "does this match the pattern we used last time?" — is a withdrawal from a finite account. I know this feeling in my body: a day full of those micro-decisions leaves me drained at 4 PM, shoulders tight, staring at a screen without really seeing it, even if I shipped quite a lot of code. I was spending attention on things that should have already been decided. A well-thought-out plan saves downstream iterations, yes. But more importantly, it decreases the cognitive tax on the work that matters. When the decisions are already made, execution becomes focused. I can put my attention on craft instead of constantly re-evaluating direction.
three levels of planning
What emerged from that session — and the weeks that followed — was three layers, each preserving attention in a different way.
Team plans capture the full scope of an initiative: remaining work, dependencies, what "done" looks like. For the RBAC effort, we jumped on a call, the whole engineering team, and used Claude Code as a shared thinking partner to build the initiative-level plan. The process of articulating it together forced everyone to get precise — and honestly, a little uncomfortable. What are the remaining components? What are the dependencies between them? What does "done" actually look like? (That last question always sounds simple until you try to answer it in a room full of engineers.) Claude asked the questions we'd been deferring. People challenged assumptions out loud instead of silently disagreeing in a PR comment two weeks later. The result was a living document we could share across engineering and product. When someone asks "where are we on RBAC?" the answer is a link, not a meeting.
The traditional cycle feels a bit backwards once you've experienced the alternative. A ticket gets written, an engineer disappears for a few days, code review happens. But review is too late for directional decisions — by that point, the cost of a fundamentally different approach is high, so teams default to marginal feedback. The team plan moves that conversation to the cheapest possible moment.
Personal plans are where I clarify my own thinking. These happen in a Claude Code session, just me and my intent, usually first thing in the morning with coffee before the Slack notifications start pulling at my attention. What am I actually trying to build? What's the right approach? What are the tradeoffs I haven't thought through? These plans might never leave my terminal. Their value is the clarity they produce in my head — the feeling of sitting down to write code and already knowing where I'm going. They're how I meet execution before I start executing.
This is also where AI changed my work most fundamentally. The better I can articulate what I want to build, the better the output. Vague prompts produce vague code. Precise intent produces precise implementations. The quality of the upstream thinking became the single biggest determinant of the downstream result. And the artifact of that thinking… turned out to be a plan.
Implementation plans are the detailed, reviewable artifacts: APIs, usage examples, test strategies, verification checklists. These get submitted as pull requests and reviewed by engineers before anyone writes a line of code. When it was time to build the RBAC permission enforcement components, instead of jumping straight to implementation, we produced an implementation plan collaboratively.
A fragment of what that looked like:
// Extends MUI's ButtonProps with access control
interface ProtectedButtonProps<C extends React.ElementType = "button">
extends ButtonProps<C, { component?: C }> {
hasAccess?: AccessPredicate;
accessDeniedTooltip?: ReactNode | null;
}
That's the actual TypeScript interface, decided before implementation begins. The plan went further: seven usage examples per component, implementation notes referencing MUI documentation, test cases enumerated by name, and a deliberate implementation order with rationale. The conversation on the PR was exactly what I wanted — the right questions at the right time: "Should the default behavior be hide or disable?" "Do we need the children escape hatch on NoAccessMessage?" "Is the polymorphism pattern worth the type complexity?" Those are the kinds of questions that, if they surface during code review, feel expensive. In a plan review, they feel like the whole point.
What all three levels share is that decisions happen before execution begins, so that execution can happen with full attention on the work itself.
guardrails and trust
The plan is where decisions get made. But decisions don't enforce themselves.
I built a layered system of guardrails around Claude Code: context documents for codebase orientation, rules that are always loaded, skills for on-demand patterns, and formatting hooks so we're not spending attention on style. They hold the standards so I don't have to hold them in my head (which, given how much I'm already holding, is no small thing). When I hand a reviewed plan to Claude for execution within that system, the plan constrains the solution space and the guardrails enforce the standards. My attention stays on whether the output matches my vision — the thing only a human can evaluate.
I wrote about this infrastructure in detail in "Running Out of Context". The short version: guardrails are attention-preservation infrastructure. They make the plan-to-execution handoff trustworthy.
the compounding loop
When execution reveals a gap — the output doesn't match my vision, a pattern doesn't work as expected, a decision I didn't make upstream creates friction downstream — I don't just fix the code. I improve the plan-generation process itself.
When we designed the ProtectedButton component and discovered that MUI's tooltip-on-disabled-element pattern required a specific span wrapper technique, that became a documented skill. The next plan that involves tooltips on disabled elements doesn't need to rediscover that constraint. It's already in the system. What starts as planning becomes a knowledge-capture surface — execution failures feed back into system improvements. Each cycle preserves more attention for the next one.
And there's a quieter effect underneath all of this that I keep coming back to. When I sit down to build and the decisions are already made — by me, yesterday, in a planning session — the work feels different. There's a specific kind of ease that's only possible when I'm not constantly context-switching between "what should I build?" and "how should I build it?" The plan clears the path. The guardrails hold the edges. My attention goes to the craft. I end the day less drained — shoulders looser, still curious about the problem at 5 PM instead of just wanting to close my laptop. That might sound small. But over weeks, it changes what kind of engineer I am.
open edges
I used to have concepts of a plan. Now the plan is where the real work happens.
But I'm still figuring out where the edges are. Some work resists planning — exploratory prototyping, debugging something nobody understands yet, the kind of problem where the solution only reveals itself through contact with the code. I've caught myself writing plans that were too thick for the work, where the planning session itself became the bottleneck (and I could feel it happening in real time… that restless energy of wanting to just start already). There's a weight threshold I don't have a formula for yet: too thin and execution wanders, too thick and the plan becomes its own project.
I also don't know how this scales beyond our team size. We're small enough that everyone can be in the room for a team plan. What happens when that stops being true? Do plans become artifacts that communicate across groups the way code review does now? Or does something else emerge?
What I do know is that the real shift was in where the work lives — upstream, in decisions, before anyone writes a line of code. That's where we started. I think it's where most teams will.
Our team uses Claude Code for both planning and execution. The sample implementation plan referenced in this article was derived from the collaborative team plan on remaining RBAC work. The full plan is available here for reference.