Most AI initiatives don’t fail because of weak models. They fail because they collapse under real-world complexity. This episode breaks down how CTOs and business leaders can design AI systems that survive messy data, unpredictable users, and production reality.

You’ll learn how to shift from “build a model” thinking to system-level strategy, manage AI as a high-risk investment, and align business expectations with technical uncertainty.

Key Takeaways

• Why AI success depends more on system design than model performance

• How to build guardrails, monitoring, and rollback into AI from day one

• The “VC mindset” for AI investments and why most initiatives will fail before one works

• How to align CEOs and boards around uncertainty, cost, and probabilistic outcomes

• The real reason AI breaks in production and how to anticipate failure modes early

• What skills modern AI teams need as roles shift from building models to orchestrating systems

About Sairam

Sairam Sundaresan is an AI Engineering Leader with over 15 years of R&D experience. Currently leading autonomous driving research at Valeo, he has a history of innovation at Intel Labs and Qualcomm, backed by a portfolio of patents and publications.

Beyond his technical roles, Sairam is deeply invested in the growth of the AI ecosystem. He has mentored countless engineers, served as a Lead at the Frontier Development Lab (FDL) applying AI to space science, and actively advises business leaders on AI adoption.

He is also the author of the book 'AI for the Rest of Us' (Bloomsbury) and writes Gradient Ascent, an illustrated newsletter read by over 25,000 subscribers. Through these channels and his LinkedIn following of over 100,000, he is one of the industry's most trusted voices for making AI accessible.

Chapters

00:00 Industry Real World Failures

05:26 Reliability of AI Models

11:24 Ad

11:57 "AI for the Rest of Us"

16:28 Starting With AI

24:54 Explaining AI to the Board

27:37 Ad

27:48 AI Unrealistic Expectations

32:42 What kind of People does AI Demand?

36:49 Keeping Up with AI

39:15 AI Predictions

Where to find Sairam

• Website: https://newsletter.artofsaience.com

• LinkedIn: https://www.linkedin.com/in/sairam-sundaresan/

• Instagram: https://www.instagram.com/artofsaience/

• YouTube: https://www.youtube.com/@artofsaience

• His Book: https://www.amazon.com/AI-Rest-Us-Illustrated-Introduction/dp/B0F29THNLT/

One of my favorite phrases, I don't know who said this, but I really love it, which the model doesn't change, the world around the model changes. And so that I think captures everything that can go wrong with AI systems. Just having that mindset that you need to be vigilant. And you need to be paranoid. That's the best way to build robust and reliable systems.

Welcome to the CTO Compass podcast. I'm your host, Mark Wormgoor, tech strategist and executive coach. In every episode, we meet tech leaders from startup CTOs to enterprise CIOs to explore what it means to lead in tech today. They share their stories and their lessons so that you can navigate your own journey in tech. Let's dive into today's episode. Most AI projects these days don't fail because the model isn't smart enough. They fail because the model can't, or because the system can't survive reality. The demo, it often works and the benchmark looks great.

And then you get real users, you get a lot of messy data, chaos, and real business processes and real business users that hit the system. And the system often breaks down very quickly. CyROM spent over 15 years building AI. Way before Chet's GPT, machine learning, we'll talk about that. And he knows where failure shows up when it hits the real world. He now leads perception and AI R&D at Vallejo, where they're developing computer vision systems for autonomous vehicle. Really cool.

Before that, he's built machine learning systems at Qualcomm and Intel, and he's mentored machine learning team for NASA's Frontier Development Labs. Very cool background. He wrote, and that book was launched last year, the AI for the rest of us, and he writes the Gradient Ascent newsletter.

So, focused on helping people, regular people, understand how AI systems really work and really behave. Sairam, welcome to the CTO Compass.

So, Let's dive right into it and let's get into the background of that. You've been working on machine learning systems for, well, over 15 years. When did you first encounter those real world failures and when did it all go wrong?

