speaker-0 (00:07.832)
Welcome back to Adventures in DevOps, our guest, previous senior leadership at Citrex, where they focus on access security, managing conversational AI products, led orchestration platforms at Redwood Software, and now the CTO at Sauce Labs, where the their team is validating the the efficacy of written software tests. Welcome to the show, Anuk Tripati.

speaker-1 (00:26.222)
Thank you, Warren. Thank you for having me out here. So many times they will go and dig in saying, yeah, we do have a test case and did fail. But since our test cases are not reliable, we don't really give much weightage to it. Andy dug into it and he came back and said, you know, we do have a test case and it was failing, but we never bothered to look into it because it used to occasionally, all our tests occasionally fail. So I said, my God, let's do this. Next three sprints.

We are not going to take anything else. We are not fixing any customer issues. We are not writing new code. I just want everybody to make sure they fix all the test cases. And fixing test cases actually doesn't always mean you're fixing the test script as such. Sometimes it's more about fixing the environment. Sometimes in going and fixing the code, changing the behavior of the code.

speaker-0 (01:13.592)
How do you actually make sure you have the the right tests up front? I I think every single failed RCA root cause analysis session always ends the same way. We just needed to have one more test. of course, the trick is actually having that test before the incident.

occurs. So I think one of the challenges is how do you make sure that the validations that you're writing and putting in place are actually matching what will prevent future problems and not just handling a arbitrary edge cases.

speaker-1 (01:43.702)
It's a challenge. I don't think it's a fully solved problem to be be frank about this, right? But there are multiple ways to look at people have gone about hey I'm going to do my instrumentation of the code and make sure how many lines of code have I covered in the in the test process right instrument like okay I'll instrument the code and then I will run my test and at the end of it it will give me a code coverage report and we went and acquired a company in my last job and when we went to acquire them we asked them hey are you agile? yeah. You use JIRA? Yes we use JIRA.

Okay. All right. So the point is don't stop at those questions. said, okay, so how long is your sprint cycle? one releases sprint cycle. I said, nice. That means maybe they're doing release every week, every other week. But I asked, how long is your release cycle? we release once a year. So once a year, it's an agile process. One sprint is one year long, right? And the patterns out there.

Same thing is on the testing, right? Testing becomes an afterthought, right? And I had a product where everybody was testing and releasing to the field, the debug version, right? This is a Windows-based product. They're compiling a debug version of it and sending it. Why? Because the moment they change the compiler to say release, would start crashing left and right.

speaker-0 (03:01.624)
How do you fix this fundamentally so that no one ever thinks that this is the the right solution? And I think that the just the steps removed to have both the mindset and the orchestration and a platform or a system set up in a way to encourage the right practice here. So I I think just as an example.

Right. You may have a end-to-end test that calls a third party service that you don't control. Maybe it's your your billing platform or something like that. And there's some sort of non-production environment there. And it does some processing. And then you wait for the result. And it maybe it's an async process. And so it comes back with some sort of URL or some sort of wait timer or some sort of GUID that represents that process. And you could pull it over and over again and say, hey, you know, where is this at? Is it done? et cetera.

But if it always takes about five seconds, is it it's so much easier to write the line of code that says just wait five seconds? Or you know what? Let's be safe. Let's just wait ten seconds. Exactly. you know, in case something happens. and then with that, we'll just check the result. And then it works. And it works almost every single time. And of course, everyone knows, well, the right thing to do is, well, your test is dumb. separate out the like a harness for that third party system.

Have your own sort of mock of how that works because you don't need to test the integration of that realistically in this way. That's not a time-based thing. You can have expected return results and then just directly validate it against your harness. this happens a lot for like physical equipment, right? If you have like a a printer or a you know a saw or something that's mechanically controlled, a CNC machine, et cetera. You don't need to

attach your your tests, your integration test, your end-to-end test to the physical machine. You can make a mock of the interface and have it work like the a actual thing works. So you don't actually need to cut or or run an expensive or dangerous piece of equipment every time you want to r validate your your platform or your integration. I mean, of course you can have the the long-term integration test or end-to-end test to actually do it at some point, but for most of the stuff you don't need that to happen. But to build that out is not free. A lot of companies that offer computer controlled products

