Putting AI On-Call for Humans | Spiros Xanthos, CEO of Resolve AI

Spiros Xanthos is the CEO of Resolve AI, a platform to put AI on-call for humans. He previously started Log Insight that was acquired by VMware. And started Omnition that was acquired by Splunk. He also helped start OpenTelemetry. They've raised $35M from amazing investors such as Greylock.

Spiros's favorite books: 
- Zero to One (Author: Peter Thiel)
- Build (Author: Tony Fadell)

(00:01) Introduction & Setting the Stage
(00:42) AI’s Impact on Software Engineering
(02:55) What Reliability Means in Software
(04:34) Resolve AI Explained in Plain English
(06:33) Real-World Example of Resolve in Action
(08:28) Early Customers & Lessons from Company Building
(11:40) OpenTelemetry & The Open Source Journey
(16:55) Positioning a Developer Tool in a Crowded Market
(18:58) Philosophy of Product Building
(21:06) Cultural Norms: What to Keep and What to Change
(24:33) Radical Transparency & Team Dynamics
(26:50) Recruiting for Resilience in Early Team Members
(28:59) Future of AI in Software Engineering
(31:25) Resolve AI Roadmap & Expansion Plans
(33:28) Exciting AI Advancements on the Horizon
(35:17) Rapid Fire Round

--------
Where to find Spiros Xanthos: 

LinkedIn: https://www.linkedin.com/in/spiros/

--------
Where to find Prateek Joshi: 

Newsletter: https://prateekjoshi.substack.com 
Website: https://prateekj.com 
LinkedIn: https://www.linkedin.com/in/prateek-joshi-infinite
X: https://x.com/prateekvjoshi 

Transcript

Prateek Joshi (00:01.444)
Thank you so much for joining me today.

Spiros Xanthos (00:05.122)
Hi Prateek, thanks for inviting me, I'm glad to be here.

Prateek Joshi (00:09.484)
Let's start with the current state of play in AI for software engineering. So much is happening and software engineering is being taken over by AI in all shapes and forms. just as a starting point, what are all the tasks within software, software engineering that can be automated with AI and where are the gaps? Meaning what is AI good at and

What is AI not good at as of today?

Spiros Xanthos (00:42.71)
Yeah. So first of all, think software engineering in that traditional sense before AI, you know, does not exist anymore, right? Like it's not a question of if this is happening, it has happened already. And, know, I think the future is our profession has changed. And, you know, most of the things we do will be driven by AI. I think, I don't think that we're going to have fewer people working in software. In fact, I believe what's going to happen is going to have much.

higher technology output, like 10x, 100x, and more people are probably going to be working on technology and software. It's just that I think the way we work on it is going to change. I think we're going to be delegating more more of the work to agents and we're going to be operating at a level of abstraction higher. Now, if you take software engineering and what was done so far, think at scale, especially what you see happening is that as systems become more complex,

As you start delivering business to software, obviously reliability and how well the system runs and how stable it is become like of paramount importance. And, generally speaking, more and more of the engineering time, whether that's software engineers or SREs is spent in maintaining and improving these systems, not just like building new, right? And, you know, one of my favorite quotes from one of our recent engineers is that if I were to type all the code I create in a week, it's going to take me an hour.

And why is that? It's because the complexity at scale makes it so that, you know, you have to worry about so many other things outside of like just coding that slows you down. And I do think that models have done an amazing job with coding and obviously, you know, take resolve itself. Like the majority of our code is generated. And although this has created, you know, huge productivity gains, the velocity of actually, or the output has not increased at the same pace. Right. And why is that? It's because like,

Basically that is only a fraction of what a software engineer does, right? You have to deploy and maintain and scale and improve all of that in production, right? And I think that's kind of the next frontier. That's what we need to now address to be able to move, like say 10x, at the 10x the velocity of the prior kind of world.

Prateek Joshi (02:55.128)
Within software engineering, you mentioned reliability and software reliability engineering is a big field. for people who may not know, what does that phrase mean and also what is covered in the scope of reliability?

