
Loading summary
A
I love the term vibe coding. It sounds so cool, it sounds so relaxing to me. It's like sitting with a cup of coffee and, you know, getting something done and solving some problems and having fun with it. Does that belong in the enterprise? Probably not.
B
This is a show about the future of tech and the future of work. I'm Jeff Nielsen and today I want to dive into the future of software development in the age of AI. The obituary for software development is free front page news with every other CEO boasting that 100% of their code will be written by AI. And morale for coders is at an all time low. I think that is so stupid and that AI has made developers more important than ever. And my guest today to discuss that is Lawrence Moroney. Lawrence is an award winning AI researcher and best selling author who was head of AI advocacy at Google for over a decade and he's currently director of AI at Army. As one of the leading experts in machine learning, I consider him an unbiased voice in this space. So I want to find out what the future really looks like. Is AI still a bubble? Is vibe coding the future? And is a comp Sci degree destined to be completely worthless? It should be an amazing conversation. Let's jump in. Lawrence, thanks so much for joining today. Really excited to talk to you about all things AI, future of tech, software development. Maybe to just set the table a little bit. I mean, you've been a fairly vocal critic, I guess around AI hype for a number of years now around concerns that were, that were in a bubble. And frankly I have been as well and I guess for me it's been a little bit disheartening in some ways not seeing that come to fruition despite, you know, some of the, I guess, underlying concerns. And so I wanted to, you know, ask you, now that we're here in, you know, the summer of 2026, where are we in this cycle? Has your position on this changed? Have you, you know, kind of recanted based on what you've seen about where we're at or how do you see the next handful of months playing out with this technology and I guess the financial futures related to it?
A
Oh wow, there's a lot there. So let me just start like we're just like with the whole idea of hype. I'm still very much an advocate for asking people to be careful to understand what the hype cycle looks like and not to get caught up in the euphoria in a hype cycle. Right. So every hype cycle has that shape that it follows. It begins with a technology trigger, it rises to a peak of inflated expectations before falling down into a trough of disillusionment before you can start rising up to true productivity. Now AI has been kind of unique in that, like I said, it begins with a technology trigger. But in the AI space there have been so many, so many technology triggers that almost end up restarting the hype cycle again. Right when I first started getting involved in AI, many, many years ago, just the whole idea of a neural network was a technology trigger and the world went crazy. And then cheap neural networks and cheap data and open source frameworks like TensorFlow or PyTorch, and then later foundation models like GPT or Gemini and all, all of these start these new cycles again. So I think, you know, for where I generally want to strongly advocate for people is like every time it begins with a technology trigger and you've got this massive peak of inflated expectations that if you invest too much into those inflated expectations instead of tunneling through to understand, I mean it's horribly named the trough of disillusionment. But you know, to, to, to understand what that really means and that's, you become disillusioned with all of the extra hype, you become disillusioned with the nonsense and you start understanding what the technology really is and what it can do and how it works and what, and you're making your decisions based on your own understanding rather than all the noise that's floating around, then things will always be good. That's the point of the hype cycle chart. Where the pain happens is when you don't do that. So that's all of the leadership that I've brought to places where I've been and all of the advocacy that I do is really all around that is like, I joke sometimes, but I'm a professional disillusioner. But I think that's really what you want to be. Once you get beyond that peak of hype and that peak of misset expectations with any technology, not just with AI, that's when you can start becoming truly productive and that's where you can start guiding the positive future that you want. So for the people who do that, like you ask about future and future prospects and those kind of things, it's like that's what I encourage them to do is, and the key to getting there is really understanding the technology, what it is, how it works, what its merits are, what its costs are, are. And you know, and then start making smart decisions for your business or for your Life around that.
B
So, Lawrence, I'm, I'm really glad that you, you know, in some ways unbundled the fact that AI is this whole bundle of technologies and we use this sort of nebulous term to describe an awful lot of different things that can have an awful lot of different outcomes and serve an awful lot of different purposes. One of the things that I guess I struggle with is the difference between what people tend to be using the technology for now in practice versus the promise of what it could one day do. And I was actually just recently looking at a survey data set we had conducted with a number of firms who had said that, yes, they're actually ahead of the curve in their AI usage. And when I dug into, well, what does that actually mean? It's almost all kind of the, you know, standard automation of the most boring business things you can imagine, right? Like it's saying, well, we're using AI for meeting notes and we're using AI for, you know, automated document creation and a little bit for development. And so I'm curious, you know, it feels like there's this promise that something better than that, something more exciting is driving this hype. What are you actually seeing in practice? Is there a much more exciting wave right around the corner or is this it and it's fundamentally a productivity and efficiency tool?
A
It's a great question. I mean, I think there can be fundamental improvements around the corner. It's just up to us to decide how we want to embrace them. Now, ultimately, what I found, you know, for years working in AI, where the people have been the most productive with it, is really in two main things. The first one is if you're taking an existing thing that you need to do and making it much more efficient and making much more productive. Now that could be mundane things like meeting notes like you've mentioned, but it could also be global scale things like, you know, massive business processes to be able to cut inefficiencies out of them. Every business is different, every process is different. But like the family and the category of things that you would do is the same, right? It's adding productivity, it's reducing inefficiency, it's reducing waste, you know, by doing things intelligently. And whether that that's with biological intelligence from people or artificial intelligence from machines, I mean, or a combination of the two, which is my preference, you know, that's the way forward. The second of these classes to me is the more interesting part, and that's doing things that were previously considered infeasible or Impossible without the use of artificially intelligent technology. Like, I mean, a very simple, trivial one is most of us wear some kind of a watch, right? For fitness nowadays. Now, that watch can detect our activities, right? My watch, if I'm running and I forget to tell it that I'm running, it detects that I'm running. There's a small artificially intelligent application running on that watch that's detecting a change in my behavior and increasing my overall user experience with the watch and making me much more likely to want to wear this 24, 7 and buy a new one when it comes out and those kind of things. Now, that was the kind of application that was infeasible and before AI, right? If you were trying to build something that detects somebody's activity to see if they're walking, running, biking, golfing, or whatever in order to create a better user experience on a product like a watch, I mean, it would cost. There would be millions of lines of code. It would be too big to fit on such a device. But with AI and machine learning being able to train a model based on the data on the watch to be able to detect those activities, suddenly it became feasible. Now, that's a relatively trivial example. But think about any business and the big things that they would love to solve, but they are financially infeasible, computationally infeasible or whatever to be able to start pivoting towards thinking about how do we make those infeasible, feasible with automation, with AI, with maybe agented workflows and stuff like that. And that's that second category. And I think that's where the massive growth will come from. And I do see people thinking in those terms already and doing things in those terms already. And they're probably not the ones necessarily talking about it that much because they want to continue to build on the advantages that they get from building in that way.
B
It's a really interesting example, and I really like it in some ways. And one of the things I like about it is, in that example, AI is not really the star of the show, if that makes sense. It's kind of an enabler of a completely separate product or a completely different vision that's now unlocked by AI vs I'm selling you AI, I'm selling you a fitness tool that happens to use AI. Is that indicative of the types of, I guess, value that we're going to see unlocked here?
A
I mean, I think it's indicative of the type of. Right. Thinking in order to be able to unlock value. Right. You know, There's a phrase that's been knocked around for years that AI is the new electricity. Okay, but then think about that a little bit more deeply. Electricity is not something you get excited about, right? You know, electricity is just something that you expect and it drives things. I'm in a room that's lit up because of electricity. I'm speaking on. My laptop's on battery, still electricity. I'm speaking to you because of electricity, you know, and it fades into the background and it empowers things that were previously infeasible. I'm currently on the 18th floor of a building in Seattle, right. Without electricity, it would be a lot of steps to walk up to get here. It would be very difficult to light, heat, cool, all of those kind of things. But the electricity itself just faded into the background and makes all of this type of thing possible. And to me, when, if you're thinking in terms of AI and particularly going beyond the immediate future, that it's the types of applications that are made possible when AI fades into the background. And we don't get excited about AI, but we get excited about the application that it empowers. Like my trivial example of fitness on a watch. That's when you start getting into the real productivity. And when I start talking about those two classes of things. The thing that was previously considered infeasible but someday will be considered default is the kind of thing that would be powered by AI. And that's the area of massive growth and optimism that I have is thinking about what those applications are.
B
If you don't work in enterprise technology, you can skip ahead or take a quick braincation, but if you do, infotech is your secret weapon. Infotech helps IT teams get projects done faster, better, and at a lower cost. Whether you're rolling out new tech, improving processes, or just looking for cost savings, Infotech provides unlimited access to practical tools and expert guidance you need to execute at a fraction of the cost of traditional consulting, no matter the project. From AI strategy to cybersecurity to vendor negotiation, Infotech has you covered. Check it out at the link below. And don't forget to like and subscribe. I really like that. And I'm just, you know, sort of processing that. And I'm thinking about that in relation to the way AI is talked about these days still. And yeah, for better or for worse, one of the biggest differences between the advent of electricity and call it Even the first 50 or 100 years of electricity and the present day around AI is this sort of media sphere and the channels we have in this sort of, I don't know, I guess, engagement driven behavior where everybody feels incented to see who can, who can compete by saying that AI is going to be the greatest or it's going to be the worst. Right. Like, it seems like any sort of rational middle ground gets drowned out. Like, God forbid you say that an AI driven future will be 10% better than a future, you know, without AI. Like it's like the most boring thing you could possibly say.
A
So 6.4%.
B
Yeah, there you go. There you go. Even a boring number. So I guess with that in mind, are there any stories you're hearing a lot of or any narratives that you consider red herrings that, that are taking up an awful lot of oxygen in the room around AI that you think are, you know, close to utter nonsense? And is there, you know, a reality there that's maybe not being discussed because it's too mundane? That's a better model for how we should be thinking about this.
A
I mean, I think some of the red herrings that drive me crazy are the ones where absolute statements are made, right? We don't need humans anymore because we have an agent that does this. Or you know, we don't need coders anymore because we have a model that can write code. You know, and it's like I always like to say, understanding is a triple edged sword, right? There's, you know, there's one extreme, there's the other extreme, and there's the truth in the middle. But all three of these will cut you. So like the red herrings on one side, you know, are cutting very deep and making people very upset. Like things like coders are not needed or particular jobs are gonna go away. And you'll notice that over time the people who are telling those stories are backtracking, right? They're realizing that's not case. The downside though is like people who make a business decision based on those opinions and then make decisions that will impact real lives based on those opinions on this side are very, very poor business decisions and very, very poor leadership. So it's like those type of red herrings where it's sensationalist, it's absolutist, and those kind of things are always the ones that end up getting dialed back. But how much damage is done before they get dialed back is what, you know, is some of the things that I'm very passionate about advocating. Don't do that. You know, it's like, be smart in making your decisions and you certainly don't want to jump on the bandwagon because I think you use the word engagement based that when people say something inflammatory like that, they get a lot of engagement, right? They get a lot of reward for doing it, but it's a very short term reward where they're sacrificing the future to save the present. And you know, and I, and I just like that would, that's always the advice that I give to people in business settings and in one on one is like, look at those people who've got the most engagement and then ignore them. Right. You know, and then no offense if you have a lot of engagement listeners, but you know, you know, but it, it is one of the things that those inflammatory stories are out there. And it's funny because I work a lot in the science fiction field. I've done some consulting on movies and TV shows and stuff like that. So I get to work with and know a lot of sci fi writers. And the sci fi writer mindset in some ways is the same because like, you know, when they're writing a story, it's almost like, hey, every story needs an antagonist. And right now the modern antagonist is the specter of AI, right? And it's very easy for us to write stories about the specter of AI and like you just turn on any movie right now and it's like there's Terminators, there's AI being the bad guy or whatever, you know, and it's, they're cut from the same cloth, but there's so much opportunity to kind of not do that. The other side of the spectrum, of course, are the AI optimists where it's this happy hippie future where AI is going to give us abundance and every problem is going to be solved. And it's very pleasant and it's very nice reading and very reasonable sounding, but unfortunately that's just far from the truth as well. I think the key thing that's beholden on us is to try and figure out where society actually is and where the technology actually is between these two extremes. Understanding that that will also cut you, but to be able to navigate that and navigate that effectively, I think is the job of every leader out there. Not just business leader, not just political leader, but also technical leaders like you and me.
B
So with that, let's try to walk that middle line for a minute. And you know, maybe in relation to the example you used earlier of coders aren't needed anymore, and there's an adjacent, there's an adjacent saying I'm hearing lately too, which is mostly CEOs it never seems to be like CTOs saying that 100% of code will be written by AI in their company. So I'm curious, what's your reaction to that? Is coding a field that folks shouldn't go into anymore and it's just going to be considered completely antiquated? What is the future of software development in an AI age?
A
Great question. I want to start though with that 100% statement that whenever anybody says 100% of something, blah, blah, blah, blah, I automatically don't believe them. Right, because it shows that careful measurement hasn't been done. There's no way you replace 100% of something with something overnight, that kind of thing. That sounds like a sensationalist statement off the bat. Now you could say maybe the majority of our code is going to be AI generated, or more than three quarters of our code is going to be AI generated. And then I'm going to listen to you and I'm going to listen to your reasoning. But my encouragement would be as soon as somebody puts an absolute number like that, you know, my BS detector goes off. That'll be the first part. The second part, though, is like just talking about coding itself. I think the optimist in me, which is usually the dominant trait, generally says that. I mean, I've been coding for many years, like 40 plus years, and what I've seen is that every advance in coding has moved me up the value chain. Right. You know, the very first coding I was doing was very primitive, able to do very primitive things on very primitive machines. As time went on and code got more and more sophisticated, you know, like, for example, the emergence of the Internet and being able to write code and things like Java, Blessed Soul, you know, that kind of stuff that allowed me to then move up the value chain. And instead of previously, I was writing a piece of code that would run on one machine for one user. I can now run a piece of code that runs on one machine for a billion users. And the value that I bring continually is moving up the value chain. As a result, there's no reason why anybody should think of AI differently. The idea of being able to generate code instead of writing code can be very seductive in thinking, hey, I don't need to put in the brain power to write a proper solution anymore, because AI engine X can generate that for me. But the reality is, once you sit down and you start doing it, is that while it can do a lot of the drudgery work for you, it can never create that full solution to your actual problem. And to your needs. It's great for flashy demos. It's great. You can see somebody vibe coded a breakout game in five minutes and oh my gosh, amazing, fantastic, really fun. But once you start getting down into real solutions, there's domain expertise that's needed for a particular thing. There's domain expertise within your company, if you're building it for your company and the solutions that they have. And there's all of this extra stuff that cannot be generated by a general coding machine, but it can take the drudgery out of your work. So maybe you can do something in one day that used to take you 10 days. Or if I go back to what I was talking about, the feasibility side of it, you can start building things that were probably too expensive to build in the past, but you as the human, are continuing to move up the value chain as a result. So it's the encouragement that I always give to developers that if your developer identity is entirely about your ability to code, you might need to refactor a little bit there, right? You know, remember those T shirts? I turn code into. Sorry, I turn coffee into code. You know, those kind of things are like that developer identity. I used to wear one of those shirts. The realization is as code becomes possible to auto generate, if all you can do is code, then that's where you might need to think about your choices a little bit. But if you are able to take the ability to solve a real problem and turn that into code and now expand that ability by being able to generate much of that code, you're suddenly more valuable, not less valuable. So I would continue to encourage developers to invest in your skills, invest in your development skill and to continue to do that. Because all of that stuff of people saying, I don't need coders anymore because it's 100% generated. Sorry, Red flags are waving like crazy when I hear that. And then the other part that I would say is when it comes to software development, that there's a new thing that I'm seeing emerging and there's no real term for, I call it ephemeral code. Where once upon a time as software developers, our job was to build a product and then that product would ship. It might ship on a server so that billions of people could use it. It might ship on a desktop so one person at a time could use it. But there was an artifact that we actually shipped we had to maintain. It was an app in an app store. Those kind of things, with the cost of code generate with. Sorry, with the ability of Code generation driving the cost down. There's the whole idea now of being able to, hey, I can spin up code to solve a particular problem and then I can throw the code away. I don't need it anymore. And as a result, a lot more bespoke solutions can start happening. Whereas in the past I had to think in terms of when I write code, what do I have to do to maintain it, what do I have to do to pass it on to somebody else, now there are many, many solutions out there where it's a case of, you know what, I don't need to build a product for this, I don't need to buy a product for this, I can spin up a piece of code to solve this particular problem for me and then not take on the technical debt of maintaining that code anymore. And the mindset behind doing that, I think is only going to grow more and more and more prevalent, particularly in enterprises. And as a result, the coders and the engineers who can do that and who can solve a problem quickly or who can train the non engineering staff to be able to do that and take some of the burden off them again is a very valuable skill moving them up the value chain.
B
I find that the ephemeral code model really interesting and part of the reason I find it interesting is it seems like it's sort of the polar opposite of so many of the principles of coding that have been, you know, what we've been taught for so long, right? We almost treat code as eternal, like this is something that's going to outlive you. So make sure that you comment it well, that everything's documented, that it's, that it's clear versus the idea that it could ever be disposable. So if it can be disposable, I guess what are the implications of the coding ecosystem both technically and organizationally surrounding it?
A
That's the question, right? How do you project that forward? I think one of the biggest implications, if I'm right, an ephemeral code becomes more and more important, like for example in enterprises, then those big fat general purpose applications that are designed to do almost everything I worry about, like you know, the continuing to build and maintain and support those. Whereas, you know, if you know, you, there's the 20 pound hammer for the one pound nail, right? You know, whereas like, you know, many business problems, if you can solve them with a one pound hammer, that a disposable one pound hammer equivalent of a disposable razor, for example, that kind of thing, why not? And you know, so there's long term implications there, I think, in how we build general purpose applications which are still going to be necessary. But I think those general purpose applications, if I were to guess, would probably slim down a bit because they are. They tend to have to be overgeneralized, right? You look at email applications, they can do everything, you know, that kind of stuff. What if they become focused just on email? And for some of those problems that one person solves one time a month, do we need a big expensive application for them to be able to do that thing, you know, one person in your enterprise to do that one time a month? Or do we need something that is so customizable that a software engineer has to spend a month customizing it so the person can, you know, once one person can, one time a month use it? And so that kind of the. I think the age of those gigantic pieces of software that are general purpose, you know, that might be changing very drastically as a result of ephemeral software. I think, I mean, I just use. One particular example was a couple of years ago before I joined arm, I was working on forming a startup to help people make movies using AI. And I was creating a piece of software for that. So this will be a desktop application, you know, that had a thing in it that I called the meat grinder that would take, you know, your script or your story or whatever, and it would break it up into all the tiny little artifacts that you need. You can't just push a button and turn a script into a movie with AI, you know, there's so many steps and processes and shots and artifacts and all these kind of things and to take all of that complexity out of the user. And I got pretty far along in building this thing. And then I realized when I made my first movie that all of the things that I would have to do to this, you know, to make it general purpose enough for just my movie, never mind somebody else. The cost of building all of that was like, it was just cheaper for me to do bespoke software for the movie and to start. And that's where the idea of ephemeral software came to me. And then I abandoned the idea of building this desktop application, you know, and I think, you know, though, that I can see that will happen a lot again if I go back to the enterprise, where the enterprise will have people who need to solve a particular problem, transform this data from this to this, apply these analytics to value. Wouldn't it be better over time for many of these problems to be solved by somebody who can just spin up a bespoke project to do that. Going back to the old, you know, the two things that I mentioned earlier, right, like, you know, making existing things more productive or doing things that were previously infeasible. The idea of bespoke projects was previously infeasible, but now suddenly it has become feasible and it may be the right decision in many cases.
B
The example is really interesting and I can certainly see a number of use cases for that. The piece where I'm still trying to sort it out in my mind, I guess Lawrence, is if we're talking about large scale enterprise information systems and suddenly there's data in the mix, if we're talking about ephemeral code, does that create, I guess, a traceability problem for us if we have to go back later and say, what did we actually do here? And validate whether we actually use the right data or, you know, have some sort of common language for the data and can confirm that we're making decisions based on the right information?
A
Oh, absolutely. I mean, I'm not saying it's a, it's a drop in replacement for every scenario. And this sounds like a scenario where you don't want to do that. Right? So, I mean, let me give an example. Pulling it out of the air right now. So forgive me if it's wrong, but I mean, I used to work in a financial services enterprise many years ago in Times Square in New York City. And a lot of my job as a software developer would be configuring existing pieces of software so that analysts could run experiments. So for example, they would come up with a new analytic that would take in various pieces of data to establish a value for a company. So then we could tell company A, if you know who company A wants to buy company B, you know, we could tell company A, well, here's our analytics of company BE and here's why we think it's worth it or not worth it. And there was a crazy amount of configuration of heavy enterprise software that I would have to do to be able to come up with those analytics. Sorry, to come up with those answers where an analyst would define the analytics and I would encode them into a pipeline. In the idea of ephemeral software, it could be just simply a case of I sit down with this analyst for five minutes and I code up a thing, you know, that takes data pieces A, B and C, feeds them through a pipeline that I've just spun up, applies his test analytic to it and gives an answer. And then he realizes, nah, his analytic that he designed is all wrong. Let's go and start that again. That type of thing, you know, that type of prototyping is a clear case for it. But I would say that that will pull through, that there will be many solutions in the future, I believe, and maybe people are doing it right now where it's a case of why would we need to configure big heavy pieces of software to put a square peg into a round hole to try and sort out a thing when we can just spin up something quickly to do that, solve the problem that we have on mind and then move on.
B
That example is really interesting to me and I want to play with it for just a second because it teases out something. That's another one of these discussion points, which is Vibe coding, which you mentioned earlier. Because when you used how this could look in 2026, Lawrence, what you didn't say is there's no you or no developer at all. You didn't just say the analyst will do it all themselves and they'll pull it all out with no intermediary. And so I'm curious with that example and in general your perspective on Vibe coding or like an actual true coderless future where you've got, just call it business generalists or, you know, operational users who are doing everything, you know, using their own devices. Yeah.
A
So first of all, I love the term Vibe coding, It sounds so cool. It sounds so relaxing to me. It's like sitting with a cup of coffee and, you know, getting something done and solving some problems and having fun with it. Does that belong in the enterprise? Probably not, right? You know, there may be an element of CO generation which is part of Vibe coding. Yes, it does. But I think the core of your question here is like, you know, if I giving back my example of me working with an analyst to figure out a particular problem, am I even necessary in a future where code can be generated or can the analysts do it themselves? In some cases, I would say the ability to create the code to solve a problem could be moved to the non coder. Absolutely. Does that mean coders will go away? I still say no. I still believe that moves coders up the value chain. And one important part of moving them up the value chain that I, I'm personally passionate about is when we look at AI models doing things for us. Remember that AI models are trained to be generalists and not specialists. If I am within an enterprise and I need to do a thing within the enterprise for the AI model to be as effective as possible, it has to be a specialist for my enterprise. There are secrets in my enterprise that I'm not going to share with a third party. There are techniques in my enterprise that have grown up over time. There are standards of communication or coding or documentation in my enterprise that are uniquely ours. And at some point the model is going to have to be trained on those. And that brings me to the thing that I'm most excited about in the field of AI is the smaller models becoming more and more intelligent. And those smaller models then, because in many cases the weights are made open that I can take those weights and I can retrain them or fine tune them on my own data and on my own techniques. Again, that's a job for a developer, right? Not for the analyst. And that's a job for the developer that has suddenly moved them massively up the value chain compared to just general coding. And then once they've done that, that's a model that needs to be continually maintained. That's a model that needs to continually be retrained as new information is coming in. And that's a model that then becomes inherently value. So that maybe some of the tasks that were previously needed by a coder can be done by a non coder domain expert. But your job as a coder has again increased your value to the business.
B
Let's talk about those smaller models for a minute. So if we're, if we're trying to make this really practical and we're talking about coders in an enterprise organization, what could that look like? And if you're, you know, I guess a business leader, like a technology leader within your business, how should you start investigating this and what would that look like and what would it yield?
A
You sure, sure. So total shameless self plug. I'm writing a book on this at the moment with O'Reilly on fine tuning small models. So forgive me, totally shameless of me. So some of the things that I talk about in that are exactly the answer to your question, right? There's no magic pixie dust, excuse me? There's no magic pixie dust that you can sprinkle in a problem and it will be solved. It involves hard analytical work. So for example, if you want to fine tune a model to do a particular task, and the task that I go in the book is really for a doctor's office to be able to have a model that can help do front desk work and help answer some basic questions. And the reason why you would fine tune a model to do it is that if you look at an AI model today and you ask it particular questions. It's very robotic in how it answers, it's very machine like and how it answers. So part of the fine tuning will be, let's fine tune it, A, with knowledge that it may not have already and B, to speak in our voice, right? We want to appear friendly. If a parent has a sick child, we want to reassure them, you know, we don't want to give them a checklist, you know, things like that. So the pipeline that you have to do there, first of all is gathering the data, right? Gathering sufficient data to be able to retrain a model. And then perhaps most importantly, is formatting the data in a way that you can then efficiently fine tune a model. You know, the images out there that we just shovel it in like coal into a burner. But it doesn't really work like that. There's a lot of work that has to be done and a lot of pair model specific work that has to be done based on how an individual model will expect it. So that requires a lot of brain power, it requires a lot of engineering expertise to be able to do that. And then the job of fine tuning, once you've done that, is relatively easy, right? It's a case of. Now that you've told. Shown the model lots of examples. Sorry, now that you've defined lots of examples of how the model would like to see it and how it understands it, now you simply go and you show the model. To do that, there's a technique called LORA Low Rank adaption or Low Rank adaptation that's actually used to do that and that's relatively easy and relatively cheap to do. You're talking thousands of dollars of GPU time, not billions of dollars of GPU time to be able to do such a thing. And now you have a model that you can deploy, and then you do all of the engineering principles that are ageless. You're putting it out there, you're gathering data, you're gathering metrics, you're seeing how well it works, you're seeing what doesn't work. And then you start the whole ops lifecycle of continual improvement. And now you have a model deployed in the enterprise that's specific to that enterprise. Now, the example I gave was Q and A for a doctor's office. But there's no reason why that couldn't be your code and your analytics within your enterprise or whatever it is that you want to fine tune the thing to be an expert on. And I think that's ultimately where we're going to start driving a lot of value in the AI industry. The other benefit, of course, of these small models is that you can run it on your laptop so you have privacy, you don't have the latency issues, you don't need expensive data centers in order to be able to run this on. And all of those kind of things become feasible and become possible.
B
There's that that makes a lot of sense to me and there's a few implications in there that I want to tease out.
A
Sure.
B
One of them is, and it comes, it comes back to just things you were talking about earlier. But I like it because it really feels like it's solving a real problem or it's designed to solve a real problem rather than just starting with hey, we need to get more AI in our business. And it feels, yeah, it feels a lot more like how do we actually use this as a tool that's going to help us versus taking a technology first approach. And it cuts through a lot of the hype we talked about, which makes it feel very practical to me and a very different model from what we're seeing. You know, I guess the Clauds and the Chatgpts shout from the mountaintops.
A
Yeah, I mean, absolutely. I mean there is still always going to be use for the gigantic models, right. But the idea of them being the sole way to use AI is I think the big mind shift that we need to start thinking about. I do see a bifurcation happening, right? As those bigger models become better and more intelligent and trained on with new techniques and new data and all of those kind of things, there will be problems that are only they can solve. But the mindset of the only way to solve problems is with them is the thing that I think would need to change and that's that bifurcation that I'm talking about that the smaller models are no longer just toys.
B
Right.
A
A lot of the innovation that's gone into model architecture to make models more efficient is actually being driven by the small ones. You look at things like Nurip's papers, last year, I believe it was Quinn. There were more papers designed on the Quinn model than the wear on any other model. So that small model mentality is beginning to come in. But not just a small untrained generic model. The real value becomes when you have the small fine tuned model on your specific task.
B
The other implication of that, Lawrence, that I wanted to talk briefly about is in that world, it strikes me as doing that effectively in some ways means there's going to be more engineering in your company rather than less, which is again, kind of diametrically opposed to some of the conventional leadership wisdom that's happening around AI. And I'm curious because I am somewhat involved in the coder community and I follow their forums and the overall sentiment about the future of software development feels like it shifted into quite negative territory in the last year or two, as though, you know, the sentiment is that senior leadership is trying to reduce the amount of engineering happening in their organization, and in some case they're following that up by divesting themselves of large numbers of coders. And so, I mean, if that happens, it makes it substantially more difficult to do some of the things you're describing. How do you see that playing out for the organizations that are doing that, that are trying to decrease their engineering footprint versus increase it?
A
Yeah, I mean, the first thing I would remind them is like, you know, we have seen stories of the engine of organizations that have done that. We've also seen many stories of organizations who've regret doing that, or at least they did it too quickly, you know, and I think that's the first big reminder. The second big reminder is, I mean, there's an old adage that you cannot shrink your way to growth. Right? And I can understand that. Like if you're a business leader today and you're looking at the expense of your engineering and you're looking at the benefits that that engineering is giving to you, and you're doing a costs benefit analysis and then you're reading those stories of this kid who can go to Claude and build a product overnight. You know, that kind of stuff, that there's certainly a lot of pressure on you to start making cuts and changes. But I think that my advice there is to resist that pressure and to really understand A, the truth about that story about, you know, the kid used Claude to vibe code a thing and B, how you can take the existing engineering resource that you have and grow the amount of value that they bring to your company. And the idea of being able to a, at least generate code, to be able to expand the domain of any particular developer, is a really interesting and seductive and powerful one that can work. But you know, right at the beginning when we were talking, I was saying there's two things, right? There's making existing things more productive, but then it's discovering things that were previously infeasible. And I think the role of a business and technical leader there would be like, well, what are the things that are infeasible today that will grow our business? You know, 10x or 100x and like, can we start using the resources that we have today, the engineering folks that we have today who know our business, who know our stuff, and start deploying them differently and start giving them the ability to expand their domain? One of my favorite sayings is the pursuit of happiness is the exercise of vital powers along lines of excellence, affording them scope.
B
Right.
A
You know, and I think here the pursuit of profit and the pursuit of productivity is the same thing. It's taking those vital powers that you have, giving them new lines of excellence and giving them scope and being able to massively grow your business. You can play the defensive game and be in retreat by doing those kind of cuts. But what's going to happen is somebody who's not doing that, somebody who's innovating, somebody who's thinking out of the box, somebody who's doing the infeasible things, will be that company that disrupts you.
B
Right.
A
And will be that company that takes over your business eventually. And you don't want to be in that position. So I'm very much. I've been a software developer my entire career. I've been writing code since I was 10 years old. You know, I'm not saying it because I have part of that identity, you know, but I'm really saying it because it's just common sense that when you see through the curtains of hype that there's so much opportunity there by investing in your skilled people rather than by cutting your skilled people.
B
So assuming we keep our skilled people and assuming we've got the, I guess, wisdom or forethought to actually focus on, what are the new opportunities? What can we unlock with technology that never existed before? What do you see as the role of coders, of CTOs, of CIOs, of technology leaders? And is it changing or is it the same as it's ever been?
A
Oh, it's changing. I mean, I don't think it's ever been the same as it's always been because it's constantly in flux.
B
Right. Well said.
A
You're right. Even if you take AI out of the picture, it's something that's been constantly in flux. And we have to realize that, you know, the curve of change is accelerating, but it's still. It's always going to be changing. It's interesting that the first named entity that you use there was coders. I mean, I think if your personal identity is as a coder, that's the person that I would appeal to most to say you're the One unfortunately, who probably has to do the most self reflection and the most adaptation in this world. Because if all you can do is code, you have to realize that models can code just as well as you can, but faster. Or maybe they can code better than you can, but faster. So you have to start thinking of your identity above being a coder. I've been using that phrase moving up the value chain. So what is it? As you, as somebody who's passionate about, who loves doing it and who's very good at writing code, how is it that you move yourself up that value chain? Obviously it differs for every business, but I would say the brunt of change and the brunt of needing to make personal changes to adapt to that change is most heavily on you, but the opportunity is also the greatest for you.
B
Right.
A
So like, you know, and I think that would be something that I encourage every coder listening to this and then every CTO. I can't remember you said coders CTOs. I can't remember the other.
B
I said CIOs as well. And tech technology.
A
I think for you, what I would encourage is to realize that these people in your organization who are engineers, who are coders, who are forward deployed code. What is the new term?
B
Engineers.
A
Forward deployed engineers. Thank you. To realize that the opportunity that you have to be able to apply their brain power to solve problems that will be massively impactful, positively for your business. It's your job to develop that. It's your job to help in this new world to continue to develop that and to encourage that as opposed to seeing people as a line item on a sheet that's easy to cut. Right. So the best CTOs and the best CIOs I think know that already, but I would just encourage them to keep thinking in that way.
B
I want to get really crisp on what you've described a few times as the value chain and moving up the value chain. So if you're, if you're coding and you see yourself as someone whose identity your career is writing code, what is up the value chain? If that's a question you're struggling to answer, what are the adjacent activities that are going to be the most valuable skills I guess to develop?
A
Right. I think first of all is, I mean, if you are coding in an enterprise today, it's knowing and understanding what business problem you're solving by creating that code is the first step. I would hope most coders are doing that already, not just reading a spec and turning it into code and delivering it. Right. But I mean Junior coders tend to do that as they get more senior, they begin to understand the problem. Because sometimes you get a spec from somebody, you realize the spec is wrong, you're going to push back, then you're beginning to apply business value, right? But then the real place where you begin to thoroughly move yourself up the value chain is spotting those gaps. A business analyst or whatever is the one defining the products, giving you a spec that you're going to implement into code because they know things about the business that you do not. But you have to realize that you know things about the application of technology that they do not. And if you start bringing that to, like, business problems and, you know, being able to solve business problems that they haven't anticipated or they assumed could not be solved, and to start bringing that immediate business value right away is that two. And then the trajectory goes upwards from there because then it becomes less about reacting, more about anticipating. And then when you're not going beyond anticipating, you become part of the process of designing. And then when you become part of the process of designing, you become part of the process of expanding and that kind of stuff. And now you've gone from somebody who turns coffee into code to somebody who understands the business, projects, things that the business needs, works with the business experts to be able to bring your technological expertise to solve those particular problems. You know, those are like, generally the steps of moving up the value chain. Like, you know, people, a lot of people do it throughout their career, right? You know, as a coder anyway, they move up into architecture or ops or they move up into the management side of it. But I think it's something that's unfortunately going to be beholden on all coders, because if you only ever stay at those lower levels of the value chain, you're more easily replaced by an AI model.
B
So I guess kind of bringing that full circle. If you were to give advice to younger folks who are just getting into a career in computer science and development, would you tell them to steer clear and, you know, go get a philosophy degree or, you know, you know, informat bioinformatics degree or something? Or do you see it as still a discipline with a bright future, career wise?
A
I see it still as a discipline with a bright future, career wise. I do see, though, that we probably have to temper expectations that we did have an age of excess abundance for coders where companies bent over backwards to hire engineers, that that age is now gone. So if you're getting into it expecting to walk out of college into a job that gives you Free laundry and massages every day. That's probably not going to happen anymore, but it's still going to be a very valuable and enriching and rewarding career. The one thing I would encourage is if you are, for example, going into studying to maybe do a split major to study software engineering with something else. My undergraduate degree was computer science and physics, and I think that's one of the things that helped me throughout my career to actually have an understanding of something outside of just the software engineering side of it. I did a lot of my physics work. I was ahead of a lot of my competition in my labs because I could actually write code to solve some of the problems rather than doing it all on paper, stuff like that. And it really helped me a lot. And so I would say if you are getting into the field to study, don't be afraid. I think it's as good as it's ever been for you to have a productive career. You may not have all the fringe benefits that used to be there, but they were fringe benefits. They weren't the real core part of the career. But if you really, really want to be valuable and develop those skills to move up the value chain that I've been talking about, then maybe a split major with something else. I mean, I think that's always been a good idea. But to be able to do that now, I think it's equally good and it may equip you better
B
from, I guess, a human perspective. In the world of certainly software development, there's been the adage for as long as I can remember about the Myth of the 10x software developer. And I'm curious, with some of these tools now, Lawrence, are we going to end up in an age where AI is a great equalizer, or is it going to make the rich richer and suddenly we have the best who are now 100x or a thousandx better?
A
Oh, boy, that's a great question. I think the fearful part of that one is when you use a phrase like the rich get richer. Right? Because I think if wherever you are on the line of advancement, I do believe that the further you are up that line, the more advanced and more things that, you know, the benefits of using these things are greater. However, you don't stay at that one point on the line throughout your entire career. Right. You know, the ability to move up the line, you know, to become better has also accelerated. You know, the ability to be a junior engineer and become a senior engineer, you can probably do that much quicker than ever before.
B
Right.
A
So it's like it's not a static place that you're at that gets multiplied less if you're further back and multiplied more if you're further up. But it's your ability to move up that value line has accelerated as well. Right. So there's a double acceleration, if you want to call it that. Right. So X squared rather than X or A squared rather than X if I go back to the Newtonian mechanics for a moment. So I think, you know, there's the most important thing I honestly believe is attitude. Right. Think about it in terms of an airplane. Altitude is how high above the ground you are. Attitude is whether you're climbing or diving. So I think in a similar term with the idea now of AI tools being able to make you far more effective, where you are today is your altitude. Your attitude is going to change whether you're going to climb or not. And these tools being out there are the things that will make you far more effective at climbing more quickly. And don't be fearful of this person who's two years ahead of me is going to be 10 years ahead of me next week. You know, don't think in those terms at all. Just think in terms of your own attitude.
B
I really like that. And it's much more optimistic than I think the alternative. Yeah, I want to shift gears for a minute and talk about some specific technology, I guess because we've been talking a lot about AI, broadly what it can do, what some of these tools can do. We haven't talked specifically about agentic AI, which is, you know, one of the hyped up technologies du jour. And nothing we've described to me necessarily requires agentic AI. Agentic AI being, you know, actually having functions and processes run entirely, you know, without kind of human intervention in my books. I'm curious, Lawrence, what's your outlook for agentic AI versus some of the other technologies and use cases under the umbrella.
A
So I mean, I would do a minor correction there, like, you know, I do believe human outlook is still necessary for effective agentic AI. You know, I don't think an automated pipeline without any kind of oversight is as effective as people might think it is. I think we always need human oversight, if for nothing else. That word that we all love, hallucinations. Right. And I think the important thing is like, let me boil it down to what agentic AI actually is so that we can understand it. And I like to think of it as a four step process.
B
Right.
A
The first step is, you know, we want to understand the intent of the User. You know, any kind of input that you do in any kind of application today is you're forcing the user to express their intent in a way that the computer can understand. You're typing your username and password in, right? You know, you're using TurboTax. You're typing in like, you know, these numbers that come from your, like, from your various documents around tax. So you are being forced to tell the computer your intent. Exactly. Because the computer doesn't have the ability to abstractly understand your intent. One of the things that AI gives you is the ability to abstractly understand the user's intent. So say, take for example, I'm building an agent to help me find a place to eat tonight. I'm traveling somewhere, I want to find a place to eat tonight. And I say, I would love to eat okonomiyaki, right? You as a human, you probably go, oh, okonomiyaki, that's Japanese food. I can tell you a Japanese restaurant, but I didn't say anything about Japanese food. You have the knowledge of that computer program doesn't until AI came along. And now it can start to understand intent. So that's the first really valuable part of an agentic system is whatever input I give I as a human, I'm not forced to give it something that it understands. It understands me instead. So then the second part then is to make a plan, understanding the tools that are available to the agent. So for example, if I'm building an agent for the scenario that I just mentioned, the tools that it might have are Google map search, Google search, maybe understand my location from my IP address and stuff like that. And it makes a plan. So then the AI would go, ah, the intent was okonomiyaki, that's going to be a Japanese restaurant. I have these tools. I can search for Japanese restaurants, I can find the website, I can browse that website, I can see if they serve that thing. And then I can find okonomiyaki for him. So that's making the plan. Then the third part is executing the plan. And that's where it writes the code to do all those APIs that I mentioned, Google map search, web search, and all that kind of thing. And then the fourth part, when it gets those results is it reflects right? So it goes, I found all these things. Did I meet the user's intent, yes or no? I found him sushi, but I didn't find him okonomiyaki. I gotta go back to step two and do the whole thing again. So that ultimately is how an agent works. And that's what an agent is all about. And it's really powerful and really useful because it can take something abstract, like my intent to eat okonomiyaki and turn it into maybe make a reservation at a restaurant for me. And this is why agentic software development has become so exciting and so powerful. It's all of that abstraction that a programmer doesn't have to think about while giving an improved user experience. Now, are they going to eat the world? No, they're not. If I go back to my two categories that I mentioned, taking existing processes and making them more efficient, or coming up with entirely new scenarios, you can see how agents can be built to fit either of these, particularly the second one, because of all of that abstraction that can be baked into it. So those are the agents that we're seeing today. And those are the agents that are getting particularly exciting where it's like entirely new applications that weren't feasible are beginning to land because of this agentic loop that I just mentioned where I'm beginning to then see the next step for this. And again, thinking in terms of engineers and developers now, what if instead of just having this loop that you have a number of models that are fine tuned expert models in a particular thing, right? Hey, here's a fine tuned expert model in international cuisine, here's a fine tuned expert model in whatever, you know, talking on the telephone to somebody and being able to orchestrate these things together as tools instead of just the APIs like a Google search and all that kind of thing, that's where now intelligence will be building on top of intelligence and networking other intelligences together to build really powerful or super agents to be able to solve a problem. So yes, I'm really excited about it. But if I try to boil it down and use the electricity paradigm that we spoke about earlier on and let it fade into the background, ultimately it's a new design pattern for building applications based on understanding of what these things can actually do and solving a real problem. And the biggest real problem I think that they initially solve is understanding a user's intent, which is a very difficult problem to solve when you create a user interface.
B
So with that in mind, coming back to, I guess some of the lens we were using earlier around larger models and smaller models, there's a number of different ways that an organization could potentially implement something like this. Whether they build it themselves or they source it from one of the large AI players, or they try and source it from an existing, existing enterprise technology vendor, or they find a smaller fit for purpose One that they sort of modify. Do you have a sense of where this is going to be most successful? And I guess if there's a wrong way to do it, I mean there's
A
probably going to be a bit of all of the above, right? I think, you know, the wrong way of doing it is. The first thing I would say is like we've always done it this way, so we're going to continue doing it this way by adapting it. I think that's probably the first step in the path to a wrong decision. I think being open minded about how you would solve a particular problem without thinking in terms of how you've done it previously is probably the first step towards making the right decision. I do think though, when we talk about growth, the easiest growth to do is to go from zero to something, right? It's hard to go from 99% to 100%, but it's easy to go from 0% to 1%. So then I would start looking at, well, what are the things and what are the things that just don't exist yet but could exist in that time frame and in that model, excuse the pun. And I think that a lot of that is the creation of fine tuned models for specific tasks. I mean, at some point I think we're going to have a catalog that we can look up and go, here's a model that's fine tuned for talking on the phone to make a restaurant reservation, right? Here's a model that's fine tuned to understand the ins and outs of Japanese cuisine. You know, I mean, I might be getting a little too granular there, but I think you see where I'm going and then being able to take those and orchestrate those together as part of an agentic or any other workflow. I mean, I think that's a, that's a domain that just simply doesn't exist today. I mean it's close to existing in things like hugging face, but you know, to be able to take off the shelf ones with a licensing model, with a, you know, the ability to, with you know, the indemnity and all of that kind of stuff, to be able to include it into your applications, that is in its infancy at the moment. But I see that's something that's going to grow and I think that's going to be a rapid area of growth and I'd be really excited to see who's doing anything in that space.
B
Well, and I'm curious too, just, you know, kind of speculating, but whether you think we're going to continue to see a fragmented landscape there. Or you know, something I could easily see is, you know, one of the Googles of the world saying we want to own this space for, you know, every conceivable, you know, kind of consumer pattern that we can think of. And they start to, you know, build out or purchase all of these, you know, potential smaller or more focused models. And it becomes a point of competition among, you know, the big tech consumer players.
A
I mean, that's an interesting view. And maybe I find like if you look through history, particularly in tech, there's always been a duality, right? You know, I'm a Mac, I'm a PC, you know, Java or net, you know, TensorFlow or PyTorch, you know, that kind of thing. And I see like, you know, that bifurcation happening is like, at least when it comes to models, it's going to be the large versus small, right? And then, you know, the nice thing about the small is that it could be a massive, widely open ecosystem where there will be some players who want to control a large subset of those models and build their own. But there's no reason why there can't be independent or smaller players doing it. I think of something like an App Store. Today you can go to the App Store and if you're looking for a note taking application, there's going to be some giant companies who've created note taking applications and there's going to be some plucky young upstarts ones that have made these massively disruptive note taking applications. And there's no reason why the model scenario can't be the same. The nice thing about openness and open weight models that can be fine tuned by anybody is that you can't have one person dominating the entire game or one company dominating the entire game because you can have those plucky little upstarts who are fine tuning a thing and you know, the old adage of, you know, it's much harder to turn the Titanic than it is to turn a speedboat and you know, the advantages that the smaller companies would have will come into play there. So the scenario that you mentioned, I'm not really that worried about.
B
Interesting. I am finding we've spent most of this conversation talking about, you know, models and the application layer and development. You know, you've had a shift fairly recently in your career where you're now working with ARM and you're more sort of at that, you know, semiconductor or you know, the hardware layer there. What's going on in that space and what excites you about, you know, the future there?
A
I think what excites me about the future with ARM in particular is, you know, the whole leadership thing that I've been talking about is something that they're exemplifying, that they're looking at cutting through a lot of the hype around things to see the real business value. Like let me give one example. We spoke a little bit about agents earlier and then ARM recently released something called the AGI cpu. And the idea behind the AGI CPU was a realization that if you're building an agentic system, very little of that system is actually the stuff where the model is that's consuming or generating tokens.
B
Right?
A
You know, I spoke about like the part where it understands your intent, that's consuming and generating tokens. And I spoke about the part in phase two where after it's made a plan that it's going to kind of generate code to execute on that plan that's consuming and generating tokens. But if you look at that big diagram, a lot of that is traditional compute that needs a cpu. And that's the whole idea of like the ARM AGI CPU was to create what can we do to put into data centers for enterprises or whatever to be able to have these agentic workflows, but to be much more efficient in how they run, to be able to run as many workloads as possible on low energy, low cost CPU and then offload the stuff to high energy, high cost GPU only as appropriate. And it's that kind of vision I find particularly exciting. And it's that kind of thought leadership I think that I find really exciting. And then the other one and one that I'm working on is called SME and it's same logic, it's called scalable matrix extensions. And the idea behind SME is that like, well, if you're using a phone, right, you know, your phone is usually disconnected from power, so you're relying on your battery. And if you want to do artificially intelligent workloads, they are computationally very expensive. And as a result they generally need something like a GPU or some kind of accelerator chip on which they run that draws a lot of power, that draws down your battery. It's one of the things that's caused AI on phones to generally lag, right? You know, they can do simple things like photographic AI and the like. But what if you build directly onto the CPU which is already there and sips power instead of gulping it? The ability to offload some of this computationally expensive stuff. And SME stands for scalable matrix extensions and that's something that's been built into CPUs that are on some phones and obviously it's becoming increasingly more common. So it's that level of that forward thinking leadership that got me excited about ARM in particular and why I joined them and then working on those types of projects to see what we can do to make AI more prevalent. And go back to my two scenarios, right? Things that were previously infeasible, like being able to do AI on a phone because of the cost of running a GPU on a phone, are now becoming feasible because of that type of thinking.
B
It's so interesting and it's just as I sort of reflect on this conversation, we've covered so much ground and there's so many different themes and pieces of advice that have come out. Lawrence, thinking again to an audience of business leaders and technology leaders, is there anything we haven't covered? Or what do you consider sort of your top advice right now to actually get value out of this technology and make sure your organization is ready for tomorrow? What would that be?
A
Oh, wow. I think we've probably covered most of it, but I mean, if I were to condense it, I would say the best way to get value out of this technology is ultimately to deeply understand what it is and what it is not and to make your decisions out of that clear understanding. There is so much disclarity. Is that the right word? There's so many opaque thoughts out there and there's so much hype and noise out there that it's easy to be seduced by it. Those decisions that you make based on firmly understanding of it are not going to be easy decisions, but they're going to be the right decisions, at least coming from the right standpoint. I'm dismayed by how many wrong decisions I've seen made because of hypo, because of reacting to a trend. And so I'd say that would be the one thing that invest in understanding the business impact, the technological impact. Listen to your cto, listen to your engineers, those kind of things, and listen to the people who really, really, truly understand what's going on with this technology and who aren't seduced by the hype.
B
I love that answer and I think it's very on theme with what we've been talking about. Lawrence, just before we wrap up here, is there anything we didn't cover in this conversation that you were hoping to talk about?
A
There's one thing I would like to bring Out. Yeah. And it's a particular passion of mine and that is really around. I've forgotten the word now.
B
Sorry.
A
I say it's a passion, but it's sovereign AI. I guess what I'm thinking of, that sovereign AI is becoming increasingly important. But if I talk about the misunderstood part of it, that it's only, I think, partially understood. And when we talk about sovereign AI, if we read articles about sovereign AI, it generally falls down into country X, wants the data from that country to be in a data center in that country, the end. But that's just the beginning. And I think there's really, really important opportunities again, going back to engineers to do things that are really good when you fully understand the implications beyond that. And if I go back to fine tuning AI as an example, think about education today, how an AI model is trained. A large AI model is trained on masses of data from the Internet and from other sources. And then that's pre training and then it's post trained with the values of the company that's actually training it. There are safety filters, what they consider to be safe, their values, those kind of things. And it's really condensed into the world of models is models with the safety and sovereign values of San Francisco or models with the safety and sovereign values of China. I'm not saying either of these are good or either of these are bad, but there are only two locations. And if you are creating, for example, a solution for an education system in Ireland, right, You have to realize that this thing has been trained with the safety filters and the values of San Francisco, and they're not necessarily your values. And that's part one. Part two is even if they don't have those safety values applied to them, they are also trained with statistical relevance in mind. I always like to tell this story. Have you ever been to London, Jeff?
B
I have.
A
If you go to the Houses of Parliament in London, right outside the Houses of Parliament is a statue of a guy called Oliver Cromwell, right? They put a statue of him there because he was the guy that led part of the civil war against the Crown that brought democracy to the uk and the Houses of Parliament are part of the democracy. Right next door to the UK is the country of Ireland where I grew up in. And the town that I grew up in called Drogheda, has a street called Scarlet Street. And the reason why it's called Scarlet street is Oliver Cromwell's victims. You know, so many people were murdered by his army there that their blood flowed down the street. Okay, so now if you Train a model on data and you look at statistical data, you're far more statistically likely to have stories about Oliver Cromwell being a father of democracy, because the UK is a much larger country than you are to have stories about Scarlet street in Drogheda because it's a small town in a smaller country. And now if you are building an education system for Ireland, right, and you're using AI for building that education system, you are swimming upstream against the values of your country. And as a result, you know, it begins to negate a lot of the usefulness of AI doing it. The big problem is awareness of that, right? Because it's like, you know, sovereign AI is generally, like I said, data center data in a particular country. But now it's a case of as we start infusing AI more and more, it becomes electricity, fusing it more and more into the background life, for example, for things such as education, there are problems like that that need to be solved. My way that I'm going to argue of solving them is using small AI with open weights and fine tuning it on your specific thing. So if I'm creating a syllabus to teach history in Ireland, I, you know, as part of the Irish Education Board, have all of these materials that are my syllabus that I teach the way that I want to teach it, the textbooks that I trust, the research that I trust, the values that I want to impinge on the people in my country, you know, those kind of things. I need to fine tune a model to do that. And I can't rely on something with San Francisco values and the statistics or something with Beijing values and the statistics. Again, no offense to either of those, but it's just not my country. And as a result, the opportunities there in sovereign AI, as AI fades into the background, are becoming endless. And I think back to my model of things that were previously infeasible. Now, those are things that are not just feasible, but massively valuable. And I would just encourage anybody out there who's listening, who's in this space, or if you have all of this type of data that the opportunity's there for you to build something that's meaningful and impactful are huge.
B
I find that extremely interesting and compelling. And I'm sure, you know, it's one example, but I'm sure there's a million examples around the world of that. But let's stick with this one for a minute. So if you're on the Board of Education in Ireland and you want to actually do this, and you're concerned about the San Francisco models and you're concerned about the, you know, the Chinese models. Where do you start? Are you necessarily condemned to starting with a blank canvas here or what foundation do you draw from if you want to make sure that you're going to end up with a model that has Irish values?
A
Right. So the first question becomes do I use a large model that I have no control over and then start doing exception management with that model? Right. Or do I use a smaller model that I do have control over and I can fine tune understanding that that small model, you know, is not going to have my values baked into it?
B
Right.
A
You know, it's still going to have post training done. You know, Google have the Gemma models, San Francisco OpenAI have the GPT OSS San Francisco, China has Quin and other models like that Chinese value. So I'm already starting from something that's been posted trained to somebody else's values, but at least I can overwrite that. So the question becomes do I create using somebody else's model and it becomes a process of exception management or do I create using an open source model and build on top of that? Or the third choice of course is do I train my own model from scratch? Training my own model from scratch is probably too expensive to do right now and maybe there's not enough data to be able to do that. So if I'm in that role at the moment, I'd say I can't do option number three today and that means option number two I find is the most attractive. And then going back to what I was talking about, fine tuning models, it becomes then a domain problem of like, I have all of this data already, I have my syllabus that I want to teach already and textbooks and in research and in policy papers and that kind of thing. Now it's a case of me taking that and formatting it in a way that a model understands so I can then fine tune a model. And now I will have a model that has become a domain expert, expert in my syllabus that I want to teach. And it's not perfect because the foundation is already, you know, a model that's been post trained on somebody else's values. But then at least you're overriding that with your own values and your own details and that kind of thing. And that would be the path that I would probably choose in that case. But it would require a lot of evaluation to be sure, sure and well.
B
And I like that because again, it walks the middle line, right? It's sort of the Goldilocks model, so to speak, between going with the large model and the completely DI model.
A
Yep.
B
Lawrence, I wanted to say such a big thank you for coming onto the program today. We've covered so much ground. It's been really interesting and insightful and I really appreciate your time.
A
Thank you. It's been great. Fun interview. Thank you so much.
B
Jeff Most viewers don't know this, but Digital Disruption is developed by Infotech Research Group, a leading advisor to technology leaders around the world. If that's not you, you don't need to care. So skip ahead and enjoy our content. But if you are a technology leader, Infotech helps IT teams get projects done faster, better, and at a lower cost. Infotech provides unlimited access to practical tools and expert guidance. You need to execute at a fraction of the cost of traditional consulting, no matter the project. From AI strategy to cybersecurity to vendor negotiation, InfoTech has you covered. Check it out at the link below. And don't forget to like and subscribe. Subscribe.
Date: July 20, 2026
Guest: Lawrence Moroney, ex-Google Head of AI Advocacy, Director of AI at Arm
Main Theme: The true impact of AI on software development, enterprise productivity, and the hype vs. reality of the Next Industrial Revolution.
In this episode, host Geoff Nielson is joined by Lawrence Moroney—renowned AI researcher and former head of AI advocacy at Google—to cut through the noise of AI hype and explore what AI genuinely means for the future of software development and work. The conversation is an honest, practical look at AI's integration into enterprise environments, the limitations of "vibe coding," and the critical skills coders must develop to remain relevant as technology changes.
Timestamp: 02:08-04:44
Timestamp: 04:44-10:56
Timestamp: 12:29-16:16
Timestamp: 16:16-22:21
Timestamp: 22:21-29:45
Timestamp: 29:45-32:10
Timestamp: 32:10-37:19
Timestamp: 37:50-41:57
Timestamp: 41:57-47:09
Timestamp: 47:09-51:20
Timestamp: 51:20-57:07
Timestamp: 57:07-61:46
Timestamp: 61:46-65:19
Timestamp: 65:19-66:53
Timestamp: 67:05-74:41
| Segment | Timestamp | |-------------------------------------------------|---------------| | Navigating AI hype cycle | 02:08-04:44 | | AI in practice vs. promise | 04:44-10:56 | | Media hype, sensational stories | 12:29-16:16 | | 100% AI-written code & coder value chain | 16:16-22:21 | | Ephemeral code: meaning and impact | 22:21-29:45 | | Vibe coding & coderless futures | 29:45-32:10 | | Small, fine-tuned models | 32:10-37:19 | | Organizational strategy: more engineering | 37:50-41:57 | | Moving up the value chain: coder advice | 41:57-47:09 | | Future of comp sci/software careers | 47:09-51:20 | | Agentic AI: intent, orchestration, reality | 51:20-57:07 | | Model ecosystem, openness vs. consolidation | 57:07-61:46 | | Hardware innovation at Arm | 61:46-65:19 | | Condensed advice for leaders | 65:19-66:53 | | Sovereign AI: cultural context in models | 67:05-74:41 |
Summary prepared for listeners who want actionable insights and the essence of the episode without missing key nuances or technical depth.