speaker-0 (05:01.26)
don't necessarily offer a virtual version of it, a digital clone, to run in in your testing suite, which has real time responses to it. And so we end up with this problem. And I think we see it in even huge platforms, even ones that are totally software based. Like you would think that email providers and companies that have digital messaging products offer a way to support item potency. Like you send a message and you can guarantee that message, you know, was delivered or not. And they don't offer a way.

to ensure that you don't deliver a message twice. So sometimes you I feel like you're forced into this because of controls that are just not in your sphere of ability to really affect. So

speaker-1 (05:43.276)
and very few people build the product for testing. But what happens is, and this is where if you, and one of the orgs that was working, this was at Citrix actually, what we did was we said the developers will do the testing, but very few organizations actually think that way, right? They're always in the rushed way. Let me build something and get it out.

speaker-0 (06:03.426)
for sure. I I think this is a very nuanced and mature perspective where if you know your software is gonna have to be tested, that you look at code and maybe today you'll have aesthetic opinions about how it was written. I don't like the way this looks. I don't like how this class is named or how these methods are formed, but or how it's architected, how it com communicates with this third party component. But if you say, Okay, but we have to test this, then you're like, Well, okay, now I can be specific.

The way this is coupled together makes it very difficult to inject in a impl a fake implementation of this third-party thing so that we can actually write a test that validates the code that we've written. And I find that those are the weird edge cases where it does force you to do more software development in order to even have the test in the first place. The counter-argument goes: tests have no upfront value for customers, right? No one of your no customer of your software cares.

if your tests pass. They care that your software works. And I think this is a fundamental distinction. So if you spend more time architecting your software in order to write tests, you're actually spending more time to deliver the same amount of value. How do you argue against that?

speaker-1 (07:11.584)
It's, you know, this is a similar question that our go-to market leader asked me the other day, says, Anu, how do you define a testing budget for a product? That's a very interesting problem, testing budget is like you kind of going and saying, you know, I screwed up and I want money to fix that in some sense. This is like I'm buying insurance, not even insurance actually is worse than that.

I think the testing budgets are typically getting defined more about what actually happens in the field, right? People will start with a certain place where most of the companies, okay, I don't have testers in my company, we don't test, we just build and ship it to the customers. Our unit test is so good, our interface testing is so good that we can ship it, right? Then they'll go through this process and over time they'll find some big customer issues, or big customers really, to a point where either they are threatened to leave or they have left.

and then you'll bring in a testing team and then you'll over-rotate on the other side and then they will talk about developer to test ratio, my developer test ratio is two is to one, three is to one, four is to one, eight is to one kind of a thing, right? And the thing is, it's more about the maturity curve of the problem. But again, the problem, I can understand the practical problem as you rightly put it, like why do I invest in building the test cases upfront? But the thing is,

If you do it, you will be successful in the long run, but the question is always about, let's worry about this quarter, let's have this fiscal year, we are not thinking about five years from now, right? So very few people think that way. But that reminds me actually of something that was very interesting. This is, was to year 2000. So voice over IP was a big thing and we were building an IPPBX at 3Com. 3Com is a big company, a competitor of Cisco for.

and networking and enterprise telecommunication space. So this PBX says for people who don't know like phones on their desk, a lot of times you don't have them anymore.

speaker-0 (09:13.55)
What are you talking about?

speaker-1 (09:15.918)
So we had to test this product and one of our software developers, came and he said, no, I've added a hidden telnet interface to it because the testing would be, the testers will pick up the phone, dial numbers, do this transfer, call hold, call record, all those buttons, right, call forward, hand group, do not disturb, that kind of a thing. So he put in a telnet interface where you could, through that interface, you could, as if I have pressed the button nine.

as if I press the hold button kind of a thing. Then he showed me and he says, you know Anoop, see this? I'm sitting and all these five phones are on this desk and randomly they are ringing each other. One is answering, there's a recording happening. So that's where it was both the physical machine as well as the software running on it was automated because I forced the developers to test it out there. And that, so this thing works for a while, right? So make sure you invest time in asking your developers to test the product early on in this.

The earlier you ask them to do it, you will make a more testable product.

speaker-0 (10:17.612)
Well, you know, so that's the thing, is like I always responded back instead, you know, when someone asked like how much budget should we allocate for testing, it's like how much budget should we allocate for having customers trust our brand? And what is the what is the you know, provide me a a quantitative metric that represents our brand trust without using something ridiculous like NPS score.

