How I'm Productive with Claude Code

TL;DR Highlight

A hands-on account of building parallel agent workflows and infrastructure automation with Claude Code over 6 weeks — the key insight being the shift from 'coder' to 'agent manager.'

Who Should Read

Full-stack developers looking to integrate Claude Code or similar AI coding agents into their actual development workflow. Particularly useful if you're struggling with environment conflicts or context switching costs when running multiple tasks in parallel.

Core Mechanics

The author's commit count visibly increased over 6 weeks, which they frame not as raw code output growth but as a byproduct of a paradigm shift: 'I'm not an implementer anymore — I'm a manager of agents.' Automating repetitive grunt work was the first major shift.
The first automation was a /git-pr custom Claude Code command that handles staging, commit message writing, PR description generation, pushing, and GitHub PR creation all in one shot. PR descriptions end up more thorough than hand-written ones since the agent reads the entire diff.
Server build time was cut from 1 minute to under 1 second by switching to SWC. That 1-minute wait felt too short to do something else but long enough to break focus — sub-second restarts created a seamless flow where previews appear the instant you save.
After Chrome extensions kept crashing, they switched to Claude Code's built-in preview feature. The workflow was redesigned so agents verify UI changes themselves via preview. Once 'done' was redefined as 'agent has visually confirmed the UI,' the agent could run autonomously for much longer stretches.
Port conflicts were the biggest blocker for parallel work. Frontend and backend each need their own ports, and running multiple git worktrees with identical env vars caused them all to fight over the same ports. They built a system that auto-assigns unique port ranges when creating worktrees.
With port conflicts solved, running 5 worktrees simultaneously became feasible. The new workflow: spin up multiple agents in separate worktrees, let them self-verify UI, then just do code review. Heavy involvement during planning, hands-off during implementation, back for review.
The author admits their role shifted from 'engineer who solves hard problems directly' to 'person who builds infrastructure so agents can work effectively.' The joy of hands-on UI implementation decreased, but designing agent operations infrastructure became the new fun.

Evidence

Using commit count as a productivity metric drew heavy criticism. 'It's repackaging the 90s practice of judging quality by lines of code.' A sharper point: 'Developers objected when managers used such metrics, but now that they get to choose, they picked the exact same approach.' The complete absence of any mention of quality, bugs, or maintenance burden was also called out.
Some questioned the practicality of multi-agent parallel work. When agents create large features spanning multiple files, a human still has to read every line — and reading someone else's (or a machine's) code is harder than writing it, potentially negating the productivity gains. 'So are we at the stage where we just deploy AI code and let agents fix it when it breaks?' was one rhetorical question.
Relatable comments came from people running similar workflows but hitting cognitive bottlenecks. One PM using Claude Code for 90% of their day said managing even 2 agents is hard to maintain isolation for, with brain capacity being the bottleneck. Running 5 would require a smarter brain or better tools.
Someone shared that high-performance modes like Opus 4.6 feel amazing at first but quickly become routine. Even single-agent sessions require constant oversight, suggesting parallel agents may not work well in every environment.
There was pushback against AI-written PR descriptions. 'PR descriptions exist for one person to communicate what and why they changed to another — what's the point of delegating that to AI?' The concern was diluting the core communication value of code review.

How to Apply

To automate PR creation, create a git-pr.md file in .claude/commands/ with instructions to 'read the diff, write a commit message and PR description, then create a GitHub PR.' One /git-pr command completes the whole process, reducing context switching.
If port conflicts are blocking parallel agents, add auto-port-range-assignment logic to your worktree creation script. For example, assign frontend ports as 3000+n and backend as 8000+n based on worktree index, eliminating conflicts when running multiple instances.
To make agents self-verify UI changes, explicitly state in your agent workflow instructions: 'After UI changes, launch preview and verify the screenshot before marking as complete.' This ensures agents self-validate before human review, extending the time they can run unsupervised.
If you're new to parallel agents, start with a single agent and stabilize a workflow where it self-verifies and meets completion criteria. Multiple commenters noted that managing 2+ simultaneous agents creates new cognitive overhead, so jumping to parallelism without infrastructure automation may burn you out faster.

Code Example

snippet

# .claude/commands/git-pr.md example structure
# Creating this file makes /git-pr command available in Claude Code

## git-pr

1. Read all changes with `git diff --staged` or `git diff HEAD`
2. Write a commit message in conventional commit format based on the changes
3. Write PR title and description (include What changed / Why / How to test sections)
4. Run `git add -A && git commit -m "[message]"`
5. Run `git push origin HEAD`
6. Run `gh pr create --title "[title]" --body "[description]"`

---
# Example script for automatic worktree port assignment (bash)

create_worktree() {
  local branch=$1
  local index=$2  # worktree index (0, 1, 2...)
  
  local frontend_port=$((3000 + index))
  local backend_port=$((8000 + index))
  
  git worktree add ../worktree-$index $branch
  
  # Create .env.local with unique ports for each worktree
  cat > ../worktree-$index/.env.local <<EOF
FRONTEND_PORT=$frontend_port
BACKEND_PORT=$backend_port
EOF

  echo "Worktree created: frontend=$frontend_port, backend=$backend_port"
}

Terminology

git worktreeA Git feature that lets you check out the same repository into multiple directories simultaneously. You can have multiple branches open at once without stashing or switching.

SWCA Rust-based JavaScript/TypeScript compiler, much faster than Babel. In Next.js, it's a one-line config swap that can improve build speeds by orders of magnitude.

Claude Code skill (custom command)Custom instructions callable as /command in Claude Code. Defined as markdown files in .claude/commands/, used to automate repetitive tasks.

grunt workRepetitive, mechanical work. Tasks not directly related to coding but essential nonetheless — PR writing, staging, branch management, etc.

worktree port conflictWhen multiple git worktrees each run dev servers, they all reference the same env vars (port numbers) and try to bind the same ports, causing failures.

agentic workflowA work style where AI agents go beyond just suggesting code — they autonomously read files, make edits, execute commands, and verify results when given a task.