When the cost of code approaches zero, what does engineering leadership look like?​​​​‌‍​‍​‍‌‍‌​‍‌‍‍‌‌‍‌‌‍‍‌‌‍‍​‍​‍​‍‍​‍​‍‌​‌‍​‌‌‍‍‌‍‍‌‌‌​‌‍‌​‍‍‌‍‍‌‌‍​‍​‍​‍​​‍​‍‌‍‍​‌​‍‌‍‌‌‌‍‌‍​‍​‍​‍‍​‍​‍‌‍‍​‌‌​‌‌​‌​​‌​​‍‍​‍​‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‍‌‌‍‍‌‌​‌‍‌‌‌‍‍‌‌​​‍‌‍‌‌‌‍‌​‌‍‍‌‌‌​​‍‌‍‌‌‍‌‍‌​‌‍‌‌​‌‌​​‌​‍‌‍‌‌‌​‌‍‌‌‌‍‍‌‌​‌‍​‌‌‌​‌‍‍‌‌‍‌‍‍​‍‌‍‍‌‌‍‌​​‌​​‌​‌‌​‌​‌‌‌‍‌‌‌‍‌‍‌‍‌‌​​​​‍‌​‌‌‍‌‍​‍​​‍‌​‍‌​‌​​​‌‌‍‌‍‌‍​‌​‍‌​‍​​‌‌​‌​‍​​‍‌​‍‌‌‍​​‌​‌‍​‍​‍​​​‌​‍‌‌‍‌‍‌‍‌‍‌‍‌‍​‌‍‌‍​‍​‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‌​‌‍‍‌‌‌​‌‍​‌‍‌‌​‌‍​‍‌‍​‌‌​‌‍‌‌‌‌‌‌‌​‍‌‍​​‌‌‍‍​‌‌​‌‌​‌​​‌​​‍‌‌​​‌​​‌​‍‌‌​​‍‌​‌‍​‍‌‌​​‍‌​‌‍‌‍​‌‍‌‌​​‍‍‌​‌‌​‌‍​‌‌‍​‌‍‍‌‍‌‌‍‌‍‌‌‌​‍‌‍‌‍‌‍​‌‍‌‌​‍‍‌‍​‌‍​‍‌‍‌‍‍‌‌‍‌​​‌​​‌​‌‌​‌​‌‌‌‍‌‌‌‍‌‍‌‍‌‌​​​​‍‌​‌‌‍‌‍​‍​​‍‌​‍‌​‌​​​‌‌‍‌‍‌‍​‌​‍‌​‍​​‌‌​‌​‍​​‍‌​‍‌‌‍​​‌​‌‍​‍​‍​​​‌​‍‌‌‍‌‍‌‍‌‍‌‍‌‍​‌‍‌‍​‍​‍‌‍‌‌​‌‍‌‌​​‌‍‌‌​‌‌‍​‍‌‍​‌‍‌‍‌‌‌​​‌‍‌​‌‌​​‍‌‍‌​​‌‍​‌‌‌​‌‍‍​​‌‌‌​‌‍‍‌‌‌​‌‍​‌‍‌‌​‍‌‍‌​​‌‍‌‌‌​‍‌​‌​​‌‍‌‌‌‍​‌‌​‌‍‍‌‌‌‍‌‍‌‌​‌‌​​‌‌‌‌‍​‍‌‍​‌‍‍‌‌​‌‍‍​‌‍‌‌‌‍‌​​‍​‍‌‌

