DEV Community: Shubhajit Chatterjee

[Boost]

Shubhajit Chatterjee — Sat, 16 May 2026 12:46:52 +0000

Shubhajit Chatterjee

May 16

How I used Claude Code and git worktrees to ship 2 features and fix 3 bugs in one day

#ai #claude #git

Comments

5 min read

How I used Claude Code and git worktrees to ship 2 features and fix 3 bugs in one day

Shubhajit Chatterjee — Sat, 16 May 2026 12:05:19 +0000

I want to share an interesting workflow I experimented with recently while working with Claude Code and git worktrees.

Background

I had a lot on my plate with deadlines approaching. I had to fix 3 bugs and complete 2 feature implementations.

And it was not just implementation work. I had to write new unit tests, update existing test cases, manually verify everything, and make sure fixing one thing was not breaking another.

Initially it did not feel like too much. But once I properly analysed everything that needed to be done, I realised the approaching deadline could easily turn this into a mess if I handled it poorly.

I wanted to experiment that day.

How would I have approached this earlier

Normally I would have started with one task, completed it, raised a PR, and then moved on to the next one.

If I got PR comments, I would stash or commit my current work, switch back to the other branch, fix the comments, and iterate on that again. Then I would come back to my original task and continue implementing.

This process itself is not necessarily bad. Always moving fast is not the solution.

The real problem was that these were new implementations. And in my experience, implementing something new usually requires significantly more thinking, exploration, and iteration. If I spiralled on one task, it could easily consume a huge amount of time while everything else remained blocked behind it.

This would have easily taken me 3-4 days.

The moment of realisation

I paused for a while that day and went through multiple possible approaches in my head.

I cannot work on all of them in parallel myself. That is just a fact.

But AI can. But the problem was how do I actually make this practical?

Should I run multiple Claude Code sessions and ask each one to handle a different task
But that would quickly become a mess. All of them editing the same working directory and modifying overlapping files was guaranteed to create conflicts.
Then I thought, what if I ask Claude Code to not make edits and only work in memory?
But that was not practical either. I could not properly verify anything, test changes, or realistically iterate on the implementation.
What if I clone the repository multiple times and run separate Claude Code sessions in each copy?
That probably would have worked. But it felt extremely clunky and difficult to manage.

At that point I decided to simply ask Claude Code itself how to solve this problem.

That was the moment it introduced me to git worktrees.

So What are git worktrees

I had never used git worktrees before this. I vaguely knew they existed but never had a reason to try them seriously.

Interestingly, I didn’t even manually set this up myself initially. Claude Code already knew how to work with git worktrees. I simply asked it to help me create a parallel workflow for multiple tasks in the same repository and it handled most of the git setup.

The idea is actually pretty simple.

Normally, we work on one branch at a time. Switching between tasks means stashing changes, checking out another branch, rebuilding context, running the project again, and mentally reconnecting with what we were doing.

Git worktrees solve this differently.

Instead of switching branches in the same directory, you create multiple working directories attached to the same repository. Each directory has its own branch checked out independently.

git worktree add ../project-feature-1 feature/feature-1
git worktree add ../project-bug-1 fix/bug-1

After this, I effectively had five copies of the same project open at once — each isolated to its own task.

One thing I liked here is that I didn’t need to become a git worktree expert before trying this workflow. Claude Code already understood the setup pretty well and guided most of it.

Running Claude Code in parallel

I opened a separate Claude Code session in each worktree directory. I am no expert in prompts.

For the bugs, I gave each session proper context:

what the issue was
how to reproduce it
what I suspected the root cause might be
what I had already checked

For the features, I described the expected behaviour, edge cases, and which parts of the codebase would probably be involved.

Then I let them run in parallel.

But honestly, this was not some magical “everything worked perfectly” workflow.

Managing five parallel sessions was mentally exhausting initially. There was a lot of context switching. One session would ask for clarification while another had already generated code that needed verification while another was going in the wrong direction entirely.

The interesting part was learning how to drive the sessions properly.

If Claude Code was drifting away from what I wanted, I had to steer it back with more precise instructions. Sometimes the difference between a useful output and a useless one was simply giving better constraints or explaining the intent more clearly.