Spiros Xanthos (03:13.358)
First of all, think obviously we have within software engineering, have, know, software engineers, developers who have maybe platform engineers, infrastructure engineers, have site reliability engineers. And, know, it, obviously there is some specialization, right? But in reality, I think everybody's actually involved in all of the above, practically speaking, right? And obviously in smaller organizations and smaller teams, you know, oftentimes you don't even have specialization, right? The same people.

that built the application, manage the infrastructure and troubleshoot the incidents or, you know, try to make the whole system more reliable. Now, to your point about site, site reliability or reliability, to me that involves, you know, in some sense, thinking when being proactive about all the things that, you know, might go wrong almost, right. And, you know, having like better design and having like more, you know, a more defensive posture.

And how you think, let's say how the system runs in production, right. And how you deliver this, you know, software. And also it's also being much more effective in actually understanding when something goes wrong, right. And when something goes wrong, being much better at connecting the dots and, know, fixing the problem very quickly. So it's not really a separate discipline in my opinion, but it's part of like, you know, what makes, you know, great products, great, great almost right. Cause they deliver a great user experience.

Prateek Joshi (04:34.722)
You're the founder of Resolve. For people who may not know, how do you explain what the company does in plain English?

Spiros Xanthos (04:46.158)
So Resolve AI is building agents for software engineers and cyber reliability engineers, say, Broadly speaking, agents for software. So what we do is we build the agents that basically use all the tools that are available to humans, whether that's source code, telemetry tools, infrastructure. So basically everything from code to backend databases and everything in between, right? Our agents try to deeply understand.

the structure and topology of software systems, learn all the tribal knowledge that are made in the environment. And then they can work alongside humans to help with reliability. Right. The main use case of our product is what we call AI SRE these days is to actually agents that are on call. They can receive alerts. They can participate in incident investigations and hopefully get you to the root cause much, much faster than when a human does it.

But also because those agents essentially have like access to all these tools that the human has, you know, our users use them for all sorts of other tasks. Right. We actually use the term vibe debugging to describe this, but imagine any question that you have that goes across code and production, right. Something slow down. Has there been a feature flag has been in change. If there was one, could it, could it explain the slow down, right? Or is something else. So what we've seen is that.

It starts with, you know, reducing like time to resolve incidents, reducing, let's say escalations, making the life of on-call engineers better, but then it kind of expands to really most of the tasks that software engineers do on a daily basis by using all these tools.

Prateek Joshi (06:33.846)
Actually, that's a good segue into my next question about the product. So Resolve, they're building agents who can autonomously step in, troubleshoot, fix issues. So can you walk us through a simple real-world incident where the agent steps in and does its thing?

Spiros Xanthos (06:55.98)
Yes. So first of all, the agent is not, you know, is think of it almost acts as a human, right? It uses human tools and it operates on top of all the tools that are available, right? You don't have to change anything. So basically it joins almost as another team member into your organization. Like let's say a typical example is maybe an alert fires about something that is wrong or a customer comes in and complains about some symptoms, right? The agent receives that this very high level symptom could be that, you know,

Suddenly some of our users are receiving, let's say errors when they try to perform an action. And then what it does is it takes that high level symptom and then creates a plan and goes and uses all the tools. It's going to go look into logs. It's going to look into metrics and dashboards. It's going to go look and change this infrastructure, change this traffic patterns. And it goes into this loop trying to essentially figure out what might be causing the problem. As it does the work, it reports back to humans and this happens very quickly.

What are the findings? So let's say within a minute from starting an investigation, it usually has an answer about what might explain the problem. But then it continues running in the background and it can interact with humans until it gives you an answer, essentially the root cause of the problem. And then after that, usually it can recommend a fix as well, right? In most environments, customers want to be, users want to be the ones who apply the fix. They don't want the agent to necessarily take action.

But the agent can also propose what the fix might be.

