Cedric Beust: Mobile's Hardest Problems Never Change

Matt Klein: Welcome to another episode of Beyond the Noise: Signals, Stories, and Spicy Takes, the show where we dig into the stories of the people shaping the future of app-based computing, with a special focus on mobile. I'm your host, Matt Klein, co-founder and CTO of bitdrift, as well as the founder of Envoy Proxy. Each episode we'll talk with engineers, founders, and technical leaders who've transformed the way their companies build and understand what's happening inside their systems. We'll dig into the challenges, the breakthroughs, the lessons learned, and we'll wrap it all up with their hottest takes. So let's dive in.

Today I'm thrilled to have Cedric Beust, a seasoned software executive with more than 30 years of experience in software engineering and deep technical expertise spanning back end, front end, mobile infrastructure, machine learning, graphics, testing, and security. He's a hands-on Rust and Kotlin coder by night and a tech lead by day, and has shipped dozens of products still active today and used by millions. He was one of the early members of the Android team, created the Android Gmail application, and built the popular TestNG and JCommander Java libraries. He's filed over 20 patents, published two books, and holds a PhD in computer science from the University of Nice in France. Welcome, Cedric. Thank you for joining us.

Cedric Beust: Thank you, Matt.

Matt Klein: Fantastic to have someone with such an extensive amount of experience on the show. I'd love to start with you. How did you get into computing? Tell us a bit about your journey.

Cedric Beust: I'll try to keep it short, since as you mentioned, I've been doing this for a very long time. I was very fortunate to have a computer in my house at a young age, thanks to my dad, who I convinced to buy an early computer in the '80s, an Apple II. I became absolutely fascinated by that machine. At first I just played games on it, but I got intrigued by coding at a pretty early age and started trying to write my own games and utilities, first in BASIC, like a lot of people did back then, and then I expanded into other languages. It was obvious to me from a young age that this was what I wanted to do professionally. I did all my studies in France, then moved to the US about 25 years ago. I'm based in the Bay Area, and I've been in Silicon Valley ever since, right in the heart of where computer science happens.

[00:01:45] GROWING UP WITH THE APPLE II

Matt Klein: Which games did you play on the Apple II, if you remember? We're probably not too different in age, and I also have memories of playing games on the Apple II in the '80s.

Cedric Beust: I remember vividly, for a couple of reasons. First, because a lot of these games are etched into my memory, since they shaped my childhood and my early contact with computers. But also because for the past five or ten years I've been really interested in emulators, and I've written a bunch of them, including two Apple II emulators, one in Kotlin first, then ported to Rust and expanded. So I actually know exactly what these games were, because I've played them again in the past few years just for nostalgia's sake. I grew up with games like Prince of Persia, Conan, a lot of text adventures, King's Quest, some of the early Zork text-only adventure games, Choplifter, Aztec, plenty of others. I don't know if any of those ring a bell for you.

Matt Klein: For sure. I have memories from when I was a kid of taking one of those big floppy disks and trying to get a game working. Fond memories, for sure. Tell us a bit about how you got to Silicon Valley, and since this is a mobile-focused show, I'd love to learn how you wound up at Google and on the Android team. I'm sure you have some great stories from the early days of Android.

[00:04:28] JOINING GOOGLE AND THE MOBILE TEAM

Cedric Beust: So many stories, and so many incredible, happy memories. These were definitely some of the happiest times of my career as an engineer. I think I lucked out. I joined Google around 2003, still fairly early days. Google was already close to its IPO and pretty famous by then, but a lot of what they were doing was still very early stage, and it was mostly still a search company making money through AdWords. I joined with a backend background. Before that I was at BEA WebLogic, and before that at Sun, so I'd been working on backend systems for a long time. Back then, by default, when you joined Google you went to the AdWords team, since that's where the money was. I worked on backend there for about a year and a half, and started feeling a bit bored, like I wasn't learning much anymore. So I looked around for anything new happening at Google, and I heard about the mobile team, which at the time had something like five people total. I figured, well, I don't know a thing about mobile, so I might as well join.

Matt Klein: In 2003 that would have been pre-Android, before the acquisition. So what was the mobile team actually doing? Mobile browser, mobile web pages?

