From DevOps ‘Heart Attacks’ to AI-Powered Diagnostics With Traversal’s AI Agents

If you're in product, if you're in design, if you're in core engineering, you constantly have to make bets as to where AI is going to be six months from now and be willing to reevaluate everything six months from now. The good news is that it's only going to get better, so it's not like your product's going to get worse six months from now. Right. And so, for example, one really interesting thing bet that has paid off is Raj and Raj were very prescient about the fact that reasoning models need to get better. Right. They'd made this bet in September. Right. Just seeing where the world was going. And we architected our system such that the reasoning models would get to shine. And that has really played our dividends right now in the way our entire architecture is set up.

Today we're excited to welcome Anish and Raj, co founders of Traversal. Traversal is building AI agents to transform the world of DevOps and site reliability engineering. Today, companies have war rooms and armies of DevOps and SREs, troubleshooting their production failures and fixing them in the code base. Every minute of production downtime is costly and sometimes life or death. Keeping a company's application running is very hard and valuable work. And it's a problem that is only getting worse with the advent of AI generated code and vibe coding. Traversal believes that agents are the scalable solution to the problem and has seen exciting results already from the troubleshooter agents that they've deployed into production. We're excited to have them share more about that vision and the results so far.

Anish and Raj, welcome to Training Data. So wonderful to have you today. We have been working together for a year and we can't wait to share with our audience how AI and AI agents can transform the world of software, site reliability engineering and DevOps. And somehow we need to weave Negronis in the conversation someplace later on. But we'll get to that. Let's start with some quick hot takes. Will DevOps or SRE as we know them today even exist five years from now?

Yeah, it's a great question. I think it will, but I think it'll look fundamentally different from the way it looks now. And I think in this world of DevOps and SRE, I think healthcare analogies generally fall quite naturally, I find. And in this world, if you think about healthcare and the maslow hierarchy of needs there, imagine the stage one is where, let's say you're having a heart attack. You have to solve that right now. Nothing else matters. Nothing matters five minutes from now other than solving the heart attack that you're having. And to me that's analogous to dealing with a high severity incident. And then stage two is where let's say you're dealing with some sort of chronic issue that you face. You have sprained ankle or whatever illness that might be affecting you and it's very hard to plan three months in advance because that's something that's just affecting you every day. And I think that's the analogous thing you do in DevOps is dealing with streams of alerts, streams of checking whether a deployment was safe or not safe. Right. And then stage three is where I think of it as like life hacking, where you're thinking about how do I optimize my sleep and my nutrients so that I have a high quality life and fulfilling life. Right. And I think that's the equivalent of like planning out what your next five years of infrastructure look like and how you'd invest in the right places. Now if I think of what unfortunately people in the DevOps SRE or on call engineering space live like right now, it's like having a heart attack twice a week and dealing with a debilitating chronic condition that you have to handle every day.

As I'm listening to you, I'm just trying to picture all the people who I know in DevOps and SRE in scrubs or wearing CGI monitors to life hack, like you know, their infrastructure.

And I think people don't realize it, but when you make this connection to healthcare, you realize how what we've gotten used to and what life really should be like in this world as we think about the healthcare of large scale software systems. And so I think if Traversal does its job right, then that first stage and second stage of needs, which is there's really high severity incidents and that constant pain by death by a thousand cuts should be something that AI and AI agents take care of. And DevOps necessarily get to deal with the creative fun parts of what is it my infrastructure should look like for the next year, for the next five years. And it becomes a much more fulfilling job.

And many engineering teams are nowadays adopting autonomous coding, things like cursor windsurf. Do you think that's going to have profound impact on how people maintain the reliability of their infrastructure? Or will it be the case that AI will have a major role to play in fulfilling that vision, moving people away from being the intensive care unit surgeons to being more thoughtful planners?

