Mohit Aron, a proven tech founder of two multi-billion dollar technology companies, Nutanix and Cohesity.
The job of a leader is to build a system. So if you give people the right system, they will plug into it and they'll do well. The job of the CTO is also to build that system.
When you are hiring engineers, are you testing them any differently now?
My personal opinion is that you should test them the old way. Because if you have a person who's well grounded in software engineering concepts, then after using AI they become 10x. But if you hire a bad software engineer and maybe they pass your interview by using AI, they'll actually create a mess. You need to understand that even though AI is writing the bulk of the code, you need to own the code because when the problems happen, it's not AI that's accountable. It's you who's accountable.
Once they're in the door, are you keeping them accountable on token usage?
We monitor their productivity. While AI is good at pattern matching, AI is not good at core innovation.
Thanks so much for taking the time today to talk to us. The topic I want to talk to you about is the role of the CTO in the age of AI for a startup, right? You have been a technologist right from the Google ages and you have been a co-founder multiple times. Let's start from the fact at an early stage, what is the role of the CTO? We'll go to like how's it changing in the age of AI?
Not just the CTO but any leader. Their role is kind of, I look at it as a T. The leader should stay on the horizontal part of the T. So basically they're overseeing everything in their organization and then when they see something is wrong then they can descend down. This is the vertical part of the T. Help fix it and then ascend back. Now if everything, when they stay on the horizontal part, if everything is kind of looking good then they have the luxury to do whatever they like to do. Maybe as a hobby they can actually do coding or whatever, right? But as a leader they owe it to the company, to their organization, to first and foremost have that horizontal part of the T, stay on the horizontal part of the T and make sure that everyone else is working. So that's one way to describe a leader.
Another way to describe a leader is the analogy to a traffic system. So the job of a leader is to build a system where the whole organization follows and adheres to a system. It's not haphazard. It is not the left hand of the organization is doing something very different from the right hand of the organization. And I bring that analogy out to the traffic system. So notice that we are here in California. The traffic system is pretty good. You know both of us grew up in India. You know let's talk about Delhi. The traffic system is a little bit haphazard, right? It's the same people who will drive well in California and drive badly in a place like Delhi. So it's not actually the people, it's actually the system. So if you give people the right system, they will plug into it and they'll do well. So the job of the CTO is also to build that system, right? What is the system? Like how do people innovate? How does new innovation happen? How does development happen? Right? So what sort of messaging emanates out of the company, right? How do you talk to external people? So these are all the roles of the CTO but they ought to follow a system.
When you look at this system in the age of AI, this system better incorporate things where it helps the developers to leverage AI more. And so the CTO first and foremost needs to be very familiar with the latest in AI. For instance, how to use AI-assisted coding tools efficiently and the system he or she builds should be such that his or her team then adhere to that system so they all become like 10x engineers as opposed to just the CTO being a 10x engineer, right? So he or she needs to build that system.
Makes sense. And going back to the first part of like the role of the CTO, let's say you have in your companies, to the first pre-product, you had almost had five or 10 engineers at that point, and are you building, I know you are famously building at every scale I've heard, but are you building along with them side by side or you are...
From a very early on you take the sort of horizontal role. So while you're always on the horizontal, because you have less people in the team there isn't that much to do at the horizontal level, right? This is why I'm saying once the horizontal is good then you descend. So in the early stage of the company, the CTO is building side by side. It is doing more. So it's more player-coach where coaching is less and playing is more. But as the team gets bigger, the coaching becomes the bigger part, right? And the player only happens when you have time away from your coaching responsibilities. It's a natural progression.
And we were talking about let's say moving to the AI impact on technology development. Let's say there is a design and sort of design and architecture development phase, the coding and development phase and then the you know DevOps, security, infra phase. You were mentioning off camera about how you think about let's say coding and like pre-AI, post-AI, how do you think about that system? And interestingly your view is it hasn't changed fundamentally post-AI. Talk about that.
How I personally do stuff before AI, right? What I, obviously there's the design, then the first thing I would do when I'm ready to implement, I would put boundaries around whatever I'm implementing. Correct. Right. And so think about that boundary as coming from let's say the API. So the API kind of makes sure that whatever else sits outside, it's a boundary, right? So the API consists of an input and an output. So that puts a boundary on what the software piece is doing. So you first define that, right? And I'm still talking the pre-AI era. Then what you do is now that the API is defined, you will define the intermediate state for your software wherever you're building. Then the next step, once you've defined that intermediate state, so as your software is executing, doing its compute, that's the intermediate state. And then what you do is you'll sort of define a path from the input to the output. And along the path you will lay out your functions. So you build skeleton functions and one by one you'll start populating or implementing those functions. This is what I used to do and this becomes again, this was my system for efficiently coding stuff.
Now what I've done is I've incorporated all of this in AI. Yeah. So if I'm using an AI-assisted coding editor or what have you, the first thing I would do, I started by saying that you first need to design well. Let's think about once you've designed, maybe you have a team of architects, you've done that design, then here is a software piece that I have to write. So I would in natural language I would write a spec for that. So this is a spec that eventually AI will use. And I actually even use AI to write that spec. Right. I'll keep telling AI do this, do this, do this, and unless we are happy with that spec we're not going to move forward.
So now that we've written the spec, the next thing I would do, again I'm going to follow the same path that I used to before AI. The next thing I'm going to say is I tell AI look at the spec and build the API. So it'll build some API. Maybe that API needs to be tweaked. So either I'll tell AI to tweak it or I'll do it myself depending on the situation. Once the API is finalized, the next thing I would do is I would say okay now let's build the intermediate state. Again AI will do it and again I'll tweak it. Then I will say build the path from the input to the output, build all those skeleton functions. Now I'm not typing. It's the AI doing the typing, right? So now it'll generate something. I may like some of it, I may not like some of it, but I will ask AI to fix it or I'll fix it manually myself. Then one by one I'll tell AI to start implementing those functions.
So now notice how I'm guiding AI all through. And this makes for actually a very symbiotic relationship with AI rather than telling AI, hey, just go do everything, right? Which makes, you know, AI may hallucinate and generate some very bad stuff. But when you guide it this way, it's actually basically doing what I wanted to do and the quality is pretty good.
I don't think this, just what you just described, 99% of AI developers are not doing that.
They're not doing it. And you saw the Amazon mishap which happened, right? They just put out the code and I don't know how much of it is real. So with that caveat, but I can totally imagine that, you know, yeah, you need to understand that even though AI is writing the bulk of the code, you need to own the code because when the problems happen, it's not AI that's accountable, it's you who's accountable.
Right. So this code is like even though AI is writing it, you own it and so I need to guide AI how to do it.
Right. And so AI can just do it faster, but let me guide it, right? And it does something, I'm reviewing it and okay this is good or maybe it needs a few tweaks, then do the next step and the next step and the next step. This is how it's done.
You should trademark this approach or something like Mohit's AI coding strategy. Because what you just described, if you're designing the system, you are putting checks, intermediary checks or unit test or functional test or whatever, like we can call it anything, but logically you're designing the system, you're putting the checks in place, you are checking at the functional level and the AI is filling the gaps at every point. And so predictable outcome.
The unit tests are actually interesting. That's where once this is done, then I ask AI to actually write a unit test and there I'm actually a little bit more flexible. I'm actually okay, Mr. AI, just go generate a test because you see the unit test is not something that's running in production. The unit test is something I don't have to review line by line. I just have to roughly see the logic. Hey is it testing all the corner cases? Is it testing various conditions? As long as it runs and passes and it's kind of testing the various edge cases, I'm actually good with it. And so the way I write unit tests using AI is actually very different than how I write production code using AI.
