Software Development will be AI-driven | Henri Hämäläinen & Marko Klemetti

Once again, thank you for being here on my behalf, and thank you for your presence. Perfect. Today, we've decided to explore the direction of AI-generated imagery. The first one to show is generated—just kidding. It's interesting that Bill Gates, when he released his book in 1996, wrote that we overestimate the change that will occur in the next two years but always underestimate the change that will occur in ten.

And today, we are sharing some ideas and visions for the future of software development, combined with explanations from both Henkka and me. I will also attempt to live code some examples; we'll see how far that takes us. Would you be interested in that? Yes, thank you. The idea we have is to walk you through four different steps in a scenario that we envision will occur in approximately ten years. The first scenario is something that is already happening.

You are most likely aware of the process of integrating AI-assisted software into practical use. The second scenario will focus on how to combine existing elements, specifically using AI for legacy systems. The third scenario involves leveraging AI to meet business requirements and then generating software based on those needs. Finally, the fourth scenario, which we will discuss in more detail later, pertains to self-developing software. This raises the question of how to enable customers to develop software themselves, albeit with certain limitations.

But we'll come back to that one. We'll build the storyline. We'll show some Margo's magic along the way. So please, please be actively participating here. Okay, let's start with the first one.

So, AI-assisted software development is where we are currently. I would actually like to include each one of you in this. Please take out your phones and type in either future.hopefully.works, or you can scan the QR code. There will be a yes or no question. The question is: Do we regularly deploy AI-generated code to production?

To production. Not only just using AI, but actually going to production. We're going to wait for a few minutes. There are quite a few people who are already deploying AI-generated code to production, which is a surprise. I hope you are actually doing it and not just stating it.

But it's nice to see so many of you actually using it already—more than half. I would say that Finland works as a prime example of this because, yeah, I think, like, what always happens with technology adoption like this is that if you ask developers, 97% of developers say they are using AI. They have actually utilized AI in their development.

Then, when you ask managers, they say that 42% of companies actually use AI for their software development. However, when we examine the actual value streams of workflows, only 11% genuinely use it for software development. This showcases the complexity of the situation and how things typically unfold. There are individuals who adopt the technology, and it's so appealing that they definitely want to claim they are using it, but the reality is often quite different. If we move to the next slide, you'll see the technology adoption curve, which, as most of you know, includes innovators and early adopters – those are the key players.

Those are actually the easy parts. Then, there are the early majority, late majority, and laggards, just like with every technology. The same happens with AI and generative AI tools. What we have observed with organizations is that it is relatively easy for innovators and early adopters to start using the tools because you simply provide them, and they begin to use them. However, when it comes to the maturity stage, late majority, or even laggards, you need to implement real transformation programs to get them to use AI properly.

So this is a lesson that I hope you will take away from today, even though we will talk a lot about the future. Now, as Marko is an innovator, he will actually show you some magic. I want to emphasize once again that when you implement new ideas in organizations, you should engage with the innovators and early adopters. Based on the results we've seen here today from the first poll, I would say we have many innovators in attendance. However, when I look at coding, I notice that we developers—of whom I consider myself one—often prefer to just focus on coding, although I can also communicate with business people.

We just want to create working software. So, I have a brief introduction to how coding happens. I often show an example of a service where we see the week number. It's just a website that displays the week number, and I have it actually running live at week.hopefullyworks.

The reason I'm using the hopefully.works domain is exactly for this kind of moment when I'm in front of you. I'm not quite sure what's going to happen. Anyway, when we, as developers, start to implement functionalities like this, what we would do today is create a function called `getWeekNumber`, and the date, of course, will be a parameter, which is `new Date()`.

"Function there, let's see. Okay, he proposes some code. And, Marko, just for everyone, this is now the Copilot, right? What you're using?"

Yes, you're seeing GitHub Copilot here, but I have to say that you can use whichever AI-driven development tool you feel comfortable with. You could even go to ChatGPT and ask for code completions; it will provide you with code. The point is that we provide context in development today.

We give context. AI tries to guess what we're trying to do. Then we export the module like this and save it. Oh, yes. We're at 4.7.

Amazing! However, I've also written some tests for this, so you can see the test cases. I've used AI to generate those tests, and all of them are passing.

