Feeling the Vibe? How Non-Developers Are Building Apps

Vibe coding promises a tempting idea. Describe the app you want, let AI build it, and suddenly anyone can become a creator!

Building something that works is one thing, but building something you can trust is another...

In this episode, Alex and Jason are joined by Gio and Jacek to explore how non-developers are using AI to build apps, automate annoying tasks, and turn domain knowledge into working software. They unpack what vibe coding actually is, why “prompt and pray” only gets you so far, and how a more structured approach can turn AI from a clever toy into a genuinely useful collaborator.

For anyone who has an idea, a problem to solve, or a recurring task they would love to automate, this episode might be what encourages you to stop waiting and start experimenting.

Transcript

Alex 0:02

Welcome to another episode of Optimize to Innovate. This is a show where we help organizations stop wasting money on things that don't add value to their business and start understanding the technologies that actually will. Join us as we share practical insights into the latest trends and innovations with industry experts across everything from software and finops to cloud data and AI. Now we've got a couple of great guests with us today, and we're all feeling the vibe. So let's commit to starting this week's episode. Jason, what do you think?

Jason 0:32

Are you trying to pull the audience in with your puns, Alex? Don't say you couldn't comment, right? No comment. Yeah, so we're going to be talking today about vibe coding for non-developers. Um, we've been talking a lot, Alex and I, together about how AI is going to reshape the way that software is built, who's building it, more importantly, and how it's being built. So we decided to split that into two parts. Today we're going to be talking about vibe coding for non-developers. We're going to follow this up with an episode which will really be focused on the professionals, right? Thinking about developer experience and how that's being affected by AI-assisted workflows because that's changing at a rapid pace. But back to vibe coding, I'm really excited today to be able to bring two colleagues from Software One who are explorers in this area, and they're going to bring practical experience. And as they introduce their backgrounds to you, you'll hear that they're not coming from that professional um space, um, but they're achieving some really exciting things with it. So I'm gonna ask them to introduce themselves. Um, Giovanni or Gio, could you go first, please? Yeah, sure.

Gio 1:44

Thank you. Hi everyone, it's great to be here. My name is Giovanni Saray, and currently I am a domain lead for AI at Software One. I'm based in Colombia, and I work closely with our clients in Latin America, helping them to design and implement AI-driven solutions. Um, my background is in software development and architecture with more than 20 years of experience, but in my current role, uh I don't have to code anymore for my daily uh work. So uh I I know how to create applications and that, but uh it's not my current work anymore. Thanks, Gio.

Jason 2:38

Jasek, could you introduce yourself to the audience, please?

Jacek 2:41

Hi, thanks for having me. Um Jacek uh here. I'm a global product architect, that's a f one. I have uh few years of experience in IT. I've been here uh working in IT for the last over 20 years. Uh many of that was just uh in engineering and uh more recently on AWS um day-to-day work. I work with product managers, engineers, um, and recently also uh AI agents. And uh those help me, you know, shape, maintain, and evolve our AWS portfolio for Software One.

Alex 3:22

For you, the the agents are now a part of your team. I like it.

Jacek 3:25

Yes, yes, I have my new colleagues.

Alex 3:28

That's awesome. Um so I think why don't we just kick off with a bit of a uh a level setter for the audience, right? Because um I'm sure everybody who's listening to this has probably heard the term vibe coding, but I'll guarantee you it doesn't mean the exact same thing to every single person. So, Gio, from your perspective, what what does vibe coding mean to you?

Gio 3:51

Uh for me, vibe coding means using AI to help me to write applications without using any programming language, just telling the AI what I want.

Alex 4:06

And Jasek, what about yourself?

Jacek 4:09

So um I think that there are two kinds of ways you can think about vibe coding. One is this kind of like a uh I I I read that uh term somewhere online, which is uh prompt and pray, which which basically means you type ask for something and then pray it comes out nicely at the other end. And then what I like to think about vibe coding is more structured approach because the way I work, the way um my brain works, is more structured. So I think the vibe coding and the the way you use it is um kind of reflecting your personality and your experience, your uh your ways of working, and um it also shows in how we use the tool.

Alex 4:58

Awesome. I think that that's a really interesting take on it as well, because uh we don't we don't always get exactly what we expect when we work with any AI, does it? It could be a chatbot and you're just talking to a chat bot, or it could be you're actually trying to develop something. It's just that when it gives you the wrong answer and you read it, that's one thing. When you ask it to develop something and it breaks your core application, that's possibly something else, isn't it?

Jacek 5:20

Yeah, yeah. I would say that even though I apply a lot of structure, there's still a bit of that prompt and prey involved.

