# AI Discipline: Reputation, Risk, and Sustainable Development

**Podcast:** The AI Native Dev - from Copilot today to AI Native Software Development tomorrow
**Published:** 2026-05-12

## Transcript

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 for developers and engineering leads at the cutting edge of AI and agentic coding.
Join your hosts, Guy Pajani, and me, Simon Maple, every week as we chat with the most exciting voices in AI and tackle the biggest questions facing developers today.
This is the AI Native Dev.
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-nated 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 Arc of AI and joining me is the wonderful Venkat Subramaniam.
And Venkat is one of the co-creators of this conference.
Venkat, a massive welcome.
How are you?
Doing great.
I love Austin.
I love food.
I love people.
Austin's the place to come for good barbecue, good food.
It is, right?
And I love technology.
And having them all in one place.
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 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.
Oh, imagine.
Imagine if there are only 23.
Let's talk a little bit about Arc of AI first.
Arc of AI, what does it mean, Arc of AI?
Yeah.
So with all the excitement around AI happening, we were sitting around talking among friends.
And the question was, how do we really...
bring some sense and discipline and practice into this noise that we hear around us.
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 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 can we sell you.
And so then the question is, We often talk about a narrative arc and there is 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, if I can say that as a young kid, there was this thing called object-oriented programming in the distance.
And then we saw people complaining about it, being really anxious about it.
And then the dust settled.
we started using object reprogramming, it became a foregone conclusion that we were building with OO.
And then you see this kind of a curve that happens for every single technology.
And there's nothing we do that doesn't go through that curve.
So with that in mind, my thought was, we're going to 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?
Somewhere...
still on the climb.
I think we're still in a 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, you know, praise you up on this, but really that's one of the things I've heard from people here is where they enjoyed, you know, the keynote that you and Varuj gave yesterday, 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 you or 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 not that we don't have discipline because we are unorganized or 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 that's kind of what these messages are, including the keynote and a lot of other talks.
How do you bring the 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 either create things faster than I would without AI, but also maybe even when I'm sleeping or when an agent can kind of like run in the distance while I'm doing other things.
But 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, do you know what?
I still want to slow it down a little bit.
by adding those precautions, that safety in, making sure we still have that CI, CD 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 solid production level coat.
Absolutely.
Somebody said this to me and I was like, you know, that's a way I never thought about it before.
But they said, you got a brake in a car so you can go faster.
And discipline actually makes you go faster.
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 got in right now is good enough to go to the next stage.
And to be able to have control of where we are taking this forward with the speed that AI gives us.
and the discipline we bring so that it's kind of like, you know, the 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 haywire in one direction or the other.
And I think we'll take time to learn more of those.
And honestly.
Between last year 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, you know, 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're refining, which is really the reason for us to be here.
And I think 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 really resonates actually because 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 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?
That's a really interesting observation.
I've definitely seen that.
And even in the hallway, what blew my mind is, 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 that's heartwarming because people are really engaging to learn which is the whole point of being here, right?
And I can see that energy in people taking the time to go deeper.
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.
They're not going to take the weekend, the long weekend.
And that's exactly the reason to be here.
I'm seeing that energy.
Amazing.
AI stands for artificial intelligence.
I know that's not you two.
No.
But you call it accelerated inference.
Yes.
Tell us what the distinction is and how someone, a developer, should mindfully...
know the difference?
So I think this is one thing that has at least helped me in working with AI.
So to me, an artificial intelligence elevates it to something of a being that I should respect and listen to.
And again, not that I'm disrespectful about lifeless things.
I'm not disrespectful to this so far, right?
I'm not going to put my foot on it.
But the point is...
An intelligent being, to me, deserves a higher level of respect.
Artificial intelligence is too much of a respectful term for me.
And I would accept it if that's what it was in my mind.
But to me, 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 a third person with a full-sleeve.
Oh, there's a fourth person with a full-sleeve.
and I ask you, what do people wear?
You're going to 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 I 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 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.
I wouldn't call ourselves an engine, but capable to infer in that regard.
So to me, AI stands for accelerated inference.
and not as much an actual artificial intelligence.
And I want to focus down on that piece that you mentioned whereby as a community perhaps our coding isn't the best.
I'm probably a good example of maybe some of the worst bits in that community code.
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 a...
from an AI agent and what we need to do about it.
Yeah.
So there are two issues here that I think we need to be really careful about.
The software industry is not as mature as a construction industry, for example.
Humans have been building structures where we live, where we reside for centuries.
If I'm building a house, 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'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 extremely risky.
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 going to expire.
When it begins to expire, unfortunately, it's the lawyers that's going to be stepping in because when lawsuits emerge, that's when we begin to pay attention.
And so 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 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 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 going to have to face that consequence later on.
And it's not going to be pleasant.
I've had, without AI, I have clients 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 called me up and said, hey, we know that you are an expert in the industry.
You're a third party.
No bias.
Sign 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 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 it breaks my heart when I see people do this.
And I have another client which got sued literally when their CEO was delivering a talk and saying, you have messed this up and here's 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 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 code reviews and using tools to perform those code reviews.
We can, of course, use AI as well to review the code.
It's our judgment.
We need to take that output and actually look at the code as well.
Use our judgment.
One thing that you mentioned was this interesting inversion where junior developers or less experienced developers will look at some code that's been output by AI and they'll go, wow, this is incredible.
It's magic.
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 there is that is that almost um widening the 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 it is not only widening that but 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 mean, I'll give you an example of this.
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 take care of some payment.
And so the person on the phone said, hey, here's the payment.
I've negotiated a discount.
And after the discount, we're going to pay this.
And I'm driving.
I don't have access to any device, right?
And I immediately said to the person, I'm sorry, I cannot verify what you said, but it's...
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 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 trusting that person.
But at the same time, 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 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 Venkat, 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 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 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 study in school, but we learn on the job, right?
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.
The extent you will challenge ideas in front of you, your ability to evaluate and discern between, you know, if you're a senior developer, you smell the right from the wrong.
You have that auto validation.
Yeah, that system that, yeah, that defense that builds into you.
And, you know, when I worked with senior developers as I was a young developer, that's one thing I would look and say, you know, from a mile, you are able to identify this is not going well, right?
You know, I remember 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 quote 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 going to work with them.
I'm like, okay.
So I drive across town.
I'm sitting in 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, Venkat, before I can show you this, I got to make a few changes.
And he's making some changes.
And I remember, right, I will 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 I just said to myself, and I 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 going to do this.
So I spent two hours because I'm really angry at what I'm looking at.
And I fixed this in two hours.
And then the next day he's looking at what I'm doing.
It's 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 to me, that is the sense, right?
That going from a junior to maybe a mid-level developer 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 yeah 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 things that you that you mentioned to people is you don't like one-shotting things in ai and i think you've mentioned to people try your best not to do that and it becomes more iterative people uh see that journey and can course correct more and more i guess As models and particularly agents become more capable, at what stage do you feel personally and for yourself, your own use of AI and also advice that you give other people, at what stage would you be comfortable to think, do you know what, particularly with the agentic environment, I'm comfortable with you going away, doing something, and then I'll have a look at what you do.
So let me bring in my...
Another definition of AI.
So to me, AI not only stands for Accelerated Inference, AI also stands for agonizingly inconsistent.
It's agonizingly inconsistent.
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, 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.
So you add the determinism as part of the iterations?
You are the one who brings...
control to the chaos.
And you have the speed, but at the same time you're saying, I like your speed, but I need at the end of the day still to verify.
And knowing what I know, to answer your question, at what stage will I be comfortable to say 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 as far as the things we have so far, we need to have human in the loop to do that verification.
We may be doing fewer iterations of verifications moving forward.
So maybe the answer to your question is, when that iteration distills down to one, is when I would have that confidence, maybe that's the way to put it.
And do you think that would be...
models and agents getting better?
Or do you think that would be more of kind of like as an environment that we create, maybe it's context, maybe it's skills, maybe it's something that can replace, not replace, but something that we can provide that will almost be 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.
Do you feel like that's part of a step that's missing?
Yeah.
So we can learn from other fields in that way, right?
I was talking to a builder recently.
And what I love about people is when they are very open, straightforward, direct, I really appreciate it.
So the builder said, you're going 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 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 letter 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.
That should know it.
And so rather than, well, skills are great 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 way?
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 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 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 agentic development.
Whether that's talking about the latest tools, the most efficient workflows, 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 favor and hit that subscribe button.
It really does make a difference and lets us continue to improve the quality of our guests and build an even better product for you.
All right, back to the episode.
I'd love to obviously hear 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 folks in organizations.
Seeing what people are building.
in AI today, what would you say are some of the biggest problems that people are building for to improve AI today?
Kind of cutting through the hype, but actually picking the real solutions to big problems.
What would you say they are?
Actually, that's one of the interesting part is it is quite vast.
And I'm really happy to see that.
For example, I've seen organizations really lean into AI for writing automated tests.
This is not just saying, I'm going to write automated tests for the sake of writing tests.
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 have better feedback loops.
They're using AI to identify errors, finding bugs in systems.
You take a code base and say, here's the issue I'm facing.
Can you tell me which area of code I should be able to see it in?
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've seen happen.
But why is that?
Because this gives you the ability to really go deeper into systems and understand AI is short-circruiting 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 AI is being used just about everywhere.
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 it's all over, which is fascinating and quite scary at the same time.
Absolutely.
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 agile, how to do agile well, all the way through to development really as a craft.
With 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 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've been teaching for 34 years at the university part-time, and I spent a lot of time with my students.
I really enjoy, I like to really help the next generation because I feel like I'm where I am because other people took the time to help me when I was younger.
It's my turn to give back to the next generation.
But I was on a train in Europe 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?
I'm irrelevant as an instructor with AI and all the things going on.
Should I just 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 principles.
I'm 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 way of teaching is very different from an orthodox or traditional instruction.
I do code reviews every single day.
And 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 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 he came back with a 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 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'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 $2 million for a project, but nobody is able to tell you why they need to implement the $2 million 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 going to crash and burn with the huge expenses moving forward.
I think that that question, the why question, is even more critical now than before, I think.
And if we don't train ourselves, so a good developer needs critical thinking.
A good developer needs courage.
You know, I feel intimidated, right?
Because, hey, I'm sitting next to a good developer, but I need to say, excuse me, can you tell me why?
And that person is good.
I mean, you know, I'm a consultant.
I go to companies.
I remember one experience.
I was in a company that was re-implementing their software to a newer, more modern language.
And they had a feature.
President of the company, this is a smaller company, 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're 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, I heard your explanation.
Let's go past it.
Why are we implementing this feature?
And people said a few things, and one guy got really angry.
What part of it's there already and we need it 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, all right, 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 know 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.
He was like, yep, 60% of the call is coming 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 going to keep insisting.
I'm sorry, but tell me why.
And to play devil's advocate, why couldn't AI pose those questions and try and answer them?
AI may not be...
capable to post that question.
But AI will answer those questions if you ask.
So 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 children always are fascinated.
They look at me and say, Dad, what do you mean there was no internet when you were a kid?
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, this is what surprises me.
People will come and ask me the question, and how do I do this?
I'll give them an answer by just doing a search.
And I always think, 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 created this for me, thank you.
Why are we creating it this way?
Why are we even solving this problem?
Can you tell me what are the risks and 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?
I would rather have a Simon agent than a Venkat agent.
Venkat is going to be really buggy.
I can tell you that right away.
It'll be more polite.
Venkat, let's jump into some quick fire questions.
All right.
So Venkat, 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 what I want people to know.
How can you make your efforts sustainable?
Tests first or vibe in iterate?
Tests first.
That was the easiest question.
That was easy.
Feedback loops.
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?
Vibe coding.
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.
Venkat, as an author of, I can't remember how many, let's say a thousand, let's round it to a thousand books.
What is a book that every AI native developer should read that has nothing to do with AI?
Wow.
I'm going to 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 actually, to be honest, wanted you on the podcast for a long time.
And to record the episode here at the Arc of AI conference in Austin has been absolutely amazing.
It's been wonderful.
Wonderful to do.
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 Arc of AI is probably the AI conference that has among the highest quality of sessions and speakers.
And attendees.
And attendees.
Hands down.
The conversation, actually when I got here and started chatting to people, I was starting to get worried thinking.
Am I, is my level too low, too high level for people here?
Luckily, I think I'm at a good level, but yeah, the quality of attendees is very, very strong.
So put it in the calendar for next year, Arc of AI in Austin, US.
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.
I appreciate it.
Thank you so much.
Thanks very much for listening and tune in to the next episode soon.
Bye for now.
The AI Native Dev is brought to you by TESL, the package manager for skills and context.
Your hosts are Guy Pajani and me, Simon Maple.
Our producer is Tom Dowler.
The AI Native Dev is not just a podcast, it's a community.
And we host monthly meetups at the TESL offices in central London.
Visit tesl.io forward slash community to learn more.
And I hope to see you there.