So I think it's going to be the. There's a short term answer and there's a long term answer. And I think it becomes, in the short term at least, it's a tale of two worlds, I think. So there's this because of everything happening in the world of Cursor and Windsurf and so on and so forth. I think the idea of vibe coding obviously has become very popular, right? And we can write a prompt or a few prompts and have something stood up that people can use and play with. But I think the analogy here is of fast fashion where you try something on, you like it, you don't like it, you discard it, wear the next thing. And I think in that world actually reliability doesn't really matter because you don't really need to take care of what you've created. There's no craft to it, you create it, you throw it away. But there's another world which is where you start applying these AI powered software engineering techniques to mission critical systems in payments, in financial institutions, in security infrastructure, streaming. And in that world, I think it's going to lead to a major issue. It probably already is. And it's only going to get worse in my opinion, because everyone we've seen this with, the enterprises we work with, everyone is using AI powered software engineering tools to guide them as they write code. And what you actually find is that it actually even passes their local unit test. So in that local piece of code, everything looks perfect. Right. The problem is that in large scale enterprises, things break when different pieces of your system interact in a way you just didn't realize or you couldn't foresee. And when that happens, because all of this code is being written by an AI system, it's very hard to debug it because you just don't have the context anymore. You didn't write it anymore. And I think in that world, unless we find ways of using AI systems to do software maintenance, we're going to be throttled. And either people will disallow AI software engineering tools to be used because there's too much downtime or something of that form. I think in that world we're going to need new tools and new software to help maintenance of such systems. I think that's where traversal can play a part.

You definitely have your way with words and analogies. So I love the tale of two worlds. You either have Louis Vuitton high fashion or you have fast fashion with sheen or something like that. But I think we jumped into the deep end maybe a bit too quickly. Let's go back a few Steps and maybe explain for our audience, like what actually root cause analysis stand for. Like what, what does it do? Tell us a bit more about this wonderful world of troubleshooting and root cause analysis.

Yeah. So I think if I just think about the tale of the life cycle of an incident, right? The story of an incident, it always surprising looks the same across companies. A customer will log on to a platform, things are not working exactly right. Either it's already been recorded or they make a complaint to customer support. Customer support looks at it and says, okay, it's not a user error, it's an actual issue. It escalates in this game of telephone up like five ladders of different sophistication of engineering organizations within an enterprise. At some point it hits the DevOps SRE team who look at the issue and decide is this worthy of an incident? Based on the impact of it, based on the severity of it, the immediacy of it. And if they decide it is worthy of an incident, then suddenly chaos ensues, right? You'll have a slack incident channel that's created. There's 30 to 50 people in a channel. Everyone's kind of implicitly blaming each other for what happened and a bit of a whodunit type thing. And almost without fail it's the same thing that happens, which is there'll be this 10x engineer who's been at the company for who's the Agatha Christie or the Sherlock Holmes of the situation. And like, aha, like they'll fig out exactly what happened, right? And not clear how they got there, but they get there. You roll back the, you come up with some sort of hot fix and then everyone kind of, it looks for a longer term fix over time. Right? And that's typically how it all plays out. And that whole flow is what we call the life cycle of an incident and root cause analysis in particular. Right. And I think what I find incredible is that all of observability, these incredible companies have been created. They're the second largest software spend typically companies have after your cloud spend. And yet we still have this state of root cause analysis. But anyways, that's my take on what RCA looks like nowadays.

And tell us maybe a bit more color on where does root cause analysis live with relations to the plethora of observability tools that companies use today? Why is it that if it's still the case, if this is the number two spend in technology, why is it that you have 50 people in a slack channel with a whodunit kind of.

Plot it speaks to the importance of the problem. Right. And what observability has done is the best they could have done given the technology that was available to even like six months ago. Right. Which is. So if I think what observability is, it's fundamentally about the creation of telemetry data. It's called melt data. So like metrics and events and logs and traces, so melt for short. And it's about the creation of this data, storing it, and then providing a nice visualization layer on top of it so people can create the right slices to create little eyeballs in different parts of their system. Right. And I think that's what observability ends at, which is a storage and visualization layer, because that's all that could have been done. Right. And the complex workflow of troubleshooting remains supermanual and that just because that was what. That's all we could have done so far. And I think the promise of what these AI agent companies can do is that they automate complex workflows that we do on top of software. And to me, this problem of troubleshooting root cause analysis is one of the most complex workflows that any study humans do in software. And I think now there's an opportunity to kind of move up in terms of sophistication where we use AI systems to actually automate this workflow versus just stopping at the storage and visualization layer.

