"AI Doesn't Stand for Artificial Intelligence" - Venkat Subramaniam's Take Will Change How You Think About It

You can delegate your work to AI. You can delegate your responsibility to AI. Your company cannot delegate the reputation to AI. Your company's reputation is their responsibility.

I wake up every morning, I ask a few questions in my head. Ethics, integrity, my responsibility. What do I sign my name on? If I don't take that as a responsibility for myself and if I work for a company where they don't care, I think we are in a bigger risk overall.

The AI Native Dev is a podcast with developers and engineering leads at the cutting edge of AIDENTICO.com. Join your host, Kai Fajani, and meet Simon Maple every week as we tower the most exciting questions in AI and tackle the biggest questions of Facebook developers today. Back in November, we hosted the first ever in-person AI native DevCon in New York.

This June 1st and 2nd, we're bringing it to London. It's two days built for AI native developers and engineering teams. One day full of hands-on workshops, and one day full of practical talks on agent skills, context engineering, agent orchestration and enablement platforms, and how teams are actually shipping AI in production. Join us at the brewery in London near the Barbican for all of that, plus networking, parties, giveaways, and a room full of people building the future of AI native development.

You can also join us from anywhere in the world via the live stream. As you're listening to this podcast, you get 30% off your ticket with code pod30. Just head to aiNativedevcon.io and we'll see you in London.

Hello and welcome to another episode of the AI Native Dev Podcast. And we are here in Austin live at Ark of AI, and joining me is the wonderful Vencat Supermanium. And Vencat is one of the co-creators of this uh conference. Venkat, a massive welcome.

How are you? Doing great. I love Austin. Yeah.

I love food. I love people. Austin's the place to come for good barbecue, good food. It is, right?

And and I love technology. Yeah. And having them all in one place. And and Venkat, you are, by day, you are an incredible author.

You're a wonderful teacher, both as a professor, but also at incredible conferences just like this and around the world. You teach courses, you you inspire people to learn about programming and now a lot about AI, right? How do you find the time, number one? Thank goodness there's 24 hours in a day.

Let's talk a little bit about Arc of AI first. Um Arc of AI, what does it mean, Arc of AI? Yeah, so so uh with all the excitement around AI happening, uh we were sitting around talking uh among friends, and and the question was, you know, how do we really bring some sense and discipline and uh practice into this noise that we hear around us? And and one of the things that we are very fortunate, collectively, I'm saying, is that we have a community of developers who are not only really good in development, but who are good in speaking as well.

So the thought was what if we bring those developers to form a conference that's focused on AI, but we don't want this to be uh AI by the marketing of the large organizations. That's one of the reasons why the speakers in this conference are practitioners and not from the AI companies that are trying to sell you a product. That makes a huge difference in terms of the content they bring because they are talking about how do we use this rather than what we can sell you. And so then the question is uh there is, no, we often talk about a narrative arc, and there is uh a trajectory through which we go through as a technology curve.

I've been programming for about 40 years. When I was a young kid, uh if I can say that as a young kid, uh there was this thing called object-oriented programming in the distance. And then we saw people complaining about it, being really uh you know anxious about it. And then the dust settled, we started using object-oriented programming, it became a foreground conclusion that we'll be building with uh-oh.

And then you see this kind of a curve that happens for every single technology. And then there's nothing we do that doesn't go through that curve. So, with that in mind, my thought was we're gonna go through the same curve for AI as well. So hence the arc of AI.

And where would you say we are on that arc? Umwhere still on the climb. Yeah. Uh I think we're still in the lot of hype cycle, but at the same time, I also think that we are also beginning to make sense of what works and what doesn't work.

And I'm not trying to price you up on this, but I really that's one of the things I've heard from people here is is where they enjoyed the keynote that you and Baruch gave us today, where you are really providing that cautionary tone as to there is power here, but we need to bring that. The word I would summarize your keynote is, to me, this is an important word, is the word discipline, right? To me, the problem in software is not we don't have a technology, we have a lot of it.

The problem is not that we don't have people, we have a lot of good people. The problem is we don't have enough discipline. And and not that we don't have discipline because we are, you know, unorganized or you know, negligent. We don't have discipline because there is so much pressure that takes focus away from discipline, and then it comes and bites us in the back.

