Shownotes

The Future of Software: Insights from Experience and AI Innovation

Discover how seasoned experts (aka old people in computer years) predict the evolution of software development over the next decade, focusing on AI's transformative role, hardware implications, and the potential for machine-only software.

In this episode:

• Reflection on recent episodes discussing AI and code generation and what they imply for the future

• The challenge of maintaining software in an increasingly AI-driven landscape

• The shift from human to AI-centric code creation and the implications for trust and reliability

• How hardware limitations and technological advances will shape software design and optimization

• The concept of "wet code" — intentionally un-Dry, performance-optimized, AI-generated code that forgoes human maintainability

• The potential for machine code to replace high-level programming languages entirely

• The evolution from microservices as team management tools to pure operational resilience components

• The revolutionary impact of AI training on code creation, emphasizing self-learning models akin to AlphaGo

• The concept of unikernels and the radical idea of single-kernel systems replacing traditional OS structures

• The importance of shifting from maintainable code by humans to trust-based, AI-driven code systems

This episode explores paradigm-shifting ideas about the core foundation of software and hardware in a future where AI rewrites the very fabric of code creation and system design.

Transcript

**Anne (00:00)**

So, hello and welcome to Asynchronous and Unreliable, a new weekly podcast where we discuss the most interesting ideas and concepts in tech. I'm your host, Anne Currie co-author of Building a Green Software, the Cloud Native Attitude, and author of the science fiction Panopticon series. And today I'm going to be talking to Jon Berger, a mission critical software veteran, regular on this podcast, and incidentally, I'm married to him. So welcome, Jon, who is usefully cached upstairs in my house.

So today represents one of the episodes that we're gonna do periodically, which is kind of like to reflect on what we've heard in previous episodes and also to look forward to the future and have a think about what that means and might mean about software in 10, 20—I always think it's gonna be two years, three years, four years time, but it's more like 10 years or 20 years time.

Today is a reflection on the future of software, which plays on what we just heard in the last episode from Justin Cormack and in episode seven from Martin Davidson on the future of AI and code generation, and from your perspective, Jon, as a mission critical software development veteran.

You've heard all the episodes we've had recently. What's currently in your mind? What are you thinking about what all of this means for the future of software development?

**Jon Berger (01:35)**

I guess I'm interested in where this is going. It's obviously moving quite quickly, and what people can do today is constrained in all sorts of ways. It's constrained by their imagination, maybe. It's constrained by exactly what the AI tooling can do this week, which will be different again next week, and it's also constrained by the context that they have in terms of what service they need to deliver, how much risk they can accept, and so on. But I think it'd be interesting to spend some time thinking about where all this is going, because that path we're on at the moment is pointed in a certain direction. And working out what that destination looks like, I think will inform how people move along it effectively.

**Anne (02:36)**

Okay, that makes sense.

**Jon Berger (02:40)**

If I'm responsible for software development, right, the rug has been pulled out from underneath me. Things are changing pretty rapidly. So when I'm in that sort of state, I like to try and work out, where do I think this is likely going? It doesn't need to be precise, but it's got to be a rough direction of travel, which will help me to work out, are the changes that we're thinking of right now likely to be helpful or not helpful.

**Anne (03:12)**

One thing that's struck me from the last couple of episodes that I've been recording with practitioners or DevRel type folk, but people who are involved, at least in talking to customers and companies about the problems that they're having, is that they're setting out some quite different sets of problems that they might need to be solved by AI.

Justin Cormack in the last episode talked about the problems of maintainers because he was CTO of Docker, a long-term open source maintainer. It has become increasingly difficult to maintain software because as it becomes more successful, it gets bigger and bigger and it has more features and it requires more effort to maintain, it just becomes unmaintainable. So there is a problem there.