Can you talk about your product? What is the agent or the agents that you're building to take on this problem and how does it work?

Yeah, double agents.

So maybe stepping back, what is an agent? And it's really an LLM orchestration of tools. And in our world those tools might be data fetching tools, how to get logs, how to get metrics back, data processing, how to format it in a way that the agent can really process, or statistical tools like running anomaly detection. And I think really what we're trying to look for here is you need to define the tools rich enough so that an RCA can be expressed as some combination or some sequence of these tool calls. And that's really where a lot of the complexities and the multi agents come in, is how do you piece together these tools to solve these complex tasks? And I think at least in our world, the data is so big that it needs to be sequential because a single trace might not even fit in LLM context. So you need to know how to slowly just build this context of the LLM to get to the root cause. And that's why it's really challenging of a problem.

Are you mirroring the cognitive architecture of a human troubleshooter? Is it, you know, is a map of operations very similar to what a human would be doing or is it very different for an agent?

Yeah, I think that's where at least when we were first thinking of the problem, we tried to mimic how an SRE would debug. And it was very manual, very sequential, where an SRE typically might look at a piece of evidence and then, okay, figure out what's the next piece of evidence to look. But a lot of times they make these hops with system knowledge which the agent might not know. And that's really where we used a lot more scale to figure out how to bypass some of this issue of system knowledge. So this agent will basically look in a more systematic fashion of there's this Google SRE handbook which tells you here's the key golden signals you should be looking at latency error rate. So it looks at this way of kind of health monitoring to piece together how to sequentially search this rich space. And it's less about having holes in the reasoning where a human can just immediately get maybe to that hop. The agent is making these sequential flows that get to the answer.

Are there particular conditions or environments where this agentic approach works better or worse?

Yeah, I think fundamentally it's about data access. So what we have found, and surprisingly that's what we've found, is that we sometimes can add less value in like a series, a startup versus a large enterprise. Because when you become a large enterprise your observability is quite mature. So everything is being instrumented in a way where the fundamental data is in place. But your teams are very fragmented. So no one team or no one person has enough context to piece together whatever, everything about how to debug. And that's why you have these 30 or 50 people in a slack incident room. And so what we fundamentally found is that the place where we add the most value is when the reasoning steps for this agent to go from a high level trigger to the root cause. Those steps can be found in the data. Right. It just is too much data for any one human to keep in their head. When that data is fundamentally not there, then it's when the agent suffers. And that tends to not be the case at the enterprise is what we've found.

Very interesting and really somewhat counterintuitive because it's usually the case with startups that the way you choose your design partners or customers, you start at smaller companies or mid market and Then you try to graduate your way up to enterprise. And if we're going to use the L1 to L5 analogy from self driving cars, how close are you with having agents correctly get to the root cause of incidents or maybe more broadly, what counts as success? Are we trying to get to 100% correct resolution or what even counts as correct resolution in this context?

Yeah, that's a great question. I think there's really two cases here. There's the first case where the root cause fundamentally belongs in the data. So it's in some log, it's in some pr. And in that case I would say with traversal we're at L4 and I won't say L5 because for us we might be able to flag that problematic PR or that smoking gun log. But then there's still that last mile of the fix and the remediation. And in cases where the fix is not so localized to a specific file or code change, where you need to do basically a bigger system wide change, that's we haven't gotten there. But I think that's where it's really exciting to see all the developments with code agents because that's where we can get to that L5. I think for places where the root cause isn't in the data, that's where we're more at a L2. I think traversal finds a lot of the important symptoms that really help people debug, but sometimes it's just not in that data. And this human kind of needs to make those additional hops to get to the actual root cause. But still the symptoms really help figure out how to make those additional hops. And sometimes right for us, when we notice that we can tell customers, well, maybe you should instrument in this way to make the system more observable across the AI landscape.

Right now there's really interesting kind of AI native companies being formed like yourselves. There's also the incumbents that are, you know, in many cases not asleep at the, at the wheel. How do you think about the incumbent risk here and, and why your customers are choosing to go with you?