And that's when we begin to realize, okay, let's slow down and see, you know, it's kind of like driving, right? You can drive fast, but if you're a disciplined driver, you don't get there fast, but you also get there safer. And then that's kind of what you know, these messages are, including the keynote and a lot of other talks, is how do you bring that discipline into what we do? So I think we are in the face of the curve where we have launched, but now we are thinking about sustainability.

We are thinking about how can we get results from this rather than, sorry to mention, this curve being like an Aryan spacecraft that crashes back on Earth, but to be able to launch really and succeed. And it's interesting because AI, one of the great benefits of AI is the speed it gives us in terms of I can you know either create things faster than I would without AI, but also maybe even when I'm sleeping or when I'm you know when an agent can kind of like run in the distance while I'm doing other things.

But it's it's not just about can you do something quicker, it's about can I do something quicker, but also have that discipline to be able to say, but you know what, I still want to slow it down a little bit by adding those precautions, that safety in, but you know, making sure we still have that CICD processes because that's what as software engineers, we know these are the safety nets that we require to actually be able to deliver and produce a solid production level code. Absolutely.

Somebody said this to me, and I was like, you know, yeah, that's a way I'd never thought about it before. But but they said you gotta break in a car so you can go faster. And and discipline actually makes you go faster. And and and I think to your point, right, to bringing in CICD, to bring in reviews, to bring in those stage gates, to say, I am confident that where we've gotten right now is good enough to go to the next stage.

And and to be able to have control of where we are taking this forward with the speed that agility, with the speed that AI gives us, and the discipline we bring, so that's kind of like you know, the the the the you know homostasis, right? So you don't want to tilt in one direction and you lose the center of gravity. So maybe the speed of AI and the discipline we bring stabilizes and gives us that center of gravity. So we are able to stabilize and move forward rather than you know go, hey, wire in one direction or the other.

And I think we'll we'll take time to learn more of those. And and and honestly, between last year where when we ran this conference and this year, I have to tell you that I'm noticing two things very significant. The topics are a lot more mature, and also the developers are a lot more curious and interactive. I felt like last year they were in, let me listen mode, but this year they are in more of an interactive mode.

I've been sitting in a few talks, uh, whenever I'm able to do, and one of the things I am absolutely enjoying, in addition to the presenter giving the talk, is the questions that people are asking. And that says that they're not just listening, they're bringing their current experience, and then either they're validating or they are refining, which is really the reason for us to be here. And I think that that's the that's where the curve is, is that we are going to the next phase or next stage in this where we are going beyond, let me find out what it is to, let me see how I can apply it.

That's that really resonates actually, because uh a number of the questions and discussions that I had, people were taking the topic and going, okay, this is how I'm using AR. I'm using Windsurf. Can I use this with Windsurf? And they're actually trying to, they're they're trying to work out what they can take, the gems that they can take, and how do I apply that into my existing environment?

What does it replace? What can I use it with? And that's a really interesting observation, I've definitely seen that. And even in the hallway, what blew my mind is, you know, as I was walking, somebody said, Hey, hang on a second, I got a question for you.

And then the question rolls into, this is what we are doing at work, and I'm trying to scale what we are doing, how would you approach it? And then that started heartwarming because people are really engaging to learn which is the whole point of being here, right? Uh, and and and I keep I can see that energy in people taking the time to go deeper, and and they're eager, I can see it. They're eager to take that back and apply it on.

I bet some of these people are going to go back to work on Friday. Yeah. They're not going to take the weekend, long weekend. And and I that's exactly the reason to be here.

Yeah. I'm seeing that energy. Amazing. Um, AI stands for artificial intelligence.

I know that's not new to you. No. You call it accelerated inference. Yes.

Tell us what the distinction is and how someone, uh, a developer, should mindfully know the difference. So I think this is this is this is one thing that has actually at least helped me in in working with AI. So to me, an artificial intelligence elevates it to something of a you know, a being that that I should respect and lose into. And and again, you know, not that I'm disrespectful about you know lifeless things.

I'm I'm not disrespectful to this sofa, right? I'm not gonna put my foot on it. But but the point is, an intelligent being to me is deserves a higher level of respect. Artificial intelligence is too much of a respective term, respectful term for me.