Over time, I noticed something unexpected, it started becoming easier.

The first hour felt chaotic. Later it started feeling surprisingly natural.

What actually became the bottleneck

At some point I realised the bottleneck had shifted.

Claude Code was generating implementations faster than I could comfortably review and verify them.

I was moving between worktrees continuously:

checking diffs
testing fixes
reproducing bugs
validating edge cases
correcting prompts
answering follow-up questions from another session

The limiting factor was no longer typing speed.

It was my ability to:

make decisions quickly
maintain context across multiple tasks
verify correctness without losing focus

That felt very different from normal development work.

Verification

I manually verified everything. Every bug fix I reproduced the original issue first, confirmed it was gone, checked for obvious regressions. Every feature I tested the happy path and the edge cases I actually cared about.

This would have become more easier with better agent harness. I learnt about this later, maybe will write about this as well in some future blogs.

Result

I was able to ship all 5 requirements with production quality in a single day. That genuinely made me very happy.
The entire workflow felt fascinating to me, so I thought I should share the experience.

How I work now

Now, it’s not like I always run things in parallel. Honestly, even after getting familiar with the workflow, it is still mentally exhausting sometimes. But now I know that if I ever need to move fast, there is actually a practical way to do it.

One thing this experiment made very obvious to me is how important understanding the codebase becomes in this kind of workflow.

The better I understood the codebase, the easier it became to guide Claude Code properly.
The better I understood the bugs, the faster I could identify when an implementation was incorrect.
The clearer my instructions were, the better the parallel execution worked.

That shift was probably the most interesting part of the entire experiment.

Building a single active tab experience

Shubhajit Chatterjee — Tue, 05 May 2026 05:13:26 +0000

I recently had a requirement where, if a user opens the app in multiple browser tabs, only one tab can be active at a time, and the rest are locked.

Core Requirements

Here are the core requirements as I see them:

Uniquely identify each tabs
Store the active tab somewhere
If a user opens a new tab, lock it if there is already an active tab
If the active tab is closed, detect that and inform the other tabs

Sounds simple enough, doesn't it? Take a moment and think about how you'd solve this. It's more interesting than it looks.

Edge Cases

Let’s think through some edge cases:

Next active tab - If the user closes the active tab and multiple tabs are locked, which one should become active?
Stale active tab - If the user closes the browser and returns later, how do we ensure that the previously stored active tab is not considered?
Race condition - If two tabs are opened at the same time, how do you handle the race condition?

Not so simple anymore, right?

Possible Solutions

Let's explore some solutions that I came across.

Local Storage

The most obvious solution is localStorage. Here is how the flow would look like -

Generate a unique identifier for each tab
Store the first tab as active in localStorage
When a new tab is opened, check the storage for any active tab.
If one exists, lock the new tab, otherwise, make it active
Subscribe to storage events to react to active tab changes.
When the active tab is closed, remove it from storage so another tab can become active.

The above does work and new tabs are correctly locked.

Now let's visit the edge cases -

Next active tab - We can store the order in which the tabs are opened, and then based on the order, we can choose to select the next tab. This adds complexity, as we must also remove closed tabs from the order array. We can store this in localStorage as well.
Stale active tab - You might think that we can use beforeunload event and remove it from the localStorage. But the beforeunload event is not that reliable. It won't fire in scenarios like a system crash or an abrupt OS shutdown, leaving stale data in localStorage.
Race condition - Honestly, I couldn't find a clean way to handle this with localStorage alone.

Broadcast Channel

The flow here is almost identical to the localStorage approach, with two differences:

We use a BroadcastChannel to communicate directly between tabs
Instead of storing state in localStorage, each tab maintains its own in-memory copy of the active tab and the order array, kept in sync via BroadcastChannel messages.

Here is how the flow would be like -

Generate a unique identifier for each tab
When a new tab opens, broadcast a message to ask for the current state
An existing tab responds with the active tab and the order array
Based on the response, decide whether to lock the new tab or make it active
When the active tab is closed, broadcast a message so other tabs can update their in-memory state and elect the next active tab

