What Engineers Actually Do Now That AI Writes the Code | Murali Swaminathan, CTO @ Freshworks

Your CEO said that more than half of Freshworks code is now written by AI. So you own that engineering organization. I want to hear your reaction to this. Is this the industry norm you're seeing?

I wouldn't say 100% because there's always code that is more than 50%, in some cases more than 70%. For newer things, it's more than 70% of code is being written using AI. Normally engineers write like 1,000 lines of code. Now you're writing 10,000 lines of code a day. So for example, we are encouraging our engineers to commit much sooner. Don't commit more than 500 lines of code. Writing more than 500 lines of code is hard for somebody to read. Our bar is to get to— can I get to 90% accuracy? There was a time that we were running at 40% accuracy, and now we've systematically increased the deflection rate from low 40s to now high 70s. And that's an ongoing journey. Ideally, the number of AI agents should be more than the number of employees. That's all we're saying. Everybody has a digital AI worker that's working for you, or more than one digital AI worker that's working for you. Always invite AI to your table and learn to know its limits. Be the human in the loop. You don't blindly trust its output and assume that this is the worst AI that we'll ever use. The technology is getting exponentially better. Be ready to change.

Today I have Merli. Merli is the CTO of Freshworks. Everyone today is racing to build AI from a blank page, but he's doing the harder thing, rebuilding a 15-year-old public company for the agentic era. So today he's going to teach us The thinking behind rebuilding a plane while it's still flying. Welcome, Marley.

Thank you, Angelina. I think we are not just rebuilding, we are redefining our products of how they can use the power of AI to provide better experience for our customers.

Can you share a little bit about yourself that we cannot find with AI or on LinkedIn?

I'm an engineer by education. Migrated from India about 30 years back to US, and I've lived in the Bay Area since and working for small, big, large companies, some successful, some not successful, some public, some private. So I've seen the world through different lenses, and it's been a journey. Before AI, I started in the pre-internet era. And then I've seen the internet era evolve, and then I've seen moving from a client-server to a SaaS-based products growth, and then you're seeing the AI growth. So every generation takes a new set of things. So I've been in, I would say, good or bad, I've been in each of those redefining moments for technology. And each section of that generation of products have taught me something that has changed how I think about software, how I think about building, how I think about kind of bringing new products to market using that technology that's available.

Since you've seen it all, if I were to ask you one grand takeaway, like, what would that be?

It is just the curiosity to learn. Each defining technology has something that you wanna leverage, and then it takes a finite amount of time for that technology to settle down. And for people to start using it, to understand how it really works, and then how it can be put to use, how it can scale, how it can be made secure, how it can be made extensible, right? So that's what you've seen with the SaaS era. It took 10+ years for the SaaS companies to evolve into something that really can scale and somebody can scale and perform and be secure. And even for the customers, the same thing. It took a generation for customers to accept that on-premise is gone, and now we need to rely on cloud-based software to get things to run their business. That transformation did not happen overnight. It took customers, many customers, 5 to 10 years to do those things. So, I think that's a reality check.

I'm really curious about your product, and I did some homework before this. So, I pulled your homepage from the Internet Archive. So in the last 4 months, your hero line actually changed 3 times. You're probably aware of it. Enterprise grade without enterprise complexity. So this is April this year.

Yep.

Can you see this one? So this is, this is July. So last month, you're calling yourself united service operations for the AI era. So I can see the AI era becoming one of the part of the tech line. This is the newest one. Of course, this is saying turning operational complexity into coordinated action. It sounds like it's alluding to agents taking actions, and this August change looks like a full visual relaunch as well. So it's not just a copy swap. I'm really curious, did the actual center of gravity of the product actually move underneath those lines?

I think as you're seeing, we have evolved from being Yeah, if you go back in time, Freshworks is an AI-powered unified service operations platform, and that's fast to deploy, intuitive to use, and enables every employee to be more productive. So that's our tagline, right? So as we have evolved, we have evolved our product from being a chatbot-based interface into LLM power to the agentic era. And then from the agentic era, it's all about trying to help humans be more productive in the sense that we support self-service use cases as well as human-in-the-loop use cases for agents to resolve their tickets much faster. And the intent is that any repeatable operations can now be automated end-to-end. That way, our goal is to make sure that for repeatable operations that are trusted by the humans, we want to automate it end-to-end. And that's how we are looking at it. And then it's not just tickets. We are also looking at other operational aspects of running your business. So when it comes to employee experience, you're looking at how your IT is set up, how your services are running, how you request for software, how you request for software needs to be updated. If you need to set password change, it automatically does the password change. If a site goes down, it automatically informs people and triages, and then the right people are involved in order to troubleshoot the problem to get it fixed. So, we are moving from not just somebody logging a ticket and somebody looking at it. Can I proactively start identifying issues so that I can resolve them before it even happens? That's the journey we are in.

Is the main customer-facing interface through a chat interface?

It is one of them. So we offer multiple because there is no one solution that fits all. So we are offering, if you are an agent, that means a person who is actually receiving tickets and solving, they're using a web interface to solve those tickets. But if you're an employee, which is in the company, you use whatever is a chat interface. And the chat interface could be through the web, could be through a Teams or a Slack or any of those channels. to get things done. And if you are a customer service agent and you have an issue with customer support for one of the products you bought through the website, then use a web chat as an interface to interface, or you can use a WhatsApp or an Apple Messenger to interface. So we have multi-points of entry, but all of them lead to the same set of conversational-based experience for you to directly talk to the bots. And to resolve the issue as quickly as possible. And some of the time it's not just answering questions, it's also taking action to make sure that, oh, you asked for a refund, it actually processes the refund for you instead of you waiting for a human agent to come online to take the information and process. So our goal is how can you do it without, in a frictionless approach, without having to loop in too many people? And how do you reduce the number of hops? And get it done in a fewer number of steps.

