1 00:00:00,040 --> 00:00:02,360 We're usually brought in when the house is on fire, right? 2 00:00:02,480 --> 00:00:05,720 I don't think it's an automated way how you migrate code bases. 3 00:00:05,720 --> 00:00:08,520 It's little pieces of of value that I add and that's how I 4 00:00:08,520 --> 00:00:10,120 progress from one stage to another. 5 00:00:10,160 --> 00:00:12,280 But that's intense. The right to these tests 6 00:00:12,280 --> 00:00:14,160 beforehand that there's risk mitigation. 7 00:00:14,280 --> 00:00:17,760 The more coverage you have, more accurate your parity checking 8 00:00:17,760 --> 00:00:21,480 is, the less risk you have at the AI is a differentiator. 9 00:00:21,640 --> 00:00:25,320 It empowers great software architects, software engineers 10 00:00:25,320 --> 00:00:28,000 that have a strong software architect system designed 11 00:00:28,040 --> 00:00:31,840 capability versus those two. Not to write great software, you 12 00:00:31,840 --> 00:00:33,520 still need to be a great engineer. 13 00:00:33,520 --> 00:00:35,960 That didn't change. If you're interested in system 14 00:00:35,960 --> 00:00:40,320 design and modernizing and migrating software, this episode 15 00:00:40,320 --> 00:00:42,440 is for you. I'm joined by Dennis Fink, 16 00:00:42,600 --> 00:00:46,000 principal consultant over at Xavier, and I loved learning 17 00:00:46,000 --> 00:00:49,880 from his approach how he executes on the many ideas and 18 00:00:49,880 --> 00:00:52,040 projects that he has. So enjoy. 19 00:00:55,920 --> 00:00:58,720 I looked at your LinkedIn and already in 2024 you landed 20 00:00:58,720 --> 00:01:02,280 assignments as AI engineer. Was it all bringing AI to 21 00:01:02,280 --> 00:01:06,000 production or was it more also kind of AI in way of working? 22 00:01:06,560 --> 00:01:11,040 It, it, it was more companies wanting to learn more about AI 23 00:01:11,520 --> 00:01:15,200 and, and the very beginnings like models were pretty 24 00:01:15,200 --> 00:01:19,680 primitive back then and there was not a lot of knowledge. 25 00:01:20,480 --> 00:01:23,880 What you see nowadays is that companies are much more 26 00:01:24,080 --> 00:01:27,800 self-sufficient. They have a lot of knowledge 27 00:01:28,000 --> 00:01:31,960 internally about artificial intelligence, so now the 28 00:01:31,960 --> 00:01:34,920 assignments that you currently get are are more complex. 29 00:01:35,120 --> 00:01:35,840 Gotcha. Yeah. 30 00:01:35,840 --> 00:01:39,560 But it's still bringing AI and AI component to production. 31 00:01:39,560 --> 00:01:41,640 Yeah, somewhere within a product, yeah. 32 00:01:41,840 --> 00:01:43,840 Can you share some of the examples that you've brought to 33 00:01:43,840 --> 00:01:46,880 production? For example, knowledge bases are 34 00:01:47,160 --> 00:01:50,160 quite popular. So that's, that's the 35 00:01:50,200 --> 00:01:55,680 interaction with with the rec system and then the interface 36 00:01:55,680 --> 00:02:00,160 around how do you interact with its response times, those type 37 00:02:00,160 --> 00:02:06,040 of things. But also like a Gentic data 38 00:02:06,040 --> 00:02:07,760 research. So you have a big query 39 00:02:07,760 --> 00:02:10,320 database, for example, with lots of data in it. 40 00:02:10,320 --> 00:02:11,840 You want to get insights out of it. 41 00:02:12,600 --> 00:02:14,760 How do you do that, and how do you do that responsibly? 42 00:02:14,800 --> 00:02:18,040 Yeah, I know you get a lot of energy out of building things. 43 00:02:18,400 --> 00:02:20,840 Can you share some of the examples of what you've built 44 00:02:20,840 --> 00:02:25,120 recently? Recently I've have a lot of side 45 00:02:25,120 --> 00:02:27,880 projects. One of them is Eurosso, which is 46 00:02:27,880 --> 00:02:32,880 a genetic platform where you can automate business processes, 47 00:02:33,760 --> 00:02:38,640 which is really fun. Another one is a very old game 48 00:02:39,560 --> 00:02:46,480 that I played about 20 years back that I brought back to 49 00:02:46,480 --> 00:02:50,920 life. So I converted it from a binary 50 00:02:51,560 --> 00:02:58,080 and a bit of source code which was written in C and C++ to to 51 00:02:58,080 --> 00:03:02,480 Rust and then a graphical user face around it so you can play 52 00:03:02,480 --> 00:03:03,920 it in the web browser. Nice. 53 00:03:04,080 --> 00:03:05,080 It's really fun. How? 54 00:03:05,120 --> 00:03:07,560 How is your CC plus plus or or rust? 55 00:03:08,600 --> 00:03:10,760 Rusty. Yeah, Rusty, very rusty, yeah. 56 00:03:12,160 --> 00:03:16,080 I coded C and C++ maybe 30 years ago. 57 00:03:16,560 --> 00:03:22,280 So that's that's a long time 3025 years ago, more or less. 58 00:03:23,000 --> 00:03:30,720 And well, then you evil to other other languages, a a bit lower 59 00:03:30,720 --> 00:03:36,720 level languages, higher level languages and it it's the 60 00:03:36,760 --> 00:03:39,080 knowledge about this programme like it just disappears. 61 00:03:39,800 --> 00:03:42,680 And that's not an issue with regards to bringing this piece 62 00:03:42,680 --> 00:03:46,000 of software back to life. No, like I can still read it. 63 00:03:46,720 --> 00:03:53,880 And while you're working on such a project like the, the, the 64 00:03:53,880 --> 00:03:58,120 patterns are still familiar and you know the principles and you 65 00:03:58,120 --> 00:04:00,320 can write pieces of code, you can debug it. 66 00:04:01,360 --> 00:04:05,320 So it's it's like learning to bike you, you don't forget it. 67 00:04:05,440 --> 00:04:06,520 Gotcha. Yeah. 68 00:04:06,760 --> 00:04:10,280 So patterns, principles, those are the knowledge you need to be 69 00:04:10,280 --> 00:04:13,800 able to do something like this. Or how do you see that? 70 00:04:13,920 --> 00:04:15,080 Yeah, absolutely. Yeah. 71 00:04:15,120 --> 00:04:20,360 Yeah, I think if you like you, you have the term fight coding, 72 00:04:20,399 --> 00:04:26,320 right? It is a, a, a bit of a, there's 73 00:04:26,320 --> 00:04:31,000 a bit of a smear on the term because it's, it implies being 74 00:04:31,000 --> 00:04:35,120 able to create applications without, without programming 75 00:04:35,120 --> 00:04:38,280 knowledge. Yes, you're able to do that, but 76 00:04:38,280 --> 00:04:42,600 you're not able to exercise any control over it. 77 00:04:43,360 --> 00:04:47,080 So if you, if you fight code something you have serial 78 00:04:47,080 --> 00:04:50,480 knowledge, it will just go the direction that the the model 79 00:04:50,480 --> 00:04:53,760 thinks is best. And you're not able to assess 80 00:04:53,760 --> 00:04:57,840 quality and you are not able to give the proper direction. 81 00:04:58,880 --> 00:05:01,840 What do you assess in terms of quality, especially when we're 82 00:05:01,840 --> 00:05:03,960 talking about a piece of software that's written in a 83 00:05:03,960 --> 00:05:06,000 specific language and you want to modernise it? 84 00:05:06,280 --> 00:05:09,120 Feel like a lot of companies or maybe even people always 85 00:05:09,480 --> 00:05:11,720 migrations and modernisations are always a topic. 86 00:05:12,160 --> 00:05:14,160 But what fundamentals do you really need to have to be able 87 00:05:14,160 --> 00:05:16,600 to do this? So you need to be familiar with 88 00:05:16,600 --> 00:05:20,720 test driven development. For example, let me let me take 89 00:05:20,720 --> 00:05:25,200 the the game accept. All right, so I migrated old, 90 00:05:25,240 --> 00:05:30,280 very old game from from binary C++ to Rust. 91 00:05:30,760 --> 00:05:33,960 But you want to ensure that the mechanics are identical. 92 00:05:35,520 --> 00:05:43,160 So my approach has been to to write tests, but also to use the 93 00:05:43,160 --> 00:05:49,400 code of both systems to assess whether the what it reads and 94 00:05:49,400 --> 00:05:52,920 what its outputs, the actions that it does that they perform 95 00:05:52,920 --> 00:05:57,080 identical when executed. So if it reads something and it 96 00:05:57,080 --> 00:06:02,000 parses something in one system, it needs to be identical to the 97 00:06:02,000 --> 00:06:03,920 other one, and that's how you prove parity. 98 00:06:04,000 --> 00:06:05,520 And this is in an automated sense. 99 00:06:05,520 --> 00:06:09,480 In an automated sense, yeah. So I I created tooling for that 100 00:06:09,480 --> 00:06:15,080 to to simulate. For example, in in this game 101 00:06:15,080 --> 00:06:19,400 system, you have certain actions that trigger other actions and 102 00:06:19,400 --> 00:06:24,000 then wrote a simulator like we, we triggered this action. 103 00:06:24,240 --> 00:06:26,400 Does it have exactly the same consequences? 104 00:06:27,400 --> 00:06:28,920 And that's how you how you proceed. 105 00:06:28,920 --> 00:06:33,200 So that's kind of a brute force way, but that ensures that the 106 00:06:33,200 --> 00:06:37,400 end result is is identical even though the code base differs. 107 00:06:37,800 --> 00:06:40,800 And these actions that you've specified in this way of 108 00:06:40,800 --> 00:06:43,680 working, are those actions upfront that you're saying these 109 00:06:43,680 --> 00:06:46,480 are the the set of actions we need to validate or are they 110 00:06:46,480 --> 00:06:50,200 also generated or randomised or how do they come into place? 111 00:06:50,280 --> 00:06:54,040 No, they so they they're the the actual code and three points in 112 00:06:54,040 --> 00:06:57,960 the original game versus the the new version. 113 00:06:58,120 --> 00:07:02,200 Culture interesting and looking at a perspective with regards to 114 00:07:02,200 --> 00:07:04,960 test driven development. If the old code base didn't have 115 00:07:04,960 --> 00:07:08,440 any tests, do you then work to mature that to a certain level 116 00:07:08,440 --> 00:07:11,080 before you go modernised? Yeah, absolutely. 117 00:07:11,080 --> 00:07:12,600 Yeah, Yeah. Interesting. 118 00:07:12,880 --> 00:07:16,040 Because a lot of organizations that I've looked at, people that 119 00:07:16,040 --> 00:07:18,800 I've spoken to when it comes to software that they want to move 120 00:07:18,800 --> 00:07:22,080 away from, maybe there's a license component, maybe there's 121 00:07:22,080 --> 00:07:24,280 just a knowledge gap there. Maybe they want to move to a 122 00:07:24,280 --> 00:07:27,160 different platform or a specific language. 123 00:07:27,760 --> 00:07:29,920 Typically those older code bases, they don't have that 124 00:07:29,920 --> 00:07:31,920 level of maturity. They don't have the test 125 00:07:31,920 --> 00:07:33,360 framework. That's one why they want to 126 00:07:33,360 --> 00:07:36,480 modernize in the 1st place. And sometimes it's even instead 127 00:07:36,480 --> 00:07:39,080 of a migration, a complete rebuild and lots of those 128 00:07:39,080 --> 00:07:43,240 projects in the end fail because it's a huge effort and you need 129 00:07:43,240 --> 00:07:46,880 to really have buy in from the business side because in the end 130 00:07:47,280 --> 00:07:52,320 it's a very long term play. So moving away when the code 131 00:07:52,320 --> 00:07:55,320 base is not really mature, that's I think also part of the 132 00:07:55,320 --> 00:07:57,480 complexity typically. Absolutely, Yeah. 133 00:07:57,480 --> 00:08:01,280 It's so writing these tests beforehand that there's risk 134 00:08:01,280 --> 00:08:07,120 mitigation and the more the, the more coverage you have, the more 135 00:08:07,120 --> 00:08:11,520 accurate your your parity checking is, the the less risk 136 00:08:11,520 --> 00:08:13,320 you have at the end. Nice. 137 00:08:13,680 --> 00:08:16,160 Yeah. So the parity checking that is 138 00:08:16,160 --> 00:08:18,960 mainly crucial, I guess. Yeah, you start with a code 139 00:08:18,960 --> 00:08:21,920 base, you make sure that maturity wise, test wise, you 140 00:08:21,920 --> 00:08:24,560 have a good safety net. Then you modernize and you 141 00:08:24,560 --> 00:08:26,440 modernize in an automated way, I'm assuming. 142 00:08:26,760 --> 00:08:30,400 Does it matter which model or which methodology you use to 143 00:08:30,400 --> 00:08:34,039 modernize? I don't think the model matters 144 00:08:34,039 --> 00:08:39,400 much as long as it's a competent model like I. 145 00:08:39,400 --> 00:08:44,520 I like to use open DI myself. Codex models, but you could use 146 00:08:44,520 --> 00:08:46,120 cloud. It doesn't. 147 00:08:46,120 --> 00:08:49,440 It doesn't really matter and methodology does matter. 148 00:08:49,440 --> 00:08:53,440 You need to have the the instructions in place the parity 149 00:08:53,440 --> 00:08:57,680 tooling and I think that begins before you migrate any actual 150 00:08:57,680 --> 00:08:58,600 code. Gotcha. 151 00:08:58,840 --> 00:09:01,000 Yeah. How'd you come into this way of 152 00:09:01,000 --> 00:09:02,440 working? Is it just a lot of trial and 153 00:09:02,440 --> 00:09:06,480 error experimentation, or? Like I became an enthusiast the 154 00:09:06,480 --> 00:09:13,920 moment it, it's, it went from large language models to to 155 00:09:13,920 --> 00:09:16,800 agentic. And I realized you could 156 00:09:16,800 --> 00:09:21,480 automate a lot of tasks with it. That's when I also got very 157 00:09:21,480 --> 00:09:27,200 interested in, in, in creating euro cell to, to solve, to 158 00:09:27,200 --> 00:09:31,240 automate business processes because I could see the 159 00:09:31,240 --> 00:09:37,840 potential of, of agentic. And so I became a enthusiast 160 00:09:37,840 --> 00:09:43,880 early on and, and started experimenting and, and you see 161 00:09:44,480 --> 00:09:48,360 as time progresses, these, these models get more and more more 162 00:09:48,360 --> 00:09:53,720 powerful, especially with like the tool calling they can do and 163 00:09:53,720 --> 00:09:56,920 the accuracy on that. Yeah, it's interesting because 164 00:09:57,600 --> 00:09:59,440 ownership is always a big thing, right? 165 00:09:59,440 --> 00:10:02,720 I put a lot of effort into my codebase historically with 166 00:10:02,720 --> 00:10:06,200 regards to my commit message structure, the way we design 167 00:10:06,200 --> 00:10:08,880 systems and thinking about software architecture and 168 00:10:09,280 --> 00:10:12,440 applying patterns and keeping things simple and evolvable for 169 00:10:12,440 --> 00:10:15,160 the future. And I feel like a lot of those 170 00:10:15,320 --> 00:10:17,120 are kind of out of the water. And especially when we're 171 00:10:17,120 --> 00:10:20,120 talking about a modernization, if I go from codebase X to 172 00:10:20,120 --> 00:10:24,200 codebase Y in an automated kind of finger snap way, how much 173 00:10:24,200 --> 00:10:25,880 influence do I have on the structure? 174 00:10:25,880 --> 00:10:29,360 Or should I care about what the code in the end looks like from 175 00:10:29,360 --> 00:10:33,440 your perspective? Yeah, I, I don't think, like you 176 00:10:33,440 --> 00:10:36,400 say, in an automated way. I don't think it's, it's in an 177 00:10:36,400 --> 00:10:38,360 automated way how you migrate code bases. 178 00:10:38,360 --> 00:10:44,360 So how I typically approach that is how you define like user 179 00:10:44,360 --> 00:10:48,000 stories that are really scoped to a specific piece of value. 180 00:10:49,080 --> 00:10:52,400 And that's also how I instruct the model. 181 00:10:53,440 --> 00:10:55,920 It's, it's little pieces of, of value that I add. 182 00:10:57,360 --> 00:10:59,480 And that's how I progress from one stage to another. 183 00:10:59,880 --> 00:11:03,040 And that's, that's intense. Like for example, the the game 184 00:11:03,040 --> 00:11:07,280 server migration overall, including the the web interface 185 00:11:07,280 --> 00:11:13,240 and and an editor took about a month of, of work, not full time 186 00:11:13,240 --> 00:11:16,720 work, but but still a month of work of, of prompting. 187 00:11:16,720 --> 00:11:21,400 It's rating how you would do it as a as an engineer as well. 188 00:11:21,400 --> 00:11:24,800 You, you iterate on on the product and you add little 189 00:11:24,800 --> 00:11:27,920 improvements gradually. So I don't think that that 190 00:11:27,920 --> 00:11:29,040 differs much. Yeah. 191 00:11:29,840 --> 00:11:33,200 Are engineers typically good at this because they have to step 192 00:11:33,200 --> 00:11:35,960 out of the hands on part and more orchestrate things with 193 00:11:35,960 --> 00:11:38,520 regards to, you already mentioned user stories and 194 00:11:38,520 --> 00:11:40,360 that's a lot of prompting, a lot of back and forth. 195 00:11:40,760 --> 00:11:43,480 Typically, that's not really what we historically have spent 196 00:11:43,480 --> 00:11:46,000 most of our time on. Most of the time has really been 197 00:11:46,000 --> 00:11:49,200 on actually building the thing and being in meetings to discuss 198 00:11:49,200 --> 00:11:51,200 about the thing and getting a better understanding. 199 00:11:51,600 --> 00:11:54,320 But that's one of the execution side of things, yeah. 200 00:11:54,320 --> 00:11:58,400 Is that changing? I think that is changing and I 201 00:11:58,400 --> 00:12:03,000 think you will see that engineers that are like their 202 00:12:03,000 --> 00:12:08,680 philosophy is limited by, by execution will love to be able 203 00:12:08,680 --> 00:12:13,160 to like zoom out a bit and have a whole overview and being able 204 00:12:13,160 --> 00:12:16,840 to orchestrate on that level. And you have engineers that are 205 00:12:16,840 --> 00:12:20,600 in their in their little bubble that that don't know how to do 206 00:12:20,600 --> 00:12:23,600 that. You started creating code very 207 00:12:23,600 --> 00:12:26,120 early on. Age wise, you were there very 208 00:12:26,120 --> 00:12:29,080 early and typically those are the people that really love the 209 00:12:29,080 --> 00:12:32,160 hands on part of things as well. But since the hands on thing is 210 00:12:32,160 --> 00:12:36,080 evolving, are you still getting the same amount of fulfilment or 211 00:12:36,080 --> 00:12:39,120 how do you see that? I think it's accelerated, yeah. 212 00:12:39,520 --> 00:12:44,120 Like I have, I have a mind that is always exploding with with a 213 00:12:44,120 --> 00:12:48,800 million different ideas. I have probably hundreds if not 214 00:12:48,800 --> 00:12:50,520 thousands of unfinished projects. 215 00:12:50,520 --> 00:12:52,880 Oh yeah. Still, yeah, absolutely. 216 00:12:52,880 --> 00:12:53,760 It's never going to end. Yeah. 217 00:12:53,840 --> 00:12:57,840 It's, it's never ending and I always have have have different 218 00:12:57,840 --> 00:13:01,360 ideas that I don't have time for, for fleshing out. 219 00:13:02,840 --> 00:13:08,960 And this type of tooling helps me finally finish something you 220 00:13:08,960 --> 00:13:12,720 get from from A to C quite rapidly. 221 00:13:13,400 --> 00:13:17,280 And it allows me to to have that focus to to to finish it. 222 00:13:18,240 --> 00:13:21,040 For me, I think I'm, I'm the opposite compared to you. 223 00:13:21,040 --> 00:13:23,880 When I start something, I really want to have the conference 224 00:13:23,920 --> 00:13:27,120 confidence that I can do this and actually finish things. 225 00:13:27,120 --> 00:13:30,040 So if I don't believe that I can finish something, I typically 226 00:13:30,040 --> 00:13:33,800 don't start many things because I feel like what's the point? 227 00:13:33,800 --> 00:13:37,120 If I start and I don't finish, I have to finish or at least see 228 00:13:37,120 --> 00:13:39,320 it through to a point where I'm fulfilled. 229 00:13:40,320 --> 00:13:43,320 What would you advise people that are like me or similar that 230 00:13:43,320 --> 00:13:46,000 have trouble starting because starting seems effortless from 231 00:13:46,000 --> 00:13:48,000 your side? How do you make starting easy? 232 00:13:48,000 --> 00:13:49,680 Or does it just come automatically? 233 00:13:49,800 --> 00:13:53,480 Well it it comes semi automatically so I've HDHD 234 00:13:53,480 --> 00:13:57,080 brain. So that means that I start a 235 00:13:57,080 --> 00:14:00,480 million things and unlikely to finish all of them. 236 00:14:01,720 --> 00:14:04,480 But there's also the sense that I like the journey, like I like 237 00:14:04,480 --> 00:14:11,720 the the learning journey, the experience of creating and a 238 00:14:11,720 --> 00:14:14,640 project doesn't necessarily need to end with the finished 239 00:14:14,640 --> 00:14:18,280 products for me. So it's also just just having 240 00:14:18,280 --> 00:14:18,920 fun. Yeah. 241 00:14:19,560 --> 00:14:22,480 Can we go through a scenario? You have an idea and you want to 242 00:14:22,480 --> 00:14:24,480 start something. What are some of the first few 243 00:14:24,480 --> 00:14:27,280 steps that you typically do with regards to starting? 244 00:14:29,080 --> 00:14:32,400 First, I've I've also have a business background, so I do 245 00:14:32,400 --> 00:14:35,080 some research, but this already exists. 246 00:14:35,640 --> 00:14:40,000 Is it marketable? Sometimes it it could also be 247 00:14:40,000 --> 00:14:41,640 just a fun project for myself, right? 248 00:14:41,640 --> 00:14:43,960 Yeah, like the game migration. Like the game migration. 249 00:14:46,000 --> 00:14:49,480 So typically it starts with a bit of research and then 250 00:14:51,200 --> 00:14:55,840 formulating a like a high level plan, like what do I want to 251 00:14:55,840 --> 00:14:57,080 achieve? What are my goals? 252 00:14:57,320 --> 00:15:00,480 What is the end state? And then drill down from there 253 00:15:00,760 --> 00:15:06,760 into more details, steps. And usually along the way I get 254 00:15:06,760 --> 00:15:09,280 a better idea of, of what I want to build. 255 00:15:09,800 --> 00:15:12,760 And sometimes that changes during the development process 256 00:15:12,760 --> 00:15:16,200 as well. Like I get an, a great insight 257 00:15:16,200 --> 00:15:20,080 like how this could work better. And then now it's really easy to 258 00:15:20,080 --> 00:15:23,680 pivot. So in the past, if you are 259 00:15:23,760 --> 00:15:25,960 working on the project and you've invested months 260 00:15:26,440 --> 00:15:30,880 developing something, if you get a new insight that's requires 261 00:15:30,880 --> 00:15:35,160 you to rewrite a large part of your code base, that is very 262 00:15:35,160 --> 00:15:38,960 demultivating because you've invested already so much time. 263 00:15:38,960 --> 00:15:43,280 So you have this, this sunk cost fallacy, which you also don't 264 00:15:43,280 --> 00:15:46,040 have now. So it's lowers the the 265 00:15:46,040 --> 00:15:48,040 thresholds to to pivot in that sense. 266 00:15:49,080 --> 00:15:53,120 I've done since I'm prompting a lot, I've installed like speech 267 00:15:53,120 --> 00:15:57,160 to text software on my laptop and I just talk a lot more with 268 00:15:57,160 --> 00:15:59,960 regards to either brainstorming if I have to do something non 269 00:15:59,960 --> 00:16:02,400 code related or if I have to do something software related. 270 00:16:02,920 --> 00:16:05,960 Still, I feel like prompting now and typing has become my 271 00:16:05,960 --> 00:16:08,280 bottleneck because of that interaction. 272 00:16:08,280 --> 00:16:11,000 I want it faster and faster to get the feedback faster and to 273 00:16:11,000 --> 00:16:13,360 get up and running faster. Is that something that you've 274 00:16:13,360 --> 00:16:19,400 experienced as well? Partially, yeah, especially also 275 00:16:19,400 --> 00:16:23,240 like due due to the speed, like agentic coding is not, it's not 276 00:16:23,240 --> 00:16:25,440 instant. It's not like you prompted LLM. 277 00:16:25,440 --> 00:16:30,600 You get an instant response and and and things take time. 278 00:16:33,200 --> 00:16:38,840 In terms of prompting, it's it's more the the waiting for a task 279 00:16:38,840 --> 00:16:42,000 to be finished, to see, to evaluate. 280 00:16:42,000 --> 00:16:47,360 Did it do what I want and then re prompting or moving on to the 281 00:16:47,360 --> 00:16:50,440 next bit And and it's that that wait, it is a bit of a waste. 282 00:16:51,600 --> 00:16:56,360 You can mitigate it like doing parallel features, for example, 283 00:16:56,360 --> 00:17:01,720 that say that don't touch each other's code base or source 284 00:17:01,720 --> 00:17:05,280 files. But there's a, there's a bit of 285 00:17:06,160 --> 00:17:08,839 yeah, cutting loss. Is that to say? 286 00:17:09,240 --> 00:17:11,839 Do you parallelise? So when you're working on one 287 00:17:11,839 --> 00:17:14,680 feature, let's talk about the modernisation example of the 288 00:17:14,680 --> 00:17:17,440 game, you define your user stories, that's what you 289 00:17:17,440 --> 00:17:19,839 mentioned. Do you then see, OK, if we do 290 00:17:19,839 --> 00:17:22,040 these in parallel, these are not really going to touch each other 291 00:17:22,040 --> 00:17:24,480 or how do you approach that, that waiting period? 292 00:17:24,480 --> 00:17:29,240 If I know for sure there's no overlap, but usually like for 293 00:17:29,240 --> 00:17:34,680 example in the game example, I have AI, have a game server, I 294 00:17:34,680 --> 00:17:38,720 have a database layer. Yeah, I have an editor and I 295 00:17:38,720 --> 00:17:43,360 have a web client and all of those four, they can, they can 296 00:17:43,360 --> 00:17:47,280 use some work. So if I paralyse, it's usually 297 00:17:47,280 --> 00:17:49,360 on the spread between those projects. 298 00:17:49,440 --> 00:17:52,120 Gotcha. Yeah, So that's more defined 299 00:17:52,120 --> 00:17:55,160 boundaries rather than very close to each other feature wise 300 00:17:55,200 --> 00:17:56,240 in the same domain. Yeah. 301 00:17:57,080 --> 00:18:00,720 What do you now do is what do you nowadays do while waiting? 302 00:18:00,720 --> 00:18:04,720 Because I feel like I am a little bit more waiting nowadays 303 00:18:04,720 --> 00:18:07,440 than actually executing. I read a lot based on the output 304 00:18:07,480 --> 00:18:10,560 or I go do something else but I am more in a waiting state I 305 00:18:10,560 --> 00:18:13,440 feel like. Yeah, yeah, usually. 306 00:18:13,840 --> 00:18:17,400 So I follow a bit along what it's doing because it's also 307 00:18:17,400 --> 00:18:20,440 shares like it's, it's AI thought process. 308 00:18:22,480 --> 00:18:26,920 And sometimes that leads to new questions or new insights. 309 00:18:27,840 --> 00:18:31,120 And then I go look it up, make a bit of research, for example, 310 00:18:31,120 --> 00:18:36,560 format of specific Sprite library, for example, or 311 00:18:36,560 --> 00:18:41,440 thinking, oh, I maybe I want to support X&Y format. 312 00:18:42,320 --> 00:18:46,320 And then I go look it up if that exists and, and how do you 313 00:18:46,320 --> 00:18:51,680 ingest that, for example. So it's it's reading up and if I 314 00:18:51,680 --> 00:18:54,240 have nothing else to do, I will get distracted with something 315 00:18:54,280 --> 00:18:56,920 else. I'd probably forget what I was 316 00:18:56,920 --> 00:18:58,800 doing anyway and then come back half an hour. 317 00:18:58,920 --> 00:19:02,520 Oh yeah, I was doing that and looking at the output again. 318 00:19:02,920 --> 00:19:06,200 Gotcha. Yeah, I did a poll recently for 319 00:19:06,200 --> 00:19:09,120 the people that are listening. It was what are your favorite 320 00:19:09,120 --> 00:19:12,000 topics on the podcast? And system design was the one 321 00:19:12,000 --> 00:19:13,760 that won. I think it's like 50%. 322 00:19:13,760 --> 00:19:16,400 And then I had four options, so head and shoulders above the 323 00:19:16,400 --> 00:19:18,760 rest. System design for me is quite 324 00:19:18,760 --> 00:19:20,960 interesting. It's not something that I'm very 325 00:19:20,960 --> 00:19:24,240 good at because I've always come into projects where something is 326 00:19:24,240 --> 00:19:26,800 already live and now we're building on top of that. 327 00:19:26,800 --> 00:19:30,000 So a lot of artefacts with regards to system design have 328 00:19:30,000 --> 00:19:34,320 already been chosen and unless we're bridging a gap with 329 00:19:34,320 --> 00:19:37,080 regards to a new feature that we have to do, there's not much 330 00:19:37,080 --> 00:19:39,960 thinking in advance. So my experience has not been 331 00:19:39,960 --> 00:19:43,280 from zero to one that often, but I know throughout your 332 00:19:43,280 --> 00:19:46,960 experience you've worked and focused on cloud and also as AI 333 00:19:46,960 --> 00:19:49,840 engineer, you've brought a lot of stuff to production, not just 334 00:19:49,960 --> 00:19:52,080 in companies but also inside projects. 335 00:19:52,360 --> 00:19:54,120 Do you think system design is still going to be one of the 336 00:19:54,120 --> 00:19:58,000 most core competencies for the people building or how do you 337 00:19:58,000 --> 00:20:01,480 view that? I do think it's, it's just going 338 00:20:01,480 --> 00:20:05,880 to remain important for sure. It's, it's, you need to have a 339 00:20:05,880 --> 00:20:10,720 strong foundation. I'm a I'm a strong believer that 340 00:20:11,680 --> 00:20:15,640 you will see in the in the in the coming years. 341 00:20:16,120 --> 00:20:22,160 That AI is a differentiator. It empowers great software 342 00:20:22,160 --> 00:20:25,560 architects, software engineers that have a strong software 343 00:20:25,560 --> 00:20:30,840 architect system design capability versus those who are 344 00:20:30,840 --> 00:20:35,240 not. I believe that the the quality 345 00:20:35,280 --> 00:20:39,720 of the of of what you create with with these models is 346 00:20:39,720 --> 00:20:43,920 exponentially higher in great engineers versus those who are 347 00:20:43,920 --> 00:20:47,000 not. Well, first, not to speak of the 348 00:20:47,000 --> 00:20:49,040 new generation. I I worry for them. 349 00:20:50,240 --> 00:20:51,640 Why do you worry for them specifically? 350 00:20:52,520 --> 00:20:57,480 Because they will not be educating themselves in these 351 00:20:57,480 --> 00:21:00,800 principles anymore. Because it's, it's like the 352 00:21:00,800 --> 00:21:05,120 Fable, it's, it's take out and you don't have these learning 353 00:21:05,120 --> 00:21:06,880 experience anymore. Gotcha. 354 00:21:07,240 --> 00:21:09,720 What would you advise them then? Because you're saying software 355 00:21:09,720 --> 00:21:12,040 architecture and design principles, those are going to 356 00:21:12,040 --> 00:21:15,720 be important since you are more orchestrating rather than 357 00:21:15,720 --> 00:21:17,960 executing. What would you advise the new 358 00:21:17,960 --> 00:21:20,440 generation that's now learning or studying and coming up 359 00:21:20,440 --> 00:21:22,800 actually? Go go through the big yeah. 360 00:21:22,800 --> 00:21:25,120 Yeah, do it manually. Is that what you mean or? 361 00:21:25,120 --> 00:21:32,240 Do it manually, struggle, make mistakes, preferably get from 362 00:21:32,240 --> 00:21:36,000 the Internet so you have no resources to look it up and 363 00:21:37,240 --> 00:21:38,920 that's that's the way how you truly learn. 364 00:21:40,120 --> 00:21:42,840 Yeah, that's difficult. I feel like because the the 365 00:21:42,840 --> 00:21:46,760 manual approach, it will no longer be what companies expect. 366 00:21:47,160 --> 00:21:49,880 I feel like if they will hire juniors, they will expect them 367 00:21:49,880 --> 00:21:53,320 to operate on a meaner level because you give AI tooling to 368 00:21:53,320 --> 00:21:57,560 accelerate people to also accelerate their knowledge, but 369 00:21:57,560 --> 00:22:00,880 also their execution power. So then doing the manual route, 370 00:22:00,880 --> 00:22:03,520 especially on company time, I think that's going to be 371 00:22:03,520 --> 00:22:04,880 challenging. It's going to be a hard bargain. 372 00:22:04,880 --> 00:22:06,040 Yeah, right. Yeah, Yeah, it's. 373 00:22:06,200 --> 00:22:10,560 Going to be a hard bargain. I think it's, I think great 374 00:22:10,560 --> 00:22:15,440 engineers are usually interested in in, in writing software at A 375 00:22:15,440 --> 00:22:17,560 at a younger age. And I think that is when you 376 00:22:17,560 --> 00:22:22,800 make the investment. And I think the true cost of of 377 00:22:22,800 --> 00:22:25,640 the accessibility, the availability of these models is 378 00:22:25,640 --> 00:22:29,680 that new generations will have lack of understanding of how to 379 00:22:29,680 --> 00:22:32,280 build software. And looking at the industry, 380 00:22:32,600 --> 00:22:36,000 because I'm curious there how, how you see this a few years 381 00:22:36,000 --> 00:22:39,240 back you would be able to do a boot camp or at least this is 382 00:22:39,240 --> 00:22:43,000 what was out on the market. Boot camp, six weeks, two to 383 00:22:43,000 --> 00:22:46,640 three months, education specifically for a core 384 00:22:46,640 --> 00:22:49,440 competency, meaning front end or back end. 385 00:22:49,800 --> 00:22:51,200 And then you would be marketable. 386 00:22:51,200 --> 00:22:54,200 That was the boot, the boot camp kind of marketing strategy. 387 00:22:54,720 --> 00:22:57,400 And some people coming out of that boot camp, they really got 388 00:22:57,520 --> 00:23:00,160 kind of hooked and they found fulfilment in creating and 389 00:23:00,160 --> 00:23:03,240 executing and building. And then they probably landed a 390 00:23:03,240 --> 00:23:06,160 job because there was a big demand for software engineers, 391 00:23:06,160 --> 00:23:08,480 for people that would be able to execute and create. 392 00:23:09,160 --> 00:23:11,480 I feel like the market is kind of flipped upside down. 393 00:23:11,480 --> 00:23:14,920 I don't know if it makes sense to go through a boot camp with 394 00:23:14,920 --> 00:23:18,640 regards to core competencies or skills with regards to front end 395 00:23:18,640 --> 00:23:22,560 and back end anymore kind of cookie cutter model as compared 396 00:23:22,560 --> 00:23:25,280 to taking that same time and educating yourself and using 397 00:23:25,280 --> 00:23:28,440 tooling that is now out there to self educate. 398 00:23:28,760 --> 00:23:31,080 How do you see that? I think that's a good point. 399 00:23:31,280 --> 00:23:34,280 You had companies like Kodish, you're right, that's educated 400 00:23:34,400 --> 00:23:37,280 developers. I've also personally seen a lot 401 00:23:37,280 --> 00:23:39,000 of very good people come out of there. 402 00:23:39,520 --> 00:23:45,640 Also people that's that drought, that's that were not able to get 403 00:23:45,640 --> 00:23:47,560 this fire started in in themselves. 404 00:23:49,720 --> 00:23:52,160 And I don't know what's what. What is the difference between 405 00:23:52,160 --> 00:23:56,320 these people? Like what makes one person gets 406 00:23:56,320 --> 00:24:02,200 really enthusiastic and deep into into the matter and and 407 00:24:02,200 --> 00:24:04,080 others not? I don't know what what the 408 00:24:04,080 --> 00:24:10,040 difference is, but yeah, I don't know where we're going, but. 409 00:24:11,720 --> 00:24:17,280 That's OK. But I, I do think, yeah, I'm 410 00:24:17,280 --> 00:24:22,000 back on track. So I do think that people 411 00:24:22,000 --> 00:24:25,200 nowadays will have way more opportunities to educate 412 00:24:25,200 --> 00:24:30,280 themselves. There is a lot more information 413 00:24:30,280 --> 00:24:34,520 available on the Internet and people can experiment really 414 00:24:34,520 --> 00:24:36,400 rapidly. It's really, really rapidly. 415 00:24:37,400 --> 00:24:40,120 So that might ignite that fire in them. 416 00:24:40,360 --> 00:24:44,520 Yeah, I feel like one of the things I really underestimated 417 00:24:44,520 --> 00:24:47,800 coming into this industry was the amount of collaboration that 418 00:24:47,800 --> 00:24:51,080 I do within a team. Not just within the business 419 00:24:51,080 --> 00:24:53,840 with regards to what are we building and why is that, But 420 00:24:53,840 --> 00:24:55,720 also throughout the team. There were a lot of inter 421 00:24:55,720 --> 00:24:58,680 dynamics of working together and trusting each other and then 422 00:24:59,240 --> 00:25:01,800 letting things be with regards to what other people build and 423 00:25:01,800 --> 00:25:05,120 giving feedback and reviews. From my perspective, that is 424 00:25:05,120 --> 00:25:07,080 evolving. If I as individual have more 425 00:25:07,080 --> 00:25:10,360 building power, more execution power, then maybe instead of a 426 00:25:10,360 --> 00:25:15,040 team of 6, we can have a team of two or three, and that is really 427 00:25:15,040 --> 00:25:17,040 shrinking. So then the focus I had on 428 00:25:17,360 --> 00:25:21,200 trying to fix collaboration, I feel like we'll be much more 429 00:25:21,200 --> 00:25:24,800 focused on the business side of things, trying to understand 430 00:25:25,280 --> 00:25:27,360 what are we actually building and why is that? 431 00:25:27,360 --> 00:25:30,000 I feel like that will be where software engineers are going to 432 00:25:30,000 --> 00:25:33,760 grow, not just going deeper on the technical side, but also on 433 00:25:33,760 --> 00:25:35,800 the business side, understanding outcomes more. 434 00:25:36,240 --> 00:25:38,480 You already mentioned when you start a new project, one of the 435 00:25:38,480 --> 00:25:42,000 first few things you do is research from the business side 436 00:25:42,000 --> 00:25:44,320 and also seeing if it's marketable, which I thought was 437 00:25:44,320 --> 00:25:46,800 quite funny. And I also do that. 438 00:25:46,800 --> 00:25:49,160 And it's because I think I like entrepreneurship. 439 00:25:49,160 --> 00:25:52,960 I like building something also in terms of outcomes, but I 440 00:25:52,960 --> 00:25:55,840 don't, I, I've spoken to many software engineers that are not 441 00:25:55,840 --> 00:25:57,600 like that, that also like building for the sake of 442 00:25:57,600 --> 00:25:59,440 building. And then when they've built it, 443 00:25:59,840 --> 00:26:02,160 that's it basically. That was the fulfilment. 444 00:26:02,160 --> 00:26:03,720 It wasn't the fulfilment that comes after. 445 00:26:03,720 --> 00:26:06,840 For me, it's the fulfilment that comes after and those distinct 446 00:26:06,840 --> 00:26:09,600 parts, the building for the sake of building or the building for 447 00:26:09,600 --> 00:26:13,640 the part that comes after. I see those as very much 2 camps 448 00:26:13,640 --> 00:26:16,080 and 1:00 will be happier. I feel like with a gentic 449 00:26:16,080 --> 00:26:18,440 tooling and the other one building for the sake of 450 00:26:18,440 --> 00:26:22,440 building, that is the part that is rapidly evolving. 451 00:26:22,440 --> 00:26:24,600 So I don't think those people will experience the same 452 00:26:24,600 --> 00:26:28,880 fulfilment anymore. Which is, yeah, it's it's new. 453 00:26:29,000 --> 00:26:32,880 It's never been this crazy in terms of evolution. 454 00:26:33,200 --> 00:26:35,320 No, no, absolutely. I, I think you're right. 455 00:26:35,840 --> 00:26:38,440 So that'll be a big differentiator as well. 456 00:26:39,280 --> 00:26:42,640 But you don't know what happens when people get the headspace to 457 00:26:42,800 --> 00:26:48,280 think about these things. So when you have the, the if, if 458 00:26:48,280 --> 00:26:51,280 you're more an orchestrator rather than an executor, so 459 00:26:51,280 --> 00:26:53,600 your, your roles change. Actually imagine you're stuck in 460 00:26:53,600 --> 00:26:55,760 the old roles, but you discover a genetic tooling. 461 00:26:57,280 --> 00:27:01,240 You will get more headspace to also consider other, other 462 00:27:01,240 --> 00:27:05,440 things. Like I used to be someone that 463 00:27:05,440 --> 00:27:10,200 was deep into my coat as well. That that was my, my whole world 464 00:27:10,200 --> 00:27:16,120 at that at that time. Along the way, I, I learned the 465 00:27:16,120 --> 00:27:20,280 ability to, to zoom out and look at the bigger picture and I 466 00:27:20,280 --> 00:27:24,040 found I found enjoyment in that as well. 467 00:27:25,320 --> 00:27:27,360 But that's something you, you, you learn. 468 00:27:27,360 --> 00:27:30,080 And I think that learning process is accelerating as well. 469 00:27:31,160 --> 00:27:36,520 So that might also affect people who are not there now but might 470 00:27:36,520 --> 00:27:39,120 be in the future. Yeah, I'm wondering in terms of 471 00:27:39,120 --> 00:27:42,960 focus, because I always see myself as software engineer, no 472 00:27:42,960 --> 00:27:45,000 matter if I have the responsibility of a person that 473 00:27:45,000 --> 00:27:48,040 is responsible for product. At my core, I feel like I'm 474 00:27:48,040 --> 00:27:53,240 engineer, but I also feel like there is a lot to focus on or be 475 00:27:53,240 --> 00:27:56,640 responsible for as software engineers in terms of knowledge. 476 00:27:57,040 --> 00:28:00,040 And one of the things I didn't really look at was system 477 00:28:00,040 --> 00:28:02,520 design, which I think is is going to become more important. 478 00:28:02,760 --> 00:28:04,640 So I should put my time and effort into that. 479 00:28:04,880 --> 00:28:08,600 But system design as a whole, it's also how do I make my 480 00:28:08,600 --> 00:28:11,480 software actually run or what does it run on and what are the 481 00:28:11,480 --> 00:28:15,040 underlying components of that Infrastructure wise, I feel like 482 00:28:15,040 --> 00:28:17,640 infrastructure might be a good bet with regards to focus 483 00:28:17,640 --> 00:28:20,400 because if building is accelerating, then yes, we will 484 00:28:20,400 --> 00:28:23,120 have more build pieces of software, but it still has to 485 00:28:23,120 --> 00:28:24,880 run somewhere. It still has to scale to a 486 00:28:24,880 --> 00:28:27,920 certain component, still has to be in the hands of users. 487 00:28:28,440 --> 00:28:31,040 And I feel like infrastructure is kind of the the core 488 00:28:31,040 --> 00:28:33,920 competency there. I don't know how much innovation 489 00:28:33,920 --> 00:28:38,000 has been happening in terms of a gentic solutioning for that 490 00:28:38,000 --> 00:28:41,400 front or if people are still very much operating in the same 491 00:28:41,400 --> 00:28:43,000 way they did two or three years ago. 492 00:28:43,600 --> 00:28:47,560 Do you know? I think it's like cloud 493 00:28:47,560 --> 00:28:52,400 infrastructure hasn't changed a lot in terms of core principles. 494 00:28:53,400 --> 00:28:58,440 It's become more accessible so more people can easily deploy 495 00:28:58,440 --> 00:29:02,800 cloud solutions. But you're, you're right, it, 496 00:29:02,800 --> 00:29:07,320 it's, it is a core component, but it's also also just a small 497 00:29:07,320 --> 00:29:12,120 part of the solution, right? So there is a phase where you 498 00:29:12,120 --> 00:29:15,320 where you do the the infrastructure underneath your 499 00:29:15,320 --> 00:29:21,080 replication, but that might be two weeks, a month and then then 500 00:29:21,080 --> 00:29:26,240 you have it running in terms of like developing infrastructure 501 00:29:26,240 --> 00:29:29,120 scope for example, a genetic models can help with that as 502 00:29:29,120 --> 00:29:30,760 well. Yeah, yeah, yeah. 503 00:29:31,320 --> 00:29:34,440 I did not do any infrastructure as code for a long, long time. 504 00:29:34,440 --> 00:29:37,200 And then I came into a project where that was part of the 505 00:29:37,200 --> 00:29:39,680 responsibility. And then using and leveraging A 506 00:29:39,680 --> 00:29:43,400 genetic tooling because it is code, it was quite powerful for 507 00:29:43,400 --> 00:29:46,480 me to just illustrate and say, well, these are the things we 508 00:29:46,480 --> 00:29:49,040 need to change or what is out there in the 1st place. 509 00:29:49,680 --> 00:29:53,160 It was very good actually at identifying those things 510 00:29:53,160 --> 00:29:54,400 infrastructure wise. Yeah. 511 00:29:54,760 --> 00:29:58,880 Yeah, what what I like about the like infrastructure scout in 512 00:29:58,880 --> 00:30:01,360 general, it's a very deterministic role. 513 00:30:01,360 --> 00:30:06,840 So if I have a template, if I push it to test or production or 514 00:30:06,840 --> 00:30:10,280 to acceptance, it will behave identically because it's a 515 00:30:10,280 --> 00:30:14,920 deterministic template. It's a declarative with AI 516 00:30:15,440 --> 00:30:17,240 coding, that's that's not the case. 517 00:30:18,320 --> 00:30:22,240 It'll it'll write code and if you prompt the same thing again, 518 00:30:22,480 --> 00:30:27,720 it will write different code. So that's, but that, that also 519 00:30:27,720 --> 00:30:33,400 has its appeal because it forces you to design the process and 520 00:30:33,400 --> 00:30:37,960 the tooling to, to fall into surgical strains. 521 00:30:38,480 --> 00:30:45,160 So you have predictable output. So for me, the, the allure of, 522 00:30:45,200 --> 00:30:50,000 of cloud engineering was to create deterministic roles 523 00:30:50,120 --> 00:30:53,720 because I believe that determinism in development 524 00:30:53,720 --> 00:30:58,120 processes makes engineers happy, especially DevOps engineers who 525 00:30:58,120 --> 00:31:00,080 might otherwise be cold awake at night. 526 00:31:02,320 --> 00:31:06,360 And for for example for software migration or writing new 527 00:31:06,360 --> 00:31:12,320 software it is I I get fulfilment about shaping the 528 00:31:12,320 --> 00:31:17,680 constraints around it to produce stable code, high quality code 529 00:31:18,840 --> 00:31:20,680 and scalable code. Yeah. 530 00:31:21,200 --> 00:31:24,920 For people that have then, as an example, a code base that they 531 00:31:24,920 --> 00:31:28,000 want to modernise, that they want to move away from, there's 532 00:31:28,000 --> 00:31:30,320 a lot of vendors that kind of hook you into a certain way of 533 00:31:30,320 --> 00:31:33,000 working with specific components, a specific code. 534 00:31:33,520 --> 00:31:36,720 And if that is 20 years ago, you might still be building on top 535 00:31:36,720 --> 00:31:40,360 of that, which can be quite substantial when we're talking 536 00:31:40,360 --> 00:31:42,760 about absolute lines of code. It can be in the millions 537 00:31:42,760 --> 00:31:45,200 basically. Also with regards to business 538 00:31:45,200 --> 00:31:48,840 logic and the complexity that is in there, you might have teams 539 00:31:48,840 --> 00:31:51,520 that are kind of maybe not even building features on top of it 540 00:31:51,520 --> 00:31:54,240 anymore, but just that are there as insurance to make sure it 541 00:31:54,240 --> 00:31:58,520 runs and they maintain it. Now there is an opportunity to 542 00:31:58,520 --> 00:31:59,920 modernise. And I feel like that 543 00:31:59,920 --> 00:32:02,600 modernisation can be accelerated with tooling. 544 00:32:03,000 --> 00:32:06,720 You already mentioned that we have to make this deterministic 545 00:32:06,720 --> 00:32:10,240 or close to deterministic in terms of quality and outcomes. 546 00:32:10,480 --> 00:32:13,120 It can't just be a finger snap and then you have a new code 547 00:32:13,120 --> 00:32:16,680 base and what is the outcome of that can be non deterministic. 548 00:32:16,680 --> 00:32:19,560 So you have no clue if you can migrate or modernize or shift 549 00:32:19,960 --> 00:32:22,320 safely. But do you think this approach 550 00:32:22,560 --> 00:32:26,320 can work regardless of the scale of the existing code base? 551 00:32:27,640 --> 00:32:31,800 Give an infinite tokens, yes. That's the constraint. 552 00:32:31,800 --> 00:32:33,040 That's the constraint, yeah. Interesting. 553 00:32:33,120 --> 00:32:36,880 So it gets expensive really, really fast to to give you an 554 00:32:36,880 --> 00:32:42,200 impression, the amount of tokens I used for the the game server 555 00:32:42,200 --> 00:32:46,120 migration runs in the billions. OK, so that's that's a huge 556 00:32:46,120 --> 00:32:48,840 project, but it's also a big code base, right? 557 00:32:49,600 --> 00:32:57,040 There were more than I would say about half a million of, of, of 558 00:32:57,040 --> 00:33:07,000 lines of, of code lines assembly C++ and some some old Flash 559 00:33:07,000 --> 00:33:10,320 clients like Flash is also from a from a previous era. 560 00:33:11,040 --> 00:33:14,080 The Flash client actually ran into the millions lines, lines 561 00:33:14,080 --> 00:33:17,360 of code that varies from both. That's that's huge. 562 00:33:18,720 --> 00:33:23,160 So that that takes a lot of processing power to to process, 563 00:33:23,880 --> 00:33:26,160 but you do it in chunks, you do it in little chunks. 564 00:33:28,040 --> 00:33:32,400 I look at the specific set of functionality I want to migrate 565 00:33:32,400 --> 00:33:37,600 this, this piece of of functionality, this slide and 566 00:33:37,600 --> 00:33:41,320 then create a plan for it. So I have an executable plan 567 00:33:41,320 --> 00:33:46,000 with with check boxes you can take off and I work on that in 568 00:33:46,000 --> 00:33:47,920 conjunction with the with the parity tool. 569 00:33:47,920 --> 00:33:51,880 And then when that piece is done, I archive that the 570 00:33:51,880 --> 00:33:56,720 documentation for later reference and also continuously 571 00:33:56,720 --> 00:34:01,280 do regression testing. So that's my new change break 572 00:34:01,280 --> 00:34:03,280 something that I introduced before. 573 00:34:03,440 --> 00:34:07,440 Yeah. So the general my way it's it's 574 00:34:07,440 --> 00:34:11,440 not a really fast process. OK, So it's not like the snap 575 00:34:11,440 --> 00:34:15,960 and you have your new code code base, but I think it's the the 576 00:34:15,960 --> 00:34:19,600 the best way of working to ensure that you produce 577 00:34:19,600 --> 00:34:20,920 something of value. Yeah. 578 00:34:20,920 --> 00:34:23,960 Interesting. The finger snaps way, that would 579 00:34:23,960 --> 00:34:25,719 scare me, right? Because if all of a sudden 580 00:34:25,719 --> 00:34:27,920 there's a new code base and there's no ownership, there's no 581 00:34:27,920 --> 00:34:30,280 people that are in between orchestrating the thing, but 582 00:34:30,280 --> 00:34:33,320 they still have to own it. That's just as like throwing 583 00:34:33,320 --> 00:34:34,840 something over the fence basically. 584 00:34:34,840 --> 00:34:38,360 I don't think that would work. But this way of working, I'm 585 00:34:38,360 --> 00:34:41,679 assuming the same principles with regards to a modernization 586 00:34:41,679 --> 00:34:45,080 strategy would apply, right? If I have a software piece of 587 00:34:45,080 --> 00:34:47,560 software code base I'm modernizing away from, I'm going 588 00:34:47,560 --> 00:34:49,920 to look at my modernisation strategy. 589 00:34:49,920 --> 00:34:53,280 I might want to migrate specific features first or deprecate 590 00:34:53,480 --> 00:34:55,440 certain things. I might want to freeze new 591 00:34:55,440 --> 00:34:58,120 functionality that comes on top of that, or figure out a way 592 00:34:58,120 --> 00:35:01,480 that can build in parallel, although that has risk. 593 00:35:01,840 --> 00:35:04,040 So you're going to do a lot of it's, I feel like it's a whole 594 00:35:04,040 --> 00:35:06,720 risk mitigation exercise. And that still needs to happen 595 00:35:07,080 --> 00:35:10,120 even though you have tools that accelerate and you might not 596 00:35:10,120 --> 00:35:13,720 have to build hands on yourself as much anymore. 597 00:35:14,480 --> 00:35:17,240 That would be my same approach. Still figure out what the 598 00:35:17,240 --> 00:35:20,120 modernisation strategy should be, then approach it from that 599 00:35:20,120 --> 00:35:20,520 way. So. 600 00:35:20,640 --> 00:35:23,600 Imagine that you're building a product with an with an API, 601 00:35:23,600 --> 00:35:26,440 right? And you build functionality on 602 00:35:26,440 --> 00:35:29,200 top of that. Or you deprecate certain stuff 603 00:35:29,200 --> 00:35:33,160 from that API. You would still have to think 604 00:35:33,160 --> 00:35:36,120 about the same principles. I need to deprecate that 605 00:35:36,120 --> 00:35:40,440 endpoint or I need backwards compatibility and you need to 606 00:35:40,480 --> 00:35:43,840 safeguards that. That is actually built in. 607 00:35:44,120 --> 00:35:47,680 So do the the actual checks, Do the API still do the same? 608 00:35:47,680 --> 00:35:54,320 If I call the new API with an with old POST parameters, does 609 00:35:54,320 --> 00:35:56,160 it? Does it return exactly what I 610 00:35:56,160 --> 00:35:59,960 expect? And it it's easy if you have 611 00:35:59,960 --> 00:36:04,440 the, the, the codes of the the old API versus the new API to 612 00:36:04,440 --> 00:36:07,320 write a tool that automatically checks that like how these are 613 00:36:07,320 --> 00:36:12,120 the possible input values and you can do assertions, right? 614 00:36:12,120 --> 00:36:18,200 So if I post this combination of values, I expect this result. 615 00:36:18,720 --> 00:36:21,120 And if not, there is an error in the API. 616 00:36:22,520 --> 00:36:26,320 So you can instruct the agents to to actually leverage that. 617 00:36:26,880 --> 00:36:30,920 Maybe even run simulations for combinations of both parameters 618 00:36:32,040 --> 00:36:38,240 and then say does it in each instance return what I expect 619 00:36:38,280 --> 00:36:42,480 and if not, revise and and fix the error? 620 00:36:43,400 --> 00:36:44,760 Yeah, yeah. Interesting. 621 00:36:46,040 --> 00:36:49,920 I really want to work with this in a production kind of sense 622 00:36:49,920 --> 00:36:52,480 and I'm now at a client where I have the opportunity to do so. 623 00:36:52,480 --> 00:36:55,320 So this is going to be fun. This is the magnitude of things 624 00:36:55,320 --> 00:36:57,560 and the teams that are involved in the code base scope. 625 00:36:58,480 --> 00:37:00,640 I wouldn't know where to start and we're probably going to run 626 00:37:00,640 --> 00:37:03,560 experiments, but I'd like your suggestion of the code base is 627 00:37:03,560 --> 00:37:06,240 not as mature in the current state. 628 00:37:06,320 --> 00:37:10,160 You need to work on the maturity side of that first, so looking 629 00:37:10,160 --> 00:37:13,840 into the existing flows and creating tests around that, or 630 00:37:13,840 --> 00:37:15,480 at least scaffolding around that. 631 00:37:16,400 --> 00:37:19,160 Absolutely. But also so not not only 632 00:37:19,320 --> 00:37:23,440 maturity in the sense of tests and and priority tooling, but 633 00:37:23,440 --> 00:37:25,480 also documentation which is often lacking. 634 00:37:26,280 --> 00:37:30,760 Like the more the more the agent knows about the structure of the 635 00:37:31,200 --> 00:37:37,240 old project and the so so the structure and the the the the 636 00:37:37,240 --> 00:37:41,120 the layout the better. How much of this do you do 637 00:37:41,560 --> 00:37:45,280 manually or how much do you rely on kind of your your agent to 638 00:37:45,280 --> 00:37:48,720 give you input into structure and formalize that is what I'm 639 00:37:48,720 --> 00:37:50,960 still wondering. So when when starting up, 640 00:37:50,960 --> 00:37:55,120 there's a lot of manual input because I have a particular idea 641 00:37:55,120 --> 00:37:58,680 about how these documents should be structured, what should be in 642 00:37:58,680 --> 00:38:01,640 there, what is important and what is not important. 643 00:38:02,640 --> 00:38:07,000 Whereas an agent does a does a wild guess based on inferring 644 00:38:07,000 --> 00:38:11,800 from the from the source code. But I have a more high level 645 00:38:11,800 --> 00:38:17,440 overview of what's what the scope base is and what all pain 646 00:38:17,440 --> 00:38:20,840 points will be. So I make sure that the most 647 00:38:20,840 --> 00:38:26,320 important points are document as well, and then have an agent 648 00:38:26,320 --> 00:38:28,760 revise it once I have the base in place. 649 00:38:29,080 --> 00:38:31,720 Nice. I want to talk about risks and 650 00:38:31,720 --> 00:38:34,800 pick your bane on that front. I've heard a narrative, I don't 651 00:38:34,800 --> 00:38:37,760 know if it was in person or online because sometimes those 652 00:38:37,760 --> 00:38:41,080 blur together, but that certain agents are not as good when it 653 00:38:41,080 --> 00:38:43,320 comes to specific programming languages. 654 00:38:43,320 --> 00:38:47,040 You already mentioned CC Plus plus from the example of 655 00:38:47,120 --> 00:38:50,000 modernizing the the game code base Flash as well. 656 00:38:50,480 --> 00:38:53,840 Is that something that you've experienced in in practice that 657 00:38:54,000 --> 00:38:57,360 for example Rust since it's a newer quote UN quote language, 658 00:38:57,640 --> 00:39:03,880 it's not as good as? I found, I found migrations to 659 00:39:03,880 --> 00:39:07,240 go to be much better than than Rust. 660 00:39:07,520 --> 00:39:10,960 Like Rust. It's it would often lead to 661 00:39:10,960 --> 00:39:13,520 compile errors because it's Rust. 662 00:39:13,720 --> 00:39:15,680 Yeah, that's Rust. Yeah, yeah, that's Rust. 663 00:39:15,680 --> 00:39:17,680 Also, if I do it manually, yeah, yeah. 664 00:39:17,840 --> 00:39:21,280 Yeah, exactly. So that's that takes a few 665 00:39:21,280 --> 00:39:23,760 iterations before it compiles in the 1st place. 666 00:39:24,280 --> 00:39:29,320 Whereas Go I rarely have compile errors if I if I have an output 667 00:39:29,320 --> 00:39:35,160 Go code, I don't think it has a lot of knowledge about Flash in 668 00:39:35,200 --> 00:39:36,920 in general and the models that I use. 669 00:39:37,840 --> 00:39:39,840 Also nobody uses Flash. So yeah, why? 670 00:39:39,840 --> 00:39:45,000 Why makes sense, makes sense, but it could infer from most of 671 00:39:45,000 --> 00:39:51,440 the principles like so my the the Flash client I migrated to 672 00:39:51,440 --> 00:39:56,560 HTML JavaScript. OK, it's got the base right in 673 00:39:56,560 --> 00:40:00,600 one shot, but particularly implementation details it did 674 00:40:00,600 --> 00:40:03,760 not. And then I that that took quite 675 00:40:03,760 --> 00:40:05,680 a few iterations to to get right. 676 00:40:05,920 --> 00:40:08,280 Gotcha. And then when we're talking 677 00:40:08,280 --> 00:40:12,600 about risk, I feel like hallucination is still a thing. 678 00:40:12,600 --> 00:40:17,680 It's getting better and better, but how do you build around or 679 00:40:17,680 --> 00:40:20,120 with hallucination in mind accommodate for that? 680 00:40:21,160 --> 00:40:23,680 That's that's the test to me. That's all the scaffolding is 681 00:40:23,680 --> 00:40:25,520 basically. Is it just for the non 682 00:40:25,520 --> 00:40:27,840 deterministic part? I assume so, right? 683 00:40:27,840 --> 00:40:32,840 Yeah, nice. The same feature parity sense I 684 00:40:32,840 --> 00:40:35,800 could still do regardless of any code base, right? 685 00:40:36,120 --> 00:40:38,080 Because code base will have features. 686 00:40:38,160 --> 00:40:41,400 You have a structure around figuring out if the old code 687 00:40:41,400 --> 00:40:43,840 base behaves the same as the new code base. 688 00:40:45,040 --> 00:40:50,120 So I don't see feature parity working differently for 689 00:40:50,120 --> 00:40:53,280 different pieces of software. So how do you build on top of 690 00:40:53,280 --> 00:40:54,880 that? Because the existing code base 691 00:40:54,880 --> 00:40:57,040 for me feature wise has everything. 692 00:40:57,040 --> 00:40:58,840 It's complete. That's what you're modernizing 693 00:40:58,840 --> 00:41:01,080 away from. But the new code base you're 694 00:41:01,080 --> 00:41:03,720 going to incrementally build up in terms of features. 695 00:41:04,040 --> 00:41:07,200 Sometimes it's just a ball of mud and features kind of are 696 00:41:07,200 --> 00:41:09,840 very much interwoven. How do you accommodate for that 697 00:41:09,840 --> 00:41:12,400 when you're moving to a newer code base? 698 00:41:12,800 --> 00:41:16,560 So the the advantage of the the approach I described is that you 699 00:41:16,560 --> 00:41:19,840 also you, you already have your tests written right in your in 700 00:41:19,840 --> 00:41:22,520 your old code base because you're maturing that you already 701 00:41:22,520 --> 00:41:25,040 have your parity tooling running properly. 702 00:41:25,520 --> 00:41:28,400 That also means that in the new code base you will also have 703 00:41:28,840 --> 00:41:31,720 tests already written and you will have regression tooling 704 00:41:32,200 --> 00:41:37,280 that checks whether a change that you made, but it leads to 705 00:41:37,280 --> 00:41:42,560 to a regression bug for example. So that makes it really easy to 706 00:41:42,560 --> 00:41:46,400 to iterate on it. And if you are going to continue 707 00:41:46,400 --> 00:41:49,520 with agentic coding on the new project as well, which I didn't 708 00:41:49,520 --> 00:41:55,720 assume is the advantages, you can can use the same pipeline 709 00:41:56,920 --> 00:42:01,120 and you can codify that into your documentation that that 710 00:42:01,120 --> 00:42:03,840 needs to happen every time a build this room for example. 711 00:42:04,880 --> 00:42:08,760 That newer way of working, if we have an existing code base, you 712 00:42:08,760 --> 00:42:11,800 can structure it in a way that agentic tools work quite well. 713 00:42:12,160 --> 00:42:16,160 There's a narrative online on skills versus agents and how 714 00:42:16,160 --> 00:42:19,040 much documentation is too much documentation, how explicit you 715 00:42:19,040 --> 00:42:22,240 need to be versus relying on implicit model knowledge. 716 00:42:22,760 --> 00:42:26,640 I feel like years ago you had to be very explicit, but nowadays 717 00:42:26,640 --> 00:42:29,720 there's a lot of implicit model knowledge. 718 00:42:30,400 --> 00:42:32,920 The way of working that software engineers are going to go about 719 00:42:32,920 --> 00:42:36,440 is very much changing. I'm on the train of I feel like 720 00:42:36,440 --> 00:42:39,600 spectrum development is quite effective if I put my time and 721 00:42:39,600 --> 00:42:42,760 attention in building a spec. And also a spec is quite 722 00:42:42,760 --> 00:42:44,040 arbitrary. I've noticed people have 723 00:42:44,040 --> 00:42:46,760 different interpretations of what it is to create a 724 00:42:46,760 --> 00:42:50,640 specification, but if I have a very solid spec that actually 725 00:42:50,640 --> 00:42:53,760 aligns with the feature that I'm trying to build, then the 726 00:42:53,760 --> 00:42:55,960 building of things is actually quite reliable. 727 00:42:55,960 --> 00:42:58,920 If I have really good conventions, that is even 728 00:42:58,920 --> 00:43:00,360 better. And if I have the right 729 00:43:00,360 --> 00:43:03,680 scaffolding and the right kind of safety net in testing and 730 00:43:03,680 --> 00:43:05,920 resilience, that's the best, to be honest. 731 00:43:06,440 --> 00:43:09,920 So I really see that as kind of at least right now how we're 732 00:43:09,920 --> 00:43:12,760 going to operate in the future. What is your view on that? 733 00:43:13,600 --> 00:43:15,600 Yeah, I think that's a devil evolved, right? 734 00:43:17,160 --> 00:43:23,120 So absolutely. I have a have a fun anecdote. 2 735 00:43:23,120 --> 00:43:28,400 weeks ago I had a session with a colleague of mine who works for 736 00:43:28,400 --> 00:43:37,000 CBA and she had an idea for 10 years to create a it's it's for 737 00:43:37,000 --> 00:43:44,280 the the real estate market but she's not technical and so she 738 00:43:44,280 --> 00:43:48,440 asked me and another colleague to to help her out with with AI 739 00:43:49,000 --> 00:43:50,720 to create this application for her. 740 00:43:51,640 --> 00:43:56,320 What I did instead is show her agentic coding. 741 00:43:56,760 --> 00:43:59,840 How does it work? I set up the the the base for 742 00:43:59,840 --> 00:44:02,640 her like this is how you structure your projects. 743 00:44:03,800 --> 00:44:10,280 Here's how you create a plan and then the first iteration I 744 00:44:10,760 --> 00:44:15,920 instructed the the model to create a a plan from her. 745 00:44:16,160 --> 00:44:20,120 She had a document with functional requirements, which 746 00:44:20,120 --> 00:44:24,200 was quite elaborate. And then the model created a 747 00:44:24,200 --> 00:44:27,760 implementation plan from those functional requirements and then 748 00:44:27,760 --> 00:44:32,600 started implementing them. And within the hour there was an 749 00:44:33,720 --> 00:44:39,360 like a POC application that she could already showcase to a 750 00:44:39,720 --> 00:44:42,840 venture capitalist for for investment, for example. 751 00:44:44,240 --> 00:44:49,560 But then I gave her the rates. I said, now you're going to do 752 00:44:49,560 --> 00:44:52,560 it. She prompted the next bit of 753 00:44:52,560 --> 00:44:55,760 functionality. And then I uttered the words, 754 00:44:55,840 --> 00:44:58,760 you're now a developer. And she, she lit up. 755 00:44:58,920 --> 00:45:06,200 She, she realized she was now she had the efficacy to, to, to 756 00:45:06,240 --> 00:45:14,160 execute on, on her vision. So I think that's that's that's 757 00:45:14,160 --> 00:45:16,680 a great way for her to to to to start. 758 00:45:17,560 --> 00:45:23,160 And now she understands she's, she's still not technical, but 759 00:45:23,160 --> 00:45:27,880 she knows how to structure her project, how to iterate on it, 760 00:45:27,880 --> 00:45:32,200 how to, how to create new versions of her application to 761 00:45:32,200 --> 00:45:35,160 make her vision come true. I don't know if that answered 762 00:45:35,160 --> 00:45:37,520 your question, but it's something I had to think about 763 00:45:37,520 --> 00:45:40,240 when you said that made. Me think of another question 764 00:45:40,240 --> 00:45:44,440 because I know topics like these can be quite controversial for 765 00:45:44,440 --> 00:45:47,040 different audiences, but especially the people that have 766 00:45:47,040 --> 00:45:52,480 gone through education with the software or have years of work 767 00:45:52,480 --> 00:45:53,880 experience under the belt, right? 768 00:45:53,880 --> 00:45:56,480 If you would say she's now a developer, there are many people 769 00:45:56,480 --> 00:45:58,760 that would say actually she's not because she doesn't think 770 00:45:58,760 --> 00:46:02,360 about XY and Z. But I do agree that this build 771 00:46:02,360 --> 00:46:04,840 process, that's the part that gets a lot easier. 772 00:46:05,120 --> 00:46:07,800 So I'm very much wondering then, when do software engineers or 773 00:46:07,800 --> 00:46:10,520 the people that currently are engineers come into play? 774 00:46:10,520 --> 00:46:12,760 Is it when it reaches a certain level of scale? 775 00:46:13,520 --> 00:46:16,120 But the people that are driving, they will never realize that, 776 00:46:16,120 --> 00:46:18,880 OK, this is when you actually need certain foundational 777 00:46:18,880 --> 00:46:22,320 knowledge or expertise. There was a LinkedIn article on 778 00:46:22,320 --> 00:46:25,920 someone that made an app and the app was actually, people had to 779 00:46:25,920 --> 00:46:28,800 upload their pictures and it was kind of a social network app. 780 00:46:29,480 --> 00:46:32,360 And it was completely orchestrated and built in the 781 00:46:32,360 --> 00:46:36,680 way that you exemplified. And there was a security breach 782 00:46:36,680 --> 00:46:38,680 and all the images got leaked and stuff like that. 783 00:46:38,680 --> 00:46:40,840 So that will definitely be concerning. 784 00:46:40,840 --> 00:46:43,000 I feel like I don't have an answer for that yet. 785 00:46:43,120 --> 00:46:45,720 No, we we're usually brought in when the house is on fire, 786 00:46:45,720 --> 00:46:46,960 right? That's when you need real 787 00:46:46,960 --> 00:46:49,600 software. Damage control, Yeah, that's it. 788 00:46:49,600 --> 00:46:53,000 That's the reality. Yeah, no, So I I took the phrase 789 00:46:53,000 --> 00:46:55,160 you're now developer from from Netlifi. 790 00:46:55,160 --> 00:46:56,680 You're probably familiar with it. 791 00:46:56,680 --> 00:47:00,160 That's, that's what you see the first time you deploy an 792 00:47:00,160 --> 00:47:02,760 application to, to Netlifi. You're now developer. 793 00:47:03,440 --> 00:47:08,120 And the idea is to, to, to, to empower people to make them 794 00:47:08,120 --> 00:47:10,160 enthusiastic so they deep dive more. 795 00:47:10,800 --> 00:47:14,680 Of course, to, to write great software, you still need to be a 796 00:47:14,680 --> 00:47:16,200 great engineer. It didn't change. 797 00:47:16,200 --> 00:47:18,640 Yeah. Yeah, thanks so much for coming 798 00:47:18,640 --> 00:47:19,920 on, Dennis. This was a blast. 799 00:47:19,920 --> 00:47:23,120 I love picking your brain on modernisations and just your 800 00:47:23,120 --> 00:47:25,160 general principles on building nowadays. 801 00:47:25,600 --> 00:47:26,840 You're more than welcome. Cool. 802 00:47:26,960 --> 00:47:29,040 We'll round it off here. If you're still listening, let 803 00:47:29,040 --> 00:47:31,320 me know in the comments section what you thought of this episode 804 00:47:31,320 --> 00:47:32,360 and we'll see you on the next one.