Jason 5:31

And for the audience, I want to just um pick this point out because ironically, in vibe coding, there isn't actually any coding being performed by the vibe coder, is that right?

Gio 5:43

Yeah, that's the that's the general idea. The the user doesn't need to know anything about coding. The coding is create the code is created by the AI, but uh there is something that for sure the the user needs to know. It's and it's the the requirements, the direction, and what they want to build. They have they need to have a good understanding of what they need to build. Uh, sometimes we have a lot of ideas of applications, but we don't have many people don't have the the skills to write the code. So right now we can use AI to build that code for us.

Alex 6:29

That's a really interesting point. Uh I think the uh there was actually a there was a competition just recently, I think it was earlier on this year, uh from Anthropic. They did this competition where they had um there was like a hackathon using clauds, and I think they had 13,000 entrants. You know, predominantly most of these people will have come from a development background. And two of the top three were a lawyer and a cardiologist. So it wasn't about them being able to develop, it was about the tacit knowledge that they had in their industry that they could then bring to bear to develop an application, which actually helped. Um, so it's really interesting that shift now from uh it's about understanding the problem now, understanding the requirements, and that's actually what's going to deliver the value at the end of it. Um, doesn't mean there isn't value in knowing how to code, and that's a different part of the conversation, I think, but but huge value in the human brain power associated with like why do we need to do this thing in the first place?

Jason 7:29

Absolutely. So to clarify, this is something which is primarily aimed at people who are not skilled developers. That's the first thing I want everyone to understand. Brilliant. Okay.

Gio 7:40

Uh if you let me say something about that, uh, I I don't really think so, because a lot of professionals already use bytecoding to create applications. The professionals are speeding up the velocity to create applications, but for sure uh the users that don't have the knowledge to build applications are using the technology to help them to build um software that they need for any any purpose for personal things and even for um small applications for their work.

Jason 8:22

So, Gio, you just answered my next question actually, which was can it also be incorporated into the workflow which a skill developer uses to benefit them too? And it you're saying yes? Yeah, yeah, for sure. Yeah, okay, absolutely. Interesting that they don't have the skills to okay, so some fiber coders don't need the skills to code, but Alex, if we think about those people in that competition, apart from tacit knowledge, I was thinking about what Yasik said about structure, the way he approaches it with structure, they must have understood something about how to structure that knowledge and structure the requirement to get what they need out. So Yasik, maybe you can help us understand like what does that structure from your point of view, if you think of it as scaffolding when we're coming to approach this task of using a vibe coding tool, what does that structure look like?

Jacek 9:16

Yeah, so the the way I like to think about that is that um your skills and the way you use them kind of move um up the stack a little bit. So you kind of like um play a role of someone who supervises and who structures and who guides the orchestration of the tasks. And the way I I like to work is come from from the idea from a seed uh thought that then I will develop, build a requirements around that, but also then um build some depending on the tool you use, like for example, Claude would use skills, um Kiro has some other uh functions that can help you with that, with defining the requirements, design, and then splitting them into tasks and then build them. There's um there's something that you need to apply from your how would you normally build a piece of software or piece of um process that you want to develop, right? So so if you are an architect, you come from the business requirement that then you translate into more technical um sort of language, and then from there you get to uh low-level design and then split that into tasks, and then observe how those tasks are being developed, but it just not ends there because then you still need to have um a way to monitor what's being produced and also verify that. And what I discovered is that the more um verification layer you add as early on, uh the better output you get.

Alex 11:10

So so you're you're saying instead of as many people, many people's brains naturally think bottom up, if you will, right? I'm gonna go and build this thing, it's gonna do it, do this thing. You actually you start at the very top, like, what's your why? What do I need to get out of this? And then you work your way down and you turn that into finer and finer granularity of requirements. Uh that that's correct.

Jacek 11:31

But I also kind of like um try to slow down the process because it's it's easy asked to ask, you know, build me this and then look at the result, yeah. Uh coming out at the other end. I purposefully ask to you know, do some gates on the way, uh, ask some questions, ask um how did you come up with this idea, question what is being proposed. Um, try to ensure that we cover all the aspects, all the avenues, and it's not just you know, first idea that is going to be productized.

Alex 12:09

So you're you're turning it on its head, you're you're reversing it and saying to it, I'm not gonna uh ask you a bunch of questions or ask you to do a bunch of things. I want you to ask me questions to really clarify to make sure that we have the right set of requirements.

Jacek 12:22

That's the kind of work and um framework that I try to build and enforce.

Jason 12:30

