The B2B Podcast Index
Index
All categories
MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
MethodologySubmit
Best of:MarketingSalesSaaSFinanceHROpsLeadershipCustomer SuccessAI & DataProductStartups & FoundersRevOpsEngineering & DevTools
An independent project byFame
SearchBest episodesGuestsInsightsMethodologySubmit a podcast
Index/AI & Data/Behind The Tech with Kevin Scott
Behind The Tech with Kevin Scott artwork

Ask Me Anything with Microsoft CTO, Kevin Scott

Behind The Tech with Kevin Scott · 2025-02-18 · 42 min

0:00--:--

Key moments - from our scoring

Substance score

45 / 100

Five dimensions, 20 points each

Insight Density9 / 20
Originality8 / 20
Guest Caliber13 / 20
Specificity & Evidence9 / 20
Conversational Craft6 / 20

This AMA episode covers Kevin Scott's practical experience with AI across both personal and enterprise contexts. Scott discusses using Copilot for ceramic kiln design and glaze chemistry research, demonstrating AI's value in creative problem-solving beyond typical business use cases. On software development's future, he argues that AI fundamentally changes how we build systems - moving from algorithmic thinking inherited from Ada Lovelace to natural language-based descriptions, potentially eliminating traditional applications entirely in favor of conversational interfaces. He emphasizes that regulation is essential but must be consistent across federal and international levels, with practitioners responsible for educating policymakers despite inherent biases. For AI deployment in underserved regions, Scott notes that building applications is easier than ever with APIs and open-source models, but infrastructure remains the bottleneck - rural broadband and baseline technology fluency are still missing in large parts of the world. Finally, he shares critical DevOps lessons: measure everything relentlessly, manage complexity intentionally by refactoring rather than appending, reserve engineering capacity for tech debt, and test infrequent failure scenarios frequently - including LinkedIn's practice of randomly taking data centers offline weekly to validate fault tolerance.

Key takeaways

  • →AI is shifting software development from algorithmic thinking toward natural language interfaces, potentially eliminating the need for traditional applications as we know them.
  • →Consistency in AI regulation at federal and international levels matters more than state-by-state fragmentation, with practitioners obligated to transparently educate policymakers.
  • →Building AI applications has never been easier due to hosted APIs and open-source models, but deployment in underserved regions remains limited by infrastructure and connectivity gaps, not technical capability.
  • →DevOps success depends on rigorous metrics, good monitoring, and treating complexity as something that requires refactoring rather than accumulating through incremental changes.
  • →Test infrequently occurring failure scenarios more often than they naturally happen - including chaos engineering practices like randomly taking data centers offline to validate fault tolerance systems.

Topics in this episode

CopilotOpen source AI modelsTech debt managementAI regulationJapanese raku ceramic firingSoftware development tools and architectureAda Lovelace algorithmic thinkingLarge language models APIsDevOps and infrastructure scalingData center fault tolerance

Questions this episode answers

How can AI help with ceramic and pottery work?

Kevin Scott used Copilot to research glaze chemistry and kiln design for replicating traditional Japanese raku tea bowls, finding it particularly helpful for determining boron composition and formulation to replace lead while maintaining proper melting temperatures - demonstrating conversational problem-solving in specialized domains.

Will AI completely reshape how we build software?

Yes, AI fundamentally changes software development by enabling natural language descriptions instead of algorithmic thinking, potentially eliminating traditional applications in favor of direct conversational interfaces, though this shift will take years and requires composable tools during the transition.

Should AI regulation be federal or state-level?

Federal and international regulatory consistency is preferable to fragmented state-level approaches, as good regulation's goal is deploying beneficial technologies quickly and safely - which requires reducing unnecessary complexity rather than creating it.

How can AI reach underserved regions with poor infrastructure?

While building AI applications is easier than ever through hosted APIs and open-source models, scaling requires solving connectivity problems first - rural broadband deployment remains the unsexy but critical work, as demonstrated by disparities in rural Virginia where some homes have good internet while neighbors miles away use 300k DSL.

What's the most surprising DevOps lesson at scale?

Testing rare failure scenarios must happen more frequently than they naturally occur - LinkedIn's practice of randomly taking entire data centers offline weekly ensures fault tolerance systems actually work when real outages happen, rather than assuming a single successful test means permanent reliability.

What our scoring noted

Our reviewer’s read on each dimension, with quotes from the episode.

Insight Density

9 / 20

There are scattered genuine insights - the LinkedIn data-center kill drill, the potential obsolescence of app paradigms, and using AI for root-cause triage - but the AMA format fragments every topic before depth is reached, and large portions of the transcript are filler agreement and vague platitudes about AI regulation and agents.

at random points every week, just take a whole data center offline, uh, to make sure that all the fault tolerance systems would work
I don't know that you need apps in this world... the user interface telling someone they got to go learn all of the complexity of some software... versus just say what they want done