Prateek Joshi (08:28.8)
And as you go to the early days of company building, can you talk us through how you got your first few customers and also looking back, like what were the learnings? Like what went right and if you had to do it again, what would you do differently?

Spiros Xanthos (08:49.902)
I've done it multiple times. This is my fourth time. So I had a lot of learnings. know, I had built two other, actually I built two observability tools, a log analysis tool out of my PhD that was acquired by VMware in 2012. It's called Loginsight. It's still VMware's log analytics platform. And then in 2018, I built a company called Omniscient, which was an observability platform for cloud native apps.

Prateek Joshi (08:52.482)
Yeah, right, Yeah.

Spiros Xanthos (09:17.368)
We also co-created OpenTelemetry, which now has become a very popular open source project for, you know, essentially collecting. It's a de facto standard for collecting telemetry from software systems. It's the second most active project in CNCF after Kubernetes. CNCF is the foundation that shepherds Kubernetes. So I guess I have like a few views. I mean, something's changed actually in AI, but I truly believe that, you know, the best way to build like...

very useful product is to work with customers from day one. So at the beginning, we had this hypothesis that, you know, building AI that kind of works alongside humans or does this all this tedious and stressful work that humans have, it's going to be very valuable, right? Because it both helps with reliability of systems, but also, you know, takes away all this stressful work, right? But we have two questions there, right? Is this something that humans would trust in production?

I'm talking now early 2024, right? And is it possible to even build a system like this that is effective enough that is going to be actually useful and not create a bunch of noise? to tell you it's like, it's the hardest product I ever tried to build. And I think the only way, the only reason where we are with like, you know, good success and traction so far is because we've been working with customers from day one, right? And there are no silver bullets, especially not in AI.

As easy as it is, let's say to build a demo application, it's that much harder to build something that works in production. So a few of the principles on which we build the product, right? True innovation comes from solving real customer pains. And we've been trying to do this from day one. We're working with design partners from day one before we even had the product. You know, we started by discussing ideas and mockups. And then, you know, I truly believe, and this is kind of a lesson I had from all the startups I worked on.

Like if you're going to, if you want to build a great company and a great product, the only way to do it is by working with great people. And, know, if you ask me what I spend most of my time other than product and customers was actually trying to recruit and convince, you know, smart people to join our mission. So these are some of the lessons that we applied from, from the early days.

Prateek Joshi (11:40.942)
That's amazing. talking about open telemetry, you created it and it is one of the hugely popular tool and it's certainly the industry standard when it comes to observability. So can you talk about the open source journey and also more importantly, how it influences your thinking around product, bottom-up adoption.

And maybe part of the question is if somebody has an early open source tool that's kind of taking shape, how should they think about open source and community?

Prateek Joshi (12:55.428)
So you helped create OpenTelemetry, which is a hugely popular open source tool. And it's certainly the industry standard when it comes to observability. So can you talk about how the open source journey influences your thinking around product? And also maybe part B is, if somebody has an open source tool, it's kind of slowly, early days taking shape. How should they think about community, trust, bottom-up adoption, and hopefully commercializing it sometime in the future?

Spiros Xanthos (13:27.435)
Yeah, so first of all, I'm a huge believer in open source. It has been a huge kind of positive influence in an industry, right? Technology has become a lot better because we adopted open source widely, right? From Linux to open telemetry and everything in between.

You know, with open telemetry, back in 2018, we started by working on open sensors, which is the precursor to open telemetry. then open telemetry was the outcome of the merger of open sensors and open tracing. Our view at the time was that, first of all, every vendor had their own proprietary agent and format, which actually was bad for the end-users, right? Because they didn't control the data. But also it made our ability to utilize this data, it prevented, let's say,

Prevent us from utilizing the data fully, right? Cause your metrics were separate from your logs, separate from your application sometimes data. So our thesis at the time was that it doesn't make sense to have like the separation of data. doesn't make sense to use proprietary protocols for all of these. And now to be honest, we didn't know that, you know, telemetry would become as successful as it became. But you know, it makes sense, right? Cause it solves a very real problem. And you know, it gives us the ability to build much more powerful solutions.