Cedric Beust: This was more like 2004 or 2005, so the Android acquisition was getting close, I'll get to that. But you're right that back then all we had were what people called feature phones. Do you remember those? The Nokia candy bar phones, the StarTAC, the Motorola devices. Ironically called feature phones even though they didn't have many features. Very low memory, poor displays, they crashed a lot, and getting the radio to work reliably was its own challenge. Google was exploring porting some of its applications to these phones. We'd meet once a week as the mobile team, and we could all fit in a pretty tiny room. I started thinking about what I could actually do for Google in mobile, and I decided I was going to build Gmail for feature phones. This was pre-Android, so just Gmail on J2ME phones. I started it by myself, the only person on it at first, and the team grew from there. I didn't really know what I was signing up for, since I had zero knowledge of mobile at the time. Programming for these devices was genuinely painful: the development environment was basically nonexistent, extremely constrained memory and CPU, no debugging tools. It was a nightmare. But after about a year and a half, with a team that had grown to around five engineers, we shipped Gmail on feature phones.

Matt Klein: At that time, if you were targeting something like a Motorola RAZR or a Symbian phone, I'd assume they all had different SDKs and libraries. When you say you shipped Gmail on feature phones, was that for all of them, or just one or two? I'm curious how much code was actually shared across all those different SDKs.

Cedric Beust: Surprisingly, quite a lot was shared, because we only targeted J2ME phones, specifically MIDP phones. We didn't touch BREW or the other SDKs that were C only. All we had were Java specialists on the team. Sun had published a real standard here: there was J2ME for mobile phones, J2SE, the standard edition, and J2EE, the enterprise edition, each a different size and scope. Most of the feature phones we mentioned ran J2ME.

Matt Klein: So it sounds like you had one unified API, which should have made it pretty easy to write the same code everywhere, right?

Cedric Beust: Of course not. J2ME turned out to be extremely underspecified. It was easy for any phone vendor to claim J2ME compliance while really only supporting a subset of it, often poorly documented or poorly supported. So there was still a fair amount of device-specific porting required, but overall there was a uniform codebase underneath all of it.

[00:09:12] THE ANDROID ACQUISITION

Matt Klein: So you shipped that, hopefully it worked, and then what happened?

Cedric Beust: We shipped on around 300 devices, and started working on Gmail 1.5, the next version. That's around when the Android acquisition happened. Andy Rubin and his team came on board, and Andy reached out to me pretty quickly. He sat me down and basically said, I'm writing an operating system from scratch, it's going to be based on Java, and we need Java engineers, people who understand the Java ecosystem, because right now my team is mostly C and low-level kernel and driver engineers. That already piqued my curiosity, because that's a pretty open-minded stance. There isn't usually a lot of overlap between people who think every byte of memory matters and people building on a JVM with a garbage collector. But these engineers were genuinely open-minded, and to Andy there was no question the new OS should be based on Java. He told me they needed someone who knew the Java ecosystem well enough to build APIs that Java engineers would feel comfortable with immediately, and that Android would obviously need to run Gmail, which I already knew well on mobile. I didn't need any convincing. Being asked to help build an operating system from scratch is every engineer's dream. So I joined the Android team, stopped working on Gmail for feature phones, and started on Android, which at the time was close to nonexistent as an operating system. It was really starting from the bottom.

Matt Klein: I actually don't know this part. What did Google acquire when they bought Android? I had the impression they were further along, but it sounds like they were still starting from scratch.

Cedric Beust: A bit of both. They had a lot of experience from building the Sidekick, which was a successful phone at the time, and they reused a lot of that architecture, though they had to rewrite the code itself since it didn't carry over directly. A lot of the APIs people use on Android today, things like Activities and Intents, and the overall way the system works, already existed in some embryonic form in the minds of the engineers who were ready to build it. So it started almost from scratch technically, but not from a conceptual scratch.

[00:12:37] WHY JAVA FOR ANDROID

Matt Klein: Before we get into your time on the team, I'd love to ask about the platform choice in general. Android picked Java, Apple started with Objective-C and later moved to Swift, two very different paths. I've heard very different opinions over the years about whether Java was the right call for Android. Based on your experience then and over the last 20 to 25 years, do you still think it was the right choice?