speaker-1 (10:37.975)
Yeah.

speaker-0 (10:39.736)
And like that's an impossible problem to answer. And so like if someone doesn't if someone's challenging you on how much budget to allocate for software development, it goes the other way. Like realistically, as you said, look at your product and how do you want your customers to feel about it? And I think that can answer a lot of things because I get a lot of experienced senior engineering leaders, you know, staff plus principal engineers, directors of technology, that will often say, Yeah, we know we need this particular budget to ensure

That we have this much reliability. And my question is always how much reliability do your customers expect? And they can't answer the question. It's like, what if it's down 90% of the time? Will they will they care? Like, yes, they will care so much. Will they care enough to switch to a competitor? No, they probably won't do that. Matter of fact, we've been down, you know, every single week for the whole year and no one's left. I'm like, why are you investing in reliability then? Why who cares if your stuff is broken? And they don't have an answer.

And I think this is where it really comes back is you can't be making technology decisions in a vacuum without understanding the impact to customers here. If you want to have long-term value that you can, I hate to say, extract from your customers, you have to understand what long-term means for them. If customers will be with you five years, 10 years, 50 years, potentially longer, then the long-term implication of the usage of your software is important. And so it should be easy to justify. Well, we'll make a change today.

And we may not find out for five years down the road whether or not there's a problem and who at that point is gonna remember what the features that were supposed to work or or do at that point. And so you really do need to focus on testing in that regard. And the only way you can get that done is if you do it, you know, up front. We took a step historically in my experiences to push testing all the way to the engineer that was doing software development. So if if you do TDD, even without pair programming, you write the test first. So the developer starts by writing the test. Now

I can understand why that's unpopular opinion because who wants to write the test when I can just write the code and someone else will write throw it over the wall, someone else will write the test and test it for me. Sounds fantastic. I love this job. Let me keep doing that.

speaker-1 (12:47.81)
yeah, so at Citrix when we started to put this thing about the developers and peer programming and TD model, right? So lot of opposition from the same things like, that means that you're wasting my time writing test cases while I could have written a new feature and all those things. So I started, I did a bugathon, right? And I said this week, sorry hackathon, was not a bugathon, I've done bugathons in different times, but.

This was a hackathon which was only to write test cases. I said, who writes the most number of test cases? And it was all open to both the test automation team and the software development team. They'll win a prize. And what happened is like at the end of it, the smartest in software development in the team, he wrote the most test cases and he won the prize. So after that, became like nobody had an excuse to say, no, I don't want to write test cases because if the best engineer in the team could

was be able to adopt and write test cases also. That whole concept, the taboo that they had about, write software code for production, I don't write for test, kind of disappeared in the organization. It was so fun to watch that whole thing melt away and now everybody is always writing test cases. But the hidden cost of quality that you touched upon, sometimes we don't realize that so many other places where you have hidden cost of quality, like,

If your product is, obviously it comes from testing and building it, right? also building has to be done right, the architecture and everything. But we don't realize that sometimes because of that our sales guys actually are spending more time with the customers on the stability issue, they're on those calls trying to pacify the customer, or at least as opposed to going and selling more. So it's not just about losing revenue, your salespeople, they're off the street now, internally focused on existing customer as opposed to going and hunting or farming.

a different account out there, right? So there is another place where you really come in, but it's very hard to really put a number and say, where should the cost of quality go?

speaker-0 (14:49.006)
So I think we have to be very careful about the incentives we put in place for engineers or even technology leaders or non-technical people, it doesn't really matter, that we put in place to drive particular behaviors. Cause we had something very similar at a previous organization that I was in. And the result was a bunch of engineers r went around automating the creation of tests for every single code that we line of code that we had. So for every project that there was, there was a now a new unit test project that popped up.

with a method for every single function. And inside was a single statement, assert, pass. And and so like a hundred percent unit test coverage by method count. I mean obviously not by line or branch count, but every single function passed. And he definitely won a prize. He didn't get the benefit of the consequences of that action though. He got to r leave that company and go somewhere else and make the same mistakes elsewhere. But we lost a critical signal there because actually

The lack of the unit test project and and unit test allowed us to identify what parts of the code were quote unquote legacy and untested. And by doing this, he won the prize of the most tests written, but he c had created a detriment to the organization because now we lost this signal that we had in place. And I just I just find this particularly interesting. So I I think there has to be a lot of goodwill behind why you're doing a particular thing and people have to be aligned. And I I'd be curious to, you know, go back in time now and see.