I think pretty early on. The first time I encountered it was when I first moved from academia after my post-graduation to the industry, where in academia, you typically have these very clean data sets and you have these toy projects and everything works well. And you can almost always say where the bug is. Then you move to the industry and then you write code, you train a model, everything looks great. I'm not even talking about neural networks. I'm even talking about classical machine learning at this point.

And then it actually goes out to different teams and then all hell breaks loose. Like one easy example is you can consider a model that's maybe something that you have trained and it has to go into a phone, for example. It has to be optimized, meaning that it has to be quantized. And the first thing is that when you quantize a model, the performance, the accuracy or any other metric that you're talking, tracking for quality, you'll notice an immediate problem.

And then the challenge is like, how do you work with your colleagues to figure out why that's happening? That was the first experience.

And then since then, there's been like cascadingly bigger things that, you know, where things have hit the fan, but it's all been a wonderful learning.

Experience. So what's an example of something that did actually get through something that hit the streets where afterwards you thought, Maybe we shouldn't have done this. Maybe... Where reality broke the system almost immediately.

I think the easiest example that comes to mind is there was this project where we had to deploy a model to track objects to the camera and it sounds simple enough. And then the problem was the tracker had a lot of drift and for those who might not be familiar, object tracking is when you are basically focusing on one or more objects and then seeing how they move through your feed. And In order to save power and processing, you employ something called a tracker that, you know, you don't need to have a model that detects where the object is every time. But instead, you use a tracker to say, okay, it was here. Most likely, it's going to be somewhere here.

And then the problem with those trackers is they have a problem like drift, which is the predictions are always noisy. And the longer you use a tracker, the more noisier it gets because the current estimate is based on what you estimated before and then before that.

So, you know, errors cascade. And imagine now the system being deployed on something like autofocus, right? Where you're using your camera to focus on the object.

Like maybe you have a dog jumping, grab a Frisbee and you're trying to... Make sure that everything is in sharp focus when you get the video. If your tracker is drifting a lot and you don't have good signal, your autofocus systems would be spending a lot of energy. And, that, like a slip like that going into production is pretty bad. And, that's one example I can think of. But then nowadays the costs are much higher when you use neural networks and we can probably talk about that.

Yeah. And you'll end up with a video where the dog is in focus at the beginning and then the further the video goes, the more out of focus the dog probably gets and everybody's going Yeah.

To think. And your phone's battery mysteriously goes down very fast.

It sounds like the, I think it's gotten much better on phones now, but it sounds indeed like the early phone or camera systems that we had on our phones. Yeah.

So you talk a lot about reliability of AI models, right? Versus what the smartest model is. How do engineers think about that? How do you create... A more reliable model.

First... Thing to keep in mind is actually there's this excellent blog post by Andrej Karpathy from many years ago at this point. It's like how to train a neural network. And he focuses on only training the model and how paranoid you have to be. But that lesson, I think, applies just as much to deploying things in production these days as it does to training a model. And he says you have to log everything. You have to absolutely be sure that everything is as deterministic as you can make it because The model is inherently, you know, it fails silently.

So transposing that lesson to, you know, say reliability and production, it's the same idea because previously with traditional software, you would have unit tests and integration tests and all that, where if you gave a certain type of input, you knew what to expect or how the system would respond. With something like a language model that's powering a lot of the applications these days, the output isn't guaranteed to be what you expect. In fact, when it gets into the hands of users, they will find creative ways to make the model do things that you didn't plan for. And so edge cases are always going to keep coming.

So just making the system robust around the model. So having guardrails to make sure nothing awry happens, making sure that you have logged everything, like every single, you know, step. You have the receipts, so to speak, about what's happening. And when you need to debug, that will help you identify.

And then just having the mindset that the model is a part of the system, not the system itself. And so if your model is fantastic, that's great, well done, but that's not going to make your product work alone. Your entire system has to work in unison with this model. And so with that comes a lot of other moving parts that you have to account for.

