Observability 2.0: Shifting Left From Reactive Mon... Kokilavani K, RK Gupta, Sivakumar K & Suresh K¶

Playlists: KubeCon + CloudNativeCon India 2026

Panel with Intuit, Atlassian and Cloudera practitioners on the shift from traditional monitoring to LLM-assisted 'observability 2.0'.

Categories: Observability, AI & ML, Cost & efficiency

Topics: observability, generative ai, llm, monitoring, shift-left, aiops

Transcript¶

▶ 0:00 Hi, welcome to our panel discussion. I'm Kokila. I work for Intuit. And I have here an incredible experts from our panel. Um before I get into the discussion, uh like today you would have walked through the Expo floor. And you would have seen multiple vendors talking about observability 1.0, 2.0, even 4.0. Just to make things clear and to have grounded and for our discussion, we would like to see the evolution of observability in two phases. Wave one where we were completely focused on traditional monitoring, where we see the logs, metrics, trying to find a way to figure out what went wrong and all that. Uh but that is doesn't scale, right? So

▶ 0:43 when it that is that started impacting our business outcomes as well. Now with LLM's introduction uh with AI coming into picture, now the shift happened. So now that comes the wave two, which is we call it as observability 2.0. Where we introduce uh the LLM's capabilities, generative AI's intelligence to see how we can leverage that for our monitoring. So with this context, uh I would like to introduce our panelists, RK from Intuit, Suresh from Atlassian, Shivakumar from Cloudera. So with this, I would like to start my first question mainly focusing on what are the challenges that we had faced in the the first wave, which means the

▶ 1:28 traditional monitoring. So to begin with, Shiva, I have a question for you. As you have led like a major enterprise transition starting from traditional data centers to the cloud uh environments, uh what are the challenges that you had faced in your career? >> Yeah, I think that's a good way to start with, right? We are still, you know, a lot of enterprises are still in wave one as Kokila was explaining and slowly they're getting into the wave two. Right? And we as humans, generally we are good at one thing, right? We are pretty good at replicating or copying what others are doing and then implementing the same, right? And in a data center world, what used to be there is the capacity was finite and deterministic. So, a lot of our alerting thresholds, pretty much everything was,

▶ 2:12 you know, kind of static in nature, right? Now, this was already working well and it was serving us. What we did as part of our transition to cloud, right? What worked here? We just took the same, the lift and shift, like what we did for our servers, right? And added to that, I'm pretty sure, you know, we all engineers know, anything and everything which we do, we wanted it as of last week, last month, right? Coupled with that and our human nature, what we did is we migrated those static thresholds as your static alerts into the cloud or multi-cloud world, right? I think this is one of the major thing which we also underwent at a lot of enterprises, right? When we migrated the static threshold, all of a sudden, your cloud is non-deterministic, there is no finite

▶ 2:57 capacity, at least, you know, theoretically it looks like you have an infinite capacity. Now, what's the battle here is your static threshold versus infinite capacity and resources. Now, all of a sudden, you know, everything is going up for a toss and, you know, causing a lot of back pressure on the teams, you know, who are setting it up and managing it, right? And this is definitely one of the very good promises which the Wave 2 is holding for us. >> Thank you. Thank you, Shobana. That's a good thing. Um a next question to RK. So, we at Intuit, we handle like quite a lot of financial data, which is like which is at huge scale. So, because the data is very huge, how do we differentiate between signal versus noise? Given that we collect too much

▶ 3:41 data, is that slowing down the recovery process? Please share your thoughts on that. >> So, um there are two contexts of the data. One thing is real business data, which is I assume most of the business data are like real data, right? You really want to make sure, you know, you can consume it. The another aspect is operational data, which is we talk about we call observability data, right? Uh the for any enterprise, you know, when you talk today, you know, like the amount of the observability signals you generate is like, I would say, much more than what you really need. And uh the problem you face with that, you know, how you really differentiate uh that what are the real insight and

▶ 4:26 what are the real noise in that data, right? So, at the same time, you know, as you know that the organizers growing, the data continue to grow both operational as well as the business data, but operational data becomes a pain because you end up paying the cost which you don't need, right? So, the key struggle for any traditional things like even companies are kind of adopting a lot of new tools every day. Data continue to grow. Same time, you know, how you really keep the cost low. So, it become more around, "Hey, how to differentiate my telemetry data, which is, you know, real signal versus noise, uh keeping the cost low, serving your