But when I spoke to Adrian Mouat a few weeks earlier, he highlighted the problem that they saw at the moment, which was security—that exploits are being exposed much, much more quickly now than they ever have been in the past. So people need to be able to get on top of them, they need to be able to patch, and again he was thinking about can we use AI to solve the problem that is coming out of that. But your work history had a completely different problem, wasn't it? You were looking at how to make code run faster but then at the same time maintain it. So the problem was how can you make code run really fast but be maintained and maintainable by humans. 

So what do you think is the key problem?

**Jon Berger (05:16)**

I don't think any of those are completely different problems. I certainly didn't have any different problems from the ones that were described by Adrian, and of course the code had to be maintainable. I was responsible for products that were in the field for decades. 

You know, when I left Microsoft we were still maintaining products that had been in the field for over thirty years, successful and very profitable, and they still need to work. And you spent way more time on maintenance than you ever did on building the thing in the first place. Well, in some cases, the people maintaining it were actually the people that had written software 30 years earlier. That wasn't the norm, which makes life harder. And of course, security was also absolutely critical. There's not a lot of software out there that's doing that sort of job, that lasts for that long, for which security doesn't matter and updating security matters. So I don't think there's any difference at all in terms of what we're trying to achieve.

And I think they also care about performance in the work they're doing because it matters, because what they're doing is also a scaled problem, which is interesting. Having said that, we've already done a podcast where we did talk about performance at scale in networking where the challenges are quite extreme and people have been willing to go to quite extreme lengths in the past to create high performance software where per packet processing is as low as possible, and that will lead people to handcraft code, including potentially down to the level of assembler, which is by definition therefore pretty hard to maintain.

But the balance there is more towards performance than maintainability. Now, of course, in the control plane, performance matters a bit, but much less. In the management plane, performance doesn't really, or very rarely matters, and therefore your needle is much more pointed towards the maintainability side than it is towards the performance side. I've been responsible for software across all of those, and sometimes it's just about speed of writing, and sometimes it's all about speed of execution, and sometimes it's really about maintainability, which is a slightly different thing yet again.

**Anne (08:13)**

I agree with what you're saying. There's also of course the kind of point almost that Justin Cormack made in his last episode, which is that with a long running project—I mean he was talking about open source projects, this applies to proprietary projects, but the biggest examples are open source projects—that sometimes the pendulum swings, that code was put in for absolutely vital performance reasons. Then over time that performance might come not to matter anymore, but it becomes a maintenance and a security issue. I

 mean, the classic case was OpenSSL became almost unmaintainable because it was full of code that had been written in assembly language to make it perform on certain operating systems or certain hardware. And that just became totally unmaintainable. And it became a security hole, but nobody really knew whether that code was, as Justin described it, load bearing or just a nice to have. The difficulty is that projects tend to accrete code that was utterly key for a certain number of years and then became an utter threat at a later point, but it's difficult to tell which state it's in.

**Jon Berger (09:42)**

Exactly.

Sure. 

So I want to put everything that Justin and Adrian said to one side because I think it's almost irrelevant to the where are we going in the long run question. That's the where are we today and what can we achieve today. The only answer to AI as a security threat is more AI; only AI can defeat AI. Nothing else can operate fast enough.

The maintainability question, like today's maintainability question, looks nothing like the maintainability question in ten years' time, because today the software is maintained by people and in the future it won't be. So it's just a completely different thing. I just really don't think those two things look similar. Now, where does that break happen? How do we gain the trust to go from maintained by people to maintained by AI? I think that's a different episode. I think it's really quite complicated. And I think we'll be spending hours talking to get to that point. I think the goal here is just to work out what that future might look like.

**Jon Berger (11:11)**

And then we come back to okay, well, if this is the direction we're going, then how do we get there? What are the interesting steps on the way to that future? But I think if we don't agree roughly the direction we're heading in, then we won't be as effective at moving through that conversation because we're just gonna go, well what can we do next?

**Anne (11:34)**

