Viktor
00:00:00.000
the ideal combination, the one that will be doing real circles is a person with real experience and also a person who. Accepted who, who is willing to accept change and has been doing that always. And now that change is ai, right? Because you cannot replace experience.
Darin
00:01:23.364
Back in October of 2025, I read a report from JetBrains that said 85% of developers are using AI regularly and beyond. That one in five every week are saving a full day Viktor. Does that even seem possible?
Viktor
00:01:46.170
October. Yes. I mean, yes, it's definitely possible. I was about to say it must be a much higher number, but then I forget that how, how many messed up companies there are.
Darin
00:01:57.647
And it's interesting, right? Because if, let's So the first part is everybody's using AI probably in some way, shape or form, whether we like it or not. There's probably a little bit of AI happening.
Viktor
00:02:06.128
Oh yeah. You know, whomever is, is claiming that they're not using ai. Well, you never use Google Maps.
Darin
00:02:13.920
Right there. There's all of these things that just happened, but the second part of what I said, one in five developers, so 20% of developers are saving a full day per week. That seems really interesting to me.
Viktor
00:02:27.434
if you ask me how much I'm using, I, I'm all the time in cloud code. Now. I honestly cannot say how much I'm saving. How, how can you know that?
Darin
00:02:36.679
I don't know that you can know that, but where we're really headed is as developers, as computer programmers. We think that we would code probably what, 95% of the time when we're at the desk.
Viktor
00:02:51.739
Let's say that the numbers, yes. Assuming that you are never writing specs, you're never reviewing anybody's code, you're never designing anything, you're never doing whatever else we are doing in this industry. Yes. Then you're 95% coding. let put it this way, is, is that somebody else is doing right and they're not, they're not counted into that average, right?
Darin
00:03:17.598
Exactly. So. I would have to say when I was coding on a day-to-day basis, I was doing good maybe to work an hour and a half, two hours a day, and the rest of the time I was in some form of a meeting, whether that was like an HR ish type meeting or a just a team meeting or a specs meeting or something.
Viktor
00:03:38.097
And even in your example, you're still, you are not thinking about the problem. You're coding, right? You're not designing solution in your example, right? And, uh, you're not, uh, asking for help. You are right. There are so many things we do. Now here, here's a problem. I feel that. In larger, more traditional, not to say legacy, environments or enterprises, right? There is a very strict separation of concerns, and when I say separation of concerns, I don't mean code, you know, good practices. I mean, separation of concern is this person, this role does this and this role does that, At least that's my experience in in bigger enterprise. And then there is somebody's job. Some somebody's job is to define what should be done, and somebody's job is to just design what should be done and somebody else's job is to review what has been done and somebody's job is to just do it. And significant majority of technical people in the company. Are in that last group, For one architect. There are like 10, 20, 50 hundreds I type code, type of roles. For every reviewer there is again, five, 1,000 I type code, type of, uh, roles, and so on and so forth.
Darin
00:05:10.592
Let's think about when you were coding on a day-to-day basis, which you're like me, you don't do it on a day-to-day basis anymore
Darin
00:05:23.563
but let's, let's pre AI the thing for just a minute. in the times when you were writing code on a daily basis, was the hardest part of your job actually writing the code.
Viktor
00:05:35.312
That's the easiest part. I, I don't understand the fuss about it. It's so easy. It's, it's like asking, okay, ask me, ask me the same question about writing books. I wrote a few. Do you think that typing words was the hardest part of writing a book?
Viktor
00:05:55.966
Exactly. Everything else is harder. I might have spent considerable percentage of my time typing the book, but that was the easiest part. That's just mechanic. Once you know what you want to write, once you understand the subject in detail, once you figured out the chapters, the flow, the so and so forth, right? It is technical. Those are technical books. Books. Once you wrote all the, all the, all the scripts and validated the day run in different operating systems and so on and so forth, right? Once all that is done, man, The part of writing was like being on holiday. that was the part where I could just disconnect my brain and just do it, you know, mechanically almost,
Viktor
00:06:41.768
because I've done all, all the work. Yes. Now there is a, there is a overlap, just to be clear. I'm not saying it's only you do this or you do that. There is an overlap, By literally typing, it's not a type type for four hours and then think of for four hours. There is a mix, but the actual typing, no matter what does, what is the frequency or duration of typing that, that was the easiest part. And I claim that with code is not really that different, it's just a different language.
Darin
00:07:14.158
I wanna flip it around just to see, because there's probably some people saying no. Coding is the hardest part of everything that I do.
Darin
00:07:28.738
I could finish that out, but I'm not going to the, the strategy part of this is if I'm not spending my time in strategy and I'm able to spend all my time coding, it's like, look, the architects can sit around and whiteboard invisio all day long. Okay? Draw io, whatever it is nowadays.
Darin
00:07:49.708
I am the one that's gonna be stuck writing the code, and I'm the one that actually has to deliver it while the architects are off going off on their next trip to Hawaii for another yet offsite.
Darin
00:08:05.042
one way to think about it, but. It's like without me being a ghost writer, nothing's gonna happen. That's the hard part.
Viktor
00:08:18.470
I think it is because that, that creates a disconnect between the designer of something and the end result of that design. Oh, I designed like this. I dunno whether it's doable or not. Kind of what? That's my design, right? Oh, I dunno whether it was done as per my design, but my design is there. you are now, I feel that you are now pinpointing to a real problem that is getting solved.
Viktor
00:08:56.159
Because if I'm designing, if I'm thinking, if I am figuring out what and how, and when, and all the, all those questions, then I jump to ai, who is going to do it faster than a person? But I'm still behind the driver, uh, driver's wheel and I still check on it and correct it and do the things that you should be doing as an architecture, whatever the role is, but you haven't been doing because nobody likes you breath behind their back. Right? imagine this world, forget for for a second, ai. Let's say that we have a traditional developer. I type code. And you have a software architect. I, I figure out what to do and how to do it, and so on and so forth. Right? Now, imagine that those two people would pair program. Wouldn't that be awesome? Now, you will say no if you think about it, because it's not awesome, because for one. Architect, there is a number of code writers, Typically 10 23, many more. There is one too many relationship, right? So you cannot do that. You cannot, you cannot do what I'm suggesting. You cannot pair program, right? Because then we would have the same number of architects as developers because the writing code is act might be actually slightly slower. But if you speed the up, if you have that I type code person, that actually can type much faster, much, much, much faster, much faster, then you can go back to the idea of per programming and say, this is actually good thing, because I can think of the next thing that we should do. While you're doing it, and by the time you finish that something in short iterations, we are going to talk about it and validate that that that's correct. Correct it if it's not, and then I'm going to tell you what to do next because I use that time while you were doing it. Think of what to do next. And then you do the next thing and we repeat the process over and over again. The only bottleneck in that. The idea process is that people typing code are too slow.
Darin
00:11:26.670
I'm not gonna disagree with that either. I wanna poke at it a little bit more. We've heard about all these abstraction layers always being helpful to us and saving us time.
Darin
00:11:37.380
Okay. Well again, four gls. Were supposed to make our life easier. Does anybody remember what a four GL is anymore? a few of us gray hairs do. How is AI any different than any of this? I mean, what does it matter? So what if it speeds me up if I'm gonna be spending my next six months trying to clean it up?
Viktor
00:11:55.465
Why would you clean it up? again, let, let's go back to non-AI. Why do we clean up? Code. Now there there can be technical reasons, like because of performance, right? But let's exclude those technical reasons for a second. The main reason why we clean up code is so that we have easier time navigating through that code, through that code, and understanding that code and so on and so forth, right? if you have this give or take, the same function repeated in 20 different places, we are going to have trouble updating it 20 different places. When we wanna change something, right? And so on and so forth. But what if today that's not a problem? Then should we still clean it up? Excluding technical reasons, like performance, the size, and so on and so forth.
Viktor
00:12:47.013
Not only that, it doesn't matter, but. There are two rules that there is very often a thoughts there is don't repeat yourself but there is also a rule, I'm not sure what the exact phrasing is, but that that's don't make it more complex than it should be Very often, in order for us not to repeat ourselves, we need to make things very complex. Imagine you start with this function does something X, right? And then use that function in three different places. But then there are some variations between those three different places. And then you will update that function to have some conditional loops and things like that, right, to include those additional variations into what it does. Then you extend it to a hundred different places where you call that function and that function becomes hell of a complex. and that function most likely has 80% of the code that none of the callers need because it needs to match everybody's needs, If you take through any truth party library, you will see that pattern, right? It does things for everybody and nobody needs much of it. So those two things are dots and we are willing to pay that price because still, keeping up to date hundred different functions that are doing more or less. The same thing is more complicated than adding complexity into one central function, but there is a trade off, right? Increased complexity for. Potentially, maybe, who knows, easier maintenance. But that's changing as well because I'm not sure whether it's, whether we want shared functions with ai, with code written by ai. Sorry. makes quite a few things easier because if I don't have shared functions, then I understand code better. Imagine if you have 200 lines of code that is completely self-contained instead of 20 lines of code in five libraries. What is easier for you to understand?
Darin
00:14:44.026
Well, in theory. Depends on how it was written. So if the developers are, saying, okay, I've got, I've gotta deal with this AI stuff. I don't want to, but my boss is making me do it. What are the skills they've gotta start learning if they haven't started learning them yet, and let's say these are mid and senior level people, let's leave the, we'll visit the juniors after a while. What are those sort of hard skills they've gotta learn? What are some of the soft skills they gotta learn? That's gonna be the hard thing I think.
Viktor
00:15:13.133
I would first start with. The same advice I would give to that person adopting anything else. And that advice is keep in mind that this is not the same, like switching from VMs to Kubernetes or VMs to containers from containers to Kubernetes and so on and so forth. Well, you need to reset part of your brain and and say, okay, I need to understand how this works. And what are the benefits and how I should do my work differently because if I enter into that area from I'm going to do the same, but somehow different, then it's not going to be very good. With any change, no matter what, you switch from Java to rust. And if you don't accept that, you will have to think about it differently. Some things are going to be the same, some logic, but many things are going to be different if you don't accept that. If you try to write Java code in rust, you're not going to get far so that's one thing. Another thing, and I feel that this is. A problem with software engineers, many software engineers in general, that's communication skills, I, I'm not sure about younger generation, but at least our generation, many of us became software engineers because we are a social, we don't like contact with other people. Just kind of gimme, tell me what to do and I'm going to do it and I'm going to get, get back to you after a week without talking to you. This is different. This is like being this pair programming essentially, right? You cannot effectively do pair programming if both are not talking to each other Well, that applies both to ai, not only to us. Just to be clear, there are some models. That are better and some models that are versed at explaining really what's going on and why it is doing what it's doing, and so on and so forth. Right? And then you need to ask it a bunch of questions. Yeah. But why, why, why did you try to edit this file? Right? but the same thing goes for you. You need to build some people skills. I know it's not a person, but think of it like people skills. Think of it this way, can you explain what you're about to do to CEO of your company? Right. Most of the time people, people think that they can, but they cannot ' cause that's why their ideas never get buyout. Buyin, sorry.
Darin
00:17:38.235
so I'm thinking about what you just said there about the CEO and thinking about interacting with ai. you have to remember somebody's not technical and technically AI is not technical, right.
Viktor
00:17:51.066
It isn't a it. So again, it depends because now AI is very technical. AI knows more about any particular technical subjects than than you do, right? Because simply it has all the internet is disposal. But when you're working with the code, it's not only about is this code correct? I would even say this is the least problematic part, right? It is about what do we want to do? What are we trying to accomplish? How does this, this affect something? how is this related with something and so on and so forth. Right? Does this still sometimes technical, sometimes not technical conversations, but not that deeply technical as software engineers like to talk. You don't really need to go into endless loop of something. You need to explain. That's why I feel it's, it's closer to the communication to CEO. And we imagining that your CEO is a very technical person, right. It's just that that person who stopped coding or doesn't code much anymore, but he's now CEO of a technical company. Right? So how would you explain it to, to him? you you can use technical jargon, but you're not going to to go, uh, through every line of fluoresce code with, that person.
Darin
00:19:12.848
What you're bringing out is being able to translate between the business requirements and the technical requirements, and if you're, if you as a mid, or especially as a senior, if you're not able to do that, I don't know how you got to that position other than just, but time and seats,
Viktor
00:19:27.957
And the important addition to what you said and vice versa. Also technical to business.
Darin
00:19:33.333
correct. That's a two way street. I wanna think about the, one of the hard skills that you, you sort of talked around. What do you think about code reviews? I mean, we think about it. We, we write our code and off we go. But now if AI is writing the code, going back to your programming analogy, not even an analogy, the actual working style, how big of a deal is code review now?
Viktor
00:19:55.971
I feel it. Depends on who wrote that pr, Like there are people you trust and people you don't. so if I, let's say, let's say scenario, this is scenario possible. I work alone. Easiest scenario, right? Uh, and I would like that to be reviewed, right? ai perfect for that, right? Because I already embedded everything I believe is important. To that pr I wrote the code of that pr. Right? So I want AI to find correlations with other stuff that I missed and things like that. Right? Issues, whatever it is. Now, there is a different scenario and that's person you don't trust or maybe person that doesn't understand the code base well. Right? And that in that case is I had. Couple of cases where kind of, okay, according to Code Rabbit, this is okay. There are some things to be fixed, but in general this is okay, but then I look at it in this is completely wrong. The direction is completely wrong, And AI does not necessarily know that I don't like the direction in the first place. You, you, you created a pr kind of like, Hey, we should arrive to Paris. And, uh, according Codera takes a look and says, yeah, you are in Paris. Now the missing thing is that, man, we are going to London. Uh, doesn't matter how, how well you arrived to Paris.
Darin
00:21:26.776
Right, because Paris was just a way point, or shouldn't have been a way point on your
Viktor
00:21:30.637
Well, yeah, maybe it's the wrong direction altogether. I dunno. Right? There are many, many things that can go wrong, so, but still in those cases, right? What? AI helps me a lot. I'm using Code Rabbit to be precise is that I still don't have to validate technically whether that's correct. I might look at specific cases that I'm interested, but normally in the past I would go through every single line. And there can be many in a pr, right? Many. So I might review code itself specifically for specific parts, that I feel should get extra attention. That's fine. But more importantly or more focused on is this really how and why, and, and all those things. I'm asking the same questions I would have to ask myself. Before I would, I would start working on it if I would work on it instead of review somebody else's work. It was the same skills in a way.
Darin
00:22:34.032
So again, mids and seniors should already have these skill sets. Should we'll leave those there for a second.
Darin
00:22:44.912
oh, that's true. That's another conversation that we won't get into. What are we gonna do about juniors? I mean, we have people coming. Either straight out of college with a CS degree or you had somebody that completely skipped college, went down a bootcamp route, just a standard bootcamp. Forget, again. Forget AI for a moment, like people are coming in right now that are ready to come in, but you know that those skill sets haven't been built in. What good is a junior nowadays?
Viktor
00:23:19.983
I mean, there, there is always something somebody can contribute, right? You know, we had those same questions before, let's say an open source area, right? Oh, I, I, I, I'm, I'm afraid to contribute, I dunno this, I dunno that, but can you do docs? Right. Can you check whether it works? Can you validate it, test it? You know, there are so many things one can do, my bigger fear is of how much of juniors will spend their time on doing stuff as opposed to using this opportunity, which didn't exist before. For rapid learning, you can upskill yourself today faster than ever in the history of software. Except maybe in early days when everything was so simple that all you had to do, you learn to choose between basic and assembly, so it depends. And then it's very hard. Not to try to be what is perceived as productive during all your work time. ' cause everybody wants to be productive, honest, Hey, if I work eight hours, five days this week on something and show the outcome of that something, I will be better seen than if I do it for three days and use the other two days to understand what the heck is going on.
Darin
00:24:47.711
So you're saying sprints now move from two weeks to one day, three days. That's a different conversation, but.
Viktor
00:24:57.782
a different conversation, but I think that we need to revisit the subject of, rapid development. Right. sprints to me never felt good to begin with. I was never a sprint person. I was. Advocating back in the day for something more like Hanban, You have a feature, you work on it, it's done, it's in production, and then you work on the next one and somebody else does the same. and I feel that that model is even more valuable now with, with ai.
Darin
00:25:32.076
Let's go back to juniors just for a second. If you were mentoring a junior today, and that's effectively what a lot of people listening to this podcast are. They're juniors trying to break in. What are a couple of very specific skills that they should be picking up today?
Viktor
00:25:44.909
Man, and if anything, just try to understand how things work. And try to build stuff. You need to combine two things. You cannot be spending too much time building because then you don't spend enough time understanding and you cannot spend too much time understanding because without building, you don't get through understanding. This was probably mine. I cannot use the word right. Something in that direction. Right. simply, I don't believe that any theoretical knowledge can replace practical knowledge, but doing only practical work, without ever stopping and trying to understand, why am I doing this? How am I doing? This is not worth either, and you cannot do it faster than ever. You can learn faster than ever, and you can do things faster than ever.
Darin
00:26:35.108
so what I'm hearing is that they listen to this podcast at two x or three x while they're learning to type at speed. Then there are running circles around all of us.
Viktor
00:26:44.734
here's my recommendation For juniors, find a company that rejects ai. And then spend some time learning how all this stuff works. It's, it's not immediate. You, you, you need a couple of months of practice, but once you figure it out, don't tell anybody that you're using ai and then you will have your time for learning.
Viktor
00:27:08.698
Yes, a hundred percent always. The fact that shadow AI exists, or shadow infrastructure or shadow, whatever we had whenever we had it, is a sign of a problem not, but the problem itself is not the shadow. You just surfacing some other issues.
Darin
00:27:30.156
we'll talk more about that in a couple of episodes. Shadow ai, it's a thing. So let's make a couple of predictions. Uh, I don't know where to start. What do what in five years, where do you think you're gonna be or where we as an industry will be?
Darin
00:27:48.434
Here, here. Lemme throw one out there and see if you like it or not. How about this? Uh, in five years, the best developers we have are gonna be people that started after this big AI revolution. In other words, basically starting right about now, people coming into the market in early 2026, mid late 2026, are gonna be running circles around everybody else that's been in the industry for 20 or 30 years.
Viktor
00:28:13.350
Around some. Yes. the ideal combination, the one that will be doing real circles is a person with real experience and also a person who. Accepted who, who is willing to accept change and has been doing that always. And now that change is ai, right? Because you cannot replace experience. And then we, then the race for the second place is between, hey, I'm experienced, but, uh, this, this is not for me. And hey, this is a cool thing. it's so amazing, but I have no experience. Then between those two, I'm not sure.
Darin
00:28:50.605
How about this one? Here's another idea. Senior developers are gonna become more like senior editors
Viktor
00:28:57.583
It'll be like working in a family business where all the employees are my children. Right. I employ only my children, kind of like no strangers in this business. Small business, no strangers. If I need more workers, well, I make another child and teach it the craft, And then after a while of teaching the child a craft, it joins my enterprise, right? This very family business, right? I feel it really like that because we will have agents that some people will be using generic or agents created by company, but some of us will be using agents. We created ourselves because they're tailor made for the way we work for our understanding of the world, efficiencies on and so forth. It's like, you know. Before when you have, I dunno, you use Vim, but then you customize it heavily because, you know, and, and that customization works for you and you are even faster than before. Probably doesn't work for anybody else, but for you. Amazing, right? I, I feel it'll be that it's kind of like, Hey, me, John, something, something. I have my own team, kind of that team comes with me, goes with me. We will be competing on human productivity based partly on how good is the team that is working for us and that team being our agents.
Darin
00:30:34.815
Let's go in a completely different direction from our prediction. There will be software out there. That will have a label on it called AI Free and that is marketed as a feature, sort of like how we have organic and free range today in food. Because you and I both know people that are so anti ai, of course they probably wouldn't market that way either 'cause they don't like marketing. But just to follow out the story, what's the chances of that happening? I mean, are we gonna see, hey, there's no AI generated code or any images or any. Documentation that was generated by ai. This was all human collated. It took us 25 years, but, uh, you know, now it's ready.
Darin
00:31:21.715
Oh wait, I forgot. I forgot one more thing. you think back to those times where the Broadcom prices increased for VMware, we charge a lot more than that.
Viktor
00:31:30.181
There we go. There. Yeah. Yeah, so, right. I don't think that people look at software, especially services in that way, right? You don't care. Kind of do, do you ask yourself in the morning and say, oh, I, I would like to use EC2 from AWS, uh, I would like to see the names of the people who did it and how much AI is involved in it, and so on and so forth. You judge it by the quality of what? The quality of what it does. there is a premium market for goods that are, that receive special attention, but I don't think that software is that for fruit? Yeah, organic fruit, of course. Kind of like, I'm going to pay double, triple, but I'm willing to pay that price. Better taste or whatever. There is no, no sign that we ever had that notion for software, right? I could imagine easily that there will be something like what you mentioned for art, for example, right? Oh, was AI involved in this art piece or no? And if it's not, then okay, now you rolls Royce for equivalent. Right? Well done. Here's a hundred K. Yes. I, I don't think for our craft,
Darin
00:32:41.817
Probably not. So let's try to figure out talking about the, the early entries, the juniors, the mids, and the seniors. I think if you're early career, you can't skip the fundamentals. If you don't know basic Linux commands, you don't know basic windows commands. You need to know these things. You need to understand what a shell is. ' Viktor: cause you will not understand. So again, that's, you are the supervisor of a team, right? That team can be one or many agents in parallel. We'll see. Do you think that you can supervise. People forget about ai. Can you supervise people without actually having knowledge of that craft of whatever they're doing? Oh, I dunno what is a car? But I just got the job to supervise a car plant. Right? No, So, or oh, I supervise, uh, surgeons in kind of like, I'm, I'm head of s surgery, surgery department, and I, I dunno, I, I, I play soccer. Kind of like, no, you need to understand what's going on, if you want people to work well for you. And the same thing goes for agents. At least today, we'll see. Yeah. One more thing I think for juniors too is. Build things completely from end to end. I mean, think back in our early days, Viktor end to end was, for us, was PHP MySQL running on a Nalytics machine, right? That was everything that was full end-to-end full Stack. For some people it still is.
Viktor
00:34:14.812
that, that's when I grew old man. In my case, it was Pascal on, on a machine. I dunno how it's called anymore.
Darin
00:34:20.956
Right, but what I'm saying is, as a junior, as an early entry, don't focus on just front end. Don't focus on just back end. You need to understand the whole thing. If you're wanting to stay in this industry, doesn't mean it has to be completely correct, but you've gotta understand it. You gotta at least understand the moving pieces. To me that, again, this is a fundamental, is knowing what the building blocks are. Going back to your car, I know I have to have wheels, I have to have seats, I have to have some sort of transmission and an engine, right? I, I need to understand it at least.
Viktor
00:34:47.827
You are moving, your job is moving to a higher level than it was before. That's the point. Right now, you're, you're not the one assembling Ince, you are Steve Jobs, right? Kind of like you need to think about all the aspects of that thing, not necessarily of everything that the company does, but of the product you're trying to push for, right? So now all of a sudden you need to understand content. You need to understand backing, you need to understand operations because you are managing different. All those aspects, right?
Viktor
00:35:21.982
Yes. And David, be specialist people as they always are, right? Kind of. They would be, oh, I, I do only front end kind of, but I'm a designer now. Right. I'm, I'm not a software engineer anymore. I'm, I'm a designer. I design front end and, uh, I give you, and I will probably use AI as well and I will give you, I dunno, whatever designers do, kind of, I'll give you a Photoshop I image from workshop. I, I'll give you, I will give you a working website, uh, but for you to see what my design is and then, then I'm not going to do it. Then you will have to do it and again, you will be doing backend, frontend and all this stuff.
Darin
00:36:05.334
If you're mid-career, I think you've gotta double down on architecture and systems thinking
Viktor
00:36:10.050
Yes, we are all becoming architects slash managers slash CTOs us without the pay of those people.
Darin
00:36:19.415
Without the pay. Yes, and, and you're having to pay. What's funny of this is you're paying all of your employees, but you're not getting paid to help subsidize your employees.
Viktor
00:36:28.666
Yeah. Many companies are now giving you some extra bucks, like 50 bucks a month for internet connection. Now it's gonna be kind of like, you know, uh, it'll increase to a hundred.
Darin
00:36:39.500
So if you're later or a senior, unfortunately, you're gonna have to get used to having this, who's in charge of this AI generated code
Viktor
00:36:51.376
And just quickly, it's not only code. Uh, right now code is the most common use case, but that can be many different things. Remediation, operations, and so on and so forth. Whatever you're doing, you'll be using AI or you should be already.
Darin
00:37:05.577
so it's not so much going back to our initial premise of, you know, if code isn't the hardest thing that we're doing, it's all these other things,
Viktor
00:37:15.033
Yes. And if you think that that's wrong, you are missing a point. That has nothing to do with ai. Nothing to do with ai. I would make that claim 10 years ago.
Darin
00:37:31.247
It's the same question that we've had all along. If all we've done is become people that pull tickets and implement the ticket and put the ticket back in the queue after it's done, uh, that job is, could still be there for some people. I'm not saying it's not. But do you wanna stay in a company that that is going to be your career path?
Darin
00:37:57.073
Okay. We have to talk about mainframe a little bit because they're probably being paid a whole lot more than everybody else right now, at least at that that aren't non AI researchers.
Viktor
00:38:11.074
probably not yet. But I imagine that AI is going to accomplish something that nobody else managed to accomplish before. And that's for us to move away from mainframe. ' cause that's. Relatively trivial for AI to actually translate code from one language to another. When I say trivial, not kind of five minutes, we are done, mainframe gone, but that's, that's one of the relatively trivial tasks, easier tasks than building something new.
Darin
00:38:41.321
What kind of developers are gonna drive thrive throughout all of this drive and thrive, I guess.
Viktor
00:38:47.288
The same type of people that were driving and thriving before, and that's either managers or software engineers who are always curious and don't stick with what they already know. Only.
Darin
00:39:02.719
So for the listeners, what's the most valuable thing that you do at work that isn't code? Head over to the Slack workspace. Look for episode number 3, 3, 4 in the podcast channel and leave your comments there. We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us, our contact information and a link to the Slack workspace or at DevOps paradox.com/contact if you subscribe through Apple Podcast. Be sure to leave us a review there that helps other people discover this podcast. Go Sign up right now at DevOps paradox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.