▶ 5:10 customer to the best capabilities?" And for today, all the traditional uh I would say the observability solutions which you are around it, I think problem is not yet solved. Uh you know, though all the vendors comes and talk about two things today, "Okay, I can reduce your cost." Uh but the observability being a so sticky technology, you know, a lot of times enterprise, you know, shy away from changing it because the cost of changing it sometimes is high. So, you are in kind of uh place where, you know, you want to change it, but you can't change it. Same time, you have the cost going on, so you have to find some alternate solution. So I think in the wave one where we are today um in invariably for the all the large

▶ 5:54 enterprises, the dilemma continue to be there, you know, and I think that's where the new uh area for disruptions which we can talk about. >> Yeah, sure. Thank you for that insights. Um my next question to Suresh. So your team builds most fundamental foundational capabilities for the developers. So why is it historically so difficult for a product developers to think about the telemetry early in the SDLC? Like people always think about first let's build a product, then we think about okay we'll set up monitoring, we'll set up alerts, or do whatever the telemetry setup. Why that shift is not happening? What kind of challenges that you see there? >> Well, uh I think as everything in life it's all about incentives.

▶ 6:38 And uh as of now or even if you look at telemetry or or monitoring or observability is more of a externality, right? So when a developer and and Shiva mentioned on we need something yesterday and with today's AI world coding agents, you know, that time is compressing, right? So you need to get those things done and and it's it's basically a tax which every developer has to pay. And they are doing it for someone else, you know, ideally it should not be but you know, hey a developer writes a code, somebody else is on call from the team or an SRE is on call. And it's they are benefiting from it. So I think that's where the problem number one. I think the problem number two is also that we have all these solutions and and I know we have been talking

▶ 7:22 about wave one and wave two. Uh we also know that we started collecting a lot of data. Arkin mentioned about it and and there's a too much data, too much too much noise and then how do we make, you know, even with all this data dashboards, you know, it's it's kind of not easy to figure out problems, right? So identify issues and and reacting to them and fixing them. So, I think that's one reason and if we have to solve that problem, I think what we need to do is increase the value proposition for the developer, right? And how do we do it? I think one is we make it free and free in the sense that in large or small organization alike, right? Can you remove the friction for developers to basically incorporate telemetry and I think with

▶ 8:05 wave two where we are talking about arbitrarily wide structure log or events, right? You know, we can do that and with coding agents is going to be super fast. But, the second part is also make it personal, right? How do, you know, developer can say I can immediately benefit from it? So, hey, I I put a PR, I'm rolling out my code progressively and then I can actually figure out where the problem is. And third is make it social, right? You build it, you run it, right? You know, it not no no other person. So, I think if we take care of these three things, you know, we can actually remove that friction or that resistance from developers' mind to actually, you know, focus on telemetry. And yes, obviously right tooling, right support. I think as a platform leader, our focus is on that.

▶ 8:49 How do we remove that tax? How do we remove that friction? And if it's virtually free for a developer, I don't think they will register to do that. So, that's the key. >> Yeah, I really like your point of incentivizing them and making them personally attached towards what they are doing. That's a That's a nice thought, actually. Okay, now let's move towards our next wave, the wave two where GenAI got introduced and that made a significant impact all over the place, not only the observability area, but there are so many impacts. Now, let's talk about like how we had used it or how what are the kind of knowledge that they wanted to share on with respect to that aspect. Specifically on anomalies, because previously we used to set up thresholds

▶ 9:32 and then the thresholds whenever that breaches, we'll get an alert. But, now with the GenAI world, we have anomaly pipelines with it can learn the pattern. It knows, okay, this is not It is kind of a common pattern that it sees. So, it should alert only when there is a change in pattern, not when the threshold is breached. Um so, with that, my question to you, Suresh, again. So, how this kind of GenAI is integrated integrated into our our observability engineering? What are your thoughts there? >> Well, uh I would say two points or two key things. Uh one is I would say see, AI is the interface, but you know, the most important part is the substrate, right? So, as we also know, we are talking about context engineering, obviously, prompt to context, and now harness, and

▶ 10:17 loop, and I don't know, but context is most important, and LLM are good at reasoning, but you need to provide them the right context. So, unless your substrate, your data, if we keep getting the similar data fragmented, I think today one of the problem also is logs, metrics, traces, all are silos. And while GenAI can or LLM specifically can make it easier for you to reason with those, you know, without running a specific DSL or something, but unless we improve our substrate, GenAI cannot help. But, GenAI can help. I think it can help scale, right? With very specifically, right? You know, if you have the right set of instrumentation, and a junior engineer at 2:00 a.m. get the alert, right? They don't need to understand the query DSL or the tool