And I would accept it if it that's what it was in my mind. But but to me, if I if I tell you, if you look around here, right, and if I tell you, oh look, that person is wearing a full sleeve shirt, oh, so does the person next to, oh, there's the third person with the full sleeve, oh, there's a fourth person with full sleeve, and I ask you what do people wear, you're gonna say, gosh, they wear full sleeve. So in other words, inference is neither right or wrong, but inference is based on the data that's available.

For us, the programmers, code is the data. Well, the problem is not that AI has not been trained, the problem is AI has been trained a lot on a lot of code. And I don't think you need to really convince any human to, you know, say, do humans in general, you know, overall, every single human put together, do we write really good code or do we write terrible code? I think most of us will agree we write terrible code as humans.

We have done that. And the reason is we have really struggled to write high-quality code. But AI has been trained on that vastness of code. So when you ask it to infer, it doesn't know to infer from the good parts and leave out the bad parts.

So the inference is cumulative on everything it's seen. So this is one of the reasons why you see it generate code. It generates either code that doesn't compile or doesn't work properly, or the code appears broken. And why?

Because the phrase I want to use is look what the dog just dragged in. Well, it's not that you like what it dragged in, but that's what it found in the backyard. So I think that's why you call it an inference engine. It's an accelerated inference.

You and I infer a lot, but our capability to infer is limited not by our availability of data, but our ability to consume that information. We can only can hold so much at a time. So machines will always be faster than humans. That's where the acceleration comes in.

And so it's an accelerated inference engine. We are just maybe a little bit more of a refined but slower inference, you know, uh, I wouldn't call ourselves an engine, but capable to infer in that regard. So to me, AI stands for accelerated inference and and not as much an accelerate uh artificial intelligence. And I wanna I wanna focus down on that piece that you mentioned whereby as a as a community, perhaps our code, our coding isn't the best.

I'm probably, you know, a good example of maybe some of the worst bits in that in that in that community code. Um but ultimately when we get bad code from AI, I think you referred to it in the past as this is karma. This is like the years of our bad code that we are providing, we're getting it back now. So I guess what does that tell us about, I guess, number one, the state of the industry, but two, how we as developers should think about the output of the code from an AI agent and what we need to do about it.

Yeah, so so so there are two issues here that I think we we need to be really careful about. Uh the the software industry is not as mature as uh uh uh as a construction industry, for example, right? Humans have been building uh you know structures where we live, right, uh where we reside for for centuries. Uh if I'm building a house, uh I can't just grab somebody out of the street and say, build this house for me.

The county will not allow that to happen. The county sends inspectors, they inspect multiple faces multiple times. The reason is there is there's a concern of loss of life. If a beam here, right, we're sitting in this beautiful building, but if the beam above you were to fall, that's that's extremely risky.

And and so to me, there are consequences to what we do. The software industry, because it's relatively new and it's been accelerating, we've been enjoying a lot more leniency, but that's that's gonna expire. When it begins to expire, unfortunately it's the it's the lawyers that's gonna be stepping in, because when when when lawsuits emerge, that's when we begin to pay attention. You know, and and and so what are we what have we done so far?

Even though the quality of code we write as humans is not great, we typically balance it out on teams where people can create things, but then there are other team members who constantly review them and also rework and refactor. So one of the things we have been doing for the past about 20 years is we write code, but we continuously refactor code. Why are we refactoring code? Because the code we wrote, not because entirely of our fault.

A lot of times we don't know where we are going, and so when we get clarity on it, we have to rework the code, we refactor it. So that's how we've been coping with that. But but in that regard, the speed at which humans are able to write code is in pace with the speed at which humans are able to review code. But when the speed of generating code increases and the ability for us to review is still the same, I think we're in bigger trouble.

And that's where we need better tools to review the code as well. So the maturity in this regard has to be that we as humans still need to take the responsibility. I cannot tell my company, don't ask me to take responsibility anymore because I've delegated this to AI. You can delegate your work to AI, you can delegate your responsibility to AI.

Your company can delegate work to AI, your company cannot delegate the reputation to AI. Your company's reputation is their responsibility. So we can, we want, so the question is, how can we delegate effort without throwing our hands up and saying I'm not responsible anymore, right? And if we don't, there are consequences to it.

This is where I was talking about. One of the things businesses have to really think about is not the speed at which we can go. Speed is important, not the speed at which we can go, not the money we can save, but what is the cost of failure? And if I don't understand the cost of failure for what I produce, then I'm gonna have to face the consequence later on, and it's not going to be pleasant.