Yeah, I think it's a great question. I think the heart of it is observability is expensive. Right? It's such an expensive product that people pay for as a result. It's extremely fragmented. Right. You go to any big enterprise, they're using Datadog, they're using Splunk, they're using Dynatrace, they're using Elastic, they're using Grafana, they're using ServiceNow, I mean they're using everything and all of them are encroaching in this game of attrition. And the problem is that if you just think about the pricing models in this world, it's all based on the amount of data they store. And so as a result, company A is not incentivized to give you better insights from anything that's stored in company B. Right. And to debug something, if you just look at any of the SRE or on call engineers, they're calling upon all five, six tools they have access to. And is that fragmentation of this historical industry, I think, which is going to ideally lead to companies such as ourselves that are somewhat agnostic to where the data is stored, at least for now, it gives us a chance.

Do you have customers deployed on traversal today? And what have you found is the difference between what you kind of expected, even coming from an academic background, versus what you're actually finding in real world environments?

Yeah, it's been quite a journey. I think when we started, as one should typically do, we started with very small companies and built something that worked for them. And that typically took the form of we went through the last hundred incidents that they had in the slack channels and kind of try to use our brains to figure out what is the meta workflow of how they always debug an incident in that particular company. And in that situation, a very popular framework for agents is something called the React framework. And that as a general idea work, we could somehow imbue the meta workflow into a react agent system and it was able to do a really good job. And then at some point we started working towards larger companies that had an actual large scale observability system, thousands of microservices, that kind of situation. And I think I remember there's very clearly this one week where it was the first time we dealt with that kind of scale. And the second we tried to apply our system on just some historical incident that happened. Our accuracy was at 0% and we just, it would not move. Whatever we did to the prompts, whatever we did to anything, it was stubbornly at 0%. And that was a rude awakening. I remember Raj and I had a.

Negro.

And I think at that point we kind of had to think through ways of. We made some interesting decisions which played out in our favor, which is we said, okay, nothing about a specific company will be hard coded into the prompts and nothing about a workflow that humans do there will be hard coded into the agentic workflow. And that complexity has to go somewhere. And eventually where it went to is computation, which in our world takes the form of spending tokens in the problem, like using it at inference time. And once we were able to kind of find an architecture that exploited inference time compute, which is something now everyone is finding to be important, accuracy starts shooting up. And what we found then is for if the fundamental answer lies in the data, we get to the answer more than 90% of the time and we get in within two to four minutes. Right. And which is amazing because now you just look at these slack channels. Humans are spending most of the time just verifying the answer to what we find versus actually root causing it. And just the month to month timed resolution has dropped, I'd say, as is the number of people on average in the slack channel, which are the two things that I think any enterprise cares about.

And how do you measure accuracy in this context? For example, there are a lot of companies that focus on LLME valves. Does such a thing exist in the world of SRE and root cause analysis? Or how do you know that you're correctly identifying a root cause?

The gold standard is honestly trying it on live incidents. I think when you onboard to a customer, oftentimes incidents can happen like two to three times a week. And in those scenarios you get the best feedback. Maybe it takes a couple of hours for that incident to complete. You look at the postmortem and you can really evaluate it. So I think that's one definitive source. There's other subtasks we do for evaluation, such as when people are trying to search for specific information from their observability. There's smaller chunks of tasks you need to do to do rca. So we evaluate on those tasks as well, which are just higher volume. But ultimately real live incidents are the best way for us to evaluate.

Awesome.

It sounds like, you know, you had this rude awakening at some point where you deployed the product and it was stuck at 0% accuracy before you kind of went back to the drawing board and really rethought the entire architecture. So maybe can you give us a very quick tour under the covers of how the product works today and kind of what is the magic that enables precise root cause analysis?