So just having this paranoia about everything that can go wrong, let me try to catch it as much as I can before I put this thing into production. And then on top of that, once things go into production, having a rollback process method, right? Being just able to pull back something that, you know, let's say there are many approaches these days that people follow.

Like, you know, you have something like canary deployment and then you have shadow deployment, which is all well and good. That really matters now. But then just having that plan B when your plan A didn't play out as much as you expected. I think those are just like starting points. But then if you really get into the weeds, it's about monitoring something like drift. Because one of my favorite phrases, I don't know who said this, but I really love it, which the model doesn't change. The world around the model changes. And so that I think captures everything that can go wrong with AI systems. And just having that mindset that you need to be vigilant and you need to be paranoid. That's the best way to build robust and reliable systems.

I love that. And most of us were building, let's see, not so risky AI systems, maybe you're working on autonomous driving, which I think is probably one of the riskiest AI systems that we can talk about. How do you do it there?

It takes a village to bring up a model. I think that's the best way to put it. There's a lot of guardrails, fail-safes, compliance-related measures and safety-related checks. As you said, it's like one of those use cases where the model has to make a split-second decision about what's happening around it and then act on it. And at the same time, your margin for error is very low. You don't have time to react. And if you make a wrong decision, things can go south.

So just putting in as many fail safes as you can so having redundancies built in making sure that you have a certain level of confidence to make a decision, right? Like you tuning the model so that you're absolutely sure.

So it's not just the model directly making decisions. It's like the system around the model double checking, triple checking things. And as you have these models out in the streets, just being able to look at the data and collect feedback and say, okay, here's where I think this is a corner case that's waiting to happen.

So let's proactively address it and it's an iterative process because once a model goes out you get feedback from tests in the real world and then you use those tests to make your model better and the system around the model better and always like you know it's really dependent on which type of autonomy you're talking about because now there's like all the way from L2 to L5. L5 meaning no drivers, no nothing, just go, you just sit and everything happens.

So, The higher up in this chain you go, the more robust your system has to be. And always being able to, like if you can allow it, having human intervention possible and then elegantly handing it off to a human.

So giving the human enough time and context to, you know, if they need to take control. All of these things come into play.

So it's an intricate web of many I.

Understand, right? Then it's extremely complicated autonomous driving. I can't even begin to imagine how difficult that system will be. But for me, it gives me at least a reference before you said we have the model and then the system around it. And with this story, at least helped me understand far better how that works.

So you have the model, but then you have all these different guardrails around it. You have these checks around it to make sure that whatever the system outputs is correct and is usable and should be done and or it should not be done. I like that. Before we jump back in, here is something that I've learned from over 30 years of working in technology. The hardest part of leadership, it's not the technology and it's not even the people or the teams. It's often that you're added alone by yourself. There's no one in the room that fully gets what you're dealing with. There's no one that you can trust to discuss your decision with. If that sounds familiar, find me on LinkedIn. Mark Wormgoor, and tell me what's in your mind. There's no pitch, just a discussion with somebody who's sat in a chair as well. Let's get back to it.

So let's get into your book a little more. You wrote a book published last year, AI for the Rest of Us.

I mean, you clearly have a lot of background in machine learning and AI. What's the book for and what's your audience?

So, The rest of us is actually tongue in cheek. And I've spent my career so far in both sides of the table. I've been like an IC working on the engineering bits. And more recently, I've been working on the management side, you know, leading teams and so on.

So the common problem I've seen across both of these experiences is that the business side talks in terms of P&L, ROI, and strategy, and the engineering side talks in terms of KPIs and technology. Technology and there's this messy middle where people are stuck trying to understand how to connect these two because everybody's trying to achieve the same goal which is let's make the company successful or let's build something really cool and you know that you know, delights our users. But the problem is they try to approach it from two, with two different languages. And with AI, it's even more challenging because if you say, like, If you think about it from the stakeholders perspective, like the business side, they are under immense pressure because their competitors are busy launching AI initiatives, new AI features, what have you. Investors are questioning, why haven't you done it yet?

