Detailed Notes
Discover the full spectrum of modern coding options—from no-code and low-code platforms to the emerging practice of vibe coding powered by AI.
Hosts Rob Broadhead and Michael Meloche explain when each approach shines, how to avoid platform lock-in, and what to watch for as your project scales.
👉 Read the full blog recap: https://develpreneur.com/coding-options-no-code-low-code-vibe-coding/
đź‘Ť Like this video if you found it helpful and subscribe for more episodes of Building Better Developers.
Transcript Text
[Music] Press record and let's do episode two. >> Oh, cool. You picked your camera. I was about to suggest that. >> Um. Oh, how so? Because I was up here. >> H you were way down. >> Oh, yeah. I don't know that I changed it. I think I just I sat differently because Yeah, I was probably down here because I wasn't standing up sitting up properly. I'm thinking um I'm thinking dive right into low code, no code, and vibe coding for this episode is talk about those because those are such big cool things right now. And I think those are I'm seeing a lot of that. I'm seeing a lot of problems with that, too. And I think this is where I think it's an opportunity uh like every other problem that's out there. I think we have opportunities here on how we can help people out. Um, and even if we're trying to do it ourselves, how we can help ourselves out so we don't end up getting bit by doing an MVP that really is more of like a proof of concept. It's really more of a one-off and that you end up doing an MVP and then you have to rewrite the entire MVP. Sound good? >> Yeah. Yeah, I was just quickly refreshing my memory on low code because uh no code and vibe code I've been dealing with a lot but I keep forgetting about low code. Let me do this. I will do I'll get some officials here. So no code, low code. Won't hurt to Yeah, wouldn't hurt to actually put those definitions in as we do it. Okay. Yeah. So, low code is basically where we're using tools uh uh what was that tool? Uh kind of like Figma's becoming a low code because you can uh do wireframes and that and add code behind them to make them clickable demos. >> Uh yeah, to some extent usually that's like yeah the no code low code stuff will do some of that. Um, usually it's more like visual uh I guess I typically think of it as more like visual uh graphical interfaces coding. Um although I guess you can do that with no code but usually there's um yeah you're plugging stuff in and you are throwing a little scripting or something behind the scenes uh into it but and it's really that's why I sort of combine low code no code I combine and most people I think do u sort of combine those two because it's like not worth draw distinguishing between the two. Uh and of course vibe coding is a little you know is different a little bit. Yeah. So here's in short from AI no code is no coding visual only low code some coding visual plus code extensions and then of course vibe coding is AI assisted intent driven coding uh it would even allow it's even offering to create a whole podcast miniseries outline under building better buzzwords each one is an episode um we're not going to do an episode per all right well that sounds good so let's just dive right into this one so we can get going get on with our day a little three two one well Hello and welcome back. We are continuing season 26 of building better developers the developer podcast. Uh 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 to have a better foundation in these uh 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 Broadhead. I am one of the founders of developer building better book developer podcast uh site and all the stuff that goes with it matter of fact uh 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 no uh an technology agnostic approach We're not going to like 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 road map that you can come with and uh either you can run with it or we can help you implement that road map to make your business better as well. Uh 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. Uh 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 road map we talk about. Then we come back and spend an hour with you walking through that road map and how you can implement it. Again, all that you can check out at rb-sns.com. Good thing, bad thing. Uh my this is one. Here's one that's like a I don't know if it's a good or bad will be part of this. I'll just combine these two into one story. So we're we are running low on tea uh in one of our where we were get 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, you know, the bad thing was is 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. Uh 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. Uh so watch out. You know, sometimes like sometimes you get 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 have Michael introduce himself. >> Hey everyone, my name is Michael Malashsh. I'm one of the co-founders of Building Better Developers, also known as Developer. 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 uh helping you uh 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. Uh, check us out at envisionqa.com. Uh, good thing, bad thing. Uh, good thing, good thing. Uh, well, I guess it's a mix. Uh, 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, well, I'm feeling better. Um, my peaks and valleys of my uh focus have really dropped. Uh, so I have had to slowly increase my caffeine intake a little bit. Uh, but unfortunately tea just doesn't do it. It's like a little too much tea. The flavor is not quite right. I It just doesn't taste right to me. So, and coffee upsets my stomach. So, I'm dabbling again briefly. Uh, 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 uh Celsius. And I've been trying that recently. and one a day if I drink like half the can uh in the morning and then half the can at lunch seems to keep me focused all day uh and I can just stay on decaf tea the rest of the day. Uh and it seems to keep me more steady uh and focused. So uh the good and bad is uh 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. ah the challenges of properly medicating ourselves. So speaking of properly medicating, I don't know if this is really good segue segue, but anyways, we're going to dive right into no code, low code, and vibe coding. And first uh let me give I want to go with a definition of each of these just because uh because again they are buzzy as how they are as we're getting into it and we talk about these uh and this may be this could actually spelled into a second episode but uh I want to give us a foundation in building better foundations for what this discussion is. So, no code is uh and this uh I threw it out to AI to get me some stuff off of the internet and it's got some h pretty decent little uh 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 tool tools as we had in no code with some hand coding enabling faster delivery while allowing custom extensions. And then vibe coding is using AI assistants like uh GitHub's C-pilot, ChatGpt, Repliciter, um 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. Uh 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 uh code extensions. And vibe coding is AI assisted intent driven coding. What I want to talk about with these is um a little bit like when they when they come into play, but a little bit more about like what what to be aware of when you're doing it. So I often see I I 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 know that are using essentially uh they're using low code tools as no code and then they'll you know maybe use AI or they'll maybe do a couple of searches or something like that to find like the little script that 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 uh 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 it to go to or this is the the function that I want it to execute. I'm 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 a word document or um a PowerPoint uh you know slide or or pages or presentations or keynote or whatever it is whatever you want to whatever your tool is. Um and then low code you're doing that but then yes you're there are going to be now you're doing something a little more complex. So 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, um 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 a customer where it was uh we made it low code because we had a couple of coded coding type areas we did and we were able to connect to some systems and stuff like that. Um and so it was it was the front 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. You 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. It's got functionality that you would expect from that kind of a website. Once you get into any of the real work, uh then it does become a little more complicated. Now that that is not like it's getting better. There's things like um uh shoot I just lost the name of oh like air table u some of those kinds of places some of those kinds of tools. Now there's a lot of inter in integrations with those. So now you do have like a database backend that you can use. Uh and 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 u pretty solid. There are some you know there like you can build solutions with it. It's just growing the solution I think is where your 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 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. Basically, you have an online marketing tool, uh, 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. and you may have to connect it to uh 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 uh macros or even functions within each cell to do calculations within uh numeric calculations. That's actual coding people. That's not just writing formulas. Um spent it's called VBcod it. Uh or it was called VBcode years ago. There's actual code behind the scenes. It just looks like math. Uh 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. um 99% of I won't say 100% 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 uh 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. Uh so you just have to be very careful with what you pick to kind of build these applications uh using low code or no code. So I will start the vibe code conversation now and then I'll pass it back to you. Uh 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. Um it 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 uh and can regurgitate it. But as far as logically building you an application, it's going to give you peace meal based on what you're asking. So it's like, hey, build me a login screen. Okay, 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 uh for your authentication, for your password authentication? These are things that if you're buy 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. Uh or uh validation may not work at all. It may make it look like it's working, but you have essentially hard-coded values or very uh insecure um protocols going on when you're logging in. But it works. You know, you build the application, hey, I have a screen, I have a backend piece, it works. It lets me log in. it the problem I 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 I will say that it 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'll I do want to drop back to no code, low code real quick because I do think that's what they one of the things there is that yeah, Excel, Word, uh, 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. uh low code where you're just doing a little bit here and there like your uh formulas within your cells in Excel. Uh but then you can do full-blown coding which is you can get back in there. You can rewrite huge portions of it. uh I would not recommend it because if you're having to rewrite it's not built to be um there are better ways probably for you to build an application then build it you know do everything in Excel and then try to like under the under the covers start adding all your coding in which is one of the things that you need to be concerned with is where where is this going to go if it's a one-off if you're doing something that is like I just I' 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 does it in no code or low code for 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." Uh, and that's really where I think the vibe coding. uh had a conversation the other day that I the guy like just nailed it. Um and he says, you know, I he was talking about his experience with AI and he said it I think of it as like a a junior or mid-level employee is sort of what uh 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 is it's very much um probably more a junior level than even a a mid-level developer because it's really it's like I have to be very specific on what I ask. Um, I do like if I'm doing coding, like vibe coding, I guess is what I'm doing is I'll 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 uh 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." U the simplest things like versions. Uh it is amazing how often you will get code that is like on a version of your environment that it just won't work. U I've had all kinds of fun times trying to get AI to understand the difference between in the Salesforce environments uh whether using the uh the old UI or the new way UI and how you're actually coding especially anything gives you multiple ways to do it uh which is most general languages you're going to have some you're going to have some fun nailing that down. Java, there's so many different like, you know, if you wanted to write something that connects to a database, it's there's a couple different ways you can do it and you have to be very specific on what you want and what version you're dealing with. Uh, 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, uh, to do uh, even like this most simple stuff like login and authentication. So, I think if you treat it uh like a child basically and that you're going to like realize that you're going to have to be very specific uh trust but verify, maybe even don't trust and verify uh 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. Uh 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 a key to all of these is like probably the biggest thing to think about when you're going through these is uh really is like does it scale? Is this something that really actually works that the like Michael implied it's like it works but in quotes because air quotes because it's yes it does it but it doesn't really do it correctly. It may not be secure. U it may not be something that supports growth. I 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, you know, thousands, tous thousands or millions of records. It was built to do something quick and dirty with 20 records. Just like a spreadsheet, Excel spreadsheet, you can sit there and, you know, 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 that's we do this so often. It's like can't just think about what is it that you need today. Let's think about what happens tomorrow, 6 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 I'll tag this on um 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. I I know that's dating myself because every 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 5 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 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. Use multiple language models till you get comfortable finding the one that really resonates for what you're trying to do. Uh chat GPT seems to be really good with Python uh and PHP. Java at times it is way off. Uh C-pilot's getting a little bit better. Uh Claude's started dabbling in code. It's okay. Uh Weaverly, uh which was Kodium, that one's actually pretty solid. Uh Tab 9 is another good one. Uh they've they've actually been around for a while. Uh 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 uh little functions on how to do different things in Spring Boot, and you could type in like uh Java string, and it would give you all these examples of how to use the different versions of uh Java string. So, those to me are still more beneficial even than just a flatout AI uh provide coding. I I like sites that give you code examples based on what you're trying to build. Uh so just food for thought on that. Um make sure you test multiple tools and then make sure you still verify verify verify. You know, Stack Overflow, Tab 9. Uh 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 is play around with those tools because they are they do have different um 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. Um I do recommend highly starting to play around with those things. I part of the reason I use uh all these tools and I I randomly will pick a different AI engine probably every time as a Google search. I use it 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 um on my phone I've got it there. So I use it instead of like my browser window and just popping something up there. Uh 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. Um I will use it I also use it not just for searches. I do use it for quick code code cleanups. I'll do things like take this and um you know 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. Um you know there's some things like that that and 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. Um the way to do it though is keep it and it goes back to the idea of uh in all of these I think the best way is think of it as a very junior you know a junior maybe mid-level employee um 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 like you I know a lot of people I see 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 it needs and these are all the requirements. Well you haven't really walked through the requirements individually and it's going to give you a mess of 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 I need you to do that and verify that you've done it and it can be yes it can be a little bit timeconuming 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 uh 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 part of it is because the the turnaround is so fast. You can just like go boom boom boom boom. You can have a conversation and you can get something uh refined very very quickly. And it's not a the last thing I say on this one before as we're wrapping this episode up is it's not a threat to your or should not be a threat to your career or anything like that because all this is doing is uh it's doing the gathering. It is being your your hands and feet. You should still be driving it. You should be understanding that you're building this solution that you're using all pulling all these pieces together and turning it into something that is uh useful and you're being intentional about it and you're not just saying here do this thing. I'll give a quick example uh for our for the app that we did. I like said give me a landing page uh 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. um give me something that's like, you know, 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 I'm 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 pow 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 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, I was like, well, let's change this, let's do that, move that over there, change that there, let's try this, like swap this around. What if you do 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 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 like, "Oh, AI did it." Um so you know walk through those things like be very u 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 uh at least an outline. It's 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 like 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 timeconuming those are the things that are perfect for AI. I am sorry if this has been too tedious and timeconuming. It's not perfect for AI because well I don't know I 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 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. uh because AI will not be able to answer your emails properly because I know you're going to shoot us one at [email protected]. You're going to let us know what you think and uh we're going to be able to integrate that into our next round of topics and seasons even as as we move on uh that slow and steady march towards a thousand and 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. Um, also check us out on X at developer. You can check us out developer.com is really where everything lives. Uh, you can leave us comments on any of our articles, any of our past episodes. Check us out. The the developer 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 uh I think there's like 200 episodes of uh tutorials and mentor mastermind type classes and mentoring presentations and just tons and tons and tons and tons of stuff. Uh and actually a lot of it is still pretty uh you know pretty relevant. It is amazing how many uh like when we look at numbers how often some of the stuff that we did years and like five, six, seven years ago is still uh being checked out on a regular basis because it still has some, you know, is very valuable to whoever's, you know, 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. Well, so go out there and have yourself a great day, great week, and we will talk to you next time. Bonus material. I think one of the bonuses we're probably going to have to come back around to the vibe coding. I think this was like too big a too big a topic for one. Um I don't I think so sticking to like uh no code, low code. Um I'm just going to throw one thing out. It's like because you mentioned uh I think you mentioned here maybe before you mentioned Figma. I have seen so much stuff that has been done in Figma, uh, Canva and some of those and those are, as somebody that has zero, double zero artistic skills, um, those things are awesome. They've got so many great templates. They've got so many tools to help even the most incompetent artist do something that looks nice. There's lots of uh for me, I I am one of those affirming believes that the best designs are just stealing from all of the other designs and putting it together in your own little way. Uh they give you so many good options and and tools and things to make something that looks pretty good and do it on a in a fairly quick time frame. Um, so as far as like mockups and requirements and things like that, I think those are great starting points, but I would I would warn anybody that's doing Figma and they're saying like, "Okay, here's our Figma designs. That's our requirements. Go. You're you're going to be missing, I think, a lot of stuff. There's a lot of functionality usually that's going to be behind the scenes unless it's as Michael alluded to just a straightup static website where you're just doing some, you know, here's our company and here's some pictures of people and products. Um, that's great. But if you start saying, well, but now they're going to order products or they're going to be able to see reports and things like that. There's even like loginins and administering user IDs and stuff like that. Just the simplest stuff. there is more to it and you're going to need to spend some time on the requirements uh for that if you ever and as always actually one of the things info developer you can use that and if you have questions about it let us know because we can we would love to you know give you some feedback on how you can do requirements better as well because that is something that is very near and dear to our hearts and because we end up suffering the the problems when people don't get it right uh your thoughts your bonus material >> yeah so I have a whole episode idea for testing around this uh because you briefly alluded to it and I think we could really blow it up into a full testing uh discussion but sticking to low code no code uh the tool I kept trying to think of was called just in mind >> um that is it's still around the pricing has changed on it a little bit so I don't use it as much but it is great for prototyping so if you need to just do wireframing you can do that you can then convert your wireframing with low code by actually going in and writing scripts uh behind the scenes to actually give it functionality. And then it actually now allows you to deploy your apps uh to a kind of a a functioning demo kind of feature where you can actually deploy them uh and use them uh with even a little bit of additional scripting. You can plug them into databases and things like that. now. So, it has kind of gone through the whole phases of here's no code, low code, and I think they've added some AI recently for Vibe, but um don't hold me to that yet cuz I haven't really touched on the paid version of that, which of course uses the AI. Uh but where I was going with this with the testing side of things is as we discussed with AI, have that discussion with AI. If you are writing code but you don't know how to test your code or you're literally just have no coding experience whatsoever, ask AI as you're building your applications or it's building your piece of code, follow up the question, how do I test this? Write me a test for this code that you just wrote me. And the funny thing is you could actually have AI test itself. So you can take the code, drop it into your application. Then you could take the test, drop it into your application, run the test to test the code, and does it work? If it doesn't work, one, you now have a way to run it through the debugger and actually figure out how what's going on and how it works. And two, you can then throw it back to AI and say, well, hey, that code and that test you gave me, they don't work together. Why? And then it will actually have to think through and figure out what's going on. Caveat to that though is sometimes AI is dumb and it will write a test that always passes. So you do have to understand testing enough uh or at least coding enough to know when you're getting a dummy test. Uh so just a little caveat there. But if you've never written tests, it's a great way to get started. It's a great way to kind of build your test suite quickly and at least get some checks and balances in place so that you know as you're adding to your codebase if you break something because anytime you add one line of code you potentially introduce three errors. I will say that that is probably the funnest thing is having AI is like sending stuff back to AI and saying okay why doesn't this work this way this is doing this it shouldn't do that and it's oh so often it is also like oh you're right this is what it I forgot this or oh you gave me and which is actually a very good learning experience because a lot of times it'll be like oh that's right because you're dealing with this and so now you know that that this needs to be part of your conversation the next time around just like dealing with a very like an entry- level employee while you're bringing people in and you're training them up, there going to be things where you're going to realize like, oh, they don't know this. I need to specify that. To be clear, AI is very much the same way. Um, and don't trust that just like anything else. Sometimes it'll forget that that's part of the context and you're going to have to bring yourself back around to it. Uh, and as you use it more, it will like it'll blur context just like human beings do. I don't know how like Michael and I have had so many conversations over the years where especially when we get into technical stuff like he's talking about one window and I'm talking about another and we start off on the same page literally like the same screen and then five minutes later it's like wait a minute what are you talking about that has that isn't even here like oh yeah I moved on I moved to this or oh we talked about this so I thought we were going on to this page you it's like and it's the same kind of stuff you're going to have with AI AI still is not smarter than most people and so and it's going to be at least as frustrating. >> I I have to say this. So years ago when Google first came out, when search engines first started, the biggest thing that uh engineers had to figure out was how to Google Google, how to use these search engines. And the same can almost be said today for AI. You need to teach your junior developers, you need to teach people how to Google AI or how to talk to AI. You need to understand the buzzwords, the keywords, the uh I guess uh commands essentially to get AI to do what you need it to do. Same with Google. It's like if you actually type a minus in a search engine, a lot of people don't know this, the next word you put after that minus is excluded from your searches. So, you can actually do complex searches in Google, but today most people don't know that because they either rely on the AI search tools or uh the more general language now where it's like uh give me this, not this. And the AI searches automatically filter that out. But you can do all that in the search bar with just plus minus and some other commands. >> Yeah, I think this is the Yeah, these are the tools that we're getting. This is like one of those like adoption phases of those tools that it is very valuable to understand how to use them best because that's going to be that's going to start to differentiate uh everybody. I think that's there is some level of uh like everything else like the the script kitties of 20 years ago where they're just like oh okay they know and honestly they're still there. There's people out there that are doing these high-end uh Netswuite, Salesforce, Oracle implementations and things like that and they really don't understand what they're doing. We're going to see the same thing with AI. And so understanding how to leverage it and that doesn't mean that you this doesn't mean that you know like the ins and out of large language models and how to train them and things like that. Although I highly recommend you at least get exposed to that to understand some of the tools that are out there uh and what they can do and and how they even if you don't really know how to use them enough in a because you may not go deep enough in whatever that that vertical is. Um if you at least know what they are, it's going to help you immensely. So that being said, I think we've taken up enough of your time. I know we've taken up enough of ours. uh do appreciate the time that you've given us. We are going to come back. We uh actually I think we're going to continue on this one for the the next episode at least because I think we've got more than a few things. I do think we have a topic of I think a whole episode on just how like AI and testing or something like that would be uh that could be a really fun one uh is to figure out how to like get that much better. AI with testing and documentation and uh even deployments and things like that. I think could be a really cool way to uh walk through a episode. Unfortunately, it may also be two or three episodes. That being said, as I said, I've taken up too much time already. Thank you so much. Have yourself a great day and we will talk to you guys next time around. [Music]
Transcript Segments
[Music]
Press record and let's do episode two.
>> Oh, cool. You picked your camera. I was
about to suggest that.
>> Um.
Oh, how so? Because I was up here.
>> H you were way down.
>> Oh, yeah. I don't know that I changed
it. I think I just I sat differently
because Yeah, I was probably down here
because I wasn't standing up sitting up
properly.
I'm thinking um
I'm thinking dive right into low code,
no code, and vibe coding for this
episode is talk about those because
those are such big cool things right
now. And I think those are I'm seeing a
lot of that. I'm seeing a lot of
problems with that, too. And I think
this is where I think it's an
opportunity uh like every other problem
that's out there. I think we have
opportunities here on how we can help
people out. Um, and even if we're trying
to do it ourselves, how we can help
ourselves out so we don't end up getting
bit by doing an MVP that really is more
of like a proof of concept. It's really
more of a one-off and that you end up
doing an MVP and then you have to
rewrite the entire MVP.
Sound good?
>> Yeah. Yeah, I was just quickly
refreshing my memory on low code
because uh no code and vibe code I've
been dealing with a lot but I keep
forgetting about low code.
Let me do this. I will do I'll get some
officials here. So no code, low code.
Won't hurt to Yeah, wouldn't hurt to
actually put those definitions in as we
do it.
Okay. Yeah. So, low code is basically
where we're using tools uh uh what was
that tool? Uh kind of like Figma's
becoming a low code because you can uh
do wireframes and that and add code
behind them to make them clickable
demos.
>> Uh yeah, to some extent usually that's
like yeah the no code low code stuff
will do some of that. Um,
usually it's more like visual uh I guess
I typically think of it as more like
visual uh graphical interfaces coding.
Um although I guess you can do that with
no code but usually there's um
yeah you're plugging stuff in and you
are throwing a little scripting or
something behind the scenes uh into it
but
and it's really that's why I sort of
combine low code no code I combine and
most people I think do u sort of combine
those two because it's like not worth
draw distinguishing between the two. Uh
and of course vibe coding is a little
you know is different a little bit.
Yeah. So here's in short from AI no code
is no coding visual only low code some
coding visual plus code extensions and
then of course vibe coding is AI
assisted intent driven coding
uh it would even allow it's even
offering to create a whole podcast
miniseries outline under building better
buzzwords each one is an episode um
we're not going to do an episode per all
right well that sounds good so let's
just dive right into this one so we can
get going get on with our day a little
three two one well Hello and welcome
back. We are continuing season 26 of
building better developers the developer
podcast. Uh 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 to have a better
foundation in these uh 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 Broadhead. I am
one of the founders of developer
building better book developer podcast
uh site and all the stuff that goes with
it matter of fact uh 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 no
uh an technology agnostic approach We're
not going to like 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 road map that
you can come with and uh either you can
run with it or we can help you implement
that road map to make your business
better as well. Uh 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. Uh 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 road map we
talk about. Then we come back and spend
an hour with you walking through that
road map and how you can implement it.
Again, all that you can check out at
rb-sns.com.
Good thing, bad thing. Uh my this is
one. Here's one that's like a I don't
know if it's a good or bad will be part
of this. I'll just combine these two
into one story. So we're we are running
low on tea uh in one of our where we
were get 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, you know, the bad
thing was is 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. Uh 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. Uh so watch out. You
know, sometimes like sometimes you get
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 have Michael introduce
himself.
>> Hey everyone, my name is Michael
Malashsh. I'm one of the co-founders of
Building Better Developers, also known
as Developer. 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 uh helping you uh 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. Uh, check us out at
envisionqa.com.
Uh, good thing, bad thing. Uh, good
thing, good thing. Uh, well, I guess
it's a mix. Uh, 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,
well, I'm feeling better. Um, my peaks
and valleys of my uh focus have really
dropped. Uh, so I have had to slowly
increase my caffeine intake a little
bit. Uh, but unfortunately tea just
doesn't do it. It's like a little too
much tea. The flavor is not quite right.
I It just doesn't taste right to me. So,
and coffee upsets my stomach. So, I'm
dabbling again briefly. Uh, 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 uh Celsius.
And I've been trying that recently. and
one a day if I drink like half the can
uh in the morning and then half the can
at lunch seems to keep me focused all
day uh and I can just stay on decaf tea
the rest of the day. Uh and it seems to
keep me more steady uh and focused. So
uh the good and bad is uh 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. ah the
challenges of properly medicating
ourselves. So speaking of properly
medicating, I don't know if this is
really good segue segue, but anyways,
we're going to dive right into no code,
low code, and vibe coding. And first uh
let me give I want to go with a
definition of each of these just because
uh because again they are buzzy as how
they are as we're getting into it and we
talk about these uh and this may be this
could actually spelled into a second
episode but uh I want to give us a
foundation in building better
foundations for what this discussion is.
So, no code is uh and this uh I threw it
out to AI to get me some stuff off of
the internet and it's got some h pretty
decent little uh 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 tool tools as we had in no code
with some hand coding enabling faster
delivery while allowing custom
extensions. And then vibe coding is
using AI assistants like uh GitHub's
C-pilot, ChatGpt, Repliciter,
um 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. Uh 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 uh code extensions. And vibe coding
is AI assisted intent driven coding.
What I want to talk about with these is
um a little bit like when they when they
come into play, but a little bit more
about like what what to be aware of when
you're doing it. So I often see
I I 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 know
that are using
essentially
uh they're using low code tools as no
code and then they'll you know maybe use
AI or they'll maybe do a couple of
searches or something like that to find
like the little script that 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 uh 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 it to go
to or this is the the function that I
want it to execute. I'm 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 a word document or um a
PowerPoint uh you know slide or or pages
or presentations or keynote or whatever
it is whatever you want to whatever your
tool is. Um and then low code you're
doing that but then yes you're there are
going to be now you're doing something a
little more complex. So 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, um 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 a
customer where it was uh
we made it low code because we had a
couple of coded coding type areas we did
and we were able to connect to some
systems and stuff like that. Um and so
it was it was the front 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. You 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. It's got functionality that you
would expect from that kind of a
website. Once you get into any of the
real work, uh then it does become a
little more complicated. Now that
that is not like it's getting better.
There's things like um uh shoot I just
lost the name of oh like air table u
some of those kinds of places some of
those kinds of tools. Now there's a lot
of inter in integrations with those. So
now you do have like a database backend
that you can use. Uh and 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 u
pretty solid. There are some you know
there like you can build solutions with
it. It's just growing the solution I
think is where your 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 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. Basically, you have an
online marketing tool, uh, 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. and
you may have to connect it to uh 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 uh macros or
even functions within each cell to do
calculations within uh numeric
calculations. That's actual coding
people. That's not just writing
formulas. Um spent it's called VBcod it.
Uh or it was called VBcode years ago.
There's actual code behind the scenes.
It just looks like math. Uh 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. um 99% of I won't say 100% 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
uh 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. Uh so you just have to be
very careful with what you pick to kind
of build these applications uh using low
code or no code. So I will start the
vibe code conversation now and then I'll
pass it back to you. Uh 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. Um it 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 uh and can regurgitate it. But
as far as logically building you an
application, it's going to give you
peace meal based on what you're asking.
So it's like, hey, build me a login
screen. Okay, 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 uh for your
authentication, for your password
authentication? These are things that if
you're buy 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. Uh or
uh validation may not work at all. It
may make it look like it's working, but
you have essentially hard-coded values
or very uh insecure um protocols going
on when you're logging in. But it works.
You know, you build the application,
hey, I have a screen, I have a backend
piece, it works. It lets me log in. it
the problem I 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 I will say that it
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'll I do want to drop
back to no code, low code real quick
because I do think that's what they one
of the things there is that yeah, Excel,
Word, uh, 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. uh
low code where you're just doing a
little bit here and there like your uh
formulas within your cells in Excel. Uh
but then you can do full-blown coding
which is you can get back in there. You
can rewrite huge portions of it. uh I
would not recommend it because if you're
having to rewrite it's not built to be
um there are better ways probably for
you to build an application then build
it you know do everything in Excel and
then try to like under the under the
covers start adding all your coding in
which is one of the things that you need
to be concerned with is where where is
this going to go if it's a one-off if
you're doing something that is like I
just I' 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 does
it in no code or low code for 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." Uh, and that's
really where I think the vibe coding. uh
had a conversation the other day that I
the guy like just nailed it. Um and he
says, you know, I he was talking about
his experience with AI and he said it I
think of it as like a a junior or
mid-level employee is sort of what uh 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 is it's very much um
probably more a junior level than even a
a mid-level developer because it's
really it's like I have to be very
specific on what I ask. Um, I do like if
I'm doing coding, like vibe coding, I
guess is what I'm doing is I'll 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 uh 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." U the simplest things like
versions. Uh it is amazing how often you
will get code that is like on a version
of your environment that it just won't
work. U I've had all kinds of fun times
trying to get AI to understand the
difference between in the Salesforce
environments uh whether using the uh the
old UI or the new way UI and how you're
actually coding especially anything
gives you multiple ways to do it uh
which is most general languages you're
going to have some you're going to have
some fun nailing that down. Java,
there's so many different like, you
know, if you wanted to write something
that connects to a database, it's
there's a couple different ways you can
do it and you have to be very specific
on what you want and what version you're
dealing with. Uh, 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, uh, to do uh, even
like this most simple stuff like login
and authentication.
So, I think if you treat it uh like a
child basically and that you're going to
like realize that you're going to have
to be very specific uh trust but verify,
maybe even don't trust and verify uh 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. Uh 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 a key to all of
these is like probably the biggest thing
to think about when you're going through
these is uh really is like does it
scale? Is this something that really
actually works that the like Michael
implied it's like it works but in quotes
because air quotes because it's yes it
does it but it doesn't really do it
correctly. It may not be secure. U it
may not be something that supports
growth. I 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,
you know, thousands, tous thousands or
millions of records. It was built to do
something quick and dirty with 20
records. Just like a spreadsheet, Excel
spreadsheet, you can sit there and, you
know, 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 that's we do this so often. It's
like can't just think about what is it
that you need today. Let's think about
what happens tomorrow, 6 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 I'll tag this on um 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. I I know that's
dating myself because every 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 5 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
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. Use multiple language
models till you get comfortable finding
the one that really resonates for what
you're trying to do. Uh chat GPT seems
to be really good with Python uh and
PHP. Java at times it is way off. Uh
C-pilot's getting a little bit better.
Uh Claude's started dabbling in code.
It's okay. Uh Weaverly, uh which was
Kodium, that one's actually pretty
solid. Uh Tab 9 is another good one. Uh
they've they've actually been around for
a while. Uh 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 uh little functions on how
to do different things in Spring Boot,
and you could type in like uh Java
string, and it would give you all these
examples of how to use the different
versions of uh Java string. So, those to
me are still more beneficial even than
just a flatout AI uh provide coding. I I
like sites that give you code examples
based on what you're trying to build. Uh
so just food for thought on that. Um
make sure you test multiple tools and
then make sure you still verify verify
verify. You know, Stack Overflow, Tab 9.
Uh 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 is play around with those tools
because they are they do have different
um 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. Um I do recommend highly starting to
play around with those things. I part of
the reason I use uh all these tools and
I I randomly will pick a different AI
engine probably every time as a Google
search. I use it 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 um on my phone I've got
it there. So I use it instead of like my
browser window and just popping
something up there. Uh 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. Um I will
use it
I also use it not just for searches. I
do use it for quick code code cleanups.
I'll do things like take this and um you
know 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. Um you know there's
some things like that that and 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. Um the way to do it
though is keep it and it goes back to
the idea of uh in all of these I think
the best way is think of it as a very
junior you know a junior maybe mid-level
employee um 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 like you I know a lot of
people I see 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 it
needs and these are all the
requirements. Well you haven't really
walked through the requirements
individually
and it's going to give you a mess of 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 I need you
to do that and verify that you've done
it and it can be yes it can be a little
bit timeconuming 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 uh
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
part of it is because the the turnaround
is so fast. You can just like go boom
boom boom boom. You can have a
conversation and you can get something
uh refined very very quickly. And it's
not a the last thing I say on this one
before as we're wrapping this episode up
is it's not a threat to your or should
not be a threat to your career or
anything like that because all this is
doing is uh it's doing the gathering. It
is being your your hands and feet. You
should still be driving it. You should
be understanding that you're building
this solution that you're using all
pulling all these pieces together and
turning it into something that is uh
useful and you're being intentional
about it and you're not just saying here
do this thing. I'll give a quick example
uh for our for the app that we did. I
like said give me a landing page uh 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. um give me something
that's like, you know, 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 I'm 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 pow
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 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, I
was like, well, let's change this, let's
do that, move that over there, change
that there, let's try this, like swap
this around. What if you do 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 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 like, "Oh,
AI did it."
Um
so you know walk through those things
like be very u 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 uh at
least an outline. It's 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 like 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 timeconuming those are
the things that are perfect for AI. I am
sorry if this has been too tedious and
timeconuming. It's not perfect for AI
because well I don't know I 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 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. uh because AI
will not be able to answer your emails
properly because I know you're going to
shoot us one at [email protected].
You're going to let us know what you
think and uh we're going to be able to
integrate that into our next round of
topics and seasons even as as we move on
uh that slow and steady march towards a
thousand and 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. Um, also check us out on
X at developer. You can check us out
developer.com is really where everything
lives. Uh, you can leave us comments on
any of our articles, any of our past
episodes. Check us out. The the
developer 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 uh I think there's
like 200 episodes of uh tutorials and
mentor mastermind type classes and
mentoring presentations and just tons
and tons and tons and tons of stuff. Uh
and actually a lot of it is still
pretty uh you know pretty relevant. It
is amazing how many uh like when we look
at numbers how often some of the stuff
that we did years and like five, six,
seven years ago is still uh being
checked out on a regular basis because
it still has some, you know, is very
valuable to whoever's, you know,
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. Well, so go
out there and have yourself a great day,
great week, and we will talk to you next
time.
Bonus material. I think one of the
bonuses we're probably going to have to
come back around to the vibe coding. I
think this was like too big a too big a
topic for one. Um
I don't I think so sticking to like uh
no code, low code. Um I'm just going to
throw one thing out. It's like because
you mentioned uh I think you mentioned
here maybe before you mentioned Figma. I
have seen so much stuff that has been
done in Figma, uh, Canva and some of
those and those are, as somebody that
has zero, double zero artistic skills,
um, those things are awesome. They've
got so many great templates. They've got
so many tools to help even the most
incompetent artist do something that
looks nice. There's lots of uh for me, I
I am one of those affirming believes
that the best designs are just stealing
from all of the other designs and
putting it together in your own little
way. Uh they give you so many good
options and and tools and things to make
something that looks pretty good and do
it on a in a fairly quick time frame.
Um, so as far as like mockups and
requirements and things like that, I
think those are great starting points,
but I would I would warn anybody that's
doing Figma and they're saying like,
"Okay, here's our Figma designs. That's
our requirements. Go. You're you're
going to be missing, I think, a lot of
stuff. There's a lot of functionality
usually that's going to be behind the
scenes unless it's as Michael alluded to
just a straightup static website where
you're just doing some, you know, here's
our company and here's some pictures of
people and products. Um, that's great.
But if you start saying, well, but now
they're going to order products or
they're going to be able to see reports
and things like that. There's even like
loginins and administering user IDs and
stuff like that. Just the simplest
stuff. there is more to it and you're
going to need to spend some time on the
requirements uh for that if you ever and
as always actually one of the things
info developer you can use that and if
you have questions about it let us know
because we can we would love to you know
give you some feedback on how you can do
requirements better as well because that
is something that is very near and dear
to our hearts and because we end up
suffering the the problems when people
don't get it right uh your thoughts your
bonus material
>> yeah so
I have a whole episode idea for testing
around this uh because you briefly
alluded to it and I think we could
really blow it up into a full testing uh
discussion but sticking to low code no
code uh the tool I kept trying to think
of was called just in mind
>> um that is it's still around the pricing
has changed on it a little bit so I
don't use it as much but it is great for
prototyping so if you need to just do
wireframing you can do that you can then
convert your wireframing with low code
by actually going in and writing scripts
uh behind the scenes to actually give it
functionality. And then it actually now
allows you to deploy your apps uh to a
kind of a a functioning demo kind of
feature where you can actually deploy
them uh and use them uh with even a
little bit of additional scripting. You
can plug them into databases and things
like that. now. So, it has kind of gone
through the whole phases of here's no
code, low code, and I think they've
added some AI recently for Vibe, but um
don't hold me to that yet cuz I haven't
really touched on the paid version of
that, which of course uses the AI. Uh
but where I was going with this with the
testing side of things is as we
discussed with AI, have that discussion
with AI. If you are writing code but you
don't know how to test your code or
you're literally just have no coding
experience whatsoever, ask AI as you're
building your applications or it's
building your piece of code, follow up
the question, how do I test this? Write
me a test for this code that you just
wrote me. And the funny thing is you
could actually have AI test itself. So
you can take the code, drop it into your
application. Then you could take the
test, drop it into your application, run
the test to test the code, and does it
work? If it doesn't work, one, you now
have a way to run it through the
debugger and actually figure out how
what's going on and how it works. And
two, you can then throw it back to AI
and say, well, hey, that code and that
test you gave me, they don't work
together. Why? And then it will actually
have to think through and figure out
what's going on. Caveat to that though
is sometimes AI is dumb and it will
write a test that always passes. So you
do have to understand testing enough uh
or at least coding enough to know when
you're getting a dummy test. Uh so just
a little caveat there. But if you've
never written tests, it's a great way to
get started. It's a great way to kind of
build your test suite quickly and at
least get some checks and balances in
place so that you know as you're adding
to your codebase if you break something
because anytime you add one line of code
you potentially introduce three errors.
I will say that that is probably the
funnest thing is having AI is like
sending stuff back to AI and saying okay
why doesn't this work this way this is
doing this it shouldn't do that and it's
oh so often it is also like oh you're
right this is what it I forgot this or
oh you gave me and which is actually a
very good learning experience because a
lot of times it'll be like oh that's
right because you're dealing with this
and so now you know that that this needs
to be part of your conversation the next
time around just like dealing with a
very like an entry- level employee while
you're bringing people in and you're
training them up, there going to be
things where you're going to realize
like, oh, they don't know this. I need
to specify that. To be clear,
AI is very much the same way. Um, and
don't trust that just like anything
else. Sometimes it'll forget that that's
part of the context and you're going to
have to bring yourself back around to
it. Uh, and as you use it more, it will
like it'll blur context just like human
beings do. I don't know how like Michael
and I have had so many conversations
over the years where especially when we
get into technical stuff like he's
talking about one window and I'm talking
about another and we start off on the
same page literally like the same screen
and then five minutes later it's like
wait a minute what are you talking about
that has that isn't even here like oh
yeah I moved on I moved to this or oh we
talked about this so I thought we were
going on to this page you it's like and
it's the same kind of stuff you're going
to have with AI AI still is not smarter
than most people and so and it's going
to be at least as frustrating.
>> I I have to say this. So years ago when
Google first came out, when search
engines first started, the biggest thing
that uh engineers had to figure out was
how to Google Google, how to use these
search engines. And the same can almost
be said today for AI. You need to teach
your junior developers, you need to
teach people how to Google AI or how to
talk to AI. You need to understand the
buzzwords, the keywords, the uh I guess
uh commands essentially to get AI to do
what you need it to do. Same with
Google. It's like if you actually type a
minus in a search engine, a lot of
people don't know this, the next word
you put after that minus is excluded
from your searches. So, you can actually
do complex searches in Google, but today
most people don't know that because they
either rely on the AI search tools or uh
the more general language now where it's
like uh give me this, not this. And the
AI searches automatically filter that
out. But you can do all that in the
search bar with just plus minus and some
other commands.
>> Yeah, I think this is the Yeah, these
are the tools that we're getting. This
is like one of those like adoption
phases of those tools that it is very
valuable to understand how to use them
best because that's going to be that's
going to start to differentiate uh
everybody. I think that's there is some
level of uh like everything else like
the the script kitties of 20 years ago
where they're just like oh okay they
know and honestly they're still there.
There's people out there that are doing
these high-end
uh Netswuite, Salesforce, Oracle
implementations and things like that and
they really don't understand what
they're doing. We're going to see the
same thing with AI. And so understanding
how to leverage it and that doesn't mean
that you this doesn't mean that you know
like the ins and out of large language
models and how to train them and things
like that. Although I highly recommend
you at least get exposed to that to
understand
some of the tools that are out there uh
and what they can do and and how they
even if you don't really know how to use
them enough in a because you may not go
deep enough in whatever that that
vertical is. Um if you at least know
what they are, it's going to help you
immensely. So that being said, I think
we've taken up enough of your time. I
know we've taken up enough of ours. uh
do appreciate the time that you've given
us. We are going to come back. We uh
actually I think we're going to continue
on this one for the the next episode at
least because I think we've got more
than a few things. I do think we have a
topic of I think a whole episode on just
how like AI and testing or something
like that would be uh that could be a
really fun one uh is to figure out how
to like get that much better. AI with
testing and documentation and uh even
deployments and things like that. I
think could be a really cool way to uh
walk through a episode. Unfortunately,
it may also be two or three episodes.
That being said, as I said, I've taken
up too much time already. Thank you so
much. Have yourself a great day and we
will talk to you guys next time around.
[Music]