Claude Chat, Claude Code, and Me
The Rocinante
I got tired of saying “Claude Chat” and “Claude Code.”
Not conceptually. Literally. I use Wispr Flow to dictate to my AI tools, and neither name comes through clean. The words fight the transcription. It’s a small thing. But small friction compounds.
So I gave them names.
That’s how something really fun and useful got started. Not a strategy. Not an architecture. A crew.
I’ve always had an affinity for sci-fi, and lately I’ve been using names from some of my favorite sci-fi series. It’s not aesthetic. It’s functional. Names carry personality, and personality tells you what a thing is supposed to do. When you pick the right name, you stop having to explain the role.
The first name I chose was Amos.
If you’ve watched The Expanse, you know Amos Burton. Big. Direct. No-nonsense. No performance. He does what needs doing and he doesn’t editorialize about it. I wanted my AI chat to talk to me the same way. Direct, warm when it needed to be, but never soft. Never flattering. So I called it Amos, and I configured it that way, and something about the name made the configuration stick.
Amos was the brainstorm chat. Somewhere to think out loud.
A quick note for the non-engineers in the room. We’re going to talk about building software. But stay with me. The problem I’m solving isn’t really a software problem. It’s a coordination problem. Information scattered across tools. Context evaporating between sessions. You playing messenger between systems. That shows up everywhere: marketing, sales, ops, finance, legal. Any knowledge work where you’re managing complexity across more than one tool. This is for you too.
Explaining the same context over and over, chat after chat, was getting old. I decided to use GitHub to solve it and set up the GitHub MCP connector so Claude could talk to it directly. A GitHub repository is just a place where files live. Code, documentation, notes, all of it in one place, versioned, shared. Now my chat session could read and write to that repo from inside the conversation. No copy-paste. No switching windows.
The idea was simple at first. If all my chat sessions read from the same repository, they’d all start with the same information. No more re-explaining context from scratch. One source of truth. Every chat boots from the same state.
I took it one step further. Each Claude project got instructions that point to a repo. The operating rules, the context, the instructions, all of it lives there. Every session starts by reading the repo. Every AI tool reads the same instructions. Nothing has to be re-explained because nothing lives in the session. The session is temporary. The repo is permanent.
Claude Code is a different animal entirely. Where Claude Chat thinks and talks, Claude Code acts. It works on files, runs code, pushes changes to GitHub. It’s not a conversation. It’s a builder. And it could read from the same repo.
None of these tools were new. They were already there. The insight was figuring out how they fit together.
This is when I realized I was building a ship and I needed a crew. Funny thing. Spaceships were my favorite thing to build with Lego bricks as a kid. Some things don’t change.
The next crew member was Naomi Nagata.
Naomi is the ship’s engineer, literally. In the show she builds what the others can’t. Technically brilliant, methodical, gets things done under pressure. That mapped perfectly to Claude Code, the layer that actually builds things. So I stopped saying “Claude Code” and started saying Naomi.
She doesn’t decide why, when, or what to build. She figures out how and then does it.
I was still the go-between though. Chat said this, Naomi needed that. Every handoff passed through me. Having Amos write up information that I would cut and paste over to her. Better names, same problem.
GitHub also has a feature called Issues. Think of them as work orders, a way to assign a specific task, track the work, and log what happened when it’s done. Now I was having Amos write tickets directly to GitHub, and then I’d ask Naomi to go work them. No more cut and paste. Just simple instructions.
The friction went down. Not gone, but down. I didn’t have to carry as much anymore.
The new workflow: “Naomi, please go work issue 42 in the story-workshop repo.” That’s it. Later I come back, the chat reads what she logged, and tells me what happened.
Amos was good. Really good. But he couldn’t see the big picture. By design, he was handling independent pieces, helping think things through, giving Naomi work to do. He wasn’t built to coordinate. Something was missing. A coordinator. A strategist. The captain.
That crew member was Captain James Holden.
Holden is the one who sees the whole situation in The Expanse, decides what matters, and gives the orders. He thinks. He dispatches. He doesn’t execute. I called that chat Holden, configured it accordingly, and the coordinator emerged. Amos is still around. I still use him for one-off brainstorming, thinking out loud, working through ideas that don’t have a home yet. But Holden holds the full picture, plans the next move, and routes everything to the right place. The central hub.
The crew was taking shape. But I kept noticing a gap. Even smart people need a second set of eyes, someone who wasn’t in the room when the work was done. Same is true for AI. The model that built something can’t fully audit it. I needed an independent reviewer. An observer. Someone to keep us on course.
That crew member was Alex Kamal.
Alex is ChatGPT. In The Expanse, Alex is the pilot: steady, precise, the one keeping the whole thing from flying apart when everyone else is deep in the problem. In my system he’s the external check. Before anything significant gets marked done, Alex does a genuine review pass from the outside.
He’s not there to agree. He’s there to find what Holden missed.
Later I added Fred Johnson. Fred runs Tycho Station in the show, the largest mobile construction platform in the Sol system, a massive shipyard. I named my Mac mini Tycho Station, and Fred is the AI agent running on it. Persistent process, his own tools, his own connection back to everything else.
That’s a story for another time.
I know this all sounds complicated. Here’s what I hope you take from it.
If you’re building software, managing a sales pipeline, running ops, or doing any kind of knowledge work across more than one tool, the coordination problem is the same. You’re re-explaining context every time. You’re copying and pasting between sessions like it’s 2019.
The ship is constructed of modules. Lego bricks. A shared surface that all the tools can read, a naming system that forces role clarity, a dispatch pattern that keeps me out of the middle. The bricks exist. You probably already have most of them.
Start small. Give your tools names. Not because it’s cute. Because names carry behavioral contracts, and behavioral contracts are what turn a pile of tools into something that actually works together. Then look for places to eliminate friction.
The system isn’t the tools. It’s the ship.
In The Expanse, the crew’s ship is the Rocinante. The Roci, as she’s affectionately known. She’s always getting retrofits and upgrades.
My system is already different from what I’ve written here. Smarter. Tighter. One of the crew has been reconfigured. A new one is being sketched. The whole thing keeps evolving faster than I can write about it.
What’s the name of your ship? What upgrades are you putting in?
One of my favorite scenes from The Expanse is when a man promises Amos their bloody confrontation is coming. Cool, calm, and direct as always, he responds:
“How about now? I’m free right now.” — Amos Burton
No time like the present. The Lego bricks are waiting to be assembled.
Uncomplicated systems. Uncommon results.