My AI Dev Setup: No More Context Switching, No More Lost Knowledge

I’ve been building with AI tools for a while now. And for most of that time, the experience was… fine. Each tool did its thing. But they didn’t talk to each other, they didn’t remember anything, and I kept hitting the same friction points over and over.

Then I started thinking about the workflow as a system, not a collection of tools. This is what I built.

The Problem

Four specific pains drove this.

The branch-switch interruption. I’d be mid-thought on one feature when a bug came in. Stash everything, switch branches, lose the thread, come back 30 minutes later and spend 10 minutes reconstructing what I was doing. Every time.

The decision that evaporated. I’d spend an hour working through why a particular architecture made sense. Write some code. Move on. Three months later: why did I do it this way? No idea. The thinking lived in a terminal window that closed.

The AI that forgot everything. I’d have a great session with an AI assistant — it understood the codebase, the constraints, the tradeoffs. Next session: start from scratch. Explain everything again. The AI had no memory of yesterday.

The code review that never got written. Under pressure, the review step is the first thing that goes. “I’ll do it later.” Later never comes. The feedback that would have caught the next three bugs just… didn’t happen.

These weren’t hypothetical problems. They were real friction I was living with every day. So I fixed them.

The Setup, in One Picture

The whole thing is a loop:

Idea
 └─ Claude plans → saved to Obsidian
     └─ GitButler branch (no switching)
         └─ Claude codes
             └─ AI code review → saved to Obsidian
                 └─ Daily note logs session

No step is optional. No output disappears into the void. Every decision gets recorded, every session gets reviewed, every piece of work lives in a branch that doesn’t require you to abandon everything else.

GitButler: Work on Many Things, Switch on Nothing

GitButler replaces the traditional Git branch workflow with something that actually matches how thinking works.

In standard Git, branches are exclusive. You check one out, it replaces your working directory, and everything else disappears. Context switching isn’t just a metaphor — it’s literally how the tool works.

GitButler uses virtual branches. Multiple branches are active simultaneously, layered on top of each other in your working directory. When you save a file, GitButler tracks which branch the change belongs to. You can have three things in progress at once without a single git stash or git checkout.

Right now, as I write this, I have three virtual branches open: the blog post you’re reading, a refactor of the slides build pipeline, and a small fix to the RSS feed. None of them know about the others. None of them required me to switch context.

The practical effect on AI-assisted development is significant. Claude Code can be committing changes to one branch — writing tests, fixing types — while I’m thinking through the design of something else on a different branch. The mental overhead of “which branch am I on?” simply goes away.

GitButler also has a great UI for reviewing what’s in each branch before you push. Paired with an AI review step, it makes the “ship clean work” bar much lower to clear.

Obsidian as AI Memory

This is the piece that changed the most about how I work.

The problem with AI assistants is statelessness. Each session is a blank slate. The AI doesn’t remember what you built last week, why you made a particular decision, or what you tried that didn’t work. You have to re-establish context every time — or just skip it and hope the AI picks it up from the code.

I solved this by making Obsidian the persistent memory layer that feeds AI sessions.

Before coding: Claude writes a plan. When I start a non-trivial task, I ask Claude Code to plan it out — scope, approach, risks, open questions. That plan gets saved to my Obsidian vault via the Obsidian CLI before a single line of code gets written. Future me (and future AI sessions) can read it.

After coding: Claude writes a review. When a session ends, Claude Code does a code review of the diff and saves it to Obsidian. Not a summary — an actual review. What was changed, what’s good, what’s fragile, what to watch. It takes about 30 seconds and creates a permanent record.

Daily notes tie it together. Each day’s note in Obsidian logs which branches were active, which plans were executed, and links to the reviews. A month from now, I can open any day and understand exactly what was happening.

The vault compounds. After six months, it’s not just notes — it’s a searchable record of every significant technical decision I’ve made. Why did we switch to Astro? It’s in there. Why is that API endpoint shaped the way it is? Linked from a daily note in November. The answer isn’t lost in Slack or in someone’s head. It’s in the vault.

The Obsidian CLI is what makes this hands-off:

# Save a plan to the vault
obsidian write "plans/$(date +%Y-%m-%d)-feature-name.md" --content "$plan"

# Append a review to today's daily note
obsidian append "daily/$(date +%Y-%m-%d).md" --content "$review"

Claude Code calls these directly. I don’t have to think about it.

GitHub Copilot CLI: AI at the Prompt

Not everything needs a full AI session. Sometimes you just need to remember the right rsync flags. Sometimes you want a quick explanation of what a shell command does before you run it.

GitHub Copilot CLI handles these. Two commands:

# Suggest a command
gh copilot suggest "compress a directory and exclude node_modules"

# Explain what a command does
gh copilot explain "tar -czf archive.tar.gz --exclude='./node_modules' ."

It’s muscle memory now. Instead of alt-tabbing to a browser, opening a new tab, typing a search, scanning results, and copying a command — I just ask at the prompt and get an answer in context.

Copilot CLI complements Claude Code rather than competing with it. Claude Code is for longer tasks where context and planning matter. Copilot CLI is for fast, one-off lookups. They occupy different parts of the workflow.

The Glue: Scripts and Hooks

The tools work because they’re wired together. Left as independent utilities, they’d still require manual effort to connect. The glue is a small set of shell scripts and Git hooks.

A post-commit hook triggers the review flow: after a commit on a feature branch, it calls Claude Code with the diff and saves the output to Obsidian. Zero manual steps.

A daily note script runs in the morning, creates the day’s note from a template, and links in any open GitButler branches. When I sit down to work, the context is already there.

A session-start script opens the relevant Obsidian plan for whatever branch I’m about to work on — so the AI and I are both reading the same brief before we start.

None of these are complex. Each one is 10–30 lines of shell. But together they mean I never have to consciously decide to do the knowledge-capture steps. They happen as a side effect of normal work.

What Changed

The before state: context switching was constant, decisions evaporated, AI sessions started cold, reviews didn’t happen. Every session was a minor struggle against entropy.

The after state: I have three branches open right now and don’t feel any friction from that. The vault has records of decisions from months ago. AI sessions start with context because the plans are already written. Code gets reviewed after every session without me having to remember to do it.

The vault is the most surprising part. It started as a place to dump plans. It’s become the closest thing I have to a second brain for this project. It grows with every session, and it compounds — the knowledge from last month makes this month’s decisions better.

The tools aren’t the point. Any one of them in isolation is useful but not transformative. The loop is the point. Each step feeds the next, every output gets captured, nothing disappears. That’s the setup.