And then the stock prices are correlated with how these features are rolled out or not. And all of a sudden they have to figure out how do we wrestle with this thing? And they say, okay, I need you to roll out three AI projects initiatives and get them into the hands of users. Easier said than done.

And then the engineering side is here thinking, okay, what budget do I have? Do I have the infrastructure? What type of expectations are we setting up for the users? What's the timescale? How many people can I hire or what tooling do I have?

And then on top of that, what type of model should I use? What type of system should I build with this model?

And then they're trying to communicate from that and then it just goes over. You know, the head. And so this book is basically sort of a translation manual between the two.

So I've tried to explain AI in plain English, how it works. So right from the fundamental principles all the way to more recent, algorithms that have come out. Unfortunately, agents weren't a thing when I started writing the book.

So those aren't there in the book. I hope to add them in the future. But pretty much everything else is in there. And my goal is that if you are a business leader, this will help you speak to your engineering teams a lot easier and a lot clearer. And you will understand what is and not possible based on machine learning and AI capabilities. Plot is. Conversely, if you're the engineering side and you need a way to speak so that your business leaders get it, This book is a way to translate what you have in your head. In a way that they can understand.

So that's what the book is.

For. - Because even with that, a lot of people feel, even in tech, that AI is just so complex that only people that have a full PhD can understand it. PhD in machine learning, right? Not another PhD. I sometimes agree with that when I start to see these models. Is that the case or do you really think that's a misconception?

I think the answer is always it depends. And for example, if you want to understand the nitty gritty of fine tuning or alignment and reward modeling and all of that, it's probably better that you are somewhat technical in machine learning and so on. However, if you want to figure out how to you know which model to choose or how to evaluate models and or maybe just whether AI is the right thing to do for your product or service let's even start there you don't need to have a PhD you just need to understand a certain level of fundamentals and then be able to converse with people who are much more steeped in the area so then that way you get you can make an informed decision so If you are on the farmer side, I would recommend get as technical as you can. And even if you're on the latter side, if you enjoy the technical side, get in. But it's not mandatory. And part of why I wrote this book is I wanted to see if there was a way to teach people AI without them having to get a PhD.

Yeah, I mean, it sounds incredible just explaining that, all the models, because it sometimes feels that complex, even for me. We have a lot of professionals out there, right? A lot of people that have been in the workforce for maybe shorter or longer, but they feel locked out of this AI conversation.

I mean, they can use ChatGPT or Cloud or the simple chat models, but that's sort of where it ends for them. Is this a good starting point?

Yeah, I think like the best way to get involved in AI is to start using some kind of AI tool and just play with it and see where it works, where it breaks. And you don't need to play with every tool. And I know the FOMO is very real. It's real for people who are you know, even building these models, you know, that imagine the pressure that, you know, a team at say Anthropic might have when, I don't know, Gemini, you know, Google Gemini comes out with a new model or, you know, like OpenAI comes out with a new model. Hang on, we have to redo it so that we get better scores on the benchmark.

So pressure is everywhere. So it's not just you. But the best way to start learning is to actually just get involved with the tool because the advantage that we have today is that AI, for the most part, doesn't have a user manual. And I'm going to use this very carefully because people may take it the wrong way. My point is, We're writing the user manual as we go.

So everybody's kind of in the same starting point, depending on when you get into it. So if you haven't already, start using the tool and then start maybe questioning like, okay, so I'm using this. I see that it works really well when I maybe prompted this way or I use it in this certain aspect or use case, but it doesn't quite do so well when I do this. And why is that?

And then sort of using that as a way to dive deeper and deeper to understand how that's the best way to learn and now we have chatbots that can for the most part outside of the hallucinations teach you pretty much anything so you know just leveraging that I think is the best way to learn. So learn by doing.

