--- title: "My Claude Code workflow in 2026" url: https://akdarrah.com/posts/my-claude-code-workflow-in-2026 author: Adam Darrah published: 2026-11-06T01:56:52Z updated: 2026-11-06T01:56:52Z tags: ["ai","claude-code"] --- # My Claude Code workflow in 2026 I want to be involved in a piece of work twice: when I approve the plan, and when I judge the finished pull request. Everything between those two moments runs in Claude Code without me. A skill runs each ticket through the same steps, pull requests run in parallel, and a small app brings me one decision at a time. This page is the map. Each section is a short summary of one part of the workflow, with a link to the post that covers it in full. ## What is the software factory? Almost everything I build goes through the same lifecycle, so I turned it into a Claude Code skill called `/factory`. It takes one ticket through fixed steps: 1. **Verify.** Read the ticket and check every claim against the code. Tickets are often incomplete or out of date. 2. **Plan.** Write a plan with me. This is the first time it stops and waits. 3. **Build.** Implement the plan without checking in, and open a pull request. 4. **Review.** Rounds of code review, fixing every critical or important finding, until a round comes back clean. 5. **QA.** Test every permutation it can, in a real browser with the Claude in Chrome extension for anything with a UI. 6. **QA report.** Publish what was tested, with screenshots, and link it in the PR. 7. **Risk report.** The blast radius, what could break, and who would notice. A Claude Code mod shows a band above the prompt with the current step, the ticket, the PR and the CI status. I can glance at a session and know where it is without scrolling back. You can set the whole thing up with one prompt: [Build a local software factory in 10 minutes](/posts/build-a-local-software-factory). ## How do I run Claude Code agents in parallel? A lot of tickets turn into several pull requests once they're planned. Running them one after another meant a lot of waiting, so the factory now runs them at the same time. The first two steps still happen once, for the whole batch. The ticket gets verified, and I approve one plan with a section for each PR. The plan includes a collision table: every file two PRs both touch, and the order to merge them in. Reading that table before I approve is the cheapest moment to catch two PRs that will fight over the same file. A few rules make it safe on one laptop: - **Two at a time.** Each build can boot Rails and a frontend build. When I tried more, runs were killed for memory and the machine crashed. - **Locks for shared things.** There's one browser and one development database. An agent takes a lock (a directory made with `mkdir`) before using either one. - **Questions come to me.** A stuck agent stops and asks instead of guessing. That started in [Run the software factory in parallel](/posts/run-the-software-factory-in-parallel). ## Why does each pull request get its own session? The first parallel version gave each PR to a subagent inside one main session. It was great at the start and got in the way at the end. PRs don't finish together. One is ready to merge, one conflicts with main, one has a failing test. With one parent session, every fix had to wait its turn. So now the main session plans the batch, then starts a real background session per PR and stops: ```text claude --bg -n "TICKET-123 Short title" "/factory --plan " ``` Each session skips verify and plan, builds its own PR, and asks me its own questions. The lesson I took from it: put the boundary where your tools already look. My tools think in sessions, so a unit of work that will need me later should be a session. More in [One session per pull request](/posts/one-session-per-pull-request). ## How do I keep track of all those agents? Parallel factories moved the bottleneck from the work to my attention. I had six or seven sessions open, and finding the one that needed me meant opening each of them. So I built agentctl, a terminal app that replaces the agents list. Instead of me checking on agents, they bring me one card at a time: - **Ready to merge.** CI passes, no merge conflicts, every CodeRabbit comment resolved. I read the QA and risk reports and merge. - **Approve plan** or **answer questions.** An agent is waiting on me. - **Review requested.** A teammate's PR, already reviewed by a local agent. - **Finish PR.** Something is still red. One button types the fix request into that PR's own session. - **Ready to start?** A ticket from my Linear cycle that looks ready. I answer yes or not yet. After a day with it, the bottleneck moved again: my laptop running a dozen worktrees, test databases and dev servers, and the token limits on my Claude Max plan. The posts: [Focus mode for AI agents](/posts/focus-mode-for-ai-agents) and [One day with agentctl](/posts/one-day-with-agentctl-the-bottleneck-moved-again). ## Claude Design vs Claude Code: which one designs the UI? Claude Design does, and I drive it myself. For a while I believed Claude Code could drive Claude Design on its own, and I wrote [a post saying so](/posts/claude-design-doesnt-need-me). I took it back a week later. When I opened Claude Design myself to fix a couple of pages, the difference was obvious. The bigger win is consistency. When Claude Code designs as it builds, each page is designed on its own. When I mock up the pages in Claude Design first, they're designed together and share the same choices. So everything gets designed before it gets built: 1. Mock up the UI in Claude Design, myself. 2. Hand the design to Claude Code. 3. Let Claude Code build it. The full story is in [I was wrong about Claude Design](/posts/i-was-wrong-about-claude-design). The lesson that stuck: a model saying it did something is not proof that it did. ## How do I hand requirements to an agent? Sometimes with a two-minute screen recording instead of a written spec. I click through a mockup and talk over it: what matters, what's out of scope, what happens after you save. The agent reads the transcript and looks at frames sampled from the video. I pair the video with the clickable mockup for exact copy, and have the agent compare the video with what the code does today before it plans. Then I ask "is this enough to make a plan?" and let it tell me what's missing. How to do it: [I handed Claude a Loom instead of a spec](/posts/i-handed-claude-a-loom-instead-of-a-spec). ## What about work that can't run in parallel? Some projects are a chain. One server change, then several apps that use it, each waiting on the server. More agents don't help when each one waits on the one in front. Our CTO suggested agreeing on the contract first, and that's what I'll do next time: write the API down as an OpenAPI spec, then build the server and every app against it at the same time. The spec matters more when agents do the building: an agent working on an app can't lean over and ask the server agent what a field is called. More in [Agree on the API before you build the apps](/posts/agree-on-the-api-before-you-build-the-apps). ## How much of the code do I review? Less than I used to. For most changes, I read the PR description, the QA report and the risk report from the factory, and decide. The code still matters to me at the level of architecture. I wrote about how I got comfortable with that in [Someone always trusted someone else to write the code](/posts/someone-always-trusted-someone-else). Feature flags help. Building a feature takes days now instead of weeks, but I still ship it in pieces behind a flag, then walk through it end to end before I turn it on. See [AI made me use more feature flags, not fewer](/posts/ai-made-me-use-more-feature-flags-not-fewer). ## Where does the context live? In an Obsidian vault I call a brain. It records what was decided and why, and every fact links to its source: a meeting, a PR, a Slack thread. Decisions and open questions each get their own note. Claude filled it. Each source (GitHub, meeting notes, Slack, Linear) went to its own subagent, and only conclusions came back. Now it stays current two ways. My global `~/.claude/CLAUDE.md` tells every session to log decisions before finishing a task. And a launchd job runs `claude -p` every weekday morning, files what's new, commits, and emails me a short brief. Build your own with the prompt in [I built a brain for work, and Claude keeps it up to date](/posts/i-built-a-brain-for-work-and-claude-keeps-it-up-to-date). ## How do I deploy? This blog is Rails 8 on a $12 DigitalOcean droplet, deployed with Kamal and a local registry. QEMU lets my arm64 Mac build amd64 images, and the Let's Encrypt cert took seconds. That's covered, as a song, in [Now We're Live](/posts/now-were-live). One rule from long before AI still holds: [I never have production open](/posts/i-never-have-production-open). When I need production, I open an incognito window or a red terminal window, do the one thing, and close it.