what sort of tests were actually written by the engineer to to to win the prize because you know it's like if you know a prize you're gonna win. If it's a competition. You know, it's just maybe winning the competition is is the value and not necessarily having the product

speaker-1 (16:27.796)
Yeah, you're right about it, right? And I think you just do some of these things because it's just fun and it creates a new energy in the organization as well, right? And you get some positive surprises. almost every time I've run this kind of whether it's a Bhagathan, whether it's an Akathana, whether it's an Automaton, I think we call it Automaton or something like that. But metrics are one thing that I always say that, don't chase metrics because

then what happens is that's what gets optimized for. The entire organization gets optimized around that metric. In fact, right now, for example, we are doing more and more using AI in our software development process. And everybody keeps asking, what's the metric? And what metric are you looking at? I said, don't worry about metric. Because the moment I tell you which metric I'm looking at, I'm sure that will look the best. So I look for multiple signals and I'll ask the questions, but I'm not telling you which particular metric am I more interested in on this particular front, right?

because gains can be different and people say, are writing five hours, we are, our engineers are producing 548 % more code now. I'll hear those kind of numbers from my peers as well. But for me, those are very meaningless numbers because I've been there, I have written the code, know, I still write code, so I know what you can do to come up with those kind of numbers because the moment you put a metric in front of you, as you said, right, start writing all the asserts with true and true and enjoy.

speaker-0 (17:49.55)
We so the question that I had actually put out and the metric that we try to use if we're gonna, you know, be specific here was roadmap acceleration. And I feel like anything else is sort of a mistake. Things that and why I mean that is things that you wanted to achieve for the benefit of your organization, company, product, customer, you thought was gonna take a very long time to do based off of whatever sort of back of the napkin calculation you had done and that you put in your OKRs or KPIs. And it turned out after implementing

process changes, adding LLMs or agentics software development strategies, it got moved up as far as when you were you considered it done. Not you did less, you did different, but it got done. And I haven't had any leaders come back and tell me for a long time that this was actually happening. Yeah, we were ever all the engineers feel way more productive. It aligned with the Dora 2025 report that came out last year, which we did a whole episode on. And the the TLDR for that is lots of organizations were saying,

Everyone felt they were being more productive, felt that they were delivering more or faster. But the only metrics that were actually measurable were quality metrics. And they said that quality went down, negative impact to your business. So everyone felt like the right thing was happening, but the outcome was quite the opposite. And a couple episodes ago, we had the ex-CTO of Grafana on, who actually was the first person who said, we are seeing roadmap acceleration that we would not have seen previously.

But I think it's a rarity still. And I think it's going to com continue to be a rarity, especially when the mindset that we have doesn't necessarily align with the the long-term vision that we're putting out there. As you put out, like if you want teams to write tests, you need to encourage tests being written. You have to encourage the long term mindset in order to make that happen. As long as you're focused on the next quarter or whatever the current metric is, you're going to have a problem.

speaker-1 (19:38.222)
No, I think I'm sure the Grafana team is seeing a roadmap acceleration. But one thing you have to always feel done and look into is if they made that as a goal to measure, because roadmap acceleration come in many ways and I've seen it, right? Okay, I'm going to declare GA much sooner than like three months before the product is ready, right? All right, my feature is GA now. That's what you're measuring for roadmap acceleration, right? So that's why what I say is do not make those as public statements as to what you're measuring.

And the other thing I also keep saying is there is something called output gain versus outcome gain, right? And that's where it is. What is the outcome that you're looking for? There's definitely an output increment that is happening with AI for sure. But is there an outcome gain that is happening as well? And outcome gain at the end is there. You know the top numbers that companies work on, right? Top line, bottom line. Is there some impact happening out there or not, right? Even if I accelerate the roadmap,

Did I build a meaningful product? Did I create a feature bloat in my product even, right? As opposed to really doing anything good out there. So it's a multifaceted problem. I think what we have to do is make sure you measure properly. But quality going down, we are seeing this problem and hearing about this problem everywhere. In fact, it's not just on the software development. It's even the content in the software design, the architecture documents that are being created. We have a quality problem.