I know that you had Freshdesk, which is a ticketing center, for many years. So, which parts of the product suite did you actually have to rebuild from ground up, or which parts are just AI layered on top of what was already there?

A lot of the products that the source of truth, or we call it the source of record, which is the— that is standard, right? How we store tickets, How the tickets are linked to users, how those tickets are linked to products, things to services, the structure, the data schema, all that stuff continues to be the same, right? Because end of the day, whatever you do, you have to store it somewhere so that you can then report off of that information, and then you can act on that information. So, none of that structural schema has changed, and our product was always API-enabled. From the get-go, so we we the customers could do it through the UI or they could do it through API. Right? We always had that interface open. With the evolution of AI, we have MCP enabled some of our our interfaces. That way, a third-party AI tool can actually interface with it because working with an API is a little harder for AI-based tools. But with an MCP, it's a lot more decorated, so it's much easier for a AI. it's coming from Claude or OpenAI, you can directly interface and do reads and writes into our system, right? So we have added that layering on top. From an agentic perspective, it's more of, we already had a fully working workflow engine that did deterministic flows, right? It means that exactly, no, you can map out the flow to say, when this happens, do this, and this happens, do that. And you have decisions, loops, all of that stuff. So, some of that stuff doesn't change, right? If you are trying to reset a password, the steps to reset a password doesn't change. But in order to make the decision that should I reset the password or not is where the agentic AI comes into play, because you don't know what the user's real problem is. So, where the AI layering is on top is to first understand what the user is trying to do. Is the user having an issue logging in? If he's logging in, is it because the person forgot the password or is it because the person is in the wrong page or the person is using a long ID? So you need to first investigate what's going on or help understand the issue. Once you understand the issue, then it's easy for you to take action. And that's where you call a reset password action and that'll reset it for you. So that's the thing that, that's the facading that we have to do is where we have to Collect as much information as possible from the user through conversation. And based on the responses, you can direct the user to the right solution or outcome. And that's what we have done as part of the product. And so, that means that it doesn't change how we were operating within the product. It changes how we interface with our users and how we leverage data to make decisions for, on behalf of the users.

The automation happens when in the past a human has to do it, changing the passwords. You, as an employee, I have to talk to the IT person or something, maybe if I got logged out and I couldn't log back in anymore. But now basically agents can take over that downstream pipeline of actions and then do all those things without human supervision. That's what a value add that you're building on top.

That's right. So some of these workflows can be automated because you can generate those actions by looking at a pattern. You can generate those actions into the agentic workflow for the AI bot to automatically perform, right? You don't have to codify every single thing, right? That's what the agentic stuff is like. It makes decisions based on the patterns. It makes decisions based on The inputs and the answers given by the user. It kind of, you don't have to think about all paths. Normally in a normal workflow, you would say, I have to anticipate all scenarios and then build a workflow, and it might handle 80, whatever, 9 out of 10 scenarios, but might still miss out some scenarios.

Right.

Here there is a high probability of, it figures out based on the need, and then it connects the dots. And then creates the right workflow for the person to perform their operation.

Yeah, and that's through runtime, right? Figuring out the best path of solving a problem.

Exactly. A lot of it is not design time, a lot of it is runtime, but you empower the person. It's like similar to, you have a handyman, he has a toolbox with a set of tools, and now the handyman, we are empowering the handyman to have all the tools on their hand so that now they can use all the tools to figure out How do I fix a leak on a tap? Or how do I put a doorknob in place? So they need to know what tool to use when. So that's what the, uh, the agentic framework makes that decision at runtime.

Yeah. I want to double-click on the MCP part. I interviewed another founder and he told me that most public MCP servers are basically unusable. It's untested and very few tools and probably have bad authorization. So I'm curious about your MCP gateway. So you must have to connect with all those third-party tools like Zoom or Workday, whatever it is. So are you relying on those vendors' official MCP servers, or are you building them yourselves and harden your own version of them?

So we have 2 sets of MCP servers, right? We call it, one is we call it the inbound MCP servers and the outbound MCP servers. Inbound MCP servers are nothing but how somebody interfaces with our Freshservice product. That means they can push information or get information, right? We call it, that means that MCP server has been built by us.

What do you think is the real value add of MCP servers letting you do today versus maybe last year you're still relying a lot of the API calls?

APIs need to be coded. And right now MCPs are a little more discoverable in the sense that, like I said, it's runtime configuration, right? And at runtime using MCP, I can now discover all the tools that I can use to talk to a system of action. And then I can, that way it's much more descriptive and it's written in a form where I can interpret it. The other advantage of MCP is the AI tools have become a lot more savvy in interpreting how to use MCP in an interoperable way, right? If I don't have to be able to say, use this API, this API, based on, it's like I'm exposing a Rolodex of all the things. And it goes and looks at, okay, this API makes sense based on the description. Let me use this API. Let me connect it. So I don't have to link, same thing. I don't have to manually wire one API to the other. If I've exposed both MCP servers to it, the AI engine is smart enough to introspect that MCP server for the tools that it supports, figure out which tools can be mapped to which other tools. and then make the right API calls. So that chaining becomes easier and chaining happens at runtime. It's not, again, a design time thing. So that's what I think, that's the flexibility that MCP has. And it's getting a lot more useful right now because everybody's trying to get data from multiple sources. And it's so convenient if it's, instead of trying to go, somebody go run a query against a database, if there's an MCP interface that's available, you can use that MCP interface to query that I do that all the time in some of the work that I'm doing. I no longer go to a static dashboard. I no longer go to a database and run queries. I operate using the MCP servers that have been exposed through those data sources.