Originality

8 / 20

The LinkedIn data-center chaos-engineering practice and the Ada Lovelace framing of software's unchanged paradigm offer mild novelty, but the AI regulation, agent, and rural-connectivity discussions recycle widely circulated takes without adding a genuinely contrarian or first-principles argument.

the way that we've been building software hasn't really changed since Ada Loveless... this whole process of algorithmic thinking... We've been doing that for almost two centuries now
without telling Them, you just kill the whole system and you'll know real quick whether, uh, their application's robust or not

Guest Caliber

13 / 20

Kevin Scott is genuinely high-caliber - CTO of Microsoft, former VP Engineering at LinkedIn, 40 years of hands-on programming - and he has demonstrably done the things he describes at scale; the AMA format, however, prevents him from showing the full depth that his experience could justify.

at LinkedIn, we uh, used to, at random points every week, just take a whole data center offline
I've been programming for 40 years, um, so I'm 52. I started when I was 12

Specificity & Evidence

9 / 20

The episode has pockets of genuine specificity - the LinkedIn weekly data-center takedown, a 300k DSL uncle, 1100°C raku firing temperatures, rural India AI diffusion anecdotes from Satya Nadella - but most of the AI regulation, agent timeline, and infrastructure scaling discussions remain abstract and unquantified.

my uncle, who lives, uh, just a few miles away from them, is still on some kind of, like, crazy 300k DSL connection
I've got a set uh, of tea bowls that I uh, am firing in the classic raku style at 1100 degrees Celsius

Conversational Craft

6 / 20