Engineers are coming and complaining already saying, I know there's so much of content to review now. Because before, you know how the software engineers are like, they hate writing documentation. It's like pulling teeth out of them, right? In most cases, right? Very few of them love writing documentation. Now with the use of LLMs, everybody's writing a 20 page document on even a small thing, right? And now, and some of it could be wrong. Now the reviewers have to go and read each and every line out of it, right? And so there is a waste of...

So there is a quality problem in almost every phase of software development life cycle, whether it's architecture documents, whether it's design documents, whether it's actual code. And we are as an industry facing a testing problem because of that.

speaker-0 (21:39.702)
Why why do you say we're facing a testing problem?

speaker-1 (21:42.69)
Because the amount of content that's coming in, reliable validation of that content, it's still a human problem to be taken care of. Till that, till we go ahead and solve that testing problem in a way where you can rely lot more on non-humans to solve it.

we have actually created this problem much worse than it was before with the drug. So that's what is the one of the side effects, right? Like how you take drugs and they will solve a problem and you get some side effects. is one of effects. Use of AI in the entire process is we have created a testing problem.

speaker-0 (22:19.36)
I I agree, you know, and I I like the analogy because I I think what we've applied to the LLM provider companies have created products that are addictive, similar to TikTok and literally I I think a the analogy of drugs is very, very spot on. There is there is this this quote that I often feel like I'm repeating, at least back to myself, which is if you have i if you think that technology will solve your human problem.

you don't understand technology and you don't understand your problem. and I I think that for sure is what a lot of people are stumbling on today, which you know, historically there was no no reason to understand your problem fully, right? You you see something that looks like it's I hate this analogy, looks like a nail and you have a hammer and and you so and and everything looks like a nail. So why not why not go to town? But I I I think

Realistically, from a metrics standpoint, we still need to find an opportunity to share something public that allows us to align on whether or not an experiment that we're making or a change we're making to our organizational structure or software development process, SDLC or technology or et cetera, actually turns out better in the end. And I know people hate measuring stuff and I know people actually hate running an experiment, but some some organizations still want to do that. And I think at this point it's still very difficult to identify.

how you measure it. I I think you as you rightly pointed out, roadmap acceleration is even difficult to identify if that's the right metric. Obviously, if you create a a metric that you make as your target, any metric that becomes a a target ceases to be a good metric, right? And I I think we have that wisdom, but it still becomes incredibly problematic to deal with in practice.

speaker-1 (24:00.846)
I think what you have to do is constantly keep working on, I would say, a combination of signals to look for things. For example, I'll give you a quick. We had a code in a certain area of our actual deployment process. The SRE team had some code that was a tech debt for them. And it was so complex, they were too scared to touch it. And what I've been told in my company is that I've been only here for a year.

They've been thinking about changing that code for the last five years, but they're so scared to touch it, right? And then in one of the, so I do a hackathon, like we do four hackathon weeks, but two of them are actually purely innovation-focused hackathons twice a year. So in that one week, they went ahead as a team and solved it using the help of AI. Now, how do you put that into your, was it faster to release a feature? Like the kind of tech that you are able to offload, you don't need those

I would say, unique arm, ingenious to be so much expert in that dated way of doing stuff that can only support that system, that problem, that the risk that you reduce on the organization, right? So there is benefits where you can gain. So that's why you have to look at multiple signals when you're looking for what am I gaining out of using this? And then one signal alone won't help you.

speaker-0 (25:20.184)
So I mean, obviously we could talk all day about the AI stuff, but I'm much more interested from the testing standpoint. I think one of the challenges that we brought up here is realistically having the right tests is important and the incentives to have the right tests. But at the end of the day, how do you know that you have the right tests and what do those actually look like? Because I know if anyone's using an LLM or even if they're not,

We we still see lots of tests being generated that are very technical in nature, right? I called this function and then this function, and these were the parameters passed from one to the other. They're very internal behavior focused rather than input and output focused. And even when they are input and output focused, they don't feel like they're very product driven. They're very, yeah, this method that adds two numbers correctly added the two numbers together. But we don't say why it's a sum function or

how that function is supposed to operate. And I I I've definitely struggled. How do you convey that wisdom in writing the tests or making sure that future tests are written with this mindset in place?

