What if AI has Immunity like Humans? Ft. Animesh Koratana, PlayerZero

Will your software soon be a living organism with its own immune system?

Animesh Koratana, founder of PlayerZero, started his software career long before he founded the company. Growing up in Atlanta, he spent his childhood inside his father’s software business, watching engineers sitting through the unglamorous work of QA and keeping systems alive after launch. He saw early that writing software was only half the problem. Maintaining it was the real battle.

Years later at Stanford, he witnessed the birth of GPT-2 and Codex, the very foundation of GitHub Copilot. While much of the world focused on how AI would help engineers write software faster, he became obsessed with a different question: What happens when companies are flooded with AI-generated code that no single engineer fully understands?

With PlayerZero, Animesh is building toward what he calls self-healing software: systems that behave less like static machines and more like living organisms with their own immune systems.

At the center of that vision are “Context Graphs” which captures the "institutional memory" of a company: the deep knowledge held by a senior engineer who has spent years understanding how complex software breaks, the failure modes it develops, and the decisions behind fixing it.

If you are building software today and wondering how reliability, debugging, and ownership will work when machines write most of the code, this episode is for you.

0:00 — Trailer
0:45 — Building Self-Healing Code
2:03 — First Exposure to LLMs Through GPT-2
3:45 — What Is PlayerZero?
5:42 — Institutional Memory of a Senior Engineer
7:10 — How Context Is Built
10:06 — The Viral “Context Graph” Piece
16:24 — The Outcome PlayerZero Delivers
19:59 — When the Agent Tells the Human What to Do
23:43 — Who Is PlayerZero Selling To?
26:56 — Why Software Should Be Treated Like Biology
28:54 — The PlayerZero Customer Pitch
30:37 — Can Software Really Have an Immune System?
35:15 — How Animesh Chose His Investors
36:55 — What’s Next for PlayerZero?

-------------

India’s talent has built the world’s tech—now it’s time to lead it.
This mission goes beyond startups. It’s about shifting the center of gravity in global tech to include the brilliance rising from India.

What is Neon Fund?
We invest in seed and early-stage founders from India and the diaspora building world-class Enterprise AI companies. We bring capital, conviction, and a community that’s done it before.

Subscribe for real founder stories, investor perspectives, economist breakdowns, and a behind-the-scenes look at how we’re doing it all at Neon.

-------------

Check us out on:
Website: https://neon.fund/
Instagram: https://www.instagram.com/theneonshoww/
LinkedIn: https://www.linkedin.com/company/beneon/
Twitter: https://x.com/TheNeonShoww

Connect with Siddhartha on:
LinkedIn: https://www.linkedin.com/in/siddharthaahluwalia/
Twitter: https://x.com/siddharthaa7

-------------

This video is for informational purposes only. The views expressed are those of the individuals quoted and do not constitute professional advice.

Transcript

SPEAKER_00 0:00

You're building self-healing code? That's almost like you're taking us into a terminator matrix.

SPEAKER_01 0:06

So that was the first time in my life where I saw computers writing code. And there was just like this holy shit moment. What happens now? How do we maintain it? How do we operate it? Layer zero people now and say, hey, you know what? There was an incident six years ago. You seem to be changing something. I ran that simulation again, and it seems like you're about to break it. And it just completely blows people's minds. Think about the most senior engineers in any organization. What do they bring? They have an institutional memory. They have context about the last five years or the last 10 years. Oh, we all know that guy, right? Like he's been in the company since the beginning and you know knows everything about everything. That's the institutional memory that PlayerZero is building.

SPEAKER_00 0:49

Hi, this is Bhahat Alwaliya. I'm your host and managing partner at Neon Fund, a fund that has invested in some of the best enterprise AI companies between US and your corridor, like Atomic Work, Spot Draft, CloudSec. Could I have with me Animesh, founder of PlayerZero? Animesh, so excited to have you today.

