Revolutionizing Developer Learning with AI – Matias Madou, Secure Code Warrior

This is Textron tv. Hey guys, thanks for the throw. We're here with Mattias, Madoo, C T O, for Secure Code Warrior, and we're talking about the impact that AI is gonna have on developer education, which is gonna be profound, but we're not all quite sure how Mattias, welcome to the show.

Thank you so much for having me. What do you think is gonna happen here with ai? It seems like in theory we're gonna give developers more access to all kinds of knowledge that will be embedded in their workflows, but, um, how much does a developer need to know going forward?

'cause right now, the cognitive load for being a developer's pretty high. Yeah. Well, first of all, um, let's, let's see, will there be, I want to take it back to will there be more or less developers, first of all, because that's a, that's a big question, right?

Um, and then let's see how we can weave, um, upskilling training and, and education, uh, to those developers. So, will there be more or less developers given that we are gonna give more AI to these, those developers that will help them on, on their, in their day-to-day lives? Um, that's a, that's a big question.

I would say if it would be all good developers, then I think we will need less developers because they will be smart enough to know how to use the AI in the ml, um, to go faster in life, to produce secure code in a faster rate. Unfortunately, you know, um, we, we have a pretty mixed bag of developers, you know, and not always, developers are not always self-aware. You can compare it with, um, uh, drivers, you know, in the US for example, they did a study and they asked people, are you better or worse than the average driver?

And 80% said, yes, I'm better than the average driver. Guess what? That doesn't, that doesn't add up, right?

And it's very similar with software development. Um, if, you know, I did this study myself, and I, I poked around a little bit. And on average, more people say that they're better than, than the average developer, which doesn't add up.

So smart developers, they will go faster with the use of AI and ml, um, bad developers, um, or, or starting developers. I think they will be become dangerous, um, in the workforce. Why?

Because, um, you give them super powerful tools and they will be able to go fast, but they will be able to also introduce a lot of problems fast. And right now, AI and ml, um, you know, um, you see the problems, it's pretty obvious. It, it makes silly mistakes and people are like, well, that's a silly mistake.

Let's fix that. In the future, I think we will see much better machines, much better generative ai, um, where the problems are more subtle. And, you know, if, if you're not able to do critical thinking, if you're not senior enough to know these platforms, um, well, you will skip those problems and you will introduce problems at the massive rate.

So I think that's, that's a little bit the setup here that we're facing. We're facing, um, a, a new landscape for software developments that we need to maneuver into and be able to guide these people in, in writing secure codes. So it almost sounds like maybe have more code than ever moving through our DevOps workflows, but it may not be grade code initially.

And then maybe we'll get better over time as the LLMs get a little smarter. And the AI platforms recognize the difference between good and bad code. What are we supposed to do about all this right now?

Because to your earlier point, there are so many people writing code or creating code that aren't even developers, right? They're end users and they're business people, and they're running all kinds of stuff now going, Hey, look at me. I don't even need to be trained.

I can be a developer. And of course, we all know there's a world of difference between being a developer and being a professional developer. So how do we cope?

I, I think we can learn some lessons from history. Like, like back in the day, um, even be before the year 2000. There's, there's, there's this company in Belgium.

I'm from Belgium, there's this company in Belgium that said, well, by the year 2000, we will no longer need developers because it's all gonna be drag and drop. So everything will be just moving boxes and software development will no longer be a thing. Well, quite the opposite happened, right?

We needed more software developers, we needed more people to maintain those systems, to create those systems. Um, and, and that led to a huge inflow of new developers into the workforce. And I'm pretty confident something similar is happening right now.

Um, by the way, if you look back, there are people that are able to create programs by moving boxes around. Um, however, today, I think with AI and ml, the same thing is happening. More people have access to these powerful tools, um, through AI and ml, you can just express what you would like to see.

And through the AI and the ML and the generative AI code can be created. So there's gonna be more code than ever. So what's key over here is making sure that we manage all of that, and especially, you know, it's not necessarily about the code, it's about the people writing the code.

It's about the people that generate the code. Um, AI ML will not take any responsibility for the code that it is creating. It will be the software developer or the person creating the code.