And your agent product, that's called Freddy, right? How old is Freddy?

Freddy has been around since 2018, but we started in an era much before the whole GenAI evolution happened, right? So, GenAI evolution happened back in 2022. So, we started with the whole AI/ML models because some of those things, that was the norm of how you built AI/ML solutions before, was to use those traditional BERT models and traditional classification, clustering, and other regression models to solve for use cases. And that required data scientists to look at the data, understand it, run trainings, patterns, and all of that. So, it was a very methodical way of doing it, but it took time. And then, the only way to know whether it's working or not is to actually try it on customer data and then figure out it's working or not working. So, we have gone past that. So, as part of the whole moving to the GenAI wave, most of our use cases are now based on these frontier models. We don't leverage the traditional models as much, but there are some use cases that still need access to look at customer data patterns and then make those decisions, right? We can't just make those decisions without looking at customer patterns. Like in our case, a simple example is we have a ticket suggester, which means that ticket field suggester. So when you're logging a ticket, how does it know that it should be assigned to this particular team? It should be assigned to this particular priority. It should be assigned to this particular type of issue. All of those things are derived based on historically how those tickets have been created. So some of those things are better done using AI/ML models than using these frontier models. So there are still continue to be some use cases which require traditional AI models, but for the most part, 90% of the use cases can be achieved using the frontier models.

Is the reason for that being hallucination could still be a problem that in like high-stake decision-making through the agentic process. So you're not using an LLM as a judge to make that call, like this is the path to go or the other one. Instead, you know the history anyway, so use ML makes more sense.

Yes, I think some of it is hallucination. Some of it is also the patterns of like how you're trying to use the GenAI models here. So some of it requires a lot more looking at data patterns and coming up with You don't want to pass all the data to the LLM as well, right? You don't want to be like normal ways people say, I'm going to pass a context to the LLM and then through RAG-based search, I'm going to let the LLM interpret the data. I can't push millions of records into LLM and say, now you tell me what should the field be, right? So that's why I think sometimes you cannot use a— you have to know what to use. You can't use a Ferrari to go to the grocery shop, right? You have to be able to use the right tool for the right task. Right purpose. I think that's where it's a cost versus benefit. So certain models, I think it's more effective to use a traditional model because that use case does not scale if you suddenly are trying to operate at a much larger dataset.

Do you have any heuristics of making that kind of decision? What kind of things you need to rely on opening up the context window and give just that to the LLMs who make decisions? Versus where do you make decisions using a more deterministic way?

Exactly. I think that's where the experimentation comes in. We do have a group of data scientists who are constantly looking at model evaluations and understanding what is accuracy of data and where is the tipping point for it again that says that, okay, it works for X number of records, but the moment it goes to Y number of records, it doesn't work, right? Or the accuracy drops, or it takes longer time to get that outcomes, right? So you want to— and how many tokens are you consuming in the process? So we are looking at all of these patterns and then trying to determine the best approach for a certain problem. So certain times for simple use cases, for example, like, oh, I give a block of text and I say summarize, I'm not going to use a model. I'm just going to use the GenAI Frontier model to summarize it for me because there's not much logic to be applied other than processing a bunch of text. But when I'm passing something a little more structured, structurally rich with context of what that ticket means, and it has access to other things that it needs to look at before it makes a determination. In those scenarios, either you do the pre-compute and then let the LLM model make the final kind of call. It can help you summarize or it can maybe order stuff or it can even make the final call. But instead of doing that, you can do this end-to-end using a— traditional ML model practice, deterministic model practice. So, I think each use case has to go through the same journey, and that's part of the experimentation phase that we go through. Whenever there's a requirement, we say, okay, let's try through all these approaches, and then whatever gives you the best outcomes is what we'll go pick. And then it also has to, not just the best outcomes, it also has to be scalable, and it has to be, from a cost-benefit perspective, it has to be I'm curious, what is the single hardest technical problem your team actually had to solve to make Freddy agents work in production? Single largest problem that we had to solve. I think as an engineer, there are many such problems that we tackle on a regular basis. I think one of the things that we had to solve is definitely the hallucination was accuracy of data, right? How much deflection can you achieve for your tickets? So, we have constantly Our bar is to get to, can I get to 90% accuracy? Can I get to— so there was a time that we were running at 40% accuracy, and now we've systematically done a lot of work through model evaluations, looking at training data, looking at patterns of data, to then looking at feedback, looking at positive correlations, tweaking our instructions, tweaking our How we leverage these models to systematically increase the deflection rate from low 40s to now high 70s. So, that's an ongoing journey. We have not stopped. We're continuing to now figure out, okay, how do I get from high 70s to high 80s to high 90s? So, this is just one of the many things that we look at on a regular basis.

Are you doing some guardrails or preventative measures For especially things related to agents potentially going rogue or doing something irreversible, like messing up someone's payroll because the models still hallucinate. And you're saying your accuracy is around 70%. So how do you prevent that from happening?