SPEAKER_01 1:08

Super excited to be here. Thank you for having me.

SPEAKER_00 1:10

Animesh, um, 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.

SPEAKER_01 1:19

Yeah.

SPEAKER_00 1:20

So tell us, you know, the background of Player Zero and then obviously your background.

SPEAKER_01 1:25

Yeah, for sure. Um, so yeah, but player zero, I think, was a long time coming for me. Um, it was something that I'd been thinking about for a while from many different threads in my life that actually came together. Um, the first one actually starts with my dad. Um, so my dad was a founder of a company as well. He's I basically would spend actually just doing support in QA for him. Um, so that was a family business, one of the first software kind of businesses in Atlanta. Um, and so that gave me a lot of kind of empathy for what it took to actually maintain and like operate software. Um, my dad was a CTO and he would be building a lot of stuff. And my way of hanging out with him would just be, you know, like, let me go help you do QA or whatever. Um, you know, many years later, I was at Stanford, and just by virtue of some of the research that we were doing, um, we were working on model compression and inference and stuff like that. Um, you know, we got exposed to language models. Um, so in 2019, 2020 time, uh, 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 uh uh that was called Codex. And this is kind of the the same name has been repurposed now for all the stuff that we know about codex now. Um, but this is actually the model that uh GitHub Copilot started building on top of. And so that was the first time in my life where I saw computers writing code. And there was just like this holy shit moment, right? Like, what happens now? Right? What is like what does the world look like when you know computers are writing more and more of our code? Like, how do we maintain it? How do we operate it? And I couldn't like 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. Uh, started off in research. And, you know, I think one of the open questions that we were thinking about is just like, how do you understand software? Right? How do you model it? Um, because understanding often tends to be the bottleneck uh to being able to, you know, inflect change and to be able to do all the support and production engineering. Um and so that was that was kind of the the initial impetus, right? It was these like two, three threads in my life actually coming together. Um, 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, um, but we knew that we wanted to be a part of it. And we knew that we wanted to be, you know, kind of addressing kind of the uh the second-order effects uh of the change that we were about to see.

SPEAKER_00 3:47

Got and and so uh today AI is writing at least 25% of an enterprise code, but the review, the human review is let's have falling short of it today. So how are folks coping up with it and how does player zero play a role in that?

SPEAKER_01 4:02

Yeah, uh that's actually a great question. And I think actually there's there's a there's this like one uh kind of abstraction above that I think we should talk about first is you know, what is missing um in in in enterprise AI? And um, you know, especially as we kind of think about the second order effects of AI generated code, um, like how do we actually close that gap? Um player zero'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 um, 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's changing in the infrastructure, right? And something's breaking there. And all of these different slices, right, of functions, right, that we that we use to basically operate production software, um, essentially construct independent views of how that production software actually works. And the central thesis behind player zero is basically that the central model doesn't exist, but with AI, that we 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 player zero 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 go run, you know, QA for you, that'll run support engineering, that'll run SRE, um, and do it in a very leveraged way. Right. Um, 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 you know, 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, right, 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, right? And this makes a lot of sense because if you think about the most senior engineers, let's say, right, 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 or the last 10 years, right? We all we all know that guy, right? Like he's been in the company since the beginning and you know, knows everything about everything, has seen every nuance of how the system breaks and the failure modes and state and all of those different things. Essentially, that's the institutional memory that player zero is building. And we can bring that into the QA cycle. And we do a lot of other cool things, and we'll talk about it later, like code simulation and stuff like that. But the real advantage actually tends to come from hey, you change this area in the code, and eight months ago, you know, there was a customer that complained about it. 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 noise piece is extremely difficult to solve. And you know, I think we we we have a pretty compelling answer.

SPEAKER_00 7:11

And now let's talk about the system that you have built that you pointed out. Yeah. How how does uh this context reside in player zero? How do you build that? Like what and obviously what kind of system is it with UI and uh what kind of backend?