And if you think about why is open telemetry so successful, because, and why is open source successful, right? Because when you have a movement like this, right? When you're trying to create a standard in some sense, right? It's impossible for every, any individual vendor on their own to actually do everything that the community does. You know, when open telemetry started, we had like, I don't know, 10 developers working on it, right? Across all the contributors. The bigger vendors who had their own agents had hundreds already. But you know, still like when the...

community comes together and when you be the movement, know, open telemetry ended up having more than a thousand active developers and it's impossible for any kind of individual, let's say, kind of company to be able to accomplish this, right? And I think honestly move the industry forward and made observability what it is today. And the other thing I'm proud about when it comes to open telemetry is it's not just a product, right? It's kind of like an open source project is a framework, right? And many successful companies actually were built on top of it.

Spiros Xanthos (15:48.075)
So to your question about commercialization, I think that I'm not a huge fan of like open source projects for just the sake of maybe distribution, right? I think that they truly have to provide something that is valuable. And if you're going to build a business, I mean, it's desirable, right? If there is one, but I think I do believe that the best way to do it is in a way that complements the value of the open source provides, right? Take open telemetry as an example.

You know what we did and what I would suggest anyone do if they want to work on it, like don't try to take that and maybe like create a closed source version or like a limited version of that. Right. But maybe build now a much more powerful, you know, observability solution, assuming that open telemetry is successful. Right. And, you know, anyway, that's kind of my philosophy in it. And I think that makes it a lot easier because then we're not kind of going against the community, right? It's truly open source and you know, maybe the value that open source creates.

is complimentary to what you're trying to build as a commercial solution, right? Rather than the open source being like a subset of what your commercial solution is.

Prateek Joshi (16:55.756)
When it comes to building a developer tooling company, almost mostly selling to engineers, there are so many products and tools in the market. So how do you think about positioning a product in this domain? And also specifically, how did you do it when you started, when you talked to customers? How do you explain what you're trying to do and where you're positioned in the?

Spiros Xanthos (17:23.543)
You know, I think that, it depends on the, obviously it starts with solving the real problem, right? And doing it in a much better way than it was done before. The reason for us, to start resolve is, or, you know, the motivation and also the way we thought about it is like that there is now not just like a slightly better way of solving this problem, but it's a completely different way of solving the problem. Right. And, know, our entire focus has been on.

Definitely building something that is way better, but also being different, right? Like by thinking from first principles, how maybe we should troubleshoot systems, right? How should we approach all these hard problems of connecting the dots across different, you know, data systems. You know, and I think if you do that, then you find yourself in a situation, maybe, you know, you're not competing directly with kind of established products and vendors, right? Maybe you're solving initially a smaller problem, but you're doing it so much better that can become a no brainer, right?

As opposed to like trying to be maybe very broad and maybe try to be everything to everybody. Uh, so that's kind of my, my take and starting, right? I started with something very painful problem and try to be very initial most, right? Like solve it better than anyone, but focus on one thing. Right. And you even see this in my opinion, as a mistake, sometimes like AI kind of developer products do these days, right? They try to be too broad, right? And almost, you know,

They're good at some things, but you cannot be great at many things all at once, right? And I think then, you know, you dilute the value.

Prateek Joshi (18:58.286)
And when you think about the philosophy of product building, what core tenets or how do you structure your teams? What do you tell them? How do you think about just product building inside the company?

Spiros Xanthos (19:18.615)
So, you know, there are a few kind of principles we try to follow, right? One is...

We don't believe, let's say in technology or innovation, let's say for the sake of it, right? We always try to essentially have a lot of clarity and what is the pain that we're trying to build, right? And not only that, we always try to have a lot of clarity. One, what are the problems that we're trying to solve have a known solution and it's, say mostly engineering and what are the problems actually require maybe research, right? It's require a new approach. And you know, honestly, the only way to separate between the two.