So you've used um several phrases there that make me think of you know IT uh understanding IT thinking a lot more like system design, right? And but but when I think about vibe coding and the original idea, I'm sort of trying to get back to that root of what is it really uh setting out to be. Um and I don't know if it's as black and white as I maybe make it in my head. So maybe Geo, you can help me with this. Is it a case of you are either a hobbyist having fun, you know, just creating apps, web apps, stuff that runs by software you didn't create using traditional methods and you don't need those system skills, or you are somewhere in that world of professional IT, whether you're a developer or not, and therefore you've got more of the mindset to understand how to drive the AI in a way for it to be successful.

Gio 13:21

Uh I I think that the people can learn how to uh have a conversation with the AI and to have better results and better applications. For sure, when you don't have any idea and you are starting, you use like give me an app for that and that, and you can have uh uh good results, not good results, you need to change a lot, you need to iterate in the conversation with the AI, but you are going to learn some practices and some workflow to uh help you to get better results in the in the conversation. For example, when I start working for an application, I tend to use uh Chat GPT or Gemini or some chat like that to give me an idea of the application to drive the what I want to build to get a good understanding, and then I use a platform to generate the the application but with a good uh idea uh from the previous conversation with the AI. And even today, before start building the application, I am using tools like um Google Stitch uh or Cloud Design to generate the visual representation of the app. This helped me a lot to be to have a better idea of what I want to build, and then I use also these visual representations to help to build the real app in a bytecoding platform.

Jason 15:13

Wow, that's a lot of scaffolding. Um so maybe Alex, I'm just gonna ask one more question about the basics if it's okay. Um so a question for both of you guys what what would you say are the minimum things which someone needs to have for a go at vibe coding, right? Because it sounds like we can get complex, it sounds like we can you know build all kinds of uh support structures around to make it more like to be successful, but at the heart of it is uh being able to use natural language, which really is setting people free to just be human, right? To talk to AI, to give it instructions in a way that we can all access. And accessibility is one of these key things that AI brings, right? That all humans can interact with it. So I know you've gone well beyond the basics in your own projects, which we're gonna hear more about later. But for somebody starting out, what what do they need? What do they need to own or borrow to try it out?

Gio 16:13

In my opinion, I think that uh the user needs need to have a good idea. I think that they need to have a good understanding of what problem they want to resolve because at the end uh the AI is going to help them to write the applications, and we have a lot of improvements in the recent times. Uh, a year ago, uh you asked to the AI to create application and the AI starts working right now, but today we have agentic platforms, and before start building, the agent is going to ask you a lot of questions to understand. So we are going to have uh better uh skills in the AI platform. So at the end, you need the idea what you need to build, what is your problem, and if you got see if you have a good understanding of that, the AI is going to help you with the um basic coding writing.

Jason 17:19

That that's that's a really good answer. Yasek, is there anything you'd want to add to that?

Jacek 17:24

So I would say, first of all, pick one tool of choice. There are many uh to choose from. You have you know Clot Code, uh AWS Kiro, uh course or copilot. There are many, uh many others, right? Choose choose one. Then the next step would be to maybe pick a small topic that you want to solve. So don't ask, you know, build me another social uh social media platform.

Alex 17:51

Rewrite SAP from scratch, that kind of thing.

Jacek 17:54

Yeah, but maybe just say, you know, automate that one annoying thing that I do every day. Uh, something that you know takes me a few steps to to finish. Can you automate that? Something like that. And that will just get you started. You will discover how the tool works, uh, you will learn along the way. You will probably start building your own um kind of a framework, the way you like to work. Uh, you'll find out what works, what not, uh, and then you you kind of get bigger and bigger. What I would also say is um read what what um what the tool says back to you. Because it's quite easy to just get to the point where you just accept, accept, accept, accept, and wait for it because you you can't wait to get the result and see how that how does it work. I would say read what's there because sometimes you'd be surprised that certain choices may be um surprising. Uh let's put it like that. Um, so read what what's uh what's the output later on, or where you have um some knowledge about how to use git. Uh I would say because some some of those outputs may be quite verbose. So later on, uh it may be super helpful to switch to reading diffs. So if you ask questions, instead of reading full output, you can just focus on uh what changed based on what you asked for. Uh so that that's also helpful. Uh and the other thing is uh don't um and this is actually quite convenient because you don't have to worry about what the other person will think about you. So it's easy to say no. It's easy to just challenge the uh agent and ask, why did you design it like that? Or this is a stupid idea, do it differently.

Jason 19:58

Is this the skill of the future, right? Being assertive with agents. Yeah, I think so.

Alex 20:04