I've had without AI, I have I have clients that I've that I have directly worked with where they have been in lawsuits because of poor quality software they have created. Personally, I have served on three lawsuits so far where I've served as an expert witness. A company suing another company because of poor quality software. They call me up and said, Hey, we know that you're an expert in the industry, you're a third party, no bias.

Signed this agreement, we have not told you what to say, and then they present me the code and they say evaluate it and present your findings, and that's what we're going to take the code of law. And I'll tell you, in one case, it was unbelievably low effort for me. Because all I had to do was go to the organization that has this library and get the page of do's and don'ts and show that every do they didn't, and every don't they did. And and it breaks my heart when I see people do this.

But and I have another client which got sued literally when their CEO was delivering a talk and and saying, you have messed this up, and and here is a summon to appear on the court. And when your company's reputation, in addition to money, is jeopardized by poor quality of what you produce, your business people are going to be responding differently. So at that time they come back and say, fix this. And I think it's our responsibility as to me, a programmer, we are not coders.

We are professionals. I wake up every morning, I ask a few questions in my head. Ethics, integrity, my responsibility, right? What do I sign my name on?

And I think that is very important. And and I if I don't take that as a responsibility for myself, and if I work for a company where they don't care, I think we are in a bigger risk overall. And I think you mentioned a couple of things there, including the code reviews and using tools to perform those code reviews. But we can of course use AI as well to review the code.

And it's our judge, you know, we need to take that out and actually look at the code as well, use our judgment. One thing that you mentioned was uh this interesting inversion where junior developers or less experienced developers will look at some of the code that's been output by AI and they'll go, wow, this is incredible. It's magic. And then you look at senior developers who will look at the same output and they'll hate it.

They'll know what it should do, they know what they would expect and they can say, This is wrong, this is wrong, this is terrible. Um so there's this gap over there. Is is that is that almost um widening the gap between a junior and a senior developer if they're not necessarily learning but being exposed more to that and assuming that's the right way, is this widening the gap between between those two? It is not only widening that it certainly is widening the gap.

But I think the risk is even higher. And to me, one of the biggest challenges today is if the tools lead us to turn into consumers of the code and in the process if we lose our critical thinking that is a dangerous situation to be in. Because I'll give you an example of this. This is you know calculators are great.

I love it. But I'll just give you one example of this. I was driving one day and we had to come we had to you know take care of some payment. And so the person on the phone said hey here's the payment and I've negotiated a discount and after the discount we're gonna pay this.

And I'm I'm driving I I don't have access to any device right and I immediately said I said to the person I'm sorry I cannot verify what you said but it doesn't sound right. Could you please run the numbers again one more time and tell me if after applying discount it would be this amount and there was a pause and then they came back and said no you're right I I had a round calculation here's the number I'm like okay that makes me feel better. So the key here is for me to process that in my mind and say I'm validating right I'm I'm I'm trusting that person but at the same I'm validating to saying hey I'm capable of making mistakes so are you let's validate it.

But if I don't think about it critically we would have sent a higher amount as payment and and that would have cost other things. So the key here is at every step we need to develop the capability to check and double check and say is this actually correct? Is this the way we need to do and for that AI can replace our effort but AI cannot replace our knowledge. I don't have knowledge in chemical engineering I can write all the code you want me to write but a chemical engineer literally comes down and tells me oh Vancat we never want to do that for hydrocarbons and I say thank you for letting me know that because I don't have that knowledge.

But an engineer has that knowledge but imagine you remove that engineer out of the picture for a minute I would be writing the code which is not going to behave correctly for a hydrocarbon. Now replace me with something faster which is the AI. And if you don't have that engineer it's dangerous what you're producing. So it's not that I was perfect but the key here is I had people around me who would do the verification.

And while I write the code they make sure I'm not writing rubbish. And in the same way the person who is using AI, if it's a senior engineer, senior developer, they're able to evaluate and say, yeah that that is good or in this case that's not adequate so I'm going to reiterate through it a few more times. It's not like they have to abandon this and do the job by hand but they have the smartness in their head to reiterate until it gets to where it needs to get to versus a junior engineer who never had that benefit to get trained by a senior developer, right?