Yeah, I think that's why we still have human in the loop for some of these things. Wherever you don't have high confidence, you'd come back and say, this is what I found out. And we let the human make the final call to say, okay, from a confidence perspective, if the confidence is below 50%, we will make sure to not provide that kind of outcome back to the user, or we will make a suggestion to say, this is what I found. Can you tell me what's the right path to take? And then we let the human make the judgment, and then we learn from that interaction so that next time a similar pattern appears, we are now saying, oh, somebody already said this is the right path to take, and let me take the right path. The confidence improves with actions. The more you use, the more gets better. That's where the trust improves. The trust is the very common pattern for all AI-based solutions is the more you use it and the more people give feedback or implicit feedback or explicit feedback, the trust builds up. That means that next time it's going to do it, it's going to say, oh, this is a proven path. Let me do it with confidence. Similar to how we do driving, right? The more you drive, the better you get. That's exactly what you see in the AI world as well.

You're covering several different aspects, customer service, IT side of things, human resource management, all in one platform. I want to ask you, like, why, why, why should I think about buying a whole bundle of things instead of potentially one vertical tool for each one of my problems? There's a cost to unify all those data across different departments, where in a business, all of that information could be needed. For one agentic loop, right? Especially if it has a long pipeline, then it's going to be cross-departments, not one single vertical doing one thing, right?

Yeah. The larger the company, the more complex it becomes, right? So, you have like, if you have 10 employees, a certain set of complexity, if there is no real separation of roles. The moment you go from 10 to 100 to 1,000 to 10,000, there is separation of roles and separation of departments. That means you cannot just randomly work with HR. You have to go through a certain protocol to work with That means any automation that you have put in place, any AI agents you have put in place have to respect the same protocol. Just because using an AI agent doesn't mean I can just skip the mark. If you have to send somebody something to somebody for an approval before you process it, you have to follow that same protocol.

How are you pricing your AI agents? I'm curious. I heard that you recently announced a session-based pricing.

Yeah, we've, again, the pricing is a science by itself and it's evolving as we speak. We are, we've always supported session-based pricing for our chatbots. And so we have, we have desired to open up the same similar kind of session-based pricing for our AI agents too, which is slightly different from how our other competitors have priced their, some of their, their AI agents. In our case, if you're using a web-based AI agent, one session is equivalent to the conversation you can have within a 24-hour period. So, we give you a lot more coverage. It's not like you send a message, somebody responds, and it consumes a session. No, it's sessions that are consumed over a longer period of time. Similarly, we have email AI agents where that's something which is very common in our Freshdesk customer service use case where customers are emailing the customer support help desk and they get tens and thousands of emails. These sessions run for 72 hours. That means I can send a message, the bot responds back, the person responds back again, the bot responds back again, and it can go on for 72 hours and we still count it as one session because it's not like something that you just— sometimes you get an answer right away. Sometimes the person is not happy with the answer, so you have to respond back again. And so, depending on the type of interaction, we kind of make our sessions extendable for that particular scenario. Again, this is just an evolution. Pricing is still evolving. People are looking at resolution-based pricing, credit-based pricing. So right now we have a combination of hybrid pricing in the sense that you do buy seats for the people that are solving tickets, and then you do offer sessions for employees who are actually interacting with those AI agents. And then, so it's a combination of both. If you have more employees, then you might use more sessions. If you have less employees, you might use less sessions. So depending on the company and depending on the need, the pricing is adapted to their business needs.

It doesn't seem like there is a— the industry has come to one single conclusion, like how SaaS was designed, right? And versus today, AI agents has so many variations of how we can price it.

I know. I think there is a little bit of that variation too. Customers don't want to pay a running bill as well. So what we are seeing is people are looking for predictable pricing to some extent. Even though we are saying sessions, we are expecting customers to, or we will work with customers to anticipate the number of sessions that they might consume based on their historic volumes. And then they would buy those session packs. That way, They have, they don't have to keep coming and buying more.

So it's more usage-based.

Yeah, exactly. More usage-based, right? That means they have, they anticipate that I'm gonna get 10,000 tickets and they buy sessions equivalent to those supporting those 10,000 tickets. That way they don't have to keep budgeting for it, 'cause customers also work with a defined budget. I've allocated X amount of money for my IT, X amount of money for my customer service. So you wanna be able to make sure that They are able to operate within those norms too. That's where the whole token maxing and some of the stuff became a problem because there's no unlimited budget. There's always a limit to the budget. And we wanna make sure that we work within those boundaries.

And people want to see outcomes. It's not just like a predictable budget, but also they wanna see the real outcomes that I'm spending this much money. I wanna know that what I, what's the ROI on them?

That is true. Because if you're doing something and if you don't get that, it's similar to anywhere. Like you ask something for some, you ask somebody for a for a favor and you expect that person to give you an answer. You're not expecting the person to dodge the question, right? That means you— so similarly, when you're using an AI agent for a certain purpose, you're expecting that AI agent to give you a solution to that problem or solve that problem for you, right? Either way.

Let me switch gears to the people side of the questions for the 2026 version. Your CEO said on one of the earnings calls that More than half of Freshworks code is now written by AI. So you own that engineering organization. I want to hear your reaction to this. Is this the industry norm you're seeing?

It is. I think we are more and more for code. All our engineers have access to multiple coding tools. And those coding tools are used by our engineers to build new code. And naturally, a lot of that new code that we are adding is generated by AI. It does require us to put a lot more gates and make sure that the code that's being written is tested, reviewed, and deployed in the most secure manner. So we have increased some of that governance there, but it is true that a lot of the code that's being generated, or all the code is being written, is by leveraging AI. And that means the experimentation is getting faster. We are able to make sure that, okay, if somebody thinks about an idea, it's easy to build a prototype that you can iterate over. And then when you agree on what's the right product to build, then you go ahead and build it.

