Vibe Coding for Grown-Ups - AI in Professional Software Development

(upbeat music) Hello and welcome to Optimize to Innovate, a show where we help organizations stop wasting money on things that don't add value to their business and understand the technologies that actually will. We've got a couple of great guests with us today. So let's find out whether vibe coding is a shortcut, a superpower or just technical debt with really good marketing. And let's commit to this week's episode Jason, what do you think? Absolutely. The world of software development and creating value through code has been changing dramatically over the last 12 to 18 months. And we did the first episode, which was looking at vibe coding and how it can help people who are not professional developers to really be able to do amazing things using some of these models, which have been trained specifically to help bring coding excellence like world class coding capability to ordinary people if they know how to use it. Now today on the episode, we're really digging into what it means for professional developers to have AI coming alongside them, working between them amongst them as teams. Thank you very much about the corporate, the enterprise world and what the future looks like for this group of people. So I'm really pleased to be able to welcome two people are very deep into this in our organization, Sebastian and Pavel. So Sebastian, would you like to introduce yourself first and then Pavel, after us, please? Yes, sure. Hi. Hi, I'm Sebastian Brandt. I've been a professional software developer for 20 years now. And today I'm working as a principal application architect here at Software One. Yeah, my day-to-day job mainly is architecture decisions called reviews mentoring and also a good bit on pre-sales for critical infrastructures and everything. So yeah, that's me. Thank you. Hi, I'm Pavel Stuchinski, working IT like 18 years, I think, for now being a game developer, dev-ops developer, trainer, doing a lot of stuff, currently focusing on the platform engineering, consulting, implementation, GitHub platform. And of course, a lot of co-pilot things around that one. So safe to say we've got a couple of experience developers on the call today, I think. So we're gonna start you guys off easy, right? Because this is, or maybe it's not so easy, I don't know, we'll see. And what I was quite curious about was, from your perspective, do you think that the definition of a developer has changed in this whole new world? Or do you think that really it's more about development as a role has almost just moved up a level? What do you reckon, Pavel? So I think it depends how, who is looking at that one? In my opinion, as a developer, the definition didn't change. It's the same person that need to know quality of the code is behind the scenes. But I speak a lot of people, there are not developers, and they think now they are developers, because they can wipe code something. But at ends, it's always finishing it. I look at the code was generated there, and this amount of surprises. So definitions, I think the same. But we have now new experience that we need to have it, like we need to better review what is generated, what is in our repository. So shifting the balance of what you're doing day to day from the generation more to the review of that code? Yeah, I think that's more like about reviewing code was generated than writing the code. But I still want to keep balance. I'm trying to don't use AI for every simple thing, like, you know, at a new line, the code, or something like that. Still doing like my best approach to like do as much as possible for the commit, so small commit, small changes. So it is easy to understand by other team members here. Interesting. And what do you think Sebastian? Yeah, I'm definitely on Pavis site. So it's developer is still a developer. So his goal is to write code. And yeah, some things have changed, because we've got introduced a new tool. It's called AI or LLM, however you want to call it. And it helps us to write more code, more code, to write faster code. It also makes some of the developers life harder, because they have to, wherever you're more code, of course. Yeah, but at the end, we still need to develop processing. Do you think just almost a bit of a follow up there? Do you think that there's a danger that we just end up continuing? The more of this code that gets generated, the more that that role shifts towards the review rather than the creation. Do you think we end up overly trusting it? And it just ends up in a position where some of that code is going to slip through that's not so good? Of course, this is this is this is this chance is there. So that you it's totally easy to write some prompts and get a software out and click through it and think, well, well, it's definitely what I wanted. And I took me not one week. It took me to prompt or something like this. And when you trust it, when you overly trusted and don't do this, what Pave said, small commits, you still need to do small commits, read code and understand what's actually happening there, because if you don't do this, you're getting into trouble sooner or later. So at least it's my experience. And thinking about the way that we use the specialized generative AI tools, you mentioned, LLM's there. And I think it's really important to just point out to our listeners that when generatives AI first came out, it was a very general purpose technology, right? It really was. But what we're looking at now is models which have been shaped through the data they've trained on, the way they're refined to become expert programming assistants, right? Like world-class competition, winning expert coders. So how do you best use one of those and what you're doing, Sebastian's? And the question I'm thinking here is, like where does it feel most useful to bring them into the process of developing code? Is it building prototypes? Is it actually helping create internal tools? Is it automations or is it actually just building production applications? Is there an area where you think they excel? Or are they actually just so good around? - So the short answer is yes. (laughing) Yeah, so I would say even on most of it, on all of it, what you mentioned. So of course, prototypes, this is, so this we all know. So it's really fast to get prototypes out of us. And yeah, when you're on pre-set situations, talking to customers and they are saying that they want to see some kind of dashboards or something, these type of numbers. Then you just put a prompt in, go to Cloud Design or something like this and put a prompt in. And you get a dashboard created and show it to the customer and say, yeah, that's exactly what I need. Or no, no, this number is wrong. I need something else here. I need to see this more. So this, you are faster in prototyping and talking to the customers. You are getting feedback for the customer. You can do it live. So normally you would talk to the tech, so in the older days, you went to the customer, went to in a workshop, you get all the requirements or you tried to get all the requirements, went home again, prepared some dashboards and so on. And now you can do it live. You can simply do it live just with a prompt. And this makes you much faster. And this is, therefore, it's very, very useful. But also when you are going to code, yeah. I have to implement your stories as a developer. Of course, you can create your development plan. You can also use it for checking if you took everything into account, but you actually need to fulfill the story. Also there, AI helps you. And then when you go down the bottom line, when you commit the code, when you push the code, the code needs to be reviewed, of course, by another teammate, but also now by AI. So we are also using AI for code reviews. It also is very, very useful there, because it can do much more than I can. So just from context or brain context window. Yeah. So, and of course, at the end, automation, deployment, testing, all of this is useful. So it's not, it's not the silver bullet. You still need to know what you do. And you need your experience at front sometime, from time to time. Let's say it like this. But it will help you everywhere. It's my experience. And a question for you, maybe this is for Pavel. So if we're saying it's great for prototypes and for automations, if we think about production applications, so say we're using Claude or get up code pilot or something else like that, and it's building code for us for a production application, we need people in front of the screen who understand what good looks like, right? Who can, who have that reviewing skill? Who have enough of an understanding of what the structures and the way the modules being built should look like to judge whether what's being created is good or not. So is that, from your point of view, is that, is that still the main boss will neck? If we talk about AI helping make development more efficient, is reviewing still Is it the bottom neck I guess is what I'm asking. So it may or it is bottleneck currently. We are engaging a lot of clients currently with the advisory about on the boarding to copilot things to like adoption of copilot. The question that is always happening from the clients is that how can how can how we can measure measure that is the quality of this the colors are doing is good with the AI. That's like for now is a big question mark how to measure it because like what we're as a goal we're working with this ROI thing and approach was very simple. Just we need to count how many licenses are there? How many lightings of this are used? And this is like a right for AI tools like because it was only a chat there at the beginning and just maybe small very simple agent that call edit your files. Now we have a lot of tools agents forms skills and other things. And clean start like asking, okay, we have developed this kind of feature. The developers mark them as done. But it was productive or not. How big effort was behind is how to measure the value? How to put price on it because even now is probably how to give values to new future like someone is asking for the future in future before I say it will be 80 hours. But now it is like big question how much will time take and how how quality will behind the scenes? So going back to question original question. And again, this is bottleneck but we have also roles in the company that are developers are doing only code review. Yes, it is code. Okay, it's safe. Of course, we have high press there. There's got scanning tools that can check quality. But that at end, there are product managers, product owners, someone who requested the future for the application. That teams need to be involved now more like to test, create a quality tests. In my experience, there's a lot of clients that are looking at the cost of the project and they find that finding out that to lower the cost, we don't need tests. We don't need quality assurance team here. Why we need them here. Developers, developers can test here. What is not true because I went and was as a game developer, the testing team was very important. That even fight between developers and testing teams because there was a example we was doing games for Nintendo and the submission of the new game was so difficult from not even functional way of the game, the story and the quest, but from the technical way, how the game boy will behave and you close the lead when you open it. So that was that also to be including tests, how it will behave on the Firefox from the explorer, not only in my local environment that I have, you know, everything perfect. Yeah. That's interesting because you're taking effectively, we're stripping out cost, if you will, for the cost of generating and writing that initial code, which is great. We're accelerating the left hand side of the process, if you will, but actually what that is going to mean is we do need to have a more of a focus on the right hand side of the process. And probably that by that additional focus, then actually realistically costs are going to probably go up a little bit around that QA and QA into production kind of a process. Yeah, I think we can now produce more. We can create more software, few prototypes. A lot go through the a lot, a lot of like ideas, you know, always have team brainstorm and we find it out the best idea. Now you can select two ideas and go with two ideas and check them at end. But it means that at end, someone need to validate that one and I think now, like the companies that are, you know, they know what they're doing, they will invest more such teams like QA, product manager, because it will be, we'll produce more. So we need to test more it, yes? Yeah. And you can pick up on something that both of you guys mentioned earlier on actually in passing. And you were both talking about the size of your commits and why the size of the commits is so important. So I'd like to move us into a few practicals as we go through this. So we can, you know, our audience can have some takeaways of what you're actually seeing day to day and what works and what doesn't work, et cetera. And so Sebastian, I think you and Pavel both said it's incredibly important regardless of it's a human or an AI that's doing the coding that we should do small commits. Can you just dig into that? Yeah, sure. So it's not only small commits, but also small progress or reasonable size pull requests, let's say it like this. The important thing is that the very needs to understand or to what's in there. Yeah. And of course, with a lot of small commits in a pull request, you have a some kind of roadbook, how the developer achieved the pull request. Yeah. And with the pull request also having it not too big, having it, I don't know, I mean, the number is there's not a fixed number. Where you cannot say 10 is good and 20 is bad or something exists, but I'm pretty sure or for me, 200 files are bad because I cannot read 200 code files and say it's working or it's not working or it's good or bad because I start reading and after 10 minutes, I'm my brain is dead. Yeah. So, so this is, so you need to understand what's there. When you read, you need to understand it's like, it's, yeah, it's letting like reading a math book or something like this. You cannot read half the math book and send the, say it's correct or wrong. It's not possible. So you can only read one page and decide. And that's the same pull request. Yeah, I totally agree with that one. You can always assign to the review our AI tool and I can review for it for you. What, what will actually end up with that massive amount of the comments and suggestions to change something? What will be worst situation like you and it's like not ending club. So, yeah, in most of cases, 200 files is bad thing. It's good when doing some kind of formatting fixing or something like that. Some like that. But, but yeah, I like to not mix features because, no, looking past when I double the following new feature, it would take, for example, one day, at and they have some kind of few comments that I used in locality to write my job and one prequests with this five of six comments, let's say. But now you can have feature in five minutes. So it means that every five minutes you can do a prequests, yes. Not, you know, and you can be being bored of that. Oh, again, I need to create prequests. Why I could commit directly to the main branch and get forget about that one. So, then I guess to try and bundle together multiple different features and pull requests into one just for the sake of reducing your admin overhead. But actually, then you're introducing way more risk. Yeah, it's easier now to have like one big commit at end of day with the five massive features. And what we want to regret it. One of it for for us is we switched a bit the work or the work mode. So prequests are not they get reviewed by AI for us. So we have small prequests and we have automations there. So which, yeah, some using GitHub code, how's it called? For public. Quality code. Yeah, code quality checkers with some words. Some there's a normal words and some custom words. And we also use GitHub. Agente workflows to check these pull requests against requirements. So we connected it to Jera. Or I think I think I have to call it Jira. We connected it to Jira and and it's checking back. It's actually checking back. Okay, what are the exceptions create here? Are they met or they not met which or maybe are the words to develop or working against it? So it's doing something different and didn't read properly or something like this. So this is a fast check and this fails if it's not correct. But if everything is fine and if these code comments, a code quality, the code quality scan gives you are resolved or at least closed with a comment. Then the pull requests gets much automatically without having a look from me. I look at it later because it's not so we cannot. I cannot where we are every pull requests in time now because if as probably said, if you have need five minutes, okay, maybe it's half an hour for a big for a feature. Then you still get I don't know 16 features a day. But I won't develop and I have a team of four developers. So you can think of the workload I'm not getting. So we have to improve here. But it's not that I'm not reading the code. I just that I'm just using also a I to quantize the risk for specific pull requests. And I have sent it at the end of the day or at the beginning of the next day. I have a list of pull requests in order, which I have to look at. And with high risk and low risk and so on. And then I go for it. And if I've enough time. I go through all of it if not I skip something and then we have meetings during a week one or two one to two depends a bit on the project Where we go through the risky pull requests and talk about it together as a team afterwards It's already merged. It's maybe even more already in production, but we are talking about this Yeah, and also fixing things then because we are fast to fix things so So this changed completely definitely Let's see a fundamental ways of working are completely different in this world At the not just the volume and the throughput and all those things, but actually your day-to-day operations are fundamentally changing Fascinating as well that you can also plug in you're really thinking about it from a Requirements perspective as well. It's not just building out a whole load of code You're actually double checking back on really what was being asked in human speak of the developer in the first place via the gearticket Yeah, I love it I love it approach because I was doing few speaks on the conferences last time about this aggantic workflows and everything is about If the developers of team know that the agent is not only for generated code But you can also use it for the other task. I divided quality review something even the credits report for daily stand-up weekly stand-up whatever but adding This other extra things that can be used to make it better like to Decrease this noise of the code generated It will have so the developers teams need to be aware that it's not only code generator things This is the thing that can also validate what's related if you use proper tools. Yeah, so so yeah the documentation Requirements creation today. I was working for the one client and we were working about effort for the immigration for one platform It was like I think I should have also GitHub but we use the outputs from the Our discovery tools that just listing the number repositories number pipelines and etc and stuff Versus our original plan versus Problems that client provided us so we get the notes from the meetings I have former position I put the notes for everything and running a positive this knows using as To modify the whole migration plan to find the Spots what could be problematic well when where you can save time where we can save the time to register all answers there and and then at end I can even create some kind of Automation scripts to help me with the bunch of the migration stuff and co-generations. Yeah building out your stories as well even in the first place based on those on those meeting notes Yeah, that makes sense and I guess it would also the this New way of working if you're an organization or a team that is not familiar with Say proper use of pipelines Uh, in your you know, you're regardless of the fact you're using AI You're maybe starting to maybe I'm wrong here, but it sounds like you might be setting yourself up for failure without having some of those fundamentals in place because What you're suggesting here is Because of this volume because we're now using other AI agents to be actually doing code review to do static code analysis Security reviews other bits and pieces you need to have that pipeline in place which has a mixture of traditional automation uh AI based automation and review and then human review within that pipeline Yeah, yes, yeah It's otherwise yes Like simply triage of the issues every day you can just throw out out of the the issues that the dot have any comments or just towards their like fix that this is not working the lot of things like you know I have a lot of friends that are putting in the issues exception Nothing that I could understand like We're talking about the problem now we're writing in now like fix this problem A naming problem with the two words and after one month because it was not important today But after one month we stick down and we Don't know what is what is to do so Very simple task like if you have a big project there's a lot of communication happen You can also use a agent to trash issues or clean up the noise yeah And uh the thing is it's like this why I also said it's not it's not a silver bullet because it's a tool and uh You still need your your development background or you need or at least you need to know how to use the tool and if If you don't know or if you for example trusted too much it everything gets worse. Yeah, so it's uh I see what what I see here is High potential teams are stay high potential. So they they they get faster as they get more output and so on But for not high potential teams they're falling back. Yeah, even when they're using AI They are producing more bugs having more problems. So you need this You need to be a good team otherwise it won't work Yeah, that's a really interesting point that you know we Alex you make the joke about um, you know, we just we just producing technical data fast to rate right because If you're not doing it right that absolutely could be the case and we've already talked about bottlenecks um So it's clear that we're getting to the point where It won't be hard based on what you've been saying Sebastian Pavley won't be hard to produce more code Then we actually have time to review So it's not just a question of They're being a backlog, but that backlog could grow exponentially Because it's a limited number of people that can review or waste review versus waste to create um Which makes me think about the overall process and makes me think about team um because when we think about DevOps You know an agile these were effectively Designed they were they were people's ideas about how could we create it the ultimate or the optimal way For people doing software development Which involves communication involves interacting with other people to work together to to be better together and my question actually is around this concept of Developers leading Teams of agents. I'm interested in understanding what does it look like for developers to lead a team of agents? And how does that then change the dynamic between People within a team who are real human people developers interacting communicating together It's an interesting question. I take it because uh I I connect about this um when when I started to work as an as an architect I got my team when we were working on and was a tech lead on the project and Yeah, of course I had to Mentor the team. I have to look as I said code values also very important But of course also talking to the team and to do a single developer and telling them okay We have to do it this way because it's okay to do it this way, but for our project here We have we need to another approach because of this as it is and um the funny thing is now it it really for for every developer He has to do the same now but not to the team but to his agent team He also has to go to the agent team and tell him okay. It's a good approach good idea But maybe it's not the perfect one for my solution because of xyz So it's exactly the same or at least for me it feels the same. Yeah, so it's it's uh Yeah, this is definitely what changed here I had a colleague who is working doing development um and one of the things he said was You almost have to limit yourself on how many agents you've got going at once because otherwise you can actually end up feeling overwhelmed And almost burnt out because you're trying to juggle mentally All of these different processes at the same time Yeah, yeah, definitely so um I also tried uh how how much Processes I can live with or say or I wish I can manage and um when you when you have a normal eight hours working day Yeah, same like this and then you try to have I don't know five five sessions five agent sessions in parallel with prompt running And then always checking back to back getting notifications here's a question there's something and you always have to switch Read something right another prompt and so on um took me easily four hours I was done So because this is yeah your head is exploding and you just need a break and you so it's not working this way and um Yeah, so maybe some a some on it can do this. I mean then this is everybody's the god developers because um Yeah, so then they have much more output Um, but let us later come also to to input. Yeah, I think uh what we also need to talk later is about uh requirements Requirements and if you don't have requirements, you cannot put this code here So the you need to be a multi-threaded brain developer. That's why I'm hearing yes. Yes. Yes. Yes. You know you are you need to but but it also raises the question right of not just Your agents know when going home time is right to they know when to stop working But how do we avoid the risk of developers getting burnt out right because You could be running to all agents, but if you know you're under pressure Then maybe you start running 15 and actually the like you're saying the cognitive load You know during the day may just become so much that actually You can't even work five days a week you have to stop and you have to less and it makes me think about platform engineering because Platform engineering as a discipline Really came about because we needed to reduce cognitive load for developers right to give them um more opportunity to focus on creating value through their understanding of the business, their understanding of the need, and their understanding of how to write good code. And it was taken away some of those admin tasks, the things which weren't directly allowing them to bring that creative capability. I mean, apart from burning people out, is there a risk that we take away the things that they enjoy doing from the job? - I think, I would compare with this, with any kind of hobby you have. Like, for developer, I can see it developers that I love it that I do it. You can have the people that just do it. I think here is, I think nothing changed. Like if you like to be developer, you will dig into technologies and you will find a way to use them and you will start loving some of them. But for me, what I see and what I'm struggling now, beyond us, because I'm not active at all, I'm just developing from time to time. So I don't have a lot of forums against a lot of CLI, terminals, running, and doing stuff for me. I don't keep be updated what is happening on the market, what is now a popular tool. So I'm more like, I will think the developers are not scared, but afraid that they go out from the business because they are not using the newest agents and tools that are, you know, now popular, because I hit a lot of talking of my teammates that, "Hey, have you hit up that one?" "No, this is new, this is crazy, this is amazing." And you can think that you need to be more updated and you can like be thinking that you are behind, behind all of this happening. You can think that you are not senior anymore. But like you said, the beginning, it's not about how much code you developed is more what is quality of your job. So I'm the person that I don't like the households. So I have friends doing everything because new, a lot of hobbies, a lot of fancy stuff. I'm just like more positive. I don't like gadgets, you know? I just like to have things that are useful for me. So like with the agents, I have only a few of them. And my favorite one is thinking beast mode. So yeah. So yeah, so I think it's, but it is still the same. New tools, new technology, if you want to be, you need to be keep peace with that one there. So if you stuck in the Somalagasy like Classic ASP, what when I was working with one, there are still, but there are still people, Dinosauros that are very needed, I paid well to dig into Classic ASP. So I think still depends on the person, what you will take as a joy from your work. - So just kind of thinking about that whole cognitive load thing. This sounds very similar to the kind of challenges that we run into as knowledge workers in general with context switching. 'Cause ultimately, you know, you're running five or 10 agents, you're effectively, it's the equivalent to trying to do five or 10 meetings at the same time on five or 10 related, but slightly different topics and trying to solve five or 10 different problems. And will tell you the cognitive load on that is intense. And it did make me think, well, actually, if we're able to though, let's say we have this ultra-god developer as you described before Sebastian, and they're able to far through and build all of this stuff. Surely there's gonna reach a point where they're actually able to develop faster than the requirements. - Yeah, that's a good point, good question. - Even this happened to us even before AI. And this is, and the thing is called producing code was never be a problem, I would say. So of course, we can now do it better. We can now do it faster, but the requirements are talking to the customer, getting the requirements out of the customer is the whole another topic. Of course, AI will also help you there, but you need time. And you need to prepare your project very well when you say, okay, now we want to go for 10 sprints with a development team of five developers. I could prefer AI, the throughput is enormous. So you need stories for that. And this, you also have to keep in mind when now planning for projects, new projects. So requirements, engineering needs to be faster, maybe even more beforehand than during the project now. So this is what I have sort of here. So you're almost shifting left, some of the workload again, but we keep talking about shifting left and right, but here, if left is your architecture phase, and in a kind of agile project, you're gonna have iterations of that architecture, depending on various features you're working on and all that. But actually, the, again, much in the same way as for QA and test, is gonna start ramping up the need. Actually, you're gonna have an architect who's almost gonna have to be full-time requirements gathering and building stories for the rest of the team. - We have, for us, for our projects, we have a business analyst in the project, always acting as a PO as a product owner, who's doing this. So it's always doing the architect and the product owner together. We are creating the requirements or sourcing the requirements, let's say it like this. But of course, when we also need to do the QA part, so it's all time. And then you have, it's all time you need to have, and then you have a fast development team. You need to plan your work properly. - I have one question here. Like, what about we stick this time to do more like experiments, AB testing, like, I always problem with my teams that there's several ideas and we end up only with one. And then we finally have that maybe the other one was better, but we never test that one. So is there more time for like, for like, finding more place for testing, experimenting with the project? - Yes, if you use your time wisely, this can happen because if you don't have, I mean, you wouldn't stop the project when you don't have requirements. Of course, you have to set the sprint somewhere to the customer and to do a proper review after the sprint, of course. But when you try something out, you can, or if you have time, you can try something out. Definitely, maybe one of the developer's is doing this where and the others are creating new features, new value for the customer, definitely a possibility here. - That's really interesting, because that opens up all different avenues of what it means to do a development project, doesn't it? Because obviously, potentially a lot more complexity, if we end up with lots and lots of different, almost a tree structure of AB testing of different features and stuff. But that actually sounds like a really interesting thing. If you're the product owner, you can say, hey, this is my outcome. I know we could get there a couple of different ways, the development team say, well, actually being able to build that fast, you could almost POV your features as you go or POC your features, do you want to put it? And then your development cycle then becomes build multiple, choose the best as we go. Obviously, that also might lead to people going, oh, well, we don't have to make too many decisions. We'll just build all the versions and then, maybe it becomes a wee bit wasteful. But I could definitely see a lot of value to maybe also say, not that I'm saying that it ever happens that developers would argue over the right solution, because that never happens. We're always, you know, in a pull-it-ly on track. But in those scenarios, it probably would actually help quite a lot too. - Yeah, and you can even use the power of AI also to develop these AB tests faster than you ever were ever before. - Exactly. It's an easier decision to do it. - It does sound interesting when we talk about prototyping the fact that you were saying Sebastian, you can real-time prototype with people, which means you get the feedback quicker, which means you can then adjust and you can recreate and then show them again. It does make me wonder whether we, you know, will it compress the timeframe of projects, right? Because we're actually getting there just much quicker. We're being much more efficient in how we collaborate with people. Or will we actually expand the work to fill the time, you know, because it's like, instead of having all the two prototypes, we'll have 10, right? And there'll be this debate about whether it's eight or nine, you know, version eight or version nine, will they the best? Probably marginal differences between them. So there always has to be some constraint, doesn't it? You know, to actually get people to complete work. Otherwise, things just become open ended. I guess, come back to Sprints. You mentioned Sprints. The whole point of Sprint, the whole focus of Sprints was delivering something tangible that people can test, that people can validate, right, to make sure you're moving around that cycle. I'm interested in particular in security. And the reason I'm interested in security is, we've talked about the velocity of code generation increasing. But one of the things that we're saying that AI can do, and we think about models like Mythos and Fable, is AI can be very good at picking up vulnerabilities in code. So we know that we're moving into an era where releasing code that has vulnerabilities is going to be much more dangerous than it ever has been before. At the same time, we're also potentially turning on a new way or introducing a new way of working. That's really geared towards producing code at speed. Okay, so there's been this battle of where does security sit and develop a life cycle? How can make it fundamentally part of it? So DevSecOps, how can we shift left? So make sure that the validation of security within You know applications it's happening before they're released not us running around after was trying to fix them and trying to Find you know The thunder better is then patch them and release them which is chasing your tail kind of cycle We know that with AI models becoming better at spotting those holes in security. That's not the way you want to operate anyway Where do you see us sitting with security are we going to get more back from our AI coding assistance? To help us actually meet this goal or Are they just going to make it worse because the velocity will increase and we can't actually keep up with it? Yeah, so now My experience with clients is that they're paying more aware that they need to have scanning tools included in the process Even I could say the name, but we have one big client. This is hundreds of developers and Think of that they now looking for the security solution to scan software to do tests So what we're doing what way what were they doing before like they didn't have secrets can tools or I think it was more like in my experience Each team was doing whatever they want they will do one of them was one tool other team was to do the smoke no standard there And and now they are looking for the standard because they are aware that AI tools code in this is a genetic and mass of the problems like even small dependency things like choosing the frameworks packages They are not secure. This is one thing second things generating their code that that It's not secure still injection is stopped in top 10. Yes I on one one of the conference I did demo demo of the SQL injection So my this someone said me this is not happening anymore. I said of course it's happening if you put here someone that don't know What is that it will happen so? scanning tools can be need to be there Companies are being more aware of that one and AI tools can help here, but They can work they need to work of the results some some like real tools like static scanning tools etc can help can help to shift it left to make the provided fix easier and for example I shouldn't like promote anything here, but As I'm working when I'm working we using the kept advanced security and there's a small issue call out to fix so can provide you Suggestion how to fix this vulnerability fund from the Statistics come so it can bring can help you deliver fixes faster Not always precise, but can even give you a clue How to fix it the pendesis can you I think this is what we need for now like if you are doing this on kind of Cloud solution public website public product The pendesis can you this is like bus half because there's you have a lot of examples that People find out that very very popular package have small issue that you can Breaking yet One one lone developer looking after that one teeny tiny feature that's buried away in the bottom of the operating system We're in the bottom there. Yeah, that's that's quite a common one, isn't it? So what you're actually saying though to me is if I if I understand correctly um AI has shown a light on The fact that we should actually really have been doing these this level of security in the first place It's just that now with AI um The risks are even greater but the risks were always there to an extent and so AI has both Sean that light on it but at the same time given as additional tools that we can use by shifting left To capture those issues before they actually make it into production AI still learning from the code that we created so if some package is very popular AI will choose this package because it's popular Of course you can have some kind of uh custom instruction agents to that place check the Overse please for something like that or check this That packages that are allowed It will skip using this package, but it's like you know like you have Some companies have some companies. I have control over of the Package register using packages that can use This need to be still implemented in place like At and on some kind of level uh So yeah, I guess my question before we wrap up to you guys is um If there were you know, you'd be working in the space now for for a while and You feel obviously you've bumped into and run into many of the walls you've uh got the scar tissue if you will So if there were a couple of things that you would say here's a really key that less than that i've learned working in this way Professionally day and day out. What would they be Sebastian? Do you want to kick us off? Yeah, I can I can uh first one I already mentioned so uh leading agents is like leading a team uh from from a technical perspective Uh, but I for second one um Uh the agents or the LLM or whoever sings differently than a developer I had a one-back with uh, where also the i was just a puree i developed something for a customer was translation application And uh, yeah, there you had the ability to just put in some words and translate it like we like with You know translation tools there and they also had the other uh Or they also want to have another option for translating documents pdf files, word documents or something like this And I also implemented this with the upper fai And this was I think it was one of the there was what the puree and I said it's a great solution to try out to max out on AI So do as less as possible and see what's happening here and and i did this And yeah, then some days the customer came to me and said okay, we have a strange back here said why what's the problem? Yeah, when you when you look at the documents the language from from what it was uh translated to the other one It's changing so it's it's wrong. So I look at it is wrong I don't know why and I looked at it and then yeah the back was easy because the AI needed these languages source language and target language for every document in the history and but it was in the wasn't in the object Which I passed to the to the client uh, so it took just the the drop downs on on the top for new documents So everything what you change to drop down from for the target language the language in the list in the history also changed the target language So and the developer wouldn't never do this this way I don't think the thing so I doubt uh, I hope Even but It's missing common sense ultimately it doesn't yeah, like I hear that you would never do something as bonkers as that yeah Yeah, yeah, so this was it was a nice learning To continue what's about the installing don't be offended here, but it is like Uh Don't give a monkey a monkey a hammer because it will break everything And this is like with every tool you can give tool but you need to also give a proper training how to use the tool and put some guiders What can be used what cannot be used? Uh, so Just this common role. That's why what I learn uh from using tools a second thing will be like I will not be again original here a security Uh, because because now everyone can think that it's a developer because can wipe coding and create a solution I have like two weeks ago situation that I was checking application created my friend and he asked me to publish it okay, I can help you to publish it and I did just review a code whereas I just enable some security scanning like sick It's scanning and code scanning and just to review and find out that he put in the code because it was Frontend JavaScript application with no back end he put hard code that in the JavaScript his path to get cap account Act token to get up with the full scope of access It was internal tool But still It's just like big faith because he couldn't really code he could understand that I I told him hey we need now Talking to have it working. Oh, he just did it. He's talking put the cook and the application and now probably publish it Oh So yeah, so I think We can use wipe coding for the Depends who is using the not developers can easily build some kind of a lot of prototypes To show the client to prove something Uh, but if you are a developer you need to know what they're using Atend. Yeah, absolutely makes sense security is job one As they always say What have you guys learned in terms of the Best way to be cost efficient Using these tools because Pavel you made this Statement if I remember it rightly it was don't use a rocket ship to cross the road to get groceries when you could Walk or something like that right so your point was there are many different ways of invoking these tools And the impact of them from a cost perspective is going to be dramatic do you want to say just a bit about what you've learned from that point of view I think I still learning because going to expensive it is expensive using tools expensive but For the point of view, you need to convert this cost to the value that you're producing. So it can be expensive but it can be green a lot of benefits. So it's like, well, producing everything, even if doing, you know, we're doing some kind of building, some car, airplanes, everything is part of the cost. Now we have new costs that can be easy, easy, spent by running swarrow against. But at the end, you need to be sure that you're bringing good value products. Because you can generate, I would have the demo for the client and in the one our generate tokens costs around $300 by one developer. So even my son started coding and he gets, I give you have access to tool and he was super happy because he was playing his micro game which is key created some kind of launcher for that one. And he's, he's holding one license for a small price penny. But he consumed $500 of tokens in one week and sold it for like $5. Oh, that's a, that's a lot of money. Love it. But he's super happy and happy because he's happy. Comparing to me when I start to coding, it was like not a command, not a command or thing. It was option to create some kind of fancy menu there. It was a batch files. It was like, it was my entry point there just creating batch five with some kind of stuff. Now he's chasing hundreds of lines at his working and he sold it. Amazing. What about you Sebastian? What have you learned on this on this tokenomics front? Any particular tips? Yeah, so at least I'm also still learning definitely because yeah, it's, yeah, recently it got just much more expensive. So we had to we are forced to we think all this. How we do with this and yeah, of course, I mean, always using favor for simple development stuff isn't the right choice, I would say. So yes, you should choose your your your tool here. And yeah, also when you when you know I don't know I mean fixing one line with some spelling errors. You shouldn't use the iPhone. Yeah, yeah. So I mean, this was literally meant there. So of course as a developer. Especially if you can talk to agents. You don't use use hands to fix this type of yeah, you need to think about this. Of course, you are I mean, if a simple model, you can also achieve a lot. Maybe when, yeah, when you just need to write some biceps script or some for like this for deployment and want to deploy something. And it's nothing special in there nothing. So just needs the context simple context there. You want to deploy an app service. You don't need favor for that. You can just use the model for that. Basic task means basic model choice and saving potentially multiple times as many tokens. There was one really interesting thing somebody said to me literally just in the last few days they were talking about. And if you look at the statistics on token usage and development, the percentage of tokens used for input are, you know, an order of magnitude larger than the tokens used for output. Because when you ask it to make a change especially for brownfields less if you're just writing a completely greenfield piece of text, right. But if you're modifying an existing code base, it effectively has to read and contextualize all of the code related to whatever you're asking. And so thinking very carefully about your inputs to then try and descope the number of files it's going to be working through and looking at can have a massive impact. So for example, let's say I write a one line change I want to make I say go and change this the font on this table. I'll just keep it really simple. Change the font in this table. I haven't explained, you know, which piece of code that relates to where that table is, what document it sits in. So if I just keep it as simple as going change this table and change the font, it's now got to search through all of my files, which actually all effectively get uploaded contextualized, it goes through all that, you know, how many tokens have I burned just to find the change. And then it's got to actually make the change and so the actual input tokens could be huge. Whereas if I had just said, hey, I've got this table. I know it exists in roughly this location in the code base instantaneously. I've already cut out a huge number of those tokens. So you're almost starting to think about how do you use or sorry, how do you reduce like you might do when you use a search engine. The amount of information it needs to troll through to be able to then get to what it is that you're going to change. And that can have a huge impact like two or even three X on your token usage just by being a little bit more specific in what you're asking it to do and having it spend less time at work acting as a certain very expensive search engine. True. Even don't say hello to the agent because there's a letter. Yes, this is tough. You're being asked to be the manager of team of agents and yet you can't talk to them. You can't be nice to them. It's just going to burn tokens. In the words of Sebastian, AI is not a silver bullet. So however you're going to shape your team, however many agents you're going to run, however you're going to use them way at that balance between what the human brings or the AI assistant brings an ideally what does perfect look like when they're both working together. So before we wrap up, I just want to thank our fantastic guests, Pavel and Sebastian. How can people reach you online Sebastian? Are you available on any social media platforms where people can follow you? Yeah, you can find me on LinkedIn. So search for my name Sebastian Brandt software one. Live to find me there. Great and Pavel yourself. I'm happy to answer any questions. I also look at in Pavel's two chainsky Poland software one. As for our next episode of the Optimized 308 podcast, we are going to be focusing on digital sovereignty. It's a topic which has become quite well, let's say publicized within the last six to nine months, but the question is what's the value get from implementing or embracing digital sovereignty? What are the pros? What are the cons? Are we going to be digging into that with some experts on the topic in our next episode? If you'd like this episode, hit subscribe on your podcast app and leave us a review. It really helps more people to find us. And if there's something specifically you want us to cover in the future, don't hesitate to leave a comment or let us know via social media. We're at software one just throughout everywhere. With that, thanks for listening and we'll see you in the next one. [BLANK_AUDIO]