I kept feeling like I was leaving something on the table. AI-assisted coding was clearly transforming how people ship software, but I wasn’t capturing that leverage. I just hadn’t figured out how.
So I started experimenting. What I found: the amount of value I deliver per day increased dramatically. Not because I work more hours, but because the gap between having an idea and shipping it shrank to almost nothing.
The speed isn’t the point, though. The point is what speed enables: trying more things, learning faster, running experiments that would’ve been too expensive before. When shipping is cheap, you stop guessing and start testing.
Here are particular workflow and tips I’ve landed on.
The setup
I use Conductor, which works heavily around git worktrees. Each workspace is isolated on its own branch, running its own development server on a unique port with a dedicated Claude Code session. Whenever I have an idea, I spin up a workspace. If I want to try a different approach, I open a new workspace. When a bug appears, I start a fresh one. I even create workspaces from within existing ones.
I’m typically working on 2-3 workspaces at once. I haven’t gotten to the point where I manage more than that (hopefully yet). One might be a feature I’m reviewing. Another could be a bug fix or UI improvement. Maybe a third is an experiment that might get merged or abandoned within the hour.
The isolation matters. Context doesn’t bleed between tasks. If an experiment goes sideways, I just close the workspace. No reverting, no cleanup.
If you are not familiar with Claude Code
The article may make more sense for those familiar with Claude Code. If you are new to Claude Code, the best place to start is to read the official documentation:
The New Mental Model: Multiple workstreams at once
Before Claude Code, I worked on one thing at a time. Now I run several value streams in parallel — a new feature in one workspace, a bug fix in another, an improvement in a third. Each moves forward independently.
This only works with a mental shift: as a person, you’re limited by creativity and your focused time. You decide WHAT to build and WHY. Claude handles the HOW.
My job as a software engineer became supervising those changes — steering, fixing, and building systems that let Claude work more autonomously. Tests, linters, type checking: these aren’t just for catching my mistakes anymore. They give Claude feedback so it can iterate without waiting on me.
Practical Workflows
Plan mode as effective context transition between chats
I usually start with plan mode. Plan is for:
To ensure the AI understands WHAT to build and exposes you to all unknowns or things you haven’t considered.
To describe HOW to build the thing. There are multiple ways to implement and you narrow this down to single solution
Then I hand that plan to a separate session with fresh context to implement it. I always prefer the fresh context to avoid having context rot problem. That’s the conventional way to do it, but here is a more sophisticated way I use plan mode.
If the implementation doesn’t fully work — maybe it introduced new problems, or didn’t solve things the way I expected — I go back to the planning session. I give feedback on what worked and what didn’t, and ask for a revised plan. The key: the revised plan includes notes about the failed approach plus a new strategy.
Then I ask to do coding again based on updated plan. This cycle repeats — plan, implement, feedback, revise plan, implement again. The plan document accumulates attempted solutions. Each new implementation session starts with full knowledge of what’s been tried, so fresh context doesn’t mean repeating past mistakes.
As a result, we efficiently hand off context from all previous chats and keep Claude Code focused on a specific problem or set of problems to help it find a solution.
Not everything needs careful plan review, though. When fixing specific UI bugs, for example, the plan barely matters. What matters is iteration velocity — trying many approaches quickly until one works. The goal shifts from “review the plan” to “transfer context efficiently between attempts.” The plan document becomes a running log of what’s been tried and why it failed, not something you scrutinize before each implementation. Once you’ve made it work, feel free to make it right.
Building guardrails for autonomous iteration
Here’s an example that changed how I think about working with Claude.
I needed to localize an iOS app. I picked the libraries and tools. Then, instead of asking Claude to find and translate every string manually, I asked it to set up the infrastructure: configure a linter to catch non-localized strings.
Then I asked Claude to fix the linter errors. During review, I spotted more strings the linter missed. So I asked Claude to tighten the linter rules to catch those too. More errors appeared. Fix those. Tighten again. Repeat until clean.
My job was picking the right solution and tools, and designing the guardrails for the agent to work with. Claude’s job was iterating against those guardrails until the work was done. The linter became the feedback loop—Claude could work autonomously because it had a clear signal for success or failure.
This pattern generalizes. Tests, type checking, and linters aren’t just for catching mistakes; they’re shift‑left infrastructure—tools that catch problems early, allowing Claude to iterate without waiting on you.
Continuous rule improvement
When I notice Claude producing something I don’t want — an overcomplicated pattern or a naming convention I dislike — I don’t just ask for a fix. I ask Claude to fix it and add a rule to `CLAUDE.md` so it doesn’t happen again.
Tip: Write an effective CLAUDE.md
These rules accumulate. Over time, Claude’s output gets closer to what I want without me having to specify it each time.
I use skills a lot when I identify specific domains or pieces of knowledge that I want Claude to remember and apply consistently. Feel free to use plugins to install skills already developed by others.
Reference projects as context
I keep a gitignored folder with reference code—other projects, examples, patterns I like. When I spin up a new workspace, that folder comes along.
This helps Claude one-shot solutions. Instead of describing what I want, I point to an example: “Do it like this project does.” The reference eliminates ambiguity. Claude sees exactly what good looks like in my context.
Disclaimer: I prefer to do it the way I described, but you should probably use “--add-dir” or “/add-dir” for that.
User invokable skills for repeated patterns
When I catch myself describing the same workflow twice, I turn it into a command I can invoke in Claude Code. For example, releasing a new iOS version always involves the same steps—bump the version number, update the changelog, check that everything builds. Now I just type ‘/release’ and Claude Code does everything for me.
The main principle is identify repetitive actions or workflows in your work and automate them using user-invokable skills.
Smart attention allocation
This will probably sound controversial.
Our attention is limited. I’ve learned to be strategic about where I spend it.
When Claude writes UI code and I can see it works visually, I don’t scrutinize the underlying logic. The blast radius is small if something’s off—it’s one prompt away from rewriting the component from scratch.
But database migrations? New schema fields? Those I review carefully. Changing them later is costly and complex. A mistake compounds.
The goal is distinguishing critical code from disposable code. Some changes deserve deep review. Others deserve a glance and a ship.
Voice Input
I’ve stopped typing most of my prompts. Speech-to-text is faster and allows me to describe what I want while reviewing code in another workspace; the keyboard has become optional.
I find it much quicker to describe my prompt this way, though it is worth noting that adopting this workflow involved a bit of a learning curve.
I use the Handy and Parakeet V3 models. The transcription is purely local and works insanely fast.
A small tip: use a wired microphone for speech-to-text.
Context
This is based on my experience with personal projects, not work. I spend 1-3 hours a day for my side projects. I’m on the $100/month Max plan and haven’t hit any usage limits.