I personally feel much better after you said that even the engineers at Anthropic and Google and OpenAI, they all have FOMO as well. So at least that personally makes me feel much better. Thank you for that. So if you're now going and you're, I don't know if you do this, but you're advising a CEO or board, right? And they always come up with the statements, we have to do something with AI. What should they do without actually falling for the formal?

Very fast. Question would be like ask them like a follow-up question like what do you want to achieve specifically like if because there's two types here, right? There's like AI native and that word gets used a lot. But the point is, if AI is the heart and soul of your product or service, or rather, if it is you made into the heart and soul of your product or service. If that completely elevates and transforms what you do, then that is something that you need to pursue. By all means. Whereas if it's something that is nice to have and a marketing gimmick, then you really need to think about whether or not you should roll out that initiative.

Like classic example, like a mailing client, right? The AI features are, I mean, I'm not going to include spam filtering because that is essential. But outside of that, if you think about auto-completing your emails or summarizing them, those are nice to have features. But the fundamental... Point of having an email client is to be able to send and receive emails, right? And you don't really need AI for that. And whereas if you are thinking about self-driving cars or if you're thinking about a chatbot that's going to be coding software with you, their AI is sort of... Front and center and if you remove the brains out of that it's going to become a problem you no longer have a product or service that is worth selling or users would want to buy so that's the first thing so if they don't have an answer for that there's no need for an ai initiative first of all Second, Tell them that the outcomes are going to be very, probabilistic and more often than not you will hear it depends. That's always the correct answer. And the reason is, Everyone thinks AI is like something you build a model, you build a system around it, you launch, and that's it, you're done. Whereas the actual work starts at launch. Because you need to see how is the model behaving. How are the users breaking the system? How are they using it? What are the failure modes? Is there drift? Is there a difference in assumptions between the way you train the model versus the way it's actually being used? All of those things have to be something that you monitor.

So that you get to do only when things go out in the real world. Yes, you should have good data sets that allow you to, you know, measure performance as a proxy for what you will see in the real world. But that's very hard. And, The other thing is if your attempt fails, you need to be able to iterate very quickly and come up with a solution. However, if your attempt succeeds, you're in even more trouble because now many more people want to use it. You have to scale and you have to start you know, scaling your system and services for supporting more load. That means the model all of a sudden has to handle more requests and things can go wrong.

So as you can see, it's never a one and done. It's a very iterative process. And The common denominator you see here is you're going to have to spend money regardless of whether your attempt succeeds or fails. And unlike traditional software, where you would have where you can say, I need X number of engineers and I need a budget of Y. And in three months, I'm going to deliver this feature for you and we can go to launch. And yes, you still, there is an iteration bit in software, but for the most part, it's deterministic. But when you launch an AI initiative, first of all, you have no idea if this model is actually going to be worth it. Even if like you need to spend weeks training it and then you need to test it and then see if it's actually good.

And then, So assuming it's good, then you go to launch and then you see what happens there. And if it breaks, you have to come back and fix.

So it's, like the amount of investment doesn't guarantee returns. And that is the mindset that you need to be comfortable with.

Like uncertainty is something you need to embrace and be excited about. So that's what I would pitch to a COO or others. And I know they would absolutely hate it, but You know, it's better to tell them the truth than promise the world and tell them nothing. And.

I think you talked about this in terms of Look at it as... Being a VC company and investing in initiatives. Can you explain that?

Yeah, so like if you think about I'll, venture capital works Most of the companies that a VC firm invests in do not give them that astronomical return that allows them to reinvest and grow. One or maybe like a And for less than a handful will give them that exponential return that allows them to grow and then reinvest in more. But that. They're okay with the fact that, you know, it's a long tail and only like a handful is going to give them value. And it's the same with AI. It's like, you have to be okay with investing a lot of money, but then you have to do it in stages.

Like you need to figure out, okay, I'm going to give you a budget of X amount. For you to prove this first let's actually see that you do it So get the info you need, get the people you need, the tooling you need, build this model and let's get to a particular milestone. And once you hit that milestone, then I'll give you more budget for either scaling it or refining it those kinds of and that is like a very VC mindset because you're betting on uncertainty. You don't have guaranteed outcomes, but you are investing a tremendous amount of money and resources into this.