Did you say 100%? Is it actually not 50%?

No, I wouldn't say 100% because there's always code that is the human. It's not like the code is automatically being written. More than 50%. Of course, I would say in some cases more than 70%. For newer things, it's more than 70% of code is being written using AI. For existing code where you are marrying, you're making changes to an existing code base and you are adding new things, there, there's a lot of AI. It's a blend of human knowledge and AI which needs to write that code for you, right? So depending on the use case, a new product, a lot more AI code, existing product, At least 50% of the code is AI. That's how we've learned.

Did you notice that when we're using so much AI in our day-to-day work, it's not just the engineering team, probably your PM team does the same thing. AI is very verbose, right? So you tend to have like a much longer PR to review. So it's the work becomes not writing code, but actually becoming reviewing the code and reviewing the PR. And even a PRD, it's the same thing, right? You probably have a nicely done PRD you're looking at, but it's really, really long. Are you seeing that? How are you tackling that problem within your organization?

Very true. I think we saw the same patterns emerging where whenever somebody's writing a document, it's a large document, n number of, it's like 20-page documents or 30-page slides. The codes people are generating, normally humans used to write, engineers write like 1,000 lines of code. Yeah. Now you're writing 10,000 lines of code a day because of the amount of code you're checking in. So, what we are encouraging people to do is we've come up with best practices of how people should use some of these products. So, for example, Core, we are encouraging our engineers to do commits much sooner, right? We are asking them to say, okay, don't commit more than 500 lines of— don't commit in less than 500 lines of code. That way, it goes through those checks quickly and it's And we have used AI reviewer tools, and then we have human reviewers as well as an ad hoc basis. Not every code gets reviewed by humans, but those checks and balances are there where some subset of code gets reviewed by humans too. And we want them to review code which is palatable, right? So anything more than 500 lines of code is hard for somebody to read up, right? So that's why we have put that checks in place To kind of set those guardrails. Same for PRDs. It's more of how much information are you gathering? So, we have started adopting something called AI PDLC, AI Product Development Lifecycle, where from a single-page abstract, we are able to generate a multi-page PRD, which takes the information, looks at the feature, looks at the code, looks at customer-reported issues, looks at documentation, looks at UI, and then fills the blanks for you, right? So it's filling the page full of it. But the intent is, after generating it, the product manager has to review it, make sure that they correct things that are not right, and fix it before they pass it to the next stage of generating code or generating a technical design document. So we have Checks and balances in place where it's not like we take something and directly put it in. The person has to review it, make sure that the content that has been generated is good before they pass it to the next stage.

What about promotion? Because of AI, we're probably doing more than we can do in the past, but does it mean that doing more will get us promoted now, or does that become the new baseline? How are you making decisions around that?

I think, yeah, it's all efficiency is what I think. It's not about the amount of code you're writing, it's the amount of efficient— how are you leveraging your time to do more things? Are you doing more with less, or are you working on producing code? But a lot of people do a lot of experimentation, but if that code doesn't really get into the product, It's not of much use, right? So, that's why we see outcome, again, outcome-based rewards is what we have. If somebody has contributed to a product that got released and that released product is generating revenue, then naturally the people who worked on it get a lot more credit for it instead of somebody who is just experimenting and producing a lot of prototypes and mocks, but it's never seen the light of the day, right? Then that is not— yes, they're producing a lot of experimental stuff, but nothing has seen light of the day. the outcomes have not been met, they are rated differently. Somebody who's contributed to a product that is actually shipped and used by customers.

You as a leader, does it mean that you're hearing a lot of pitches these days for experiments? And people probably are having tons of ideas, you know, but you'll probably have to think like, what's worth doing? And are you allowing these creative budgets on how employees are spending their time on, like 20% you can experiment? But 80%, you have to stick to our roadmap or things like that.

Yeah, again, we don't have that kind of 20%, 80%. We are just letting them experiment a lot. If somebody's really curious, they go and experiment. Either they finish their work and experiment, or they find time to do it outside their working hours or weekends or something. I think so the curious learners will always do it wherever you are, right? good thing about AI is it's opening the doors for many people. So many people who thought they couldn't do it are now able to do it because AI lets them do it faster and AI lets them try it out. So, we are allowing people to experiment all the time, right? Independent of whatever they have primary tasks are. And then we do hackathons, we do some of these idea gathering sessions, and teams get to experiment. So, we have this thing where between when you're moving from one stage of the project to next stage of the project, We do create a little bit of room for people to go experiment and build tools and do things. We are always encouraging people to build new skills, new tools to make engineering productivity better, right? So, that is something that happens. There's a product track and there is experimentation track and there's a productivity track. So, people are always switching gears. If somebody's bored of building something, they'll go back and build a tool. Or somebody says, oh, I'm doing this over and over again. Let me go build it and automate it. and they would go build something and contribute back. So, we encourage people to share new ideas, encourage people to build new tools that other people can benefit from.

Has AI changed how do you think about how big your team needs to be?