Eric explains how Intuit rolled out Claude Code across the entire organization, why PMs are now merging their own PRs, and what it means for engineering culture when product/engineering roles start to converge. Eric and Ben unpack the engineering skills that matter most in an AI-first industry and why the work of developing junior talent has gotten harder. Eric also shares how he personally uses AI to manage his inbox, synthesize specs, and run promotion processes (but why he stopped letting it send emails on his behalf). Connect with Eric on LinkedIn. TRANSCRIPT Eira May: Hello and welcome to Leaders of Code. If you are joining us for the first time, this is a segment on the Stack Overflow Podcast where we get senior engineering leaders together and we talk with them about the work they're doing, how they build their teams and the biggest challenges they have in front of them right now. My name is Eira May. I'm the B2B editor at Stack Overflow and I'm here again with my colleague, Ben Matthews, who is engineering director at Stack Overflow. Ben, thanks for coming back on the show with us. Ben Matthews: Thanks for having me. Excited to be here. Eira May: Absolutely. Our guest today is Eric Anderson. Eric is director of engineering at Intuit. Eric, thanks so much for joining us. How's it going? Eric Anderson: It's going great. I'm super excited to talk to you all. Thank you. Eira May: Amazing. I'll jump right in. I know we have a lot that we've been wanting to talk about and I wanted to start by just thinking about something we've had very much at the forefront of our minds at Stack, which is the importance of human critical thinking in relation to coding speed. When AI tools are making code generation essentially instantaneous, we need to think about human critical thinking, I think, and context and oversight in a different way. So I wanted to start by asking you, Eric, in your work with your teams, how are you thinking about balancing that, the speed benefits of AI tools against that need for human critical thinking? Eric Anderson: I would say that it's this incredibly interesting time in the industry right now because never before, I've been doing this a number of decades and I would say never before has the incremental cost of a line of code been cheaper. It essentially is about the most inexpensive thing of anything that we do in terms of software development is actually produce code. And what that's really created is this very interesting dynamic where it used to be that coding was the thing you were always worried about from a scheduling perspective, from a risk management perspective, from a rollout perspective, from a rollback perspective. And now we've started to really look at how do we reshape how we work? What does it mean to actually build a feature? What is a system design? What are the skills that engineers need in the organization to be successful? Because if you're a rockstar programmer, that's not necessarily the thing that is going to make you a rockstar software engineer in this new day and age. And so I think it's a really exciting time to be a software engineer. I think that in many ways, a lot of folks a while ago were saying like, "Will software engineering go away?" It's like, I think we're making more software every day now than we ever have. I just see the need for software development, software architecture, software resiliency, support, engineering, all of these things becoming more and more and more. And I think to the core of your question, at the heart of all of that is a human that actually has to make high judgment decisions about the best way to put this code together and make sure it generates value for customers. Ben Matthews: I'd love that, especially the insight into a cost. The cost per line of code now has never been cheaper. And I think that's the resounding thing of how mindsets are going to have to maybe change of how we look at things. I think the big question that's challenging us everywhere is, well, how do we measure effectiveness now? How do we measure how well an engineer is performing? How well are we measuring the quality of a product? We see a lot of companies bragging that we've generated X million lines of code now just through AI. And that is impressive not to take away from that, but is that the real thing to measure? Is that how Intuit looks? Eric Anderson: We have a lot of metrics that we use here, PRs, CRs, numbers of reviews, lines of code, all those kind of traditional metrics I think are still relevant and interesting, but ultimately the metric that was and continues to be the most important one is whatever we did in the technology, did it generate customer value and how do we measure that? And I think that the speed with which we can actually put things into the production environment, explore different variations of things. We do a lot of experimentation inside of Intuit around, does this version of this experience work better than that version? We don't have to choose anymore. Can we do two experiments? Can we do five experiments? Can we do nine experiments? Can we do 900 experiments? We actually have the optionality of experimentation has become much greater and I think that's really very super exciting because now we're not just getting at like, okay, these are great ideas. How can we actually try them all out? How do we try them all out with velocity? How do we actually get the right metrics and instrumentation in place? It's much easier to do that now. And ultimately what we want to do is really deliver value for customers. And I think that's still the same metric that existed five years ago, 10 years ago, today, tomorrow, five years from now. It will be, we will build all this technology to make someone's life job activity better, happier, easier and make an improvement. And so I think it's the same thing. And it goes back to, I think, the core of this talk we're having, which is humans have always been at the center of software engineering. And so I think it really is even more so now super important that engineers are really empathetic and in tune with who their customers are and what's important to them because they're so much more easily able to have impact on that customer experience than they ever have before. Ben Matthews: Yeah. I especially love that idea that we're here to create things that people want to use. I think when you say it's still a human experience, I would say in how we consume it and how we generate it, that's still very much a human adventure. And I'm reminded to really date myself back when people thought like, oh, who's really engineers anymore of like when IDEs came out and all these integration tools and all these other tools of like, what do I do as an engineer? And that continues to evolve. I think this is another phase of that of we have to figure out what does an engineer do? What are those skill sets? Is it now more playing like coach and how you're getting your agents to work together? How much of that is understanding the system? So when you mentioned the speed part is what's really exciting, what do you think is the new bottleneck? Before is how fast could we generate code was classic, not always, but classically one of the bottlenecks. What do you think is going to emerge as the new bottleneck? Eric Anderson: We just had a big planning exercise with my organization a couple of weeks ago. We actually started the planning process saying, let's go build a Q4, a quarterly roadmap. And we said, "Let's not do that. Let's actually reimagine what it will take to deliver that roadmap." Because when I start to look at backlogs across my teams, what I started to realize was that we were thinking too small and what we could look at and be like, "Yeah, we can do all of this and more." And so really you start to really change the conversation around, okay, where is design? Do we have enough designs? How are we going to work through design iterations more quickly? Where's product? Where are product requirements? Do we need really sophisticated product PRD documents with all kinds of nuance and details documented out? Or do we need sketches of what we want to try and then actually then co-develop with a PM and an engineer a bunch of different scenarios for a particular feature? And so I think where do we see the bottleneck? The bottleneck is really in the ideation process to get from, "Hey, here's a cool idea that it solves a customer problem." to, "Here's something running in production." And trying to figure out how to retool a lot of those working relationships, experiences, handoffs, what does it mean to be designed complete in an era where it doesn't really matter. We can change the design tomorrow and build a new one. It's fine. And so I think that's more of where the bottleneck is the process of constructing the software because I remember when Scrum became the way that you did software engineering and you had product owners and Scrum masters and it was really transformational in terms of moving from this waterfall approach to more of an agile iterative approach. I think now we're in a new approach and we don't really know how to do it well, I would say. We're experimenting and learning through the process, but I think that's very much what I see the bottleneck is today is the process itself is slowing us down. And so I think teams are having to go back and retool and depending on what they do, if they build a front end store experience, they can probably do a gazillion... They need to think about it one way. If you're talking about a backend team that focuses primarily on large scale data pipelines and sort of mission-critical data ingestion, they're probably going to have to think about doing it another way. And so I think we're in this, again, really interesting time where we're re-imagining what it takes to be a really successful software organization. We've gone from a tool to a completely different tool t