And not do research for the sake of research is by deeply understanding both the problem and the technology available to you at any given moment to solve the problem. And, know, this is kind of my philosophy in product building, right? And obviously to do that well, you need to, you know, be honest with yourself. First of all, right. Is, is what you're solving. This is the problem you're solving real, right? Do people have the real pain? Are they going to pay money for it? Right. And then also it requires you to work very, very closely with users.

And always validate your ideas. And then in the early days, I do believe that the best way to do it is for everybody to have access to everything, including like customers for engineers to be legit, the product managers, especially when you're building dev tools and interact directly with, with users and customers and build the product at the same time. until, you know, very recently, until we had like more than 30 engineers.

everybody reported directly to my co-founder who's the CEO of the company. And everybody had access to all the information and you know, it was much better way of actually communicating and you know, understanding the problem.

Prateek Joshi (21:06.98)
Now going to going into company building for a second, you know, you've done this multiple times successfully. So if you look at the cultural norms and principles that you want to continue keeping from your previous companies, so what would that be? And also more, maybe part B to the question is, what is something that you specifically don't want to do at this company that you did previously, which you now think is either not great or just not.

some reason.

Spiros Xanthos (21:41.953)
Yeah. So first of all, I think, being a founder, it's, it's not like a glamorous job. And I think it has, maybe it appears like that to people right now, but you know, if if you approach it that way, I think, you know, you're going to be very disappointed. Being a founder means doing all the work that nobody else sometimes wants to do. Right. And not just doing it for the sake of doing it, but doing it because it's, you know, you need to set the example that, you know, to,

To do this well or to be successful, you know, to be able to do whatever it takes. I believe in transparency, actually radical transparency, would say. Like inside the company, everybody knows everything about what's going on. We, every quarter when we have a board meeting, we actually share the deck with everybody. I truly believe that any problem should be visible to everybody. Sometimes founders make the mistake of hiding, let's say, challenges.

Because they want to protect their team, right? They feel like, if people are exposed to all these problems, you know, they might get scared. I think the opposite is true, right? I think if you have, if you want to have an amazing team, right? And if you want to solve problems, everybody should be fully aware of what's going on at any given moment. Because. Chances are somebody else is going to be more creative than you in coming up with a solution, whatever the problem might be. And also I think it creates a culture of trust and a culture where nobody, startups have problems all the time, right? Like.

Most things don't work. So this approach in my opinion, creates a culture where people don't get scared, right? Like when something goes wrong, you know, they come together to solve the problem, right? They don't run away because this is so sudden or, you know, surprise to everybody. Now, one of the things that I'm doing differently is in most of my previous companies were like in person, but we always had, you know, the beginning folks that were remote, right? Because, know, you always know.

Great people that maybe don't live in the Bay area, right? In our case, this time we decided that we would have every, we would all be in person, work in the office five days a week and do it all in San Francisco. And I truly think it was a great decision in that obviously makes maybe recruiting a little bit more difficult. But at the same time, maybe it attracts people who want to be in an environment like this, right?

Spiros Xanthos (24:04.887)
And I think this environment creates trust a lot faster, enables you to solve hard problems a lot better because the communication is better. And in general creates, I would say, a very strong culture. you know, oftentimes people feel much closer to each other and, know, they work hard because they, they, they, you know, they want to support the people they're working with and, you know, they want to actually, you know, do great and solve real problems and have problems.

Prateek Joshi (24:33.006)
You made a very good point about how founders feel the need to protect the team from all the bad news, the hard news. So they just kind of keep it contained. But on the flip side, let's say if you're completely transparent, every board deck gets shared, everything, cash out, all of that gets shared. Now on the flip side, some of the founders said, hey, I did that. And now in addition to the problem, I had to deal with all the team members who are freaking out because...

that's just not used to it. So how do you balance the need for complete transparency, which is great, but also teammates who are just not, I mean, maybe founder stress is not for everybody. So how do you deal with that dynamic?

