DEV Community

Bryan Dorsey
Bryan Dorsey

Posted on

Never stop cookin'

By Bryan Dorsey

I've got a groove going. Claude Code and I are dialed in, deep in something good, hours of context stacked between us. I can't stop now. But I know the dreaded compacting conversation is coming, and starting a new work session feels like losing everything we built.

What do I do?

Here's what took me a while to see: the groove was never in the work session. It's in me, and in the notes I leave behind. The session is only where the work happens, not where the flow lives.

The wave

Most work sessions end like most waves, rolling in strong and flopping onto the sand. Mine doesn't. My wave never stops. I can open a new work session with confidence and intention and drop right back in where I was riding it before. Even three days later, my board is propped up exactly where I left it, ready to hang ten. That flow shows up every single time.

Full circle

Over 20+ years I've worked alongside developers, designers, producers, product managers, owners, key stakeholders, researchers, and writers. Working with each one taught me what a great version of that role looks like, how a strong developer thinks through a problem, what a sharp researcher asks, how a good writer cuts a sentence down.

Working with humans has a real limit, though, and it isn't skill. It's investment. When someone isn't as invested in the work as you are, asking for a fourth revision starts to cost something. You start softening the ask. You apologize before you make it. You tell yourself the fifth round isn't worth the friction, and the work stops short of where it should have landed.

That limit is gone with Claude. I define the exact role I need, built from the best of everyone I've worked with, and I iterate as long as the work needs. No apologizing, no rationing the asks, no stopping early because I've used up someone's goodwill. Claude is ready whenever I need it, as much as I need it, and as late as I need it.

A way of thinking, systemized, and it works for me session after session, like a Top Chef pulling a cohesive menu together night after night.


Table of contents


Mise en place: make the implicit explicit

When Claude misses, it's easy to lose your cool and start barking like an angry chef, which only confuses him more. Every round of that eats the context I'm fighting to keep. Say what you mean the first time and the wave lasts longer.

Working the pizza station, be a pizza expert (role), this pie, not the others (location), start with the dough, then the sauce (order), and it's going to a VIP (intent). Spell it out and Claude stops guessing.

Claude guessing wrong costs a rebuild, a re-explanation, or three rounds of back and forth.

Five things up front, and the work comes back closer to done.

Role (the hat):

Rehat when you cross into a new discipline, and the sharper the hat the better the fit. An expert in Harry Dry writing is not a UI masonry expert, and neither one writes your TypeScript. Different work, different specialist.

Location (of the change):

Name the exact spot (in the code, in the UI, in a sentence). "That's not accurate" with no location costs multiple rounds. Naming it cuts that to one.

Order:

Let Claude know what to do first through last, and flag any potential blockers.

Intent:

Thinking out loud and instructing look identical from the outside. I tag which one is in play: still iterating or ship it.

Verify:

Read the actual code or file and confirm against memory before showing me. Never go from memory alone. Taught once, then it's a single word: "verify."

Bonus, ask for succinct:

When you're iterating fast, tell Claude to be succinct up front. Saves you digging for the answer in a wall of text.

Bonus, how I keep from losing my cool:

I talk to Claude like a child. You're going to be a good kiddo today (role), go play with all your friends nicely on the monkey bars (location), if you're not sure about something, ask before you do it (verify), remember to have fun, this is playtime (intent), and after playtime we'll go get ice cream (order).


Claude Code work sessions

A clean station is a chef's first rule. Never start service on top of last night's mess. The loop, swoop, and pull 🪢 moves the whole project to a fresh session, clean every time.

I never /clear or /compact. I never wipe a station. I build a fresh one and leave the old exactly as it was, so I can look back and remember the hell we climbed out of.

A clean station

Lit by my Android, deep in a project, and it hits me it's time for a fresh session. It's been a day, maybe a day and a half, and the current one is getting full.

The loop is the hard part: deciding to stop. You don't want to lose momentum. A simple "update the MD docs" completes the loop. I keep three primary docs, Claude MD, current-context, and the handoff, with everything else in an archive folder, and my Claude MD tells the project that's what those words mean.