So in, in, in, in my philosophy, it all starts with the people, the, the, the people that are creating the applications for the business. They need to be vetted people, they need to be skilled people that know what they're doing. And I think if you, if you control that, and if you are getting your head around the people creating the software, I think that that is key to the success of your organization.

You have to make sure that you have skilled people, knowledgeable people that know how to maneuver and how to work with the AI systems to create the software. Are we gonna see something that feels like more like a federated approach where we'll use a co-pilot for one l l m to help write the code, and then there'll be another l l M to check whether or not the code's any good. So, you know, well, I need an l m to keep track of my LLMs.

Yeah, exactly right. And hopefully the LLMs are trained on good data, right? Mm-hmm.

And that's, that's key over here. Like if I'm, I'm, I'm genuinely convinced that, um, if, if you train in, uh, uh, an L L M with, with really good data, it can really help you, it can help you a lot. Um, however, that's a little bit a tricky point.

You know, what, what is good data? Is it just the worldwide web, what everybody wrote on planet Earth? Or is it like a subset of that?

And, and if, if we're able to find the right set of data, I think we can, we can go, we can come a long way. It's not gonna solve the problem, but we can come a long way. And on top of that, if, if you, you know, if you know the people who wrote those pieces of code and, and those skilled people, if, if they are there to help out, and if they then take in what the, the, the L L M is producing, then of course we can, you know, we, we can do something in, in this world, um, to produce secure codes.

Is there something we should be doing in the interim to make sure that that code that's being generated at the moment by a general purpose l l m is secure enough to run? Because we could wind up getting a bad case of, uh, how we say cybersecurity whiplash in about nine months when we discover all these vulnerabilities? Well, I, I think it's already like, um, companies are experimenting, right?

Companies are right. You know, a software developer, um, will always try to find the path of least resistance. So, um, there's a lot of software development, which is good, by the way.

I, I like that. So they will try out new things and they will try out things like copilot, um, but also junior people will try out copilot without understanding the framework or the, you know, especially the framework, um, that, that they're using on a day-to-day basis. And, and that's really, you know, where, where the tricky part comes in.

You know, we have to make sure that also these junior developers are skilled enough and have some critical thinking and know the basic things about the security of that platform. Because before they use that l l m, uh, to help themself, We hear a lot these days about developer productivity, and it was always in my mind, you know, an issue, but it seems to be a hot button these days. What is your sense of what is the issue from a developer's perspective?

'cause we hear all about it from the perspective of IT organizations and platform engineering and all the efforts that they're putting in. But, uh, what is it that the developer finds challenging about improving their productivity these days? It's, It's, it's a lot functional and feature driven, right?

Right. In, um, the organizations, um, today, a lot of the work is, well, can we ship code faster? Um, and quality and se security is quite often an afterthought, but it buys you back in the long run.

It buys you back in the long run because there's a lot of rework that needs to happen 12, 18, 24 months down the road. Quite often, it's not the same people that need to do the rework. So for, for organizations, um, it, it's, first of all, they need to figure out themself or they hear for the long run or the short run.

In the short run, they can just pump out, um, uh, features and functions without caring about the quality or the security. So for software developers, unfortunately, a lot has to come down from, from the managers and what the organizations want to achieve. If they only care about features and functions, they can crank out code very fast.

But there's gonna be a lot of rework later down the track if the organization wants to invest in them. And if they say, well, no, we're here for the long run. We hope that if you do something, you take the time to do it in a correct way, in a qualitative way, well then that organization is gonna invest in their developers.

And yes, they may take a small hit initially, but in the long run, the software developers will be better off because ultimately they will go faster because they have clean, qualitative and secure code in the long run. It's an old saying that says, you know, if you wanna go fast, you need to start out going slow, right? Yeah.

Um, what is your sense of, is the cognitive load on developers too high at the moment? And we hear a lot of surveys will point to most developers are spending about a quarter of their time riding code, and the rest of it is scut work. Um, you know, so is the proverbial cart before the horse here, do we need to kind of just rethink this?

Or is it's just the nature of the way we ride code? Because I'm not always gonna be in that quote unquote code riding zone. And I, I, I think that comes back to my previous answer.

And we're in this particular situation simply because there's quite often a very short term view in organizations where they say, well, you know what? We want to do things fast. We wanna be fast, we wanna be first to market.

