Siddhartha Ahluwalia 0:51
Hi, this is Siddhartha Ahluwalia. I’m your host and managing partner at Neon Fund. A fund that has invested in some of the best enterprise AI companies between the US-India corridor, like Atomicworks, SpotDraft, CloudSEK. Today I have with me Animesh, founder of PlayerZero. Animesh, so excited to have you today.

Animesh Koratana 1:09
Super excited to be here. Thank you for having me.

Siddhartha Ahluwalia 1:11
So Animesh, PlayerZero is a very interesting concept. Like you are building self-healing code. That’s almost like you are taking us into Terminator or Matrix.

Yeah. Tell us, you know, the background of PlayerZero and then obviously your background.

Animesh Koratana 1:27
Yeah, for sure. So PlayerZero, I think, was a long time coming for me. It was something that I’d been thinking about for a while from many different threads in my life that actually came together.

The first one actually starts with my dad. So my dad was a founder of a company as well. I basically would spend actually just doing support and QA for him.

So that was a family business, one of the first software kind of businesses in Atlanta. And so that gave me a lot of kind of empathy for what it took to actually maintain and operate software. My dad was a CTO and he would be building a lot of stuff and a way of hanging out with him would just be, you know, like, let me go help you do QA or whatever.

And many years later, I was at Stanford and just by virtue of some of the research that we were doing, we were working on model compression and inference and stuff like that, you know, we got exposed to language models. So in 2019, 2020 time, GPT-2 had just been trained. And that was, I think, one of the first language models that came together and was coherent over longer horizons.

And there was a variant of GPT-2 that was called Codex. And this is kind of the same name has been repurposed now for all the stuff that we know about Codex now. But this is actually the model that GitHub Copilot started building on top of.

And so that was the first time in my life where I saw, you know, computers writing code. And there was just like this holy shit moment, right? Like, what happens now?

What does the world look like when computers are writing more and more of our code? Like, how do we maintain it, how do we operate it? And I couldn’t stop thinking about the work that I used to do with my dad.

And so, you know, it became a little bit of like an obsession. I started off in research and I think one of the open questions that we were thinking about is just how do you understand software? And how do you model it?

Because understanding often tends to be the bottleneck to being able to, you know, inflect change or to be able to do all the support in production engineering. And so that was kind of the initial impetus, right? It was these like two, three threads in my life actually coming together.

We knew that something like ChatGPT was going to come out. We knew that the way that we developed software was going to change. We didn’t quite know when, but we knew that we wanted to be a part of it.

We knew that we wanted to be, you know, kind of addressing kind of the second-order effects of the change that we were about to see.

Siddhartha Ahluwalia 3:49
Got it. And so today AI is writing at least 25% of an enterprise code, but the review, the human review is literally falling short of it today. How are folks coping up with it? And how does PlayerZero play a role in that?

Animesh Koratana 4:03
Yeah, that’s actually a great question. I think actually there’s like one kind of abstraction above that I think we should talk about first is, you know, what is missing in enterprise AI? And, you know, especially as we kind of think about the second-order effects of AI-generated code, like how do we actually close that gap?

PlayerZero’s view of the world, right, is that you have all of these different kind of disparate functions that operate production software. And, you know, one of those functions is QA, right? Thinking about, you know, how the code that we’re writing is actually going to affect our customers in the future.

But then we also have support, right, which is essentially doing the inverse of that, right? Something broke, now I need to go fix it. And then we also have SRE, right, which is something that’s changing in the infrastructure, right, is breaking there.

And all of these different slices, right, of functions, right, that we use to basically operate production software essentially construct independent views of how that production software actually works. And the central thesis behind PlayerZero is basically that the central model doesn’t exist, but with AI we can actually model how production software actually looks like. And if we can do that well, then we can actually centralize and own all of the work that happens on top of it.

And so fundamentally what PlayerZero is is that we’re a production engineering platform that builds a central model of how production software operates between your code, between your telemetry systems, between your ticketing systems, between the intent of what the developers are writing and the actual reality of what’s happening out there. And if we can model all of this stuff, then we have agents that’ll run QA for you, that’ll run support engineering, that’ll run SRE, and do it in a very leveraged way, right. Now, to directly answer your question, right, there’s a ton of code being written, and now there’s a second bottleneck that’s kind of happening in review.