I don't just do it at the end, either. I often ask for an update once or twice mid-session, usually right after we land something good, so if a compaction hits or I forget to make a handoff in the zone, the docs are already current from that point.

Current-context holds the present moment of the project (the barrel of the wave), ready to pick up and run with. The handoff goes in the handoffs folder, which keeps every past one so the next session can look back, what's done, what's left, what to watch for.

The swoop is spinning up a fresh Claude session and naming it right. Iterating is easier on my phone, but a new session is faster to start on the laptop, so I move from my phone to my desktop. New terminal, cd into the repo, run Claude, /remote-control, /rename to the next number up, same naming convention every time.

The pull ties it off. I ask the new session to read the current docs, get familiar with the older ones so it can find them later, read the code. Then I ask it to prove it read everything by telling me one interesting thing about the project, TLDR so it doesn't talk my ear off. It always comes back with something worth reading, and the wave is right where I left off.

The last step is archiving the previous session, left exactly as it was, there if I need it.


Working with Claude Code/remote

It works on one condition: my terminal session has to be running and my laptop awake at home. That's the leash. The laptop holds the wave, my phone reaches in. When I figured out remote control, it was on. I've been spotted coding from the announcer's tower at the motocross races during track maintenance.

Pros: screenshots and images attach in a tap, talking to it feels as natural as voice-to-text with a friend, and I can jump between projects while one is still working.

Cons: viewport testing is hard without my workstation, where the laptop, Studio Display, and Claude driving Chrome let me test live across sizes.

My fix: I built a viewport simulator. Pick the display size, laptop, desktop, studio, 4K, and see exactly how it renders right on my phone.

As of this writing there's a bug in the Android app that tricks you into thinking your input is queued when it isn't, so you lose the thought mid-flight. I found a workaround, a pain but better than losing my thinking.


Run Claude like a brigade kitchen

Claude is your team, not your tool. Manage him like one.

Picture a brigade kitchen. You're the chef. Claude is your sous chef, your number one. Every station is a different project (work session) running at the same time, one on the sauté, one on the pass, one baking, all going at once. Your job isn't to cook every dish. It's to keep the whole kitchen moving as one.

A chef needs two things from a kitchen like this. Every station has to cook to the same standard, no matter what they're making. And every station has to call out where they are, so you always know the state of the whole line without walking to each one.

Those two needs are the whole system. Keeping every station to one standard is Overwatch. Hearing where each one is at is Dispatch.

The line

A flow diagram showing core values feeding rules down into three projects, Overwatch checking them for drift, and each reporting its status up to Dispatch.

Overwatch: the pass

Nothing gets served unless it's up to standard. Overwatch stands above every project and compares them to each other. It catches the one that drifted, the one cooking with ingredients the kitchen doesn't stock, misalignments I'd never have caught without the other projects to compare against. That's the visibility I never had before. Now I catch it and fix it right away.

I check in and ask it to report back on how all the projects look today. It knows my structure: the Claude MD, current context, and handoff setup, the tagging system (a hidden one-line comment in each project's Claude MD that marks it as a live project), which projects report into Dispatch and which ones went quiet. It finds what I can't see from inside any single project and brings it back to me: a missing tag, a project not yet wired into Dispatch, a repo letting stray MD files pile up in root instead of tucking them into archive. It recommends, I decide. Nothing changes in a project unless I say so, because they're my projects, not Overwatch's.


Dispatch: "Yes, Chef"

Ask once, the whole line answers.

Dispatch holds one line per project: date, where things left off, what's next, a status flag. Every project overwrites its line on commit. Instead of opening ten repos to ask each where it stands, I ask Dispatch once and it answers for all of them.


Terminally honest

With so many years designing in WYSIWYG, the terminal was never part of my world. That's changed fast. The hardest part is getting over the fear of opening it, worried you'll break something with a command you don't know. But you only need a handful to get up and running and start feeling like you know what you're doing. Every week you learn a new command, a new mode, you make a new mistake, and you get better. Learning the syntax is like learning a new language, and that's exactly what's happening.


Think backwards

Most people pitch to get the work approved. I build first, so the work becomes the pitch, and the whole team sees the same future I see.


Design Director (Growth) + AI-native product builder · bryandorsey.com

Top comments (0)