▶ 11:01 which you are using. They can ask question in natural language and get an answer, right? So, that's a that's a one of the key part, right? Uh second part is AI with coding agents is also making instrumentation easier. The cost or the the text which I was mentioning earlier, that actually reduces a lot. You know, all your coding agents can tell you, okay, hey, what does it matter for this code? If you are writing a proper spec, it can instrument the code for you. You can get the right signals, you know, at the right time. You can analyze those. So, that's one, but also there are so many things which we can do is like, hey, you can review your PR from a lens of incidents, memory leaks. We are actually doing that a lot. Uh it can summarize previous incidents. So, I think somewhere where

▶ 11:44 you needed somebody joining a new organization taking 6 months to 1 year to understand the context and with the complexity of thousands of microservices, so many interfaces, different BUs, that makes it much much simpler to scale, right? that that tax which you are paying reduces a lot. But, I would throw one caution. I think we all talk about GenAI can self-heal, automate systems. I would say, okay, you cannot make a LLM deterministic, but what you can do is you can make the envelope around it deterministic. So, basically, your typed inputs, you know, your validation framework, dry runs, your policies, and make sure that uh you are actually,

▶ 12:28 you know, allowing GenAI to take some automated action which are like bounded, which are reversible, and and like which you can control. Like, it should not make things worse for you at 2:00 a.m. >> Yeah. Now, you nicely touched upon that GenAI being probabilistic and non-deterministic. Maybe that context, my question to you, RK, like it it is a general problem that everyone faces. It hallucinates, we can't trust the data and all. So, how do we make it deterministic or how we can trust the answers or the the solutions provided by these kind of GenAI-based solutions? What can we take? I mean, how what kind of actions we can take there? >> Yeah, so um I think I'll answer this question, but I just

▶ 13:12 want to just again come back to the setting the ground around the AI. You know, I know we are in this era of, you know, where I think most of the times we forget the problems, but we talk about AI 24/7. Uh how it's going to change. So, the way I I look at uh the AI is a first is a tool, okay, which is going to really solve some problem which we've been facing it. Then uh I talk about observability, right? Um observability is, you know, though things will be evolving, but uh the fundamentally the on-call toil or, you know, alert fatigue, you know, those problems are still existing, which is taking the human toil, you know, like the company which are like going through the human

▶ 13:54 toil, right? So, how you really take this technology which is coming up and solve that real human problem, right? That's That's basically the value proposition we coming to uh this side of it. So, uh when I look at AI, uh which coming to your questions around making it deterministic, so definitely being an organization, you really understands what are the your um defined path, you know, uh you know, you know your product uh I would say hierarchy, your uh architectures patterns, your design pattern, right? Those are the assets you always use to kind of give a very deterministic uh uh uh kind of path to your systems, and they're really

▶ 14:38 a uh kind of inputs to build your knowledge graph, right? You know, which is really LLMs kind of, you know, depends on, right? And when you kind of have this constantly at you control, not basically controlled by some other third party, your agents basically start learning in your own language, what you you build inside your operational data and the transactional data you in the company, right? So, your real focus must be now not only look at the logs or, you know, your uh metrics or the tracing data, but also looking at your change management data, your GitHub data, or, you know, you all the data you see upstream from operational point of view. And if you start seeding those data, you you start building that knowledge graph or, you know, your uh contexts, uh

▶ 15:22 you know, engine much more powerful which LM can understand, right? So, that's the one part and you get highly deterministic from that angle, right? Another things from AI like we've been when AI started coming in for our organization, we are really not just thinking about observability context, but the way we are thinking is about how to redefine entire SDLC. Right right from a design to the production, but in context of thinking of our observability from the day when you write a code and you ship the code to the productions, right? So, your SDLC basically the way it's integrated that you know, if I'm writing a code what kind of logging should go through this? What kind of tracing should go through this, right? Can I have my AI to

▶ 16:06 basically start kind of creating those for me? Now, we are shipping the code and I write another incremental code on top of it, what kind of new alerts has to be created for it, right? What kind of new dashboard has to be created or do I need to kind of redefine my existing alerts in a dashboard. So, when you integrate the your observability mindset as a part of your SDLC the AI becomes so powerful because typically what really happens when you build SDLC out of your observability, your observability becomes obsolete and you keep writing a new code and when incident happens, your observability is kind of lagging behind. But as you bring your observability as part of your SDLC life cycle right from a code and keep it aligned with how things are changing, you always see your stack is

