How I'm Productive with Claude Code

This is basically the same workflow I've come to adopt. I don't use any "pre-built" skills, mine are actually still .md files in the .claude/command/ folder because that's when I started. The workflow is so good, I'm the bottleneck.

I've started to use git worktrees to parallelize my work. I spend so much time waiting...why not wait less on 2 things? This is not a solved problem in my setup. I have a hard time managing just two agents and keeping them isolated. But again, I'm the bottleneck. I think I could use 5 agents if my brain were smarter........or if the tools were better.

I am also a PM by day and I'm in Claude Code for PM work almost 90% of my day.

> What’s become more fun is building the infrastructure that makes the agents effective.

Solving new problems is a thing engineers get to do constantly, whereas building an agent infrastructure is mostly a one-ish time thing. Yes, it evolves, but I worry that once the fun of building an agentic engineering system is done, we’re stuck doing arguably the most tedious job in the SDLC, reviewing code. It’s like if you were a principal researcher who stopped doing research and instead only peer reviewed other people’s papers.

The silver lining is if the feeling of faster progress through these AI tools gives enough satisfaction to replace the missing satisfaction of problem-solving. Different people will derive different levels of contentment from this. For me, it has not been an obvious upgrade in satisfaction. I’m definitely spending less time in flow.

> I’m not “using a tool that writes code.” I’m in a tight loop: kick off a task, the agent writes code, I check the preview, read the diff, give feedback or merge, kick off the next task

the assumption to this workflow is that claude code can complete tasks with little or no oversight.

If the flow looks like review->accept, review->accept, it is manageable.

In my personal experience, claude needs heavy guidance and multiple rounds of feedback before arriving at a mergeable solution (if it does at all).

Interleaving many long running tasks with multiple rounds of feedback does not scale well unfortunately.

I can only remember so much, and at some point I spend more time trying to understand what has been done so far to give accurate feedback than actually giving feedback for the next iteration.

Yup, the manager gets implicit credit for the work their team does. In most cases, deservedly so. I don't see why it should be any different for engineers using LLMs as "direct reports". Not all engineers will be the same level of "good" with LLM tools so the better you are (as with any other skill as well) the more credit you would receive.

I do parallel agents in worktrees and I don't always constantly keep an eye on them like a fry cook flipping 20 burgers at once. Sometimes it's just nice to know that I can spin one up, come back tomorrow, and some progress has been made without breaking my current flow.