SPEAKER_01 7:27

Yeah, that's a how many hours do you have? Like um this is it's not it's not a simple answer. Um, actually, one of the pieces that we wrote um about context graphs uh actually was a byproduct of some of the pieces of the system that we've built. Um, but there's there's a couple of like really important kind of architectural pillars uh to what we built. Um is you know, we think a lot about not only the context, but also the people and the process, right, associated with a lot of the workflows that we're dealing with. For example, when a support ticket comes in, right, 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 you know gate the remediation or gate the escalation path. Um, sometimes it's about actually verifying hypotheses with different people or you know, using tools at your disposal to you know fill in the gaps that observability may not be able to. Right. And so there's all of these different edge cases and based on the contours of any like any piece of software that uh that are important for agents to be able to navigate in order to be really effective. And so when it comes to the UX and things like that, we've created a lot of you know different levers to be able to um, you know, define what is the contour of your workflow, right? 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 way you can tune the degree of autonomy that you really want to adopt. The other piece is, you know, I think from a pure technology standpoint, a lot of actually what we're what we have to consider is what is kind of the decision path for agents to truly own the authority of ticket remediation or incident resolution, right? Or even of QA. Um and this is actually where the kind of the idea of context crafts really came from, which is you know, 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 from 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, you know, a lot of representation learning, a lot of, you know, really interesting agent setups, um, multiplayer agent setups that can actually navigate multiple personas in an organization. Um and yeah, and and a lot more. But these are, I think, like two uh, among many others, of like you know, really important kind of architectural pillars that we've had to think about when we're building a system like player zero that is essentially a counterpart to a lot of these you know coding agents and then uh addressing some of these second order effects.

SPEAKER_00 10:08

So uh I want to dive into a very interesting topic, right? And please explain this as layman as far as you know, because our audience comes from all different uh backgrounds, right? So, how did you write the first paper on context graph? Yeah, and then how did you forward it? You know, that you know, that became the viral piece by Jaya and Ashu from Foundation Capital. Yeah.

SPEAKER_01 10:34

So you know, context graph.

SPEAKER_00 10:38

We can start with what is context graph.

SPEAKER_01 10:39

What is a context graph? That's a that's a good question. Um a context graph is a representation of the decision dynamics um in an organization. Um it often basically draws a line or like kind of it represents a fabric uh that connects people and different systems of record, um, all in a problem-directed way, when you're trying to answer a particular question, right? When you're 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, right? I think Salesforce is a good example, right? Probably the most central system of record, probably the most uh uh popular one right out there. Salesforce is a great system of record, but it represents the output. It 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, right? Why did I price you know this deal at $100,000 instead of $50, right? Why did I discount it? Why did I price higher? All of those things, right? And there's a lot of nuance to this. But a lot of actually what an 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. Right. And the the last year, right, 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, you know, I think a counterpart to um to the traditional systems of record that uh I think can actually be really helpful for agents to compound the institutional knowledge uh that they naturally create and then also you know participate in um as they become productive members of an enterprise.

SPEAKER_00 13:10

So the second part is as soon as you written this piece, how did you share it with Jay and Ashu? Yeah, how did it become vital?

SPEAKER_01 13:18