In a way, yes. It's true that you have to understand what kind of skills do you want on your team. I think that's the way I think that things have changed. Before, when you're building a product, you'll say, I need a frontend person, I need a backend person, I need somebody who understands this technology versus that technology. With AI, you don't need as many specialists. You need a few, unless it's a really, really complex thing that requires a certain person's domain expertise. Any person can do anybody's job. That's becoming a little bit of norm. And then you don't need a developer and a tester and a designer and a product. Sometimes all of it could be the same person who's doing the work, right? So that's what you're seeing. So, It's not the team itself. It's the number of roles that are involved in a project could be depending on the size of the project. If you're running a big, massive project, yes, you may still have designers. You may still have testers. You may still have product managers, but if you're working on a small size project, you could be playing the same role. Yeah, you are the developer. You are the designer. You are the tester. You are the security guy who is doing all these phases as part of your development side. That's what we wrote. Interesting.

The problem is this is not how we grew up. This isn't how we were educated, right? Even people with past experience are probably set in one single role and they haven't seen the whole pipeline, how things are done. So are you seeing, how do you, what kind of people are you seeing are becoming more successful in this new way of how you organize a team? It sounds like you're expecting your team members to wear multiple hats.

I think people are open to change. People are open to learn. People are open to be creative. I think those are the ones that are succeeding a lot more than others because they're willing to experiment. They're willing to learn. They're willing to change how they operate if something else is better, right? So, they're not settling for less, right? They're always constantly saying, oh, there's a new technology. Let me experiment with it. I used to do it this way. Let me do it the better way. Whoever is willing to embrace change, they are the ones who are actually succeeding. If somebody is saying, I've done this way and I'll always be doing it that way, there'll always be some work that they could do, but it'll be very hard for them to break through because the kinds of things they would do is getting— there are fewer and fewer things that are happening for those kinds of people. For the majority of the people, it's all about, oh, I'm learning something new, I'm building something new, And every single day there's a new technology that something is getting better than the previous day, right? So, the more curious you are, the better you are as an engineer.

Are you changing your team structure to enable these kinds of creativities in a sense? Let's say if I'm on your team, can I just come to you one day and just say, Murli, I have this like great idea and I pulled some data and did some market analysis and ICP analysis. I can tell you this. potentially have a great impact. And if I convince you, will I be able to build something like that, being the PM and being the data scientist, being the engineer who can actually make it happen?

Definitely, yes. Because I think that's one thing. That's where the teams are no longer becoming rigid. You have the opportunity to be a team of 1 or a team of 2 or a team of 5, right? You can form your own teams with like-minded people, and you're no longer thinking about it as I'm operating in sprints where you have to have defined work that needs to be planned and done. People have a list of tasks, people pull it, get it done, move on. And so, the ways of working are changing with how people are operating, right? Some of it, if it's planned work and we know exactly what we have to build, then yes, it's a group of people are on it and they're building it. But for a lot of unplanned things, people are coming up with ideas to say, oh, I know how to do it. Let me come up, let me pick up the task. Let me come up with a design. Let me do it end-to-end without having to rely on someone. So, we see both kinds of play. So, there is no rigid team. Nothing we talked about, oh, do you have to set and say this group only works on this for the next 6 months? No, I think there's a lot of flexibility that's happening right now where teams are saying, okay, I don't need as many people to get something done, or they're pulling the right person for the right need at that time, but then the person goes back to their original team. There are a lot more free-forming teams right now. Because we can bring in people with the right mindset and then get the job done. Because like I said, there's no requirement that, oh, I need to know this technology better than that technology. Generating code is the easiest part. What you want to generate code, the designing the right— designing the solution for the problem is where most of the brains are being spent right now. Am I solving it the right way? Is it working the right way? Do I understand the problem? Have I designed it in a way where it is going to solve that problem and then also not just work for this use case, it's going to work for other use cases beyond the problem, right? Can I anticipate what could go wrong and build it with that in mind? Those are ways I think people are spending more time, not writing that code, because writing the code has become easier. That's why the planning agent, the design agent, those are becoming a lot more important. The coding agent is the step where People can generate code in any language they want and then push it through.

Does it mean that your managers are essentially shifting to do different things? I imagine when I was a manager, I managed my team, I have a set of projects I need to do, and I just make sure the team do a good job on finishing up. But now it sounds like managers has to be investors, right? They kind of have to take an investor perspective on what to invest on, what to spend spend the time on and listen to the team members to pitch, right? And each layer and eventually reach to you and you decide what's worth investing. And then so that the fluentness of team forming up like a squad team working on something can be realized.

That's right. Yeah. Manage, like, I like the word investors that you've heard. I think exactly that. Managers cannot be just pure people managers are. They have to be techno-functional. They need to be able to roll up the sleeves and support the team. They need, they should continue to experiment themselves as well. So we are expecting managers to be a lot more hands-on to do things because there is no barrier to entry right now, right? Anybody could do any task. And if you're a manager who has got some amount of experience doing some things, then you may be able to contribute to a design much more easily and build it. You don't have to say, I didn't code before, because coding is not The coding part of it is the easier part of it, right? Because before, you say, I've coded 2 years back, or I've coded 10 years back, I cannot code anymore. That is not an excuse anymore, right? You can still leverage your experience to generate the code. So, that experience is what matters here because you built something, a system at scale. Now, let's use the same experience to design a new system that can operate at scale.

Are you also thinking of flattening the team structure a little bit more to have more agency around the team members, or?

We have done some of that stuff as well where we have created— yeah. So, it's not like we need— again, for the larger the company, you do need some of these structures because it's very hard. You need to keep the employee connection going.

Right.

But we have done some intentional flattening of our structures to make sure that each layer is adding value to the system, right? If somebody is a team manager, They're adding a certain sort of value to the system and they're not just managing people.