How do we make sure that these bugs actually don’t come out? The intuitive way that we actually solve for this is that because we have a central understanding of all the things that are actually breaking out there, we can actually do a great job of actually figuring out if you change this area of the code, here’s actually how it’s going to break, because we understand how production actually breaks. And this makes a lot of sense because if you think about the most senior engineers, let’s say, in any organization, what do they bring when they’re actually doing a review? They have kind of an institutional memory. They have context about the last five years, the last 10 years. We all know that guy, right?

He’s been in the company since the beginning and knows everything about everything, has seen every nuance of how the system breaks and the failure modes and state, all those different things. Essentially, that’s the institutional memory that PlayerZero is building, and we can bring that into the QA cycle. We do a lot of other cool things, and we’ll talk about it later, like code simulations and stuff like that.

The real advantage actually tends to come from, hey, you changed this area in the code, and eight months ago, there was a customer that complained about this particular issue. They couldn’t upload an invoice. The code that you’re changing right now is going to reintroduce that problem, and this is why that matters, right? That signal-to-noise piece is extremely difficult to solve, and I think we have a pretty compelling answer.

Siddhartha Ahluwalia 7:12
Now let’s talk about the system that you have built that you pointed out. Yeah. How does this context reside in PlayerZero? How do you build that? Obviously, what kind of system is it with UI and what kind of backend?

Animesh Koratana 7:29
How many hours do you have? It’s not a simple answer. Actually, one of the pieces that we wrote about context graphs actually was a byproduct of some of the pieces of the system that we built, but there’s a couple of really important architectural pillars to what we built.

One is we think a lot about not only the context but also the people in the process associated with a lot of the workflows that we’re dealing with. For example, when a support ticket comes in, the remediation path isn’t just about bringing code and tickets together. It’s about also navigating through multiple different people in the organization that gate the remediation or gate the escalation path.

Sometimes it’s about actually verifying hypotheses with different people or using tools at your disposal to fill in the gaps that observability may not be able to. There’s all of these different edge cases based on the contours of any piece of software that are important for agents to be able to navigate in order to be really effective. When it comes to the UX and things like that, we’ve created a lot of different levers to be able to define what is the contour of your workflow?

What should it look like? What is the remediation path for your organization? And to be able to create autonomy in that entire flow and then create checkpoints so that you can tune the degree of autonomy that you really want to adopt.

The other pieces, I think from a pure technology standpoint, a lot of actually what we have to consider is what is the decision path for agents truly on the authority of ticket remediation or incident resolution or even of QA? And this is actually where the idea of context graphs really came from, which is we have all of these systems of record that store outputs, but the way that we actually have to architect agentic systems that can build reinforcing loops to learn the work that they’re doing have to also capture the decision dynamics within any organization and then ultimately encode them back. And so that implies a lot of representation learning, a lot of really interesting agent setups, multiplayer agent setups that can actually navigate multiple personas in an organization, and yeah, and a lot more.

But these are, I think, two among many others of really important architectural pillars that we have to think about when we’re building a system like PlayerZero that is essentially a counterpart to a lot of these coding agents and addressing some of these second order effects.

Siddhartha Ahluwalia 10:09
So I want to dive into a very interesting topic, and please explain this as layman as possible.

Animesh Koratana 10:15
Sure, yeah.

Siddhartha Ahluwalia 10:16
Because our audience comes from all different backgrounds. So how did you write the first paper on context graph? And then how did you forwarded it that became the viral piece by Jaya and Ashu from Foundation Capital?

Animesh Koratana 10:36
So context graph.

Siddhartha Ahluwalia 10:39
We can start with what is context graph.

Animesh Koratana 10:41
What is a context graph? That’s a good question. A context graph is a representation of the decision dynamics in an organization.

It often basically draws a line, or it represents a fabric that connects people and different systems of record, all in a problem-directed way when you’re trying to answer a particular question, when you’re trying to solve a particular problem or take a certain action. The key insight behind context graphs was that the last decade of SaaS basically has been built around this idea of a system of record. I think Salesforce is a good example, probably the most central system of record, probably the most popular one out there.