So that's sort of the mindset that I was referring to.

So the first round's The seed Yeah.

Rounds. Seed rounds, basically.

The product market fit. Round A, round B, and then if it actually works, if it scales up, invest more money. I like that.

So if I'm a CTO, right, and CEOs come to me and they say, Mark, we have to do AI now. Let's go. How do you explain, how do you go and explain all of this without...

Yeah, sounding like you're asking for unlimited budgets or unlimited money or time or just... Yeah. Making it feel like it's just a delay tactic. How do you make this a good discussion?

I think you need to be honest. And upfront with what people can expect and even if it's the CEO I feel like You need to make it clear that this is a very sort of a bet. You're making a bet. But you're making a very calculated bet and you're going to do the best that you can to make sure that this bet is going to give you a good return on investment. And the other aspect is you need to have that cultural shift I feel where everybody from the top down understands that different from traditional software. Where you aren't building something that's guaranteed to work in a certain way. Or guaranteed to succeed, but rather it is can work in very unexpected ways. And some of those ways may be things you didn't even think of when you were building the entire system. And they may give you outsized returns. But the point is, if the CEO comes to you and says an AI initiative, let's go, you have to first ask like, why and what.

Like you need to get the specifics saying that I want to build this so that the likelihood of us succeeding is as high as possible. And for that, I need more context.

So what exactly is your vision? And then having that alignment from the start about what is possible, what isn't possible.

And then taking calculated bets like we talked about, where you say, okay, I'm first going to do this with this budget. And let's review the results together. And if we're seeing traction, let's then double down on it or let's pivot. And let's be very clear about it from the start that I'm, you know, that way you aren't expecting something crazy and when push comes to shove and we don't deliver what we promised, it's not a huge surprise for you.

So I feel like the transformation is more cultural. And versus something that's technical because if people keep thinking that I'm just going to throw a lot of money at this problem I'm going to fix it because if you're not solving the right problem for your company, if you're not thinking about AI in the right way, and going in with the right set of assumptions it's going to be a world of.

Pain. A quick one before we continue. If you're getting something out of this conversation, please hit the subscribe button below. That way, other tech leaders can find us as well. I would really appreciate it. Let's get back to it. I'm sure, I mean, you've been in this industry for a lot longer than most of us, machine learning before generative AI even. You must have had some unrealistic expectations at some point around what machine learning or AI could do. Give us a good example. And how did you deal with that?

I think, One of the things that was... I can actually take this example from sort of the working with space scientists and how grounding it was. I was working with an interdisciplinary team, meaning that there were astrophysicists, there were pure machine learning researchers, and we had the task to understand properties of the sun. And the reason that this was important is because if a solar flare comes, you need to know well in advance because it has the ability, a strong enough flare can knock out the communication lines of the Earth and you don't want that.

So you need to be able to understand all of these properties, which is super fascinating. And There was a part of the camp... That believed that if you had enough data, you could, predict, and wins or rather you could very accurately determine the properties that you wanted to measure for data that, you know, that your model hadn't seen before. And the Flip side was, I absolutely was... By the fact that some of the astrophysicists pure astrophysicists were upset and were saying, I know that this is working on this data. But how do you, how can you prove to me that this is not hallucinated. And I think in that project, we sort of went in with an unrealistic expectation that Given that we had several satellites worth of data, we could use it to predict the properties of the sun reliably. And that was unrealistic because... Yes, the model can hallucinate based on the data it's seeing. And the physicists were really pushing back and saying unless there's a physical interpretation for this phenomenon that you say that the model is predicting. I refuse to believe it. And I think That's an example I can think of that was very different from the ones that you typically encounter in the industry. And honestly, I still don't, have a solution to it in terms of how to reconcile the physics side with sort of the yes and you can draw parallels to that in other places right like medicine or finance like or law or any place where the reliability or the cost of a wrong judgment can be astronomical I feel like going into those domains with expectations like we did is very dangerous.