Well, one important decision we made was we only require read only access to the data. And I think that was a decision basically based on enterprises not wanting to just have yet another tool generate more data. So how do we actually do it? Well, I think there's two phases. There's an offline phase and an online phase. So during this Offline phase, we're really trying to learn this rich dependency map. How do different functions, how do different logs relate to each other? And one way to do that is through LLMs. So LLMs go traverse, really understand semantically how these logs, different tags within the logs all relate to each other. And then we also use statistics and statistics comes in when, for example, there's natural variation in time series and that turns out to leave traces of causality, which basically Anish and I worked on in grad school of how do you pull causal relationships out of this data? And that's really key to build this rich map. We also use self play to basically prioritize certain paths that are very promising for rca. So now once we've constructed this rich dependency map during the online phase, when an actual incident comes to us, what this agent is doing is it's using that real time information and this dependency map to basically figure out what hops to make to do the root cause analysis.

How long does it take for the offline part to become effective? Such that in other words, between deploying your solution and the first incident that you can actually troubleshoot, how long is that gestation period?

It kind of depends on if they want to troubleshoot a live incident or a historical incident. In general, I would say we take about five to 10 hours to kind of look through all of their code base, look through their observability, really have that system understanding. For larger customers it can take a day, but generally five to 10 hours.

So you've mentioned reasoning and inference time, compute a couple times in there. Are you using kind of foundation models and fine tuning them for your purposes? Are you building a lot of that kind of architecture yourself? Maybe just talk a little bit about the architectural decisions you've made.

Yeah. One really interesting thing we have learned is that if you work with enterprises, they typically have a existing relationship with a LLM provider. So they might have an enterprise contract with OpenAI or Anthropic. And if you try to bring your own model or your own fine tuned model to them, you're going to be stuck in security hell for about a year. And so you have to kind of tie your hands where you say you have to be able to use whichever model they give you. Typically OpenAI is a pretty safe bet, Anthropic as well. So then most of the complexity is really about how do you get the right set of tools that this LLM has access to to orchestrate the RCA step itself. And the other thing you can do is fine tune within a company's environment. So let's say they point to their Azure OpenAI instance. Then you can fine tune that by every time an incident happens, you see how far you got, you saw whatever the pinned root cause was, you can see how far away you are. And then the system can fine tune on making sure that gaps get smaller and smaller over time. So that's generally how we've seen it's played out.

And you also mentioned that you guys had part of the architecture here is based on years of your academic research. Can you share a bit more about kind of this interplay between your PhD dissertations and translating that now into a company?

Yeah, actually. So one thing that's kind of interesting is at least during grad school I worked closely with the Broad Institute to basically understand what these CRISPR interventions, you have these gene regulatory networks, you do a CRISPR intervention and you're trying to understand what is the effect of this drug or this knockout experiment on how these genes express. And the techniques we developed there for learning that causal structure between genes turns out to be pretty related to this problem we're facing with production systems where if you think of the nodes of swapping them with genes as microservices and then you're learning, okay, what happens when I make a PR change or I break this part of the system? How does that percolate? It becomes almost the identical problem. And I think that was honestly by sheer luck, we didn't know that was going to be the case. And only until we got into the weeds of the problem did we realize like, oh wow, we got really lucky that our grad school research played out well here.

What have been some utter surprises on this journey over the past year, year and a half?

Well, for one, I think which is part of why it's been such a joyous thing for us is just how it's like the industrial age of AI. And so I think all of the most interesting innovation I feel is happening at small research focused startups, such as the ones that we are part of or have the privilege to be a part of. And so I think just having seen the best of research in some of the best universities, and now actually seeing how it gets played out in a company, it just feels like this is where all the magical special work is happening. And I think that was surprising to me. Coming from a world of academia, becoming a professor, I thought that's where all the innovation will be. And so that's been quite surprising, honestly. I think the other thing that's been quite Surprising is just how hungry enterprises are for using generative AI to solve real problems. And you can show that the pace at which you can move with them, what typically would take a year or two years to close, can be rapidly done in a couple of months. And so I think the hunger of the market and also the pace of innovation in the industry has been, I think, quite surprising.

Speaking of the pace of innovation, things are moving like, you know, so quickly and you have been working on this product for slightly more than a year now. Have you been in situations where you have to go back and rework something? Oh, because now there's MCP or something new on the market that previously you had to engineer yourself, but now it's readily available, like off the shelf, so to speak, or, or in some ways. How do you future proof your architecture and what you're working on?