Salesforce is a great system of record, but it represents the output, represents that this deal was sold for this price at this time. But a lot of the decisions and the path to getting to that deal ends up being lost. Why did I price this deal at $100,000 instead of 50? Why did I discount it? Did I price higher? All of those things.

And there’s a lot of nuance to this. But a lot of actually what, when a new employee comes on, what they have to learn is actually the decision dynamics, not just, hey, this deal was sold for $100,000. And the last year, 2025, was supposed to be the year of agents, especially the year of agents in the enterprise, but it never really delivered.

And a lot of actually what we were thinking about over the course of the year was like, why not? And I think the reason context graphs went as viral as they did is just because I think for the first time we put a finger on what that gap really looks like. And took a kind of a prescriptive stance on how to actually close it.

And so that’s what context graphs are, right? Context graphs are a model of the decision dynamics in an organization that model the why in addition to the what. And it’s, I think, a counterpart to the traditional systems of record that I think can actually be really helpful for agents to compound the institutional knowledge that they naturally create and then also participate in as they become productive members of an enterprise.

Siddhartha Ahluwalia 13:12
The second part is, as soon as you’ve written this piece, how did you share it with Jaya and Ashu? How did it become viral?

Animesh Koratana 13:19
Yeah, I mean, to be honest, actually, the word context graphs, I have to give credit to Ashu and Jaya. They were the ones who actually figured out that this word should be something that is popularized. But the idea of context graphs is something that actually we’ve been circling for a very long time.

This is actually a very central tenant of PlayeZero. And I’m going back to what PlayerZero is. PlayerZero is an AI production engineering platform. And our central belief is that there is a central model of how production software should work. Not should work, but actually how it does work. And that model is not represented anywhere.

The reality of how production software works lives somewhere in between your code base, your thinking system, your telemetry systems, the complaints of your customers, the incident response paths. It’s messy. It’s really messy. And in order to model this, a lot of the technology that we were building ended up resembling a context graph. And by the way, to be clear, it’s actually not a graph. That’s actually one of the biggest misconceptions around this whole thing.

It’s actually not a graph. But a lot of the technology that we had to build actually just was trying to represent the decision dynamics in a way that agents could actually get better the next time that they ran. That they could learn from this incident so that way the next time they could be better. Or they could learn from this ticket remediation or this particular PR. So that way the trajectories and the why behind the decisions can actually be encoded and kind of externalized in some meaningful way. The…

So it’s been a very central tenet for PlayerZero for a long time. I think actually the first time Ashu and Jaya and I met before they’d even invested in us, actually the first conversation actually was about this. During the course of last year, I think there’s been a lot of noise in AI, obviously.

And very consistently what our customers have told us about why we’re different has actually come down to PlayerZero’s ability to understand nuance. The quality that we bring about how PlayerZero understands the decision dynamics and how we’re able to understand just more than an AI agent usually could. And for a long time I was struggling with how to articulate this really well.

So over Thanksgiving I actually ended up writing a long memo just that Thanksgiving tends to be the first day in that period of time when customers are quiet, your team’s quiet. So I was just sitting at home and I was like, let’s do this. So I wrote two, three pages on what is PlayerZero and what succinctly actually makes it different.

And I shared it with them and that’s basically all we ended up talking about for the next month. And I think that along with everything else that we were learning at Market ended up kind of motivating some of the context graphs pieces and stuff like that that we published at the end of December.

Siddhartha Ahluwalia 16:20
So how does context or the outcome of PlayerZero look to an enterprise? Is it like a UI that shows all the problems in the production? I’m just trying to imagine it.

Animesh Koratana 16:34
Yeah. Context graphs are quiet. They’re not something that their representation is not necessarily something that is consumable by humans.

It doesn’t have to be. And I think it’s actually vertical specific as well. But for us, context graphs manifest in the way our agents make decisions.

Our agents are able to retrieve an understanding of what was the last time I saw a problem that looked similar or felt similar. I think actually a great analogy for this is how does experience manifest in an employee’s work? Somebody’s like the amount of time that they spend in your company compounds the amount of experience they have and the amount of context that they have in their ability to be effective the next time they have a decision that they have to make.

And I think that is actually very similar to if you model context graphs really well, agents can actually experience something similar. And that actually ends up becoming a mode. And I think that’s also really important for how AI agent companies end up differentiating over time.