okay. I get your point here. That basically all my thinking about what everybody's saying up till now is based on thirty years experience of writing and then maintaining and supporting and managing teams or doing all of those things. And actually I need to let go of that baggage. All the limitations of the past should not become the limitations of the future. Is that what you're saying?

**Jon Berger (11:37)**

I think quite. Change is hard. Change at scale is really hard. If I'm changing, I want to change to the future, not just to a more recent past.

**Anne (12:14)**

So okay. From what you've heard and what you're thinking, what do you think that future looks like? What do you think a good future looks like that we should be aiming for?

**Jon Berger (12:25)**

So I think the baggage that we need to let go of is all of the limitations in software that only exist because it's humans doing it. They don't have another good reason. Some of the things that we've learned over the decades have really good value and we need to keep them, or the AI will want to keep them because they are useful structures and ways of deploying and maintaining software. And others are only there because we are quite limited in our context window, or we get replaced fairly frequently and we can't ramp up in microseconds, or because we have limited communication bandwidth, which means that our sort of horizontal scaling in the team is much more limited than that of an AI.

And I think an awful lot of software development, probably most of the difficult stuff in software development over the last 30 years, is trading off those things against the things that you really want to have, which is your function, your security, your performance, scalability, all of those things. So it's like how do you deliver on all of those and offer a service that the customer wants as cheaply as possible while still being scalable? And I think what you're alluding to on the performance side is that performance in most areas of software development has been one of the things that tends to lose out because it's humans maintaining it, because high performance code is really hard to maintain. Really hard to maintain, more so than most other function or illities in your code.

So I think one of the things we will get with code that's purely AI generated is it will, not today, we're not there yet, but in let's say ten years time, be a lot faster. It will use a lot fewer resources to do the same job.

**Anne (14:54)**

Well, I'm gonna pull you up somewhat on that, which is it might be. It could be, but it won't necessarily be. I mean, not all code will people bother to optimise. I think if you go far enough down the road, then all the people are out of the loop entirely and it will just be optimized. Is that what you're saying?

**Jon Berger (15:21)**

I think there will still be different levels of optimization because there will still be trade offs, right? There will be: Do you want or need to have different versions of your code on different platforms? Maybe, maybe not. One of the trade offs that's just inherent in code and is affected by maintainability, but even if maintainability is free is still something you have to think about, is things like size of code versus performance, where there are things that you can do in your code base which make it flabby but perform better. They often also have a maintainability deficit. Those will still be trade offs that in a purely AI written world someone or some AI will need to make.

**Anne (16:30)**

What you're saying there is essentially almost a hardware trade off—how does it fit into the cache type questions, which are not just about human limitations, they're about hardware limitations. And even if we take humans out of the mix, because AI does it, the hardware limitations still remain.

**Jon Berger (16:50)**

And there will be things where maybe it still costs the AI more to write software. That I don't know. I mean, it may be that once software becomes pretty good, all the software, the default is just it's excellent. Maybe. That's not the default at the moment.

**Anne (17:15)**

Even with good code bases like the Rust code base, the code isn't training the AI to write performant code. Even in Rust, although probably more in Rust than in Python.

**Jon Berger (17:39)**

One of the things that needs to happen and is already happening to get us to that future is that AI needs to learn to write code not just by reading human code. So if you look at the AI training that people are familiar with from the concept of LLMs, where it essentially looks at a body of work created by humans and to some extent emulates that, it is actually very different from the sort of AI that AlphaGo used to learn how to play Go by playing against itself, working out what worked, what didn't work, and it was quite innovative, right?

So it would play initially relatively noddy moves, worked out whether they worked or not. But then as a result of playing gazillions of games against itself, it created new strategies that humans had not seen before, and that allowed it to beat humans because it had trained itself on what really good looks like, which was beyond what humans could do. I think software needs to go the same way to get to what I'm thinking. And people are already starting to do that.

**Anne (18:54)**

