Confused by the headline? Don’t worry, I will break it down below…

(Note: This is the second piece in my “HumanxAI” series. Please read the first one here: TreatAIAgentsAsHumans-1 for better context)

In the first article of the series, we discussed why treating AI coding agentic teams like a human team is beneficial.

But that does not mean you totally forget they are not human, because if you do, you are not taking advantage of their non-human characteristics. Rather, you want the best of both worlds, so you want to use AI’s machine-like capabilities to the hilt.

Note:

This is not about AI being indefatigable, 24 x 7, etc. All that is well understood.

Neither is this about whether humans are better than AI or vice versa. What we discuss here, like the first article, is more about your relationship with AI coding agents and the processes you set up around them to get the best of both worlds. About how you can multiply the capabilities of humans with those of AI. (“HumanxAI”).

So, let's dive in.

AI agents don’t judge you for changing your mind

I am sure you have faced this dilemma as a leader or manager - you give the team directions, they get going with gusto, and then you have second thoughts or better ideas and wonder how to ask the team to change course.

Will they think you are indecisive? Will they resent the change in direction after they have already invested time in the previous direction? What if you realise this is not the right path either and have to change track once again?

These thoughts and doubts sometimes paralyse you, preventing quick direction changes even when necessary.

Using AI agent teams frees you from such worries, allowing you to change your mind as many times as you wish.

You can try out different directions, see where they lead, and then decide the best option.

You can even come back to your original plan if that turns out to be the best, without feeling embarrassed - there is no one to judge you.

They do not get attached to architecture, design and code

If you have led, designed or built anything, you know this first-hand - we get attached to what we create. They become our babies, and we become protective of them. We become intolerant of criticism of our creation, and resist any suggestions to change.

This is why engineers, architects and tech leads can often resist making changes to code and products they have created and owned, even when the change is justified and for the better. This attachment to the past and this bias against any suggested improvements is the most common reason why changing, modernizing or updating software products becomes such a tough exercise, even when you do it only occasionally. And you expend a lot of energy and time on debating, explaining, and cajoling to convince the creators.

But with agents writing code, you are freed from all these aspects. You can ask AI to change the code from last month, last week, or even a few minutes ago.

You need not worry about change resistance, pushback or lengthy debates and explanations.

This is very beneficial in keeping your code and product constantly evolving based on your ideas and learnings and on changing market and customer conditions.

You can change your management style at will

If you are a leader or manager, I am sure you have spent time thinking about and honing your “management style”. How should you manage without micromanaging? Should you give detailed instructions or let the team figure things out?

Over time, this becomes your operating system and your team’s comfort zone. That is great until you need to change your management style due to special circumstances, or because the environmental drivers for that management style have changed.

Let me give an example.

Let us say you were giving detailed instructions to a junior team, and now that they are more seasoned, you want to give them more leeway and ownership. The team may be confused. They are used to detailed instructions and do not know what this change means. Are you testing them? Are you focusing elsewhere? To make it work, you have to spend time explaining the reasons behind the change and convince them that the new way is better and that they are ready for this. You can see how a small adjustment in leadership style can become a big cultural shock to the team.

With an agentic team, you have no such problems. You can decide when to be very detailed, when to just leave the agents with a broad brief, and when to tell them to go figure it out. AI will adapt instantaneously and seamlessly.

AI does not get bored

This is the obvious one.

Make a human team work continuously on “so-called” mundane tasks like bug fixing, code cleanup or minor enhancements, and you start worrying that they will get bored. Especially the top performers who thrive on new challenges. However, sometimes these “mundane” tasks are critical to the customers and the longevity of your software product, so someone surely has to do them.

AI comes to the rescue here. Agents can churn away at support tickets, code fixes and minor enhancements day in and day out, all year long, without getting bored, without complaining.

So, the smart thing to do is to have your rockstar team do the innovative, new, challenging stuff and leave the mundane to AI.

(Disclaimers:

1 - These are my personal views and do not represent or characterise any organisation or AI provider.

2 - No AI was used in writing this. Just like AI, I too can make mistakes. Apply your own judgement)

(However, never forget that they are not human)

Most of us treat AI as a tool, and that is natural. We have been told it is “artificial”; we have been constantly reminded that though they can emulate humans, they are not, and the human vs AI debate is never far from the headlines. How could we forget that we are dealing with “machine-generated” intelligence? Why would we treat them as anything but non-human?

Interestingly, what my experiences with AI coding agents have taught me is that knowing they are not human, but interacting with them as you would with a human, is very different from mistaking them for human. When we intentionally engage with them as humans, we get much better results.

