My team lead went all-in on AI this year. Here is what 6 months as an AI agent orchestrator taught me.

By Christopher Trux, Fullstack Consultant at Netlight

"I don't want any more human written code by Summer, by then everything should be done via agents". That is what our team lead told us one morning in late February and back then I thought it was quite an ambitious statement. Only a handful of people on the team (me included) were coding with the use of AI agents at that point and were still finding their ways around this new way of working. The rest of the team was still coding and working way more traditionally. Despite that the direction was clear: the client bet big on AI and saw it as the future of software development. And to reach the goal set by my team lead I had to not only learn to code with AI but to also turn into an AI Orchestrator to be able to unleash its full potential.

What does that look like? Imagine a big orchestra. Many different instruments working independently but creating a symphony together. And just like that agents allow the user to work on multiple problems at the same time, they just need to be managed. Remember, the goal is no more human written code, so we need the tools to take us all the way from the idea for a feature to the finished code review. The question is now: how do we create the music and what do we need to play it?

Of course, the most essential thing you need to make music are the instruments. In our case the instruments are agentic-devtools: an agentic development tool written in Python that was created by a team member. It is a CLI toolkit for AI-assisted development that breaks down the development lifecycle into dedicated steps and workflows that standardise and automate development with strict quality and policy enforcement. It provides a set of commands that wrap common development operations (git, testing, Azure DevOps, Jira) with background task management and workflow integration. It is designed for AI agents and ensures consistent workflows and enforcement of coding guidelines and best practices. For our project we are using Azure DevOps which does not come with many built-in AI features as of now, which made this custom solution necessary.

Now with the instruments set, you also need a great musician that can make use of the tools provided. The star of the show in our case is GitHub Copilot and more specifically the VS Code extension. It acts as the developer and does all the tasks that I would usually do like updating tickets and writing and reviewing code among other things. Meanwhile, I stay in the loop to give directions, define specs and give my own review and final approvals. What this achieves is that it frees up time to work on more creative and value-creating topics, while the agent takes up the implementation busy-work.

With the musician side covered, we need some music to play for our artist. And this is where the agentic-devtools come back into play. Like a setlist or a programme as it is called in orchestral music. It provides us with a set of music pieces that can be played either individually or in a set order. These pieces are the workflows that come included with the toolkit and as mentioned above they represent different steps of the developer lifecycle. Overall, there are seven of them. One to create a Jira issue, one to break down an issue into subtasks, one to update an existing issue, one to optimise an issue for the AI agent, one to do the actual implementation work, one to do a pull request review and finally one to apply suggestions by other reviewers. And to continue with the music analogies each of these workflows has a predefined series of steps just like notes on a music sheet. These steps tell the agent what to do in which order and ensure consistency across multiple iterations of the workflow. Depending on the complexity of the workflow and task the number of steps differ but in general they all work similar.

Now that was a lot of talk about what it takes to make music, but as of now our Copilot is still a solo artist. However, in the beginning I spoke about the need to become an AI orchestrator to unlock the full potential of this new way of working. So, what is the final puzzle piece that allows us to turn our solo artist into the full orchestra? One word: parallelisation. And git worktrees allow us exactly that: to work at multiple different points of the application at the same time without interfering with each other because changes are isolated. That's why each workflow checks if there is an existing worktree for a certain issue and if not creates a new one to act as a sandbox environment for all the changes to be made. This way, we can tackle multiple issues at the same time.

Now all of the pieces are in place to become an AI Orchestrator and after around 6 months it is time for some takeaways. On a personal level, it was very unusual to hand over the reins at the start and let the AI do all the implementation. My daily work was changing quite drastically. Away from writing code towards working more on the bigger picture. On top of that, the reversal of roles led to some questions of "Why am I still here, if the AI does the implementation?". But over time I also learned that this role reversal gives me much more time to focus on other tasks and topics. This allows me to spend more time discussing and defining specs, which in turn also improves the output created by the AI. Starting out it was not immediately clear if the AI would deliver quality results and while the toolkit is also being refined constantly, in the beginning you could see some differences in approach between Frontend and Backend tasks, with Frontend tasks needing much more specific inputs to get the UI side of things just right.

However, to achieve the overarching team goal, the rest of the team also needed to be onboarded to use the new tools. The toolkit was still a work in progress and needed some further testing and refinement. As a result, a kind of divide was created in the team between AI users and people who could not use it right away. This led to a few interesting processes happening within the team. The AI agents not only change our ways of working but also how certain tasks are done. For example, a pull request reviewed by AI will look much different to a human-reviewed one. The AI will post a comment under each file with a reasoning for approval or change requests, which will add up very quickly. If you cannot use AI yourself to apply the requested changes, this new style of PR can seem a little overwhelming and might create some distrust towards the tool on top of pre-existing concerns regarding the quality of the code. But once more and more people were onboarded and got to use the agents and get a feel for them, these concerns slowly started to fade away.

The team got used to working with the agents and soon after the pace in the team started to pick up noticeably and we got tasks done much quicker that used to take lots of work. This is not only true for new features but also for improving existing code and identifying and fixing bugs. While in the past, adding tasks from the backlog to an ongoing sprint was an exception, it has now become more of a regular occurrence and has allowed us to rethink how we plan our sprints and goals.

Back in February, my team lead said he did not want any more human-written code by summer. Six months later, I would say we are close, but what I have really learned is that the orchestra doesn't replace the conductor. It frees them to do what only they can: hear the whole piece at once and make sure it tells the right story.