So you're thinking a totally no-humans-in-the-mix whatsoever way of doing software development, which is basically a couple of AIs fighting against one another, battling against one another to produce the better instance of the product, almost like a little microcosm of companies battling against one another to produce the products that will be the leading product. That's an interesting question.

**Jon Berger (19:24)**

I guess I wasn't even really thinking about it as competitive in that sense, more competitive in just: can I make this better? If I write this code in this way, does it still pass the functional tests but do so with some other benefit or whatever? But as someone who is not an expert in how to train an AI, I don't know whether that would be more or less effective. It's an interesting way of thinking.

There was definitely work in other companies in the past who, when they had a complex problem, they would set three teams off running and say, "Go build this thing and whoever builds the best one still has a job at the end of it and the other two teams get sacked." That is one way of doing it. I don't think that's the cleverest way of doing it, but I don't know.

**Anne (20:22)**

It's interesting. So obviously our recent episodes have been about AI, about really genuinely ambitious AI-generated code—AI generating the kind of code that your teams used to write, mission critical code. That is like Justin Cormack talking about recreating Amazon S3 and Martin Davidson talking about doing all kinds of things that he was doing.

**Jon Berger (20:25)**

Well—

**Anne (20:47)**

Martin Davidson was using quite an adversarial system. He had multiple chatbots, different models, almost competing against one another in helping him. Justin was taking a slightly different approach where I think he just had one model, but he was a big part of it. But as you say, it's—

**Jon Berger (21:18)**

I heard Martin's statement more collaboratively than that, rather than competing. But you could take it either way, I suppose. I don't know whether he was, for example, genuinely having different models create different ideas to see which was best—that sort of evolutionary approach versus a try something, change it, see see what happens sort of model. I'm not sure.

**Anne (21:48)**

Well, we'll get Martin back on again and get him to listen to this. We've got a lot of questions for Martin. We'd quite like to know how much he spends, which is a question we never asked: what's his token spend? What kind of budget does he have to do all this experimentation? But also, would he consider what he's doing to be essentially collaborative or essentially competitive? We'll have to ask him.

Coming back to that, you were saying your background is that you often had a problem. You worked in networking code, so it wasn't just mission critical, it was networking software, which has to be unbelievably fast. And the blocking thing for you over and over again was it has to be unbelievably fast, but it still has to be supported by humans and written by humans. That was your kind of bottleneck. Would you say that was your primary bottleneck?

**Jon Berger (22:55)**

The fact that it had to be done by humans. I was responsible for lots of different products in quite a lot of different spheres, all generally under the heading of networking. But some of that was very much management plane, some of that was data plane, some of that was control plane, and all the things that go around that. For sure there are times when the limiting factor is a human has to do it. Equally, a lot of your limitations really just come from the sales environment and what your customers will tell you or allow you to do.

But I just think it's a completely different game. That's why I think it's interesting to see where we could get to. One of the reasons why it's important to look at where you can get to rather than how you evolve there is because if there's a place that you can get to which is way better than the place you can evolve to, the new entrants that just go straight there and don't need to evolve will eat the lunch of anyone who's evolving. That's how economic development works, so that's why it's an interesting question to ask and not just say, "How do we evolve?"

But I think you've got to do both. If you've got a business today, you've got to work out how you can evolve. And what we're talking about now, right, almost nothing fully exists; we haven't even started talking about what the thing looks like yet. It's not about what you can do today, but if you can understand where that might get you to, then I would think you'd be able to start evolving in that direction in a way that you can maintain the evolution and get there such that you can maintain your business, and still be in the nirvana of super fast, cheap code that does everything in the future. That means someone else doesn't get to eat your lunch because you're never far enough behind them that they've got an advantage, and you've got the advantage of having an existing product set, existing customers, and money coming in.

**Anne (25:14)**

