We are living in an exciting time. Innovation in software development usually comes in waves and AI is a massive wave that has upended the way software developers approach feature work and has accelerated the amount of work that can get done in a short amount of time. Over the last week, I have been experimenting using Claude’s Agent Teams feature in order to accelerate some of my development work and I wanted to share my experiences using this experimental feature.

To provide some context: envision a project comprising 10 distinct tasks. In a typical workflow, each engineer would independently spearhead a single task, driving it toward completion until the collective delivery of all 10 tasks culminates in the successful achievement of the overarching project objective.

For each task, we have built sufficient test harnesses to ensure the agent has successful criteria to judge its work when accomplishing a task. The agent first writes the tests that it must fail against, then writes the implementation against those tests and finally runs the tests again to ensure that the implementation is correct. It continues to do this until it gets the implementation of that task correct i.e. a test driven agentic loop.

I noticed that for each engineer, despite the task being quite templatized, it would still take them 2-3 days to complete the task along with the help of an agent guiding them through the development. So what I set out to accomplish is this - Could I run a team of agents that can accomplish not just a task, but an entire project by itself. That is when I ran into Claude Agent Teams.

Claude Agent Teams essentially allows you to have a team of agents working together in order to achieve a shared objective. The agents will have a team lead which will coordinate, organize and delegate tasks to its teammates in order to achieve the goal you’re working on. The team lead essentially is the main window and the only agent that you interact with. While you do have an option to interact with the teammates, I chose to interact only with the team lead and used the team lead to relay the message to appropriate teammates.

I set out with a prompt like this:

I am intending to complete Project X. The skills to complete a project like this are already present in this repository where the agent can go research the code in order to accomplish a task and then use the loop-until-task-complete skill in order to complete the task. However we have not identified all the tasks for Project X. You can refer to the tasks done for Project Y as a reference. Create an agent team to explore this from different angles - one to do research, few of them to accomplish the tasks (one per task), and spin out multiple merge requests for each functionality that can be reviewed by an engineer on the Team.

After sending this the agent set out to explore using subagents to come up with a plan that I can review. Another pattern I followed once I had the initial plan was to use an adversarial agent. While I did not do the complete loop in an automated fashion as the article mentions; I did use the critique received by a parallel agent, in order to iteratively improve the plan and capture the missing pieces. The plan consisted of 4 Phases:

1. Phase 0 - Creation of Tickets to track the work

2. Phase 1 - Bootstrap MR

3. Phase 2 - Research only MR to document the inventory of tasks

4. Phase 3 - Per task MRs (one agent, one task, one MR)

Each phase of the plan had a significant amount of details and I spent around two days refining the plan itself in order to get the plan correct. For each Phase, the plan consisted of a success criteria for the phase and especially for Phase 3, the plan consisted of all the subtasks that the agents would perform in order to call the task done and create an MR. Between each Phase, the team lead would ask for my explicit approval before proceeding.

Learnings

Deadlocks and Race Conditions

One interesting race condition that I had to address was the testing between the per task agents. Theoretically you could have run multiple agents at the same time to ensure that the task finishes quickly. But practically, my local setup only has one database running in a docker container and if two agents were running at the same time that would cause contention. The team lead came up with an idea to assign locks to agents that are running at the same time. However one feedback I had to provide the team lead was to ensure that idle agents are not consuming the lock thereby leading to a deadlock situation.

Interactions with Teammates

According to Claude’s documentation, you could interact with teammates directly. But practically when I was running through the gauntlet, my messages sent to the teammates directly did not get any response. However if I asked the team lead to relay the messages they would get sent just fine. The team lead was also proactive in poking the teammates if they were idle when they were not supposed to be idle and it used git commit history as well in order to determine if a teammate was hung.

Inter-process communication

The lead agent did recommend me using the /loop 30m so that I would get an idea of where the execution of the project was but I was skeptical on the usage of the loop due to the number of tokens used and pollution of the context window. While the team lead was quite responsive when I asked for a status, there are still some bugs that Anthropic can sort out for communication between the team lead and the teammates. I had multiple times when the teammates were idling (in the worst case - overnight) and the team lead was under the false impression that the teammates were performing work.

Cost

Cost for the team lead session as per /cost: $514.93 (Note: This doesn’t account for the teammates cost)

ccusage for all the entire team comes out to $3300.

Total Duration (API): 6h 37m

Total Duration (wall): 3d 2h 10m

Models used - Opus 4.7 and Haiku 4.5

This is where the savings get interesting - Our initial estimates computed close to 110 Story Points for this work. This would likely take a single engineer about 6 months to complete this effort. Since we still need to spend time reviewing this code we can cut the estimates by half. But even so that is a significant saving in effort/$ spent.

Conclusion

At the end of the 3-day session, we merged in the bootstrapping code and the research inventory and now have around 15 merge requests which need to be reviewed by myself and my teammates.

This feature from Anthropic has a lot of potential. I can see this expanding quite a lot where agents can start picking up features from the Sprint Board itself and send out merge requests that the humans then review. I do want to also use this feature for a smaller feature task in order to understand how it scales for a smaller task. I suspect I could use it a lot to avoid pollution of my main window in order to create a coordinated workflow to complete a feature.

In this blog, I intend to talk about my experiences and share some of the things I have learned along the way. Some of it I have lived through directly, some of it I have watched happen to others, and I hope a bit of it resonates with you. Please join the chat below if you would like to discuss or debate on anything related to software engineering. I am always up for a robust discussion about what folks run into in their day-to-day jobs. And do subscribe if this sounds like your kind of thing. I plan to post about once a month.

Join chat

How to get started

1. Get the Substack app by clicking this link or the button below. New chat threads won’t be sent sent via email, so turn on push notifications so you don’t miss conversation as it happens. You can also access chat on the web.

Get app

2. Open the app and tap the Chat icon. It looks like two bubbles in the bottom bar, and you’ll see a row for my chat inside.

3. That’s it! Jump into my thread to say hi, and if you have any issues, check out Substack’s FAQ.