Cedric Beust: Well, obviously it worked out. Whether it could have been something else, I'm not sure. There weren't a lot of strong contenders at the time. Java was starting to be fast enough to run decently on mobile platforms, and we'd already proven that with Gmail for feature phones. The JIT compiler was there and made a real difference in JVM performance. It also mattered that Android rewrote its own VM from scratch rather than using the JVM. You'll never see the word JVM in Android's documentation, partly because of the litigation between Sun and Google over that. But by then Java was fast enough that speed wasn't the biggest concern. Memory is always a concern in a garbage-collected environment, but because the Android team built a VM specialized for mobile, they avoided a lot of the memory pressure and CPU pitfalls you'd otherwise hit. The Java ecosystem was also strong at the time, with a lot of good ideas emerging around application servers, and Sun was riding pretty high. Overall I think it was a great choice, and it clearly worked out well.

[00:14:32] FIVE YEARS BUILDING GMAIL FOR ANDROID

Matt Klein: Let's go back to your time on Android. I'd imagine working on a true version one product like that, with no technical debt to speak of, was every engineer's dream. Take us through what it was like to work on it.

Cedric Beust: It was magical for the five years I was there. We were building the operating system and the apps in parallel, so there was constant back and forth. Sometimes we needed a feature to build the app, whether it was Gmail, Calendar, or something else, and the functionality just didn't exist yet in the OS. So we'd go to the operating system team, which at the time was pretty much all of us, and implement that functionality in Android before we could build on top of it. There were a lot of exciting sessions inventing new things, mixing existing operating system concepts with genuinely new approaches.

There were also interesting dynamics because the relationship between Google and Apple was starting to get contentious. We knew they were working on the iPhone. Eric Schmidt, Google's CEO at the time, was on Apple's board and had roughly weekly meetings with Steve Jobs. He'd come back regularly and tell us a bit about how Jobs felt and what they were doing, while also telling us to ignore as much as possible of anything we heard about the iPhone, which was still very under wraps. Steve Jobs had made it very clear to Eric that we weren't allowed to use any of Apple's ideas, and if we ever started infringing, there'd be a problem.

Matt Klein: I'd imagine that even then, you were preparing for or knew you'd eventually have Gmail on the iPhone, which creates an interesting dynamic. You want your own platform to be the best, but the iPhone had massive market share too, so you'd also want Google apps to run well there.

Cedric Beust: What you're describing wasn't really true yet at that point. We had no idea what the iPhone was actually going to be. When it came out, it didn't have an SDK or third-party apps at all. Version one only allowed Apple's own apps, and you were supposed to build web apps if you wanted to extend it. Steve Jobs changed his mind for version two, probably partly under pressure from Android, since we launched with a store and support for third-party apps from the start. I'm not sure how much of an impact that actually had on his decision, but he clearly saw the writing on the wall. By the time iPhone 2 shipped with third-party app support, I don't think the Android team was particularly interested in writing apps for it, partly because it also took a while for the iPhone to really take off in the market.

Matt Klein: While you were on the Android team, were you mostly focused on the operating system, the Gmail app, or both? I'd imagine over five years you touched various pieces.

Cedric Beust: For the first year, I was doing a bit of everything, like everyone else on the team: contributing to operating system decisions while building the app in lockstep with it. But the team grew quickly, and after about a year we had more independent teams working on specific sections, so people naturally settled into their own lanes. By then things were getting more solid from a foundational standpoint, so I focused more and more on the app itself.

Matt Klein: So for the five years you were there, you were mostly working on the app side?

Cedric Beust: That's right. Until I left I was working on Gmail for Android, though the last year I was on a different app.

Matt Klein: From an engineering perspective, did you have a preference for working on the app versus the operating system? They seem like very different disciplines.

Cedric Beust: I would have been interested in either, honestly, but there were so many interesting problems building Gmail on Android, especially since we were writing the view system at the same time. We were able to shape the view system specifically to enable what Gmail, Calendar, and the other apps needed. I never found myself wishing I was working on something else. Every day was a new challenge and new problems to solve. No regrets there at all.

[00:20:15] A FAVORITE BUG STORY

Matt Klein: Before we move on, I love asking people about their favorite bug from that time. Is there one that stands out?