Yeah, I mean, so the uh to be honest, actually, like the the word context graphs, I have to give credit to Ashu and Jay. Like they they were the ones who actually figured out that uh, you know, this this word um, you know, should be something that is popularized. Uh, but the idea of context graphs is something that actually we've you know been circling for a very long time. Um, this is actually a very central tenant of player zero, right? And and I'm going back to what player zero is, but player zero is an AI production engineering platform. And our central belief is that there is a central model of how production software should work, right? Not should work, actually how it does work. And that model is not represented anywhere, right? The the reality of how production software works lives somewhere in between, you know, your code base, your ticketing system, your telemetry systems, the complaints of your customers, um, the incident response paths, like all of these are it's messy, right? 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, right? Like as 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, you know, was trying to represent the decision dynamics in a way that agents could actually get better the next time that they ran, right? 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 the trajectories and the 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 for Player Zero for a long time. I think uh actually the first time Ashu and Jaya and I met um before they'd even invested in us, um, actually the first conversation actually was about this. Um 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 player zero's ability to understand nuance. Um, the the quality that we bring about how player zero understands the decision dynamics and how we're able to, you know, understand just more than an AI agent usually could. And for a long time, I was struggling with like how to how to articulate this really well. And so over Thanksgiving, I actually ended up writing a long memo. Um, you know, it's just that Thanksgiving tends to be the first day um for like in in that period of time when you know customers are quiet, your your team's quiet, right? So I was like just sitting at home and I was like, let's let's do this. And so I wrote, you know, two, three pages on uh, you know, what does what is player zero and like what succinctly actually makes it different? And uh I shared it with them, and that's basically all we ended up talking about for the next month. Um, and you know, I think that along with everything else that we were learning in market, uh, ended up kind of motivating some of the the context craft species and stuff like that that we published at the end of December.

SPEAKER_00 16:19

So how does context like or the outcome of player zero look to an enterprise? Is it like a UI that you give that shows all the problems in the production? Or like I'm just trying to imagine it.

SPEAKER_01 16:33

Yeah. I mean, context graphs are quiet. Um they're not they're not something that uh the the representation is not necessarily something that is consumable by humans. Um it doesn't have to be, and I think it's actually vertical specific as well. But for us, right, context graphs manifest in the way our agents make decisions, right? Our agents are able to retrieve an understanding of what was the last time I saw a problem that looked similar or felt similar. Right. I think actually a great analogy for this is like how does experience manifest in an employee's work, right? Um somebody's somebody's like uh uh the amount of time that they spend in your company, right, compounds the amount of experience that they have and the amount of context that they have and 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 if you model context graphs really well, agents can actually experience something similar. Um, and that actually ends up becoming a moat, right? And I think that's also really important um for how AI agent companies end up differentiating over time. That ends up becoming a moat because now you have one agent that you know 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 like long horizon um sort of like uh relationships and ways that this thing manifests. So I'll give an example. Um, in order to debug any problem, um, usually we end up generating a whole bunch of hypotheses. And those hypotheses say, you know, if the system is in this particular condition, right, 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, you know, our agents come up with a bunch of different hypotheses, informed by the past, informed by tickets and whatever else that uh whatever other context that they can gather. And they go and run these simulations um to go and uh uh 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, right? What ends up happening in the future, maybe six months, maybe one year, maybe five years in the future. Somebody's gonna go change that area in the code again. And player zero is automatically able to now pull that back and say, hey, you know what? There was an incident, you know, six years ago. And six years ago, this incident was related to this particular area in the code or this particular area of the infrastructure. You seem to be changing something, right, in this particular area now. And I ran that simulation again, and it seems like you're about to break it, right? And there's this like deja vu moment, right, and just completely like blows people's minds. Um, because it's like, oh my God, like I wasn't even there when that happened. Like, how did you know? Right. Um, and and so that this this kind of thing ends up compounding with time. Um, and this actually also is a very expensive part of running enterprise organizations, which is just the institutional knowledge.

SPEAKER_00 19:51

Yeah.

SPEAKER_01 19:52

Right. And that now uh context graphs, I think, are are an opinionated way of actually capturing institutional knowledge in a way that agents can access and and uh benefit from.

SPEAKER_00 20:01

So the way I'm trying to imagine the players you know, how it works in an enterprise is as soon as a developer is writing a code, do you set an ID?

SPEAKER_01 20:10