Spiros Xanthos (25:17.217)
Yeah, I think actually the problem you're describing is exactly what I think, what I'm saying avoids, right? You know, first of all, you always do, you need to, as a founder, first of all, you need to be honest with yourself, right? Is the situation as good or as bad, let's say, as you might imagine, founders tend to be. Second, what I'm saying is like, if you this culture from the beginning, you know, people are not used to it, right? I agree with you, but let's say.

When you start doing it when it's five people, right? And it's 10 people, like the 11th person that comes to the company, you know, maybe surprised initially, but then they become part of the culture themselves, right? And I think you can maintain this a lot better as let's say new people join the team and you know, they realize that that's how we operate. In my opinion, it becomes very, very powerful, right? And what you're describing, in my opinion, is a symptom of maybe somebody not doing it. And suddenly when something is wrong, actually now exposing it to people.

Prateek Joshi (26:05.252)
Right, right, right. Right. Actually, that's a very good point. And I think it's like, if you want to do it, you do it from day one, because if you start doing it two and a half years into the company, that's a big culture shock because you hired a recruited certain type of people based on your criteria then, but now suddenly you want to introduce this very like net new thing. Okay. Maybe question then when you, when you are looking to recruit your first five or first 10 team members.

Like how do you test for this muscle? Meaning obviously you can test the technical knowledge, you can do background checks, that's good. But how do you test for mental toughness or just the ability to withstand all the stress?

Spiros Xanthos (26:50.977)
I think that naturally anybody who would be willing to join a five or 10 people startup, probably they have built in resilience, right? Like I don't think, you know, what I usually do is when I talk to somebody, even at this stage of the company, right? Where 60 people always try to understand for myself, are they a person that are gonna enjoy working at the startup, right? Which means the fast paced.

the challenges, the intensity, or is this a person, somebody who feels like somebody that, you know, prefers stability, prefers to be an environment that is predictability and all of that, right? Now, how you test for that, you know, I don't know if I have a set of criteria, but usually it's very easy to tell, right? And it's very easy to tell because oftentimes people who prefer stability will care a lot more about, let's say, you know, to discuss salary and outcomes than work, right? Which is fine. Like there's nothing wrong with that.

But you you can tell very quickly. And then what I do is when I find somebody who truly feels to me like a startup person, especially if they don't come from a startup, right? Especially if they come from maybe Big Tech, then I usually like, that's where I focus, right? And I spend a lot of time because I honestly believe it's going to be better for us, but also more importantly, better for them to join a startup, right? Because if you have that mindset and if you want to move fast and if you want to have ownership.

Then startups that work well are magical, in my opinion. The satisfaction you get is way more than, let's say, a bigger organization where we're constrained, where oftentimes decisions are made for you, et cetera. One way I describe this sometimes is, let's say, if you join one of the big labs for people who work in AI. The work might be interesting, but your own kind of work won't.

make or break the company, right? Or the chances of that are very, very small, right? Versus if you join Resolve or a startup like Resolve, you know, your own work can make or break the company, right? And if that excites you, you know, you should be at a startup.

Prateek Joshi (28:59.844)
Right. Looking forward to AI and software engineering as a whole, right now, a couple of areas where for code generation, a lot of people have adopted the products of code generation. AI is being used for code review. AI is being used for DevOps, incident management. So if you look forward to the future, what's the next?

area in software that's like ripe for disruption, meaning where will AI make the biggest impact? What do you see happening in the next 12 months?

Spiros Xanthos (29:39.553)
Yes. So what we have seen happening so far in my opinion is that models tend to be very good with almost like one modality of data, right? When it applies to software engineering, like models have become very good with code, right? And, know, they have become very good, you know, in a similar sense, maybe with customer service data, which tends to be text. I think that software engineering is not just coding, but, know, to solve real software engineering, you you have to build.

Models and agents or the combination of the two, but it's very good in dealing with all the different modalities of data, right? Source code telemetry, which itself is usually time series versus unstructured data like logs, you know, understanding infrastructure and, know, changes and all these events that happen there. And, you know, also all the tribal knowledge that usually exists that is very unique in every organization, right? Code is self-documenting, but you know, the way my application works end to end.

