AI-Assisted App Development: Speeding Up Code & Solving Problems with Bryan Liles
Transcript
All right, you're listening to episode we don't count episodes here because we're not like that. You're listening to another another episode of the CTL Advisor podcast. Return guest, I haven't had him on in a few years because he's been busy. One, standing me up for this conversation on AI application development. And then two, he has a pretty important day job building some of the world's biggest cloud solutions during the day. Brian Lau, Brian, welcome back to the program. Keith, thank you for having me.
And actually I do want to say a public apology for standing you up. I got busy into something and then 15 minutes into the time I looked up and said, "Oh my god. " if I'm not guilty of that at least two or three times a week I'd be lying. There's a whole There's this whole story around this new generation of workforce coming in who don't respect time. We'll get into that another day. But what I did want to spend some time talking about is this concept of AI assistant application development.
You develop a lot of code. You've developed a lot of code over your time. And I noticed on, you know, the socials that you're I think it's safe to say you're a proponent of AI assistant application development. Oh yeah, of course, 100%. And I use AI when appropriate. I would say just about every single day. And before we get deep into this conversation though, I have a I have a way of looking at this that might make sense to folks who aren't really well versed in this area.
Uh years ago at the advent of cloud we had the same conversation. Why would I want to use someone else's computers? I can put servers in racks and data centers. I can't configure my networking, and I can do all the things. Yeah, you can. But what we found out with cloud is that it gives more people more access to more flexibility when it comes to deploying infrastructure. And it allows us to make mistakes and say we're going to go on a wholly different method.
But, you know what? Uh it's still there. And I look at it the same way as I look at uh when it comes to using AI in coding. I still can write code in many handfuls of languages fluently. But, you know what? When I switch from Rust to TypeScript, and I want to think about streaming, when it think when I move from Rust to TypeScript, do I want to hold that information in my head? " And the AI can help figure it out.
And I have enough sense to be able to look at it and say, "No, that's not going to work. " Or write it myself. But, that conversation that I had generally will be faster than just trying to write it myself and include steps and include the uh test and include the integration test. So, I look at AI as something that is making me a better developer. Just like a carpenter or a plumber has their favorite set of tools that make them better, and they're not going to just use any tools.
Yeah, you wouldn't go to a carpenter and say, "Wait, you're using a jig? Real carpenters don't use jigs. " So, tool. So, with that said, one of the things that has stood out to me, not necessarily the AI deniers and saying AI code assistants aren't the way, but this gap in understanding on how they're actually used. The one comment that stands out to me over and over again is this idea that I can't trust AI code. Uh that Okay, I I get it.
I agree. I can't trust AI code, but guess what else I can't trust? Any code written by any person at any time. So, guess what? Um okay. Well, what do you do when you can't write when you can't trust your code? Oh, you write test. Well, guess what? I can have the AI at least do the first pass of writing test. I can read them and make sure it does it does what it needs to do.
You know, good developers have good code review skills, so we should be able to do that. And then we can go one step further. We can get into this this whole realm where we are actually trying to prove that our code is correct. And whenever we're trying to reason about our code, guess what? We don't have to write all that because those languages around automated reasoning are are pretty thick. And we can use AI to help us with that. But notice that what I'm saying is that AI is just one of the superpowers.
It's one of the things in my utility belt that help me be faster, more effective, and allow me to do more things at once. And and I really think that we get hung up in that I would write better code than this AI. Well, would you? And that's a good question. And and I think that what it comes down to is that uh we we let ego guide us. Uh I mean, I have no ego about this coding stuff. Um I only code because I want what code makes.
I don't code. Well, actually no, that's not true. Most of the time when I'm coding, I want what code makes. I actually do code for the fun of it sometimes, but that's on my own time. Whenever it's at work for money solving uh business problems, no. My job is to solve this thing so I can get on to solving the next thing, and I'm using AI to do that. So, I get Brian Lau, the guy who was on stage at CNCF, you know, doing the keynote there.
I understand someone at your career level. You understand distributed systems. You are a distributed systems expert. You went from programming Kubernetes control planes to programming storage units and uh and and public cloud. It, you know, the the problem is the problem. You're attacking the problem. What I haven't really wrapped my head around is how to teach that skill set of AI development or AI assistant assistant development to less seasoned professionals. I don't know how to scale AI assistant code.
Okay. Well, that's an interesting That's an interesting way of putting it. And, you know what? I have actually never sat down and thought about it cuz maybe I am closer to the expert level than a lot of other people. But, I do think everything breaks down to you work on defining what the problem is. You iterate on a solution. You put the solution out. You test it, and then you do this loop of do I need to adjust the problem?
No. All right, need to adjust the solution. Put it out there, and you continuous then you make this flywheel, and you continue to do that. What I think a lot of people haven't learned is that ability to make uh code iteratively. And, we see this in and just in in code culture where people are like, "I need to get a new job. So, what are you going to go do? I'm going to go do some lead code. I'm going to do five hards this week and and I'm going to do some mediums on the weekend.
And that sounds just super I'm not even going to tell you what that means cuz it is not important. But, what we've done is we basically raised a generation of developers who can only who can only employ algorithms. They can't fundamentally think around an algorithm. Like um a good one for your listeners would be the convex hull problem. You're like, what in the world is a convex hull problem? Not important. But, someone knows that algorithm, but they probably couldn't derive it down from first principles.
And I do everything that way. Everything is derived from first principles. So, what we need to do is teach our developers how to ask questions. They need We need to teach them how to question what they're doing. We need them to understand the why of every single thing, not just the how. And whenever you get people who start understanding the why, um employing tools like code assistance uh becomes or actually starts making a lot more sense. And I don't just use it for code, I use it for writing docs.
Um I use it for proofreading emails. I use it for so many things. And the reason why it all fits in is because I understand why. I want to sound better. I want to move fit quicker. I want to generate better code the first time. So, what I'm hearing, you know, we can parallel this to the data center. We have people who switch out boards or part replacers. Oh, there's this system symptom, I know I need to replace the network card.
I There's this symptom, I know I need to replace the CPU heat sink. I don't know why these problems occurred. Like the the central problem is there's not enough cooling getting to the system. I need to to solve the cooling problem. I just know how to uh solve the the the symptom and we train people to troubleshoot and solve for symptoms and not the core business or technology challenge. So, what I'm hearing is a reset in thought process of okay, let's get down to the core challenge and you're solving for the core challenge not which IDE to use.
Yeah, that's it. I mean, I have my preferred IDE, but I'm I'm constantly asking why. And because I my brain thinks like that, I'm doing this because I'm doing this because I can I can model out everything that I'm doing in a like a graph and when I say a graph, I have nodes and I have lines between those boxes and they have arrows so we have a direction. And so all I'm doing is solving one part that is part of a larger problem and everything I do is like that.
Which is why I don't have to upset my the way that I work to incorporate AI assisted tooling. Because it's just all it's doing is speeding me up. And I go back to this example that I had before where I was doing something where I'm building a a streaming system. Actually, it's for an AI. It's it's for Anthropic's model context protocol. And I'm building I'm building a server for it. And guess what? I I read their docs. I know how to code in a whole bunch of languages.
I wanted to do it in Rust. So, instead of So, instead of just coding out all their all their their object types in by hand, I just put that into the AI and say make a Rust struct version of this. All right, make a builder for this. Okay, now write me a a set of tests so that I know that it works. How much typing did I just save there? I'm not even a fast typer. But how much typing did I save?
A lot. I mean, I'm thinking this is probably made me four to five times faster. And why? Now I can figure out I can start thinking about how my server works and how the method calls in my server works rather than the the plumbing of putting this together cuz I've already been figured out. All I needed to do was translate it. And I didn't have to even think about translating it. So, translate that to me translate that in like productivity.
Like what pre-AI post-AI, what's the difference in your ability to solve problems from a practical perspective? Oh, there's no there's no um difference in ability. Um I think one of the biggest things is time savings. I can spend my time focusing on things that provide value, not things that need to exist. Um so, back to my example where I am either moving from JSON schema or TypeScript types to Rust. Uh of course I can do that, but that's not value.
So, I use the AI to do those conversions for me. Now, when it comes to the logic of having the server work, you know, I get to think about that right up to the point where I'm done. Then I never think about it again. And I can go on to other hard problems. So, if I were to distill this down, really what it what it comes to is AI frees me to think about things that are actually problems, not things that need to be done.
So, this is helping me better understand how AI is used in this domain. I use it in similar ways in my research and writing. But, it also highlights the skill gap between again, your level of, you know, a senior principal uh applic engineer application developer your your your role and that of some younger or less experienced application developers. I think I'm getting the sense that as you're mentoring younger folks in their career, they may not be younger than you, but younger in their career, you're seeing patterns develop between how they approach problems.
What what's the the the top challenges they face as they look to get to that next level, regardless of AI, but you know, obviously AI could assist them and you know, being a little bit more productive. Okay. So, I think the difference between me and a lot of a lot of other folks is I do work at Amazon and one thing that I really like about Amazon is this idea of working backwards. And I've had this wave of I've had this way before Amazon.
Figure out what your goal is and you work backwards from it. What a lot of less senior developers do and people in general is they have a hard problem in front of them and instead of defining the problem and working backwards from that, they jump right in where they're comfortable. And when you jump in the middle, let's say if you're at a pool and you go in you go in the shallow end, you know how it is, or you can walk around to the deep end jump in there.
You know exactly where you are. But if you just jump in the middle of a pool, how deep is the water? You don't know. And so because you don't know, you have to do you have to go figure out how deep it is, how far you are from the edges. And there's really only two ways to work. You can work forward from the beginning, which I don't really know anyone who can do that, or you work backwards from a problem.
But what I find with a lot of newer developers, less seasoned developers, is that they jump in from the middle. And then they get confused. And these are the people that say, well, AI's not helping me. Well, no, it's not AI that's not helping you. It's just multiplying It's just multiplying the fact that you don't know where you are. And that's fine, it's solvable. And I can tell I could actually sit down and walk you through in a minute.
I'll give you a I'll give you a an a prompt that will actually change the way you think about the world. And it's not even mine. I saw it on the internet and and it was just that good and I use it for everything now. Oh, you have to share that prompt All right. I'll just say it. I'll just I'll actually just read it cuz I have it here in front of me. Yeah, You you put it you go to your favorite um AI interface and you say this, "Ask me one question at a time so we can develop a thorough step-by-step spec for this idea.
Each question should be based on my previous answers and our end goals to have a detailed specification document I can hand off to a developer. Let's do this iteratively and dig into every relevant detail. Remember, only one question at a time. And at any time, if you have recommendations, suggest them. And then you say, 'My idea is'" That's all you need to do. Yeah, that is genius and it's very close to how I write blog posts now. It is "Interview me one question at a time.
Mhm. ask you know, stop and ask for clarifying pieces. Make sure you draw on my experience because what I find is that the difference between a great AI a a great AI blog post and a mediocre AI assistant blog post is that lack of depth of human experience and you're bringing that full human experience and problem-solving to it and it's uh I don't think it's cheating at all. It is it is a tool. Uh I I write I write blog posts faster.
They're not uh less me. They're just I just don't have to worry about structuring sentences and reorganizing and doing my own editing. It's done. It's part of the iterative process. So, that's actually this is this is what I would like to leave the world with is this. Um for folks who are scared that they're going to lose their job to AI, ask yourself this. Um can I work backwards? Do I actually provide value where I am working? " Well, then you might be afraid.
But, don't worry. There are ways you can get around this. You can start by working backwards, understanding, defining the problems before looking at the solutions. You can understand that humans are We are very subjective. We're not objective. But, um we provide we we provide something that no computer has figured out how to. Um we have a sense of beauty, a sense of what's right that you're not going to be able to get out of any of these current large language models.
And that's what you should As long as you have that, you have value. But, understand that if you think your value is writing code, unless you are ju- creating unique very useful algorithms, you're probably not. Um don't don't focus on those things. Focus on the value, which is solving these business problems to allow a business to move forward, to make more money, to have to have more capital with to expand whatever it's trying to do. And that's really where it comes down to.
And that's it. That's how you win. Yeah, I love your your ending statement. Most of my conversations with engineers, helping them to understand their value, is if they had to explain their role to a CFO on how they help their organization make more money or profit more, reduce risk, or whatever, how could they how would they go about explaining that? And that working backwards, that same methodology of working backwards, I'm not just someone who does DNS. I'm someone who does that does this name resolution in support of selling more X, Y, or Z.
Do that work. Figure it out. AI may even be able to assist you. Brian, what is what will leave on what passion projects are you working on in the community where folks can find them if you have time for any of that stuff? Uh fortunately, I have no time. But, um things that I really like is um even though no one knows what agents are and and gen AI, um I like exploring that space. Uh I've also, because of my work, have taken an interest into uh the data that we use to to um feed into training models.
And and how do we how do we build that? How do we take care of that? It's actually what I do for my day job now. Um so, I think about those things as well. Um but mostly, when I'm not working, I'm just watching TV um because I'm old and it's cold and I don't like going outside. All right, Brian. I really do appreciate you taking time out of your busy schedule. I've been wanting to have this conversation for a long time.
com. com. Talk to you next episode of the CTO Advisor. Bye, Brian.