Now let's revisit the edge cases —

Next active tab - Same as before, we maintain the order array in memory and pick the next one when the active tab closes.
Stale active tab - Interestingly, this is partially better. Since state is in-memory, it dies with the browser — no stale data persists to the next session. However, we still rely on beforeunload to notify other tabs, which is not that reliable.
Race condition - Same problem. Still no clean solution here.

A step forward, but still does not covers everything we need.

Web Locks API

Both approaches we discussed earlier got us close, but we were essentially building a locking mechanism from scratch. What if the browser already had one?

This is where the Web Locks API really shines. Instead of building a locking mechanism from scratch, we can use a browser-provided one that already handles coordination between tabs, including queuing and race conditions.

In our case, the application itself becomes the shared resource. We can define a lock name, say dev:app, and use it to ensure that only one tab can acquire it at a time.

Here is how a typical flow would look like -

When a tab is opened, use the Web Locks API to acquire the lock.
If the lock is acquired, set the current tab to active.

That's all. Everything else is handled by the browser.
Here’s how this looks in React, though the same idea applies across frameworks.

const [active, setActive] = useState(false);

useEffect(() => {
  navigator.locks.request("dev:app", () => {
    setActive(true);
  });
}, []);

if (!active) {
  return <div>This tab is not available</div>;
}

return <div>This tab is available</div>

Let's visit the edge cases for this -

Next active tab - The browser handles assigning the next active tab. When the active tab is closed, the lock is released and the browser automatically assigns it to the next tab in the queue.
Stale active tab - Since the Web Locks API doesn't persist any state, there is no stale data to worry about. When the browser is closed, all locks are released automatically.
Race condition - The browser handles this gracefully. When multiple tabs try to acquire the lock at the same time, the browser ensures only one tab gets it, queuing the rest.

Conclusion

What started as a simple requirement turned into a useful reminder that sometimes the real challenge is not in the implementation, but in knowing what the platform already provides. Instead of building our own coordination logic, we can rely on the Web Locks API to handle it in a much more reliable way.

If you find yourself building a locking mechanism from scratch in the browser, stop and check if the Web Locks API fits. Chances are, it does.

Performant Web Apps

Shubhajit Chatterjee — Sun, 08 Sep 2024 12:15:00 +0000

Imagine a world where dynamic web applications are so responsive, they feel as fast as static sites served directly from a user’s local system. That level of speed would create a seamless and delightful user experience.

But is that even possible? Dynamic apps need to load HTML, CSS, JavaScript, retrieve data, render the UI, and often pull in more resources as users interact. So how do we achieve snappy performance, especially when screens depend heavily on server data? A “local-first” approach might help, but it’s not always feasible—and not every manager will agree to it.

I’ll share strategies I’ve learned from blogs, X (formerly Twitter), and YouTube videos to help close the gap and improve the user experience.

We will discuss the following here

The Problem
Possible Cause
Possible Solutions
- Poorly written data fetching or async code
- fetch-as-you-render & render-as-you-fetch

The Problem

Before jumping into performance strategies, let’s define the problem. The perfect user experience depends on factors like network speed, server latency, and data processing.

Our goal is simple: reduce loading states. We won’t focus on code optimization, data structures, or algorithms. Instead, we’ll explore solutions for SPAs that work across frameworks and can be extended to SSR apps.

Possible Causes

One major reason apps feel slow is the network waterfall. This is very well explained on Remix’s homepage. I encourage everyone to check it out if not already done. But how does a traditional app cause this? Common reasons I’ve seen in many codebases include:

Poorly written data fetching or async code
Fetch-as-you-render
Decoupled components that fetch their own data, leading to more fetch-as-you-render scenarios

Thus the above problem statement can be rewritten as reducing network waterfall

Possible Solutions

Tools these days are very good and when used together can handle some of the above scenarios if used properly.

Let's see some ways to resolve some of the mentioned above

Poorly written data fetching or async code

Let’s take a look at this function:

async function fetchUserData(userId: string) {
  const postsResponse = await fetch(`/api/posts/${userId}`);
  const posts = await postsResponse.json();

  const commentsResponse = await fetch(`/api/comments/${userId}`);
  const comments = await commentsResponse.json();

  return { comments, posts }
}