I can I'll tell you what though, see what you said there about um the the make sure you read what it says. I have this thing which I'm seeing more and more, and I literally was having a conversation with somebody about this yesterday, something I would I would refer to as approval fatigue. So, what I've found is the more I've used various different agentic AI systems, the more you you start to trust it. And but then often, depending on how you've configured these things, they're constantly asking, is it okay if I do this? Is it okay if I do that? And you kind of get to the point where you're like, yeah, yeah, yeah, accept, accept, accept. And then suddenly you realize, oh no, I didn't want to accept that one because it's just gone and done something really stupid. So I think you're absolutely on the money there, trying to find that balance between um allowing it to be semi-autonomous and do the things for you and save you time, but at the same time maintaining that level of control by making sure you do read what's coming back from it. Um and I and I loved your thought about you know, let's let's not reinvent SAP or whatever. Um, my personally, my very first experiment with this, agente AI coding, was um I absolutely, and I'm gonna say this very politely, but I'm not a big fan of the Windows speech-to-text functionality. It doesn't work very well for me. I've tried it on many machines, it's never that accurate, et cetera. And so I was like, this what this is a thing that's really irritating me on a day-to-day basis. So what I then did was I pulled up Claude and I said, Claude, this is what I need to do. I want to be able to do, you know, speech to text, I want to be able to paste it automatically into Windows, you know. So I set up a bunch of requirements. And within 10, 15 minutes, I had something that was actually functionally working using open source uh voice models, et cetera. Um, so it it it really opened my eyes at that point to the capability and the power of what you can achieve with it. But at the same time, I saw some of the limitations and then. I did see really weird things that would happen or bits that it was maybe making assumptions. So let's kind of what I'm keen to move on to is I know you guys have been doing lots of really interesting things with this, but what are some of the things that you've run into where you're like, oh, this is a this is a bit of a gotcha when you're doing this, these are the things that have really kind of wound you up. Gio, what do you think? Are there any any things that really jump out at you?

Gio 22:24

Uh yeah, for for sure. Um for small things, I think that uh we can have uh great results, but sometimes you try to build a bigger application, some complex application, and you start having issues for some things like uh you need to take into account security, privacy, and all other uh non-requirements, non-functional requirements that usually a user doesn't think. The user wants their functionality, but doesn't think about performance, about security, privacy, and all the all those non-functional requirements that we as uh as an engineer always always think. So this is uh a topic where uh a user uh when try to build something bigger needs to take into account, and for that, for sure, they need to research and to have a greater understanding because it could be a problem. We can we see a lot of problems of people building applications and sharing applications without the proper configuration and with a lot of issues that they don't know that they have.

Alex 23:49

Yeah. So so if you're building something really small, uh in a let's call it a small closed ecosystem, like that example I gave, right? I have a speech to text thing, it's on my desktop, it's not shared with anybody, the the risks of something going wrong there are actually relatively small, unless somebody is taking over my desktop or whatever. But the risks of uh if I vibecode uh an application that might have customer data in it or something like that, and then that application, I make it available either across an intranet or even more so if you make it available on the internet, all of a sudden the risk levels go up. So we need to start thinking about okay, what are that what's that next layer that we need to add into there to make sure that this is compliant, secure, all the usual things that you would expect.

Gio 24:40

Yeah, yeah, sure. And maybe at some point, if you go this route and you are going to publish an application uh that manas customer information and so on, maybe you need help because at the end, uh professional application uh can start with bytecoding, but at some point you are going to need help to make sure that the application is compliant and uh has uh the appropriate uh um the appropriate uh functionalities to make sure that is is compliant with all the regulations and all the characteristics for a production application.

Alex 25:26

Yeah. I I completely agree. And I think that that that's the thing, though, is you can do a heck of a lot of good just with things that you can do locally on a small scale, and you can learn a huge amount. So you don't need to jump to that level. I mean, maybe you do have the most amazing business idea that's going to change the world, in which case maybe you are wanting to develop something at that level. Uh, but there's a lot of things that we can do to build our skills and to build our understanding of this technology, just solving small problems for yourself or for your team. Um, yeah, see, what about yourself? Which gremlins have you run into?

Jacek 26:02

So I I would say that um the biggest one is uh if you skip or cut corners on uh on research and fact-checking, uh that's something that if you do that, if you don't do that in the very beginning, if you don't do the proper research, it will bite you sooner or later or later because you will face some issues where um you know it was easy to to quickly check or do a proper research while preparing the requirements, but later on it will small change may lead into you know massive code rewrite of half of the application that you are preparing, because you didn't ask to uh fact check something uh in in your requirements.

Alex 26:57

Yeah, but but we don't know what we don't know.

Jacek 26:59

