Treat your AI coding agents like humans, and they will reward you!

(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.

(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)

God could not be everywhere – so he made man invent “digital”.

An interesting experience the other day made me stop and think about this phenomenon called “digital” that has everyone so excited.

I was driving to work and stopped at a gas station to fill-up my tank. However, when I reached for my wallet, I realized that I had left it at home. I had no cash or cards with me. I panicked. I was already running late. Neither could I drive away, nor did I have the time to leave my car and go back for my wallet! In that dark moment came inspiration. I did have my mobile! So I fired up my mobile-wallet app, scanned the QR code at the gas station, paid with a click and was on my way in a jiffy. Woohoo, “digital” to the rescue!

That set me thinking. Why was this experience so powerful? This was like having an ATM where I needed it, when I needed it! Not only that, to the vendor, it was like having a cash-register connected directly to their bank account. If the gas station had a NFC capable POS, I could have moved cash from my bank to their bank by just waving my phone! “Digital” is omnipresent. Bank accounts, health data, weather information, maps and directions, public records, music, movies, books, real-time video from across the world, a dictionary or the complete encyclopedia – you name, you have it – whenever you want it, wherever you want it. Today, it is with us through gadgets and wearables, and all around us in thousands of digitally-enabled “things”. Tomorrow, it will be within us through implantable chips. And one day, at the moment of singularity, when the boundaries between brain and chip dissolve, it will be us.

Is this just about being everywhere? No, that is just the beginning. Not only is “digital” everywhere, it is also interconnected. An internet of digitally-enabled “things” bound together in a myriad of connections, talking to each other, exchanging information, acting in collusion. And, when the light of AI and analytics is thrown on this vast pool of interconnected data and events, “digital” becomes omniscient. The Google map in my car can see the data from all other cars along my route to tell me that I am heading into a traffic-jam, immediately sifting through all other possible routes to come up with the best alternative - all this, while continuously communicating with a satellite thousands of miles up in space! If that is not a pretty good definition of “all-seeing”, tell me what is.

Now what happens when these astounding powers of digital are coupled with robotics and sensors? The results are truly magical. Scientists can effortlessly control a Mars rover millions of miles away, surgeons can conduct extremely complicated surgeries remotely, cars drive themselves and warehouses become completely automated! “Digital” is becoming omnipotent. As more things become digital, as computing power multiplies and as more and more data is collected, the possibilities of digital keep expanding.

But why now? Why did the digital curve jump the chasm only recently? To explain, let me take you back to an interesting product that I built more than fifteen years ago as part of a team at HP’s Advanced Technology Labs. We were building a banking product based on “Zero Latency Enterprise” technology. While a customer withdrew cash at the ATM, a recommendation engine would do a near-real-time analysis of the customer’s relationship history, and come back with personalized up-sell and cross-sell offers on the screen. If the customer opted-in, an email would be sent to the salesperson’s palm-pilot to initiate necessary action. This was as close to “digital” as you could get fifteen years ago. But the ecosystem that truly propels digital to its current omnipresent, omniscient and omnipotent capabilities simply did not exist in those days. Our recommendation engine did not have the insight into the customer’s online activities, social circles, loyalty and credit cards, location history, online and offline purchases, club memberships, investments, online-trading transactions – the mountain of data that is available today. Nor could we reach the customer anytime, anywhere through their smartphone to make offers at the point of purchase or to send location-aware promotions. And, AI and robotics were still in their infancy. You can see how the possibilities would be limited even a few years ago.

“Digital” has come of age today because the network effects of the Internet of Things has crossed a tipping point, compounding the impact of the technology. I am not omniscient enough to see where this new technology wave will take us, but I can definitely advise you to grab your surf-board and start riding this wave – and be prepared for a wild ride!

So you think you are a Technology Company? Think again.

I was recently asked to speak on technology at our company town-hall, and since our company is in the middle of a transformation to a “Technology Company”, I decided to make that the anchor-point of my talk. Why? Because I have found that most companies and their employees do not really “get” this concept, leading to many interpretations and confusions and hence resulting in lost opportunities. I wanted to make sure our employees got it right.

As I thought through my talking points, I came up with a small list of misconceptions about what a Technology Company really is. I decided to share all the thoughts I had gathered here, in anticipation of an interesting discussion and feedback from a larger forum…

So what is a “Technology Company”? The most common explanation I have heard is - a Technology Company is one that effectively uses technology to be successful in business. If you let yourself believe that, you are in deep trouble, in my humble opinion. Merely “using” technology may have been a good strategy in the 70s and 80s, but today, being technology-enabled is just “table stakes”. Can you name any business today that has not adopted technology? You can’t, right? Even local mom-and-pop shops now use mobile-payments and take delivery orders on Whatsapp. So, would you call all of them Technology Companies? I am sure you wouldn’t. So, what is it that Technology Companies do differently?

Well, to answer that, let me borrow a term coined by Tom Peters. The term he uses is “Re-Imagine”, which I think perfectly captures the essence of what I am attempting to convey. Technology Companies are companies that use Technology to Re-imagine business, rather than to just automate or enable existing business. They use technology to find completely new ways of doing business, they even invent new kinds of business on the strength of technology. At a Technology Company, technology defines business, rather than the other way around. Ask the big banks, and they will tell you how they thought interconnecting their branches and installing billion-dollar “core-banking” systems to centralize their operations would be all the technology play that was needed, only to be left gaping at upstarts like Atom (UK) and Ally (US), the new “online-only” or “direct” banks, that have redefined (Re-Imagined!) what the banking business is. This quote from an article in Wired magazine (http://www.wired.co.uk/article/digital-only-banks) sums it up nicely – “I could make a compelling argument to say that Atom is actually a data company that happens to have a banking license”. Well, there you have it. I could not have put it any better myself. But wait, it gets even better – “Atom's competitor, Mondo, is perhaps best known in the tech world because it has run a series of hackathons to imagine new banking functions”. See what I mean?

The second common fallacy I find is the idea that Technology Companies are about the latest and greatest technologies. I have seen companies become a veritable museum of new technologies, in an effort to embrace all that is new and shiny, thinking that just being on the latest technology will give them a business advantage. They keep building “Next-gen” versions of their existing products using new technologies, thinking that will automatically make the product better. No. Technology is just a tool, it is how you use it that counts. Yes, the latest technologies may have capabilities that could give you advantages, but only if you apply those capabilities to business in innovative ways. Try this exercise. List out the top 50 companies by R&D spend. Next list out the top 50 innovative companies. See how many names in the two lists match. Surprised at the lack of co-relation? You shouldn’t be. Re-Imagination happens when business ideas and technology capabilities come together in previously un-conceived ways to result in completely unforeseen outcomes. That is why it is so difficult. That is why it so often blind-sides established players. And, that is why it is so valuable.

As I was finishing up my preparations for my talk, I tried to anticipate counter-points that would come up, so that I could go in prepared. One of the top questions I knew folks would have was – “Hey, we have been in this industry for decades, and have unique knowledge and expertise in the domain, and that is our biggest competitive advantage. Why do we need to become a Technology Company”? Very good question, and many companies think along these same lines and go – “Oh yeah, that’s right! So, if I use technology to automate or enable these unique business strengths I have, I should be a winner on all counts, right”? Umm…hold on. I know that logic sounds very reasonable. But don’t jump to conclusions yet, follow me closely here. The problem is that your “unique business knowledge and expertise” is competitive in the context of how business is done today! It is tuned to the way the business works today. What if the context changes to a “Re-Imagined” way of doing business? Would your well-practiced orchestra go completely out of tune? Would your years of in-grained processes and culture make it all the more difficult to turn the ship and catch a new prevailing wind? You bet it will! Tell me, did Amazon have decades of experience as a book-seller? Or was Uber a taxi-fleet operator for a century? They are true examples of how Technology Companies change the game.

Well, that brings us to one final interesting question – if you are a true Technology Company, do you always remain so? Can you rest on your laurels and be assured of continuing success? Aha! Life is never that simple. Remember, you rose to ascendancy because you were the first to use technology to “change” how business was done, so if you stop changing, what happens? Yes, you are right; your competitors will soon catch on. What was unique to you will soon become established business process! Your days ahead of the pack will be numbered, and soon the herd will be all around you. And now, you will be as susceptible as the others to a new upstart who changes the game again. So you see, to retain your Technology Company badge, you will have to continue using technology to change the game. Look at Facebook, the guys who wrote the rule-book on social media. They are now trying their best to catch up to the new brats in town – Snapchat and Instagram! The only company (that I can think of) that has relentlessly held on to the Technology Company badge is Apple. No wonder both their customers and their shareholders love them so much.

Hope I was able to get you to think differently about this topic. So, what do you think? Do you agree? Which of the fallacies listed above have you encountered? Do you have some more examples? What are your examples of great Technology Companies? I would love to know. Or, do you disagree? If so, please enlighten me with your point of view through your comments.

Flying the product kite - creative tussle between Product Management and Engineering

If you have built software products as part of either Engineering or Product Management, I am sure you have often wondered why these two roles sometimes seem to be at cross purposes. Product Management always seems to want the greatest features now, and engineering always seems to be explaining why a feature is technically infeasible or difficult to complete in so short a time. You are very sure both sides are trying to bring their best to the game, and you keep wondering how they can play better as a team.

These kinds of experiences led me to the need for a simple analogy describing the relationship between Product Management and Engineering - something that teams could easily grasp, something that would stick. So where did that search lead me? It led me back in time to the days of childhood and the joy of flying kites!

In my model, Product Management can be pictured as a kite, soaring among the clouds, with Engineering as the little kid on the ground, holding the string firmly. Please see the picture below the next paragraph, where I have attempted to represent this visually. (Note : This is just my way of looking at this relationship. You readers may have other ideas or opinions. I would love to hear about them, and I look forward to your comments)

Product Management is up there facing the winds of change blowing through the business environment, trying not to be left behind. They have their head truly in the clouds, thinking up grand new features to leave competitors languishing in the lower echelons. Being up high, they are also able to gaze at distant horizons and see the future of the industry, and they may also look through their telescopes at other kite-flying teams to see what the competitors are up to. Engineering, on the other hand, is the kid running around on the tough technology terrain, trying to avoid prickly technical problems and the hard rocks of architectural dead-ends. They are the anchor, grounding the product in solid engineering, the voice of practicality and logic and reason that keeps the kite from being torn apart by the wind or snared by the electric pole. And just like the skillful interaction between kite and flier helps them reach new heights, close coordination between Product Management and Engineering is the only way to launch a successful product and keep the organization's banners flying.

If you have flown kites, you know that the only way to make the kite rise is to pull on the string, against the wind. Similarly, Engineering needs to have a firm hold on the string to help and guide Product Management through turbulent business scenarios. Another thing you will also know from your kite flying days is that to get the kite higher up in the sky, you need to successively pull on it and release the string to allow more and more of the string to play out, carrying the kite higher and higher. This is very important for Engineering to understand. The successive pulls on the string are equivalent to engineering hardening of the product where feature-creep is kept on a tight leash and the product resilience and performance is improved. The successive relaxations of the string are the innovations, hackathons, new technology adoptions and release marathons that Engineering undertakes to feed Product Management's needs for better features, improved user experiences and insightful business intelligence.

Kite-flying disasters are quite common when either of the parties stops playing as a team. An unruly kite that fails to respond to the inputs of the flier ends up in tatters or high-up on a tree, and a flier that pulls too insistently on the string is left with either a stalled kite or a broken string. These are important lessons for Product Management and Engineering to keep in mind.

By the way, in no way do I want to imply that these roles of kite and flier are rigid and exclusive. Far from it. Good engineers are expected to understand business and be aware of developments in the domain, and if they do, they can also become partners to Product Management in driving features. I have seen many instances of this happening. I have also seen equally commendable cases of Product Management being cognizant of the challenges faced by technology, and working with Engineering to create a road-map that provides enough space for deep technology transformations. So yes, the parts played by the kite and flier can overlap, and they often do. However, the analogy presented here does provide a very simple story of what the generic and ideal relationship between Product Management and Engineering should be like.

What do you think? Do you see your kite-flying lessons being as handy in product development and engineering as envisioned here? Or do you feel that product development is too serious a sport to be compared with mere kite flying? Do let me know through your feedback.

Technological Advances, or just "degrees of separation"?

I am very sure you have heard about the "Six degrees of Separation" theory as a party-topic or at the office water-cooler. Interestingly, as computer hardware, software, and networking have advanced through the ages, computing has gone through its own "degrees of separation".

In the beginning, everything was one big block - the hardware, the OS, the applications - everything came from the same vendor and ran on the same box that took up the space of a house! Things were simple, it was a close-knit family living in a single room.

Then, in the mid-to-late 1960s, the first "application software" was developed and sold by a third party. This was a major step, since till this point, the business software applications used to be bundled along with the hardware and OS, and no-one thought it could be any other way. Now, the computer hardware companies were joined by a new class of software companies - the Independent Software Vendors. Thus were the giants like Microsoft born.

Meanwhile, the dumb terminal had separated from the mother-ship, and we were on to the next era of separation - the client-server era! This hardware separation was soon copied into software-side separation too, and voila, we had our "two-tier architecture"! Well, three is always better than two, right? At least the architecture pundits thought so, and stretched the two-tier architecture to create the new "three-tier-architecture", leading the English dictionary to create space for a new word in our vocabulary - "middleware".

Things were going well with the three-tier world for some time, and then the industry was bitten by the separation bug again. We started hearing about "distributed" systems. Everything could now be distributed - services, servers, databases, disks - and they could be distributed around the room, around the data center, or across larger LAN/WAN setups. We were now in the world of "n-tier" architecture, and our single-room-dwelling family had now separated, divided-up into hundreds of sub-members, and sprawled out across town and country.

However, the story was far from over. Before we had time to lament the break-up of the close-knit family and their scattering all over terra-firma, the separation drama reached for the clouds. And when mobile joined the party, things went really crazy! As I sit here and type on my web browser, it looks like it is all happening on my lap (now, don't get any ideas, all I mean is it is happening on my laptop...), but in reality, the server sending me this page could be anywhere on earth, the database storing my words could be at the other corner of the globe, and my precious text could be merrily flying around clouds, traveling over thin air or undersea cables. It truly is mind-boggling. The single-room dwelling is now a global village. How separated is that?

But why limit our thoughts to mere earth? The farthest computer today is probably on the Voyager 1 spacecraft which is a mind-boggling 20 million kilometers away from the earth and counting, and if a client on earth were to "ping" the server on Voyager 1, it would take about 38 hrs. to come back with a response, since that is the round-trip time for light to Voyager 1! (http://voyager.jpl.nasa.gov/where/) Talk about a really slow network!  So, it is not hard to imagine the day when our computing cloud would be separated across millions of miles of intergalactic space.

Well, enough about separation, it is time for my separation from this close-to-too-long post. See you soon in my next post.

The Success Paradox

I have been advising many customer CTOs and VPs with their product strategies, product roadmaps and modernization efforts. In the past I have also led new product developments, and have had engineering ownership of a mature banking product with over 500 customers. Looking back at what I learnt from all of this, I realize that I see a clear trend here - the more success a product has had in the recent past, the higher the chances that engineering is nearing a dead-end. The higher the past success, the more difficult it is to achieve the next leap in engineering for future success of the product. And, on top of that, the longer you wait to take the next leap in technology and engineering, the worse it gets.

Why does this happen?

Let us assume you head engineering, and have started building a new product. You have a clear vision of what the product needs to do, and how you are going to achieve it. The design, architecture and roadmap of the product is based on this initial vision. The choice of technolgies and tools is similarly based on current needs and current availability. Everything goes well in development. You release the product into the market and sit back and relax, expecting to keep working on the roadmap at your pace and priority. Suddenly, your product picks up! You have new customers signing up every day and guess what, your plans are hijacked. The business wants to capitalize on the momentum and starts pressurizing you into providing new features faster, features that you have never planned for. Customers start getting pushy about their defects and their feature requests. The load on the system keeps increasing dramatically. You hire a larger team, go with the flow, start churning out releases by the dozen, add many new features, increase the infrastructure footprint, integrate with a bunch of partner products....you are running just to keep up!

The years fly by, and one fine day, business comes back and tells you - "the product is not good enough, and engineering does not seem to be able to give us what we need in time". What?! Are we talking about the same product that was beating the charts 5 years ago? Yes, we are. Unfortunately, while you were busy fixing bugs, adding new features, improving performance to meet the increasing load on the system, and fighting off impractical feature requests, the world has moved on. Competitors have come out with cooler stuff built on newer technology. Their solutions are more modular and can integrate with other services. They are more nimble and agile. On the other hand, your technology, that was shining new at inception is now rusty, your architecture looks dated and monolithic, your interfaces are not open enough. And guess what, over all those years, as you were madly keeping up with "Business as usual", technical debt has been silently creeping up behind you. The trickle of technical debt, that you always planned to catch up with in the next release, is now a mountain, blocking your way to agility, nimbleness and efficiency. Each new feature now takes longer to develop, and is costlier. No wonder business is complaining!

I see this story repeated again and again.
So, what is the solution?

Well, once you get to this state, there is no easy way out. So, my suggestion is, never let yourself get to this stage. Keep "watering the roots" - keep looking at ways to improve the architecture, keep refactoring and catching up with tech debt, keep an eye out for new technologies and trends and adopt what is necessary, keep in tune with business strategy and align the product roadmap accordingly, and of, course, use an Agile or Lean development methodology. These would help, but would not insulate you completely. You will still have challenges. But just being aware of the paradox and taking adequate steps should make life much easier.

Web 3.0 - are we there yet?

We are now all too familiar with Web 2.0. It has been around for sometime, and we have heard a lot about how it has transformed the world of internet. Now, with the advent of HTML5 and the rapid developments in "rich media" and "responsive web", Web 2.0 already seems like a relic from the past. So why are we not getting to Web 3.0 yet?

Don't you know, Web 3.0 is already here! "Why did I not hear about it?" - you ask. Well...remember, Web 2.0 was more a marketing terminology than anything else. It was used to put a label to the state-of-the-art web at the time, it was a handle technology marketers could use. It was never really a "technical specification". So, though I find that in many ways, we are already into Web 3.0, we are still waiting for someone to turn on the marketing and publicity blitz to make us sit up and take notice.

Why do I say we are already into Web 3.0? Just as Web 2.0 was defined by a few major things - democratization of web, Asynchronous Calls (AJAX) and Subscription and feeds (RSS etc), Web 3.0 is supposed to be built on four key concepts - semantic web, personalization, artificial intelligence and "anytime anywhere" access. All of these are already available today in some form or other! Twine, which was first announced way back in 2007, was a good attempt at a semantic web. Though it did not succeed, it still laid the foundations. Today, many social networking and search sites use semantic search. iGoogle is the best example of personalization, and it is very much here. Artificial intelligence is evident in many of the features of popular sites, be it the graph searches of Facebook, or iGoogle, or Siri. And need I say anything about "anytime anywhere"? It is one of the most heard terms these days.

So believe me you, Web 3.0 is already here! If you are interested in knowing more about Web 3.0, this site has links to some wonderful material.