This function fetches a user’s posts and comments based on userId. However, it causes a network waterfall because the comments request waits for the posts request to finish.

We can improve it by fetching both at the same time:

async function fetchUserData(userId: string) {
  const [posts, comments] = await Promise.all([
    fetch(`/api/posts/${userId}`).then((response) => response.json()),
    fetch(`/api/comments/${userId}`).then((response) => response.json()),
  ]);

  return { posts, comments };
}

By using Promise.all, both API calls happen in parallel, removing the waterfall delay.

There are many methods available on Promise that can be useful in different scenarios

Not all API calls can be parallelized—some may depend on the results of others—but many don’t. For dependent requests, this optimization doesn’t apply, and further strategies would depend on specific cases (which we won’t cover here).

The example above doesn’t handle errors, as it’s just for demonstration.

`fetch-as-you-render` & `render-as-you-fetch`

This is an interesting one and is very very common in codebases. So, what is fetch-as-you-render and how does it cause delayed UI?

fetch-as-you-render is caused when data is fetched inside a component and the Fetch-as-you-render happens when data fetching is triggered inside a component, often during the render phase or in lifecycle methods like useEffect. This is common across many frontend frameworks such as Solid, Svelte, and Vue.

Imagine you have three nested components, each fetching its own data. This creates a scenario similar to poorly written data fetching: each component’s data fetch starts only after the component is rendered or mounted. This not only delays the rendering but can also cause additional delays as each fetch waits for the previous one to complete.

Let look at a piece of code:


function UserDataViewer() {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetchUser().then((_user) => {
      setUser(_user);
      setIsLoading(false);
    });
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return (
    <>
      <Posts userId={user.id} />
      <UserCommentsViewer userId={user.id} />;
    </>
  );
}

function Posts({ userId }: { userId: string }) {
  const [posts, setPost] = useState<Post | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetchUserPosts(userId).then((_posts) => {
      setPost(_posts);
      setIsLoading(false);
    });
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return (
    <PostsViewer posts={posts} /> // A static component to show Posts
  );
}

function UserCommentsViewer({ userId }: { userId: string }) {
  const [comments, setComments] = useState<Comment | null>(null);
  const [isLoading, setIsLoading] = useState(false);

  useEffect(() => {
    setIsLoading(true);
    fetchUserComments(userId).then((_comments) => {
      setComments(_comments);
      setIsLoading(false);
    });
  }, []);

  if (isLoading) {
    return <div>Loading...</div>;
  }

  return <Comments comments={comments} />; // A static component to show comments
}

The provided code demonstrates the fetch-as-you-render pattern, which can lead to delayed UI updates. Here’s how:

UserDataViewer: It fetches user data and waits for it to complete before rendering the Posts and UserCommentsViewer component.
Posts & UserCommentsViewer: Once UserDataViewer has fetched and set the user data, Posts fetches posts based on the user ID.

In this setup, each component fetches its data only after the previous component’s data is available, causing a cascading delay. Each fetch operation waits for the component to render or mount, leading to slower overall page load times.

Fetching data per component is a common pattern to have colocation but can lead to inefficiencies. Libraries like @tanstack/react-router and SWR simplify the process, but the fetch-as-you-render issue remains. Hoisting data fetching to a parent component helps, but what if that parent component is rendered within another component? How can we further improve this approach?

Render-as-you-fetch is a interesting pattern that can improve this situation. This can have its own blog, maybe I will write this in more details some other time, but let's directly jump to a solution.

Most frameworks provide data loaders integrated with their routers. For example, react-router-dom has loaders and actions, @tanstack/react-router offers loaders, @solidjs/router uses a load function, and @sveltejs/kit includes load function. Let’s explore how we can leverage react-router-dom and its loader and composition to improve data fetching efficiency.

export async function loader() {
  const { userId } = await fetchUser();

  const [posts, comments] = await Promise.all([
    fetch(`/api/posts/${userId}`).then((response) => response.json()),
    fetch(`/api/comments/${userId}`).then((response) => response.json()),
  ]);

  return { posts, comments };
}

