How I’m Productive with Claude Code | Neil Kakkar

How I'm Productive with Claude Code

Neil Kakkar

AboutBlogShorts

You might also like

Agentic Debt
What I learned about burnout and anxiety at 30
How to setup duration based profiling in Sentry
How to simulate a broken database connection for testing in Django

Subscribe to the Idea Muse
One idea every few weeks designed to make you smarter. Join 1,500+ people cutting through the noise. Read more

Email Address *

First Name *

How I'm Productive with Claude Code

Mar 16, 2026


•

Tech

It’s been about 6 weeks since I joined Tano, and this is what my commit history looks like:

Commits are a terrible metric for output, but they’re the most visible signal I have. Something real changed in how I work, and the commit count is a side effect.
So, what has changed?
Automating the grunt work
When I joined Tano, I was making every pull request by hand. Stage changes, write the commit message, craft the PR description, push, create the PR on GitHub. Standard process, it was fine.
It took me a while to realize this is grunt work. I was so used to doing it that I’d never questioned it.
That was the first real shift: I’m not the implementer anymore. I’m the manager of agents doing the implementation. And managers automate their team’s grunt work.
Then I wrote my first Claude Code skill: /git-pr.1
It does everything I used to do, except it does it better. The PR descriptions are more thorough than what I’d write, because it reads the full diff and summarises the changes properly. I’d gotten so used to the drudgery that I’d stopped noticing it was drudgery.
The time saved matters, but the real unlock was the mental overhead removed. Every PR used to be a small context switch: stop thinking about the code, start thinking about how to describe the code. Now I type /git-pr and move on to the next thing.

Killing the wait
Reviewing changes had this annoying loop.
Preview changes locally, go away from what I’m working on, kill the dev server, restart it on the new branch, check it all works, review the code.
The server build took about a minute, which was agonisingly long when I was mid-context-switch. Long enough to break focus, too short to do anything useful.
I switched the build to SWC, and server restarts dropped to under a second. This sparked joy.
It sounds like a small change. It wasn’t. Sub-second restarts mean you never leave the flow. Save a file, the server’s already up, check the preview. There’s no gap where your attention drifts. It’s the difference between a conversation with awkward pauses and one that flows naturally.
Let Claude see what happens
Before this, I checked every UI change. Preview locally, eyeball it, decide if it matches what I expected. It worked, but it meant I was a bottleneck on every feature.
After the Chrome extension kept crashing, I switched to the preview feature in Claude Code. It lets the agent set up a preview, persist session data, and see how the UI actually looks.
I wired it into the workflow: a change isn’t “done” until the agent has verified the UI itself. That meant I could delegate verification and only step in for final review — which also meant agents could run much longer without oversight. They’d catch their own mistakes. That mattered more than I realized at the time.
Parallel everything
Fast rebuilds and automated previews made another friction visible: I could only comfortably work on one thing at a time.
I was reviewing PRs from other agents and teammates. The workflow was painful: check out the PR branch on main, rebuild, test. But that would mess with my uncommitted changes. So I’d stash, checkout, rebuild, test, switch back, pop the stash. Or create a worktree manually, set it up, try to run the preview - only to find the ports clashing with my other running server.
Our app has a frontend and a backend, each needing its own port. Every worktree shared the same environment variables, so they’d all try to bind to the same ports. Running two things at once was a fight.
I built a system around this. Whenever a worktree is created, every server gets assigned ports from a unique range. No collisions. I could run ten previews simultaneously if I wanted.
I went from getting overwhelmed by two parallel branches to running five worktrees at once. My create loop changed: fire off multiple agents on separate worktrees, each building a different feature. They’d only stop once they’d verified the UI themselves.
I’d be heavily involved in planning. Then I’d disappear until code review. Agents catching their own mistakes mattered a lot more with five running at once.
Reviewing got smoother too. No faffing around with setup. No rebuilding. No port conflicts. Just: read, verify, merge. Next.
It’s the infrastructure, not the AI
My role has changed. I used to derive joy from figuring out a complicated problem, spending hours crafting the perfect UI. I still do that sometimes, but a lot less now. What’s become more fun is building the infrastructure that makes the agents effective. Being a manager of a team of ten versus being a solo dev. And like any good manager, you get to claim credit for all the work your “team” does.
These aren’t glamorous problems. They’re plumbing. But plumbing determines whether you’re in flow or wrestling your environment.
The highest-leverage work I’ve done at Tano hasn’t been writing features. It’s been building the infrastructure that turned a trickle of commits into a flood.
The loop
Each of these stages removed a different kind of friction:

/git-pr removed the friction of formatting - turning code changes into a presentable PR.
SWC removed the friction of waiting - the dead time between making a change and seeing it.
The preview removed the friction of verifying changes - I could quickly see what’s happening.
The worktree system removed the friction of context-switching - juggling multiple streams of work without them colliding.

And each time I removed one, the next became visible. When PRs were effortless, I noticed I was wasting time on rebuilds. When rebuilds were instant, I noticed I couldn’t run things in parallel. Classic theory of constraints — fix one, and the system immediately shows you the next one.
The nature of the work changed. 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 feedback loop is so tight that there’s no gap for my attention to leak out.
Building things is a different kind of fun now — it’s so fast that the game becomes improving the speed. How much faster can I go? When the loop is tight enough, engineering becomes the entertainment.

It’s /git-pr because our codebase CLAUDE.md says to use Graphite, but I prefer plain git. ↩

You might also like

Agentic Debt
What I learned about burnout and anxiety at 30
How to setup duration based profiling in Sentry
How to simulate a broken database connection for testing in Django

Subscribe to the Idea Muse
One idea every few weeks designed to make you smarter. Join 1,500+ people cutting through the noise. Read more

Email Address *

First Name *

Neil Kakkar
Write (Code). Create. Recurse.
neil@neilkakkar.com

I want to understand how the world works. This blog tracks my growth, the things
I've learned, and how I'm leveraging them to do epic things.

Neil Kakkar’s “How I’m Productive with Claude Code” details a significant shift in his workflow at Tano, driven by automating previously manual processes and leveraging Claude Code’s capabilities for enhanced efficiency. The core of Kakkar’s experience revolves around transforming his role from an implementer focused on individual PRs to a manager enabling a team of agents. He highlights a series of iterative improvements, each addressing a specific point of friction and unlocking further productivity gains.

Initially, Kakkar recognized that his time was excessively consumed by the repetitive tasks associated with creating pull requests—formatting, description writing, and push operations—which he termed “grunt work.” The creation of the /git-pr skill was the first step, automating this process and providing more detailed PR summaries, freeing his mental bandwidth. This initial action set the stage for subsequent optimizations.

A recurring bottleneck was the time spent waiting for server rebuilds, which consistently took around a minute. Kakkar addressed this by switching to SWC (Speedy Web Compiler), drastically reducing rebuild times to under a second. This eliminated the frustrating “context-switch” required when reviewing changes and facilitated a smoother, more continuous workflow. The author explicitly emphasizes that this seemingly small change—instant server restarts—fundamentally altered his focus, allowing him to move directly from one task to the next.

Furthermore, Kakkar introduced a system for previewing UI changes using Claude Code’s preview feature. This allowed agents to verify UI changes directly, eliminating Kakkar’s bottleneck as a reviewer and enabling greater agent autonomy, ultimately leading to them catching their own mistakes.

To manage parallel development efforts efficiently, which was initially hampered by port conflicts, Kakkar implemented a system where each server received a unique port range. This allowed for the simultaneous execution of multiple builds and previews, streamlining the workflow and reducing the need for cumbersome context switching. This resulted in the ability to manage up to five worktrees concurrently, significantly accelerating the development cycle.

Kakkar's observations follow a pattern of “theory of constraints,” where resolving one bottleneck immediately revealed the next. Each improvement – automating PR formatting, reducing rebuild times, and enabling UI previews – created an opportunity for further optimization. The ultimate loop involves setting off multiple agents on separate worktrees, which verifies the UI and generates a complete PR, streamlining the entire process. The result is a tightly-coupled feedback loop where attention isn’t lost during transitions between tasks.

Ultimately, Kakkar suggests that the most impactful aspects of his work have been focused on building the underlying infrastructure – the plumbing – that supports the agents’ productivity. He recognized that his enjoyment derived not from crafting complex features, but from building the systems that enabled effortless code production. He notes the importance of minimizing friction throughout the development cycle, enabling a faster, more fluid workflow with minimal interruptions.