No, no. So we actually like live asynchronous and in uh in in the cloud. Um and it's it's the reason the reason for that is because we're a complement, right, to uh a lot of these AI coding agents and stuff like that. We're not actually helping you develop new features. I mean, we can help a little bit, but uh that's that's not something that's not the primary uh uh 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 player zero is basically listening to your ticketing system or you're listening to your alert stream or whatever. And every time a problem gets escalated, player zero is the one receiving it, as opposed to a human.

SPEAKER_00 20:49

So so you respond at the time your ticket is getting created.

SPEAKER_01 20:53

Yeah, yeah. So the moment a ticket gets created, we're gonna go kick off like a workflow. And that workflow is gonna say, okay, well, let's go read the ticket and you know, let's go figure out what the root cause of this actually is. And once we find the root cause, let's go find, you know, the two or three people that uh, you know, really need to approve the escalation path. Player zero will decide, hey, this is an engineering system, right? Or this is an engineering problem, or this is not an engineering problem. I should deflect this, right? And it'll go and navigate the uh the organization to actually go and handle that entire ticket. And you know, I think one of the really interesting mindset shifts that that customers have as they start adopting player zero in these in these uh kind of critical workloads and these critical uh workflows. Um the the fundamental shift tends to be that player zero is the one holding the bag as opposed to the human. Right. And the shift actually changes a lot. Um there was this moment actually just a few weeks ago when a customer came to us and they were like, uh, you know, I haven't like played around with a lot of AI tools that have really impressed me, but you know, player zero really did. And I was Trying to figure out why. And the customer basically said, um, player zero is the first time that I actually felt like I was a tool to the agent.

SPEAKER_00 22:09

Um and there's the agent is telling the human what to do.

SPEAKER_01 22:13

The agent is telling the human what to do for this liver of this much longer kind of decision lineage that it needs to do, right? So if a ticket comes in over here, you have to root cause it, you have to go figure out whether to deflect it, then you have to escalate it, then you have to fix it, then you have to test it, and then you have to go follow through and make sure that it actually solves the problem, right? And there's this long thread that actually spans eight or nine different functions, right? 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, you know, three days to resolve instead of two hours. Right. And because of that, right, when player zero like when it shifts in, right, when it when it starts kind of holding the bag for this entire remediation path, the the change basically becomes player zero 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, right? To make sure that I'm not compounding errors in any any sort of bad way. And so it'll actually navigate the organization along with navigating the problem to make sure that the entire follow-through happens, right? And it happens repeatably, it happens in a way that people can predict and happens really fast and it happens more accurately than ever before. Um, and so these are really, really compounding advantages. And then on top of all of this, right, you have a this context graph underneath it, right? You have a, we call it a world model, right? A production world model. Um and every time we actually own the entire decision, we get better, right? And so there's this like compounding element to this as well.

SPEAKER_00 23:47

So when you sell to an enterprise, yeah, are you selling to the ticketing department that, hey, we'll make your tickets resolve faster, better? Who are you selling to?

SPEAKER_01 23:56

So it often tends to be the engineering leader. Um thinking, you know, VP, SVP of engineering.

SPEAKER_00 24:01

But you're following customer, you're not sitting on customer tickets, or you are sitting on customer tickets.

SPEAKER_01 24:04

No, we are sitting on customer tickets. I mean, the the like, think about it this way like um there's two ways to make engineering teams more productive. Um, 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. Right. And so engineering leaders are often kind of thinking about, you know, in this like AI native world, right? Like they're they're investing a lot already in, you know, cloud code and cursor and all these things to like make the velocity of the engineering team faster. Um, but I think there is 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, right? They're they're in the decision path of solving the problems that they're creating. And the SVP of engineering is very familiar with that, right? They're very familiar with that problem. And oftentimes, like the technical escalations and remediations end up rolling into them, right? So this is a problem that they have budget for, that they're actually, you know, actively trying to solve, that they're hiring for. Um, their engineers don't want to be dealing with anyway, right? Because they would much rather be building new software. And so it's it's a it's a very hairy problem. It's a cross-functional problem too. Um, and I think that's partially what you're getting at as well, right? So there are there are support leaders that often get involved in the evaluation. Sometimes there's QA leaders, but you like the the buyer and the the owner of this problem um is very centrally the engineering leader because they understand both sides of the coin.