That ends up becoming a mode because now you have one agent that responded to an incident in a certain way and we realize that there’s two or three nuances that we missed. And now we can actually go figure out how to reinforce our central model of how that production software works. So that way the next time the same mistake isn’t made the same way.

I think there’s also long horizon relationships in ways that this manifests. I’ll give an example. In order to debug any problem usually we end up generating a whole bunch of hypotheses.

Those hypotheses say if the system is in this particular condition then I expect it to behave in this way. And if that’s true then that would explain this ticket that this customer actually came up with. And our agents come up with a bunch of different hypotheses informed by the past, informed by tickets and whatever other context that they can gather.

And they go and run these simulations to go and verify those hypotheses. What’s really interesting is that simulation actually ends up being embedded into that context graph. And then you were asking about QA earlier. What ends up happening in the future? Maybe six months, maybe one year, maybe five years in the future. Somebody’s going to go change that area in the code again. And PlayerZero is automatically able to now pull that back and say, hey, you know what? There was an incident six years ago. And six years ago this incident was related to this particular area in the code, this particular area of the infrastructure. You seem to be changing something in this particular area now. And I ran that simulation again. It seems like you’re about to break it.

And there’s this deja vu moment. And it just completely blows people’s minds. It’s like, oh my god, I wasn’t even there when that happened. How did you know? And so this kind of thing ends up compounding with time. And this actually also is a very expensive part of running enterprise organizations, which is just the institutional knowledge. And now context graphs, I think, are an opinionated way of actually capturing institutional knowledge in a way that agents can access and benefit from.

Siddhartha Ahluwalia 20:03
So the way I’m trying to imagine the PlayerZero, you know, how it works in enterprises, as soon as a developer is writing a code, do you set an ID?

Animesh Koratana 20:11
No, no. So we actually live asynchronous in the cloud. And the reason for that is because we’re a complement to a lot of these AI coding agents and stuff like that.

We’re not actually helping you develop new features. We can help a little bit, but that’s not the primary use case. The right way to think about this is like, imagine an incident gets escalated, or a ticket gets created, right?

Your customer ran into a problem. And PlayerZero is basically listening to your ticketing system. You’re listening to your alert stream or whatever.

And every time a problem gets escalated, PlayerZero is the one receiving it, as opposed to a human.

Siddhartha Ahluwalia 20:51
So you respond at the time your ticket is getting created.

Animesh Koratana 20:55
So the moment a ticket gets created, we’re going to go kick off a workflow. And that workflow is going to say, okay, well, let’s go read the ticket, and let’s go figure out what the root cause of this actually is. And once we find the root cause, let’s go find the two or three people that really need to approve the escalation path.

PlayerZero will decide, hey, this is an engineering system, or this is an engineering problem, or this is not an engineering problem. I should deflect this. And it’ll go and navigate the organization to actually go and handle that entire ticket.

And I think one of the really interesting mindset shifts that customers have as they start adopting PlayerZero in these critical workflows, the fundamental shift tends to be that PlayerZero is the one holding the bag, as opposed to the human. And the shift actually changes a lot. There was this moment actually just a few weeks ago when a customer came to us and they were like, I haven’t played around with a lot of AI tools that have really impressed me, but PlayerZero really did.

And I was trying to figure out why, and the customer basically said, PlayerZero was the first time that I actually felt like I was a tool to the agent.

Siddhartha Ahluwalia 22:12
Because the agent is telling the human what to do.

Animesh Koratana 22:15
The agent is telling the human what to do for this sliver of this much longer decision lineage that it needs to do. If a ticket comes in over here, you have to root cause it, you have to go figure out whether to reflect it, you have to escalate it, you have to fix it, you have to test it, and then you have to go follow through and make sure that it actually solves the problem. And there’s this long thread that actually spans eight or nine different functions.

And because there’s so much context switching that happens along the way across these nine different functions, a ticket takes four weeks to resolve. Or an incident takes three days to resolve instead of two hours. And because of that, when PlayerZero shifts in, when it starts holding the bag for this entire remediation path, the change basically becomes PlayerZero is now actually owning the thread across the entire thing, but halfway through it realizes, hey, this particular engineer should approve what I’m doing to make sure that I’m not compounding errors in any bad way.