Do you have kids?

I do. I do.

Can I ask how old are they?

I have one son. He's a biomedical engineer. And so he's building, he's part of a surgical robotics company. So they're using AI in a very different way, right? They're using AI surgical robot to actually perform surgeries. Yeah.

Have you had a conversation with him about his career, like what to study? And I know he ended up doing the robotic engineering, but have you had that conversation even today?

Yes, I think, yeah, one conversation we always have is being a pure software guy, is it good enough? Or you want something where you can use your hands to do something, right? So he works on electromechanical and software as well. So he's saying, okay, he's a lot more marketable because there are certain things that cannot be replaced with AI. He still has to work on a circuit board. He still has to do certain things where he has to wire things up and he has to do certain things, which again, there are robots which do some of that as well, but there is a little bit of human aspect to it, right? There are certain things he has to physically go into the office, into a lab to actually work with the surgical robots. He can't do it from home, right? So like we all, being a software engineer, I can work from home and can do everything independently. So he feels that his job has got more job security than anybody else. Yeah. Again, time will tell. But the key thing is he's also learning. He's also doing a lot of things on the side using Claude and other coding tools to keep himself up to date, right? So he realizes that there is a lot of things that he can do without having to wait for it to happen at his workplace.

So, for all the engineers and builder audience I have watching just now, do you have any suggestion for us to make us more irreplaceable for the future?

Irreplaceable for the future? No, I don't think we should think about that. I think, yeah, that's an interesting game, right? I wish we are immortal and it's like similar to being immortal, right? I don't think We want to be immortal. So, it's good to have somebody who's challenging it. That's how human race has evolved, right? When somebody challenges you, you take it up as a challenge and you make it better. And that's how we have conquered different things, right? So, I think we should continue to have problems. Only makes us better, right? We don't want to solve everything that we have nothing else to solve. Then there is nothing. Then people don't know what to do with their time. So, I like having problems. and challenges that we can solve, and we can look forward to coming up with a solution to solve them better, right? That's how the human race has evolved. So, whatever we used to do 20 years back, now we are doing it better, and now we've moved on to bigger problems and solving those problems. And there are n number of problems in the world, and we should continue to challenge ourselves to solve those problems.

Are you fundamentally optimistic or pessimistic about the future of AI and why?

I'm optimistic in the fact that, okay, there is so much that can be uncovered using AI if you use it the right way. I want to make sure that use AI responsibly is something I believe in. So, I'm optimistic about AI, but using it responsibly is something I believe.

Can you teach me one thing to make me a better technical leader today?

Teach me one thing to make a technical leader today. How do you use AI right now in your, in what you do right now? How do you use AI?

I have the same question for you. I use Claude Code all the time.

Oh, you use Claude Code all the time. Have you tried trying out other tools, experimented with something that's built on Claude Code, and then you try to build the same thing on Codex or Cursor and see how it compares and contrasts? It'd be good to put things to test because we always trust one thing. But it's always good to experiment with different tools because the way some of the tools, the models that are being used with Codex and the models that are used in Claude are slightly different. So you might get different outcomes. So you may want to see how the compare and contrast are the same results, but built using 2 different coding tools. And that might be a good way to test whether whatever you're thinking is working or not. Which one is doing it better, if any?

Yeah. If I don't compare, then I wouldn't know. I wouldn't know.

You wouldn't know. Exactly. That's what I'm saying. Don't trust one system. I think one thing that AI has also taught us is biasing. You don't want to get biased to using one single tool because it only knows what it knows. So, unless— that's why whenever you are doing evaluations and stuff like that, you evaluate with different LLM models and judges. That way you're able to compare and contrast, like similar to how you run an idea by 4 people. You want to be able to evaluate using different AI tools as well.

That's why I'm talking with so many founders and I found like, so everybody has different opinions. There's a school of thought about only vertical AI will survive. And there's another school of thought of the future is about horizontal AI that solves everything, solves all the problems.

I think everybody will survive, just that there'll be a race. It's a race, right? Today, one tool is better than the other tool. Tomorrow, the other tool is better. So it's like, It's like driving on a highway. We all drive at different speeds and eventually everybody gets to the finish line, right? Some people who drive fast maybe are ahead, but they meet an accident and it slows them down, right? So we are on a highway of AI and it's a constant journey and we are all going to reach that end, whatever endpoint, just that some people may reach faster than others because they applied something that's working better for them. But eventually everybody will.

You know, because we are both in Silicon Valley, I wonder, do you think we're in a bubble right now?

In Silicon Valley, technically, yes. I think there is a little bit of higher confidence or higher— anybody you talk to, I don't know anybody in Silicon Valley who would consider themselves pessimists for AI, right? So, Silicon Valley always has been on the leading edge. That means we believe in things even before it becomes real, right? Certain things. That's how Silicon Valley evolved. Like, all these companies that have come for the 30 years, the companies that I've seen, come and gone. They all believed in something, they built something, they made it big, and then if they kept experimenting, then they've gotten better, right? So the Apples of the world have continued to evolve and become better than that. So I think, yes, in that sense, we are a bubble because we are always challenging the status quo. So most important thing again is same thing. What works in Silicon Valley may not work for the rest of the world. So you have to be able to try out solutions that work in other places. too, right? So if you build something that works in for companies in tech in Silicon Valley, you may want to try it out and see whether it works for companies that are in Midwest for a company that is not tech first and see whether the same solution is able to work for them. So that's my take on being in the Silicon Valley.