How can we how can we make that easier on ourselves if I don't know it's the I always forget what the what the phrase is, but I mean the the simple way to do that, and this is what I do, is I ask to give me I ask AI tool to give me like a proper spectrum of what's possible and what options uh are worth considering. And right what are the you know um drawbacks of each of them.

Alex 27:30

Yeah.

Jacek 27:30

So I can read, I can do my own research, maybe read some blog posts or something, and then make my own decision, which is more conscious, and then I understand why certain architecture architectural decision was made.

Alex 27:47

That makes sense. I I heard a uh a brilliant thing fairly recently, and I've started doing this now, and it's genuinely it's it's quite eye-opening the some of the results you get from it. Um so we know that most of the AI, or at least the the big LLM uh providers, their AIs generally want to be as useful and as helpful as possible, right? So they're always quite positive about everything. And so you almost have to get past that barrier of positivity. And a fantastic way of doing that that I found out about recently was you tell it it's six months in the future, something's already gone wrong. How did it go wrong? And so it immediately bypasses all of the, you know, everything's gonna be cool and you know, all the positivity, and it goes straight to, well, here's the five things that actually probably most likely caused whatever it was that happened in the future. And that's a great way to like start digging into those challenges that you were describing there, yes.

Jacek 28:42

Yeah, that's actually a really cool idea.

Jason 28:46

Coming back to what you were saying, um, Yasik, around um you know, that kind of framework, right? That you that you use. Um it's really interesting. The this I came across this post on Reddit from a guy called Saranja Singh who said uh the AI is the bricklayer, you are the architect, but do not let the bricklayer design the house. And uh you may have heard Alex, I think we were talking about this the other day, people who have used a metaphor of uh effectively uh talking to the LLM uh vibercoding tool and asking it to effectively design a house or build a house, let's say build a house based on some kind of vision of what it should look like, right? Without actually giving it some proper instructions as to what a floor needs to do. Right. So imagine walking into a house that you'd vibe coded and you find the floor is actually like corrugated cardboard, right? You walk on it and you fall straight through. Looks good, but it doesn't serve the function, it doesn't serve the purpose, right? And um and it's this really helped me understand uh what what he was talking about in terms of the need for constraints and structure in that whole process of interacting with the vibe coding tool, because it's a way of forcing certain behaviors, using constraints, forcing certain behaviors from the LLM building the code as you vibe. And that um that makes a lot of sense now we start to think about it, talk about it the way we have done. But again, I do think about what Alex said about you don't know what you don't know. Um so YASIC, in terms of those structures, for somebody who wants to accelerate the quality of results they're getting out of live coding, but but it doesn't have that system mindset, where would you suggest that they go to understand how they could apply some of those constraints or to think about a framework to use to shape what the LLM does to make it more usable in terms of the output?

Jacek 30:45

Okay. I would highly advise reading about things like like for example, Claude Code has all those skills, right? Uh, and those skills are almost like instructions how um the agent should progress in if if they're doing certain aspects of the project, right? So you can instruct it, for example, not to um accept the first uh workable solution to challenge itself, you know, and but also in your own mindset when you start working with uh with AI gen, it kind of like try to come with this uh mindset of challenging what's being presented, right? Something that I I I I said previously. Um, you know, question what what what you see and also ask what are the other options.

Alex 31:43

That's an interesting point because it will often, you know, it's gonna make an assumption. Okay, you want to go down route A, but actually there might be route B, C, D, E, and F. It just giving you route A to start with, and it's just gonna carry on on that unless you're asking, isn't it?

Jason 31:57

It's an interesting challenge. If you're not a coder, um you know, you've got to have a certain level of confidence to actually say when it brings something back, yeah. What are the other options? Because in theory, you know, like if it was me, I'm looking at blocks of code or it's looking at talking about libraries it could use or something like that. I won't understand one from the other, right? I won't be able to tell what's good, what's bad. But I guess you know, what we're uncovering here is the fact that vibe coding can work at lots of different levels. So for somebody like me, it's probably gonna be like you were saying, Alex, there's a there's a problem. So back to Gio's point, there's a problem, there's something I want to solve. And I'm gonna ask it in very simple language, hopefully clear, but simple language is like, hey, can you five produce me something to help me do this task, make this work? But then if I think about the way that um Yasik and Gio are using it, it they're actually getting into a lot a lot more structured approach, and like Gio's saying, actually bringing it in almost as part of a sort of semi-professional coding workflow.

Gio 32:55

