[Music] Welcome to another episode of Optimized 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 in innovations with industry experts across everything from software and venobs 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? 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. 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? Think 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 space, but they're achieving some really exciting things with it. So I'm going to ask them to introduce themselves. Giovanni or Gio, could you go first please? Yeah, sure. Thank you. Hi everyone. It's great to be here. My name is Giovanni Sarai 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. My background is in software development and architecture with more than 20 years of experience. But in my current role, I don't have to code anymore for my daily work. So I know how to create applications and that, but it's not my current work anymore. Thanks, Giovanni. Chasek, could you introduce yourself to the audience please? Hi, thanks for having me. Jacek here, I'm a global product architect, that's a one. I have a few years of experiencing IT. I've been here working in IT for over 20 years. Many of that was just an engineering and more recently on AWS. They do their work, I work with product managers, engineers and recently also AI agents. And those helped me shape, maintain and evolve our AWS portfolio for software one. For you, the agents are now a part of your team. I like it. Yes, yes, I have my new colleagues. That's awesome. So I think why don't we just kick off with a bit of a level setter for the audience? Because 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, Giovanni, from your perspective, what does vibe coding mean to you? 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. And yes, I want to yourself. So I think that there are two kind of ways you can think about vibe coding. One is this kind of like a, I read that term somewhere online, which is prompt and pray, 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 my brain works is more structured. So I think the vibe coding and the way you use it is kind of reflecting your personality and your experience, your ways of working. It also shows in how you use the tool. Awesome. I think that's a really interesting take on it as well, because we don't always get exactly what we expect when we work with any AI. It could be a chatbot and you're just talking to a chatbot 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? Yeah, I would say that even though I apply a lot of structure, there is still a bit of that prompt and pray involved. And for the audience, I want to just pick this point out, because ironically in vibe coding, there isn't actually any coding being performed by the vibe coder, is that right? Yeah, that's the general idea. The user doesn't need to know anything about coding. The coding is created, the code is created by the AI, but there is something that for sure the user needs to know, it's the requirements, the direction and what they want to build. They need to have a good understanding of what they need to build. Sometimes we have a lot of ideas of applications, but we don't have many people, the skills to write the code. So right now we can use AI to build that code for us. That's a really interesting point. I think there was actually a competition just recently, I think it was earlier on this year, from Anthropic. They did this competition where they had, there was like a hackathon using Claude's and I think they had 13,000 entrants, predominantly most of these people will have come from a development background. Two of the top three were a lawyer and a cardiologist. 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. It's really interesting that shift now from, 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. It doesn't mean there isn't value in knowing how to code and that's a different part of the conversation, I think, but huge value in the human brain power associated with why do we need to do this thing in the first place? 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. If you let me say something about that, I don't really think so because a lot of professionals already use by going to create applications, the professionals are speeding up the velocity to create applications. But for sure the users that doesn't have the knowledge to be application are using the technology to help them to build software that they need for any purpose, for personal things and even for a small application for their work. So, Gio, you just answered my next question, Ashley, which was, can it also be incorporated into the workflow which is skilled developer uses to benefit them too? You're saying yes? Yeah, yeah. Okay, absolutely. Interesting that they don't have the skills to, okay, so some five codeers 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 Yasek said about structure, the way he approaches it was structure. They must have understood something about how to structure that knowledge and structure the requirements to get what they need out. So, Yasek, 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? Yeah, so the way I like to think about that is that your skills and the way you use them kind of move up the stock a little bit. So, you kind of like play a role of someone who supervises and who structures and who guides the illustration of of the tasks. And the way I like to work is come from the idea from from a seat taught that then I will develop, build a requirements around that, but also then build some depending on the tool you use, like, for example, clothe would use skills.
Kiro has some other functions that can help you with that, with defining the requirements, design, and then splitting them into tasks, and then build them. There's. There's something that you need to apply from your. How would you normally build a piece of software, or a piece of process that you want to develop? If you're an architect who comes from the business requirement, then you translate into more technical language, and then from there you get to low-level design, and then split them into tasks, and then observe how those tasks are being developed. It just not ends there, because then you still need to have a way to monitor what's being produced, and also verify that. And what I discovered is that the more verification layer you add as early on, the better output you get. So you're saying, instead of as many people's brains naturally think bottom up, if you will, I'm going to be going to build this thing, it's going to do this thing. You actually 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. That's correct, but I also kind of like try to slow down the process, because it's easy as to ask, you know, build me this, and then look at the result, coming out at the other end. I purposefully ask to do some gates on the way, ask some questions, ask, how did you come up with this idea? Question what is being proposed. 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. You're turning it on its head. You're reversing it and saying to it, I'm not going to 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. That's the kind of framework that I try to build and force. So you've used several phrases there that make me think of, you know, IT, understanding IT, thinking a lot more like system design, right? And when I think about vibe coding and the original idea, I'm still trying to get back to that root of what is it really setting out to be? I don't know if it's as black and white as I may be making 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. I think that the people can learn how to 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, "Get me an app for that and that." And you can have 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 help you to get better results in the conversation. For example, when I start working for an application, I tend to use a chat GPD or Gemini or a 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 application, but with a good idea from the previous conversation with the AI. And even today, before start building the application, I am using tools like Google Stitch or Cloud Design to generate the visual representation of the app. This helps me a lot 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 bytecode in platform. Wow, that's a lot of scaffolding. So maybe Alex, I'm just going to ask one more question about the basics if it's okay. So a question for both of you guys, what would you say are the minimum things which someone needs to have a go at vibe coding? It sounds like we can get complex, it sounds like we can build all kinds of support structures around to make it more light to be successful. But at the heart of it is 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 going to hear more about later. But for somebody starting out, what do they need? What do they need to own or borrow to try it out? In my opinion, I think that the user needs 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, the AI is going to help then to write applications. And we have a lot of improvements in the recent times. A year ago, you asked to the AI to create application and the AI start working right now. But today we have agentic platforms. Before start building, the agent is going to ask you a lot of questions to understand. So we are going to have a better skills in the AI platform. So at the end, you need the idea. What do you need to build? What is your problem? And if you have a good understanding of that, the AI is going to help you with the basic coding writing. That's really good. I don't say yes, because there's nothing it wants to add to that. So I would say, first of all, pick one tool of choice or many to choose from. If you have a cloud code, I know this key role, course or copilot, there are many, many others, right? Choose one. Then the next step would be to maybe pick a small topic that you want to solve. So don't ask, build me another social media platform. Be right. SAP from scratch. That kind of thing. But maybe just say, automate that one, annoying thing that I do every day. Something that takes me a few steps to finish, can you automate that? Something like that. And that will just get you started. You will discover how the tool works. You will learn along the way. You will probably start building your own kind of a framework, the way you like to work. You'll find out what works, what not. And then you kind of get bigger and bigger. What I would also say is, read 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, accept. And why not? Because you can't wait to get the result and see how that's the work. I would say read what's there because sometimes you'd be surprised that certain choices may be surprising. Let's put like that. So read what's the output later on or where you have some knowledge about how to use GIT. I would say because some of those outputs may be quite verbose. So later on, it may be super helpful to switch to reading DIFs. So if you ask questions, instead of reading full output, then just focus on what changed based on what you asked for. So that's also helpful. And the other thing is, don't. 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 agent and ask, why did you design it like that? Or this is stupid idea. Do it differently. Is this the skill of the future? Right?
assertive with agents. Yeah, I think so. I tell you what though, see what you said there about 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 refer to as approval fatigue. So what I've found is the more I've used various different agentic AI systems, the more you start to trust it. But then often depending on how you've configured these things, they're constantly asking, is that okay if I do this, is that 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 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. And I loved your thought about, you know, let's not reinvent SAP or whatever. Personally, my very first experiment with this agentic AI coding was, I absolutely, and I'm going to 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 on many machines. It's never that accurate, et cetera. And so I was like, 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. 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 it. So I set out a bunch of requirements. And within 10, 15 minutes, I had something that was actually functionally working using open source voice models, et cetera. So 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 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 bit of a gochare. 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, anything that really jump out of you? Yeah, for sure. For a small things, I think that we can have a great result, but sometimes you try to build a bigger application, some complex application. And you start having issues for some things like you need to take into account security, privacy, and all other non-requirements, non-functional requirements that usually a user doesn't think. The user wants their functionality, but those things about performance, about security, privacy, and all those non-functional requirements that we as an engineers always think. So this is a topic where a user, when trying 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 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. So if you're building something really small 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 risks of something going wrong there are actually relatively small unless somebody has taken over my desktop or whatever. But the risks of if I vibe code an application that might have customer data in it or something like that, and then that application I make it available either across a internet 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'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? Yeah, sure. And maybe at some point if you go this route and you are going to publish an application that man has customer information and so on, maybe you need help because at the end, professional application can start with bifurcating but at some point you are going to need help to make sure that the application is compliant and has the appropriate, the appropriate functionalities to make sure that it is compliant with all the regulations and all the characteristics for a production application. Yeah, I completely agree and I think 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, 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. Yes, what about yourself? Which gremlins have you run into? So I would say that the biggest one is if you skip or cut corners on research and fact checking, 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 because you will face some issues where you know it was easy 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 culturally right of half of the application that you are preparing because you didn't ask to fact check something in your requirements. Yeah, but we don't know what we don't know. How can we how can we make that easier on ourselves if I don't know? Is there I always forget what the phrase is? I mean 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 are worth considering and what are the you know drawbacks of each of them. Yeah, so I can read I can do my own research maybe read some blog posts or something and then make my oldest own decision which is more conscious and then I understand why certain architecture this architecture or decision was made. I made sense. I heard 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 and so we know that most of the AI or at least the the big LLM providers their AI's 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 I found out but 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 going to be cool and you know all the positivity and it goes straight to well here's the five things that actually probably most lately 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 you say it. Yeah that's actually a really cool idea. Coming back to what you were saying yes like around you know that kind of framework right that you use it's really interesting that this I came across this post on Reddit from a guy called Sarranget Singh who said that the AI is the brick layer you are the architect do not let the brick layer design the house and you may have heard like Alex I think we were talking about this the other day people who have used a metaphor of effectively talking to the LLM vibe coding tool 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 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 and this really helped me understand what what he was talking about in terms of the need for constraints and structure in that whole process of interacting with vibe coding tool because it's a way
forcing certain behaviors using constraints, forcing certain behaviors from the LLM building the code as you vibe. And 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. So, yes, in terms of those structures, for somebody who wants to accelerate the quality of results, they're getting out of vibe coding, 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? Okay. I would highly advise reading about things like, for example, Claude Cod has all those skills, right? And those skills are almost like instructions how the agent should progress, if they're doing certain aspects of the project, right? So you can instruct it for example, not to accept the first workable solution to challenge itself, you know, and but also in your own mindset when you start working with AI agent, kind of like try to come with this mindset of challenging what's being presented, right? Something that I said previously, you know, question what you see and also ask what are the other options? That's an interesting point because we'll often, you know, it's making assumption, okay, you want to go down route A, but actually there might be route B, C, D, E and F, it just makes sense. It's just going to carry on with that unless you're asking, isn't it? It's an interesting challenge if you're not a Cod, you know, you've got to have a certain level of confidence, so actually say when it brings something back, 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 going to be like you are saying Alex, there's a problem. So back to J his point, there's a problem, there's something I want to solve. And I'm going to ask it in very simple language, hopefully clear, but simple language just make, can you five, produce me something to help me do this task and make this work? But then if I think about the way that Yask and J are using it, they're actually getting into a lot more structured approach. And like J is saying, actually bringing in almost as part of a sort of semi professional coding workflow. And you know, a lot of platforms and a lot of AI tools today are following some patterns, for example, we don't have talking from the fact that when you are building AI applications using AI, you are using tokens and you have to take into account what tokens you are using because at the end is 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 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 show you a plan to build a that house, but it's not the house that you want. And you say no, but I want that style, I want 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. A really good point and actually I think that's quite a nice segue 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 to your point Jason, in your case, you may not be super comfortable talking directly to a developer for argument sake, but you might be super comfortable talking to a project manager in terms of laying out your requirements, et cetera. And you can have the AI have different personas at different phases in that development journey. And that's interestingly the reason I say it's a nice segue is because actually I think, yes, correct me if I'm wrong, but isn't this exactly what you've experimented with? Right. So, yes, you can think of the framework as a team. That's 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 achieve. And this the output from that stage is more like a pros. It's not technical. It just explains what it is, what it will do, what questions it answers, what problem it solves. 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? Exactly. And also even then, you can always ask, you know what I don't understand. Just explain that to me in the amount of terms or explain that to me like I was never in 90. And then you kind of like switch the persona. You the next persona in my framework is an architect. So the architect will then take the product vision. And first it will turn that into requirements. And then those requirements will be refined into an architecture. But even then I have specialized architect roles in my team, in my AI team. I have data architect, I have front and architect, and they all have slightly different purpose and slightly different focus. They do research certain different areas. They propose different solutions and they create separate documents in my architecture portfolio for that project. 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 stages if you like. 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 that you can test if it works. And then what I did is I actually asked it to create a GitHub project for me. So it basically built the task list, all the tasks into GitHub project. It builds the whole roadmap 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. Again, different focus, different level of detail. And this has two functions. One function is to build a code. And then the second function is to 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 following best practice. Yeah, so that's how my framework and my mindset kind of work with relation to a and five coding. You're from a non-developer standpoint. You're able to effectively treat this as if you're working with the team of humans the same way that a non-technical person would work with the team of humans. And you're breaking it down. So each phase is getting progressively more technical if you will. But at the later stages, there's actually a lot of this is the agents almost communicating with each other via files and doing all of that themselves. So 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. And if you're building a very simple, very tiny 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 terms of complexity, breaking it down like that means it's going to be much, much easier for you and the way that you communicate, the way you understand the content, etc. One thing that is worth adding here is that at all stages, when it produces any sort of code, it is worth asking it to create documentation alongside. Because this is the part that even though I May it be.
be 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 end my experience with 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. Yep that makes sense. So I mean I think that's really good advice. Not only is it the way 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've heard of people deliberately using different models actually to check each other's homework which gives you that additional layer that you're going to catch things that maybe one model is better at than another etc. And so I'm really curious then given the experiments that you guys have been doing geo 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 the back of this. It just it does genuinely blow my mind even even this far in. Yeah sure. I going to tell you about an application that I built at the start of this year. When you know I was losing my mind tracking my kids as well because you know there is there are a lot of random events in the school and you need to track if he needs a special uniform and a special wear for that day and a lot of classes and stuff happening. After school, I've pulled that stuff I know exactly exactly what you mean. And as a part is all day okay what's the uniform for today? Today we have an event. Do we need to prepare something and it's always something from last minute that you need to resolve? So I decide to work in an application to help me to resolve that problem. So I started chatting with an AI to planning the application and at the end I use a platform to build the application for that case I use lovable that it's a very good platform that I use a lot. And I ask for that application and the initial result was not good was not what I was expecting that happens a lot but I just chatted back and forth with the AI to tweak the layout, the functionalities. I give the tool all the information. For example I export a transcript from WhatsApp group from previous year and 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 kit and they are all using the application. Also it's a good example of something that 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 platform. Is that a SaaS business, do you? Have you got the parents subscription? In the market today we have many people saying that the SaaS applications are dashing because the users are going to be able to build the functionality themselves. Yes, the so-called SaaS Poc ellipse. Yeah, interesting. Can I ask a question for you guys about actually maintaining because we've talked a bit about creation but I've got this question about maintenance. Somebody said in the past if something in technology can't be changed then it's fundamentally broken from day one because change is a constant because the needs change, demand changes you need to enhance, you need to fix and 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 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 Yasuk have talked about where lots of different parts to an application, that idea of recreating everything was scratched would sound like a complete nightmare. So how does the maintenance of these things that you created through vibe coding actually work? In my case, I use vibe coding to be a small thing so at the end it's not hard to to continue iterating but for sure in some cases at the end when I have the application working as Yasuk mentioned I put the code in a git environment in a git platform like GitHub or something like that and I download this code and work with other kinds of tools like git, GitHub, copy, load, like cursor, like Kiro and other platforms to help me to iterate and creating additional things that start as a code, vibe coding project but that moves to something bigger and I work with other tools for that case. Okay so sounds like vibe coding tools might be a good way to get started to get you going but they're not necessarily optimized for maintaining. Yeah I think that for maintaining the application if the application is because something bigger or if you have already a normal application and you need to work with that application I don't think that vibe coding was the, it's not the right path right now but you for sure can use AI with more engineering approach. Okay Yasuk what was your opinion? So I would say that for small things yes it's probably one function. If you think about the application that does one simple function then obviously maintenance of that will be easier for more complex things. The maintenance will be more difficult but this is how it worked in the old days as well right? So you had architects you have developed developers and the structure of the whole product would have to be broken down into small pieces and when you work on that you don't rewrite the whole code every time you work on it. 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 and in that way it's easier to plug in the AI agent just to work on that isolated piece of 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. I think that's really valuable advice on several different levels actually because with great complexity comes great risk right and so if you
We have these classic phrases 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 stand alone. 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 I'm coding, it's going to be a lot easier for any AI to understand a function, update that function, maintain that function, 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 feeling your way, that's an even better way to think about it, because 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 away that they integrate, you can get the AI to write integration layers. That's cool. 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 going to 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, really heading you further and further in the direction of becoming an expert with this. 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 mowing the lawn, or the dishes are nearly done, or they're about to pull up into the car park at work. So I think we're going to have to put a pin in it for just now. But as Jason mentioned earlier on, this is not the first session we're going to be talking about this topic. Our next session we want to really dive into. We've talked about it from the perspective of somebody who doesn't come from a development background. How do I get started in this? Next we're going to move into-- OK, 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, Geo, I'm going to come to you first. Could you just give us-- if there's one thing people should think about when they walk away after this session, what would that be? OK. My suggestion is that don't wait. Don't have to be technical enough. You just need to go choose one platform and start working. You are going to understand, to learn, to have more confidence at the end. You are going to understand how to build really good applications. Just go ahead and start creating some cool stuff. I love it. Don't wait. That's perfect. I absolutely love it. Yes, I think. What would you say? Well, I seconded that. Just give it a go. I would say that your first build probably wouldn't be a miracle. And in fact, it probably will be quite bad. But just do it. I mean, build something, ask it to refine that result. And then on the go, you'll see what knowledge you're missing. Then go Google your questions. Because there's plenty of YouTube channels. There's plenty of knowledge, blog posts out there. There's even anthropic, shared, full training of their platform, which is I think available for free for everyone. So that's something you can use. Just go and explore. Love it. So just like 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. So before we wrap up, I just want to thank our fantastic guests, Yasek and Geo. How can people reach you online, gentlemen? Geo, are you on LinkedIn or X or anywhere else? Yeah, mainly on X. You can find me at Sarajeo. At Sarajeo, OK? We'll put that in the show notes. And Yasek, if people wanted to follow you, connect with you, how would they do that? The easiest way would be to do it on LinkedIn. I'm available there. And you can find there. Fantastic. If you liked this episode, hit subscribe when you're podcasted at 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 @software1 just about everywhere. And you can email us as well. We are 02i. That's the letter O, number
[email protected]. With that, thanks for listening. And we'll catch you on the next one. [BLANK_AUDIO]
PodcastTranscript AI