Latest / Architecting the AI Enterprise / Episode 1: Architecting the AI Enterprise

Transcript

Episode 1: Architecting the AI Enterprise · Architecting the AI Enterprise

• Marketing: Welcome to Architecting the AI Enterprise. We are all reading the hype and the news these days of everything from how is AI going to transform the people, the code, the processes, the applications, your expenses, the businesses. We are here to bring leaders, real amazing technology leaders to the table to help us answer these questions. What's working? What's not? What are they doing about this? What are they piloting? What's in production? And most importantly, where they see this going. I am Gary Huberman, CEO founder on Quark. With me today, I have our CTO head of AI, Dave Frucci. Dave, just quick intro. We're going to get into the details in a minute, but please just introduce yourself. Yeah, great to be here. Great to be doing this with you, Gary. So I've been in AI really, you know, for a long time, for my whole life, my whole career, starting actually early when in college being inspired by computers and their potential. And I've been in the AI field ever since. I think I spent most of my career at TJ Watson Research Center, IBM, working on all sorts of different research projects and AI projects at IBM, ultimately culminating in creating Watson, the natural language processing machine that beat the best at Jeopardy. Since then, worked for Bridgewater, I had my own company, Elemental Cognition, and now it's exciting to be helping Unquirk. kind of enter the age of AI in, as you mentioned, Gary, in a field now that is moving so incredibly rapidly. And it's just exciting to have been part of it for so long and to really be in this time where no one ever expected it would accelerate this quickly. You know, what's interesting is when you look at this and Our backgrounds are fascinating if you map this out in like some sort of charter or graph, or maybe we ask AI to do it for us in a visual. You came from the research side and yet you, and a lot of research projects, I've been to IBM's research center and a lot of research projects don't ever see the light of day, much less see major TV. And that landed you not just on Lex Friedman and other shows, which I've watched you on. But it literally brought AI to the forefront where I remember driving into the tunnels in New York City and you'd see Watson everywhere back in the day. Still today it's there. And my journey was the exact opposite, which was, you know, we've got a budget, we've got to build ⁓ a CRM system, we've got to build a trading platform or money transfer or like, and how do we do this with these constraints? And I always felt like I was that old show, which most people won't know, was, you're going to give me, Language to use, you're to give me some small hardware in a box and let's going to go build this and it's going to work. I was climbing up the corporate ladder on wall street on the, on the CIO front. went from the research side after Watson to Bridgewater. So here we cross over where we're both in the corporate world. And then we both left the corporate world to create startups, which is amazing. that's, that's, and then after that we're both here. So it's really an interesting story. I we have very aligned views yet different views. We're to get Dave's opinion on, you know, what's real, what's not. My opinion is all around this concept of how do you manage an enterprise technology team? And what I mean by that is engineering's fun, coding's fun. You know, everything's great until you threw it over the wall and now it's got to run and maintain. And when you move up that ladder in corporate world, and I was managing about 2 billion a spend before I left it every year, what you realize is. It's a mess and it's just every single line of code ever written becomes your nightmare, your pain points. so, you know, it's fascinating as we're going to go through this and I'm hoping you're going to hear it literally divergent viewpoints. so some we definitely align on what I will tell you about Dave is when I met Dave the first time at his company, Elemental Cognition, I saw something I'd never seen before. A AI tool that could be used in heavy regulated markets, explain what it's doing. repeatable, not sensitive to model changes or any inputs or variables and something which you could use in insurance or banking and onboarding and underwriting. And that's how we started to get to work together. At Oncork, what Dave did was come in and basically say, we have to rebuild ground up AI first. And it's amazing to think that like, that's what we've been achieving the past several months as we're getting ready to launch. This is the one episode I get to talk about on Cork With You, Dave, because every episode after this is really going to be about our guests and bringing them in and you and I interviewing them to figure out what they're seeing is real and how is architecture important to them. I'm curious if you could share a little bit about the probability of success, the ⁓ fight to get it to go live in a way that you had the passion to see this through. Also, the risk taking you did. which is very unusual from a research point of view. got to say, like, I don't know, but if you could share that story, that would be awesome. Yeah. I I think, I think first of all, the Watson project, you know, started off as this desire for IBM to do something exciting, something that would win the company a lot of attention and very sort of concretely, they got so much publicity from creating the deep blue, the machine that beat Gary ⁓ Gasparov at CHESS, Gasparov. And that just got them so much attention to be at the leading edge of things like that in the area of artificial intelligence. I think it was eight or nine years after that, they thought, what's the next big thing to do like that? Meanwhile, I had been working with my team. in a research capacity in the area of natural language processing and in the area of what's called open domain factoid question answering, which now we kind of take for granted, although facts aside or accuracy aside, we kind of take that for granted for LLMs, but it wasn't 15 or even 10 years ago that achieving any kind of accuracy, even on basic factoid questions was somewhere in the 30 % range. And then when you added the linguistic complexity and subtlety of jeopardy questions, that went way down. And then the other big challenge that we understood from a research perspective, not from a business or marketing perspective, but from a research perspective was predicting your confidence, the likelihood that you will actually deliver the accurate answer. was also very low at the time. And this was an active research area. Many universities, many companies were trying to do this. Somewhere around consistent 35 % accuracy on much simpler questions with really very poor ability to predict your confidence, the likelihood you'd get it right. So this was a big challenge from a research perspective. But to your point, like from a business perspective, it was really about bringing Lusser to IBM. Can IBM get out there, do something public? do something that we would actually get on television for and excite people about the, excite the world about the people at IBM research, what they're capable of, what it means to lead and be ambitious in a field. I was the only one at IBM research who thought we could do this. Now I had the advantage of having led a team in this area. I knew what the challenges were. I knew what the possibilities were. Everyone thought it was impossible and that I would fail. So there was Career risk in some sense. mean, you know, people took that seriously, me not so much. I was much more interested in the technical challenge. What can we do, you know, given the resources? But to your point at the beginning, no one really knew. So IBM invested, you know, I'll generously call it like incrementally, meaning, you know, we'll give you some money, see what you can do. We'll start working with the Jeopardy team and shape this project as we go. But we did get to a point where I was demonstrating real progress and the executive team at IBM said, look, this is interesting enough. This is already very impressive. Even though the chances of winning at the time might be 50%, it's such an exciting area. Let's just go public with this. And at that point, once we went public, sort of the floodgates opened. And at IBM, it was, you know, don't say no to Dave because it's all on him. So you had to put your neck out. 50 % is not a big chance to win, by the way. No, but you know, the trajectory was good. then around 2010, early 2010, when it started to go much more public, You know, we were up there in the 60 60 % range. We ultimately played the game or I should say 65 to 70. We ultimately played the game because as you achieve greater accuracy and greater confidence estimation, like eking out those percentage points was much, much harder. So, you know, there were low hanging fruit at the beginning, but then it got harder and harder. We ultimately got to around 75%. accuracy with very good concept confidence estimation. had real probability. So once we saw a question, we would be able to tell the chances very precisely the chances we had of getting that right, which was a very cool part of the project. So we'd know whether or not we should buzz in or not buzz in or depending on the game, where the game was, we would calculate how much risk we wanted to take. And even if our confidence was low, but we needed to get ahead, we would take greater risk. and buzz in for that question. So it was quite a sophisticated system. When you think about where we've gone and how quickly things have accelerated since then, because this was the very early days of deep learning, only the ancestors of transformers, the basics behind large language models were just very early research papers around that. And then that took off so rapidly. Now we have large language models. It's very interesting to compare the architecture of large language models with Watson. Large language models are so elegant and so effective managing and dealing with language and other artifacts like images and music. There's such powerful learners. We didn't have that at the time. But anyway, things are moving very, very rapidly now. Yeah. mean, around the same time, 2009, 10, 11. ⁓ I was MD at Citi at that point managing a team of about 500 engineers. The project which really got me excited in that way, which doesn't sound very exciting, was we had built a platform called Grand Central, which was being used by like a thousand apps. We built another platform called Q-Tips that I named. I forgot the acronym, but it's spelled like the Q-Tip and it was about getting wax and bureaucracy out of companies. similar to Uncork's definition of Uncork, the bottle, get out the broke. I remember I didn't support HR. I was in the business. I was building business facing systems. head of HR came to me for Citi and goes, we need to redo our compensation systems. None of the vendor products work that we have and we need to build pay for performance for the OCC and the regulators. Could your tech do this? And in 30 days, one of my platforms rebuilt Citi's compensation system, which was I mean, we had more departments than people in the company. You know, like that's kind of the structure. It's almost more than a one-to-one, which makes no sense, but that's what the structure was. Cause you had, you had basically people reporting into multiple managers who decided there. And it was not an AI problem. It was a deterministic, pure data problem using XML at the time. Not even JSON, but we did it in 30 days and it became the actual core system of record for, for comp. It's such a different world you're playing with. It's so interesting because one of the things when you look at what happened with Watson, you know, because after we built Watson to one jeopardy, mean, I was only at IBM for about another year and a half. One of the things that was happening inside the company is so fascinating, which was the move or the expectations around going from deterministic programs. You know, if you gave it, if you gave it your social security number, a hundred percent of the time, it got your name right, right? Like this is basic transactional systems, fundamentally deterministic. Everyone expected 99.9999 % right. ⁓ when you move to Watson, in spite of its confidence estimation, where it would be able to tell you, you know, on this data set, statistically speaking, you give me a question, I could tell you I'm 70 % sure in this answer. If it had to answer questions it was 70 % sure of, it would get 70 % of them right. So was that confidence estimation mapped to a real probability. That is so, that kind of thing is so accepted now with large language models. That notion of probabilistic estimation of things. But at the time that was shocking. Like, what do we do with that? So, no, at one point in one project, you someone's, you know, because once these things take off and customers start bringing their deterministic expectations to essentially a statistical probabilistically driven system, they start saying, what do you mean it's not right 100 % of the time? And so you have people saying, Dave, you got to stop with that. probability stop. I just need it to rewrite 100 % of the time. it's not real. You know, it's the fact that it can accurately estimate his confidence was extremely valuable, but just not what everyone expected. And my point is, it's so interesting. went from customers in some sense saying, it's really cool that it weighs different answers. It's really cool that it can balance the statistics and probability of something being right. But then when you go to deployment, they say, I want it to be right 100 % of the time. But what's interesting is how much that expectation has now changed. Cause now we have AI agents, you know, threatening to run entire enterprises where nobody can tell you what the exact probability is any of this stuff will actually work and be right. And yet we're doing it. this is the question. So What would you in an enterprise like Bridgewater where you are, I'll talk for Citi MetLife, what percent of businesses do you think are deterministic versus probabilistic and have a risk reward there? I'm just curious like what you've seen. It's interesting because I think in some sense when you get to the really hard problems, they are statistical in nature and they are probabilistic in nature. And you know, it's just that we're so used to deterministic systems and very low error rates. And many tasks, I guess you could frame it in terms of companies. Like if you take a hedge fund, example, a hedge fund is very used to living in the world of probabilities and statistical variance. And it really is all about understanding what that risk is and then deciding, you know, whether you want to make that bet. Everything is seen through probabilities. Other industries, accounting, finance, obviously, it's very different, right? I expect this to be exactly right. And I expect it be exactly right every time. And I want a deterministic explanation for why I'm making this decision, that decision. So when you see things regulated from a safety perspective, from a risk perspective, from an accuracy perspective, so clearly hedge funds trading is a whole different ballgame. But what's I think surprising is healthcare is probabilistic. People don't think it that way, but that's the reality. This drug works 75 % of the time. Yeah. The disclaimers on TV. or two percent of the time, it has an adverse negative reaction. Yes. Yeah. That's a good analogy. That's, you know, it's interesting because most of the businesses I faced off against were deterministic. And it's just, the problem was more documenting what they did was a problem. Getting it down to a place where you could take the run book and execute that and, you know, translate that run book into a procedure versus, you know, someone's mind and how it's working. today, you know, think about agents today. So agents today are all around either generating code or executing a process and the highest level, right? There's two. And they're really one and the same. When you think about like agents executing a process, like it's amazing for something which is not life or death, I would say, or something that will be checked by a human. All the variables that go into that agent, the models, the inputs of the models, the operating systems it runs on and all the, you know, connections and integrations back to the core. To me, it feels like the day of like, I remember getting calls that the, the trading app went down because someone kicked the plug in the data room. You know, it kind of brings back memories of that in some ways, which is all the variables that could go wrong if the server is running under your desk in some way, or form, as opposed to in a sense. mean, look, I mean, I think this framing is very interesting because I've seen people take problems that are deterministic in nature and apply probabilistic methods for no good reason other than not really understanding the nature of the problem. I've often said to people, know, half the problems you're throwing at LLMs, you really should be asking the LLM to help you write deterministic code to solve those problems and not actually throwing them at a probabilistic system, which is very interesting in the role LLMs play and the role AI plays in different problems. And you see problems, for example, are, in fact, this is one of the things elemental cognition did, which You see problems that are fundamentally constraints solving problems, optimization problems. These have, you know, there's a set of constraints. There are algorithms that deterministically find optimal solutions. There's no reason to make this a probabilistic problem. But if you don't understand what you're doing and you make it a probabilistic problem, you end up having errors when you don't need to have errors. And sometimes I You know, refer to that as you're brushing your teeth through your ear. mean, you're getting there, but you're really getting there in a painful and error prone, painful and error prone way. There's a much more direct way to solve the problem. So, ⁓ looking at problems in terms of whether they're inherently probabilistic in nature, like predicting markets. And when they're inherently deterministic in nature is just a powerful lens because getting that wrong. is leads to unnecessary risk. And so when we think about the role of AI Asians, how often are we experimenting with the AI to really just understand a deterministic process? Right. And at what point should we admit that that probabilistic exploration of that space should actually then turn into a deterministic workflow? which could be monitored, audited, observed, maintained, consistently applied throughout 100 % accuracy. The power of the, of the generative nature of LLMs like generative AI is they can quickly search and prune a space that what might be very difficult or tedious or overwhelming for humans to try to tackle that because they have an enormous body of knowledge. that is encoded in these statistical models that allow you to do this sort of smart generation. Like this is a statistical variant that's consistent with the prior data. It's not necessarily right. It's not necessarily exactly what you want to do, but I'm going to allow you to search that space very rapidly. But then at some point, you really want to, can you tolerate, can your application tolerate the risk of it potentially being wrong, especially when it's taking action? Right. People always say, well, what if AI takes down the electrical grid? Well, don't give it control over the electrical grid. So, you know, there's, there's this notion of exploring and understanding and hypothesizing, and then there's notion of this taking action. And then you have to understand when you take that action, what is that risk? Do you understand the nature of the risk? Is it asymmetric? Is someone going to die? Are you going to lose a lot of money? Right. So there's a step of accelerating the exploration, accelerating the decision making. What is your, what is your decision flow chart? And then actually putting in an action as a deterministic process. let's Dave, like let's bring it to Uncork for a second. So there was a moment over a year ago, even more where I reached out to Dave and I said, come join Uncork. The answer wasn't a resounding, of course, the answer was come on board. hard time, see what we're doing, see if you're aligned to the concepts or strategies, but help us advise in AI. And the reason why I reached out to Dave was not just because of what I saw him build, elemental cognition and his background, but because of ⁓ he was building an app in his garage at that moment in time. that's the, it was like you were so hands on using every single agentic tool to generate code and co-pilots and cloud and everyone out there at that point. And you were in that. and using it for your own purpose, which was really cool. Now, what's interesting is when you think about applying AI, I could tell you at that moment in time, I didn't know if AI was an add-on or feature. Is it slapped on top of Uncork? Do we enable others to use Uncork to do this? I was actually not in the spot to say, here's where we move forward. It was, I needed that advice and help from someone who knew it. I'm curious from your side, when you, the first thing you did when you started to get into Uncork and help us was you focused on the word architecture from what we did in the past. And I'm just curious, like, what did you see that was interesting? And then let's talk about applying what you just described, which is where are the agents working today in Uncork? Where's code generation? They've enforced that all developers will use AI code tools to get their work done and help them. Right. And it was not something they were doing before. So I'm just curious if you could share a little bit, let's jump to that and see exactly where that applies. First off, know, this goes back to what you mentioned that when we get started, you know, how our different paths intersected. You know, one of the things that distinguished me as a researcher was I always wanted to advance technology, deeply understand where things are going, make contributions about how to advance them, but I always wanted to realize that. And you're kind of in this middle world between the high-flying researcher and the engineer who wants to make practical things work. And I always sat in that, in the middle of that, in some sense, delivering the Watson project, which was a non-trivial piece of code that we developed over four years, you know, about 40 people hands-on every day for four years. that ultimately worked flawlessly. By the way, it ran in memory. So how much RAM were you running on at that point? 15 terabytes. 15 terabytes of RAM just for those tech geekies like me. Like that's kind of insane. That's amazing. Yeah. And so, you know, in today's scale of, you know, large language walls, that was a self-contained system, you know, something on the order of 2,500 cores, fully switched, meaning fully connected network. And about 15 terabytes of RAM and never went to disk. couldn't afford to go to disk. Wow. At runtime. But yeah, so a lot of complexity came together and it had to be rock solid, right? So a lot of work, enormous amount of engineering, regular testing, thousands of carefully documented and performance experiments. So there was a lot of engineering in all of that. And when you're bringing advanced technology to the marketplace, you can't skip the engineering. So. One of the things I've always been fascinated about and interested in is how do you use AI, the confluence of advanced technology, artificial intelligence, and software engineering. And we're seeing a boon in that today, you know, with AI co-pilots, which are helping you code. But what doesn't escape that, and, know, while the junior coder in some sense is threatened because of how good large language models are at rendering formal languages, and mapping formal structures to intent and English and so forth, trained on billions of coding examples. So they're super good at this. But ultimately where the bottleneck moves from the coding to making hard engineering and architectural decisions. And this is a whole nother ball game. And in some sense, it's so interesting because as coding becomes cheaper, The demand goes, the people come to me and say, Dave, what are we going to do with AI? AI can do everything now. What are we going to do? And it's really from the beginning of all this hype was, you're going to do more. Yeah. You're not going do less. You're do more. Right? This is the famous J-Bond's paradox, right? It's like, so as this resource becomes cheaper and cheaper, the demand to do things that we never imagined we can do is going to skyrocket. It's not like we're going to do less. We're going to do more, but the bottleneck moves and the dynamics change. where the bottleneck might have been on, can't find enough coders to do all this stuff or to work quickly enough. The bottleneck starts to move to while we were able to code all over the place and everyone ⁓ from everyone's a coder. Everyone's development kindergarten CEOs can now write code. ⁓ What happens is now you need an accountable human to say, well, what can I trust here? It's not, it's not about getting that function to work as where does that function fit in a complex architecture that all has to ultimately work together to, to, satisfy a business goal, a business need for the enterprise who makes those decisions and who's accountable for those decisions. Some combinations, some confluence, some collaboration between business stakeholders, architects and senior engineers have to understand ⁓ what all this means and how to govern, control and be accountable for the results. So like the mental model is, you everybody's driving around in golf carts. And there's a few traffic, you know, there's a few traffic cops there directing them because, know, it's all going pretty slow because golf carts are slow. Now you put all of them into F1, know, formula one cars and they touch the gas and they're flying all over the place, covering a lot more ground. And those few architects are sitting there trying to control what's going on are just completely mowed over. it's total chaos. So now we have to start thinking, okay, we can go faster. Our cars can go faster, but how are we now making controlled governed decisions to ensure those business results are delivered with no more risk? Cause we know when those F1 cars are driving all over the place by drivers who are used to driving golf carts. And a lot more of them, by the way, because a lot more of them can drive now. You have enormous control and governance problem. So now it's about focusing next. It's about controlling and focusing that speed. So what do you need? You need guardrails. You need controls. You need governance. You need different traffic rules. You need all the things that are going to ensure that all that velocity is actually directed into the right channels and the right controls. So when you think about what Uncork is about, and one of the things that excited me about your original vision was that the commitment Uncork made early on and to try and to control that. Say you can build applications, but if you build them with this curated set of components and you follow these configuration rules, we can guarantee you certain runtime properties. around reliability, around security, around scale. So that's the right idea. And that's what attracted me to Unquirk. But now that idea has been not only, I think, it's been challenged, but at the same time validated. So it's been validated, my goodness, you you couldn't have been more right about the need for governance and control and for architected constraints and guidelines. and a way to build in order to guarantee these runtime results, this total cost of ownership, this zero tech debt over time, right? These are the things that enterprises absolutely rely on to control costs and control risk. But now it's so much worse with everyone able to code and to code quickly. And absolutely they should be using AI tools. Absolutely. But now, Uncork. has to be reinvented. And we think of uncork AI as a reinvention of that same fundamental principle, but now not controlling the golf, the golf carts, but controlling the, the, the F one formula cars. more of a challenge and more of a challenge, none the less, the right problem to be solving. know, it's, there's a few aspects, one speed, one of my favorite. moments in Oncork was, and it's a craziest moment, was when COVID happened and hit the city. We jumped in with, you know, New York City CIO at that time and said, we could help. And we built the contact tracing system in two days. We built the food delivery system that I think delivered 40 million orders of medicine and food in just five days. We built it from scratch without AI yet. And the reality was it was probably 50 people configuring using Oncork behind the scenes. which you're now replacing with agents. And now the speed of those apps, if I showed one of those apps today to someone and said, oh, I just used a lovable to do that before. Let me show you the prototype where I use Claude and it built it. And the problem is when you're, you know, I go back to the nightmares I had as CIO. When you're climbing up the corporate ladder and you have your career and you're a system engineer, you're going to be a project leader or a tech specialist or architect or like, my dream was always that CIO role. It was like, I always visioned that role as like, I'm in a decision seat. I'm going to make a difference to the organization. going to help people grow. And when I achieved it, what I suddenly realized was it's miserable. It is nothing but misery. And what I mean by that is you walk in and 80 % of your budget is locked away for what we call keep the lights on. that's infrastructure security, compliance, tech debt resolutions, end of life problems every 10 years. it's maintenance. then you go face the regulators and the regulators say, Hey Dave, how secure are you? How compliant are you? Show me your proof. you demonstrate you ethically hack, you know, every app once a year if it's external or twice a year if it's critical and once every two years internal and you fix issues come back, you fix them within 90 days. But you never get to the low issues or the medium issues. You only did the high and critical issues because you didn't have budget or time. when you reality, every time I said we're secure, I would have to like, you know, cross my fingers or something like that because the reality was There's 600 vulnerabilities every week created in the world of hackers. And that was before AI. know, open core, viewing as a mass hacking device waiting to take over all the systems and every, everything out there. You know, when you look at this world, you say you weren't so secure before and you'd have to be secure. You'd have to test every day with a different hack team and you'd have to resolve every night issues. And you'd have to do that across 8,000 production apps across 47 countries. Even if you had a hundred times the budget, you couldn't finish. You couldn't do it. You didn't have the people and resources. I don't, you know, what I see happening is every line of code to me was an expense. Every single line of code was a maintenance nightmare. And, you know, we, would ⁓ reward developers with apps they built. We should be rewarding with less code, which it was kind of the concept of Encore because can we do it without any code? Because that's going to be, that'll be secure. That'll be better. You know, it's interesting because it's, I mean, less moving parts and less types of parts. Right. So, know, I read, there was an article someone wrote that said they believe open source libraries, which are reusable. Open source to me is reuse and libraries are reused and frameworks are reused. you know, ⁓ they're, like, it's gone. You should guess everyone should just write all the code they need from scratch. What is your opinion? I'm curious. mean, That doesn't make a lot of sense to me. ⁓ I think what it's probably trying to echo or to be generous about the comment is that there is a growing demand for customization, but that growing demand for customization doesn't exclude or discount the power of component reuse. and the notion of constrained configuration rules over new code every time because exactly the reasons that you mentioned. I think AI can help with that, but you have to make that kind of commitment to begin with. I think the idea that all the code is going to be different all the time has so many other implications that don't make sense to me. does make sense is, and this is where you think about what's happening with the SaaS companies and so forth, right, is that it's not that the notion of SaaS is problematic. mean, the notion of a company building and providing for you all the application infrastructure so all you worry about is its application to your business is a powerful idea, always will be a powerful idea. It's about focusing on what you're good at. You know, I want to focus on selling lemonade. ⁓ I don't want to focus on software and infrastructure and all the things that I have to worry about to maintain, ⁓ to maintain that operational efficiency across all my lemonade stands. want to focus on selling lemonade. So I don't think that goes away. I think what does happen though, and this is going back to the point of as code becomes cheap, what we were willing to tolerate before. We don't want to tolerate anymore. So in other words, you know, that SaaS application didn't exactly do it the way I wanted it to, but that's fine. You know, I can make that work because- Or worse, you had to pay a strategic integrator eight times the license cost to make it do what you wanted. Right? That's the alternative. Right. So you want it to be different. You either accept it or you pay a high premium to change that. So I think what's going to happen is SaaS isn't going to go away, but the pricing dynamics, the demand for customization and the expectation of cheap customization for a particular business is going to go up. Does that mean that everyone's going to rewrite these massive applications themselves with AI? I don't know. I think it's more along the lines of the industry is going to be required to your point. of lowering the cost of customization. I am with you on the long term. I'm worried short term. I think we're going to see a lot of technology teams who've invested in AI and have a large budget they've spent in trying to make AI work. Look at the SaaS providers as they have clear documentation requirements there because they've done it before. It's already working. It's configured. And look at it as let's just rebuild it using AI and reduce costs. And what's going to happen is they might achieve that. believe they could. I don't think it's a technical challenge. Now they have to maintain each line of code they created. And that was why SAS came about. The SAS came about like I built Smith Barney CRM from scratch. know, we moved it to C-Bull because we were paying a fortune in maintaining it and keeping it up to date with not my code. Every, it was. It was the patching. was, you know, the Windows NT server was being updated. Yeah, the patching, change, but the changing as requirements evolve. so, you know, I think it depends. think it's a spectrum. If it's a very small amount of functioning, cause some people are in this situation where they get these giant SaaS contracts. They use a relatively small part of the function. Yeah. Replace it then make sense. You're, you're getting a good value. question is value long, but like it's gotta be. long-term in the sense, not just of the cost of the line of code to create it, which is now going down to cost of electricity. It's got to be long-term in the sense of risk and total cost of ownership. How much does it cost to meet a host, maintain, secure? Total cost of ownership has to include the fact that as requirements change, technology changes, expectations change, whatever you created becomes quote unquote legacy. So you're always, always adapting it. You're always trying to keep it up to date in a variety of different ways. What is that? What is that cost? And what bets are you making? And this goes back to architecture. One of the biggest challenges architects have is they have to make bets. They have to make bets about what's actually going to happen from a business perspective, from a technology perspective, from a talent perspective. Because all those externalities change the way you architect software. think I know the answer, but in the future, in a technology function, what's the most important role in your mind? ⁓ in my mind, it's the architect. I mean, it's the person who thinks about all the various choices that need to be made and what the implications are of those trade-offs, because they're always trade-offs. You can say, well, in the future, ⁓ Every time you realize you made the wrong trade-off, you can go and magically recode it all. I just think that people are underestimating the dependencies. So your silly example is your business, your software business, you make some architectural decisions that result in an implementation that has certain constraints. There's just basically the laws of physics and software, right? I mean, they just have some constraints. Your customer base becomes dependent on them. So you say, I'm going to magically recroat it. Yeah, but now you have to bring all your customers along and all their processes have to change as a result. Are they going to come along or not? This is just, there's a lot of interesting economic dynamics here, business dynamics. It's just a lot more complicated than I think. I like your answer. I like the idea of the architect because the architect really became a governance function of just thou shalt use this set of tools, but you can do whatever you want. For these reasons. So real quick, lightning round. I'm going to go through as fast as we can here. This is what we'll be asking guests. So I'm going to do this with you and I'll also answer, but by 2030, Uncork wipes out legacy technology. Which technology are you most excited about wiping out? Is there anyone? It's just a little bit snarky, but PDFs. Digital paper. I am. That's a good one. Digital paper is good. I said Lotus Notes because I still see it in our customers and production as shocking as that is and it's still here. Next question. Favorite AI podcast or any podcast besides of course this one? mean, you know, look, I have a general, you know, respect and admiration for Lex Reedman. I don't know if you consider that an AI podcast. Favorite book you'd recommend. What's your? I think fast, think slow. And I'm similar, barking up the wrong tree, Eric Baker, who quotes all of, it's Daniel kind of, right? It's an amazing book. Last show you binge watched? Oh my gosh. The last show I binge watched, I think it was Beast and Me or something like that on That's a okay. I did Land Man. I actually really enjoyed it. That was good. And let's see, Tech. product you wish you had invented, if you could go back in time. That's a good one to end on. So many. There's so many cool inventions. I'm going to stay away from the AI stuff and I'm going to say lasers. Ooh. Ooh, you could build my, what I dreamed of, like the laser gun when you're a kid and just playing with that. That's a good one. I like that. Mine would be Facebook just because it's such a simple technology to build. I mean, we could build that in like a day or two. But it had the network effect. And I like the, I like the idea that something takes off, which is great. And with that said, I'm hoping this is the podcast that will take off and bring everyone insights into what's real, what's not, how to apply this in your business. ⁓ We have some amazing technology leaders coming on after this. each, each week or two, we're going to be bringing you some, some amazing perspectives and you'll join Dave and I for that. looking forward to the next episode. Thanks, Dave. Take care. Thanks. Thank you to our listeners for tuning in. Make sure to like and subscribe. We hope to see you again in our next episode. Please send ideas for topics or guests that you'd like to hear from. We look forward to seeing you then. Thanks.