Um and you know, um a lot of platforms and a lot of uh AI tools today are following some patterns. For example, uh we we don't have token uh uh from the fact that when you are building AI application applications using AI, you are using tokens and you have to take into account uh what uh tokens you are using because uh at the end it's going to have a price, you need to pay a price for those tokens. So, a good approach that I think that the most of the tools have today is that you don't start building, you start planning, and you chat with the AI and you say, I want an application for that and that and that, and uh the AI is going to suggest a plan to build that application, and you need to read that plan. And for example, you ask, I want a house, they they they show you a plan to build that house, but it's not the house that you want, and you say no, but I want that style, I want uh three floors, I want that and that and that, and the AI is going to help you to refine the plan, and when you are happy with that plan, you start building the application.

Alex 34:26

It's a really good point, and actually, I think that's quite a nice segue. Um, because one of the things that we can do with AI, and we've been doing this even when we were doing chatbots, is you can give it a persona, can't you? And so uh to your point, Jason, in your case, you may not be super comfortable talking directly to a developer for argument's sake, but you might be super comfortable talking to a project manager um in terms of laying out your requirements, etc. And you can have the AI have different personas at different phases in that development journey. And that's interestingly, and the reason I say this is a nice segue is because actually I think yes, it correct me if I'm wrong, but isn't this exactly what you've experimented with? Right.

Jacek 35:12

So um, yes, uh you you can think of um the framework as a team. That's uh how I like to think about that. You have a stage where you work with a product manager, someone who will help you define the vision of what you are trying to uh to achieve. And this the the the output from that stage is more like a um a prose. It's not technical, it just explains what it is, what it will do, what it what and what questions it answers, what what problem it solves.

Alex 35:49

And then you don't need to be technical as long as you can read and you understand the subject matter. That's absolutely at Jason's level. Is that right, Jason?

Jacek 35:57

Exactly. And also, even then, you can you always ask, you know what, I don't understand, just explain that to me uh in Layman terms, or explain that to me like I was never in IT. Um and then you you kind of like switch the persona. You the the next persona in my framework is an architect. So the architect will then take uh the product vision and first it will turn that into requirements, and then those requirements will be uh refined into an architecture. But even then, I have specialized architect roles in my team, in my AI team. Uh I have you know data architect, I have front-end architect, and they all have slightly different purpose and slightly different focus. They um do research certain uh different areas, uh, they propose different uh solutions and they create separate documents in uh in my architecture portfolio for that project. Um later on we kind of pass that into dialogue between architect and project manager, and they build a roadmap plan for me. So that roadmap plan is dividing the whole architecture into chunks of workable uh stages, if you like. Uh, and then though each of those stages is divided into tasks. Each task is by definition something that you can start, build that, and you have one deliverable deliverable that you can you know test if it works. Um and then what I what I did is I actually asked it to create a GitHub project for me. So it basically built the task list, all the all the tasks into GitHub project. Uh, it builds the whole roadmap, uh, dependencies, and you can see all that in GitHub. And then you pass that into another persona, which is a builder. This is your developer. Uh again, different focus, different um level of detail. And this has two functions. One function is to build a code, and then the second function is to uh verify that code, to basically read that and do a quality check and verify if it's correct, if this will work, if this is uh following best practice. Um, yeah, so that that's how my framework and my mindset kind of work with relation to AI um and vibe coding.

Alex 38:48

So you're you're you're from from a non-developer standpoint, you're able to effectively treat this as if you're working with a team of humans, the same way that a non-technical person would work with a team of humans. And you're breaking it down so each phase is getting progressively more technical, if you will. But you're at at the later stages, it's actually a lot of this is the agents almost communicating with each other via files and doing all of that themselves. So you you almost don't need to necessarily, as that beginner, fully understand all of that yet until you've built confidence, you've built more of an understanding of this stuff. Um, and if you're if you're building a very simple, very tiny little, you know, a little tool for your desktop, you don't necessarily need to go to that extent. But as soon as you want to start progressing up that tree, if you will, in in terms of complexity, breaking it down like that means it's gonna be much, much easier for you. And you the way that you communicate, the way you understand the content, etc.

Jacek 39:42

Um thing that is worth adding here is that at all stages, uh, when it produces any sort of code, um, it it is worth asking it to create documentation alongside. Because this is the part that even though I'm maybe not familiar with certain technologies or certain coding languages, I can read the documentation of that piece of a code, and based on that, I can and my experience with um uh small experience with coding, I can kind of try to understand what was done here and why the logic works like this and not the other way around. And I can then start questioning like, look, you've written something, but how the user who uses that will actually interact with that piece of code. And then based on the conversation we have, I can make some decisions. You know what, this is what this was actually a wrong decision, let's change it, even though I don't understand the code itself.

Alex 40:46