One of the things I said in my keynote is something I've been learning for myself is we we study in school but we learn on the job. In school we read about stuff but the real learning happens when you apply them and so when I'm at work when I'm doing things I go to my colleague and say I'm writing this code this way what do you think of this design? And they critique it for me. And then I do that for somebody else and we collectively learn from each other.

And then that's what makes you a senior developer. To me a senior developer is not an age. A senior developer is not the number of years you have counted the senior developer to me is the extent to which you will push back. Yeah the extent to you will challenge ideas in front of you your ability to evaluate and discern between you know you you you if you if you're a senior developer you smell the right from the wrong you have that auto verb auto validation yeah that that system that kind of surprise that that defense that builds into you and and uh you know when I worked with senior developers as I was I was a young developer that's one thing I would look at and say you know from a mile you are able to identify this is not going well right um you know I I remember uh I was working for a company that acquired another company and I didn't say this to people because you don't want to insult people so I go in and sit down and this is a code I know nothing about right and my boss said go over there this afternoon spend some time with them because in two months you're gonna work with them I'm like okay so I drive across town I'm sitting in this this guy's office not knowing anything about the system right and he says let me show you how things work and then he is showing me the screen and he says oh hang on a second before I can show you this I got to make a few changes and he's making some changes and I remember right I would never forget this I remember sitting in his office and saying I don't have a clue what he is doing but I can tell you he's wrong.

So so I just said to myself I don't want to insult this person right because I don't know anything. I have nothing to prove fast forward four months I am working on that code and I hit the same spot and I'm like heck no I'm not gonna do this. So I spent two hours because I'm really angry at what I'm looking at and I fix this in two hours and then the next day he's looking at what I'm doing is like oh my gosh we've been struggling with this how in the world did you fix it? And I said you know what I got angry looking at it and I wasted some time and here's a solution I was like darn it we never thought you could do this and and to me that is the sense right that that going from a junior to maybe a mid-level developer to to say I don't know enough about it but I can tell you it's not right.

And I know it can be improved as a person using AI I need to have the sense to say this is good. Oh you know what this can be improved oh no we don't want to go in this direction at all no thanks AI let's redo this and that's interesting because I think one of the uh things that you that you mention to people is you don't like one-shotting things in AI and you can and I think you have to mention to people try your best not to do that and it becomes more iterative as people uh see that journey and come course correct more and more I guess as models and particular particularly agents become more capable at what stage do you feel personally and and and you know for yourself your own use of AI and also advice that you give other people at what stage would you would you be comfortable to think you know what this is particularly with the agentic uh agentic environment I'm comfortable with you going away doing something and then I'll have a look at what you so let me bring in my another definition of AI so to me AI not only stands for accelerated inference also stands for agonizingly inconsistent it's agonizingly inconsistent and and I think at the end of the day this is something you mentioned quite a bit in your keynote this is the difference between what we in software development have dealt with until yesterday so to say and the new norm is going from a deterministic world to a non-deterministic world and essentially when you live in a non-deterministic world this is the it's it's really a trade-off your trade-off here is you can go slower and deterministic or you can go faster and non-deterministic you are the determinism is part of the iterations you you have you are the one who brings control to the chaos and and you you have the speed but at the same time you're saying I I I like your speed but I need at the end of the day still to verify and knowing what I know to to answer your question at what stage will I be comfortable to say I'm I'm okay with it I don't know that yet because I haven't seen enough to with what exists today to say I'm ready to give that to the AI.

So I so as far as the things we have so far we need to have human in the loop to to do that verification. We may have we may be doing fewer iterations of verifications moving forward. So maybe the answer to your question is when that iteration distils down to one is when I would have that confidence that maybe that's a way to put it and do you think that would be the models and agents getting better or do you think that would be more of kind of like as an environment that we create maybe the context maybe the skills maybe the something that can uh replace not replace but something that we can provide that will almost be a an automated us in the loop where if it's a skill maybe that says no actually remember you need to do it this way or some automated verification.

But do you feel like that's part of a step that's missing? Yeah so so if we can we can learn from other fields uh you know in a in that way right uh I was talking to a builder recently and and and what I love about people is when they are very open straightforward direct I really appreciate it. So the builder said you want to tell me where to put an electric plug point and my answer to you will be yes or no and I love it and and I kind of looked at him and said not being rude he said when I say yes I will put the plug point where you want me to put it when I say no it's because the code will not allow me to do it.