I can see this week, but this is an interesting year. If we open test cases here, it's an interesting year because the year starts from Sunday. I would like to see if it should return week 47 for this Sunday, November 24th, 2024. Okay, once again, using AI picks the context, it gives me the code here. I'll just press Tab, complete it, and save.

Let's run the test cases. Oh no! The year starts on a Sunday. We would never notice this when we're operating our business days from Monday to Friday, but in reality, the code isn't working. It tried to solve the issue; AI attempted to please me here. However, since Sunday is in the previous week, it will give us a wrong answer.

It says 48, even while we're expecting 47. Now, if I have these tests and then I have my weak number code, I know it's not working. So, what should we do? Let's ask Copilot. Please generate code that fixes the tests. Let's see what happens. I implement the `getWe` function with a number from the module, and then I write some code.

Good. Copy it from there, close it, and add it here. Whoops. I almost said demo. Oh no.

So much for that. So, you lost it? Yeah, we lost the problem, but it doesn't matter. We can generate it again. And as you can see, there's no need to panic on stage. Don't worry about it; no sweat needed here.

I only wrote a part of the sentence, and it gave me the code. Now I'll copy it here for real. I'll add it here and save, and then we'll run the test cases. Okay, not getting there. What we'll do is continue by changing the styles just a bit. So, we'll use steel blue and white as colors.

And let's see if it works. npm start. Okay, there we go. So we now have different colors than in production. And then we'll commit.

Commit the changes: feet, change colors, push. Now, when we go back, what happens is, once again, we only want to code. I apologize for not getting the code ready for you and I won’t make you wait any longer. We’ve made a change to the code repository. As developers, we also want it to be delivered quite automatically. As you can see, it's now in a week that hopefully works with different colors for a nice demo effect, just as it should. Yeah, as it should. We have had the luxury of working with many different organizations overall.

And one thing that we've heard now is from a quite big organization in Germany. They have actually stated that, from their own studies, developers will save around three to four hours a week using tools like Copilot. As Marko showed, it’s not just that you press a button and everything works. But at least for me, that’s awesome—really!

So, it's not that you just press a button and everything works perfectly. But at least for me, that's fantastic. Saving 10% or even more of someone's workweek is impressive. Claims that someone will save 70% or more are simply unrealistic; that's never going to happen.

So, there's always so much more, but like 10%—that is a huge number in any case. Yeah. Once again, if we look at where we are with automation, we're essentially in a place where we're still going to fail miserably, as I did on stage. It doesn't matter because if I took five more minutes, it would be working as expected. I'm actually solving relatively complex problems using AI, and I also have the automation in place to get it live in production immediately. This means that where we are currently with software development, with all of this platform engineering and continuous integration, along with DevOps practices, we can already see that we're in a position to design the code with the help of AI and get it released as quickly as possible.

One very surprising observation we have seen from different organizations is that there are fewer findings related to CI/CD security. This is quite surprising, particularly since there hasn't been any security-related artificial intelligence implemented in this area. However, AI tools tend to produce better code because they can identify basic mistakes and common issues that should not be present. I believe this is an interesting development that will emerge from using AI-assisted tools in software development. This trend is also evident in a Fortune 500 company from Denmark, where we observed that when automated security analysis tools are implemented, those who have been using AI for a while produce more consistent and compliant code, in comparison to those who do not use AI. Both groups have learned to generate effective results from the code they produce. That summarizes the current situation, and now we are moving towards the future.

And I think Annelise started it really well in the morning, mentioning that many organizations still have not done digitalization properly. This is related to that topic, even though we didn't know you would actually talk about it. It was a nice segue to this one. So again, let's ask something, Marklas, faster. How actively do you use AI to modernize your legacy software or your legacy apps in the context of IT digitalization? Can a proper fight?

Interesting. A bit more, then we'll continue, but I think we're already seeing a trend here. So once again, what I showed you with the latest bells and whistles using GitHub or GitLab and deploying code immediately with, I was using Vercel; you could be using Fly.io or similar services like Heroku, as you might know. It's so much easier to get AI up and running there. However, when you go to legacy code, it's nowhere near that easy.

Here is the text with correct capitalization and spelling: And like what we studied, the numbers indicate that about 99.8%, almost 99.9% of the code was actually written before AI was put to use. This represents a huge mass of what we might call legacy code. Of course, not everything written before falls into the legacy category, but there is still a significant amount. There are other statistics as well; teams often spend a lot of time just fixing the legacy code or dealing with the remnants of what has been created. A surprising fact from 2022 is that 71% of Fortune 500 companies still utilize mainframes in some capacity.

