Coding with Claude Code: Almost a Month In

I’ve been at this for almost a month now, and I genuinely can’t stop. Nearly 800 commits in using Claude Code. That number surprised me when I looked at it. There’s something about the way this tool fits into how I think and work that just clicks, and I keep finding new ways to push it further. This post is my attempt to articulate what that’s actually been like: the good parts, the weird parts, and the rabbit holes I’ve gone down trying to make it smarter.

What Is It Like Working with Claude Code?

Getting Started

The onboarding story is deceptively simple. You install Claude Code, point it at a project, and start talking. I started out using the homebrew cask as the install and got up and running really fast. The first few sessions feel almost like magic, you can describe what you want and it will build you a webapp. That is really cool, and neat, but the thing wouldn’t scale in the real world. You can keep building iteratively. With context.

Now, you can do much of the same things with your AI of choice, and we can talk a bit more in future posts as I play more with Codex, and Gemini. I have used all three in the CLI, and using their clients. They all seem to have their strengths and weaknesses.

If you’re coming from Copilot or the Claude/ChatGPT/Gemini chat interface, the jump in capability is immediately obvious. This is an agent that can read your whole project, propose a plan, execute across multiple files, run tests, check the output, write up documentation and loop. It’s not a better autocomplete — it’s a different category of tool entirely.

Using It in the Command Line

Claude Code lives in the terminal, and that’s where most of my workflow happened over the month, but recently has shifted — we will get into that in a bit. You open a session with claude in your project directory, and from there you’re in a conversational loop that can shell out to your environment, read files, run commands, and return results. The slash commands (like /memory, /clear, and /cost) give you control over the session state without breaking your flow.

You don’t have to have anything setup, it will do what you need to do if you ask it. As a fun thing, I uninstalled everything (other than Claude) from Homebrew. Just to force it to do installs. I told Claude that I prefer homebrew as a package manager over NPM. We started out talking about creating a new project, and building it out. It built me a quick web interface and installed the components we wanted to use. It built the app in Next.JS along with a PostgreSQL database. (One note, it used PostgreSQL 16 for some reason.. I have since updated). It continued to install other tools as we needed them like the gcloud CLI and the github CLI.

What I’ve found is that the command-line interface rewards the same instincts that make well built requirements for engineers to deliver good products: be specific, think in systems and enterprise/scale, give more context to get better results. Vague prompts get shitty results. Detailed, well-scoped prompts with clear success criteria get genuinely impressive ones.

Eventually, you start talking to the ai to make prompts, and then you decide to have it make full blown product requirements documents(PRD), which you can then feed into the prompt to build things out. After we bootstrap it and get a MVP setup locally, I then go through the work to get it setup with a repo at Github, actions to deploy it GCP. Once it is setup, we take the PRD and run a version of the /eng-plan-review skill that I created as a PAI skill that was inspired by Garry Tan’s gstack as an inspiration to build out github issues that we can work on. I created a template for that too to make sure claude remembers what to do with a checklist to build the tests. (I found that since I am not using office hours and the ceo skill that the whole package is a bit too heavy for me).

The Problem with Agents: 50 First Dates

Here’s the thing nobody tells you upfront: every new session, the agent wakes up with no memory of who you are.

I kept thinking about Drew Barrymore in 50 First Dates — every morning she resets, and the people who love her have to re-explain the whole relationship from scratch. That’s Claude Code without any scaffolding. It’s powerful session to session, but it doesn’t know your project history, your preferences, your patterns, or what you decided two weeks ago and why. You’re constantly re-establishing context that you already established.

And a lot of that context is machine specific if you use the default as you build out the scaffolding. Before looking for a memory architecture — since I was using two computers, my desktop and my laptop — I was syncing a repo-based CLAUDE.md.

For one-off tasks, that’s fine. But I was losing things between machines that weren’t making it into the repo claude.md. For sustained development work across days and weeks, it’s a real issue. So then I started looking around on how to solve it.

Implementing PAI: Personal AI Infrastructure

The answer I landed on was PAI — Personal AI Infrastructure, an open-source framework by Daniel Miessler that sits on top of Claude Code and gives it the memory, personality, and structure it’s missing out of the box.

The mental model Miessler uses is helpful: Claude Code is the engine. PAI is everything else that makes it your car.

The Structure of PAI: 7 Phases

The core of PAI is what it calls The Algorithm — a 7-phase execution process that every task runs through. Rather than just firing off an answer, the agent works through a structured scientific method:

1. Observe — Gather what’s actually in front of it. Read the files, understand the state of the project, don’t assume.
2. Think — Reason through the problem space before doing anything. What are the constraints? What are the edge cases?
3. Plan — Decompose the task into discrete, verifiable criteria — what Miessler calls Ideal State Criteria (ISC). You can’t mark something done without evidence.
4. Build — Assemble the approach, select the right tools and agents.
5. Execute — Do the actual work, with the plan grounding the execution.
6. Verify — Check against the ISC. Did this actually meet the criteria? Not “does it seem like it did?” but verifiably.
7. Learn — Capture what happened. Update memory. Feed the signal back into the system.

This loop is what turns Claude Code from a smart tool into something that actually compounds. Each session builds on the last, instead of starting from zero.

Mine Is Named Spock

I’ve customized my PAI setup and named my Digital Assistant Spock. It felt right — precise, systematic, a little formal, but quietly indispensable. The personality system in PAI lets you quantify traits on a 0-100 scale, so Spock runs high on precision and analytical rigor, lower on unnecessary chattiness. It shapes how every response feels and how it approaches ambiguity.