Honestly, I think that is going to be a constant challenge for companies of this generation. If you're in product, if you're in design, if you're in core engineering, you constantly have to make bets as to where AI is going to be six months from now and be willing to reevaluate everything six months from now. The good news is that it's only going to get better, so it's not like your product's going to get worse six months from now. And so, for example, one really interesting thing bet that has paid off is Raj and Raz were very prescient about the fact that reasoning model is going to get better. They'd made this bet in September just seeing where the world is going. And we architected our system such that the reasoning models would get to shine. And that has really played our dividends right now in the way our entire architecture is set up. And so I think you have to keep making these kinds of six month bets about where AI is going to be and surf it just right. And I think the companies are able to string together a few of these bets just right. Other ones are going to win. I think that's why, in my opinion, if you ask me, would you rather be an AI team taking this problem or an observability team? I'm biased, but I'd say I'd rather be an AI team because you just have to, you get more fluent in making these kinds of bets about where things are going.

What is your team composition, how many are researchers, how many come from the domain? I'm curious what the shape of a AI native agent company will look like more broadly.

Yeah, I mean right now I would say we're 90% engineers. I mean, a lot of people, there's a few of us with PhDs who have done PhDs in machine learning. A large fraction come from traditional software engineering backgrounds who have been very interested in genai and have used it in their own life. But I think for some of these things at least, the barrier is lower and you can kind of get. Everyone's trying to learn how to make an agent. And I think it's not like the old days where you might have needed a PhD to write out these gradient updates on this crazy LLM. I think it's a lot more democratized and that reflects in the way we've made the team composition. We also have people working with infrastructure. So how do we scale these agents? And I think that's a really interesting problem of, to Anisha's point of inference, time compute is how do you really get this AI agent to just do a lot more work than a human can possibly do. And that involves, for us, we make thousands of network calls per investigation. So that's reflected in hiring the best infrastructure engineers. And then I think the other part is we have product managers, and some of those folks are coming in the next month. So we're really excited just to bring all of these different peoples with different backgrounds together to solve this hard problem.

Yeah, I think one thing that unifies everyone in the company is an excitement for generative AI. And I think because of that, they're willing to learn and adapt and throw away things that didn't work versus kind of being stuck in your way, because I think those are the people that are not. That's the type of culture that is not going to survive in this world because it's just moving too quickly. And if I think about what it's interesting, I think about an AI researcher versus an AI engineer versus an engineer, like, how do I organize that? I think it has nothing to do with whether you have a PhD or any sort of credential. It's about how experimental are you in the way you think, how willing are you to make little bets and hypotheses about how things can be and then quickly, you know, put that to the test. Right. I think that mentality of quick iteration with AI and data is, I think, what makes someone a good AI researcher and AI engineer. And so it's more a mindset than a credential.

Speaking of the composition of your team, I find it very interesting that neither one of the two of you or your two other co founders are actually observability industry insiders and your entire company is very heavy on AI and engineering prowess and honestly quite short on observability domain knowledge. And yet you are making waves in this domain and successfully resolving these very complex issues that otherwise take little armies of people scurrying around and dumpster diving to go figure out. What is the smoking gun log? It almost begs the question of what do you think the a future observability or SRE team at one of your customers might look like today? You mentioned that there are people who have all the insider knowledge, like all the tribal knowledge, the intuition. They can make these hoops from here to there without data. Is that still a valuable skill set like five, ten years from now? Or would the observability team look very, very different?

A couple of answers. One is I think there will be a lot of work to be done about the reliability of AI systems themselves. And I think the way you reason about reliability of AI systems will require obviously first principle, good SRE principles, but also some sort of fluency with AI as well, because they'll break in interesting, unique ways that we're just not used to. And so I think modern SRE teams will have to kind of be fluent in both in some ways, which is how do LLMs and AI systems break and also how regular systems break. And marrying those two things will, what I think will make you a really good DevOps and SRE engineer. And also even simple things. Like I think one very interesting thing that's going to happen is that the data layer of observability is going to fundamentally change as well. Like the way a log looks like is going to look fundamentally different. And a part of being a good SRE or DevOps person is knowing how to write a good log so that over time when incident happens, you have the right instrumentation. There's an art to instrumenting your system the right way, where you're not flooding it with too many logs, but just the right amount. Right. And I think the way we will write logs will look fundamentally different as well because it's no longer meant to be scrolled by a human, but meant to be consumed by an AI system.