SPEAKER_00 25:32

Just to make it very clear, yeah. So you go to uh BP engineering or the CTO to for discussion on player zero, and you tell them that hey, all the code that you are writing today with Claude, right? It the issues that it will cause on your customer side. Yeah. Player zero sits between your code and the customer tickets, and then let you know that hey, uh the the this issue on the customer got caused by this code, but but also the code that you are writing now, it'll cause that issue in the future, exactly, which is not yet there. Exactly.

SPEAKER_01 26:06

Exactly. Yeah.

SPEAKER_00 26:07

So it's just cross quite cross-functional rather than just exactly.

SPEAKER_01 26:10

Yeah. So, you know, I actually I genuinely think that um as we start centralizing this context, all of these different functions that we were talking about earlier, right? Starting from SRE on like the most reactive, you know, 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 I think the the intuitive reason why is because they all operate on the same context, right, in order to be effective. And so if production engineering is kind of what you're trying to automate, right, or trying to run, and this is kind of where that self-healing aspect comes from that you were talking about earlier. Um if that's really what you're trying to operate, it is a natural complement, right, to the way we think about a genetic development. Yeah.

SPEAKER_00 27:01

And you have mentioned earlier that, you know, uh software needs to be treated like biology.

unknown 27:08

Yeah.

SPEAKER_00 27:08

It's not no longer a machine but an organism.

SPEAKER_01 27:13

I'm curious on your thoughts too. But uh if we think about like the the growth of software being something that is purely mechanistic, um, we just won't be able to keep up with it anymore. I think this this idea of an immune system uh often comes to mind for me. Right. Like, what does our immune system do? Right? 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 like as the pace of it becomes something that that we start loosening our grip on, right? As cloud code comes in, as cursor comes in, like we're all feeling this already at all of our companies. Just the pace of development is, you know, 5x, 10x. Um, and you know, I think the enterprises are not, I mean, they're a little bit behind, but they're not that far behind, right? I think everyone's feeling these fractures. There's this asymmetric sort of 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. And so I think a great analogy for this is like you can only build, um, you can only build faster cars when you build airbags, right, or seatbelts. I think there's a version of that that basically needs to happen here too. Right. If we keep thinking about, you know, 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 like engineering team, right? The net new development that's happening and reality and constantly reinforcing itself uh to get better and better over time.

SPEAKER_00 28:57

What is the delta that you pitch? Like obviously better code, so faster resolution of tickets. Yeah. But do you pitch cost savings to the enterprise? What do you pitch?

SPEAKER_01 29:06

Yeah, so I think the first order ones tend to be you know 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 you know, fewer bugs actually going out to production to begin with. I think between all of that, there is uh some degree of cost arbitrage um where you know maintaining and operating production can be done faster, cheaper, better. Um so I think I think that there's there's a version of that. But I think generally, at least as of today, I don't I don't know if I've met an enterprise SRE team or an enterprise support team that says, oh yeah, actually we're well sapped. Right? Like they're just everybody's underwater. Um, and they're becoming more and more underwater because like the again, the pace of development, the pace of change in software is much, much faster than anybody can truly internalize and understand. And by the way, this actually goes back to the kind of biology piece of this, right? Like um for like machines, like we understand everything about how it works, but in biology, like we don't, but it still just works, right? And it's because we've we have these systems and and uh uh and processes in place that can adapt and learn and evolve over time. Um our pitch to enterprises tends to be, yeah, we'll help you on these metrics, um, but at the same time, we'll actually establish a new way of working, right? A new way of uh uh operating and maintaining software in production uh that allows you to create leverage uh for all of the different people that are participating in it. Right.