And yeah, So the models may be but 80 or 90% accurate, that's okay if you're a chatbot, but the human then understands hallucination at the end. It's less okay if you're in legal or medicine or autonomous driving. Right. Right. Even worse.

So let me, I'm just thinking where we go from here. You wrote a book, right? AI for the Rest of Us. I love it. Is it targeted towards business people or can we read it as, I don't know, is it for consumers? Is it something I could give to my mom or my daughters, for example, to read.

So how... Accessible is it?

So hopefully accessible enough for everyone that, but, If you think of the audience as three concentric circles, the first concentric, the innermost circle is what are the people I describe, like product managers, engineering managers, program managers, directors and even engineering folks who are stuck in that messy middle. The second part of the concentric circle is like business owners or, like people who are just curious about how AI works and want to apply it or understand it for the day-to-day lives. And the outermost circle is probably students or people who just are grappling with everything that's going on and just want a plain English explanation of what AI is.

So that's how I would describe it. And the relevant sort of dilutes as you go out towards the outermost.

Side. - Yeah, and I think to add to that, or at least my question from that is IT, software development used to be very, like you said, deterministic. And now it feels like it's changing rapidly. The kind of work that we do, it becomes more probabilistic, it needs more discussion, integration. What does that do for the kind of people that we need? What kind of talent do we need to be able to build these systems, but to have all those discussions. It feels very different from a standard Scrum team.

It is. And actually, you can see that happening in recent times in two ways.

So I'll sort of layer this answer. The first bit is... A lot of the principles of good software engineering are needed now more than ever before. That hasn't changed. The second aspect is you are seeing specialized roles where previously, like if you think maybe six years seven years back, you had like a machine learning engineer would be somebody who trained a model and then built a system around it for whatever purpose. But training the model was something that was integral to the role. And now if you think about the more modern AI engineer, It's somebody who assumes that a model is available to them, either through an API call or something their team has built that's accessible to them in some way.

And then they are focused on building the system around it or the application around it and then monitoring it and deploying it. So that kind of skill set has become increasingly more and more valuable because a lot of the applications that we work with today are based around either multi-model, large models or large language models. And so what happens is you don't need to focus as much on the modeling aspect. You just assume that a model is there for you. But then you really have to focus about how do you build the system around the model and how do you monitor it, observe it, how do you scale it and all of those aspects.

So that is a skill set that is becoming increasingly relevant. The other interesting trend is as with the rise of these coding assistants that can write a lot of code for you, again, You have to be really vigilant about how you steer these systems to writing code. That itself is a skill that you need to learn. Roles have started become becoming like blurrier so a product manager can code can design a designer can you know do scrums and do coding and as in here can now think about writing PRDs and maybe even taking a stab at designing and similarly like the more roles you introduce you can find that AI is able to sort of supplement the weak spots and amplify where you are already strong.

So this notion of these siloed roles is sort of going away and so Really, the skills that you have to start developing is judgment and taste. So being able to say what is good and what is great and having a very opinionated personality. Taste of what you think should be you know should be the product or application.

And then on top of that, just being able to, as we talked at the very start, just using these tools and really getting good with them, being able to know how do you orchestrate things, how do you steer things, and knowing which model to use for which particular use case, how to manage the context window. All of these are becoming way more important than sort of those previously precious skills. That's what I feel. Value is not.

Because even as a software engineer, I mean, we used to come from a world where we just pick up a ticket. Ticket says, as a marketeer, I want to go into the CRM and I want to check the latest status on, I don't know, opportunity A. That's very different building something like that from trying to figure out what the rules and the guardrails should be around a smart AI model built by somebody else. Gemini, I don't know, something else. Very different job.

Extremely.

- That'll be interesting. And it's all moving so fast. How are you personally just keeping up? Do you read research papers? How do you keep up with all the hype and all the announcements and everything that's going on?