And if you tell me no I'm the one who's paying you do it guess what happens if there's a fire and you don't get sued I get sued because I'm the one who built it and I said I respect your professionalism here. So where I'm getting to with this is skills are great but what if eventually we can help AI learn what that skill should be for code generation? What are the universal do's and don'ts? What are the things like for example right I think most of us can agree writing a meaningless single error variable is a terrible thing to do.

I showed some examples during my keynote today. The variable name was C. I scream at my students when they write a variable called C. I don't think I need a skill to tell AI don't be stupid right that should know it.

And so rather than well skills are great as a as an intermediate step. I cannot imagine five years from now we are sitting and writing skills I want AI to not only train but to be trained on what are the good practices what are the disciplined ways and and if there can be a way to coach AI to know the risk to understand the ways to write code for it to know if I write code this way and if I were to modify this code in the future to handle something else it's going to interfere and and to understand the software is a nonlinear system we know this.

AI needs to also realize it's a nonlinear system. So the actions it takes in one area has impact in another area and and if if AI can be trained to be more vigilant about the risk it is introducing into software I think at that time we'll have more maturity and fewer iterations I think. Hey everyone hope you're enjoying the episode so far. Our team is working really hard behind the scenes to bring you the best guests so we can have the most informative conversations about identic development whether that's talking about the latest tools, the most efficient workloads or defining best practices.

But for whatever reason many of you have yet to subscribe to the channel. If you're enjoying the podcast and want us to continue to bring you the very best content please do us a favour and hit that subscribe button. It really does make a difference and let us continue to improve the quality of our guests and build an even better product for you. Alright back to the episode I'd love to obviously you're someone who is very deeply entrenched in the community particularly around this conference but just generally you know you're talking to a bunch of different individuals indie developers as well as as well as folks in organisations seeing what people are building in uh in AI today what would you say are some of the the biggest problems that people are building for to improve AI today kind of cutting the hype cutting through the hype but actually you know picking the real solutions to to big problems what would you say they are there are there actually that that's one of the interesting parts is uh it it is quite vast and and I'm really happy to see that.

You know for example I've seen organizations really lean into AI for writing automated tests. This is not just saying I'm gonna write automated tests for the sake of writing test. These are real issues they are trying to address where they have developed software for the past 10 years and there are issues they're not able to find the defects in the code because their customers are angry because these defects are significant but the team is not able to figure out because the code is complex and they didn't write the original code and they're using AI for writing tests so they can give have better feedback tools for feedback loops.

They're using AI to identify errors finding bugs in systems you know you you take a code base and say here's a here's an issue I'm facing can you tell me which area of code I should be able to see it in the root cause analysis style approach to an issue and and it's able to pinpoint and say look over here right this would take months on end for humans to go you know one of the things you I mean I'm sure you you know you've seen this quite a bit when you hire somebody new you often put them in QA and say learn to fix bugs because that's when you learn the system then you come to development right this is a traditional thing that we have seen happen.

But why is that? Because this gives you the ability to really go deeper into systems and understand AI is short circuiting that. So you're able to look at defects much more quickly I've seen that quite a bit in companies I'm a consultant so I get dragged into companies I didn't write this code I don't even know who they are until I walk into the building and they're saying here's an issue fix it. And they're using AI to reason about the code to explain what a piece of code is doing so they can understand better.

They're using AI to refactor code. They're using AI to evaluate the quality of design I know a set of financial organizations that is using AI to create and refine their architecture. So I'm looking at an entire vertical in which AI is being used. I see design engineers use AI.

So so AI is being used just about everywhere and and I'm seeing this in companies when I walk in it's a question of where are you using AI and what's your use case and and it's it's all over which is fascinating and quite scary at the same time. For decades now Venkat you've been teaching expert developers all the way down to junior developers people going through universities as well what it means to be a really good developer, a solid developer everything from you know agile how to do agile well all the way through to you know development really has a craft with uh AI now does this change things in terms of what it means to be a good developer what needs to kind of stay what is the kind of things that we need to learn in addition to be a good developer.