Yep, that makes sense. So, I mean that I think that's really good advice. It not only is it the um the way that you play it back, but also even getting it to check its own work. Like checking its own homework seems like a very valuable thing. And I've I have heard of people deliberately using different models actually to check each other's homework, which gives you that additional layer that you're gonna catch things that maybe one model is better at than another, etc. Um, so I'm really curious then, given the experiments that you guys have been doing, Gio, if we come to you, like talk us through a little bit about some of the stuff that you've been doing with this because it's incredible what one person is able to deliver out of the back of this. It just does genuinely blow my mind, even though even this far end.

Gio 41:31

Yeah, yeah, sure. Um I'm going to tell you about an application that I built at the start of this year. Uh-huh. When uh, you know, I I was losing my mind tracking my kids' schedule. Um because uh, you know, there is uh there are uh a lot of random events in the in the school, and you need to track uh if he needs a special uniform and speech and special wear for that day, and uh a lot of uh classes and stuff have happening and after school clubs, all that kind of stuff.

Alex 42:19

I know exactly what you mean. Yep.

Gio 42:23

And as a parent, uh all day, oh okay. What what's the uniform for today? Today we have an event. Uh, do we need to prepare something? And uh it's always uh uh something from last minute that you need to resolve.

Alex 42:38

Yeah, so I didn't tell you about the night before. Yeah, I love those ones, that's really good.

Gio 42:44

Um, so uh I decide to uh work in an application to help me to resolve that problem. So I uh started uh chatting with an AI to plan in the application, and at the end I use uh a platform to build the the application. For that case, I use Lovable, that is a very good platform that I use uh a lot, and uh I ask for that application. And the initial result was not good, was not what I was expecting. Uh that happens uh a lot, but um I just uh chatted back back and forth with the AI to tweak, the the layout, the functionalities. Uh I give the tool all the information. For example, I export a transcript from a WhatsApp group from previous year and use an AI model to help me to find the events that we have the previous year because. My assumption was that this year is going to have similar events in the school. So I give that information to the AI, I give the list of holidays for Colombia to the AI, and all the information that I could get. And at the end, I have a working application, a simple working application, but I was able to share with all the parents from the course of my kids, and they are all using the application a lot. So it's a good example of something that may many times you have the idea to build things, but I don't have the time to code that for myself. So I use the platform and I don't even read the code at the end. I just tested the final result and it was good for me. And at the end, it was a good exercise to use this kind of platforms.

Jason 45:05

Is that a SaaS business, Gio? Have you got the parents on subscription?

Gio 45:11

In the market today, we have the uh many people saying that the SaaS applications are dodging because the users are going to be able to build the functionality themselves.

Jason 45:26

Yes, the so-called SaaS Pocalypse. Yeah. Interesting. Can I ask a question for you guys about um actually maintaining? Because we've talked quite a bit about creation, but I've got this question about maintenance. But you know, I've somebody said in the past if uh something in technology can't be changed, then it's fundamentally broken from day one, right? Because change is a constant, because uh the the needs change, the demand changes, you need to enhance, you need to fix. And I maybe I've got the wrong end of the stick here because when I think about generative AI, a lot of the time you end up going through this just this cycle of recreate, recreate, recreate, trying to get to the right thing. But when you start to get into more complexity, like some of the stuff that you and Yasik have talked about, where you know lots of different parts to an application, that idea of recreating everything from scratch would sound like a complete nightmare. So, how does the maintenance of these things that you've created through vibe coding actually work?

Gio 46:28

In my case, I use by coding to build small things. So at the end it's not hard to continue iterating, but for sure, in in some cases, at the end, when I have the application working, uh as Jasek mentioned, I put the code in a Git environment, in a Git platform like GitHub or something like that, and I all uh I download this code and work with other kinds of tools like GitHub Copilot, like Cursor, like Kiro, and other platforms to help me to iterate and creating additional things that start as a bytecoding project, but that moves to something bigger and I work with other tools for that case.

Jason 47:25

Okay, so it sounds like vibe coding tools might be a good way to get started to get you going, but then not necessarily optimized for maintaining.

Gio 47:34

Yeah, I think that for uh maintaining the application, if the application is become something bigger, or if you have already a normal application and you need to work with that application, um I don't think that bytecoding was the the is not the right path right now, but you for sure can use AI with more engineering approach.

Jason 48:05

Okay, Jasek, what was your opinion?

Jacek 48:08