SPEAKER_00 30:40

It sounds like a good idea, but I'm not able to get how real this is. Like software is like there's an immune system for your software. Yeah. And like software is healing itself. Yeah.

SPEAKER_01 30:52

Yeah, yeah.

SPEAKER_00 30:53

So how like practically how is it possible?

SPEAKER_01 30:57

Well, practically the way it's possible is, you know, let's let's think about the full loop, right? We talked about a bunch of different workflows. Let's think about the whole loop. Um, on one side, right, anytime that there's a that there's a bug, a customer is reporting a ticket, there's an incident, there's an alert, some there's a system that is now dealing with every single one of them. And it's automatically finding root causes, it's automatically remediating, it's almost automatically creating code changes, you know, approving them, and then ultimately getting them back into production. And so there's a self-healing loop there. Now, at the same time, right, what is the other thing our immune system does, right? It learns, right? I got the flu, you know, a few months ago. Um, I'm not gonna get the same flu again, right? And so there's a learning aspect to this too, which is every single support ticket that's being dealt with becomes an antibody. Right. And each of those antibodies now actually go back into the SDLC. And anytime there's a code change that's made, player zero 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, right? These are these are the support problems from the past, these are the incidents from the past that I think are very much related to it. And I'm gonna go simulate all of those different conditions and then tell you before even this thing has even gone into production whether you're going to break those things again. Right. And so there's this like self-reinforcing piece of this, which is again why that immune system analogy often comes back. But very practically, right? It's like fix problems faster, prevent problems, right? And the way we do that, it tends to be through these workflows, it tends to be through the um, you know, the code simulations and all these other things that we've been talking about. But yeah, that's that's what self-healing really means, right? And and and we're not yet at a place where you know you can turn off the lights and just have player zero go nuts. Um, to be honest, I don't think any AI is there yet. Um, but it's pretty damn close. And it's it's it's really exciting um in a world, especially like we see this, we we use our own product every day. Um I mean it's it's kind of at the place now where support tickets are dealt with in half an hour, right? That's that's something else. Yeah, right.

SPEAKER_00 33:03

Like we haven't really uh support tickets are getting dissolved in half an hour.

SPEAKER_01 33:05

Yeah, it's crazy. And like with without human intervention, yeah, right? It's uh without human intervention? Yeah, like I mean, like very minimal, right? It's like there's an approve button that somebody clicks right along the way.

SPEAKER_00 33:15

And the code changes?

SPEAKER_01 33:15

Yeah, the code changes, yeah. Player zero will make the code change. It'll say And it'll make the changes of production. Well, I mean, it won't deploy it without like express consent. Um, and you know, there's there's like one or two moments of like human human intervention, but like it's pretty damn autonomous, right? Like we're not context switching, right, from the stuff that we're doing. Uh player zero is the thing owning the entire remediation.

SPEAKER_00 33:36

Amazing. So bug, so some of the players are also trying to build this like bug bought by cursor. And so where do you think that player zero fits in when the coding system starts building the self-healing?

SPEAKER_01 33:52

Yeah, so I think the yeah, the answer often comes down to context, right? We were talking about context scraps earlier. Um, the the efficacy of these agents are highly tied to the context that they're operating on top of. The kind of central thesis of player zero is that there is no central model of production today, and that player zero is going to go build that, and then it's gonna own it. So the types of problems that we find are very different. So, for example, bug bot tends to be um, you know, hey, you forgot this question mark here, and that's a null check. And if you run the code, you're getting a null pointer exception. The types of player problems player zero is solving, again, because of the context that it has, tends to be, you know, Animish was uh uploading uh uploading an invoice uh six months ago, and that particular condition is going to break again, and then Animish won't be able to upload his invoice anymore.

unknown 34:44

Right.

SPEAKER_01 34:44