Yeah I love that question because I'll be absolutely honest about it. There are times you wake up and you doubt yourselves right it it it is it is important that we doubt ourselves because otherwise we never improve what we do. And I'll be honest about it this was about two months ago I I I've been teaching for 34 years at the university part-time and uh and I spent a lot of time with my students I really enjoy uh I I like to really help the next generation because uh I feel like I'm where I am because other people took the time to you know help me when I was younger it's my turn to give back to to the to the next generation but I was in a train you know in Europe a couple of a couple of months ago and I was kind of looking out the window just thinking about stuff and I asked myself am I relevant?

Am I relevant as an instructor with AI and all the things going on should I just you know throw in my towel and say thank you for this but I don't need to teach anymore the students can learn from AI. And then I realized I'm actually more relevant today than ever sure I'm teaching them dependency inversion principle. Sure I'm teaching them dry principle I'm sure I'm teaching them single responsibility principle. But if you set that aside for a minute what I'm really teaching my students and my le my my my way of teaching is very different from an orthodox or traditional instruction I do quote reviews every single day and I I you know spend three hours critiquing my students' work every day.

And what I'm teaching them is time management. I'm teaching them when to go deeper and when to park something and come back. I'm teaching them to push back so this semester for example right I gave them a problem they were solving and a set of students said why don't we solve it this way I said no no no no solve it this way and and and they did and then a week later a student came back and said I don't get it why are you telling me to solve it this way instead of this way and I said explain to me why you say this and and he and he came back with reason I said that's why you did not push back you just accepted what I said and I wanted to wait and see how long you go in the wrong path and you came back and pushed back and you were one among that many students who pushed back.

And this was a learning experience for all of us and and and that's what I've been really helping my students to learn is that aspect of critical thinking. So to me a good developer is not the one who can you know show that they know all the libraries all the frameworks all the things in the world a good developer is the one with good critical thinking where they can sit down and say wait a second you know I I'll be honest about it. I go into companies and I seriously ask them can you explain to me why you are doing this and you would be surprised at times when no one they have literally committed two million dollars for a project but nobody's able to tell you why they need to implement the two million dollar solution.

And to me that is the key And that doesn't change now that's just as important before and after more important now right because the speed at which we are going is much faster now and if we forget to ask that why we're gonna crash and burn with the with the huge expenses moving forward. I think that that question the why question is even more critical now than before I think and and if we don't train ourselves so so a good developer needs critical thinking a good developer needs courage you know I I feel intimidated right because hey I'm sitting next to a you know good developer but I need to say excuse me can you tell me why and and that person is good I mean I you know I'm a consultant I go to companies I I remember one experience I was in a company that was re implementing their software uh to a newer More modern language.

And they had a feature. And the and the president of the company, this was a smaller company. The president of the president of the company is sitting in the meeting. And everybody else is there.

And they were talking about a feature. I'm the consultant. I don't know anything about their product. These are people who have been working with the product for a long time.

And I said, Can you tell me why you are implementing this feature? Oh, the current version has it, so we need to implement it because we're just modernizing the application. Thank you. Can somebody in the room explain to me why you're doing this?

As I just said, the product has this feature, we need to implement it. Like, no, no, no, I heard your explanation. Let's go past it. Why are we implementing this feature?

And a few people said a few things, and one guy got really angry. What part of it's there already, and we need it that doesn't reach you. I'm like, oh my gosh, that's really rude. And if you don't want to answer, just tell me you don't know, that's fine.

And we were kind of going back and forth with this. And suddenly the president of the company who was in the room got up and said, Alright, I want somebody in the room to answer that question. So now the boss wants the answer, right? And everybody is quiet.

Nobody could answer it. And he then said, Who in this room knows that 60% of support call we are getting is on that feature? And I'm like, definitely I don't know that because I'm new to your company. And everybody's like, oh.

It's like, yep, 60% of the call is coming from the feature, from that feature. And nobody in the room ever questioned it. And now that that question has come up, it just dawned on me, it shouldn't even be here. I know exactly how to take care of that need outside, and all of a sudden we don't have that 60% of the problem we are having.

So he walked up, put a little rectangle around it, crossed it, and said, this will not be in the new product. To me, again, right, I am not the best person in the world, not the smartest person in the world. But to me, if I don't understand why, I am the stubbornest person on your team. I'm gonna keep insisting.