A couple of ways. The first thing is Just being okay with the fact that you're not going to know everything that's coming out or stay on top of everything. Anyone who's doing it, please let me know how I'd love to learn. But the second bit is to have a set of clustered sources that you have either curated or have come to follow. And for me, as part of writing my weekly newsletter, that's sort of a forcing function of being able to just focus on something what's going on and sort of either write about it in depth or just like at least curate notes and details that I can come back to later and more specifically as part of my job just focusing on what's going on in that subset I feel like just even being able to do that at a consistent cadence and spending maybe 30 minutes a day looking through what's happening. And of course, now what I've done is I've built an agent.

Sorry, I had to throw the buzzword in here. I built an agent to help me, based on my taste and preferences, curate things for me.

So that way I can... Filter through the noise and identify things a lot faster than before.

So All of these are replicable systems to each their own, but the point is don't go for more, go deeper in less. And then just keep tabs on what's happening around.

So, you know, they talk about the T model, right? You go, you're very deep in one area, but with the AI space, now it's no longer the T model. It's probably the M model. You need to be deeper in one or two areas at least. But the point is, you don't know everything at a very deep level, but you're able to keep up at a, you know, like you just are able to follow some newsletters or podcasts or something that gives you a glimpse into what else is going on. But then in your areas, you're spending a lot of time understanding what's happening and just thinking about it, writing about it. That's the best way.

And then of course, building things just, use the tools because it's mind-blowing what is possible today compared to what is possible three years ago. And just being able to appreciate and use these tools to build things, I think that itself is great. I think.

That makes sense. I am going to ask you, so what are your... Short term, at least predictions then, because if you look back, Like you said, three years. It's been incredible what's happened in the last three and a half years and where we got to from GPT 3.5 to 5.4 actually at the moment. Where do we go from here? What do you see?

A couple of areas that I would really like to come true. The first one is smaller models that are personalized.

So the context here is these models, the large language models are consuming a ton of energy. They need a lot of data to be trained and When you think about the volume of people using these models on a daily basis, it isn't particularly good for the planet.

So for me, just being able to think of smaller models that are just as capable, maybe not as general purpose as these larger models, but, you know, very specific and calibrated for your use cases. And maybe models that can run on the phone that, you know, From a data privacy perspective, that would be fantastic. And from a climate perspective, even better. And the second area where I... I'm very curious to see what happens is medicine. Interestingly, ever since Alpha Fold, you know, came out and that's an area where I feel like there's so much potential for us to do something worthwhile for humanity. And if we are able to identify, you know, cures for very incurable diseases or very you know diseases that completely debilitate the human body I think that would be fantastic but then finally I mean everybody is going to be talking about the system agents and where they go from here so I'm yet to see a real world agent use case that's you know, truly robust and outside of coding agents right I mean just this is just a personal, very highly biased opinion, but, I think like in the next couple of years, we might see some very interesting shifts in how agents are able to disrupt the industry.

So those are my top three.

Cool. Okay, it doesn't mind. Thank you very much. It's been incredible having you on today.

Yeah, I think we'll put at least where can people find you before we go.

Sure. So I'm all over social media. You can find me on LinkedIn, Sairam Sundaresan on X. You can find me at Data Science, but Science spelled with S-A-I-E-N-C-E. And I'm writing a weekly newsletter.

So Gradient Ascent, follow me on Substack there and anywhere else.

We'll make sure that we put the links to your social media. To the book, but to the newsletter in the show notes for everyone to find you as well. Thank you so much for being here today.

My pleasure. Thanks for having me.

As we wrap up another episode of the CTO Compass, thank you for taking the time to invest in you. The speed at which tech and AI develop is increasing. And modeling a new era of leaders in tech. Leaders that can juggle team and culture, code and infra, cyber and compliance. All whilst working closely with board members and stakeholders. We're here to help you learn from others, set your own goals and navigate your own journey. And until next time. Keep learning. Keep pushing and never stop growing.