Cedric Beust: Not from that specific time, but I can tell you about one from an earlier job that I still remember vividly. I was working on WebLogic application servers, and one of them was a web server generating Base64 strings in URLs to capture cookies and similar data. We got a bug report saying there was profanity in the URLs we were generating. We were pretty confused, so we asked for an example, and sure enough, right in the middle of this long string of characters were the letters F-U-C-K, clear as day. Looking at the code, it turned out to be pure randomness. If you generate enough of these strings, eventually you're going to get something like that. We were absolutely cracked up by it. The fix was easy: we disallowed vowels, so from that point on all WebLogic URLs contained only consonants, and that solved the problem. Not really a bug in the traditional sense, but I love telling that story, it still haunts me in a good way.

[00:21:51] LEAVING GOOGLE FOR LINKEDIN AND A STARTUP

Matt Klein: You eventually left the Android team. What led to that, and what did you do next?

Cedric Beust: It was actually a hard decision, because honestly I could have spent the next 30 years at Google and retired a happy engineer. There's no better place for an engineer to be, at least at the time, I don't know what it's like today. But I'd been in Silicon Valley for about 12 years and had never experienced a startup, and I still felt a bit of fire in me, a curiosity to try something new. So I decided I needed to do it before I fully settled into my comfort zone. The plan was to work toward the startup experience over the following years, building something from the ground up on a very small team. The first six months after leaving Google, I second-guessed myself constantly, thinking I'd go back because I missed it too much. But I held strong and eventually made peace with the decision. After Google I went to LinkedIn, not quite a startup, but still fairly small at the time, around 500 people, kind of a smaller version of what Google had been about ten years earlier. After that I got my actual startup experience, joining a team of four people in a tiny office in downtown Palo Alto, building something from scratch.

Matt Klein: How did that go?

Cedric Beust: The startup did okay. We worked on it for a couple of years, grew to about 30 people, and were eventually acquired by LinkedIn, of all places. So I went from LinkedIn, to that startup, and then LinkedIn acquired the startup.

Matt Klein: When you first went to LinkedIn, were you working on mobile again, or did you go back to backend systems?

Cedric Beust: That's actually the exact question the person I reported to asked me. They said, we have a nascent Android team, you're welcome to take the lead there. My answer was no. I'd just come out of five years of Android and mobile work, and I wanted to do something different, not because I hated mobile, just because I wanted a change. So I went back to backend, then switched into infrastructure and helped build out their testing infrastructure, since testing is also something I've had a long-standing interest in. Whenever I change jobs, I try to change at least one meaningful variable so I feel like I'm actually learning and growing, not just repeating myself.

Matt Klein: What did the startup that LinkedIn acquired actually do?

Cedric Beust: The product was genuinely interesting, though looking back it was pretty hard to pull off. The idea was to help you meet new people better. If you're in HR, recruiting, sales, or marketing, you often have meetings with people you barely know. We'd gather intelligence on that person and generate what we called a dossier, essentially a file with as much publicly available information as we could find: what school they went to, maybe a vacation photo from their public Facebook wall, mutual connections, that kind of thing. It was a genuinely challenging idea and we pushed it pretty far. This was around 2013 or 2014, so nothing like the LLMs and AI we have today.

Matt Klein: That almost sounds ahead of its time given what's possible now. What were the biggest problems you ran into, technical limitations, or just that the information wasn't public enough?

Cedric Beust: A mix of both. We only accessed public information, though for some social networks we had tokens or keys that gave us a bit more access. But fundamentally, we were at the mercy of the major social networks. We were querying over a hundred different networks, but realistically the ones that gave us the most useful information were LinkedIn, Facebook, and Instagram, or Pinterest, the big ones. If any of them decided to throttle us, and throttling was a constant concern, or cut us off entirely for exceeding their API terms, that could shut us down.

Matt Klein: When it got folded into LinkedIn, did the product get killed, or was it absorbed into the platform?

Cedric Beust: It got absorbed. LinkedIn was already heading in a similar direction, I think we just got there first, which is probably why we caught their attention. But they already had all the underlying data we were relying on, so they were in a much better position to build on the idea. I decided not to join LinkedIn afterward, so I'm not entirely sure what became of the product, but I'd guess they killed it directly while folding some of the concepts into LinkedIn itself.

Matt Klein: Did you not join because moving to a big company again after the startup felt like too much of a step back?

Cedric Beust: Not at all. I did want to go back to a big company, I just didn't want to go back to LinkedIn specifically. It wasn't new to me anymore, and I wanted something different.