It actually has many things that are unique and particular to me, right? That go outside of code. So I think that as now models improve and we can build agents that can reason and can connect the dots. I would say like we're at the cusp of being able to solve all these maybe harder problems. honestly are much more common in larger code bases and larger systems. Right? So I think that where we are today is we have like obviously coding tools and coding agents that work quite well. I think we're starting to see.

AISRE tools that also now try to connect the dots across all production systems. But also we start to see that code becomes an input and you know, maybe you have like a more broad view of the world now across, you know, code and production.

Prateek Joshi (31:25.028)
And for Resolve, as you go forward with the company, how do you view yourself growing and expanding? Meaning, right now you are doing what you're doing, but in the next 12, 24, 36 months, what's on the roadmap?

Spiros Xanthos (31:44.333)
You know, like I said at the beginning, in my opinion, for a startup, for as a startup to be successful, you need to solve, you know, smaller set of problems or even one problem and solve it really well. Right. Our focus as a company is to be like kind of an amazing AI SRE, as I call it, which means like want to be a tool that is indispensable, but software engineers and SREs want to use for, let's say troubleshooting problems, incidents, alerts in their environment. Right.

We want to, and what are the seeds happening with our customers? Where the way they approach this problem has completely changed, right? It improves their quality of life. It improves the outcomes and, you know, avoid so many other stressful situations that you find with on call. That's our primary goal and one I'd be like excellent at it, right? Now, if you're excellent at it, then many other possibilities open up, right? Cause now to do this well, you built a system.

An AI system that understands like software end to end, right? Cause it has to operate all these tools. It has to extract tribal knowledge and all of that. Right. So naturally if you have a system that understands, you know, software so well, you can start expanding to other problems and other tasks that humans perform today. Whether that's the management of the underlying infrastructure, whether that's improvement in code for liability purposes, whether it is actually managing the underlying tools that's the human tools, right? The observability tools, for example.

that humans use today. So my view is that if we do this very well, we earned the right to solve many other problems, right? But, you know, we have to prove at scale and, with hundreds of customers that were the best for the, the best AIS, let's say.

Prateek Joshi (33:28.708)
And one final question before we go to the Rabbit Fire round. As of today, AI is moving so fast. What AI advancements are the most exciting to you?

Spiros Xanthos (33:46.785)
I think that honestly we're at...

single digit percentages of the way to the end in my opinion, when it comes to AI. I truly think that we're on an exponential curve. I think that models are ahead even of the capabilities of products have built and agents. And we're just scratching the surface, right? I truly think that the more especially kind of the reasoning abilities of models evolve.

Even like a small increase in that, opens up many possibilities of additional things that we're able to do. And I truly believe that, you know, why am I excited about AI? Right. I think that oftentimes we worry like whether it's going to take our jobs, right? Maybe ourselves as software engineers were worried that, you know, there is a future where there are fewer software engineers. Like I said, I don't believe that's the case, but that's not really the main question in my mind. Right. Like the main question is like, are we going to be able to build technology a lot faster? Right.

And are we going to be able to use that ability to solve really hard problems? So to me, it's very, very desirable, let's say for AI to evolve and to evolve quickly and remain in this exponential improvement path. Because I think it's going to enable humanity honestly, to solve harder problems. And it's going to make things that are maybe inaccessible to many parts of the world, way more accessible. Right. And it's going to improve our lives and it's going to improve the quality of lives of most people. Right. Despite the challenges we're going to face along the way, right. Which are real and we have to be.

Thoughtful about.

Prateek Joshi (35:17.732)
Amazing. With that, we're at the rapid fire round. I'll ask a series of questions and would love to hear your answers in 15 seconds or less. You ready?

Prateek Joshi (35:29.111)
Question number one, what's your favorite book?

Spiros Xanthos (35:34.979)
I guess in the context of startups, is, I'll give you two, zero to one and build.