Um, we wanna have these features that our competitors do not have, or our customers are asking more features than our developer cap, you know, capability, essentially. So we are in this situation because organizations did not take a long-term view. At the same time, I must say, you know, the, the speed at which technology is changing is, is enormous.

Um, what we produce today, um, a year from now, these frameworks can be outdated and, um, from a security perspective, there can be, you know, new improvements from a security perspective in the next generation frameworks that we're creating. So, um, on, on, on the one hand, um, it it's, it's simply, you know, making sure that developers are capable of doing it at the same time the technology is, is changing so rapidly that it is really hard to keep up. There's, there's essentially a need for, for constant upskilling and making sure we're, we're following the trends, and we're, we're, we're here, we're in the now.

Do we do enough of that in terms of training? Because it seems to me it's one area that continuously gets overlooked. And instead of, rather than focusing on say, how we're gonna make our developers better or streamline the processes, we just keep doing the same thing over and over again, and no one takes a step back to think about it from the, the higher level.

Well, you know, I'm, uh, as, as you're rightfully saying, quite often it's, it's overlooked because, um, you know, upskilled developers, train developers, they are not introducing those problems. So it's really hard to measure that. Like, if everything goes well, everything goes well.

And there's essentially nothing to measure. There is no, no downtown downtime or, or breakage to measure. And, you know, that that's, that's also very hard, you know, for, for an organization to see if you have really good people and things are going really fast, um, then you're like, well, what's the problem?

But it comes to light when it's not happening, when it's not happening, when things are breaking down, that's when you're like, okay, we really need to make sure that we, we upskill our developers so that they're able to, to crank out code faster, secure code faster. Aren't we measuring the right things? I feel like sometimes we obsess about things like Dora metrics and DevOps workflows, and maybe not enough on, you know, what kind of quality code is coming out the other end of the system by how many developers, but do we need to rethink the metrics we're thinking about?

Thinking about measuring is hard. I always found measuring really hard, and, and my philosophy is always we need to measure ultimately business impact. So quite often I see the wrong measurements being put in place.

Um, if the security team is measured on the number of problems that they can find in the code base, that's the wrong metric. That doesn't add up to the ultimate goal of an organization is, you know, to make your customers happy, which means from a, for a development department ship code in a reliable way. So all the metrics need to line up with the business metrics, and they should not, you know, break those business metrics.

Essentially, trying to find as many problems as possible will stop you from shipping code faster. The philosophy should be, well, if you find those problems, how fast can we fix those problems? I'm not saying don't find the problems.

That's not, that's not what I'm saying, but I'm trying to figure out what metrics line up to the ultimate goal of an organization, which is making your customers happy, and it should tickle down from there. So ultimately, what's your best advice to somebody who's in charge of managing these development teams and the DevOps workflows, and what should they be thinking about, you know, how do they kind of make a dent in all of this? So, to me, to make a, to make a dent is really to take a long-term view.

If you take a long-term view with your team, with your organization, um, you know, you may take an initial hit where you say, well, you know what? We are gonna make sure that we have all the processes and the upskilled people in place to really, um, make sure that we're here for the long run. Um, it, it may be hard convince management like, Hey, you know what?

We are gonna set up everything in the correct way, but trust us like 2, 3, 4 years down the road, we will be much better than our competition. So if, if you do that, what you need to do is you need to figure out, um, what the best frameworks are. By the way, I'm a very big advocate of using the right frameworks, using the right frameworks, which already contain security features so people cannot mess up, essentially.

Um, the reality is we can do that in certain areas, but we still rely a lot on, on legacy code where we just, you know, it's, it's just given to us. We have to take it, we have to make it better, but we need to do your upfront work, making sure you pick the right frameworks. If you have to care, if you have to deal with legacy code, make sure you, you deal with the legacy code.

But on top of that, have the workforce that knows what they're doing, have the workforce that is upskilled, that knows those frameworks, that knows the security of those frameworks as well, of the legacy code. So if you do that upfront work, that is my biggest advice. Do your upfront work if you have the right team, if you have the right code base, the right frameworks, and then off you go.

All right, folks, you heard it here. There's a reason why the proverbial tortoise beat the rabbit in the race long term, and it applies to software development just as much. NAIAs, thanks for being on the show.

Thank you so much for having me. All right, back to you guys in the studio.