That's a very interesting point. Like how do you rate cursor today on their ability to write good logs?

I think it does a pretty good job, but I mean I think it's.

Better than a human.

I think the way it can format like humans just make typos and they don't. I mean I make. I'm really bad at spelling. Like I Think Cursor does a great job there, but I think a lot of it is still mimicking how traditional logging looks. And I think to Anisha's point, you need less of that. And you really, for example, want to bury as much information in the message field because that's the meat of what is going on. And now when the LLM sees that, it can kind of have a better understanding of how to make those hops. But a lot of times people don't like to add so much content because a human can't read such a long error stack trace in a log.

We have shorter context windows than these LLMs, I think.

Also then connecting with the business logic, right. A lot of times, because typically it may not be your engineering system is fine, but it depends on what fine even means for an engineering system. It has to connect to some sort of business logic for it to be healthy or unhealthy. And I think logging in a way that connects these two things in the right way is an art still. And I think that will be tough for Cursor or any other AI system to do unless they have full understanding of your business logic, which might happen, I don't know.

As you dream about the future of the software engineering market and the role that observability and Traversal will play in that future, you started this podcast episode talking about people aren't Vibes coding a payment system or banking system today? Do you think that if everything that traversal is building goes right, if observability changes in the way you think it might, that engineers at the largest banks and payments companies and healthcare institutions will be actually Vibes coding their software programs.

To some extent, yes. And I think what we'll have is just a much better sense of like, did it fulfill some function? And that will typically take the form of unit test in some form, Right. And just much better testing. And so as long as it fulfills some test, that code is fine and who cares what was written in that code? I think that will somehow, in my opinion, is how software engineering is going to evolve, which will be much more about did it fulfill some function versus the way it was written, which will be good, but as we talked about earlier, I think also bad. Because when systems fail, it's because they interact in ways you didn't expect. Right. A lot of times you are failing because a third party that you call upon is not hitting the sla, right? And that's just going to happen a lot more, I think, and it's going to be a lot harder to debug because you don't actually know what was the content of a particular code file. And so I think that that's the problem that we're going to face. And that's why I think products like Traversal will have a big part to play is in solving those kinds of issues, which is a lot more subtle.

Because I think that's where humans shine. Right is right now humans mostly write all of their code so they have that rich system knowledge. So when they see an incident they can short circuit a lot of paths because they already kind of have seen something in the past or they kind of already understand this error message they wrote. But if an AI generated that, they don't have that structural advantage. And then you really need to AI.

Troubleshooter okay, we're going to close it out with some rapid fire questions. You guys ready?

Yeah, let's do it.

One sentence or one word answers? Maybe first. What application category do you think will break out for AI in the next 12 months?

I'll try to say this in two sentences.

Okay.

Which is I think anywhere where you're using reasoning models better are where applications are going to shine and I think diagnostics is one of them. Health care being, I think a prime example of that.

Another startup or a founder that you admire?

I would say Demish Hassabis. Hopefully I didn't butcher the name, but I think just an amazing researcher. So much foundational work and just always trying to solve the hardest problems.

Recommended Pieces of Content how to make Yourself smart on AI My favorite article.

Which you can read in five minutes, is the Bitter Lesson by Rich Sutton, who won the Nobel Prize last year for his work on reinforcement learning.

Any other AI agent companies that you admire? You're one of this very first cohort of truly agent native companies. Any others?

Aside from the obvious, like glean, I mean I'd say perplexity is one for sure that I think is just doing a fantastic job.

Favorite new AI applications that you're using in your personal life?

I honestly don't use anything other than ChatGPT.

Unfortunately the same for me. It's already. It's my best friend at this point.

Wow. I love it. Maybe one last question. Will we be vibes, coding, banking apps, payment systems, healthcare systems in five years time?

To some extent, yes.

Wonderful. Thank you so much for joining us today. We really love this conversation and congratulations on what you've built so far at Traversal.

Thank you.

Thanks so much.

Sa.