▶ 16:50 basically progressing along with what you are writing. So, when you look at AI and integrating it, I think thinking holistically in your development life cycle, it makes it basically make much more powerful combinations and you kind of get that more incident you know, prevention strategy rather than you think about post incident. So, to me AI tool is I'm saying like the way we seen the last one year within Intuit it's been so powerful in terms of the data we generate. Finding the needle in haystack has been really really super powerful for us. So, AI is a tool again I'm saying but is really solving the human tool which you are really talking about and I think its potential I still see is unlimited. It

▶ 17:34 can be more deterministic as you keep making learning from your data point of view. >> Yeah, on the same friend Shiva you want to add anything on because you have seen the both the worlds, right? The on-prem world as well as the cloud world. So, now given in the cloud environment, how we can make these genies to be more deterministic? I know deterministic is not the right word as such but how can we reduce that hallucination? Like do you have any thoughts on that? >> Yeah, I think the hallucination, yeah it's it's definitely a problem and you know, I think a lot of us can even take advantage of that, right? I'm sure sure we have all seen token maxing and in Twitter, right? It's it's indirectly problem with that, right? Because you know, you just give something which is

▶ 18:18 very open ended, it starts hallucinating without much context and then we all say, "Okay, I'm I did token maxing, right? My achievement for the day for the month." Whatever is done, right? But coming back to this, how do you control, right? Because you know, as such the LLMs are just a mathematical, you know, probabilities of, you know, what's going to happen next, right? In that world, like I think a very good point which Suresh raised about, right? You cannot really make your LLM deterministic, right? If you make it deterministic, then the software what we write today kind of falls in that area, right? because we know what our inputs are, we know what our targeted outputs are, right? Now but in this world it's completely different. The the very strength which LLM brings in is those

▶ 19:02 capability to be undeterministic so that you know, it helps us to discover what we have not known in the past, right? With this, now where do we focus? Now, what you can do is start focusing around it, right? Not necessarily inside it, right? The governance structure around it based on your problem domain, right? Let's say you know, take an example, right? If you're payments gateway, now if you're using that to, you know, code a I don't know, code a aggregator, for example, right? Then you define the governance structure around it, right? It cannot take unaudited actions or it cannot, you know, just make up some number and then send it or it cannot just act, you know, saying a response, okay, the money is

▶ 19:45 transferred or whatever, right? So, you you tend to define the guardrails around it and so that it is still undeterministic, but within your context and your guardrail, you kind of keep it on its toes to exactly act the way you want it, right? It's just going to act the way it you wanted it, right? But it internally, it might still take that path and all of those things. That's where your guardrails kind of bring them back on their toes, right? So, it's it's fundamentally it's going to be the guardrails which you build around it and making sure you have a very solid validation criteria or exit criteria. Right? If you don't have this, yeah, I'm pretty sure, you know, we all can start tweeting again, token maxing every hour, every day, whatever. >> Yeah. Yeah,

▶ 20:28 sure. Um given in this world, now MTTR, which is mean time to recovery, is always more important. So, how do we handle um or how do we leverage NAI to reduce those MTTRs? Because when an incident management is like a big big problem that we have in front of us and once the once our observable telemetry data is proper, which means that is going to help us either no incidents or even if there is an incident, we should recover from that faster. So, how do we leverage NAI for, let's say, improving our MTTR? Maybe Suresh or RK you want to share any of your thoughts on that. >> So, uh again, as I said, uh MTTR in context of traditional observability uh definitely is a matrix we constantly talk about

▶ 21:12 maybe 1 hour 30 minutes 10 minutes, right? I think real the the target which people really talking about how to prevent incident, right? That means you really have an incident but you know now only you're chasing the how my MTTR is going to be whether 1 hour or 15 minutes or 10 minutes, right? But eventually if you're looking at some new technology, I think your goal going to be how you prevent incident, right? So to me that's the where we talk about anomaly and all, right? So if you have like today AI you're writing a right good some agents you're constantly watching every alert with a global

▶ 21:57 anomaly you understand the right context have the right knowledge graphs and you kind of build that relation saying okay this alert I've seen here and this alert potentially has the correlation with all these 10 other things downstreams and if continue to behave like this is going to have an incident, right? Can I prevent it, right? If I can prevent it and if I can build the recovery mechanisms, you know, saying okay if I like let's say provision more CPU or more compute maybe incident can be prevented now, right? So I would say the AI should really take us in that direction to prevention than basically reducing the MTTR because