That should always be an advantage, not a disadvantage ;-) As you're saying, we've talked a lot about the transition here, and what you're really on here to talk about today is where are we going? What's the purpose? What are we aiming for here? Because you've been doing a bit of thinking about that. I'm very interested to hear your thoughts on where we are going. What will good look like in ten years' time, do you think? What is your current thinking?

**Jon Berger (25:50)**

Okay, so this is not particularly an ordered list, but the first thing is it will all just be machine code. I don't see any good reason why high-level languages need to exist in ten years' time for the front end of software development. They are just a brilliantly useful human construct, and during the transition they're very helpful as well. But in the long run, I think their only advantage will turn out to be that humans can read them more easily, and I don't think that is a big enough advantage. There are transitional advantages to languages beyond that as well, but once you've actually trained AI on what the output of a compiled version looks like and then allowed it to optimize to do even better, I think we'll find that human-readable languages are something that exist just because humans like to read.

**Anne (27:10)**

It's interesting because in the last episode with Justin Cormack and his experiments, he's a big language fan, and I know almost nobody with such an encyclopedic knowledge of all the different languages, all the pros and cons, and what they're there for. He was really using languages as a way to effectively guide the AI when he wasn't there, when it was building stuff overnight; he was using the structure of languages to do that. 

**Jon Berger (27:36)**

I agree.

**Anne (27:40)**

But he did also mention another thing, which was when he'd given his AI, Claude, an instruction, but he wasn't watching what it was doing too closely, and it couldn't do it with the languages or the tools he'd made available to it, it had just gone in and edited binaries to get the result that it wanted.

**Jon Berger (28:12)**

Remember when we used to have to go and edit binaries? That was how you fixed bugs. Those were quite a lot of effort. I agree with Justin's logic on the short-term value of languages because AI can't yet do what I'm saying; it can't yet write excellent machine code. But once it can, I can't see any reason why anything else would be better. Those languages are a transitional technology as far as I'm concerned.

**Anne (28:52)**

I mean there is plenty of machine code out there for it to learn from.

**Jon Berger (28:57)**

Well, and which will mostly be terrible because, A, it's software, so it's mostly terrible, and B, it's compiled from human-readable languages. So it just won't be as efficient as it could be.

**Anne (29:12)**

I see what you mean that we're still looking at—obviously, almost everything that it's being trained on at the moment is the waste product of sloppy humans, rather than something that it had created from scratch. Something else that Justin mentioned in his episode was Pony, which is actually a language I'd never heard of before. But the guy who'd invented Pony was creating his own training set, because there wasn't a great deal of Pony training set for the AI. And in some ways that represents a world of the future where the AIs create the training sets for other AIs and they're clean and they're perfect. Is that what you're envisaging?

**Jon Berger (30:18)**

Well, that's what I'm saying. Once you're training your AI to write code by actually just checking the output of the code, not by saying, "What has someone else written in the past?"—maybe a combination of the two initially—then the languages give you some constraints, which can be useful. They allow you to write code faster, which can be useful, but I don't see how either of those help you in the long future. I would say those have more negatives than positives.

The thing that might change the way that works, I suppose, is that I don't know a lot about semiconductor design, so I don't know how much of that is constrained by humans, whether the machine code looks completely different because the machines it's running on are completely different, or whether you can create much more efficient machines. I don't know what the limitations look like there. I would guess you can because I think some hardware features are sort of almost aligned with the way software engineering is done at the moment. And once you're running on biological computers rather than Silicon, who knows. But anyway, machine code—that's my view of that.

**Anne (32:00)**

Okay, so that's one. You said you had a couple of thoughts. So your first one is there will only be machine code.

**Jon Berger (32:06)**

Exactly. I think libraries, open source, code structure, I think that changes quite a lot as well. But the point where you can create just the software that you need and you have trust in it, right—the transition from here to there is all about trust really—then once you've got trust you don't need open source because you don't need libraries. They're not really adding value; they're not fundamental to the way that code is going to get executed.