It's interesting. My last guest actually have a question for you and he didn't know it's going to be you, but I'll ask the question because I think it's relevant. He wants to know. Do you know how many AI agents do you have in your organization?

My IT wants to know so that they can put some guardrails around it. It's like, I'm sure there are hundreds of AI agents that are there. Like, even I myself run a few AI agents on my machine, which are doing different things. So, each one has their own threshold. So, it's very hard to give me a number. Ideally, the number of AI agents should be more than the number of employees in the Right? That's all we're saying. At some point, the number of AI agents will be a lot more. That means everybody has a digital AI worker that's working for you, or more than one digital AI worker that's working for you. That means that we should be able to leverage the power of AI to do the work for you.

You know, the interesting thing is, as a company leader, you kind of know how many employees you have in your organization roughly, or you can look it up. My last guess is doing auditability, observability on AI agents. So that's why he asked that question. Do you think this is just a matter of time that we would treat AI agents just like how we treat our employees? So they're going to have their IDs and we'll know how many of them we have and how they're put on everything?

It is. Exactly. I think that is exactly where we are going because we want to— more than anything, it's mostly to make sure that they're doing the right thing, right? We don't want any rogue AI agents. We don't want any AI agents that are doing— right now IT has access to the information of how many AIs are running. We do have a little bit of observability in place. Just that I'm not the IT guy, so I don't see that data, but IT sees a lot of that stuff. Because anything, anytime you're using some of these AI tools, it goes through our SSO. That means that it's getting logged somewhere. That means we know exactly who is using AI where, right? So we do have that information. Are we putting checks around like what should you do and not do? Yes. The larger the corporate, there are some checks to say you cannot access certain tools. We only give you access to some other tools. So there is a little bit of balancing that happens, but it is important that they will be similar to human. The non-human AI agents is getting— the number of non-human AI agents is growing. So naturally, as a company, they should be able to say, oh, I have X number of non-human AI agents and they're doing X, Y, and Z. Similar to having a company to say, we have 4,500 employees. Out of which X number of people are in engineering, X number of people in HR, X number of people in finance. Similarly, you should be able to classify and say, I have X number of non-human AI agents doing these functions, some working in IT, some working in HR, some working in finance and doing different things. And that way you can, like, you can turn off access to employees when they go away. Similarly, you should be able to turn off, turn on and off access to these AI agents too, depending on what they're doing and what they're not doing.

Yeah.

So, this is where the technology's evolving to make sure that you have visibility, you're monitoring, and you have control over those actions. That way, if something goes wrong, you're able to turn everything off, right? So, this is where all the technologies that are being built are evolving towards.

Yeah, it's definitely scary. It almost feels like the digital agents or digital employees can actually become everywhere in our daily life. It's in a sense sci-fi and in a sense scary.

That's why, that's why it's important, important to, you cannot just deploy any agents, any, everything should be backed by proper authentication and authorization. That means you cannot set up any agent which does not have access controls, which does not have role-based access. That way you ensure that it's limited by the powers of what it can do. You don't wanna have an agent which has superpowers and does anything it wants, right? You want agents that if you're creating an agent for yourself, the agent should have similar powers or limited powers. It cannot have superpowers because you don't wanna give that. Yeah. So that's where the companies have to manage their IT controls really well. There's a lot more work for our InfoSec teams and IT teams within the companies right now because they're constantly looking at, oh, what is somebody doing that they're not supposed to be doing?

Yeah, that calls back to earlier what we were discussing, the adoption curve this year. We're making mistakes like Open Call, right? We're seeing those and then we're fixing those along the way. So that's—

Exactly. Exactly. Yeah, exactly. That's where we are right now. We are making all those mistakes and we are finding those mistakes are expensive and we are fixing them along the way. And it's going to go through that cycle and in a matter of months and years, it's going to get better and then it's going to get more complex. you're going to get locked up on.

Okay. I close every conversation with this. If you could recommend me and my audience and your audience to a book, what would that be?

Yeah, so I've been reading a lot of books, but I think this one book, which is interesting, again, it came out a little, a year back. It's called Co-Intelligence by Ethan Malik. I don't know whether you've heard of it. It's like living and working with AI. And that is where Where Ethan talks about, he's from Wharton, he talks about how framing of AI is not just another technology, but something that we increasingly work alongside. And that's what we are seeing right now, right? All the agents that are building is working, you're working alongside those agents. And we just talked about all these new digital AI workers that are doing your work. So the key thing is always invite AI to your table. Use it for everything that you want to use for and learn to know its limits. Be the human in the loop so that you don't blindly trust its output, always review it. And then treat AI like a person. That means give it a persona, give it a background, give it a constraint to get the best results. And assume that this is the worst AI that you'll ever use. That means the technology is getting exponentially better. So build habits that will make you change how you're doing what you're doing. So don't just believe that, okay, this is the best AI, it's going to get better. So be ready to change.

Thank you, Merliz, so much for the conversation. It's really fun to chat with you and understanding what you're building and things you said that really resonate with, like the looking for challenges, right? It's the right way of moving forward. Just not thinking, we shouldn't be maybe thinking about how to become irreplaceable, even though it's in our head, right? But because, because This ongoing anxiety of there's no more job security. So, as engineers and the builders, it's in our head, or maybe this is true for everybody, but you talked about how you're adapting to this day and age on organizing and structuring not just your product, but also your teams. And you are sharing that intelligence and insight with us as well, how we should become more adaptable to this day and age and make us more not maybe not irreplaceable, but more adaptive and more comfortable. I mean, in this time.