speaker-1 (26:19.722)
Well, that's an interesting problem and the right problem to focus on. You have to start looking at actually your customer intent. And sometimes it's easy because if you have an existing customer base, lot of companies, actually most of the companies that we work with, they have over time built an existing customer base. So knowing your customer behavior, being able to analyze that and be able to create intent out of it is where like...

going to the original topic of RPA, it can help you as long as you can think of it as how is the customer using my product? Can I go ahead and record that behavior and mimic my test environments to be closer to it? Because at the end of the day, let's say I have 1,000 lines of code, just for example, right? And do I need to test all 1,000 lines of code if the path that all my customers use only exercises 250 lines of the code? No, right? I need to make sure that 250 lines of the code is well tested. It's great to test those others, maybe someday.

But what's my priority? Because at the end, always run the prioritization of stuff. So knowing how your customer uses the product and getting that closed loop is very important, right?

speaker-0 (27:23.704)
You it's interesting you bring up the the benefits here. And I I think this is maybe something that we didn't really get into. Historically, I think incorrectly a lot of organizations have applied the idea of the quality, the like the iron triangle to software development. And I I have this I have this link to this article, which I think is really good and jumps into, basically explaining how quality is not a trade-off with speed or or cost or features. It's

fundamentally you always get quality and quality enables these things. If you are tests, validate your code to do the right thing. When you make new code, you can ensure you aren't spending time on rework because there's a bug that was introduced. If you have tests, you we talked about this earlier, you're writing your architecture of your services or your platform in a way which is more maintainable. So future tests can be written or new code can be written easier. And I I find that these are just a

often misunderstood and organizations focus on, well maybe we don't need to test this as a extra effort with low ROI rather than understanding the implications of doing the test in the first place.

speaker-1 (28:33.166)
It makes a lot of sense. In fact, people don't realize that the hidden cost of quality burns up time all the way up to the top management in organizations. And the cost keeps going up and up, right? And so over time, if you don't focus on quality, you're really, really causing so much of, I would say, wastage in the organization of time and talent and opportunity cost. You name it, right? So many ways. So quality is spending anything on quality.

is never a wasted money, right? It's just that you have to find the right balance to do it in an organization, but do not make it as an afterthought. Make sure it's thought about like quality first kind of a thing that has been said before, right? Quality first has to be thought about it. But think about that, right? I tell people like when you write software, you use software in your day-to-day world too. Would you expect that when I go into an ATM machine and swipe my card, occasionally it doesn't work?

because somebody wrote a poor software out there? No, right? So just make sure even you write software, you also think that there are users out there who can be so frustrated or who could have problems with it, right?

speaker-0 (29:39.266)
I mean, having traveled to many countries, I definitely now do expect that there are some number of ATM failures when I'm out in the field for real. when I started my software engineering career a long time ago, I as soon as I started, I got so disillusioned and defeated. Like, wow, if software for this organization that is doing something critical is this bad, I don't trust it running anywhere, like doing anything. And it always amazes me when someone's like, yeah, we managed to put software on

I I think sa like vehicles that go into space like satellites are that have to live with the same code for a very long time that n never changes like the fundamental layers. Although a lot of organizations have figured out ways to to roll firmware updates and whatnot, but have to live without changes. when you deploy a device or like a consumer electronic that has a microcontroller that does something very simple, or like your oven or stove if there's a counter or some visual display in there. No one comes and services that code. It it literally works indefinitely.

ATMs are a little bit weird because often there's over-the-wire updates and whatnot for security protocols. But if we're really talking about these, I really hope my oven and dishwasher are not attached to the internet at this point. I wouldn't know if they're using some sort, maybe they have a 5G chip. I maybe I should be I should be checking that. of course I'm one of those people that's paranoid and my television's not connected to the internet, but I I I do I do worry about that in that particular world.

And with that, now is potentially a good time to switch over to picks for the episode. So Anu, what did you what did you bring for us today? I

speaker-1 (31:11.182)
At this moment, I'm really enjoying, like, it's just book that's been out for a while. I think people might have known about it. The book is called Genesis, right? It's about AI, right? And what's happening with artificial intelligence, hope, and the human spirit. It's, one of the authors is Dr. Henrique Singer, Eric Smid, and Craig Mundy. so that's very interesting because it talks about which are directions can AI take us. Like, it doesn't go into the technical aspects of it.

