Coding Options: No-Code, Low-Code & AI Vibe

Welcome to Building Better Developers, the Develop-a-Nor Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well, hello and welcome back. We are continuing season 26 of Building Better Developers, the Develop-a-Nor Podcast. The topic, the focus this time around is building better foundations. This episode, we are going to tackle low code, no code, and vibe coding. We're going to talk a little bit about that and how they have a better foundation in these non-coding kinds of things, I guess we'll call them. But before we do that, I need to introduce myself. My name is Rob Brodhead. I am one of the founders of Develop-a-Nor, Building Better Developers podcast site and all the stuff that goes with it, matter of fact. But I'm also the founder of RB Consulting, where we are basically a boutique consulting firm. We help companies cut IT costs. We help you, we sit down with you, walk through your business and your processes and your approach and then we get to know your business using our background and a technology agnostic approach. We're not going to sell you a specific tool or anything else. We're going to find that, look at the tools that are out there and help you craft a roadmap that you can go with and either you can run with it or we can help you implement that to make your business better as well. And that includes things moving faster, higher quality and of course the best, a better bottom line reducing your IT costs in particular, which is one of your bigger areas. You can check us out at rb-sns.com. We also have a free assessment. You can take out there about 10 minutes. You can walk through some questions and it's going to give you some ideas of where to go, very basic roadmap stuff. Or you can also, while you're there, you can actually engage us and have us spend a couple hours with you. We'll spend an hour up front. We spend a few hours. We go away. We take all of the answers to your questions. We craft that roadmap we talked about and then we come back and spend an hour with you walking through that roadmap and how you can implement it. Again, all that you can check out at rb-sns.com. Good thing, bad thing. Boy, this is one, here's one that's like a, I don't know if it's a good or bad, it will be part of this. I'll just combine these two into one story. We are running low on tea in one of our, where we were, and then actually running low on tea and I think we were out of some coffee or something like that. So my wife was like, you know what, I'm in like a tea mood. I'm going to try some green tea. So the bad thing was that she was down to like just grabbing like these like individual tea bags and stuff like that that we had left. It's not like we had anything that was like our top end stuff. It was sort of the extras. So that was sort of bad. The good thing, I think, is that she found one she really, really liked. The bad part about that is now I have to go find more of that and make sure that we have that for the next time she's in a green tea mood. So watch out, you know, sometimes like sometimes you get to what you want. Sometimes it like you should have thought a little bit more before you asked that question, but I have not thought near enough. So I'm just going to throw it to the wolves, throw it out there to the wind, whatever it is. I am casting all my cares aside and I have Michael introduce himself. Hey everyone. My name is Mike Mulash. I'm one of the co-founders of Building Better Developers, also known as DeveloperNUR. I'm also the owner and founder of Envision QA. We help businesses take back control with customer software that builds around the needs, not the other way around. So we work on helping you by focusing on great service, smart solutions and a rock solid quality. We build tools that replace frustrating systems, streamline operations and are fully tested to work right the first time. At Envision QA, we combine development and quality assurance to give you software that you can trust and support you can count on. Check us out at EnvisionQA.com. Good thing, bad thing. Good thing, good thing. Well, I guess it's a mix. I'll combine it. It's good and bad. So I've been working very hard to get off coffee and really cut back on my caffeine intake. The problem I have uncovered with that, while I'm feeling better, my peaks and valleys of my focus have really dropped. So I have had to slowly increase my caffeine intake a little bit, but unfortunately, tea just doesn't do it. It's like a little too much tea. The flavor's not quite right. It just doesn't taste right to me. And coffee upsets my stomach. So I'm dabbling again briefly back within energy drinks. And Monster gives me the jitters. I can't do Red Bull because that just gives me migraines. So my wife was telling me to check out this new drink that keeps popping up on NASCAR called Celsius. And I've been trying that recently. And one a day, if I drink like half the can in the morning and then half the can at lunch, it seems to keep me focused all day. And I can just stay on decaf tea the rest of the day. And it seems to keep me more steady and focused. So the good and bad is, the good I'm focused again, the bad is I am getting more caffeine again, but it seems to be at a stable rate that my body seems to be able to handle better. The challenges of properly medicating ourselves. So speaking of properly medicating, I don't know if this is really good segue. But anyways, we're going to dive right into no code, low code and vibe coding. And first, let me give, I want to go with the definition of each of these just because, because again, they are buzzy as how they are. As we're getting into it and we talk about these. And this may be, this could actually spilled into a second episode, but I want to give us a foundation in building better foundations for what this discussion is. So no code is, and this, I threw it out to AI to get me some stuff off of the internet. And it's got some pretty decent little definition. So no code, building software applications using only visual interfaces, pre-built components and configuration with little or no traditional programming. Low code is application development that combines visual tools, as we had the no code, with some hand coding, enabling faster delivery while allowing custom extensions. And then vibe coding is using AI assistance like a GitHub's copilot, chat GPT, replic ghost rider. And some of these, lots of others that are out there to generate code interactively guided more by natural language and intent than by strict syntax. And I'll give like the sort of the in short that it gave us, which I think is pretty good. No code is no coding, purely visual. Low code is some coding visual plus code extensions. And vibe coding is AI assisted intent driven coding. What I want to talk about with these is a little bit like when they come into play, but a little bit more about like what to be aware of when you're doing it. So I often see, I sort of see a lot of the lines being blurred between no code and low code, because the low code part of it, there are a lot of people that I have known that are using essentially, they're using low code tools as no code. And then they'll maybe use AI or they'll maybe do a couple of searches or something like that to find like the little script that they need. They're really effectively, it's no code. It really is. It's just, and by this, it's thinking about like, you can put together a website that is like create a page, create a page, create a page, create a page. The pages are, you know, they can be interactive. So they can be doing things like, you know, maybe send an email or pull data from somewhere, things like that, especially if you start getting into Zapier and if this and that, and some of those kinds of sites that do those automations. But you're really, you know, the coding you're doing is really just like pointing and clicking. You're saying if I click this button, then you drag and drop or something like that to say, okay, well, this is the screen I want to go to, or this is the function that I want it to execute. So it's not actually writing code other than writing some, maybe I write, you know, name some of my pages and stuff like that. That's it. It's not code. It's more naming. And it's much more like a word document or a PowerPoint, you know, slide or pages or presentations or keynote or whatever it is, whatever you want to, whatever your tool is. And then low code, you're doing that. But then yes, you're, you know, there are going to be, now you're doing something a little more complex. You're clicking a button, but you're actually writing some script that some code that says, oh, open this page, but also send this email out or do this thing. Usually you're getting a little more complicated and you can, like everything, the more that a system does for you, the harder it is going to be either the less you can do for yourself or the harder it's going to be to do the things that you want to do. These things are going to drive you in a certain direction. So if you're going no code, I think the biggest thing to consider is look at the tool you're using and does it typically get used to generate a product or a solution like you're looking to do? And really, honestly, I think if you're using no code and even low code, it should almost always be for a proof of concept. You could do an MVP. I actually have got a, I did something with the customer where it was, we made it low code because we had a couple of coding type areas we did and we were able to connect to some systems and stuff like that. And so it was, it was basically the front end, the marketing part, the landing pages and stuff like that. It was all no code essentially. Looks great, looks awesome. He's got all his little controls. He put all this stuff in and it looks like you can't tell that it's a no code site. It's a very pretty website. that you would expect from that kind of a website. Once you get into any of the real work, then it does become a little more complicated. Now that, that is not like, it's getting better. There's things like, shoot, I just lost the name. Oh, like Airtable, some of those kinds of places, some of those kinds of tools that now there's a lot of integrations with those. So now you do have like a database back end that you can use. There's some other things out there that you can use that you can actually store data. You can move stuff across your applications. The no code is actually getting, I say, pretty solid. There are some, you know, they're like, you can build solutions with it. It's just growing the solution, I think is where your problem may lie. Before I dive into that, I'll get your sort of your thoughts on the, you know, overall thoughts on those areas. Yeah. Touch Vibe coding. So I left that one wide open for you. Yeah. Well, we may pick that up as like a cross back and forth, but you know, just going into low code, no code to me, the only time really it makes sense to do no code is just if you have stack websites. If you have a stack application with just point click, take you through the application, there's no real meat to the application. It's just an informative site that you just have navigation. Obviously you have an online marketing tool, a big brochure with clickable links that takes you through things. Low code to me is more for when you have a little more integration within your application. You may have to connect it to say like an email provider payment system. So you have to have some type of code behind the scenes that does a little bit of additional work within the applications. In fact, I almost think of Excel as low code because you have Excel, which is the application itself, but then you can actually write macros or even functions within each cell to do calculations within numeric calculations. That's actual coding people. That's not just writing formulas. It's called Vibe code or it was called Vibe code years ago. There's actual code behind the scenes. It just looks like math. It's very cool how Microsoft did it. It's just one of the biggest gripes and frustrations I have with these particular models is you are stuck with the tool that you go with. 99% of, I won't say a hundred percent, but almost 99% of these tools that do low code and no code, do not let you take ownership of your code. You have to use the tools to publish them. You have to use the tools to maintain them. You can sometimes export the code to like pure HTML, JavaScript, whatever language you need, but that comes at a cost. And then the other cost of that is you don't know how that works because you did all this in a UI. So unless you can ingest that into a new tool to do no code, low code, you're kind of stuck. Now you got to go find someone to actually maintain your application. So while these are very quick to get to market, they can become costly down the road if those tools go away. So you just have to be very careful with what you pick to kind of build these applications using low code or no code. So I will start the Vibe code conversation now and then I'll pass it back to you. So Vibe code is an interesting concept or an interesting way of coding now that has come around because of AI. And well, it's useful. It is very dangerous because AI is not at a point where we really need to be relying on it to write our code. Depending upon which tool, there are some very good coding tools out there that give you very precise code snippets because there's enough examples of that on the web that they've stolen it and can regurgitate it. But as far as logically building you an application, it's going to give you piecemeal based on what you're asking. So it's like, hey, build me a login screen. OK, so it's going to go build you a basic login screen. There's enough of those out there that it can pull in and put something together. However, the logic behind the scenes for the login screen is going to vary. Are you going to get the right security for your authentication, for your password authentication? These are things that if you're Vibe coding, if you haven't written applications before, you're not going to know to do this. And you could essentially create an application that is full of security holes. Or validation may not work at all. It may make it look like it's working, but you have essentially hard coded values or very insecure protocols going on when you're logging in. But it works. You build the application. Hey, I have a screen. I have a back end piece. It works. It lets me log in. The problem I guess the biggest problem I have with Vibe code is it gives you a false sense that you are writing code, a false sense that you are building applications, that you know what you're doing. It will give you something that works. It is good at prototyping. I will say that it is very good to get something that is prototype that is functional, but it is probably not enterprise level or even publication level like to sell it to someone immediately out of the gate. It may look like it works, but I would really break that code down, have someone that professionally knows how to write code go through it and make sure that it's solid before you go to market. Yeah, I think I do want to drop back to no code, low code real quick because I do think that's one of the things there is that, yeah, Excel, Word, PowerPoint, all those because you do have Visual Basic for applications underneath. You could actually consider those as low code or actually all of the above. They could be no code where you're basically just writing your stuff, doing your thing. Low code where you're just doing a little bit here and there like your formulas within your cells in Excel. But then you can do full blown coding, which is you can get back in there, you can rewrite huge portions of it. I would not recommend it because if you're having to rewrite, it's not built to be, there are better ways probably for you to build an application and build it, do everything in Excel and then try to like under the covers, start adding all your coding in, which is one of the things that you need to be concerned with is where is this going to go? If it's a one off, if you're doing something that is like, I just, I've got this, I'm never going to really change it. I'm not going to do any enhancements. Awesome. You can, if it doesn't have no code or low code, go for it. But if it's going to have to grow, if you're going to have multiple users, if you're going to need to worry about security or if you're going to have to worry about like all the things that applications need to worry about, then maybe you need to think about a different approach or get something out there and say, okay, here we go. This will do for now. But then use that maybe as a, almost like as a requirements documents and say, okay, now let's go build this for real, you know, in a real system. And that's really where I think the vibe coding, I had a conversation the day that I, the guy like just nailed it. As he says, you know, he was talking about his experience with AI and he said that I Think of it as like a junior or mid-level employee is sort of what AI is. And I really, the more I've thought about that and the way I've become accustomed to using AI is almost exactly like that. It's very much probably more a junior level than even a mid-level developer because it's really, it's like, I have to be very specific on what I ask. I do like, if I'm doing coding, like vibe coding, I guess is what I'm doing is I'll have it shoot some stuff out, but I ended up essentially doing immediately a code review and then either I'll just go fix it or there's been more than a few times. It's like, you can see that it has a systemic issue throughout the code it generated. And I can say, wait a minute, this is wrong. Fix this, change that. The simplest things like versions. It is amazing how often you will get code that is like on a version of your environment that it just won't work. I've had all kinds of fun times trying to get AI to understand the difference between in the Salesforce environments, whether using the old UI or the new UI and how you're actually coding, especially anything that gives you multiple ways to do it, which is most general languages, you're going to have some fun nailing that down. There's so many different, like, you know, if you want it to write something that connects to a database, it's there's a couple of different ways you can do it. And you have to be very specific on what you want and what version you're dealing with. Python, there's a lot of different ways to do to build an API with Python. And you got to make sure that you're dealing with it properly. You're dealing, there's lots of different ways to do scrapers, to do even like this most simple stuff like login and authentication. So I think if you treat it like a child, basically, and that you're going to like realize that you're going to have to be very specific, trust but verify, maybe even don't trust and verify and take a look at it and be. I think the biggest thing here is if you're going to use any of these things, you need to spend the time to understand what it's doing. Because then if something goes wrong, or if you need to expand upon it later, you at least know what's going on there. You know where to look. If you just throw something together real quick, and then it's like, oh, we have this new feature we need to add. You didn't really spend that much time, you weren't really mentally engaged doing it. Now maybe you were from a visual point of view. But what's actually going on underneath the covers or behind the scenes may be where you're going to miss out. And I think the key to all of these is like probably the biggest thing to think about when you're going through these is really is like, does it scale? Is this something that really actually works? Like Michael's implied, it works, but in quotes, air quotes, because it's yes, it does it, but it doesn't really do it correctly. It may not be secure. It may not be something that supports growth. I don't know how many times I've run into people that have used systems, some of these systems to do data, to track their data. And then as stuff grows, suddenly the thing becomes just ridiculously slow because they're using a system that was not built for thousands, 10,000s or millions of records. It was built to do something quick and dirty with 20 records, just like an Excel spreadsheet. You can sit there and a lot of times, depending on what you know, you can look at 20 or 30 lines at a time, you can get some basic information. If you're having to move around all the time in a spreadsheet that's got 50,000 rows in it, it's going to be slow and ponderous. Even using searches and stuff like that, it's going to take it a sec. And so you need to think about where this is going to go. And I think that's one of the things that we do this often. It's like, can't just think about what is it that you need today? Let's think about what happens tomorrow, six months from now, particularly if this is like a really great solution that a lot of people are going to use. What happens when you suddenly get 10,000 customers at your door? Are you going to be able to serve them thoughts? Yes. I'll take this on to that. So as you're doing your vibe coding, I tend to use AI a little more as like a virtual assistant. Yes, I use it for Google searches as well. And I know that's dating myself because you see all the things, you know, your parents are using AI for Google search. Essentially if you really understand software development, the problem we run into building code is it's not so much we don't know what tool or what algorithm or what library to use. The problem is when did we last use that? Was that a year ago? Five years ago, a decade ago? Sometimes we just have to throw something in quick and say, hey, how do I do this? Oh yeah, I remember this now. Okay. And I go grab what I need and move on. The trick here though, especially with vibe coding is don't rely on just one language model. There's multiple language models until you get comfortable finding the one that really resonates for what you're trying to do. Chat GPT seems to be really good with Python and PHP. Java at times it is way off. Copilot is getting a little bit better. Claude's started dabbling in code. It's okay. Weaverly which was Codium, that one's actually pretty solid. Tab 9 is another good one. They've actually been around for a while. I like them more because before they went AI, they were a very good search tool. So you could just go into their application type like Spring Boot. And here's a whole bunch of like Spring Boot little functions on how to do different things in Spring Boot. And you could type in like Java string and it would give you all these examples of how to use the different versions of Java string. So those to me are still more beneficial even than just a flat out AI provide coding. I like sites that give you code examples based on what you're trying to build. So just food for thought on that. Make sure you test multiple tools and then make sure you still verify, verify, verify, you know, stack overflow, tab 9. Just do some standard Google search to make sure that what you're getting is right. Yeah, I think that's like so many of these things. I think that's part of it is play around with those tools because they are, they do have different strengths and weaknesses and they are all evolving slightly different paces. And so I think it's worth it to see what works best with you and how you utilize it. I do recommend highly starting to play around with those things. Part of the reason I use all these tools and I randomly will pick a different AI engine probably every time as a Google search. I use as my search engine a lot just to start getting used to like what do you get from these varying places. I use perplexity all the time now instead of on my phone. I've got it there so I use it instead of like my browser window and just popping something up there. I use chat GPT on a regular basis. I use Google Gemini all the time. I've got like windows up with those because I use those for my searches. I use those to do some of the things Michael mentioned where it's like, hey, just do this real quick. I will use it. I also use it not just for searches. I do use it for quick code cleanups. I'll do things like take this and refactor it so that this variable gets pulled out or rename all of these things so that they are, you know, it's built up like this. Now it's this name or something like that. There's some things like that that I'll even like have it occasionally. I'll throw stuff at it and be like, hey, is there, you know, would there be a better way to do this or what do you think this does or things like that? The way to do it though is keep it and it goes back to the idea of and all of these, I think the best way is think of it as a very junior, you know, a junior maybe mid-level employee and keep it small bite-sized chunks. That allows you to really focus on like, let's get this thing done. And I think it helps you because then you're not, you're not going to be overwhelmed by there's this whole big solution and I don't really know what it is. It's going to be this big solution, but you've walked your way through each of those things. So I, you know, I know a lot of people, so many people like say, okay, well, this is the thing I want to do and you'll tell AI, you'll give it like 50 steps and these are all the things that needs and these are all the requirements. Well, if you haven't really walked through the requirements individually, it's going to give you a mess of stuff and it may even drop some. It does that all the time. I'll give it 10 things to do and it'll do five. It's like you need to instead break it down piece by piece and go, okay, I need you to do this and then verify that it's done it. And then I need you to do that and verify that you've done it. And it can be, yes, it can be a little bit time consuming, but it is. It's just like a junior employee. It's just like a virtual assistant. I really wonder if virtual assistants will essentially disappear because it's cheaper, easier, faster to do it with an AI system than it is with a virtual assistant. And honestly, you're going to get the, I think actually I get better results out of AI results than I do out of some of the virtual assistant groups that I've dealt with over the years. And it's just, it's a part of it is because the turnaround is so fast. You can just like go boom, boom, boom, boom. You can have a conversation and you can get something refined very, very quickly. And it's not a, the last thing I say on this one before, as we're wrapping this episode, it's not a threat to your, or should not be a threat to your career or anything like that, all this is doing is it's doing the gathering. It is being your hands and feet. You should still be driving it. You should be understanding that you're building this solution, that you're using, pulling all these pieces together and turning it into something that is useful and you're being intentional about it. And you're not just saying here, do this thing. I'll give a quick example for our, for the app that we did. I've like said, give me a landing page for the matrix.rb-sns.com. It's like, give me a nice little landing page. This is what I want. This is what the thing is. Give me something that's like, you've got some pop and some polish and stuff like that. And it gave me a nice little thing. But then I go, you know, I looked at them like, okay, well that, you know, that sort of works and we're going to use that for now because I was like, I need a, I need a homepage for this. And we talked about it some more and then actually sat down and had a RB consulting management powwow basically. And it came out, it's like, you know, let's, it's not like, let's make it less of a word doc. Let's make it something that's got a little more, you know, let's clean this up a little bit and like add something that gives it a little more humanity to it or something like that. And so I was like, yeah, you know, as I thought about it and I started working with it and I started picking apart pieces of what the AI had given me and I was like, well, let's change this. Let's do that. Move that over there. Change that there. Let's try this. What if you do that? And so I was able to, it was rapid application development at that point because I was able to very quickly get stuff back and go, okay, well, I'm going to put this here. Oh, wait, I'm going to move that there. Let's move this over here. Oh, now this. And so the whole process was a lot of back and forth, but I ended up getting something better because I actually picked apart what I did and then actually walked through it that way. And I find that in the code reviews I've done for people where I can see huge sections of stuff and I guess this will be like a side note. Use AI enough to know when you're looking at AI. There are going to be markers all over the place. There are things that are going to let you know when you're looking at stuff, whether it's writing, whether it's code. I mean, I guess if it's one line of code, okay, but if it's a whole function or something, there's going to be things you're going to be like, this looks like AI and just know it because then that's going to help you understand a little bit when you're looking at things and going, why would somebody do it? You're going to be like, oh, AI did it. So walk through those things, like be very detailed about it. The time that it saves you in writing code, that means you can use that time to actually check the quality and verify it and do the updates and do the testing and things like that, which includes AI will help you immensely in the testing world. It is amazing how much you can get unit tests and things like that thrown together very quickly with UI to give you some sort of a, at least an outline. It's going to at least give you something that you can work with and then you can start adding and subtracting and doing what you need to within those. But that more and more makes it like there's almost no excuse to not have some of these things in place because the things that are very tedious and time consuming, those are the things that are perfect for AI. I am sorry if this has been too tedious and time consuming. It's not perfect for AI because, well, I don't know, maybe at some point we should take this stuff and tell AI just generate an episode and see what it does and see. We'll have a vote. Does it, was the AI episode better than the real person episode? And if AI was better, then our work is done here. We'll just like crank out AI episodes for the rest of our life. I don't think that's going to happen because AI will not be able to answer your emails properly because I know you're going to shoot us one at info at developmentorder.com. You're going to let us know what you think. And we're going to be able to integrate that into our next round of topics and seasons even as we move on. That slow and steady march towards a thousand. We've got like a year or something like that, I think, before we're going to hit that. So you don't have to worry too much. Also check us out on X at Develop-a-Nord. You can check us out. Develop-a-Nord.com is really where everything lives. You can leave us comments on any of our articles, any of our past episodes. Check us out. The Developer Nerd channel on YouTube has got the last four, I think, seasons now of this is of the podcast is out there. And then before that, we have, I think there's like 200 episodes of tutorials and mentor mastermind type classes and mentoring presentations and just tons and tons and tons and tons of stuff. And actually a lot of it is still pretty, you know, pretty relevant. It is amazing how many like we look at numbers, how often some of the stuff that we did years and like five, six, seven years ago is still being checked out on a regular basis because it still has some, you know, it's very valuable to whoever's tracking through that problem of the day. That being said, I'm going to wrap this one up. Appreciate you and your time and all that you guys have done for us. And we're going to just continue to try to do for you as well. So go out there and have yourself a great day. Great week. We're going to talk to you. Thank you for listening to building better developers to develop a newer podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.