I also had it review information about Star Trek TOS and model how it speaks. Lastly, I added the stardate (TNG version) to my PAI prompt. Just for funzies! I really didn’t know what to call it, but I was wearing my “red shirt” (a T-shirt that makes a joke about the fact I am wearing red and I might not make it).

As another improvement, I created a work and memory repo for Spock to write out his memories and in-progress work to. I also created two custom skills:

• /pai-load-remote — Pulls the repo and loads the most recent context from Spock’s memory at the start of a session.
• /pai-end-session — Writes memory out to the git repo, commits, and pushes at the end of one.

This solved the multi-machine problem. Both machines pull from the same remote memory, so Spock always knows where we left off regardless of which computer I’m on.

Voice Prompts

One of the more surprising things I’ve set up is voice input and output. PAI supports Google Cloud TTS integration, and I’ve wired up voice prompts so I can talk to Spock when I’m heads-down and don’t want to break flow by typing. It sounds like a novelty, but in practice it’s genuinely useful when you’re working through a problem and thinking out loud is faster than typing. I’ll dictate the next direction while I’m still reviewing the last output.

The other side is that I set up ElevenLabs for text-to-speech so it could talk back. I used Brian, because I couldn’t find a free or paid voice that was Leonard Nimoy.

Optimizing Model Usage

Here’s where I’ve gotten a little obsessive about efficiency. PAI’s memory and hook system let you configure which model gets used for which type of task. My current setup:

• Opus for thinking, planning, architecture and high-end coding work that crosses projects or crosses many files in the same project. Also using it for chats to build out Project Requirement documents. The main PAI session runs here.
• Sonnet for the sub-agents doing actual coding work — less complex reasoning, code generation.
• Haiku for documentation, scanning tasks, summarization, and lower-stakes reads.

This matters because you can burn through context fast if everything escalates to the most expensive model. Treating model selection like resource allocation — routing appropriately based on task complexity — keeps costs sane and keeps the throughput high.

Challenges with SSH

I won’t pretend everything has been smooth. SSH has been a consistent pain point that I haven’t fully solved yet.

The core issue is that Claude Code is fundamentally designed around a local terminal session with direct filesystem access. The way it manages context, hooks, and the PAI scaffolding all assumes it’s running where your files are. When you introduce SSH into that — connecting to a remote dev environment, a cloud VM, whatever — the session behavior gets unpredictable. Context doesn’t always flow the way you expect. The terminal state gets confused. Sometimes permissions prompts fire when you’re not watching and the whole thing stalls.

I suspect part of it is a PAI interaction specifically. The hooks and memory system are built assuming local operation, and that assumption breaks down over SSH in ways that are annoying to debug. My current workaround is just not doing it — I’ve kept my workflow local and used the remote memory repo (via /pai-load-remote) to stay in sync across machines rather than trying to run Claude Code on a remote host. It works, but it’s a constraint I’d like to eventually remove. It’s on the backlog.

I also really want to be able to use the claude client for iPadOS to manage things on my desktop from anywhere. They already have this concept with the compute you can use that claude hosts, but it isn’t quite the same as being able to interact with my desktop from anywhere. That is what lead me down the SSH rathole, and I thought the issues were just with terminus, but it turns out I have the same problem from my laptop so it is genuinely some other problem.

Moving to the Client

More recently I’ve been using the Claude for Mac desktop client, and it’s changed the workflow meaningfully with its recent releases. I found the code component in it pretty lacking previously — I wanted something more like an IDE, closer to Cursor or Antigravity. But a recent release changed that perspective for me.

Basic Features

The client gives you visibility that the command-line interface can’t easily surface. You can watch sub-agents spawn and work in parallel — actually see the orchestration happening, not just infer it from terminal output. There’s a plan view that makes The Algorithm’s phases legible. And there’s a terminal pane built in, so you still have that direct access without switching windows.

It’s a richer working environment. The TUI (Terminal UI) is powerful but opaque; the client makes what the agent is doing more observable.

Basic Navigation

A few things that are worth knowing out of the gate:

• Local folder selection is straightforward — you point it at a directory and it treats that as the project root.
• Git integration is native, so you can see diffs, understand what changed, and the agent’s commits are visible in your normal git history.
• CI integration means you can get feedback from your pipelines without leaving the environment. It natively integrated with GitHub Actions for me.

PAI Still Works

This was the thing I was surprised about: my PAI setup — Spock, the model routing, the memory structure — still works in the desktop client. Everything installed under ~/.claude is still picked up. The client doesn’t replace the PAI scaffolding; it just gives you a better window into it. I can even call my skills to sync and pull the remote context right from inside the client.

So, What’s the Backlog?

After almost a month and ~800 commits, here’s where I’m still itching:

SSH is the biggest open item. Solving it cleanly would eliminate the last real friction in my multi-machine workflow. Right now the remote memory repo bridges the gap, but I’d rather have a real solution than a workaround.

A native client/server model for Claude Code is something I’d love to see exist. Right now if you try to use remote control in a session it gets wonky — especially if it hits a permission prompt while you’re not watching. I want the agent running persistently on my desktop as a server, accessible from wherever I am, without the session management headaches. That probably sounds like OpenClaw, but I’d want it natively in Claude Code.

Deeper CI integration — the current setup is reactive. I’d like Spock to surface failures proactively, not wait for me to ask.

Local model experimentation — I’m starting to play around with Gemma locally to see if I can offload some of the lighter tasks and reduce costs further.

If you’ve been sleeping on Claude Code, I’d encourage you to just start. Install it, point it at something real, and let it do a few things you’d normally do yourself. The learning curve is real but short, and there is a productivity jump once you get a feel for how to work with it.

More to come as I work through the backlog — I have plenty of observations that didn’t make the cut for this post.