[00:28:16] YAHOO AND MOBILE ARCHITECTURE

Matt Klein: What was next?

Cedric Beust: Yahoo. I went back to mobile this time, joining as a mobile architect, working closely with a former colleague from the Android team who was already there and had sold me on the role. He was right, I had a fantastic time there for a few years. This time I was operating at a higher level as an architect, no longer hands-on day to day, though I stayed hands-on in my personal time. I wasn't writing production code during the workday anymore, but I was still doing a lot of reviews, design work, and advising teams on direction, crash reduction, performance, and building more responsive apps.

Matt Klein: I feel like that timeframe is roughly the mid-2010s. A lot has changed in the last ten years in general, but I feel like a lot of the problems inherent to mobile development haven't actually improved much. I find that interesting, since in most areas of our industry, technology changes so fast. I'd love to hear what the big problems were at Yahoo back then, and how many of those are still problems today.

Cedric Beust: You're spot on, and this is really the area you work in, so you'd know. The problems I was trying to solve at Yahoo, we had similar versions of them five or ten years before that, and I still have many of the same problems today at my current job. Crash rates, performance, animation speed, app size, authentication, logging, all of it. These transcend mobile specifically, they're just persistent problems. We solve them a bit better each time, but there's still no silver bullet for any of them. It still takes a lot of human effort, and now a bit more AI to help, but it still takes real time to get right.

Matt Klein: Certain things have clearly improved. We have better tooling for dealing with large codebases, though I'm not always sure how much better. But I'd argue observability capabilities haven't improved as much as they should have, and I realize I'm biased there given what we do.

[00:31:47] JOINING JPMORGAN CHASE

Matt Klein: Let's step back briefly. You were at Yahoo, did a few other jobs, and now you're at JPMorgan Chase. How did you end up there, and what are the big problems your teams are facing right now, whether specific to JPMorgan Chase or not? And how many of those overlap with problems from earlier in your career versus being genuinely new?

Cedric Beust: How I ended up there was mostly curiosity again. I was looking for my next role, and I'll skip over a couple of companies in between, but I always approached a job search wanting to do something different. JPMorgan Chase reached out, and I thought, a bank, that's interesting. There was also something in the back of my mind. As someone who immigrated to the US about 25 years ago, you have to learn a lot beyond just the language: the culture, the financial system, how banks work, credit cards, checking accounts, investment accounts. Everything was different from France, so like most immigrants I took a crash course just to understand the basics and not do anything foolish with my money. But I always felt I'd only ever learned the surface level, and it bothered me. I'd always wanted to understand the US financial system more deeply, partly for my own investments, but also just for the sake of learning something new.

So when JPMorgan Chase reached out, that curiosity came right back. I went through the interview process a bit skeptical, thinking, I've worked in Silicon Valley on bleeding-edge technology, what could a bank offer that's technically interesting? I was proven wrong quickly. The way I was interviewed, what was disclosed to me, the people I talked to, all of it made me realize I needed to change how I was looking at this. These people clearly knew what they were doing.

Matt Klein: I've had that same bias myself, and getting more exposed to companies outside Silicon Valley really opens your eyes to how sophisticated people are working in these vertical industries. One thing I think about with banking, and I haven't worked in it myself, is that a lot of Silicon Valley companies, no matter how much scale we like to talk about, are ultimately serving ads or social feeds. If they fail, it's genuinely not that big a deal. In banking, that's absolutely not the case. These systems have to be extremely reliable. I'd love to hear what it was like moving from companies where reliability is talked about a lot but doesn't always carry real weight, to a world where it matters enormously.

Cedric Beust: The first thing I noticed was that from a mobile standpoint, what we're doing at JPMorgan Chase is very similar, almost identical, to every other company I've worked at. Everyone in mobile deals with the same fundamental problems and similar technologies. There's choice in vendors and SDKs depending on your needs, but the core functionality and requirements are largely the same, so it felt comfortable right away, not a brand new world, just one with additional constraints. There's regulation, and you have to be far more careful about certain things. If Instagram has a bug and someone's feed shows the wrong article, that's not a big deal. If we miss a transaction or duplicate a money transfer, that's a very big deal, not just in terms of money lost but liability with real consequences. That was part of my interest too: understanding how to run a mobile business with those added constraints without letting them get in the way of shipping good software. I've learned a ton in that area.