But it's more about the social impact. one of them is very interesting thing that says that if AI becomes too smart, for example, I don't give it the entire book, but if AI becomes too smart, then maybe we'll start to think of it as if it's like the old religion times where people just say, it's like gospel. If AI said it, must be true kind of a thing. So as humans, maybe can we go in that direction? So that was a possibility that brought up. So I'm just enjoying it. I really enjoyed it.

speaker-0 (32:09.75)
You know, on on my perspective on that is just so ridiculous because I I go back and I see all these like movies, television shows, et cetera, that always got like software hacking wrong. Like they don't understand how malicious threat actors actually work and practice today. And they're just, you know, someone typing on the keyboard and mashing things. And now I feel like it ha like the world has started to like life imitating art. Now

You want to hack something, you literally are like typing, you know, mad in a prompt to an LLM to say like how to hack the thing without actually doing the work. And I think now is more reminiscent of what the movies had sort of promised us is the experience. So I think we can just look to past popular culture of what happens in society when when the AI takes over. Obviously, there's the futuristic Dune perspective, right? Where all AI will have to be banned.

For one reason or another. or the lifeless automatons will take it as a goal to eliminate all all humans to solve a particular prompt gone wrong. No intelligence required, just a particular aspect. So I don't know. I think most of them are not not fun end of world scenarios. I think there was like a a book or an article about like the twelve different ways that humanity will end as a result of

speaker-1 (33:31.064)
No, this was the one that I showed was more on the negative side, but the book has the positive side. So it talks about all the possibilities. So that's why I love that book. So you can take a look at that book called Genesis. But yeah, I'm a believer. think as human race, with every new tech that has come, we have always progressed forward. And I think we'll harness the power of this to our benefits always. So I'm a very optimist on that front.

speaker-0 (33:59.666)
we could we could fight about this. There is like, you know, what is progress and who who gets the benefit of those technology changes. I think if that's an interesting topic, there is a book called Sapiens, which talks about yeah, which which actually talks about self-domestication of humans and what what what ha what has actually improved in humanity. And I say improved in quotes, because like that's up for you know you to decide. but that's not gonna be my pick. My pick is actually

This paper that was that just came out recently, I say recently, but it may be a couple years old at old at this point, about, well, here's the question. Is quantum mechanics required to dis to explain human consciousness? And my I'm I'm totally on board with the quantum theory of consciousness for a long time now. I think it can only be explained by quantum physics. I don't think classical physics is enough to explain like why we can have thoughts or why there's a consciousness or subconsciousness. And the paper basically, I'd say

almost proved it. it identified that there's a way to prevent the anesthetic, I think it's called isoflorane, basically from impacting our conscious brain. So even if you take the anesthetic, what they give you in a hospital if you're going to go under general anesthesia and it causes you to lose consciousness and unconsciousness. Basically the theory was does this block anesthesia isofluorane from being absorbed and block neuroreceptors in your brain from completing thoughts? And

The the test that was released or validated in the in the article basically said, no, we have a way of basically preventing the anesthetic from impacting humans, or in the in the experiment was mice, of course, or rats. You know, it's it's always rats, right? Mm-hmm. But it doesn't actually block the uptake. So what's going on there? And they theorize that it has to do with impacting the quantum states of something called I think it's the MT.

I I I don't remember. anyway, really interesting. It's very short, but I I I think this is why I can totally say LMs are not thinking today and will not have a consciousness in the way we've built them, because they only emulate it and they aren't capable in the technology that we're utilizing to support them to actual I had to make this about AI, didn't I? in the way to support them the technology that we're utilizing doesn't support quantum processes.

speaker-0 (36:24.012)
We don't give it the capability to do that. All computational natures that we have currently for computers, et cetera, are based on classical mechanics. I mean, of course, outside of quantum mechanics or quantum computers.

speaker-1 (36:35.054)
That's interesting and I'll just pick on the word currently because it's not but not yet is the answer or is it not the answer.

speaker-0 (36:43.99)
Yeah. well I mean can we really know anything? I think that's the the th the the theory of knowledge is is another particular definitely outside of the realm of relevance for this podcast, but interesting topic to discuss.

speaker-1 (36:57.016)
Yes. Well, it was a pleasure talking to you, Auran, today. And thank you so much for having me here.

speaker-0 (37:03.372)
Of of course I've enjoyed the conversation. Thank Anub for for joining us and thanks for all the listeners for tuning in to this week's episode and I hope to see everyone back next.