How Elite Software Engineers Are Using Agents to Get Sh*t Done

I see so many engineers immediately go off of the cliff, basically believing the sales of marketing message. This is a black magic and it will overtake your return. We tend to come out at two hours of actually coding time and day. So we're basically optimizing for the wrong thing. Your role has never been created in Coke. Your role has been translating requirements from the business into something that will add value to your users. It's super interesting to see the time that we're in right now and how that evolves. And we can steer it a little bit, but it also is already completely out of hand. Our engineering is changing and the authentic tooling is the catalyst for this change. If you don't use it yet, listen to this episode. Joining me is Rob Boss, Microsoft certified trainer, DevOps engineer, and he has trained thousands of engineers that now have changed their way of working. So enjoy. Which part do you think is the most important for people to get when it comes to AI and software engineering? They're starting to get. What the heck is AI? Because I see so many engineers immediately go off of the cliff thinking basically believing the sales and marketing message. This is a black magic and it will overtake your work. And it's just fancy algorithms. There's nothing under the cover as if you look on it. It's just smoke and mirrors. So if you know the basics of what an LLM does, then you can at least have realistic expectations of what you can get from them. And it's just very much lying through its teeth saying you're the most awesome thing and then you mean being your role is right. So if you keep that in mind, then you get more realistic expectations of what you can get out of the tool as well. So that's for me the most important part. We wrote a book and get a co-pilot. Chapter two is on their own purpose, which is just what the heck is Gerrit Havai. It's 25 pages of just examples of this is what Gerrit Havai is both for audio, video, and text work example. So that you have realistic understanding of what can I get from this. And you use examples like the most fun one tends to be with engineers is give me your random number between 100 and 100. The answer should always be 42 because that's the magic number. And engineers get that. It's a little bit of humor as well in there, but it makes sense to them that, okay, this is just a proper ballistic causation that you get back. So that is the most important one for me, just understanding the basics. How much of that do I need to understand from being a software engineer? If I don't do any Genie I in production, let's say, but if I just use it from a tooling perspective, you've got five slides on it. Super basic, it's just the next word prediction. Basically that is in there. Usually people can get an understanding of that. And that the LLMS have a concept of semantic understanding of what is in there. So they know that a monkey is an animal, a dog is an animal, and a cat makes an animal. But those three animals can produce noises and they probably sound different. So that's semantic understanding. If you get that in together with text prediction, basically the next word, what you're doing your phone as well, that tends to be enough. Yeah. So that's the basic, it's just the next word predictor that you have there. And then the rest of you just add more compute to it and add more bigger models to it. You get basically the same thing. Gotcha. Yeah. So if that's the most important part, understanding what it actually is and brings to the table and specifically probably also what it is not, what is then the next thing when it comes to people leveraging this for their own productivity or impact. I would say understanding how it impacts your workflow itself. So where can I augment it with these tools that we have at hand to get something extra out of it? Can be better understanding, can be discovery of new things that you didn't know before. But also I tend to be a lazy engineer. So how can I implement this in my own way of working to do less work myself? And that goes down to the silly things of I have a 30 column, C is V, just a couple of hundred rows, throw that out and say, I need the third column of this. That's me being lazy. You can use that for that as well. So if you see those kinds of opportunities to work this into your own process, that's where a lot of the benefits start to stack up. What examples do you give people? Because I feel like if I understand it, I've learned the most probably through pair programming where I've seen other people use this and use this effectively. And I'm like, I like that. I'm going to steal that and put that in my own way of working. What do you show people? Those kinds of examples indeed. Live working as well. We tend to weave that even into our trainings because we see over and over again that most of the engineers, they consider it to our training that is just blown away what they have. And then they turn around, go back to work and forget everything that you just saw. So you need to have hands on experience to implement this in your own way of working. So we tend to do that as well. And that could be, usually we start with adding unit tests to code, for example, as in documentation. But also to show that if you have that concepts in place, then you get better results out of the LLM because we have more context to give away if this is the intent of what the code is doing. And then we start building on top of that as well. So usually it starts there and then you go faster and faster and faster. If you know that you follow an MVC set up, for example, in your application, then instead of going to a class, adding a field, going to the interface, making sure that everything is there and then to the front end, implementing it, you start doing that in one go. And all of a sudden people go, oh, but this is interesting. And now we can actually start augmenting the way that you do certain things. So we specifically start very small to speed up in the end as well. And for me, the big important part of the training is always start with that small part as well. Because if you just end up at the last stage, then you're basically selling the smoke and mirrors and nobody has an understanding how they got there. So you really need to take them out of hand and explain those kinds of things. But then the smaller things, do they include things like, as you are typing line completion or have we gone completely beyond that stage in terms of what we have now? And still start there on purpose. So that also to explain this is how we started with LLM basically. This is where it helps first. And usually after two or three demos on top of that, I say, I don't use it anymore. Okay. That's how I live in agent mode because I'm lazy. And usually that translates over as well, right? We're engineers. So we try to make our lives as easy as possible. So if we can skip a couple of steps and just validate the output data there, that makes my life a lot easier. So I tend to live in agent mode, even up to the jokes of when I need to change the single line of code to actually go into the code base myself and fix it or do I hand it over to an outlet? Yeah. So yeah, that's usually how the flow goes there. And what do you do nowadays? Is it you give it to the agent or you do it yourself manually still? It depends. I'm also very environmental conscious. So I am aware that this stuff costs compute. There's CO2 involved with all the machines that are running. I have cooling water that is there. So I sort of still have it in me to say let's do this manually. I can probably fix this more efficiently. Until you're really lazy and you have that CSV file again. Yeah. It's a matter of effort and how much would I joy doing this task for example? Gotcha. I want to put a pin in kind of the environmental impact because I do think that's quite interesting. But there's been a lot of studies and I don't know how old these studies are, but that's what people tell me AI does not increase productivity. And I feel like me as an individual, I disagree. But there's a lot of noise out there where people are in two camps, right? It's either all in or it's all doom and bubble. Where are you here? Yeah, I have this conversation with customers a lot as well. And especially of course management, they follow the sales pages and the marketing decks that are there. And this is black magic. We're going to go 40% faster. I'm still a DevOps engineer. That's my background. I always propose the question bag, how fast are you going right now? Nine or ten times, they have no clue what that means. Okay. So it's nice that they pose the question to us. And that we even need to explain what the ROI will be of implementing tools like GitHub Copa, not RLM, supported tools. Even up to the point of this thing costs 20 bucks a month. Whatever it's talking about. If I save you 15 minutes a month, we already have the ROI there. So why do we need to have the discussion? But on the other hand, if you need to do this with a couple of thousands of engineers, this will cost you half a million or more on a yearly basis. So there's definitely a chunk of money that needs to be discussed budgeting wise. How I look at it, if I join a customer and I'm not allowed to use these tools, I will probably try to leave. You're out. That's the point where I'm already at. I don't want to do this stuff anymore myself because the other thing can help that for me. And I'm still a devil's consultant. I want to focus on what brings value to the table. And it's not me writing that line of code. It is actually producing the business value that we need there. So if I can get there faster, I can focus on the other things. And for me, the other things tend to be things like technical debt. Because that is the stuff we've been ignoring for years and now can actually find some time to start looking into that. If I claim that time, that's the biggest if that is in there as well. Because management tend to focus on we're going to do more with the same people that we have. And we still fall over in the same pit of doing that. We don't look at technical debt. So what we're now saying, for example, is that tools like GitHub Copaola that I use basically do the same thing as we've been doing for the last 20 years as well. Devops did the same thing, has all the same thing. It will highlight the problems that you're already having your organization up to a certain extent. And AI is a massive magnifier for that. So you see that we're focusing again on producing more code faster. If you look at certain research, I usually have one state of the, I don't know. So I tend to look at the research that is there. We have a report from 2019 that we can link in the show notes, for example, that asked 3000 engineers. What do you do on a typical day and set it up into separate segments of hours and then start looking at what you do. You tend to have a lot of meetings, even back then in 2019. We tend to have a lot of meetings, we tend to look at architectural We have discussions on how we're going to approach certain things. We do requirements engineering. You talk to your PO and your scrum master. Net under the line, we tend to come up at two hours of actually coding time a day. So we're doing all this work with all the ROI that we need to have there for the two hours of data and an engineer can actually produce code. And we get faster code, more code out of that process. The other six hours we're not even looking at how we can implement AI there and help them forward doing those kinds of things as well. So we're basically optimizing for the wrong thing that is in there as well. So it's interesting to see how those kinds of discussions happen as well. Yeah, you can see that. I feel like the companies that are not at that level where you have a lot of meetings and let's say hands off work. Those were probably experienced the most significant impact where all of a sudden you can parallelize and if you're already coding eight hours a day specifically, then I don't know how that's going to feel cognitive load wise. But likely you will go a lot faster. And the interesting part there is the coding part will go faster. What do you do with your review process of that code? Can you actually absorb those code changes and push them into production with high quality still in production? So we're having more and more discussion instead of just looking at productivity of do you already have a notion of what you're as the LC looks like? Yeah. So for development lifecycle starts at the ideation of we're going to do something. Are we using AI in that process already all the way up to production? Can we see that we have more or less bugs in production? Those are performance go up or down? Can we find it back into something that the AI did? We do something wrong in the process. The then engineer just said, you'll lower everything and push to production. We'll see it after Friday and we'll go home. So those kinds of things, if you don't have that covered, then you don't know if you're actually getting the gains in the production environment coming all the way through the SCLC or no. Yeah. So again, we're focusing on the two hours of the day that people can produce code. We produce more code, which puts pressure on things like the review process. This for me is really going to be the responsibility, probably of the engineering leadership now and also moving forward into the future for individuals as hands on engineers. I'm curious to hear what you think. Should they then be still thinking of their productivity and also the software development life cycle in and of its own or suggest focus on kind of what they're therefore and executing and optimizing that and also just enabling themselves with the rest of the tooling they have. Yeah. And you're asking the DevOps engineer. So yes, that's the whole thing. And that's for me as well. What makes AI work is having a good solid foundation to stand on. If you don't have those things in place, then AI will just magnify what you already have. And that's probably a lot of technical depth that is not there. So you think you're going faster, but only in one aspect because you can't live with the value in production. So for me, the way of working always is I need to have tests available. I want to be able to run this locally in Validate that works on a seed work if necessary. And I now go so far that in my automated testing, I want to see the delta as both visually and in code. So I use AI to make something that can build up screenshots of the before situation and the after situation. And I see the working code and can validate does this make sense? Or do we slide back on call of E for example, or is that button still 10 pixels for too far to the right? You want to have that kind of control. So if you don't have that in place, then this won't help that much. I can see that. Yeah. This is a conversations I've been having more recently where, okay, we talk about AI productivity. But if we in the end, accelerate and produce more code, that's going to have significant impact on other things. Right. Is there enough input in terms of functionality and assumptions that we want to validate to have enough to build in the first place? And then once we have built, what does the review process look like? What call decades do we have? Are we going to go more bugs in production faster? Because that's not really what we want. Are we going to have security issues in production faster? Because that's also not what we want. There is a lot of resilience that needs to be underneath there. And it goes back to you. Can we actually measure value in production? Which we've been trying to do for 20 years. And that's a tough job to have. Yeah. So it's interesting to see how it goes. I had a conversation yesterday with a customer that was actually already so far that they said, we can't start with AI with the developers just yet. OK. Because our business analysts don't have the capabilities yet to deliver the user stories that they need to implement. Gotcha. They'll go to fast otherwise. Yeah. And then the pipeline will just be depleted from the business analysis. I said, this is your opportunity to bring the business analyst on board and write this stuff together. Yeah. The same thing like we're doing for the last 20 years, TDD, BDD, bringing the business analysts because they have the knowledge. So some customers are almost at the point where they almost see the light. And that is where you find a lot of the core vibration and start going faster. I would like to be then a situation where my repository is so well set up from front to back through the SELC. That basically a good stakeholder or good product owner can write the stories by themselves. And the LLM can produce the pull request for me. So the engineering role changes then into more of a VVU role. Thus, this with the requirements, which technical requirements do we have? Writing software for an embedded device is completely different from writing software that needs to be handled at the scale of a large. A web show, for example. Gotcha. Yeah. How many organizations have you seen where this is actually reality? Or is that a vision that is a little bit more further into the future? Some of them are already pretty far down the line. I see you still see a lot of customers that come our way that are still some of them are even just getting their toes wet. Okay. Really on the starting point of here, I everywhere management is on my neck. We need to do something with AI. Let's try it out. That's usually where we come in as a training partner that tends to be the motion. We have a couple of customers that are already fully implemented. 70% plus of the population is using it, for example. And they start asking the question, what is the next step? So it's a mix of that whole scale. Gotcha. Yeah. In a nutshell or in a vacuum, I would say you have to have a certain resilience. You have to have certain software maturity with regards to this is where you need to be. And then you can have AI effective on top of that. But you already mentioned this is now what I'm used to. And if I don't have that, then likely I will go to another place, which means that companies are kind of you cannot wait until you have one. Because otherwise people might leave if this is now the newer way of working, which is quite interesting. It's simple like we have before. If you come into a shop and they don't use your favorite editor, that might be a discussion point during the conversation initially. It's going to be painful. Yeah. And that goes for the stack as well. We still see a lot of engineers being almost married to the stack that they use and they don't want to go across the field or something else. For me, that goes away now with AI because that makes it easier. But that feeling is still there. And even up to the point of I want to use my favorite AI tool as well. There are people who have grown up on cloud code and they don't want to use anything else. And for me, that's the same way I get a copilot because that is where my muscle memory lives. I'm open to look at other things, but this is where I live and breathe right now. So that's the easiest for me as well. Gotcha. Yeah. There might be skeptics listening that have said I've tried this years ago, doesn't work. Not for me. I love the craft of writing software. What do you say to those people or how should what should they at least try to see this newer world or way of working? The main thing again for me is having a basic understanding of what it is. Okay. Because that also teaches you what it is not. And that's what I tend to see going wrong with these things. They believe the smoke and mirrors, they look into that, they try a prompt. It's crap. They get really garbage out of that and they go, ah, there's nothing for me. It's garbage. And a couple of years back, that was definitely true. The rate that we at the body models are being improved the poll and how they grow and being retrained. It's amazing. It's really ridiculous. So we regularly have these sessions with people as well, but they come into a train. I've had a couple of those sessions where I open up a training, explain what I was going to do. And they already said in the intro, it used to be crap. This is all really bad stuff. I'm now here for the last chance. Yeah, it got two hours to convince me. Okay. Try me. And two hours later, they come back and say, holy crap. I didn't know you could do that. I haven't seen that. I didn't look at that. And I missed the part where it explains this is what you can expect from it. This is the realistic stuff that has in there. That's why I find it so important to discuss that. Even now, the bigger models, bigger context windows, it's still important to understand what you can get from prompt engineering, context engineering because that is very imperative on what you're trying to do. Even choosing the right model for the right task will have an impact. So you need to know those kinds of parameters to be able to get the most out of that. And that's something that works perfectly fine to explain that to engineers. It's a bit harder to explain that to POs. For example, it don't have that technical background, but engineers can usually understand that pretty good. Gotcha. Can you explain it for me? From your perspective, what is this general concept? At least to a degree where engineers should know what this is. And then also why prompt engineering, for example, or context management makes sense in the end. That's a good one to do without visuals. Now, it is, yeah, I'll try to do my best there. Yeah. It's a new to see what we've done with LLMs is training on so much data that is available, that they have at least a semantic understanding of what happens with words and the parts of words that are there. So they tend to learn that talking about a dog usually involves the color of the dog. So the color means something and it can belong to that dog as well. So having an understanding that the LLMs tend to work with focus that is there, attention to a specific word that often is in the same place or in the same sentences almost of other words as well. That groups them together, has a sort of a gravity on top of that. And that is being used for translating that into what What can we produce as the next word in a sentence? That's usually how we dumb it down. So if I say a cat made a noise and I start doing something with that, you usually tend to fill in the blanks that happen there. That's what AI does as well. So it tries to continue the sentence with whatever is the most logical thing in there. So if you say I heard a cat actually making a noise, so I heard a cat is already, I heard it making a noise. Then there's a couple of options that follow after that. The cat could be hissing, the cat could be purring, something like that. From that you choose the most probable thing that is in there. If we just had a previous sentence talking about a cat, then usually the cat doesn't respond, talking about a dog, then usually the cat doesn't respond that well to a dog. In all of the examples that we have generated as humans, there used to be usually a attention to that. So it's probably not the following word when you say I heard a cat, it's not necessarily purred if the previous sentence had a dog in it. So that's how the attention works inside of an element itself. What we've done with generative AI is transpose that knowledge of the language that we have used over everything that we have. So you can do this with wave forms. It's just binary data. So you can project the next part of the wave form as well. Now we have generative AI in a form of music and sounds. You could do the same thing with video except for that it works a little bit different on the covers, but you can think of it as the same way. We translate a script back to a natural language, we then extend the paragraph, for example, of what the script is for that video, and then we can generate the video again based on what we have in the language part. So that's usually the high overflow of this is how I look in generative AI. Gotcha. For me, this is, I understand it from a language and semantics perspective. It's just mind blowing to me that it also works in, you also mentioned sound, you also mentioned video and also now code. And it works really, really well in code. Like I've been mind blown to a point where I'm now, I'm kind of desensitized to it. I'm like, yeah, because this is the newer normal, but still in a nutshell, it's very cool. And that's the whole thing of this, right? We threw a lot of data at it and the data is structured, then all of a sudden things belong to each other. That's how I usually frame it in my mind. And there's nothing more structured than a code language. There's always parentheses, there's always four loops, if loops and things like that. And they have a semantic order where they always will appear. Sometimes you can leave off sort of things in the different languages, but for those kinds of structured structures, even for those kinds of setups, it works so really, really well. That's also why even translating from a language to a different language works, both in code and natural language as well, because our languages follow that structure and that's why the whole LLM has been built upon. Why does the nuance of my input being a prompt, why is prompt engineering even a thing? It goes back to that whole attention span that Gen. V.I. has. So it zooms in on the words that you use. We usually have the example of the animals that live together in the sort of the same space. So if you see that in 3D space, usually animals are in part, in one part of the cubic environment, for example, if you think of that. But a skateboard is a very different thing. It's probably not in the same location if you start looking at that. They still are the word color in there, because animals can have a color, but skateboard can also have a color. All of a sudden, that gravitates towards you, and that's how the LLM's link things together. That happens with prompt engineering as well. So as soon as you start adding certain things to your prompt that is in there, it will go in a certain direction. Most of the models now I have thinking options as well, so this can start to reason all the things that they want to implement. But if you just say, here's my code base, fix it, then you hope that the reasoning in the model will start going through the thinking tokens that it has, reasons through the usages input it, me that I need to fix something. So apparently something is broken. So I will start looking for bugs. Which means that also calls compute and thinking tokens to start reasoning through that. If you go in and say, there's a bug, this is the error, and probably that file is necessary to fix this, then all of a sudden it can skip a lot of that thinking. And you've done now prompt engineering, also gravitating towards a specific direction. If I say the requirement that we have for a code base is that this needs to be super performant, very memory efficient, I've drawn it into a certain direction. So the attention is everything in LLMs, and this is what you do with prompt engineering. If people are listening and they are, let's say, at level zero or level, tried it a couple years ago, I don't like it. That's why I'm at level zero. It's like zero with an explanation. How long does it get for them? And also what material do they typically use or would you advise to get to that newer way of working level zero to hero side? The main thing is get your hands on it. Okay. You really need to spend some time here, and I usually say it easily takes you six months to really grasp what is happening here. It took me that in the beginning as well, and I'm using this every day. And in the first six months, I almost had an epiphany every single day or week. I even have the anecdote where I give a lot of the training. So I've grown up on the new things that were available. We've been doing this for a year and a half or so, and I was working with another trainer. They joined a half way through the session. I gave a demo. We went to lunch and he said, I didn't even know you could do that. And he's been doing this for a year as well. And then after lunch, we switched roles. He gave a demo, and I said, wow, I have never thought of you doing it this way with that specific stuff. And to be honest, that still happens right now as well. It goes so fast, this field, every week, something new pops up and go, wow, I didn't think we could implement it there as well. But for the first time, if we really start working with that, easily six months, where some of the things just all of a sudden click. And it can be little things like your typos don't matter for elements. They've been trained so much data that usually the concept of a word is good enough. As long as you can fumble about that word and sort of hear what it still is, that's good enough. So me internalizing, I don't have to fix my typos, for example, that took me a while because I tend to be a writer, I write books, I write blockpohos, I give a lot of training, so I need to create a lot of slideware. You don't make typos. So that's the hard part. Well, when I now give demos, I just fumble through words and be honest about it during the session as well. So I'm not fixing all my punctuation, I'm not writing capitalized even anymore when I say, I did something. I'm going to go with flow, a lot of them will figure it out probably, and nine or ten times, has this been confrontational for you? Because me, I don't have that long of a career to compare to some of the people I've had on or compare to some of the people listening. And for me, saying, okay, six months, I'm going to learn this new skill, new way of working, I try to believe in it, I see the value. It's not that big of an investment for me versus the people that have like 20, 30 years under their belt. And this is the way of working, it's like ingrained, they live in breathe. Is that confrontational that they have to kind of, they have learned this newer skill, which is actually quite a big skill in the end now. And especially with the scarer front of the hand of, I might lose my job because that's the interesting part. Am I working towards deprecating myself? Yes, that can be very confrontational. I never was a magnificent coder. I was always focusing on, I need to be very pragmatic and I want to solve the issue at hand, so I focus on the business value. That was very natural to me. So that's also why now at the point of, I don't care anymore about necessarily every single tidbit that is in there, the code needs to work. That's my main thing. And I've seen a lot of languages now, sometimes it just goes to an adult, I mean, so implement this for me. And sometimes it comes back with an idea of solution, and a lot of times it comes back with Python. For me, that doesn't carry, I don't care anymore about that because I've surpassed that stage already. I want to have a working solution that I can still manage to continue to work on top of that. I want to do some maintenance, I want to be able to do some changes, but I don't need to know every single thing that is in there. What I am good at is describing what I want to have implemented and how I want to validate that it works. So the Devils Foundation is usually the first things that I focus on anyway. And I did that as an engineer as well. I usually started with, I want to have a CIN in place before the repository was even there because I want to have that from day one. If I need to do that two weeks after the fact, then it will just cost me too much time. So I haven't been that stringent on, I need to have hands on code. This is stuff that I need to love and create myself. And I could grow 10,000 lines in a week. I've never been in that place. Some people are at that place and they might really feel that this is something that will have an impact on them. Some people are really searching for what will be my added value. And that's usually folks that have gotten away with this same setup for so long that they made themselves indispensable. And now all of a sudden the code will be around saying, "Okay, anybody can do that." Even up to the point of really all legacy systems, the LLM's work amazingly well with most of them. Yeah, you can just toss them in there saying this is a structured line merge, figure it out. And people have been doing that even with the language that uses spaces as indentation and things like that. The LLM can get it from there because it's structured. And that makes all the difference. So a lot of people are soul searching now of what is my role as an engineer. And I tend to say that when your role has never been created in code, your role has been translating requirements from the business into something that will add value to your users. Whether it's that, external users, internal users, platforms that you build, you want to add value there. So that's the focus usually. I wonder if engineers that really spend a lot of time kind of on hands on code, I feel like the skill of crafting code might change significantly. But also since I am, or I've stepped onto a higher level, I am thinking more in terms of systems and I am making it very explicit, the thoughts that I have. And if I don't know, but I still have to make them explicit, I do. have to reason and think of them. So I do feel like on some front, my hands on skills, they're going to change. But on other fronts, I feel like I am becoming a better engineer. If that's now the way or the abstraction that I need to reason over to actually have explicit input to something that does the code in the end. And usually the flip for me is the point where you start asking questions, how should I approach this? Yeah. Because I know five ways to implement this. I don't care which one is necessarily the best, but give me some options. And I probably get six options back. And that's six one. That is what the money is. And having that inquisitive mindset of I want to do some splunking first, I want to explore left and right. And let's see what is in there. That is where all the values got because what do we tend to do as engineers zoom in immediately into the fix for a problem. Yeah. I know it is in that class. Something happens there. Well, no, take a step back first and look at what is happening. I heard an engineer actually even explaining that during a call where everything was on fire, production was done, they need to do something. And they spent three hours with nine engineers trying to figure out the problem. And after two and a half hours, one engineer picked up the actual error message that was in there, tossed it into an LM and had it fixed within 10 minutes. That's what we tend to do as engineers. You're merely going through the depend. So being able to take that step back and say what options do I have? Being more of an explorer and all of a sudden you get better options back. And then you can make sensible decisions. That was really something for me that flipped off. Okay, I can actually now start thinking in a different way. Where is the business value and how can I achieve it without necessarily taking too many shortcuts for example? I've heard a narrative where people are saying, okay, this works now because it's the data that it's been trained on, which means that if we fast forward 10 years in the future, it's not going to be as good or in really new innovations. It's not going to be as good as. But then I do see that a lot of like older legacy co-paces. I don't know how much trading data is on there, but it's actually really good still. And when we're talking about newer, quote unquote languages, something like rust, still quite good. Go, especially good because it's quite structured. There's not many ways to do the same thing. It's very readable, which is also nice from the reviewing perspective. But will this accelerate to a point where innovation actually will not happen with this tool or will it evolve to a point where because it is structure, that's what it's good at. So we can still use it. Yeah, I'm wondering about that as well. You see that now there's a lot of people sort of taking the stands off. I don't want to buy SaaS products anymore. I can vibe code that in a week. Yes, the danger is that it's true. And yes, most of this pollution is that even something simple as a to do list or a shopping list on your phone, you can probably build a better one yourself, which is true because there was always a basically monetary reason to be able to have that from somebody else. Usually, it involves there's ads in those things and you miss a single feature that you really want to have. And people are now at the point of I'll build up myself. And my concern will be how do we actually make this maintainable, secureable into the future. The other cam says, well, we don't care about compilers either anymore. We don't write an assembly anymore, which is right in a higher level language. And this is the next iteration that is in there. I work with a lot of enterprises and I work with a lot of security, sign things as well, both in your code and supply chain. Seeing how this now interoperates in that field, it's really curious to see where this will go because we're still basically mapping AI onto the same things we've been doing for all the years that we've been building in IT. It's still writing code, it's still writing unit tests, it's still pull requests and we deploy to production. So I'm not at the point yet of here's a prompt. Let's run an LM for a couple of hours. Now we have an application and keep that application running indefinitely. That's probably also not something that we're going to do because not necessarily every person in the world will have that inclination. But who knows, maybe that changed because we hope that this is sort of the mass opener that people can everyone can step into coding because now only needs prompt and a sensible mind of I want to move that button over there and need to do this for example. So I hope for both cams that there is something in there but I know clearly where that will go. Yeah, we need there. It's super interesting to see the time that we're in right now and how that evolves and we can steer it a little bit but it also is already completely out of hand. So curious to see where we will end up in in five or ten years. Yeah, same. I do think back of my career and a lot of the biggest learnings that I've had when it comes to personal productivity and execution hands-on on the keyboard have very much been through pair programming and now I've noticed myself maybe not asking to do pair programming sessions or maybe not reaching out to other people as much because I can do that in isolation. But when I've done that, we're still with AI in the mix when someone would show me how they interact with AI in a pair programming sense. Again, I've learned the most but this is kind of counterintuitive because I feel like since you have someone or something that you can ask or even you mentioned give me options you can have a dialogue with. I feel like we are less likely to reach out to people but especially since this is a newer way of working, this might be how we actually learn the most from each other. Is the still pair up and see how someone navigates a genetic tooling in what they need to do. Yeah, and I've been in those situations as well. I tend to go into customers and then we build up local champions that share their work for example and we record our sessions with them nine out of ten times. I see them do certain things where I go dial that back a couple of fair clicks and then try this again with this setup and they go whoa that is where the learning indeed is because we're still monkey see monkey do still on that level as well. You need to see somebody else implemented in a specific way and you tend to only see that when you're sitting next side by side with somebody pair programming indeed. So yeah, I'm still at that point and yeah potentially that happens less indeed. It's interesting. There is a lot of tribalism nowadays as well. This is king, this is shit, new version, this is all of a sudden not the best scrap this thing in terms of tooling. What do you think of that? I've never been much of a fan of that and it is I'm more of an inocentist person. I tend to say I've stayed away from Python for quite a long time because that was just not my language. I grew up on C#, I grew up on Pascal even with Delphi back then, then C# and that's been my go to for at least a decade back then and then I joined a customer that exclusively did everything in Python. But by then I had copa and with that is just explain how an exception works in Python because I don't know how do I do a range check in here and you still use the same moniker is basically so I don't care what language is this as long as I can read it. It's helped if it actually is in English for me but even that doesn't matter that much because you can translate between English and other languages very good with most of the LLM's that are there. So this is really the big democratization of coding as well. So I've never been too much of those kinds of fans of needs to be Windows for the Linux tabs for I don't care anymore. Just what is the value that you add with this as well? So in the end out of the tools that are available that enable a genetic software creation or a genetic ways of working. Right now will it matter which tool I choose or are there more foundational aspects that I need to focus on that will be too like NOSTIC for example. Definitely start with the foundations. We still see a lot of differences between tooling left and right as well. Some tooling features to the code is usually the front runner for the things that are on the bigger platforms that will work for example. So that is where the innovation usually happens and the rest of the editors the main editors that I work with tend to follow later. And then you have newcomers like OpenCode for example they go massively fast because they have a big fanbase and they start working on that. And then still usually the tools that we use for our work especially in enterprise organizations where stuff needs to be a little bit more regulated on which options do you have for example. You tend to come back with the biggest ones and what I like there is that they have to focus off the enterprise customer and play as well. So everything needs to be secured and needs to be policies around certain things. You don't want to run RMRF on your code base. And having those safeguards in place is of course very important as well. So always start with the basics. If you have access to certain tools start using it, start using the free ones as well. Even Copilot has a free option for example so that you can at least get your feet wet and start working with those things. And then mix and match. But also learn that there is different IDEs available. I have people that are struggling saying I've seen your demo on agent mode but that is not available in my editor in NeoVim. Yeah sure, NeoVim is an editor and it's not necessarily where you put a chat window. But you can open the VSCode on the same folder on the side and now you can work in both ways. Or you use the Copilot C ally and bring it the chat interface into that direction as well. So you need to be more tool-agnostic as well and figure out what works for you. Some tools just had a demo this morning about SQL Server Management Studio. As now Copilot built in but only the first few iterations are there. So it is quite some part already behind on what VSCode can do. You can probably get there in the end. But you can mix and match those things. So be agnostic in what you're trying to do and look over the fence. Even the things that they build and throw into the world like in Cloudbot for example, they're doing really cool things. And if you pick up one thing from there that can help you, that's where the value is. That's already value. And that's where we learn. As humans, seeing somebody else doing something and go, "Oh, did I want to do something like that as well?" Do you think the way we're heading that IDE still makes sense? I've always been a fan of the terminal. I always interact with Git through there. It just felt cool. I have my little AI. I always enjoy that. And now with tuning that's available, Copa da Silla, OpenCode, CloudCodeX, I'm there, basically. And also, I don't necessarily need to open my IDE sometimes. I feel like lessen this, actually. It really depends on what you prefer as a way of working. I work on a lot of code bases, where I have interfaces, I have implementations of that, I have calling methods, and I still need to have that visual overlay of what we're working on, and that falls that are interesting. Yes, you can do certain overlays with teemogs and things like that, so you have them open. But if I go into the C-Li, especially Copa da Silla, I tend to have one window open with the C-Li in it. And what it tries to do right now, if you make large code changes, is that it shows the diff in the C-Li itself. And for me, that part doesn't work. So I'm the guy that wants to have the GUI around that, and see where these changes are, visualize what is happening. I still try to make atomic commits as well. So it tends to be quite a low number of line changes that are there, and that helps me doing that in the GUI itself. That said, two weeks ago, I had a blue skin of death on my Windows machine. I usually, in the old days, went into the event viewer, start searching for the time window, and then I just went over to the C-Li, so that I had this bug, and this was around that time, figure out all of the event logs that are there, and help me out figuring out this solution. It went into my event log, figured out where it was happening, went to the crash dump from that file, looked into the services that I had run, and that is where, for me, the value is. All powerful. The stuff that I used to do manually, it can now automate that for me. And then it said, well, we crashed here. There was something with your Bluetooth drive, and I see you have 42 left over Bluetooth devices from your. Shall I clean it up for you? Awesome. Go ahead. Double thumbs up. So it depends on your workflow that you have there, where it really makes sense. So if you've been a 2-E guy forever, start using that, and see how far you can get. Yeah, I love that. All the way to the beginning, we pinned kind of the environmental impact of this. And I want to unpin that, because for me, I used to be an assignment, and one of my correspondence was building a product that actually looks at trends, what if companies promised, because in Europe now you have to have certain ambitions and goals, otherwise it has potential financial impact in terms of loans. And the bigger tech companies were really good, very ambitious, but all of a sudden, then I think it was a couple years ago, they just skyrocketed through their trend line in the negative sense, which means we are now emitting a lot of emissions more so than planned, targeted, or we can potentially solve. How do you see that? And how can we navigate this? Should people be more conscious in terms of usage? Because this is a quite powerful way of working. And what I find scary is that all of the tech companies don't show that impact. Some of them are at least showing the amount of tokens that you're burned through, for example, but there's almost no information of what does that do in cost of resources in a data center? Is that resource running, is that data center even running on renewable energy? Yes or no? Those kinds of things might have impact on the choices that you want to make. And then you get back to the silly example that I had with the CSV. That is just burning basically trees that we still need on this planet. So if your conscience about those things, you want to know that information. That's been my gripe that that is just hidden behind the curtains everywhere right now. We, as humanity, seem to be sticking our head in the sand and just ignoring that problem. On the other hand, we're also thinking and expecting this is IT. IT will fix solutions for this and make this more efficient over time. Probably over five or ten years we were running these kinds of models on our phones. Hopefully. That should be cool. That's not where we are right now. Training those models calls millions and millions of dollars and a couple of months of computer time in a data center just hawking it completely. So that seems to be pretty far away. So I find it a stretch as well. I teach people how to use this. But it's very hard to then go over to that as well, especially again because lots of the tools hide that. Get up hides that and premium requests units. It doesn't matter if the LLM is working for 15 minutes or five minutes. It still costs you one premium request unit and a premium request unit costs you four cents. That's just completely abstract in the problem away. A lot of the foundational model vendors now say you're going to pay us $25 per million tokens, for example. Either input or output and they make some strategy around that. So I actually even started building an extension on top of VSCO to show the token usage of my chats as well. Because I just wanted to have a sense of what the heck am I doing? And I've learned of some of the updates that we made last week to the extension. We've built that now with a whole group out of an innovation data we had. We went deeper and I burned through something like 30 million tokens in the last 30 days. I think, okay, that's an abstract number. It seems like a lot, but what would that do? What does that mean? Yeah. What's that, especially in computational resources? So if you then start adding some estimators on top of that. How many tokens on average per word, per different model that you use? What is the environment impact of a token that you use as well? It usually goes by the millions. Then you translate that down to, okay, this is probably like 70 grams of CO2 that you've burned during that, for example. Okay, still a number and then you probably need to compare that to what happens if I fly from Amsterdam to London, for example, is that the same impact? So that you at least can reason through that for yourself. What is the impact that I'm trying to do? So that you can at least make the constant decision of maybe I should add that back on certain things that I have. Yeah. And even the 70 grams of CO2 is a number, the 600 liters of water that were attached to that. That was the eye opener for me. What the heck am I doing for certain things? So I want to be more conscious and I'm now at the point of figuring out can I actually bring this all the way to the edge and run it on my laptop, for example, or maybe bring a Raspberry Pi with a GPU top-on top of that? And maybe that might be more efficient than running this in a random data center that we currently don't have control over. No. So I expect that enterprises will get to that point where they start requiring it from their alarm providers of, tell me what is the environmental impact that our company is doing because we need to report on it. You should be able to calculate it quite well. It's like compute cost and then what is the impact of that or how much energy is spent in that? And I would love to know per million tokens of usage. How many kilometers driven is that? How many flights is that? How many trees have I burned? Right now it's a little bit off-iscaded. Can I be conscious for those? If I put this into an LLM that runs in a data center in Texas where it was already hot, that might burn through way more environmental calls than choosing to run it in a data center in Sweden that runs on renewable energy. I would love to make that decision to say, I can wait for five minutes longer. And especially with certain setups that you have, GitHub has, for example, coding agent that works completely asynchronously. So I don't care if that runs for five minutes or an hour if I get to make the choice of running on a renewable data center or running on a data center that has down time for it or has compute space available and make it more efficient now. We're not there yet, but I hope that we're getting there slowly over time. Yeah, me too. Thanks so much for that. This was a blast. Thank you so much. Cool. If you're still with us, let me know in the comment section what you thought of this episode and we'll see you in the next one. I'm coding!