[00:38:12] OBSERVABILITY, CRASHES, AND PERFORMANCE

Matt Klein: I'd guess you'd agree there are common themes across mobile teams: slow builds, observability problems, reliability problems, performance problems, but every team seems to focus on different things depending on what's hurting most at the time. What are the biggest problems your teams are facing today, and how does that connect back to your earlier roles?

Cedric Beust: We keep coming back to observability. That's still where the main pain is for me after all these years. We have a lot more visibility into what apps are doing now, but it's still a pain to extract and interpret that data. We haven't made as much progress there as I'd expect. The core issue is that I don't want to fly blind. I don't want to ship an app and have no idea what users are actually doing, only finding out reactively once there's a crash. Ideally I want to understand what's leading to a crash well before it happens, and I also want to understand what users are doing when things go well, since that informs how we improve the product. We have a lot more tooling now for observability, and we upload a huge amount of telemetry, the volume of data going into Splunk and similar systems, and the associated cost and bandwidth, is honestly mind-boggling. That comes with its own problem: once you have that much data stored somewhere, how do you retrieve it, slice it, and interpret it in a way that actually informs decisions? We're still pretty early in figuring out how to do that well.

Matt Klein: I'd imagine across JPMorgan Chase's stable of apps, your crash-free rate is quite strong, since most established apps don't crash often anymore. But as I like to point out, there are plenty of other problems beyond crashing: UI hangs, performance issues, force quits, and so on. Are your teams still primarily focused on crash-related issues, or are they starting to look more broadly at both the good and bad user flows, understanding where users get stuck or fail to convert, separate from crashes entirely?

Cedric Beust: Crashing is still critical, that's how apps live and die in store reviews, so you shouldn't crash too often. I'm happy to say we're doing pretty well at Chase, and that's not me patting myself on the back, since a lot of the infrastructure that makes our crash rates the lowest I've seen in my career was already in place before I joined, even better than Yahoo, which was already impressive in that area. We monitor those numbers constantly, but they rarely go red, so they're not a huge drain on resources anymore. The bigger elephant in the room is performance. You can never have too much of it. With crash rate, at some point you hit diminishing returns, maybe users see one crash every three years, and you can shift to monitoring gates and alerts rather than dedicating heavy engineering effort there. Performance is a daily, endless battle, because even if you're in great shape on day one, every new batch of code that ships could be quietly affecting it.

Matt Klein: One thing I love asking people is, anecdotally we all believe that better-performing apps lead to happier, more engaged users, but how do you actually prove that? The industry likes to claim it's driven by numbers. You can spend your whole career on performance, but there's clearly a point of diminishing returns. How do you know where that is, and how much of your target is subjective versus tied directly to conversion metrics?

Cedric Beust: For performance, a lot of it is quantitative, and the qualitative experience follows from the numbers. If your app is fast enough, users feel like it's responsive. Overall satisfaction goes well beyond performance, it's also about how your UI is structured and how easy it is to use, but you need to be fast enough as a foundation. If a user taps to launch the app and it takes seven seconds to show anything, that's a real problem, and there are apps on both app stores today with hundreds of millions of downloads that take five seconds just to display a static page. That's unacceptable to me. You start with the basics: launch time is the most important thing, then animation and transitions need to feel responsive, widgets need to react quickly and give feedback, scrolling needs to be smooth with no jank. Once all of that is solid, you can look at the bigger picture of how the app holds together as a whole, especially for anything complex enough that users need to be able to find their way around easily.

Matt Klein: Do your teams track a set of core performance numbers, maybe five, ten, twenty of them, and QA aggressively against those? And how much of your performance process is local QA testing versus monitoring real-world performance, given that emulators and test devices never fully capture the range of RAM, disk space, and device variation you see in production?

Cedric Beust: You have to set goals, and they can be somewhat arbitrary at first. If launch takes four seconds, you might say, by the end of the year we need to get to two seconds, and once you hit that, push further to 1.5, while watching for diminishing returns where you're spending a lot of effort for very little benefit. You can pull numbers from industry benchmarks or from testing competitor apps to set a reasonable target. But that's only half the battle. The harder part is staying there. We have a lot of automated testing in place, but there's a real gap between what we measure in QA, with maybe a few hundred people or beta testers, and the scale we ship at in production at JPMorgan Chase, which is a completely different order of magnitude. What we want is for our QA numbers to closely predict what we see in production. When those numbers start consistently matching, we gain confidence that we won't be blindsided by a release that tanks in ways we didn't see coming. That's my nightmare scenario.