And which was kind of funny. I don't think there has been a huge change in the last two years in any case. So, legacy—the old code—still matters a lot. Yeah, and it's something that will essentially slow our pace of change in the future. But as I said, the fast ones will go faster, and the slow ones will be held back by the amount of legacy that exists.

Okay, I get another try. I created a legacy sort. This, as the previous example, is easier to understand because I can show a browser and some cool colors. This is just a sorting mechanism written in C code, and I'm not downplaying C code here in any way.

It still has its place and it's an important tool, but I'll still claim that some organizations have C code that could use some renewal, and there are options for that. So I've created C code that sorts a text file with numbers in different order. If we look at how modern legacy renewal would work, once again, we would use AI. I've been using the same tool now—Copilot—and I'll keep on using it.

Sure! Here's a reformatted version of your request with correct capitalization and spelling: --- Could you rewrite this code using Rust? Rust is one of the technologies that are currently being implemented because it compiles to C and is as efficient as well-written C code. We will use Rust code here. We will create a file called `sort.rs`, save it, and then use the Rust compiler to compile the Rust file `sort.rs`.

Okay, one warning doesn't matter. Let's then try numbers.txt. Cool, maybe I'll print something here to make sure that it really is the Rust code, and I will get to see how my demo skills work. Rust sorting mechanism. Yeah, Rust sorting mechanism.

And, of course, like in this example, this is relatively simple. We have this kind of algorithm in place, and we replace it with Rust. But the point is quite clear: you have your code, AI gets the context, it understands what the code actually does, and it is able to rewrite the same functionality using a completely different language.

The same way as I am, for example, using AI as a translator today, I am using it far more than I am using, for example, Google Translate. There are already tools available; we're not going to go into the details, but this is something we have heard from many of our partners. Their first attempts are already, I think, open for trial. So this will definitely come, and we both believe this is the direction we will take with the legacy systems. But let's move forward. I'll show you something before we proceed.

So I'll just briefly mention some tools that you could use. But I want to show you something. In version control systems, you can already have this kind of automated development in place. Here's an example of how it would work contextually. I have code scanning, which is called QL scanning, and I have found three problems from it.

And how the modern world would work is that you have, here's an example of Copilot autofix. It goes in, sees the problem, reads the code, understands the context, and proposes a fix for me, which I can add as a pull request. So instead of just being a cop-out sitting next to me or a translator, it is already functioning as a real developer on the team, working independently. This will then lead us to— Yes, thanks. I'm sorry for rushing you. No, no, no, no.

The third phase of things is that we believe the language will change. I think this is something you always mention in the story about Jan, right? Yeah, so Jan is one of my colleagues working in Copenhagen, and he has always told me that when I've shown demos, like during week number, he often says, "Isn't AI just a computer trying to tell humans how to communicate with a stupid computer?" When you start to think about it, coding languages have been created for the purpose of allowing us humans to communicate with these "stupid" computers about what they should be doing.

And now we've created AI to tell humans how to instruct computers on what they should be doing. So, it's quite obvious that this is going to change in the future, and relatively quickly, I would assume. Exactly. This is a picture that Marko genuinely hates, but I still have to show it to you. The idea, briefly, is that the way it would work is through iterations with the product. You can think about agile methodologies—there will be business requirements that begin to iterate alongside the product. It's like the human loop continuously interacts with these requirements. When you can confidently say, "Hey, this is good," then it will progress to the next level, which encompasses non-functional requirements or operational aspects, like security. The order doesn't necessarily matter; it can be approached differently. However, in larger enterprises, there's often no point in always building perfect software and then going back to test it.

It’s going to be similar to agile methodologies with very short loops, which can be defined, perhaps, in the form of user stories. There are also team members on our end who prefer test-driven development approaches. While we don’t know exactly what it will look like, we definitely believe that this is the direction we are heading in the future. In one of the previous sessions in Track Two, Peter was discussing how, for instance, in the Qt environment, they have QML, which is their language for defining the user interface in code. There are similar solutions already available; for example, Figma provides tools for designing interfaces, and Adobe uses various tools for defining the user interface. The connection between the user interface, the actual requirements, and then achieving interoperability are clear steps that are currently developing independently but will converge in the near future. On the third try—one success and one failure—there is an interesting service called Critique. It was actually built for a very different purpose; it's designed as a browser extension to help users browse more effectively. However, one of the features they have implemented is the ability to define an API using their tool.