So it’ll actually navigate the organization along with navigating the problem to make sure that the entire follow-through happens. It happens repeatably, it happens in a way that people can predict, it happens really fast, and it happens more accurately than ever before. And so these are really compounding advantages.

And then on top of all of this, you have this context graph underneath it, you have a, we call it a world model, a production world model. And every time we actually own the entire decision, we get better. And so there’s this compounding element to this as well.

Siddhartha Ahluwalia 23:49
So when you sell to an enterprise, are you selling to the ticketing department that will make your tickets resolve faster, better? Who are you selling to?

Animesh Koratana 23:57
So it often tends to be the engineering leader. VP, SVP of engineering.

Siddhartha Ahluwalia 24:02
But you’re not sitting on customer tickets.

Animesh Koratana 24:05
We are sitting on customer tickets. Think about it this way. There’s two ways to make engineering teams more productive.

You let them do more in the amount of time that they spend coding, or you give them more time to spend coding. And the answer is you have to do both. And so engineering leaders are often thinking about in this AI native world, they’re investing a lot already in cloud code and cursor and all these things to make the velocity of the engineering team faster.

But I think there’s now the secondary realization of the more code that I put in production, my engineers are now just going to get more and more distracted. They’re in the decision path of solving the problems that they’re creating. And the SVP of engineering are very familiar with that.

They’re very familiar with that problem. And oftentimes, the technical escalations and mediations end up rolling into them. So this is a problem that they have budget for, that they’re actually actively trying to solve, that they’re hiring for.

Their engineers don’t want to be dealing with anyway, because they would much rather be building software. And so it’s a very hairy problem. It’s a cross-functional problem too.

And I think that’s partially what you’re getting at as well. So there are support leaders that often get involved in the evaluations. There’s QA leaders.

But the buyer and the owner of this problem is very centrally the engineering leader, because they understand both sides of the coin.

Siddhartha Ahluwalia 25:34
Just to make it very clear, you go to a VP engineering or the CTO for discussion on PlayerZero, and you tell them that, hey, all the codes that you are writing today with flawed, the issues that it will cause on your customer side, PlayerZero sits between your code and the customer tickets, and then let you know that, hey, this issue on the customer got caused by this code, but also the code that you are writing now, it will cause that issue in the future, which is not yet there. It’s just cross-functional rather than just…

Animesh Koratana 26:11
Exactly. I genuinely think that as we start centralizing this context, all of these different functions that we were talking about earlier, starting from SRE on the most reactive infrastructure-heavy side, all the way down to support engineering and then QA, I think actually a lot of these functions will actually start merging together over time. I think the intuitive reason why is because they all operate on the same context in order to be effective.

And so, if production engineering is kind of what you’re trying to automate, trying to run, and this is kind of where that self-healing aspect comes from that you were talking about earlier, if that’s really what you’re trying to operate, it is a natural complement to the way we think about agenda development.

Siddhartha Ahluwalia 27:02
And you had mentioned earlier that software needs to be treated like biology. It’s no longer a machine, but an organism. Why is that?

Animesh Koratana 27:14
I’m curious on your thoughts too, but if we think about the growth of software being something that is purely mechanistic, we just won’t be able to keep up with it anymore. I think this idea of an immune system often comes to mind for me. What does our immune system do?

Our immune system is like a barrier between our biology and reality. And it is so well-tuned to the degree where I actually don’t have to think about it. As software grows and as the pace of it becomes something that we start loosening our grip on, as Claude Code comes in, as Cursor comes in, we’re all feeling this already at all of our companies.

The pace of development is 5x, 10x. I think the enterprises are a little bit behind, but they’re not that far behind. I think everyone’s feeling these fractures.

There’s this asymmetric pain that we’re going to feel on the other side if we keep trying to support and operate our software the same way that we did before. I think a great analogy for this is you could only build faster cars when you build airbags or seatbelts. I think there’s a version of that that basically needs to happen here too.

If we keep thinking about every single support ticket needs to be dealt in this particular way, just that the process is not going to scale. And so what we need is some system that is constantly operating in this gap between the operating of engineering team, the net new development that’s happening, and reality and constantly reinforcing itself to get better and better over time.

Siddhartha Ahluwalia 28:58
What is the delta that you pitch? Obviously better code, faster resolution of tickets, but do you pitch cost savings to the enterprise? What do you pitch?