In fact, I have realised that many of the principles of managing engineering teams that I have learnt over my decades of experience leading high-performance product teams apply equally well with agentic teams.

All you need to do is tweak these principles to align them with AI’s nuances.

(Or, shall we say, adjust the weights and biases attached to those principles?...)

Intrigued? Skeptical? Find this too vague? Let me explain further…

Engage with coding agents exactly like team members

This has already been discussed in multiple blogs by Anthropic and OpenAI engineers. They treat their coding agents like new members on the team. That is a great start, but why stop there? But do you stop interacting with your team and colleagues after the onboarding? Of course not. Do the same with your AI agents.

What does that mean? That means having watercooler discussions with your agents as you think through your project. Invite them to debates about architectural styles, brainstorm design decisions with them. Have multiple parallel agents review the design decisions, technology choices, and architectural patterns you plan to use. Have storyboarding discussions, requirement-grooming meetings, bug triage sessions—all of it.

Why?

Because conversations with agents create a rich treasure trove of shared context that tells the whole story about why and how the project and the code evolved the way they did. What the initial thought process was, the guiding principles, the design decisions. Why a certain architectural style was chosen, etc. We want to record all of this for a traditional, human-team-driven project. Why should it be different for agentic code?

Not only would this be invaluable for a human who may inherit this code, but it also creates shared context for any new agents that may build upon the existing code.

Regular “stand-up” meetings

(Note: “regular” may be much more frequent than daily)

Just as you would with a human team, you need to keep track of the progress your agents are making to make sure that everything is going as per design and plan.

However, this is where you have to be acutely aware that you are dealing with a machine that can generate large amounts of code very quickly. You do not want to find out that things are going in an unexpected direction only after a lot of code has already been written. Therefore, you need frequent check-ins. And "frequent” here may mean every few minutes or every quarter-hour, depending on the complexity of your project and the number of agents you are running.

This also means that you should design the workflow so that each agent undertakes a small, well-planned step, runs all the checks, hooks and tests to validate the output, reports these back in the “stand-up”, and gets your nod to proceed with the next one.

One more thing: the tasks given to agents must be as mutually exclusive as possible, so that the agents do not wait on each other.

In one of my projects, I asked Claude code to identify the strengths and weaknesses in three versions of a codebase, and pick and choose the best parts from each. Claude very smartly started up three parallel agents to do this, which was great. What was not great was that even though the output was provided in under 10 minutes, 5 of those minutes were just the master thread waiting on the child threads to finish!

Would you be fine with a human team where 50% of the elapsed time was wait time?

Do the practices outlined above sound a bit like an Agile process to you? You are spot on. I have realised that Agile processes are very suitable for agentic setups - but that is a topic for a different post.

Delegate wisely

(However, know that you will always be the bottleneck)

This is a no-brainer with a human team - you want to offload everything you can to the team so that you are not a bottleneck, and you can dedicate more time to the really important decisions, strategic thinking and business goals.

Do the same with your agentic teams - set them up with specific skills and roles - architect, UI engineer, back-end developer, DB engineer, quality engineer, etc.

This will ensure that each agent (or group of agents) concentrates on one area of the project. The additional benefit that the context can be specific to the role, reducing context size and tokens used.

However, keep in mind that you, or any other human in the loop, will always be the bottleneck, since you cannot work as fast and as continuously as the agents. So if you keep too many decisions on your plate, you will be endlessly busy responding to agent requests, and the agents will be slowed down because they are waiting on your inputs.

Therefore, you have to find the right balance between speed and control.

Team diversity is a good thing

You must be wondering what I mean by “diversity” of an agent team.

Well, because every human on your team is different, and therefore, between them, they can be expected to see all possible angles and cover for each other's blind spots and biases. This principle can be effectively applied in agentic teams too

LLMs and the resultant AI tools are non-deterministic and could be subject to biases and blind spots. But since each of the LLMs and tools is trained using different methods (in fact, even the various versions from the same provider can be very different), a mix of LLMs and tools can help you use them in antagonistic ways to cross-check each other and cover for biases and blind spots.

I know that using a bunch of different LLMs from different providers may not be practical for most of us, however, we can and should create diversity within our agents by giving them different roles, different “personas”, if you will, asking them to look at things from various angles, and provide them with diverse context and background on information so that they can bring in different perspectives to a problem or cross-check and double-check the output of another agent.

Remember, it is not possible (or advisable) to manually check the vast amounts of code and documentation that the agents will spew out. So you must set up automated checks and balances that give you some confidence that serious errors or omissions do not get past your guardrails, and a diverse team of agents is one way to move the probability in your favour.