And so these are like they're very two very different things. Um arguably it's like the difference between code review and QA. Um, you know, one is stylistic and you know, the the feel of the code, the other is uh uh based on reality, right? Based on reality, based on use cases and customers. Um and then beyond that, obviously, I think there's the remediation, SRE, like all of those things where you know today I don't think the coding agents are actually optimized well for that at all. Yeah.

SPEAKER_00 35:16

And uh one question is then how did you choose your seed and cities they invest as because did they understand the depth of what you're building?

SPEAKER_01 35:25

I think generally, yes, but I I I think it's like uh player zero has been around for a few years. Um it started as a research project um broadly and just trying to model and understand large code bases. Um if I were telling you we started in what 2021, 2022 time. Um if I were to sit here and tell you that I knew exactly what player zero was gonna be today uh in 2021, I'd be lying to you. Um ChatGPT wasn't even out. And I think we kind of knew down the barrel of the gun, like you know, something like this was gonna come out and AI was gonna be less of a toy and more of a you know something that people would take seriously and want to deploy into production. Um, but I didn't even know right what it was gonna be. Um, and so you know, if I didn't even know, how would our investors know? Um, I think what our investors have actually been really helpful with is, you know, pushing at the right time and being patient at the right time. I think that's a that's a calibration that I've like um really learned to appreciate. I think the other piece is um learning the process of building great companies that are durable. Um, I watched this with my dad too, right? It took four years to actually go find you know the right, the right business. Um and again, it goes back to sometimes being patient and and other times being extremely aggressive. Um I think that's that's something that we've you know learned from our investors. Um and we've also chosen investors that I think understand the calibration really well. Yeah.

SPEAKER_00 36:59

What's next for player zero in 2026?

SPEAKER_01 37:06

I mean the time's now, right? Like the time is now. I think the um 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, right? They're not additive to individuals. They are um they're the ones that own the work, and then we are additive to its work. Um, and with that, I think a lot of these second-order effects of the pace of software development um need to be dealt with. And I think it's a very um understood problem among engineering leaders across the Fortune 500s, across um actually really everybody, right? Like just any, any, any, anybody who's running a uh a software team, right, that that's supporting customers. Like I think I think everyone's really kind of universally feeling this problem, and we're all starting to feel it at a similar time. Um, and so what that means is, you know, the time is now, right? It's uh it's it's like player zero has been growing a ton, um, essentially doubling uh every quarter over the last couple of years.

SPEAKER_00 38:03

Okay, so you have been doubling every quarter, like in terms of number of customer count or what?

SPEAKER_01 38:07

I'm almost almost almost on every dimension, um, which has been incredible.

SPEAKER_00 38:11

In a year, which means that you are almost grown 16 times.

SPEAKER_01 38:18

I mean, like there's like in in terms of people for sure.

SPEAKER_00 38:21

Um how big is the team now?

SPEAKER_01 38:22

Almost like 32, 33 now.

SPEAKER_00 38:24

All in SF?

SPEAKER_01 38:26

Uh it's split between Atlanta and San Francisco. With the CTO and so uh our CRO and CTO are in Atlanta, our AI team is here in SF. I'm here in SF. Um, I end up going back to Atlanta often, so we're we're like we end up seeing each other every couple weeks anyway. Um, but yeah, it's it's uh I would say at least like two-thirds of it, almost three-quarters of it is in is in person. Um we have like a few folks you know who are remote. Yeah.

SPEAKER_00 38:53

But thank you so much, Aimesh. Loved learning about Player Zero from you.

SPEAKER_01 38:56

Yeah, thank you so much for having me.

SPEAKER_00 38:58

I'll take away, you know, self-healing code has become real.

SPEAKER_01 39:01

Yeah. It's it's becoming more real every single day.

SPEAKER_00 39:04

We have got a real immune system into our code.

SPEAKER_01 39:07

Yeah. Yeah, yeah. Awesome. Awesome. I will I will absolutely do it. Thank you so much for having me.