Eric Anderson, director of engineering at Intuit, 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 and engineering roles start to converge. Eric and Ben Matthews unpack the engineering skills that matter most in an AI-first industry and why developing junior talent has gotten harder.
Eric also shares how he personally uses AI to manage his inbox, synthesize specs, and run promotion processes — and 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 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: 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: I’ll jump right in. I know we have a lot that we’ve been wanting to talk about, and I wanted to start with something we’ve had very much at the forefront of our minds at Stack — 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, context, and oversight in a different way. So I wanted to ask you, Eric: in your work with your teams, how are you thinking about balancing the speed benefits of AI tools against that need for human critical thinking?
Eric Anderson: I would say that it’s an incredibly interesting time in the industry right now. I’ve been doing this for a number of decades, and never before has the incremental cost of a line of code been cheaper. It essentially is the most inexpensive thing we do in software development — actually producing code. And what that’s created is a very interesting dynamic. It used to be that coding was the thing you were always worried about from a scheduling perspective, a risk management perspective, a rollout perspective, 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 to be successful? Because if you’re a rockstar programmer, that’s not necessarily what’s going to make you a rockstar software engineer in this new day and age.
I think it’s a really exciting time to be a software engineer. A while ago a lot of folks were asking, “Will software engineering go away?” I think we’re making more software every day now than we ever have. I see the need for software development, software architecture, software resiliency, support engineering — all of these things — growing more and more. And at the heart of all of that is a human who has to make high-judgment decisions about the best way to put code together and make sure it generates value for customers.
Ben Matthews: I love that insight into cost. The cost per line of code has never been cheaper, and I think that’s the resounding thing that’s going to change mindsets. The big question challenging us everywhere is: how do we measure effectiveness now? How do we measure how well an engineer is performing, or the quality of a product? We see companies bragging that they’ve generated X million lines of code through AI, which is impressive, but is that the right thing to measure? Is that how Intuit looks at it?
Eric Anderson: We have a lot of metrics we use here — PRs, code reviews, number of reviews, lines of code — all those traditional metrics I think are still relevant and interesting. But ultimately the metric that was and continues to be most important is: whatever we did in the technology, did it generate customer value and how do we measure that?
The speed with which we can put things into the production environment and explore different variations is really exciting. We do a lot of experimentation inside Intuit around whether one version of an experience works better than another. We don’t have to choose anymore. Can we do two experiments? Five experiments? Nine? Nine hundred? The optionality of experimentation has become much greater. We’re not just asking whether these are great ideas — we’re asking how we can try them all out with velocity, and how we get the right metrics and instrumentation in place. That’s much easier to do now.
Ultimately what we want is to deliver value for customers, and that’s the same metric that existed five years ago, ten years ago, and will be true five years from now. Humans have always been at the center of software engineering, and I think that’s even more true now. Engineers need to be 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: I especially love the idea that we’re here to create things people want to use. This is still a very human adventure — both in how we consume software and how we generate it. It reminds me of when IDEs and integration tools came out and people asked, “What do engineers even do now?” That continues to evolve. What do you think is the new bottleneck? Classically, one of the bottlenecks was how fast we could generate code. What do you think is going to emerge to replace that?
Eric Anderson: We just had a big planning exercise with my organization a couple of weeks ago. We started by saying, let’s build a Q4 quarterly roadmap. And then we said, “Let’s not do that. Let’s actually reimagine what it will take to deliver that roadmap.” When I looked at backlogs across my teams, I realized we were thinking too small. We could do all of it and more.
So the conversation really shifts to: where is design? Do we have enough designs? How are we going to work through design iterations more quickly? Where are product requirements? Do we need sophisticated PRD documents with every nuance documented, or do we need sketches of what we want to try and then co-develop a bunch of scenarios with a PM and an engineer together?
The bottleneck is really in the ideation process — getting from “here’s a cool idea that solves a customer problem” to “here’s something running in production.” We’re trying to figure out how to retool a lot of those working relationships, handoffs, and processes. What does it mean to be design-complete in an era where we can change the design tomorrow and build a new one?
I remember when Scrum became the way you did software engineering — product owners, Scrum masters, moving from waterfall to agile. That was really transformational. I think we’re in a new transformation now, and we don’t really know how to do it well yet. We’re experimenting and learning. The process itself is what’s slowing us down. Teams building a front-end store experience need to think about it one way. A backend team focused on large-scale data pipelines and mission-critical data ingestion needs to think about it another way. We’re re-imagining what it takes to be a really successful software organization.
Ben Matthews: I love that. The process is what’s going to evolve. I’m extremely confident that in four or five years we’re going to look back at how we’re using these tools now and think about how naive we were. The process is still forming, and we’re learning what the new normal will be. Organizations that push that boundary — that step back from the paved road and forge new paths — are going to lead the way. How do you approach that mindset? And how do you get other stakeholders and departments aligned with that kind of experimentation, not just in code but in process?
Eric Anderson: At Intuit, we have a very collaborative culture. Teams come together with their own points of view from their areas of expertise — design, product, data science, applied science, software engineering — and really work backwards to solve customer problems. Over the last couple of years, many people have come into my office with strong opinions about how AI will reshape how we work, and those conversations have become the foundation for how we’ve approached rethinking our processes together, across disciplines, rather than in isolation.