[00:47:36] AI, SKILL DEVELOPMENT, AND THE NEXT GENERATION

Matt Klein: In the time we have left, I'd be remiss not to ask about AI, either in the context of how your teams use it or your own personal usage, and where you think things are headed.

Cedric Beust: No secret, everybody uses AI, and JPMorgan Chase is no different. We're heavily invested and use it across a lot of different areas, though I can't get too specific. Personally I've been a believer from day one, even though the early results were fairly underwhelming. But the times it got things right were genuinely mind-blowing, and it was easy for me to project forward, since these systems don't get worse over time, they get better. So I got interested early and use it in my personal coding too. The ambiguity for me is that while I appreciate the help, I'm also worried it's going to atrophy my own skills. It's easy to get lazy and just ask an AI tool to write something instead of writing it myself. Very often it's close to correct, maybe 90 percent of the way there, and I can still use my own judgment to review it, so I feel like I'm still participating, but it leaves me a bit unsatisfied. I try to keep a clear separation: I'll ask AI to handle things I don't have much interest in or that I find boring, but I still write the things that are genuinely interesting and challenging to me.

Matt Klein: Something I think about a lot myself is that things have really shifted in the last three to six months. The tools have gotten good enough that I barely write code by hand anymore either. But you and I have been doing this a long time, and we know what good code and good systems look like because we've written a lot of them ourselves. What concerns me most is that we're not going to be working forever. What happens to the next generation? I don't believe software engineering is dying, I think these are incredible tools and we'll need as many engineers as ever to actually wrangle them well. But I genuinely don't understand how you train people who've never done it by hand. You must hire a lot of people at JPMorgan Chase, so I'd love to hear how you think about skill development in this new environment.

Cedric Beust: I'm worried, not for us, we're close enough to the end of our careers that even if AI eventually reshapes or replaces parts of our jobs, we've had the run. I have kids approaching college who'll be entering the workforce in the next few years, and I worry about whether they'll get the same opportunity I had, to work in something they're genuinely passionate about and also make a good living from it. I feel incredibly lucky to have had both of those at once. I hope they get that too, but you're right that we're in the middle of a real transformation. Software engineering isn't going away, but it's going to look very different in ten years, and honestly I don't have great visibility into what that looks like. Some people say the new code will essentially be prompts, specifying intent in English or in markdown and letting AI generate everything underneath, the same way we've trusted compilers for decades to generate code we never actually look at. There's something to that parallel, though it's not perfect, since AI today isn't nearly as predictable as a compiler. Still, we've relied on systems generating things we don't fully comprehend before, just not at this magnitude. I think we're going to witness something as transformational as the early internet was, another moment where things are simply never the same afterward.

Matt Klein: I agree, it's incredible technology and it isn't going anywhere. Even if we're in a bubble right now, and I think we probably are, the underlying technology is real and durable, much like the internet era. But this one feels different to me because right now, getting real productivity out of these tools still relies heavily on people who already have deep experience. When you don't have that experience yet, it's not obvious how you bridge the gap, and I think that's a problem the industry is increasingly going to have to face. That's probably a good place to wrap up. Any parting thoughts you'd like to leave people with?

Cedric Beust: Not really, it was a pleasure talking with you. I'm still very excited about this profession, still very much in love with technology, computers, and coding in all its forms, and I hope I get to keep doing it for a long time, now with this new addition of AI in the mix. Thank you for having me.

Matt Klein: Thank you very much for joining, and we somehow got through this whole conversation without talking about Rust, even though I know you're a Rust fan, but there's only so much time. Thank you so much for joining, this was a fantastic conversation. That's a wrap for this episode of Beyond the Noise: Signals, Stories, and Spicy Takes. Huge thanks to Cedric for joining and sharing his story. You can find this episode and all past ones on the bitdrift YouTube channel. If you had fun, drop us a review, tell your friends, or yell your favorite hot take into the void, and make sure to tag us. I'm Matt Klein, and I'll see you next time.

Cedric Beust: Thank you.