API. API stands for Application Programming Interface, which is a set of protocols and tools that allows different software applications to communicate with each other programmatically to request data or information. Once you have that information, you can utilize it in various ways. Most of you probably already know what an API is. No, we don't have a questionnaire for that, so don't worry.

So I've defined an API. It lists GitHub repositories that have the most stars. While this is a relatively boring API, since you can pull the same data from GitHub, the fact is that it could be anything. This is just a demonstration.

You go there and try out your own versions of it. It's quite funny. You define the input schema. I have limits, then configuration, what's the name, and then the output schema. In the output schema, I already have quite a bit of information I've added, for example, the number of stars and the owner here.

Then, when we try it out, test, and export the code, we need to enter a limit; we want five repositories. Of course, this touches on the performance of modern API-generated code. It must first interpret what I'm requesting and then retrieve and interpret the results. However, the results resemble data. You can already see their top five most-starred GitHub repositories, along with their details, and some code to accompany that.

So, you could have a super simple setup. This is just JavaScript code; don't worry about it. This is the URL I'm using for the critique browser, along with an API key and a regular request for this particular information I'm sending in. Let me see, `node index`. It would run the exact same query. If I would like to attach, for example, a user interface for this particular data, I would be able to do it. So, the key point is that we're already approaching an environment where we can start to define the applications through APIs.

So we are not too far from actually using experiments to generate software. These are what we call auto-development platforms. As Margo already mentioned and demonstrated, they are closer than we think. We're not referring here to no-code platforms, where someone has already created the code, and you then use various components from different places. Instead, this encompasses tools that you can use directly. For example, it could be for APIs, but it could also involve user interfaces or even complete features in some cases.

Okay, then we're jumping into the so-called unknown territory, even a complete feature in some cases. It's something that we see will be part of the future as well. The way it will be presented and the timeframe for when it's going to happen is, of course, as fuzzy as the fog that surrounds us.

But we'll still give it a try. The idea is about transitioning from static software to adaptive solutions. How do you create software that learns to meet your needs, one iteration at a time? There aren’t many good examples of this, but something we discussed a bit was the process of building a house. When you build a house, you typically buy the land and then select a package that you can fully customize for yourself, and then it magically comes together. However, everyone who has ever ordered a house knows that’s not how it actually works. Still, you get the idea.

Other than that, it would actually happen in a minute or something like that. The interesting concept about this, of course, is that house building is cool because you can define the features, and you kind of do when you engage in that kind of work. Of course, there are people involved, but the method of communication is the same. What’s funny about software is that, whether it’s AI-driven or not, in real life, you cannot simply say, "Unfortunately, I would need to move this house two meters to the east." But in software, you can. You just say, "I want to move this."

It may sound simplistic when applied to the physical world, but in the realm of software, changing the structure depends on the architecture of the software itself. In the future, if we truly reach a point where code is generated from requirements, making a change to a requirement would automatically adjust the software accordingly. Let me explain this further with an example of how a CRM system might work. To begin, we could visualize our sales and marketing processes on a board, possibly with the help of AI. For instance, AI could guide us by asking questions to clarify our target state, which would serve as input for the CRM system solution. Based on these visualizations, AI could then create the first version of the software. Once users start interacting with it, the implications of these changes will become apparent.

There's something that doesn't work. There's something we need to add. There's something we need to adjust. Then, we will have usage data along with domain knowledge—understanding how things work in this industry for this company.

And it will start building new features on top of the existing ones to fulfill user needs. This cycle will continue until, eventually, you may have the perfect CRM—if that ever exists. You can understand that this is the way it will change how you work with even large software. Of course, there are difficulties, and everyone can speculate about them. The question arises: how do you maintain something like that?

Whose responsibility is it to ask? The difficulties are something everyone can speculate about. It's a matter of how to maintain things like that. Whose responsibility is it to request unnecessary features from the software? Despite this, this is definitely the direction we will be heading in the future.

And before our last slide, I would like you to respond to one more question. This question is intentionally controversial, so feel free to answer it in the way you believe is right. When we consider how AI will change the way we work, there are indeed two different types of innovation: efficiency and novelty.