Animesh Koratana 29:08
I think the first order ones tend to be lower MTTR, so you have tickets and incidents that are remediated faster. I think the second one tends to be lower defect escape rate, which is fewer bugs going out to production to begin with. Between all of that, there is some degree of cost arbitrage where maintaining and operating production can be done faster, cheaper, better.

I think that there’s a version of that, but I think generally, at least as of today, I don’t know if I’ve met an enterprise SRE team or an enterprise support team that says, yeah, actually, we’re well set. Everybody’s underwater, and they’re becoming more and more underwater because again, the pace of development, the pace of change in software is much, much faster than anybody can truly internalize and understand. By the way, this actually goes back to the biology piece of this.

For machines, we understand everything about how it works, but in biology, we don’t, but it still just works. It’s because we have these systems and processes in place that can adapt and learn and evolve over time. Our pitch to enterprises tends to be, yeah, we’ll help you on these metrics, but at the same time, we’ll actually establish a new way of working, a new way of operating and maintaining software in production that allows you to create leverage for all of the different people that are participating in it.

Siddhartha Ahluwalia 30:41
It sounds like a good idea, but I’m not able to get how real this is.

Animesh Koratana 30:46
Yeah.

Siddhartha Ahluwalia 30:48
There’s an immune system for your cluster, and the software is healing itself. Practically, how is this possible?

Animesh Koratana 31:18
Well, practically the way it’s possible is, let’s think about the full loop. We talked about a bunch of different workflows. Let’s think about the whole loop. um On one side, anytime that there’s a bug, a customer is reporting a ticket, there’s an incident, there’s an alert. There’s a system that is now dealing with every single one of them. It’s automatically finding root causes, it’s automatically remediating, it’s automatically creating code changes, approving them, and then ultimately getting them back into production. There’s a self-healing loop there. At the same time, what does the other thing our immune system does? It learns. I got the flu a few months ago. I’m not going to get the same flu again.

There’s a learning aspect to this, too, which is every single support ticket that’s being dealt with becomes an antibody. Each of those antibodies now actually go back into the SDLC. Any time when there’s a code change that’s made, PlayerZero is going back and analyzing those code changes and then saying, hey, you know what?

These are the antibodies that are most likely related to it. These are the support problems from the past. These are the incidents from the past that I think are very much related to it.

I’m going to go simulate all of those different conditions and then tell you before this thing has even gone into production whether you’re going to break those things again. There’s this self-reinforcing piece of this, which is again why that immune system analogy often comes back. Very practically, it’s like fix problems faster, prevent problems.

The way we do that, it tends to be through these workflows. It tends to be through the code simulations and all these other things that we’ve been talking about. Yeah, that’s what self-healing really means.

We’re not yet at a place where you can turn off the lights and just have PlayerZero go nuts. To be honest, I don’t think any AI is there yet. But it’s pretty damn close.

It’s really exciting in a world, especially like we see this, we use our own product every day. It’s kind of at the place now where support tickets are dealt with in half an hour. That’s something else. We haven’t really…

Siddhartha Ahluwalia 33:05
Support ticket is getting resolved in half an hour.

Animesh Koratana 33:07
Yeah, it’s crazy. And without human intervention.

Siddhartha Ahluwalia 33:10
And this is without human intervention?

Animesh Koratana 33:12
Yeah, very minimal. There’s an approve button that somebody clicks along the way.

Siddhartha Ahluwalia 33:16
And the code changes?

Animesh Koratana 33:17
And the code changes, yeah. PlayerZero will make the code change.

Siddhartha Ahluwalia 33:20
And it will make the changes in production?

Animesh Koratana 33:21
Well, it won’t deploy it without express consent. There’s one or two moments of human intervention. But it’s pretty damn autonomous. We’re not context switching from the stuff that we’re doing. PlayerZero is the thing owning the entire remediation.

Siddhartha Ahluwalia 33:40
So some of the players are also trying to build this bug-bought-by-cursor. So where do you think that PlayerZero fits in when the coding system starts building the self-healing?