▶ 22:40 MTTR reduction is definitely a goal but prevention is I would say much bigger goal of AI where you can really kind of get the true value in sense of the business. So that's my take on the MTTR. I definitely people are in the journey but true journey will be like when you can reduce the incident. >> Yeah. Thank you. You want to add anything, Suresh? >> I think adding to what RK just said, you know, obviously, you know, prevention is better than cure. And but I do think, you know, LLMs or or basically agents built over LLM can help us bring over MTTA. There are a lot of things we are already doing, right? So, and like say, hey, we know Argo today, you

▶ 23:23 know, if if a rollout is bad, it can, you know, reverse it, right? All those things progressive. There are a few things, right? And and that actually correlates with, you know, wave two of or observability 2.0, which is when you have a lot of contextual data. And then RK also discuss about hey, how do we build that knowledge graph or context of the organization? You know, every organization has their unique DNA, and this reflects in architecture, how it has evolved over the years. Making sense of that is is the difficult part. So, yes, we have anomalies, and and I think classic ML does that also. You know, we can detect anomalies, but think about a scenario, you say, okay, hey, why does, let's say, hey, this my service's latency increased after a

▶ 24:08 deployment at 2:00 p.m. And it can actually help do a lot of triage or diagnose very, very fast, okay? Given if you have, again, going back to that AI is just the interface, your data is the substrate, right? If you have that enough context or enough data observability, like, you know, wide events, comparing everything. Like, I will give you a scenario, like, Atlassian, we we are a multi-tenant company, thousands of customer running within a single shard, okay? And and when some impact occurs, right? Okay. And then your traditional monitoring cannot figure out, okay, hey, tenant ID 8104 is only having high latency. Why is that so? So, I think with wave two of observability and making that

▶ 24:51 correlation between different, you know, parts of your system, your application code, your you know, metrics and you know, basically it can help you reduce that time a lot. Uh I will still throw the question. I keep saying that, you know, let's not think that, okay, hey, we can put agents and forget about it that it will self-heal the system. As uh as you rightly said that, you know, we cannot make them deterministic, but how can we make sure put enough guardrails so that So, yes, there is a lot of potential, both prevention and also when something goes wrong in production, AI can help you react faster. And I will again go back to the same point as a leader, not an engineer, that it helps you scale faster, right? You don't

▶ 25:36 need to wait for somebody to ramp up for 6 to 9 months, right? They can use LLM to reason, you know, LLM's understanding of the knowledge or context graph from your organization and and reduce that time. Because you can't have your best engineers on call always. They will leave you. >> True, very much. Okay, I would like to touch upon cost aspect. Uh because now I would like traditionally we think about cost only when the data explodes or when at the later point in time. But given um LLM's, as you rightly mentioned, Shiva, that tokenization is a problem now. And from the beginning cost the cost to use an LLM itself is very expensive. How do we have a check on the like how how do we optimize that? >> Yeah. I think

▶ 26:20 cost this this is going to be like a standard problem which is haunting us across, right? I think from the day the cloud started, right? Or I mean, in data centers, when the resources were finite, maybe, you know, it the cost was mostly discussed in the board room, right? Where CF the CFOs used to talk about hardware we are buying and other things. As the engineers, we really didn't think much about the cost because we were constrained by the finite capacity. But all of a sudden in this cloud world, you know, everything each and everything which we do, there is definitely a cost angle to it, right? Because of the so-called infinite amount of capacity available, right? And I'm pretty sure as engineers we have done hundreds or thousands of things to save

▶ 27:05 the cost, but then at the always it all comes back, "Hey, why are we wasting money on cloud or you know, whatever, right? Any resources, right?" So, there is there is never a thing, "Okay, I'm done with cost." Right? I think this is definitely haunting our industry in every aspects and just coming back to the observability the same. Initially, you know, we were chasing this, "Okay, there is too much log. You know, engineers are logging info messages. They're logging, I don't know, debug messages. They should be only logging fatal error, whatever, right?" So, you guys struggling with cost at that point. And metrics, we emit a lot of unnecessary metrics. No one is looking at those metrics and traces, right? And now with LLM, the problem is again getting amplified, right? Because you're