The host is consistently deferential - responding to nearly every answer with 'I love it,' 'great stuff,' or 'yeah, yeah, totally' - and rarely pushes for precision or challenges vague claims; the one genuine follow-up (asking whether the data-center drill was Scott's initiative) briefly surfaces something useful but the pattern of unchallenged agreement dominates.

Yeah, yeah, totally. I mean, lots, lots of things to think about.
was that a process that um, started before you joined or was that something that you um, asked them to do?

Conversation analysis

Computed from the transcript - who did the talking, and the words that came up most.

Share of words spoken

  • Speaker B71%
  • Speaker A29%

Most-used words

interesting18super16question14software14sure14bunch13whole12agents11making10development10complexity10systems10powerful9application9design8happens8

Episode notes

In this AMA episode of "Behind the Tech," Kevin Scott and Christina Warren address a variety of listener questions, ranging from the impact of AI on learning and personal projects to the future of software development and AI regulation. Kevin shares his experience using AI for personal projects, such as making Japanese tea bowls, and discusses how AI has changed the way he approaches both work and hobbies. The conversation also touches on the potential for AI to reshape software development, with Kevin emphasizing the significant changes AI will bring to the field and the importance of adapting to these changes. The episode also explores broader topics, such as the regulation of AI, the challenges of scaling AI in regions with limited technological infrastructure, and the role of creative leaders in the era of AI. Kevin highlights the need for consistent and agile regulation to ensure the safe and beneficial deployment of AI technologies. He also discusses the democratization of AI tools and the importance of connectivity in enabling access to these technologies.

Full transcript

42 min

Transcribed and scored by The B2B Podcast Index.

Speaker A: Welcome to behind the Teck. I'm your co host, Christina Vorin, Senior developer advocate at GitHub.

Speaker B: And I'm Kevin Scott.

Speaker A: It is time now for our AMA episode. For the past couple of months, listeners, um, have been sending in some really fantastic questions. We cannot answer every single one that we got, but we are so appreciative of all of you who sent in your questions. And so this is going to be a, a super interesting conversation. Here's our question from Ravinder. How has your pace of learning changed in the era of AI? What's been the coolest thing you've done with AI? Personally?

Speaker B: Yeah, I've definitely been using AI, uh, a ton for uh, the projects that I'm doing outside of work even um, so like a bunch of things that it gets used for, uh, at work that are hugely useful, but the uh, outside of work ones, uh, I think are kind of fun. So uh, like maybe the coolest thing that I've done is uh, I have gotten really into making uh, Japanese tea bowls, uh, in my ceramic studio this past year and I have been researching how to uh, replicate some of the results in traditional classic Japanese raku, uh, tea bowl making, which has involved me making, making my own kiln, uh, devising my own glaze recipe and even devising uh, a way to take um, a clay body that you make the bowls out of and making it tougher so that it can handle all the thermal cycling in this crazy uh, firing process. And I will tell you that Copilot was amazingly useful in all of that, like particularly with the kiln design and with helping get uh, some ideas and uh, you make progress on the glaze chemistry for this uh, glaz.

Speaker A: That's so interesting. So like, what do you do with Copilot with that? You just, do you just have a conversation and just ask questions, um, kind of back and forth about, you know, maybe how you want to design stuff.

Speaker B: Yeah, I mean I basically uh, for the glaze design, I told uh, or I asked Copilot, I was like, I've got a set uh, of tea bowls that I uh, am firing in the classic raku style at 1100 degrees Celsius, where uh, I'm going to, you know, take the glazed vessel, put it directly in the at temperature kiln, uh, like leave it for three minutes until the glaze goes cherry, uh, red and then you know, pull it out to air quench. Uh, and I, I gave it a few hints about what I had been thinking about, like what I know of the Japanese, uh, Like is this is the interesting bit. The, um, the traditional Japanese raku glazes use uh, lead in them, uh, to get the elements of the glaze to melt at a lower temperature. And obviously I don't want to be using lead in my tea bowls, uh, even though there are like safer variants of uh, you know, lead that you can use that are, you know, are safe in ceramics. Uh, but I didn't want to. And so, uh, you need to use something else, like boron. Uh, and so figuring out how much boron you uh, use and in what form the boron comes in and the glaze is like a little bit tricky and like it was super helpful. Uh, and it was, it felt like a real conversation that I was having with someone who knew a little bit something different about glaze chemistry than I know.

Speaker A: That's genuinely. This is so fascinating. And also thank you for sharing all of your many interests with us because you're such an interesting person and I never would have thought like that from all I know how much of the maker stuff you're into. But, you know, building your own kiln and making Japanese T bowls and using AI to get more information about this, I love it. That's a great use case of AI. I love that. Great, great stuff. Thank you again for that question. All right, this question is now from Rafael and he asks, do you believe that in the future AI will completely reshape the way that we produce software? And ah, and he goes on to say, you know, I mean, could we eventually get rid of the development tools that we use today and rethink the entire process from scratch? Creating a completely new approach to software development seems likely.

Speaker B: I, um, mean, and I'm, I'm an old enough fart where, um, I mean it sounds disturbing to say, but like I've been programming for 40 years, um, so I'm 52. I started when I was 12. Uh, and in 40 years, like particularly the past 40 years, like it software development now, even without AI, doesn't really resemble, uh, much at all what software development looked like in the 1980s. Uh, and so I think it's a safe bet that um, software development is going to reform itself over the next handful of years. And I think just super clear that AI is going to change the way that we. Right. Software. I think they're just sort of all of the obvious ways, uh, that it's going to change things. Um, coding is a complicated activity and it always has been like this thing where you've got an idea in your head, uh, that needs to be sharpened, and then you need to get the sharpened idea out, uh, in, to a form that the computer can go execute. Um, the thing that's really changed, and I've said this before, uh, in public, I think, um, is the way that we've been building software hasn't really changed since Ada Loveless. Uh, like this whole process of algorithmic thinking and, uh, understanding the complexity of a machine all the way down to its atomic details, and then using that understanding of the machine to transform this idea that you framed algorithmically into a program that the computer could write. We've been doing that for almost two centuries now. Uh, and there really hasn't been much of an alternative. Uh, our tools have become m. Increasingly more powerful. But it's basically that you want a computing device to do something for you. You either figure out how to do that process yourself, or you have to hope that someone who understands how to do that has written a program that you can run yourself. And I think the big thing that's changed with AI is now you have a thing where you can describe a thing that you want accomplished, uh, not necessarily even in algorithmic terms. Uh, and then the AI can do some or all of that mapping to get the computer to actually do the thing for you. And that really, really dramatically changes. Um, you know, how we think about software development and who's a developer. It changes like what, what it means that we're building. So, you know, for instance, I was just having this conversation with a bunch of engineers, like, I don't know that you need apps in this world. Um, so like an application is a byproduct of this early thing that I just described, that someone has to understand a set of problems that a group of people want to accomplish, and then they just sort of edit a bunch of code together into this thing called an application that does those things in a general enough way that those people can get some value out of it and be able to use it. And I don't know that you are going to need that too much further in the future. Um, like you'll still need the capabilities that are in the applications, but the user interface telling someone they got to go learn all of the complexity of some software because they got to navigate some weird user interface information architecture to get a thing done versus just say what they want done. Like, that's changing, clearly. And like that has an implication for the software development as well.

Speaker A: Yeah, yeah, it does. I mean, that's what I kind of think about, right? Because obviously I think you're right. Like, it could change completely how we define a developer, um, which is something that we've been trying to do in various ways for a long time, but now we finally feel like we're maybe on the cusp of really, um, you know, broadening that, that, that concept. Um, it like, really feels like that could be a reality, but it does make me think about on other levels. Okay, so how do you design programming languages? Or do you. Or how does that change? Right, like, like what, what matters then about the, the underlying code? Um, beyond that, you know, if we, um, are able to just, um, create things based on our natural language and based on what we want and make updates iteratively, um, with multiple people at once, how does that change how we design those underlying systems? I think that's really interesting to think about too.

Speaker B: Yeah, 100% and super useful stuff to think about. And the trick is, and this has been true about software development forever, is you want things to compose. So AI is still a pretty far ways away from doing this grand vision that I just articulated. And so what we really need to be thinking about between now and like, whenever that happens, if it actually happens, the way that I imagine, uh, is like, how do you take tools that are on some spectrum of, you know, classical software development tools to, you know, this new AI future and make sure that all of the things compose together in reasonable ways so that developers can then take all of this stuff that's in their toolkit and like, get the thing built that, you know, they're hoping to be able to build.

Speaker A: Yeah, yeah, totally. I mean, lots, lots of things to think about. Um, and I totally agree with you on that. All right, we've got this question from Veronica Shifting, um, talks just a little bit still around AI, and she wants to know, how do you suggest we regulate AI should this be done at the federal or state level? And how can we ensure that AI is safe and secure, both from a public and private standpoint? Great question.

Speaker B: Yeah, I think it's a super great question. M. You know, again, I've said this, uh, said this as well. And like, I think I talked about it even some in my book. Um, like, of course, any technology as powerful as AI needs to be regulated. Uh, and it would be just an odd thing in the course, uh, of human history if you had something this powerful and it wasn't regulated. Um, you know, the thing that you want to do though, with regulation is, I think, uh, consistency is helpful. Like, that's where you know, sort of, um, you know, federal Federal, uh, regulation that is, you know, consistent across all the states and even, you know, sort of international standards would be super, super useful. Uh, yeah, because regulation, regulation, like good regulations, intent is to like, get beneficial technologies deployed to those who will benefit from it, uh, as quickly and safely as humanly possible. And so you, you don't want unnecessary complexity in the, in the regulation itself, uh, because like, that prevents, you know, the, the whole, you know, beneficial technologies getting to whom it benefits. Um, but yeah, I mean, I think in general we, uh, will need our regulators to be pretty agile in making regulation that can encourage the most beneficial things for the broadest number of people to get to the market as quickly as possible, while at the same time being careful about, you know, what the downside risks are to a bunch of things and in a bunch of places. Like, the biggest downside risk, honestly, is, uh, failure to deploy quickly enough. Like there, there are for instance, like a whole bunch of medical things right now where the models are strongly superhuman. Um, yeah. And I've had some experience with my own mother in the past year with the healthcare system where if she had had access to the most advanced AI tools, a whole lot of suffering could have been reduced. Yeah, it's lots and lots and lots and lots of people are in similar situations where, uh, it's not some theoretical future where stuff could be beneficial, it's now that it could be beneficial.

Speaker A: How do you think we go about, um, I guess educating or ensuring that our legislators are aware of what the potential. I guess both, uh, you know, um, opportunities and, and risks are in this area. Right. Because this is, this is something I think about a lot. Um, I agree with you. Regulation is super important and it needs to be consistent. But I do sometimes wonder, I mean, it's hard enough for us as technologists to keep up with all these things. How, how can we do a good job of making sure that, that the legislators are informed?

Speaker B: Yeah, I, I will say the thing that I'm most encouraged by, um, on this front with AI is more so than any previous technology that I'm aware of. You have practitioners in the field spending a whole bunch of time talking with people in the academy and people in government trying to make sure that they have the information that they need in order to make good decisions. Um, and I see people doing it in very respectful ways now. You know, obviously everybody who's coming at it, uh, like whether you're in the government or you're in, uh, the academy or you're in the industry, like, you're obviously Biased, uh, in some way. And so yeah, we, we all need to be as clear as we possibly can about our biases and sort of lay them on the table. But like, just because you're biased, uh, like doesn't mean that you can't get information out there and then have someone adjust for the biases, look for what the through line is and everything and then make good uh, policy decisions. That's a way better way to um, be than to not be transparent about what's going on or decide that you're not going to talk to somebody because it's not your job. I think right now in tech, anybody who's working on AI, part of your job is to uh, when required, um, patiently explain what it is you're doing, why you're doing it and how it works.

Speaker A: Great stuff. All right, so this is a question from Muigiri, and this is really good. Uh, how can large language models be scaled effectively across regions with limited technological infrastructure? So think about places like uh, African nations, like what are some of the biggest hurdles for AI powered educational solutions to move beyond prototyping and into full scale deployments in underserved regions? And how can these challenges be overcome?

Speaker B: Well, I think the news there is probably pretty good. Uh, if what you want to do is to build an AI ah, application, it has never been easier than it is uh, right now to go build one. You have more choices about very powerful models to access. Uh, um, you have models that are available behind APIs that are hosted, where you sign up for a developer key and uh, just start making requests. Uh, you have a huge catalog of open source models that are on a spectrum from general purpose to very specific tasks, uh, um, design things. Um, and so like you just have a lot of choice where you don't have to start by saying I've got to train a model from scratch. Um, and so I think that is a huge advantage. Like it's definitely not the way things were 20 years ago when I wrote my first machine learning programs. Um, you know, it isn't even how things were three or four years ago.

Speaker A: Right. I was going to say it's a lot different even then then. Right. It's much easier for people to build really good things now, um, versus you know, three or four years ago to your point.

Speaker B: Yeah, I mean my, my boss Satya Nadella tells uh, you know, stories about his visits to India recently where he has seen the just rapid diffusion of AI applications, uh, you know, at a pace that he's never seen before. The thing that he says, which I think is really good, is, uh, there are parts of rural India where the Industrial Revolution still hasn't shown up after 250 years. Uh, where they already are seeing the diffusion of AI, where, uh, you know, a farmer, through their mobile device, can access a powerful AI system that will help them understand how, uh, they are entitled to government programs and then go sign them up for them so that they get these benefits that their government intended them to have. Uh, and that's just kind of a shocking rate of diffusion. Um, but look, it's also not all good news. Uh, I think while the expertise required to build an AI application is democratizing super fast, and you've got high levels of accessibility to the APIs and basic infrastructure required to go build them, uh, you still have to be connected. Uh, you still have to have some baseline level of technology fluency in order to be able to use the systems. And the reality is there are large parts of the world that are not yet sufficiently connected and where that technology fluency isn't as good as it should be. And so, uh, I think, yeah, there's a bunch of, at this point, deeply unsexy work that, uh, we still need to prioritize and make sure that we're focusing on things like just rural broadband. Um, you know, like, I've definitely told this story before, but yeah, my mom and brother have good Internet in this rural town that they live in in central Virginia because they're lucky enough to live within 100 yards of the local, uh, uh, telco exchange. Uh, my uncle, who lives, uh, just a few miles away from them, is still on some kind of, like, crazy 300k DSL connection. Uh, and, you know, his Internet is barely usable. And so, you know, he has to come to my mom's house to do things on the Internet. So nuts. Uh, and so, like, that's the sort of thing that I think we really have to pay attention to because as the things that you can do and the capabilities you can access with that connectivity become more powerful, like, absence of connectivity, like, becomes a bigger and bigger disadvantage.

Speaker A: No, I mean, I think you're exactly right. And this is a conversation, I feel like, you know, we definitely talked about this on this podcast, but I feel like we, uh, collectively, as you know, an industry and society have been talking about this for at least 20 years. And it's only becoming more and more important. Right. To start to really invest in overcoming these infrastructure challenges just because connectivity is only going to be more important. Right. I think that's a great Distinction that it's easier than ever to build, um, applications and things with these tools, but actually getting it to people and making it so that they can interact with them, um, is maybe the less fun part, but arguably even more important because without that, we, you know, all of this is moot. Yeah. Yep. Uh, all right. Question from Peter. He asks, I am curious about how Microsoft approaches running technical tests against its own infrastructure, LinkedIn, Xbox, Office 365 and others. Given the scale and complexity of these systems, how many lessons have you learned over the years while managing that infrastructure? And he goes on to ask, and for those of us in DevOps, what is the most surprising lesson that, uh, you've encountered that might catch us off guard?

Speaker B: Oh, God, that's a super good question. Like, very complicated. So I don't know whether I'm going to be able to answer, uh, the whole thing.

Speaker A: I was going to say, if you want to take this in parts, do that, do that. That's okay.

Speaker B: Yeah, look, so I had a boss, um, who was like, maybe the best DevOps, uh, leader I've ever worked, uh, for or with in my career. And, you know, like, he, he had a bunch of, like, very simple things that he would say about, you know, philosophically, how you should approach, uh, approach DevOps. Um, yeah, like, one of the things he says is, uh, or said is, um, you can't fix something or improve it if you're not measuring it. Uh, so, uh, a lot of the answer to the question just boils down to, are your metrics good? Are you measuring everything that's happening in your system? Do you have good monitoring built on top of the metrics? Do you have good visibility into the internal state of all of the systems? Uh, that's one thing that's super important. Um, another thing is complexity, uh, needs to have a reason. And so a lot of times, uh, complexity just sort of emerges because, uh, the most convenient thing to do to systems architecturally is often to just append new stuff onto old rather than to do the harder work of, okay, we've got some evolved requirements here. Things are different from when we originally designed this system. Now we need to just push, pause and go refactor the whole system and make sure that it's designed in the simplest possible way to meet the new set of requirements that we now understand. Um, and so, like, you know, one of the things that I've always tried to do in the organizations that I've led is to make sure that you are reserving some amount of your engineering capacity to go deal with tech debt. Um, you know that you've got teams who are building shared infrastructure whose job it is not just to provide a set of services to everyone, but to be building things in a really architecturally simple way. Uh, and to make sure that things are robust, maintainable, scalable, uh, secure, fault tolerant. Uh, like all of the things that you want out of your systems. Uh, and you just got to rebuild stuff every now and again. Um, like it's painful as it may sound, uh, you know, when you've got product managers screaming at you that like, you need to go ship, you know, this new feature or you know, you're eyeballing, you know, short term revenue or something like that, uh, to like go tell all of your stakeholders. Yeah, we got to go push pause on this for a little while while we like re architect this uh, thing. Um, you just have to, you have to do it because complexity really is the, it's the killer. Um, yeah, there's a bunch of stuff that we're doing with AI right now though, to deal with some of the complexity. Uh, so like it can, you know, when you have complexity in systems, it's irreducible. Like, you just can't figure out how to design, design away from it. Uh, like AI can help manage, uh, you know, some of the complexity. And it's like not in a way where you're letting this AI be an abstraction layer that sits between you and your understanding of your system, but to help you just very quickly triage things or figure out how to root cause, uh, operational issues or whatnot. Uh, it can be super helpful with stuff like that.

Speaker A: Um,

Speaker B: yeah, I mean I could go on all day about this particular bag of, bag, uh, of issues. Uh, but um, yeah, I mean like you just gotta, you just gotta test, test, test and like you know, here's a, you know, a thing, maybe this is, ah, I have gone into situations before where people have built systems or built functionality that are designed to do a thing, uh, in rare circumstances like data center level, fault tolerance, uh, for instance, what happens if this whole data center goes down, if it loses power or if there's a fiber cut or something, um, where the team tests the functionality once, uh, and then assumes that it's going to be available forever and ever. Just uh, because it worked one time.

Speaker A: Right? Um,

Speaker B: and so yeah, you just gotta, you gotta test for infrequently occurring things and make sure that uh, when the infrequently occurring thing happens, uh, that you are ready to go. Which basically means you need to simulate the infrequent thing more frequently than it will naturally, uh, happen. And that's like a counterintuitive thing, I think, for some folks.

Speaker A: Yeah, no, that is, but I like that. I think it probably answers um, ah, this question really well. Um, because that does seem counterintuitive, but it makes sense, right? Like you need to make sure that when this actually occurs that it's going to work. Uh, but to do that, got to have. It's kind of like fire drills, right? Like, you know, you do them hopefully much more, you know, frequently than they actually occur. Just, just, just in case, just if you need to be ready.

Speaker B: Yeah, I was just going to say, like at LinkedIn, we uh, used to, at random points every week, just take a whole data center offline, uh, to make sure that all the fault tolerance systems would work.

Speaker A: Okay. That's awesome. That's, that's, that's wild. Um, and um, was that a process that um, started before you joined or was that something that you um, asked them to do? Uh, I'm just curious.

Speaker B: That was, that was a thing I asked them to do.

Speaker A: Amazing. Amazing. And was it for that reason? Just because you wanted to ensure that.

Speaker B: Yeah, it was correct? It was. Because resiliency is a super hard thing to achieve. So it is not a service that you can just sign up for and get resilience. It basically means that every single thing that's running in the data center has to be resilient. It has to be prepared to deal for things to fail in the worst possible way. Which means obvious things for things like databases and networks and storage systems and whatnot. And there's a bunch of super classic computer science and engineering, uh, stuff that you can go do to make those things fault tolerant. But you also have to make your applications fault tolerant. What happens if, uh, an application server that's rendering the user experience to a user, like what happens if it loses like all network connectivity? Like what happens then? Uh, um, you know, is there some routing layer somewhere? Like you know, maybe in the end user application that the user is using that uh, will uh, notice that its connection back to its application server is no longer responsive and it routes it sideways to another, uh, another server somewhere in the service catalog in uh, another data center. Uh, you just have to think through all of this stuff, like how is every single piece of this system and you have to have every single service owner um, accountable for having done that work. And a real good way to make sure that they've done the work is without telling Them, you just kill the whole system and you'll know real quick whether, uh, their application's robust or not.

Speaker A: I love it. I love it. And I'm glad that. I'm glad you implemented that. I mean, I think it is a testament to LinkedIn, um, that it is one of. Covered many of these, uh, uh, services and, you know, worked at companies, you know, that need to be online a lot, that have not always had great, um, uptime. LinkedIn is one of the ones that has, at least in my experience, had very, very good, um, you know, uptime and those sorts of things. And I think that's probably a testament to the drills now.

Speaker B: But not. Not always.

Speaker A: Yeah, well, but that's how you get there, right, I guess, is by having it just, uh, uh, at the top of the hat. It could be gone. How are you going to recover? I love that. I love that. All right, this question is from Samantha, and she asks, I've noticed you've had a few recent guests that aren't typical technologists like Bin Ladi and Rafiq Andal, could you share more about your thinking and perspective on how more creative leaders are working in the era of tech and AI?

Speaker B: Yeah, part of it is, like, just to be perfectly honest, these are people that I want to talk to. Uh, and I think the conversations are interesting and I want to share them. Um, but I think, you know, there is this thing that we have been talking about, which in the era of AI, this distinction between, you know, like, who's a technologist and who isn't is, like, blurring in a really profound way. And so I think it's good to be talking to a broader variety of people because you have, like, Rafiq, for instance, uh, um, is a trained artist, but he's using technology in incredibly sophisticated ways to realize this artistic vision that he has. And I think there's just going to be more and more and more of that over time because this previously daunting and inaccessible technology is becoming less daunting and more accessible. And which means that more people are going to be using it to do a broader swath of things. And so, you know, like, is. Is Rafiq an artist or a technologist? Like, yeah, maybe it doesn't matter. Uh, he's just doing amazing stuff. Um, you know, and like, this conversation I had with Ben Laude is, uh, like, I think all the time about what the nature of art is and, like, what. What are the, you know, what are the things? What's the difference between, you know, art and instrument? And, like, what's the, you know, what's the boundary between performer and instrument? Um, and so I think, yeah, it's interesting to have artists come in and talk about how they're thinking about those relationships, um, you know, that they have had in their art and in their craft for a very long while. Uh, and then, you know, how that thinking is changing in an era of AI. Um, so I, I just feel like they're super important conversations to have right now.

Speaker A: No, I think you're right. And. And I think that, you know, kind of breaking down, maybe kind of this. This demarcation in places like. I don't know if the. If it matters, you know, if. Yes, right. That. That could be the. The answer to. To both questions. Um, these lines. I mean, when technology truly becomes accessible and kind of, uh, something that we all sort of, kind of imbibe, it's. It's not. It becomes just a part of us. Right? Like, we the. And I think that the oftentimes artificial barriers that we put into place disappear. And it's just like, you're a creator, you're a person, you know, um, regardless of, um, how you get there and what you do, um, you know, it doesn't have to be, oh, I have to be in this box or this box. It's like, no, I'm just, you know, I'm just creating the thing that.

Speaker B: The thing that I will also say is, like, I have super strong opinions about some things. Like, for instance, like, I'm not interested in AI at all absent a human wielding the AI to do something interesting now.

Speaker A: Right?

Speaker B: I'm not, I'm not claiming that everybody needs to be my way, but, like, it's just interesting to me that, like, this isn't a, uh, like a point of view that I came to through some, like, huge process of deliberation. It's just like, I am not interested in the idea of some autonomous AI, like spitting out art or, you know, music or whatnot.

Speaker A: Right.

Speaker B: Absent. Yeah. The hand of a human creator. Because, like, I've. I've sort of discovered, like, part of my connection to the experience of, or like, of experiencing art in the first place is like, I like to know, like, oh, this is the human, and this is how they made it, and this is, you know, like, imagining what they must have been thinking. And like, you know, we alike. Are we different? And like the story. Yeah, I like the story and the story of, like, yeah, you know, the robot made this. Like, who cares, right?

Speaker A: No, and I think that's a great point. Right? And that's a really interesting perspective because obviously I, I mean, I think there's an argument to be made that there is something artistic that could be made if it were completely, you know, autonomously generated. And that's an interesting thing to have. But I, I tend to agree with you. Like, the stuff that I'm interested in consuming the most, uh, outside of kind of like an abstract level, is definitely the stuff that has been guided by a human. Um, but if the technology, uh, the AI can make things more unique or, or effective, or just add a different nuance to something that can lead to a great outcome or interesting. Anyway, it's an interesting debate because I

Speaker B: don't know whether I'm right, you're right, or I do actually have this argument with people who will say, hey, you're crazy. You could have something that's interesting and artistic and merit worthy that doesn't have. It's like, okay, great. And the argument is interesting, right? It sort of tells us, it tells us something about, you know, what, what is the nature of these things?

Speaker A: No, I think it does. Right. And yeah, because I can see both perspectives, I tend to, I think, align more with you, but I can understand, like, the, the philosophical argument about it. Um, but I think that for a lot of us still, what ultimately binds us to things is not just the output itself, but the everything that comes before it, which is the story and is the thinking about what went into it and is frankly, in some cases, the imperfections. Right. And, and that is something that. Not to say that it couldn't be there, because who knows where. Where AIs might be in, you know, decades. But that's not that. That doesn't seem to be the direction that a lot of those, uh, things are now. And so, uh, instead, though, I think it's interesting to think about, like, how these tools can be used not to just clean up imperfections, but to maybe continue to let those things be there, but maybe, you know, show off other, um, ideas. I don't know. All right, this question is from Kathleen, and she says, I've been hearing a lot about agents being the next AI frontier. What can you tell us about what that will look like and when can we expect to use AI in that capacity? So, great question. Um, we all want to know when are the AI agents going to be able to run our lives? Kevin?

Speaker B: I don't know for sure. Um, but like, I think it's, like, important to be more specific about what it is we think agents are. So, um, in a way, like Copilots are agents, um, but they're sort of agents that can help you, um, with relatively speaking small tasks. Um, there might be a lot of them that you're doing and they may be very important. Uh, but right now the things that we can delegate to AI are relatively small, like small software development tasks, like small productivity tasks. Um, and like what. Eventually like if you are excited about this notion of ah, agents, what you want to be able to do is to sort of think about an agent as like a real fully capable peer or collaborator or coworker. And like you want ah, it to be able to uh, collaborate with you in like very broad and very capable uh, ways or you want to be able to like delegate like big things. You know, so like for you know, not just five minute tasks but five day task, uh, you know, like go completely autonomously, build uh, you know, this whole application for me and like come back with the, yeah, with a PR you want me to review and uh, you know, something that I can test. Um, you know, which you might do to one of your fellow software developers. Right, right. Um, and so look, I think we're, we're definitely moving in the right trajectory to like have these agents, um, you know, which, you know, in our parlance we call co pilots, become more and more powerful and capable over time. Um, so you know, I think we, we're feeling really good about reasoning capability. Um, we are beginning to make progress on actions and tool use. Uh, like we've seen a little bit of that in the past year and I think you're going to see a bunch of it in the coming year. Um, we are seeing like really interesting things happening, uh, I think and like have a lot of things that we can expect to see in the next year on memory. Um, like a lot of what happens now with these agents is they're very transactional. So like they, they, you know, they have enough information to do a very specific, ah, you know, task in a very specific context. But um, you know, in order to have them be more generally powerful, like they have to like really have complete memories and that persist over time. Um, and then you know, like we've got a whole bunch of, you know, plumbing work to go do. Uh, like you. In order for the agents to be able to do things like just even beyond basic tool use, where they can take action on your behalf or where they can go, you know, use a tool to assist them in accomplishing the tasks that you've set them off to go do. Uh, like you really do have to Think about, like, what a entitlements, uh, look like in this universe. How do you make sure that the agent has access to what it needs to have access to in order to complete the task it's been asked to do? And how do we, the humans, reason over those entitlements and get things both available and permission correctly? Um, yeah, but look, I think I'm seeing lots and lots of progress, and it's hard to predict the date when, you know, agents with capability level X is going to be there. But I think it's safe to assert that, um, we will see increasingly powerful agents in a variety of different forms emerge over the next year.

Speaker A: Sounds good, Sounds good. I think that's probably a good hedge. And, um, uh, I do look forward to the day that the robot overlords do truly control my life. But, uh, until then, uh, I'll be kidding. I'm kidding, I'm kidding. Uh, but I'm glad to know the progress is being made. Okay, that does it for our AMA episode. Thank you again so much to everyone who sent in these excellent questions. Really, really good stuff. And thank you, Kevin, for your answers. Really, really interesting. Please make sure to follow behind the Tech on YouTube or wherever you listen to podcasts. And if you have anything that you would like to share with us, you can email us anytime at, uh, behindthetech at Microsoft. Com. Thank you so much for listening.

Speaker B: See you next time.

Related episodes across the Index

Other episodes covering the same guests and topics, from across The B2B Podcast Index.

  • Green CI and Merge Queue Mastery with Trunk’s Eli SchleiferPlatform Engineering Podcast · on Copilot92 / 100
  • Andy Doyle: Let 15,000 agents bloomWorkLab · on Copilot91 / 100
  • Why Developers Hit a Wall at 4 AI AgentsThe AI Native Dev · on Copilot90 / 100
  • AI Is Producing More Code, but Is It Producing More Value?The Data Exchange with Ben Lorica · on Open source AI models88 / 100
  • 21 in 21: Patrick Ball on Using Bitcoin and AI to Defend Human Rights21 in 21 · on Open source AI models87 / 100
  • How Organizations Can Thrive in the Human + AI Era with David ChestnutThe Edge of Work · on Copilot85 / 100

More from Behind The Tech with Kevin Scott

All episodes →
  • Michele Elam, William Robertson Coe Professor in the Humanities; Senior Fellow, Institute for Human-Centered Artificial Intelligence; Bass University Fellow in Undergraduate Education
  • Year in Review 2024
  • Refik Anadol, Director / Media Artist at Refik Anadol Studio, Visiting Researcher & Lecturer at UCLA's Design Media Arts Department.
  • Ben Laude, Professor of Music (Piano Literature & Aural Skills) at Utah State University
  • Sal Khan, Founder and CEO of Khan Academy
Explore the best B2B AI & Data podcasts →
All Behind The Tech with Kevin Scott episodes →