So I would say that for small things, yes, it it's it's probably one function. If if you think about the the application that does one simple function, then obviously the maintenance of that will be easier for more complex things, the maintenance will be uh more difficult. But this is how it worked uh in the old days as well, right? So you had architects, you have uh developers, and the structure of the whole product would have to be um broken down into small pieces, and when you work on that, you you don't rewrite the whole code every time you work on it. Uh you kind of ideally split that monolith into smaller chunks that work in isolation, and then you can work and update and maintain those isolated parts. Uh and in that way, it's easier to um plug in the AI agent just to work on that isolated piece of uh software to improve that one thing. And then you can, for example, if you have a big platform and you have a bug in one of the functions, you don't ask the AI agent to fix the platform. You just say, look, in this component, there is a bug. This is the error, and can you focus on that? Try to isolate and find out why we are having this issue, and then just fix this one small thing and please do not touch anything else.

Alex 49:46

I think that's really valuable advice uh on several different levels, actually, because um with you know with great complexity comes great risk, right? And so if you uh we have these classic phrases in in IT about building monolithic applications, for example, and for the past 15 years, we've all been moving towards trying to break down these traditional monolithic complex applications into small parts and make them more atomic, more standalone, and they plug together to provide an application. Yes, you gain other complexity there, but especially I think if we move into this next generation era where we're doing a lot more vibe coding, it's gonna be a lot easier for any AI to understand a function, update that function, maintain that function, add, you know, add capability to a function rather than having to do it across the entire architecture. And if you're somebody who's completely new to this, you're you're feeling your way, that's an even better way to think about it because you can you can write a function that does a thing, you get some functionality, and then you write a separate function that does something else. And as long as you've written a way that they integrate and you can get the AI to write integration layers, that's cool. Um, then it will make it a lot easier for you to then maintain it in the long run. And the more functions you write, actually that comes with the confidence that you're gonna gain. The more you're doing this, the more practice you get, the more confident you get, and then the easier all of these concepts become that we've been talking about today, um, really heading you further and further in the direction of becoming an expert with this. Um, I would I could literally talk about this for the next two hours very happily, but I suspect there will be people who are just about to finish money the loan, or the dishes are nearly done, or they're about to pull up into the car park at work. Um, so I think we're gonna have to put a pin in it for just now. But as Jason mentioned earlier on, this is not the first session we're gonna be talking about this topic. Um, our next session we want to really dive into, okay. Let we've talked about it as from the perspective of somebody who doesn't come from a development background. How do I get started in this? Next, we're gonna move into okay, now you're a professional developer or you run a team of professional developers, how can you take advantage of this technology? So before we close it out, then um, Gio, I'm gonna come to you first. Um, could you just give us, you know, if there's one thing people should think about when they walk away after this session, uh, what would that be?

Gio 52:16

Okay, uh my suggestion is that don't wait. Uh don't have to be uh technical and note, you just need to go choose one platform and start working. You are going to uh understand, to learn, to have uh more confidence, and at the end, you are going to understand how to build really good applications, just go ahead and start creating some cool stuff.

Alex 52:48

I love it. Don't wait. That's uh perfect. Uh I absolutely love it. Um, Jasek, what about yourself?

Jacek 52:55

Uh well, Isaac on that, just you know, give it a go. Uh, I would say that your first build probably wouldn't be a miracle. Uh, and in fact, it probably will be quite bad. Uh but uh just just do it. I mean, build something, uh ask it to refine that result, and then you know, on the go you'll see uh what knowledge you are missing. Then go Google uh your and your your questions because there's plenty of YouTube channels, there's plenty of knowledge blog posts out there. Uh there's even Anthropic um shared a full training of their platform, uh, which is I think available for free for everyone. So um that's something you can use.

Alex 53:48

Just go and explore. Love it. So just like uh the first time you hit a golf ball or shoot a basketball, you're not exactly going to be an absolute expert. We should think about this as a skill in the exact same way. Exactly. Fantastic.

Jason 54:04

So before we wrap up, I just want to thank our fantastic guests, Yasek and Gio. Um, how can people reach you online, gentlemen? Um, Gio, are you on LinkedIn or X or anywhere else?

Gio 54:17

Yeah, mainly on X. Uh you can find me at SaraiGio.

Jason 54:24

At SaraiGeo. Okay, we'll put that in the show notes. And Yasek, if people wanted to follow you, connect with you, how would they do that?

Jacek 54:31

Uh the easiest way would be to do it on LinkedIn. I'm available there and you can find me there.

Jason 54:38

Fantastic. If you like this episode, hit subscribe on your podcast app and leave us a review. It helps more people find us. And if there's something you want us to cover in the future, then please do get in touch. Don't hesitate to leave us a comment or let us know via socials. We're at Software1 just about everywhere. And you can email us as well. Uh we are O2i. That's the letter O, number twoi, at software1.com. With that, thanks for listening, and we'll catch you on the next one.