You probably still need microservices, but not for all of the same reasons that microservices exist today. Microservices do a number of different jobs for you. Some of them are about humans, some of them are not. So like reusability is not necessary. For example, trust boundary limitations may be necessary across different organizations, but not within an organization in the same way. But there are other aspects of microservices which are brilliant for resilience—your resilience architecture—in which that is still a great resilience architecture. So they would exist for that reason.

**Anne (33:49)**

So that's interesting because Sam Newman is going to be a future guest on this podcast, author of O'Reilly's Building Microservices, and his new book is about resilient systems, distributed systems. And I think they do almost reflect two different things: microservices were often a kind of developer tool to limit the scope of a problem so that an individual or a small team could work on it without treading on the toes of other teams. It was always a developer parallelisation tool for teams. But distributed systems are an operational tool that help you to, well, if I'm running 10 copies and nine of them fail, I've still got something running, and you can scale up horizontally rather than vertically. It's an operational tool. So microservices do have two completely different use cases. And as you say, one use case is a very human use case, which is allowing humans to work in parallel with other teams of humans, and one use case is just a physics use case, which is sometimes hardware fails and it's useful to have multiple copies of things running.

**Jon Berger (35:10)**

Interestingly, Martin told us that even with AI writing all his code, he found it useful to break things down into microservices or libraries such that different AI agents can operate on one piece at a time. It sounded more to me like that was a sort of limitation in what AI can do right now rather than something that would necessarily still be true in ten years' time.

**Anne (35:36)**

In some ways, counterintuitively, some of the stuff that we learned about making teams more effective also makes AIs more effective because they do tread on one another's toes, especially if they're all trying to compete somewhat with one another. You do want to have those trust boundaries in there.

**Jon Berger (36:12)**

So microservices, libraries, no need for open source because you just rewrite it all from scratch. Similarly, code control is completely different. Code control is great for humans who need to evolve code one line at a time. But if you're just rewriting it all from scratch every time, then it's just getting in the way. Some people are already talking about how there's no point in controlling code, but prompt control might be useful so that you know what you asked for. I think that's probably an intermediate step as well on the way to AI actually just running a service where it can evolve things, but that will move in that direction.

I think diagnostics are gonna look enormously different, because they have to be human-readable and interpretable at the moment. So I think that would be interesting to see where that goes. I wonder if there's some fun there where just by monitoring other things that happen on the CPU you can actually just work out what's going on. There have been all sorts of reported super sophisticated security attacks based on listening to the sounds that CPUs give off, voltages, fans, temperature sensors, and things like that. I just wonder whether there are ways of—again this comes back to a performance trade-off—how much diagnostics you've got. Is there a world in which excellent diagnostics don't have a performance trade-off? Maybe that would be interesting.

Low level structure is another interesting one, which I haven't heard anyone else really talking about, which is that an awful lot of the way we write code within the language is about maintainability and having just one code base really and not duplicating things too much. Repetitive code is just harder to maintain. In the world of networking software, if you imagine you're processing different types of packets, and your packet processing for IPv4 packets and IPv6 packets is similar but not exactly the same. There are a series of tests that you want to go as fast as possible, but you've always gotta check where the packets come from, is that legal, is it a valid packet, is the addressing okay? That's obviously IP dependent. Do I just need to drop it, or does it go through shapers or whatever? So there's a lot of sophisticated questions going on on each of these things. And sometimes they're literally exactly the same, sometimes they're just conceptually the same, but the actual low-level operation you're doing is slightly different depending on whether it's an IPv4 packet or an IPv6 packet, for example.

So you might well have in your stack a whole series of if-tests where if it's IPv4 process it this way, if it's IPv6 process this way, then a bit of common processing, then another if I'm IPv4 do it this, if I'm IPv6 do this. That makes the code more maintainable, but it is slightly more expensive because each of those if-tests costs you performance. If you just duplicated the entire thing and asked the question once, 'is this an IPv4 packet?', all of the code if it's an IPv6 packet would be almost exactly the same code, but not exactly the same code. 