▶ 27:48 throwing in a lot of junk and asking it to reason it out. I'm pretty sure, you know, your cost is going to max out, right? So, if you if you notice in all of these things, there is definitely a pattern to it, right? When things are infinite, you know, we assume or we take a lot of things for granted and cost becomes a secondary thought, right? It is never part of, you know, when we start emitting a log line or when we start emitting a metric. Like the whole observability 2.0 which shift left, right? So, that even before you design or write a code, you need to make sure, you know, you also factor what sort of metrics, logs should I emit, right? Now, we keep talking about shift left, but in observability world, it doesn't really

▶ 28:33 caught up, you know, all the necessary attention it needed, right? It doesn't, you know, it hasn't got the same level of adoption as testing as security has got it, right? The moment you start thinking in this aspect, right? Try to shift left, put some guardrails around it, right? And obviously you always need to have quotas. There is There is, you know, nothing or at least the well-known thing for us for all human beings is if there is something finite, maybe, you know, we use it a little bit more carefully, right? Maybe with quotas, shift left, and third one, this is more about the perception, right? Despite of, you know, so much value this infrastructure gives us, right? Our CFO or our managers or our management feel

▶ 29:18 that we are always wasting cost in cloud. Right? I think the If you start looking at the whole number, num- like you're spending like 100k or, you know, million, 2 million, right? If you look that number in isolation, it always looks like you're going to spend more, right? There is always room for opportunity. I think one of the per- perception there which we all need to have is what is the value add you bring in, right? If you're able to tie your value add to the cost you spend, right? You'll be able to justify whether, you know, the spend is worth it or not, right? I think you can uh definitely apply the same lens once you start using LLMs for all your observability use cases. What is the value you derive out of it, right? The value could be, you know, reducing your MTTR, right? Because

▶ 30:03 earlier the downtime was 5 hours, now it is 1 hour. What is the cost, you know, you save during that, right? So, the moment you start applying this, you know, you can definitely have a much, much better conversation in regards to controlling cost, right? And lack of all this, I'm pretty sure, you know, next year, 5 years down the lane, we will continue to talk about, you know, cost as as a key thing in each and everything which we do. >> Sure. Thank you. As we're coming to the end of the session, I would like to ask one final question to all the panelists. What is one legacy monitoring habit that the developer should unlearn to survive in the next phase? What do you think about that. >> What the developer should unlearn? >> Unlearn, yes. The legacy monitoring

▶ 30:48 habit that they have to unlearn. >> No, habit is very hard to unlearn, you know. >> [laughter] >> Because what I know, I don't want to leave it. But I think I continue to want developer to focus on the value addition part of it. You know, how a technology can basically enable them to help them write better code, efficient code, or maybe, you know, reliable systems, right? So, most of the times, you know, that's the way the engineers really struggle, you know, like I write a code, then the platform engineer will put observability, then they'll come to incident, they'll come back to me. I would I think

▶ 31:31 I'm saying like uh coming back to like if I'm a developer today, I really want to focus on adding a value on my software, right? And if I can shift that mind and, you know, use technology to basically unlearn all these habit, which, you know, kind of brings downs me my time like consumes my time to not to do the things which not require. I think that is the one thing I really focus on, you know. So, I think let's focus on delivering the outcome of work and see where you can offload the work to the Now you have the AI. Uh it's your companion in double down or triple down your efficiency the part of it. I think that's where I would focus on.

▶ 32:15 >> Sure, thank you. Suresh, want to add your one habit that could do >> I think from monitoring we went to observability and we forget about observability that it's not dashboards or metric or logs and so on. It's the capability to ask question to your system, right? Not not What we are still doing is in observability 1.0 and I'm worried about 2.0 that we are going to be defining the known problems, right? And I think the idea even with observability 1.0 and with 2.0 it's more pertinent that we should think about the not only the known unknowns, but unknown unknowns in the system. So, we should think about that rather than okay, hey, I know what can go wrong

▶ 32:59 with the app, right? In today's world, there are hundreds of things you don't control the whole stack. And with AI written code, you don't even maybe have understanding of fully your code, so plan to, you know, I think the one habit which they can unlearn and as RK said, very difficult to unlearn, is that don't make assumptions, okay? Be prepared for everything and instrument your code in a way so that anything happens, you can actually you can actually reason with it and understand how your system is behaving. >> Yeah. Okay. Thank you. Thank you for sharing your thoughts, everyone. Thank you, everyone, for attending. Thank you. >> Thank you all. Thank you very much for joining.