Prateek Joshi (35:41.24)
Perfect. Which historical figure do you admire the most and why?

Spiros Xanthos (35:50.691)
Probably, I'll give you a philosopher, I'll give you Epictetus, the Greek ancient philosopher, because I do believe in like stoicism. I believe like in actually discipline more than motivational.

Prateek Joshi (36:05.444)
Alright, next question. What has been an important but overlooked AI trend in the last 12 months?

Spiros Xanthos (36:19.587)
I'll give you actually a trend that I see myself now in, in, in when we build resolve. I don't know if many people understand in my opinion, as let's say the models improve the bottleneck of progress moves from actually, let's say inference and reasoning to the underlying tools that are available. Right. Cause agents today have to work with human tools and human tools, you know, are usually slow.

They actually don't support the throughput or the velocity in which agents can move. And I think there is a huge opportunity not just to build, let's say, AI for solutions, but actually to go and build the infrastructure and the tools that agents will be using to replace the human tools that have been used so far, especially in the data space, where a lot of the tools we have were designed for high throughput data ingestion, but very low throughput of querying and data extraction.

Prateek Joshi (37:16.664)
What's the one thing about AI and software engineering that most people don't get?

Spiros Xanthos (37:31.075)
I think I missed part of the question. Can you repeat,

Prateek Joshi (37:35.61)
yeah, yes. What's the one thing about AI in software engineering that most people don't get?

Spiros Xanthos (37:48.471)
I think that because a lot of the first generation AI tools and agents for software engineers were built by primarily by researchers. think all of us are coders, right? All of us have built software, but I think like, I do believe that real software engineering is not just coding, right? That's a big part of it, right? But it's also running and maintaining and improving and making all these systems reliable, right? And I truly think that there is a lot more value.

And there is a lot more challenges, lot more challenges on that part of software than on the part of coding and coding agents.

Spiros Xanthos (39:24.775)
like I said, you know, building a demo with models is very easy building it. Truly production ready product is much harder than before. And I think that what you see happening is that oftentimes, you know, we solve like simple problems, problems that are solvable today, but maybe with AI, we'll make them a little bit faster. What is truly actually game changing is when you can build something that solves a problem that was not possible before. Right.

And that's where greatness comes in my mind when it comes to AI products.

Prateek Joshi (39:59.014)
What have you changed your mind on recently?

Spiros Xanthos (40:11.639)
I've changed my mind on, many things. I think like, okay, maybe I'll choose one, right? Like what I, I, I, shared earlier. I truly think that we completely underestimate how far AI is going to take us over the next 12 months, right? Things that we thought might take five years to get to. think it's going to be like 12 months, 12 months away, right? Like the way we work, even as software engineers, right? It's going to look completely different in a year from now.

I don't think, you know, people talked about the death of the ID and all of that. I think we're going to go way beyond that, right? We're going to be having agents that are to be doing way more work than just answering a simple question or performing a simple task, right? You know, many, many steps and, know, again, that I think is going to accelerate our ability to to build technology a lot faster.

Prateek Joshi (41:01.799)
All right, final question. What's your number one advice to founders who are starting out today?

Spiros Xanthos (41:11.201)
I think that to be successful as a founder, first of all, you have to have huge persistence. You have to be obsessed with a problem you want to solve. You have to have conviction to believe that what you're building is going to work way before anyone else. And you have to be actually truly be willing and ready to work for the next five to 10 years on a problem, right? Unless all of these are true. I don't know if, you know, somebody should try to become a founder. And of course then.

There's many other advice on how you build products in companies. But I think these are almost personality traits that somebody has to have.

Prateek Joshi (41:48.735)
Amazing. Spiros, this has been a brilliant discussion. Obviously, you're a company builder. You've done it multiple times. So I loved your insights and loved the depth of the love thinking you need to do to keep going and build a big company. So thank you so much for coming onto the show and sharing your insights.

Spiros Xanthos (42:07.479)
Thanks a Pratik.