The fact that it's almost exactly the same but not exactly the same would be an absolute maintenance nightmare for a human being, but not for an AI. So I think there's a massive opportunity to sort of—I don't know whether there's a name for it, it's a bit like loop unrolling but sort of for if-testing. So you just separate out everything, and if you've got repeated if-tests, then massive code duplication in some cases will help you a lot with performance. Maybe that won't be common, but there will be, I think, a lot of cases where that sort of construct is something that will really help you. And then you go back to the performance question we've got, which is like, well, okay, how much of that unrolling helps you? If the code gets much fatter, is that good or bad?

**Anne (41:20)**

I think what you're saying is it's like the opposite of DRY. It's not exactly DRY, but—

**Jon Berger (41:31)**

Not exactly the opposite, but yeah, it sort of is. If you can write code in a way that there's just much less to execute because it's just fatter, but the bit you're executing is fat but has fewer tests in it because you've identified up front that some of those tests are not needed, you would have to save as a human being an awful lot of performance there to ever be bothered to go down that route. And to be clear, in networking code, sometimes we have done that in the data plane packet processing. There is some super speedy stuff out there which is really hard to maintain because those sorts of tricks are being played, but that's way not normal. But that becomes accessible in lots more spaces.

**Anne (42:29)**

I'm gonna predict that it's gonna be called WET code, when you make the code as quick as possible, but you don't worry about repetition. But that means we need to think of something starting with W, something starting with E, and something starting with T. But anyway, the opposite of DRY. WET code is code where there's no attempt to make it DRY. 

When I was a first a developer 30 years ago, almost the first thing I learned was dry, do not repeat yourself. That is the classic way to make code more maintainable, so that you don't repeat things because then you have to worry about whether or not two identical bits of code have a bug in them, and you never do fix the bug in both places. It's just a maintenance nightmare to have lots of copies of the same code all over the place. Hence do not repeat yourself, dry, was like an absolutely foundational piece of advice for developers to learn. And it is a very good example of now we're saying, well, in an AI world, if you don't have to worry about maintainability by humans, if maintainability of code becomes a lot cheaper, then DRY goes out the window. WET is your new approach.

**Jon Berger (44:16)**

And I think as AI writes more code, it will spot more things like that. In the same way that AlphaGo didn't just learn to play Go and then play it as well as a really good player, it actually created strategies that humans hadn't because of the way it taught itself. Some combination of its greatly expanded context window or memory—or maybe it was just luck in the way it evolved its algorithm, I don't know—but it went beyond the state of the art. I think the same will be true here. And then you get to a point where code just couldn't be maintained by humans, right? Even humans that can read machine code are just like, "I can't hold enough in my head to be able to do that."

Maybe it will look in some ways a lot more like code we used to write 40 years ago when we had no resources whatsoever to play with, and you had all these weird tricks that you ended up playing with the CPU to try and get it to do what you wanted. The limitation there was almost always just on the code size, but there's all sorts of fun that you can do there which you can't really do commercially on a product that's maintained and out there.

Maybe you've got a service that runs every day of the week and it does slightly different things every day of the week. Instead of having an if-test, "is it a Tuesday?", now you just have Tuesday's code automatically running on Tuesdays, and Wednesday running Wednesday's code. It would have to be a reasonable performance benefit to be doing something like that, but those things are available.

**Anne (46:15)**

So what else?

**Jon Berger (46:20)**

I suppose the other obvious thing is that all APIs at the moment are just like the slowest things in the world because they're human readable. Human readability on interfaces is probably one of the biggest performance killers that we have.

**Anne (46:45)**