Animesh Koratana 33:53
Yeah, so I think the answer often comes down to context. We were talking about context graphs earlier. The efficacy of these agents are highly tied to the context that they’re operating on top of. The central thesis of PlayerZero is that there is no central model of production today. And that PlayerZero is going to go build that, and then it’s going to own it. So the types of problems that we find are very different. So for example, bug-bought tends to be, hey, you forgot this question mark here. And that’s a null check. And if you run the code, you’re going to get a null pointer exception.

The types of problems PlayerZero is solving, again, because of the context that it has, tends to be, you know, Animesh was uploading an invoice six months ago, and that particular condition is going to break again. And then Animesh won’t be able to upload his invoice anymore. And so these are two very different things.

Arguably, it’s like the difference between code review and QA. One is stylistic and the feel of the code. The other is based on reality, based on use cases and customers. And then beyond that, obviously, I think there’s the remediation, SRE, all of those things, where today I don’t think the coding agents are actually optimizable for that at all.

Siddhartha Ahluwalia 35:18
And one question is, how did you choose your students to be the investors? Because did they understand the depth of what you’re building?

Animesh Koratana 35:27
I think generally, yes. But I think it’s like PlayerZero has been around for a few years. It started as a research project, broadly, and just trying to model and understand large code bases.

If I were telling you we started in, what, 2021, 2022 time? If I were to sit here and tell you that I knew exactly what PlayerZero was going to be today in 2021, I’d be lying to you. ChatGPT wasn’t even out.

And I think we kind of knew down the barrel of the gun, something like this was going to come out and AI was going to be less of a toy and more of something that people would take seriously and want to deploy into production. But I didn’t even know what it was going to be. And so if I didn’t even know, how would our investors know? I think what our investors have actually been really helpful with is pushing at the right time and being patient at the right time. I think that’s a calibration that I’ve really learned to appreciate. I think the other piece is learning the process of building great companies that are durable. I’ve watched this with my dad too. It took four years to actually go find the right business. And again, it goes back to sometimes being patient and other times being extremely aggressive. I think that’s something that we’ve learned from our investors. And we’ve also chosen investors that I think understand calibration really well.

Siddhartha Ahluwalia 37:01
What’s next for PlayerZero in 2026?

Animesh Koratana 37:03
I mean, the time is now. The really interesting inflection we’ve seen over the last three or four months is that the models have gotten good enough that agents can actually run the entire workflow. They’re not additive to individuals.

They’re the ones that own the work, and then we’re additive to its working. And with that, I think a lot of these second-order effects of the pace of software development need to be dealt with. And I think it’s a very understood problem among engineering leaders across the Fortune 500s, across actually really everybody.

Anybody who’s running a software team that’s supporting customers, I think everyone’s really kind of universally feeling this problem, and we’re all starting to feel it at a similar time. And so what that means is the time is now. PlayerZero has been growing a ton, essentially doubling over the last couple of years.

Siddhartha Ahluwalia 38:04
Okay, so you have been doubling every quarter in terms of number of customer counts or what?

Animesh Koratana 38:09
Almost on every dimension, which has been incredible.

Siddhartha Ahluwalia 38:12
So in a year, which means that you have almost grown 16 times?

Animesh Koratana 38:19
I mean, in terms of people, for sure.

Siddhartha Ahluwalia 38:23
How big is your team now?

Animesh Koratana 38:24
Almost like 32, 33 now.

Siddhartha Ahluwalia 38:26
All in SF?

Animesh Koratana 38:27
It’s split between Atlanta and San Francisco.

Siddhartha Ahluwalia 38:30
So, where is your CRO and CTO?

Animesh Koratana 38:33
So our CRO and CTO are in Atlanta. Our AI team is here in SF. I’m here in SF. I end up going back to Atlanta often, so we end up seeing each other every couple weeks anyway. But yeah, I’d say at least two-thirds, almost three-quarters of it is in person.

Then we have to get a few folks, you know, or who knows.

Siddhartha Ahluwalia 38:54
Thank you so much anyway. Love learning about PlayerZero from you.

Animesh Koratana 38:58
Yeah, thank you so much for having me.

Siddhartha Ahluwalia 38:59
I’ll take away, you know, self-healing code has become real.

Animesh Koratana 39:02
Yeah, it’s becoming more real every single day.

Siddhartha Ahluwalia 39:05
We have got a real immune system into our code.

Animesh Koratana 39:08
Yeah, awesome, awesome. I will absolutely do it. Thank you so much for having me.