I'm sorry, but tell me why. And to play devil's advocate, why couldn't why couldn't AI pose those questions and try and answer them? Uh AI may not be capable to pose that question, but AI will answer those questions if you ask. So you you you you hit on something that I've been fascinated by for the past 20 years, and I think this only became more interesting.

When I was a kid, I had to know the answers. You know, my my children always are fascinated. They they look at me and say, Dad, what do you mean there was no internet when you were a kid? You know, there was no Google, there was no browser when I was a kid.

And I had to know the answers. All of a sudden, for the past 20 years, I had to know the questions and not the answers. If I don't know the right question, and again, you know, this is what surprises me. People who come and ask me the question, and uh how do I do this?

I'll give them an answer by just doing a search. And I'll always say, why am I able to search and why didn't they search? Because they didn't know how to ask the question. With AI, it's even more critical we know how to ask the right question.

So if you were asking the right question, you're saying, hey, you evacu you created this for me, thank you. Why are we creating it this way? Why are we even solving this problem? Uh can you tell me what are the risks in the solution you just created?

If you're able to ask those questions, AI has those answers. It just doesn't tell you. Yeah. Because it's not thinking of those questions.

And another, maybe a better way of using AI today in this kind of sense is to have, because I always think AI is great when it's almost critiquing and like having AI. Maybe I'll create a Venkat agent that asks me why and asks me these types of questions to understand and makes me think, you know, forces me to learn this muscle of why are we building this? What is- I would rather have a Simon agent than a Venka agent. It'll be more polite.

Venka, um, let's jump into some quick fire questions. Alright, so Venka, what's the conversation you most want developers to be having right now that they're not having? The most important conversation I think developers should have is how can we be more sustainable in developing products where we can deliver value while reducing the risk and creating the financial success for companies? You know, oftentimes I ask questions, I ask people, you walk into a company, why are you here?

What value do you produce today? If I cannot answer that question, I'm in the wrong place. So I think that's that's what I want people to know. How can you make your your efforts sustainable?

Tests first or vibe and iterate? Test first. That was it, that was the easiest thing. That was easy, that was easy.

Uh uh feedback loops. Yeah. If I if you know, I was thinking about it this morning, honestly. If I don't know where I'm going, it doesn't matter where I end up.

Test gives me the direction. What's one thing AI will never replace in a good developer? The passion for what we create. Nice.

What is the most overrated AI trend right now? Vibecoding. What's the most underrated AI trend right now? Seriously, I would say it's ability to really identify issues and analyze risk.

I wish we are talking more about it and not more about where it's not good. Let's spend more time focusing on what it's good at. I think we wish I wish we did that more. Yeah.

Nice. Then Kat as an author of I can't remember how many. Let's let's say a thousand. Let's round it to a thousand books.

Um, what is a book that every AI native developer should read that has nothing to do with AI? Wow. I'm gonna talk about a book I've read a few times. One of my favorite books because every one of us needs to clear our mind from time to time.

So the one I recommend always is Who Moved the Cheese? Who moved the cheese? A great book, such a good book. Awesome, Venkat, this has been an absolute pleasure and to to I've actually to be honest, wanted to join the podcast for a long time and to to record the episode here at the Ark of AI conference in Austin has been absolutely amazing.

It's been wonderful, wonderful to do that. Thanks for joining. Thanks for making this a very good event, and I enjoyed and I can't tell you how appreciative I am. Amazing, and actually to those listeners, I would say Ark of AI is probably the AI conference that has among the highest quality of sessions and speakers.

Uh and attendees. And attendees. Hands down. The conversation actually when I when I when I got here and started chatting to people, I was starting to get worried thinking, am I is my level too low, too, too, you know, high level for people here?

Luckily, I'm I think I'm at a good level, but the yeah, the quality of attendees is is very, very strong. So put it in the calendar for next year, Arc of AI in Austin, US. Uh, definitely one for your list to attend. Venkat, it's been an absolute pleasure.

Let's go enjoy the rest of Arc of AI. Thank you, Simon. Thank you so much. Thanks very much for listening and tune into the next episode soon.

Bye for now. The AI Native Dev is brought to you by Tesla, the package manager for skills and content. Your hosts are Guy for Johnny, and me, Simon Maple. Our producer is Tom Dow.

The AI Native Dev is not just a podcast, it's a community. We host monthly meetups at the Tesla Office for Temple Learn Office. This is Tesla.io forward.

community to learn for the code.