And that, of course, interestingly, that was a huge revolution in our working lives as developers. When we both started as developers and we were working in applications—I was working on Microsoft Exchange, not even super fast or deliberately super fast code—all messages were exchanged in a binary format called ASN1. And it was really hard to debug things because you had to decode these binary structures in order to work out what data was being passed between computers. And back then we had almost no resources and those binary structures were quite small, so they were quick for machines to parse and didn't take up much bandwidth. But almost the first thing we used additional bandwidth for as the internet grew was HTML and just passing things in text format, which are unbelievably bloated and huge, but were human readable.

**Jon Berger (47:53)**

Most of what I worked on, actually even the latest stuff, was binary encoded and pretty efficiently so. But I remember SIP was the first protocol I came across that was a text-based protocol, and it's like: okay, I get why you might want a text-based protocol because it makes things slightly easier, but it wasn't even specified whether it was uppercase or lowercase. So every time you looked at the message, you had to say, "does it say invite in uppercase I?" and you had to test it. All of that is CPU you're just throwing away to make developers' lives slightly easier. That was the first point to me where it was like, wow, software engineering has changed from being like 'the resources really matter' to 'screw the resources, just write code as fast as you can'. That was like late nineties.

**Anne (48:56)**

It moved from hardware being the constraint to developers being the constraint. And at that point, all the hardware got sucked up making life easier for developers. So AI will turn the tables on that. Well, we don't really know, do we, but your prediction is that AI will turn the tables on that.

**Jon Berger (49:24)**

I think it will make things like that look very, very different. But I think that sort of stuff takes longer because, again, it's all about the trust boundaries. And so while it's operating in a mixed environment where you have both AI-written code and human-written code, then that in itself is quite limiting. So to some extent how fast that goes will depend on how valuable people perceive the latter.

**Anne (50:00)**

Have we exhausted all your thoughts there on what code will look like in the future, or is there anything else that you want to add?

**Jon Berger (50:10)**

There was one thing that we should have talked about really, which I guess was maybe slightly implied, and you definitely talked about it with Justin last week, was unikernels. So the whole unikernel concept was conceptually a step in that direction. Yes, you've written an operating system that does all of these things, so it does everything for everyone, but any one use case only requires 20% of all of the things. You don't use all of the drivers, you don't even need all of the basic functions. That, but more so essentially, is what we'll see in AI-written code.

Now, whether it will actually be unikernels, which it could be, right? Certainly if you're not doing anything multi-tenant, do you gain anything from having user space and kernel space split? Well no, you've just got code running slower. Kernel space code is harder to write, but not anymore. So why would user space exist? Well, maybe something like it exists in a multi-tenant, in a hypervisor style environment. It's not quite the same thing, but that sort of split, sure, people might still want to do that.

**Anne (51:47)**

That is an interesting one.

**Jon Berger (51:48)**

That's a pretty big structural change, I think.

**Anne (51:53)**

Well that would be a very interesting direction to take. There is only the kernel; there is no kernel and user space anymore. So you've put forward a lot of quite radical thoughts there, based on 30 years of you being absolutely deep in the writing of mission critical software that runs everywhere—this kind of system software that runs the world. No more code, machine code only, no more humans in the mix, potentially no user space, only the kernel. And as we say, we deliberately haven't talked about how we get from here to there, which will vary massively from company to company, because some people will be starting from scratch here and some people will need to transition. That is another episode.

So thank you very much, you've given me plenty to talk about. And since you're only upstairs in my house, I imagine we will be continuing to talk about this for quite some time. And I'll see if we can get Martin back in, and there are various other people who I think might want to put their oar in on this discussion. Justin, for example, might want to come back in and say, "well, hang on a minute, don't get ahead of yourself," although I think that Justin at the moment is more focused on the transition than the total end game. Although ironically, he was more focused on the total end game ten years ago when he was involved in Unikernels, which was massively ahead of its time in many ways—fantastic project.

Anyway, thank you very much for being on the podcast, and thank you very much to all the listeners and watchers, and I hope that I will catch you again on a future episode of the Asynchronous and Unreliable podcast. Thank you very much.