function UserDataViewer() {
  const { posts, comments } = useLoaderData();
  return (
    <>
      <Posts posts={posts} />
      <UserCommentsViewer comments={comments} />
    </>
  );
}

The code above eliminates the waterfall effect by fetching data in the loader and passing it to the component as props. While this approach blocks user navigation until the data is fetched, you can adjust this behavior using Await, defer, and Suspense components. For more details, refer to the guide in the react-router-dom documentation.

But this above code has one problem, the data fetching is completely moved to loaders, and the colocation with component is lost. What if I want to drop UserCommentsViewer in another component in another route? I have to make sure that the data loader their fetches the data and correctly pass it to component, I cannot expect that I drop a component and it just works.

Let's improve this further using @tanstack/react-query

export async function loader() {
  const { userId } = await fetchUser();

  void queryClient.ensureQueryData(getPostsQueryOptions(user.id));
  void queryClient.ensureQueryData(getCommentsQueryOptions(user.id));

  return { userId };
}

function UserDataViewer() {
  const { userId } = useLoaderData();
  return (
    <>
      <Suspense fallback={<div>Loading...</div>}>
        <Posts userId={userId} />
      </Suspense>

      <Suspense fallback={<div>Loading...</div>}>
        <UserCommentsViewer userId={userId} />
      </Suspense>
    </>
  );
}

function Posts({ userId }: { userId: string }) {
  const { data } = useQuery(getPostsSuspenseQueryOptions(userId));
  return <div>{/* The actual code to render */}</div>;
}

function UserCommentsViewer({ userId }: { userId: userId }) {
  const { data } = useQuery(getPostsSuspenseQueryOptions(userId));
  return <div>{/* The actual code to render */}</div>;
}

This code tackles the waterfall issue while keeping the data fetching colocated with the component. The above code works as follows -

Loader Function: Instead of just letting the components fetch their own data, the loader triggers the actual api call parallely. This prevents the waterfall. The code above will also render the route without waiting for the data to be fetched, this can be modified by awaiting them.
Colocated Data Fetching: The Posts and UserCommentsViewer components use useQuery to access the already-fetched or ongoing fetch data. Since the loader has done the heavy lifting, these components can render themselves without worrying about the waterfall.

Another great thing about these components is that they’re self-contained. You can drop them anywhere in your React app, and they’ll work just fine. Of course, if you move the component, the route loader will need the prefetch logic too, but that’s easily handled.

There’s another cool benefit to using loaders for prefetching. Most routing libraries can prefetch data when a link is hovered over or rendered, meaning the data is ready before the user even clicks the link. This taps into the render-as-you-fetch pattern, where the component already has the data by the time it renders, eliminating the need for fetch calls inside the component.

I personally find this approach clean and efficient. I stumbled upon this while digging through the @tanstack/react-router docs. You’ll find a similar implementation in the Solid.js repo for Hacker News.

Of course, there are plenty of other reasons why web apps might feel slow, and frameworks are constantly rolling out new solutions. But these approaches are relatively easy to incorporate into existing codebases and can make a noticeable difference.

Hey everyone! This is my first blog, and I’d love to hear your suggestions and feedback to help me improve. I wrote this to share some solutions I’ve come across while working on codebases and tutorials, where I’ve noticed these common issues pop up. Let me know what you think!

DEV Community: Shubhajit Chatterjee

[Boost]

How I used Claude Code and git worktrees to ship 2 features and fix 3 bugs in one day

How I used Claude Code and git worktrees to ship 2 features and fix 3 bugs in one day

Background

How would I have approached this earlier

The moment of realisation

So What are git worktrees

Running Claude Code in parallel

What actually became the bottleneck

Verification

Result

How I work now

Building a single active tab experience

Core Requirements

Edge Cases

Possible Solutions

Local Storage

Broadcast Channel

Web Locks API

Conclusion

Performant Web Apps

The Problem

Possible Causes

Possible Solutions

Poorly written data fetching or async code

fetch-as-you-render & render-as-you-fetch

`fetch-as-you-render` & `render-as-you-fetch`