Episode 40 - Should you be using AI to code at work?

Speaker A: Imagine slashing your coding time in half, freeing you up to tackle complex problems and innovate rather than get bogged down with repetitive tasks. Sounds too good to be true, right? Welcome to another episode of the Scripting Then podcast. I'm Fernando and in today's episode we're diving into the age old question. And uh, by age old I mean a couple of years ago, should you be using AI to code at work? So let's dive in. All right, so let's kick things off by diving into why has uh, AI captured the imagination of the entire industry? Essentially for once, tools like Copilot, Tabnine or even Codium are able to autocomplete your code more so than just intellisense in the sense that it is able to grab the context of what you're doing and give you somewhat smart suggestions as to what you should be writing or trying to guess essentially where you want to go with your code. And you know, giving you already that they're even able to generate a full boilerplate set of code, giving you the ability to write in seconds what you could have spent a few minutes writing or even a little bit more, depending on what you want. Definitely this is not meant for complex logic. That part still it's up to you or at least some of the iterations of these tools. But as ah, they stand right now and um, just the autocomplete part, they are great time savers, uh, because again this is more than just intelligence where you would get a suggestion around the specific code or context that you have. With these tools you're given more than just the relevant ones, but you're given actual code that is probably trying to solve the problem that you're going for. So they are definitely time savers in the same line of these tools having the ability to write code faster for you. They are also fantastic for repetitive tasks. How many times have you seen uh, yourself write lines and lines of constant, for example constant files or just definitions that you're going for or you know, you're defining a class or the interface, for example, for, for your code and you're just doing what you would consider boilerplate or just repetitive tasks that just have to happen in some situations. Some IDEs are able to auto generate some of that code without the need for AI, but rather just the context. But these tools, again, they take that auto generation one step farther and they're able to have context of other files from your project or even what you have on your clipboard, so they're able to write down or suggest and solve repetitive tasks just with a simple click. They're really great at uh, taking the m mundane aspect of writing code and doing them themselves in a very efficient fashion. So they end up giving you more time to focus on the actual creativity aspect of solving problems, uh, and the actual interesting bits of programming essentially not just writing or copy pasting the same code over and over again, but rather figuring out how to tackle a problem, figuring out how to solve the problem that you're looking at. And finally in the same line as, uh, saving you time and taking the ownership of that repetitive tasks. They are also fantastic for uh, rapid prototyping. That is also a, uh, very common use case for these tools. You can give them a few instructions even in comments or in the name of function that you want to create. And um, they will take the best guess that they can based on again the context of your full project and they will give you something that most likely is, if it's not 100% there, it's going to be like 90% there. So you can take rapid prototyping. The concept of rapid prototyping one step or two actually steps ahead and finish what you were looking for. The initial idea of the initial PoC of what you want to build much faster. There are people online showing how to do this, uh, and how to build prototypes in days rather than weeks or months. Um, they are not, they don't look like your average prototype, the average POC that we're used to, if you've been around for a while like I have, but rather they look like finished products, which is incredible when you want to showcase an idea, when you want to show something, um, that should be visual. So again, the level of polish that you can get on just a prototype is just taking the concept one step further than it used to be. So again, these tools are fantastic for boosting um, your efficiency as a developer, for taking away the repetitive tasks that you're just tired of doing. And um, they're incredible for rapid prototyping ideas, checking them out, trying them out, and if they don't work, just replacing them with something else. All right, so they do sound great, these tools. They work fantastic. If you've used them in the past, you probably agree with me, but it's not all sunshines and rainbows. These tools have their downside and it's important to acknowledge that downside as well. So the most obvious one, and if you've been using them for a while like I have, you probably noticed that it is definitely a, uh, potential issue is Skill degradation essentially. If you rely too much on the tool to auto generate the code for you to solve the problem for you, you just take it and do the last few adjustments and then ship the code. From a time to market perspective, that's fantastic. But from uh, skill evolution or, you know, or just the ability of, for you to maintain your skill level over time, it's just a potential risk because you're just using it. And over relying on the tool, you stop exercising that part of your brain that is used to tackling the problem, to figuring out the solution, to writing the code to see how it works. It's not necessarily bad, it's just something that you should do every once in a while to balance out that efficiency boost that you get versus the skill degradation that you also get from not using it for over relying on it. Another potential, again these are all potential problems. They're not intrinsically there if you know how to use it, if you use it carefully. But another one is called quality and reliability of the code. So these models are great, they evolve. Every new version of each of these models is better than the previous one. Uh, you have from OpenAI, you have the O3, uh, models that are able to create a chain of thought. They're able to reason about and plan out steps and write code. That is fantastic. Some of the one shots that you see online, they are uh, incredible for AI model to just write them out in the first shot. But you know, it's not always that way because it's not. These tools are not just magic black boxes that uh, read your mind and suddenly give you exactly what you want. You have to know how to prompt it essentially. And that's kind of a skill that you gain over time if you know how to use it. If you experience uh, if you, if you try them out, if you try different things, if you start um, figuring out how to ask for different aspects of your software, then the code that gets generated eventually is reliable and has high quality. But if you don't know how to prompt it, then chances are that what you're going to get is either incomplete, buggy, or just something that you can't rely on. And even if you know how to prompt it, even if you know that you're getting great results, you have to, you can't just 100% blindly trust what you get, copy it into your project and call it a day. You have to test it, you have to verify, you have to understand the code that you get before you ship it. And that takes us to the Next, which is around, uh, the ethical and legal uh, considerations. When you use code that is AI generated on production and something goes wrong, who's to blame? Is it the AI model? Is it you as a developer? Is it the company that trained the model? Is it the data, uh, that trained that, that was used to train the model? Who is to blame when something goes wrong with code that you did not write? That is a question that many developers are asking right now. And I don't think there is, as of today, a clear answer to that question. The best approach or the best answer I've heard so far and um, the best practice that I've seen applied and that I try to use as well on my side is create a chain of responsibility. Give the responsibility to specific people, to specific roles to take ownership of the code that gets generated because in the end you can't really blame it. Or you can make a, uh, model responsible for things when things go wrong. But uh, you know, in the real world you actually need someone to take ownership, someone to take responsibility when something happens. You can't just all just raise your hands in the air and say, well, it was the AI, what can we do? That doesn't, that doesn't really work. So what needs to happen is you have to have a clear process when code gets generated before it gets shipped. It has to go through, uh, a developer site. Someone has to understand the code before they decide it's the right thing. The code has to be tested, the functionality has to be validated. The integration of that functionality of that code with the rest of the ecosystem also has to be tested. You have to make sure that from the security point of view there are no vulnerabilities added into a system because you added this code. And in the end all those validation steps are going to be somewhat responsible for the work, for, you know, for the validity of the work. And if something goes wrong, you have there identified who was involved in verifying and you know, giving the stamp of approval to that code before it reached production. So again, it's not a matter of just pointing fingers and say, you know, the developer did it wrong, so it's their fault. It's just a matter of showing, you know, giving ownership and uh, accountability to people so they take ownership and they are, ah, uh, they actually do their work. When it comes to validating the code to ensure that whatever gets shipped to production is valid code. We had this same conversation a few years ago when we were talking about people copy pasting solutions from Stack Overflow. It is the same thing. This is a new Stack Overflow. You have a lot of purchase blindly trusting the solution that was given to them without really understanding what it's doing and copy pasting it and calling it a day. You can't do that. You know, you couldn't do that with Stack Overflow. You can't do that with AI. It's just exactly the same thing. In fact, it's even worse potentially because now you get more complex solutions, more complex logic that you have to make sure that you understand. And that takes me to the last potential problem, the last risk of implementing or using AI for coding at work, which is team dynamics, essentially. How is the rest of the team feeling about you using AI? And you know, how are they using it? Are they using it exactly the same way as you are? Are they going through the same thought process and um, you know, the same process, uh, of validation that you are? That whole idea, the mental shift that has to happen in developers to start trusting and using the tool as a tool for coding, it has to happen on every team member. You know, and we're still getting people, uh, uh, scared of using AI because it might lose their job because they might uh, get replaced by an AI or by someone using an AI model. Truth is, and we're seeing it already, AI or these models are not here to replace developers. While you might see a lot of people building things on their own so that, you know, uh, before AI or before these LLMs would have taken a whole team to build. And that's true, but that's just because these models are making us all more efficient, more proficient. Not because they're replacing developers. They're giving every developer the potential to be equivalent, uh, of what used to be three, four developers, five delivery. So it's not about replacing us or replacing team members, is all giving everyone m like superpowers, right? We're like super developers now while we're using these models. And that mental shift that click has to happen on every team member so that the dynamics of a full team using these AI models works to their advantage and it doesn't work against them. So that's, again, that's a risk that has to be m mitigated by the team itself, by the team leadership, or by the project leadership or the company leadership. Anyway, you know, these developers that are shifting into using these models, they have to go through some sort of training, they have to go through some sort of insurance that this is not them training the replacement, so to speak. This is them gaining access to a very powerful new tool that is going to make them more proficient at all. Okay, so what are some of the best practices that you can apply when starting to use AI for coding at work with the goal of avoiding these downsides that I mentioned before? Well, the first one is maintaining a balanced approach, meaning that you should definitely use AI for coding, especially for coding the boilerplate aspects of the code, for coding the repetitive tasks, for getting smart suggestions about potential move, you know, potential solutions to the problem you're trying to solve. But you also have to spend some time thinking for yourself, trying to figure out the problem on your own before over relying on the machine. This is not to make you less proficient or to get you to spend more time on it. This is just to ensure that you don't over rely on these models to the point of you forgetting how to work or just losing that mental elasticity to that allowed you to solve problems faster in the past. These tools are great, but you can't over rely on them. Otherwise, the moment that for any reason you are faced with a problem without the access to these tools, you're not gonna know how to tackle the problem. Another one is implementing mandatory, uh, code reviews. You should already have code reviews as part of your development lifecycle anyway. But you know, in some situations we tend to be light about it, or not really in some situations, depending whose code we're reviewing, it might not be a big deal. We just do a quick review and apply and accept the PR or something like that. This is not what should happen. If you have AI generated code in the process, you need to make sure that the code gets reviewed by one or more developers. And you need to ensure that the code is not only up to the standards of the project, which is the easiest part of the AI to get, but also that is actually solving the problems you're trying to solve. And um, it's not adding any extra problems or any extra bugs or any extra vulnerabilities. So code review has to become a must in this process. Setting clear usage policies is also important from the security point of view. From the ethical point of view, you need to make sure that you're allowed to use them with the code base that you're working on. Essentially, in some situations you're working with code that can't leave your company. You're working with code that can't be shared outside of certain circles. In that situation, if you're using an LLM to improve your efficiency, you have to make sure that you're compliant with those regulations, with those policies. There are ways. Obviously you can have your own local server with the LLM. It might not be as good as uh, OpenAI's latest model or like Copilot or anything like, or Sonet, but there are some great open source models that will give you as close results as possible to those paid models. So what I'm trying to say here is that don't get discouraged if you have extra security or uh, extra limitations that prohibit you from using the commercial versions of these models. Because there are ways for you to still have those benefits and be compliant with those policies. You just need to make sure that you do it right. Because whatever efficiency that you get from these tools is not going to justify you breaking rules or breaking or breaching contracts with your client. Another one is, and uh, this is more of a uh, best practice for a company is to invest in training, make sure that the developers that are going to be using these tools fully understand how these tools work and what they're capable of and what they're not capable of. This is because understanding the limitations is going to dictate how you use it. If you don't understand those limitations, you're just going to think it is a magical black box and then you're going to get frustrated when you don't get the results that you want. So you have to see the coin, uh, from both sides, size and you have to understand how to treat it, how to use it essentially to get the most out of it. This is not the usual tool that you click here and you get this result, you click there and you get these other results. This is a different type of tool and you have to learn how to use it. That's it training here, it's really recommended. And finally, monitor and evaluate the impact of these tools in your workflow, in the efficiency of the team and um, make sure that you're actually getting the value that you're paying for or that you're investing in and you're getting the return of that investment. This is because while these tools are great, while I am um, the first one to say every developer should be using them by now, maybe not every project, maybe not every technology, or maybe not every team will get the same benefit. So as a company or as a project lead, you have to understand the amount of effort, extra effort that you put in to train your people to get them the right licensing, to get them the right software, to change the way they work so that they ramp up or get adjusted to that new mindset and then get the benefit of these Tools. If all that process, all that investment doesn't yield the result that you expect, then there is something probably that you need to change, that you need to adapt, and then you need to review if this is the right approach or not. In the end, again, these are all tools, there are many flavors of them. So maybe it's just you using the wrong one or you using them in the wrong way. And you're not going to see those problems unless you monitor and you review the feedback that you get from your developers, the type of output that you get. And you understand if you have better call quality, if you're producing code from faster, if you're producing, you know, more or less bugs. There are a ton of metrics that you can look at to give you sort of an idea. But obviously you have to talk to your developers, you have to get their feedback and understanding if they're enjoying the process. You have to understand if they're actually happy with the mindset change, if they done it, if they gone through it, and if they have any, you know, blockers or barriers. Because in the end, you have to find all those pain points that your developers are having when it comes to adopting these tools so that you lower the entry barrier to the point of, you know, removing all excuses and just making it the natural next step to use these tools. So should you be using AI for coding at the work? Clearly, the answer is not a simple yes or no. I can't give you that answer for everyone. I can't give you the same response to every team, to every project, to every technology. That said, these tools are an incredible asset. They're going to give you an edge as a developer if you're able to learn how to use them and you feel comfortable using them. However, it's also essential that you remember to keep a balanced approach. Use them for repetitive tasks, use them for boilerplate, use them for proper prototyping, but also keep writing code when possible to maintain that expertise, uh, that you brought into the table, um, so that the AI keeps enhancing your level. But instead of you lowering your level to the point of relying on AI forever, ensure that quality is maintained not by, um, blindly trusting these models, but rather by distrusting them and having rigorous, uh, review processes that ensure that what you're shipping, even if it's AI, uh, written, is still good quality and is not adding extra problems. And finally, listen to your team understand how everyone's using these tools and make sure that, uh, how they use it is clear. Why they're using it is also Clear, provide them with trainings, give them right policies, right workflows, so they know what they need to do and how they need to do it. It's not like everyone just free willing, trying to figure out on their own how to best use these tools. And that's it. Thank you for listening and watching. If you're on YouTube, I love to know if you're using AI for coding at work. So if you are, feel free to share your experience in the comments below. If you're in YouTube or you know, on. Just reach out to me on next. I love to know your war stories. I love to know how you, you know, if you had any issues with AI, uh, in the past, either generating the wrong kind of code or adding extra vulnerabilities. These are all things that I always bring up as potential problems. But myself, I've never seen this, uh, behavior so. Well, it is a risk. It is a very low risk to me based on my expertise. So if you experience it, I would love to know more. I love to know what, how you handle it. So make sure to share it anywhere you can. Love to know about you. And that's it. Thank you again. Uh, please like share and subscribe to the channel so that the podcast and the channel can reach more developers like you. See you on the next episode. Bye. And that was it for this episode. Thank you so much for listening. And don't forget to rate the podcast in your favorite podcasting app so that it can reach more developers. In the meantime, if you like to follow me on Twitter, or X as people call it, just look for me at deleteman. 1, 2, 3. And that's it. Thank you. And catch you on the next one.