And when we talk about innovation today and in the near future, AI brings us efficiency innovations. It provides us with ways to improve processes and make things faster, as I have already shown you.

It brings us the ways we can direct human work, human brains, and the human way of working towards the novelty side of innovation, where we can develop new solutions. With all the solutions at our disposal and the insights we've gained from Henka on how the future might take shape, we believe that the evolving role of AI is driven by efficiency while also capturing segments of innovation. This, of course, relies on iteration and continuous data input. We are still receiving answers, and while there may be some spamming, it’s alright. Fortunately, we have had enough people respond with "no," so we're currently around a 50-50 split, which is once again very interesting. Thank you for the valuable feedback.

Let's go to the last one. We thought about it a lot and had some good debates on this. What are the things we should concentrate on in the future?

I think the first data point has come up in many sessions today, so I definitely believe we are onto something there. I just want to highlight something about the data; it's also related to the connected data. It might not encompass everything.

I think that was also brought up in some of the sessions earlier, but it's not only about your data; it's also about how your data connects to other elements, what your APIs are for the data, what you expose to others for use, and what you could take from others to utilize for your purposes. It's the whole aspect of data to consider. For example, Atlassian talks about the "teamwork graph," which represents their perspective on their own domain. The concept is interesting, especially what they mentioned at Team24 in Barcelona regarding their data. They discussed how they gather data and refer to it as a teamwork graph, meaning that all of the different systems they have produce information with a consistent structure, no matter where you place it. This consistency ensures that when you use it for AI consumption or any other analysis, you already know that it's structured the same way.

You don't have to start filtering it from different sources. I believe organizations such as yours will also have to move in the same direction. Whatever you collect, you also need to consider the semantic aspect of it. How do you present the data in such a way that, even if it currently doesn't seem connected to us humans, it might actually have a connection? Yeah.

So, jumping to the next topic, which is human connection. This is something we have discussed extensively, but I believe the previous question was already about this issue. The points at which humans are involved in the value streams will start to decrease. There will be much more automation in many areas. However, this simultaneously makes human connection the key area where you can compete.

So that's something that you should understand: what the important human connection points are in your value stream. And I mean the full value stream—not just a release-type value stream, but the entire value stream from idea to product usage. Where are your human connections in that value stream? Those will be the elements you should cultivate to create your competitive edge in the long run. If we look at the Magnificent Seven stocks currently in the market, they are driving growth in the stock markets.

There are companies such as Meta and Alphabet, which are both essentially built on human interaction, human connection, and the collection of that kind of information. In the future, these aspects will become even more important for winning in the market. Lastly, the third and final point is about supply chains, which are not that easy to manage. We didn't discuss robots much today.

I think that's one thing that will take robots even longer to take over: the entire supply chain, especially when we consider resources, starting from energy and the actual materials used. If you think about the whole supply chain, it contributes to the competitiveness of your ecosystem. However, it's not solely about physical resources. A good example is TikTok; it basically doesn't have anything particularly special.

It just has the creators there. Just right. That's the competition. How on earth did they get all the creators to be on their platform? So what is your supply chain?

What is your ecosystem that creates your supply chain for consumers? I know it's not easy to consider whether, for example, TikTok dancers are part of your supply chain. But honestly, if you think about the consumers who watch them, then they are indeed part of the supply chain. This concept applies to everything in the physical world as well.

So we had Sensible 4, for example, presenting the story of their journey. To be honest, there is a huge supply chain in the background as well, even as we explore some sort of AI-driven approach based on all the descriptions we have. There will be data, and there's the human connection. So these three aspects are key for the future. We also had a very intense debate over the patents, but we've decided to focus on the supply chain aspect.

So, what will be the role of patents in the future if you can just create anything? We can reveal a bit about that. Considering the developments happening around the world, what will be the value of patents in the future? How much will they actually be appreciated? How can AI provide a way to work within existing patents? You can actually give it as a requirement: we want to achieve this, but we want to do it in a different way without infringing on any patents.

Here’s a reformatted version of your text with correct capitalization and spelling: "These are the reasons why we didn't have patterns as a separate thing. We can continue the discussion on this matter after the session in the hallway. So, going back to the beginning, we'll see this in two years. With those words, thank you so much for being here. Thank you. Thank you."