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 that makes it so much easier to produce all of these types of application experiences.
Ben Matthews:
Yeah, that's great. I love the fact that the process is I think what's going to evolve. I'm extremely confident in four or five years we're going to look back at how we're using these tools now and think like, how naive we were. The process is still forming, we're learning what the new normal's going to be. And I think a lot of organizations that try to push that boundary of like, let's rethink things, let's step back from this paved road and we're going to have to forge new paths. I would also love to explore the mindset of how you tackle that because I think you're talking about it in a very open-minded way of trying to reassess these things and does that just go back to experimentation, not so much just in code, but in processes and how do you get other stakeholders and other departments in line with that?
Eric Anderson:
I'll say it at Intuit, we have a very collaborative culture and teams really come together with their own points of view from their areas of expertise, design, product, data science, applied science in software engineering, et cetera, and really work backwards to solve customer problems. I've had many, many people come into my office over the last couple of months and we rolled out Claude Code to the entire organization. I had one of our designers come in and say, "Well, I set up Claude Code. Where do I check in the code now?" And I said, "Okay, what problem are we trying to solve?" And they're like, "I don't know. I just need to know where to put the code now that I have the Claude Code thing to do." And so I think in many ways it's really clarifying expectations around this is where we think some of these processes can be changed fundamentally.
So we have PMs now producing PRs that go into our code base and get reviewed by an engineer and they go out as an experiment. That's great. Actually, there's no engineers doing any work there other than a PR review and that's fine. We also have engineers still building wholesale features. What I would say is really important to us is keeping that experimental learning mindset and understanding things are going to change, things are going to evolve. We don't have all the answers today and whatever we think is great today, tomorrow may actually be completely different and that's all okay. And so everybody needs to be flexible in how they're thinking about things. I also think not necessarily challenging, but really being open to the idea that roles are blending and so PMs can now be engineers, engineers can now be PMs.
I've always been a big proponent of engineers and PMs being just two sides of a coin and you have very technical PMs and you have very product minded engineers and you can, in very small organizations, oftentimes they're the same person and in bigger organizations they get more specialized, but they still have a particular shared understanding. And I think that these tools are really opening up a lot of pathways and avenues for those types of experiences, which is great. I also think that, and I emphasize this with my teams, which is ultimately this is no different to me than going from eMax and VI to Eclipse and IntelliJ, you know what I mean? To now a tool that's just even more robust in terms of the ability to produce high quality structured tech code. You still own it operationally. It still has to go through CICD deployment pipelines. It still has to be supportable and maintainable and instrumented and we still have to have metrics and performance.
And so to your point of, how do you get everyone bought into these things? It's not so much a buy-in as much as it is. It's opening up the aperture around what it means to build mission-critical, high quality software across the board. Engineers are learning about product, designers are learning about code. Product managers are learning about operational excellence and how all these things come together and it's been great. It's really helped people understand what are some of the constraints that exist in the teams and why things are hard to do sometimes and really helped I think people have a much better, even more sense of shared empathy across disciplines and skillsets and that's actually helped accelerate a lot of conversations because now it's like, "Oh, now I get why that's super hard." Okay, let's do it this way. And they're like, "Totally, let's do it that way."
Ben Matthews:
Yeah, I think empathy is a great word for it, of pulling back the curtain of where some of those responsibilities and frustrations lie. And as you mentioned before, the ideation process evolving and people are now able to be technical that weren't so much before. I think especially in the ideation process where I'm having really satisfying experiences is before when we tried to translate business requirements or what we want to do. Now I can have PMs or designers say like, "Well, let me just whip something together real quick." And then they can actually show the interaction, show what they want that to look like very quickly and people can touch it. Would I ship that code to production? Probably not, but is that a quick shortcut into getting us something that is there? Absolutely. And I mean, that's an exciting time.
And when you talked about running nine experiments or 900, I think that it also goes to the number of things that we can tackle all at once. I challenge a lot of the leaders all the time when I talk to them about it of, "Do we need less engineers?" Well, if you need less engineers now, the problem is you can't think of enough things to build or to work on. That's the challenge. How do I utilize all these engineers that are now super powered? And I think trying to have that cross collaborative view of even having design or product tackle it, that's a really exciting way to keep all those things moving.
Eric Anderson:
Yeah. I mean Alex, our CTO here at Intuit is, I think he says it really well where he says that he's been here a long time, he's never seen the backlogs go down. The backlogs of work that we are being asked to do by the business has never gotten shorter. And so he's like, the minute that we feel like we can do all this work with fewer people, that's a conversation worth having. But today we actually see the explosion of ideas. And I think that it's this really exciting moment where I think everyone now feels unshackled from constraints of like, gosh, it's really hard to get software to be built and delivered to... It's still hard, but the velocity and the ability to do more is so much better now. We're making more software now than we ever have. And I think that will continue to amplify and accelerate over time.
Ben Matthews:
Love it. Yeah. So to speak more on a macro level of just where the industry is, now that speed of development or even getting ideas out is not so much the bottleneck it was before. If you were talking to the whole suite of engineers now of like, "Well, what do I work on? How do I differentiate being really good at debugging or CICD or the specific niche isn't as strong. What are the traits that I could really focus on to set me apart from other engineers?"
Eric Anderson:
I will tell all of my leaders and teams and team leads and people who are recruiting in particular. I think that there's generally two things that we evaluate for. There's functional skills and then there's how you do work and I think that the how you do work part is unrelated to the functional skill part. And so do you dive deep into problems? Are you a strong owner when things don't go the right way? Are you customer obsessed in how you think about the problems? And so there's a set of Intuit values that we have, speed as a habit. Can you unblock yourself and figure out the way forward? That's orthogonal to clog CLI or you know what I mean? Quota or whatever. On the functional skill side, I think this is where I still do believe that software engineering is a skillset and it's a functional skillset.
And so I think about it in three categories. You've got someone who understands algorithms, someone who understands how to solve a problem with technical mindset and then someone who understands how to structure and modularize things and break things down into smaller component parts. In the past, in years, you might do a coding problem in an interview with an SDE and you would evaluate, do they write logical and maintainable code? Can they create classes and structures and interfaces and do they understand methods and how that all comes together regardless of language? And I think today that's important you understand that, but it's even more important that you understand how modularity can occur because if you're going to go generate a 12,000 line PR, it can't be 12,000 lines in one class. That's not okay. And so similarly, we still need people to understand algorithms, like database queries, big data processing pipelines like ETL, these are still problems that require algorithms.
You still need to know what an OVN means and how you get to that across different types of implementations. And I think there's general problem solving concepts, which is, hey, there's a million questions out there on the internet. If you buy stock here and you sell stock here, what's the best time to buy and sell stock? You know what I mean? That thinking mentality, it still needs to be there. And so I still think that those are the three functional areas that we still evaluate engineers on in terms of how to be a great engineer. And so should you know debugging? For sure. Should you know CICD? Absolutely. Those are still concepts in software engineering, but at the foundational level, if you can't understand algorithms, you're not going to be successful. There's no Claude CLA that's going to help you be successful with that.
We're not there yet, maybe, maybe at some point in time, but today we're not there. And that's where I do... I think it's very interesting because our most senior engineers, when I think about our staff, senior staff, principal engineers, these are folks that generally are seeing... I've had one of them in a one-on-one recently tell me they're a hundred times more productive than they were before CLA. And I actually believe them. They're like, "I can just move through things so quickly because I know how it works. I know how to construct all these things." Our more junior engineers, I think this is where, I don't want to say worry, but this is where I think we just need more attention as an industry because I mean, I grew up at a time where software engineers, engineering as a discipline was learned by the people sitting next to you that had written more code than you. And you understood that it's almost like being a cabinet maker or a plumber or it's that kind of a craftsman type approach to learning.
Ben Matthews:
Thank kind of experience so to speak.
Eric Anderson:
Exactly. And I think that's the thing we've got to figure out how do we teach that over time because you need controls and guardrails and all these kinds of things to make that work. And that's something we're thinking a lot about, which is how do we make our best developers 100X more productive, which is great and how do we make sure that the folks that are new in career and/or learning this are able to catch up and ramp into this experience in a way that is healthy and productive for their career development?
Ben Matthews:
Especially around the ownership of code and needing to understand the algorithms, you need to understand how it works. I was actually at a university, I'm not going to say where yet, but I was getting to monitor some of their students that were making presentations on what they could do and someone with the best intentions that we pointed out some like, "Oh, could you have done this different in the code? This seems to be some concerns there." And they said, "Well, that's just what Claude outputted." And there was almost a dismissal of ownership around that. I'm like, "Ah, that's a mindset we have to tackle." We have to think of these things as a tool, you still own what you build, you still have to be responsible for what goes out. But also of how we mentor these junior engineers coming up, speaking to other organizations around, "Well, now we only need senior engineers that can build this."
And maybe that's true, but you know where senior engineers come from is junior engineers. You have to create them eventually. So what is that way of how people get into the industry? I remember for myself, there was this aha moment of when I was able to make something move on the screen because I coded it and I was hooked into development and that experience is somewhat dull now perhaps with some vibe coding things that people do and stuff like that. So How do you think that you're going to get the next level of engineers, one, get them in the industry, get them fruitful in learning, get that tactile experience you mentioned and how do you keep them mentored outside of that normal motivation?
Eric Anderson:
Yeah. I think from one standpoint, I feel like we've opened up the aperture of people who are now exposed to what software engineering can do. And so I also had a similar experience when I was younger, I was a teenager and I was in my basement messing around with visual C++ and it was like, "Wow, this is super cool. I didn't even know this was possible." And that led into my career. I think that now there's a lot of folks that are like, "Wow, I can just go in and make a website or I can make a little tool or I can do a thing that solves a problem." In many ways it brings me back to when I was younger and it was software wasn't quite the thing it is today. There were a handful of programs and you'd go to the store and you buy them and you put a floppy disk in the drive and you'd install it.
And nowadays, the idea that someone could just make an app and use it, I think is really super empowering. And I think that that will actually bring a lot more people into wanting to be a software developer, wanting to be a software engineer. I think that's where we'll get back into, okay, well, you can be a great prompter, but you still have to understand how to modularize. You still have to understand... And it's not classes and interfaces. I mean, it is, but can you think about breaking down the problem into smaller component parts? Can you think about how these parts interrelate with each other? Can you think about the dependencies between them? Can you think about how you might imagine use other corollaries like, "Hey, messages are passed from here to there. What happens if the message doesn't come? How do you deal with an error? How do you deal with these non-happy path things?"
And I think that will be where those skills and disciplines will still need to be learned and I think it could be that people could still learn how to program in Python or whatever, an easier language, not that the Python isn't complex, but it's very different from building your own data structures and see, which is a very different level of software development. But I do think it's going to open the aperture to who can be a software engineer and I think it's going to really make an opportunity to bring training programs and learning content for Stack Overflow into, I'm a graphic designer, I want to build software now. I want to make graphic software now. Cool. How do you think about 3D object collision? They're going to have to think about, that's a thing, do you know what I mean?
That a designer probably doesn't have to really worry about how does that mesh actually move and how do you think about the physics of that? And so I think it's for the curious person who's really interested and has that learning drive, they're going to be great. We're going to have this explosion of these great software engineers that come from new disciplines, new backgrounds, new areas, simply because they're like, "This is really super cool and I know I understand it." And it's taken away that demystified the languages themselves, which are hokey anyways, honestly. None of them are amazing, but solving problems is amazing.
Ben Matthews:
Yeah. Solving problems is amazing is what should be on a t-shirt for engineers. I think that's a great slogan. And I know what you mean about being welcoming and to all the Python fans out there, we love you, but it is a very welcoming... I do too. It's an extremely welcoming language. It's what I really suggest for a lot of people that want to get into programming, it's very readable, it's still very powerful. You could last your whole career building great software with Python, but it does get over some of that intimidation hump, which I think AI is helping people do now. I think you're referencing like, "I can do this with even less work." But the understanding of how it works is I think also real important.
There was a staff engineer here at Stack that he has a prediction and like all predictions were probably wrong, but he says, he thinks in two or three years, we're going to learn how we do things, but it's also going to expose some gaps in prompting or understanding in the software because how you prompt it is going to try to accomplish the task you put in front of it. It does not think about flexibility or portability of your code in the same way a human being will. So in two or three years when we want to build on top of these foundations and like, crap, we have to go back and rewrite it or we have to do all these things, I think that's when that understanding is really going to shine through. And maybe that's how some junior engineers find and cut their teeth of like, "Ah, all right, we have to go back and reassess some of these things."
Eric Anderson:
Yeah, no, I very much agree. And I don't know that we're two years away from that. I think we're much closer to that becoming a bigger challenge than we think. We start to see this now and we actually, when we think about agents that we're guiding, not just generating code, but actually empowering to take on specific parts of the engineering process. So we might have an agent that there's a quality improvement defect that we're working through. Here's a corpus of data, run the code, identify bugs, fix the bugs, run the code. You know what I mean? Just have this self-improving loop essentially. And you can see those agents go off into crazy land and produce all kinds of things that you may not want that are technically part of the fitness function, but actually not actually helping you in the end.
And so we think about things like how do you create adversarial agents to monitor your agents and check in on them and figure out, "Hey, are you still doing the right thing?" And almost think about agents as... And when I think about some of our senior folks, I see them develop these agents and then they're becoming like a software manager. They're like, "Hey, what's my agent doing today? What are you working on right now? How are you doing on that?" And I think going back to some of your questions around how do we measure efficacy and effectiveness of some of these processes, I think we're going to see some of that naturally evolve out of the idea that you can create these autonomous coding agents for specific tasks. How does the person who's managing that agent now demonstrate like, "Hey, what is it doing? Is it making progress? Is it screwed up? Did it do a good thing?"
And I think we'll learn and evolve and it's very exciting. Like I said, it's an extremely interesting place because it feels like we're genuinely solving a bunch of problems today and encountering these high ambiguity situations versus just saying, "Here's a spec, here's an architecture, we're just going to bang it out and we know how to do this in a very predictable way." which was fine, but now we're in this mode of going, "Yeah, okay, I can make an agent to do this and an agent to do that and an agent do this other thing and now I'm just managing agents. And now how do I actually manage the manager?"
And those kind of relationships I think is going to surface up a lot of these gaps you're describing, which is, "Hey, the agent wasn't that good. It produced a bunch of garbage and now we got to start over. Do we just blow it away?" I had one of my principals tell me, "We're going to treat code like cattle, not children." And it's like, be much less precious about it and essentially be like, "You know what? We can just start from scratch whenever we want and that may not be a great idea." I was like, "Cool your jets there, my friend. All right." But it's probably an interesting though experiment, which is again, when the incremental value of that line of code is zero or approaching zero, why not just rebuild everything every day? Maybe. I don't know.
Ben Matthews:
That is an interesting thought and it's a lot to unpack in that cattle versus kids analogy, but no, as it does approach zero, does rewriting it all makes sense and how much are those agents cutting their teeth on facing real world feedback of like any software, and I don't think this is going to change even with agents, like any software that meets the customer for the first time is going to find problems, it's going to have to evolve. And the way that you do that's important is if we start over with a rewrite for every iteration, are we losing some of that sharpening of the code? And maybe we don't, maybe we do, we're figuring it out.
Eric Anderson:
I don't know. We're figuring it out. And I think like I said, we don't know how these things are going to play out over time. It's only been like my sense is that the tooling got really good four or five-ish months ago. Before that, it was fine. Now it's really good. What's going to happen now? I don't know. Is this it? Is it going to expand from here? Maybe. Is it going to stay flat? Maybe. Is it going to become incrementally so complex that we're not going to even understand it anymore? Maybe. I think that's the judgment part, right? That was the prompt for this conversation was like, where do humans fit in? Right there. That's where people are needed a lot.
Ben Matthews:
So I think we've been talking a lot about how we can enable our engineers as leaders to use these tools and move faster, which is of course a huge part of it, but there's maybe the less talk about part is as engineering leaders, what do we do to utilize AI to help in our day-to-day and help make these decisions? Is there anything that you try to follow or anything that really jumps out to you that this is what's leveled me up at my level to go faster?
Eric Anderson:
I would say there's very little of my day-to-day at work activity today that is task oriented that I don't use AI for. So for just some examples of, I built an agent that reads my email every day, summarizes it and basically suggests responses to things and then I can go in and tune it and sort of craft it in my tone and messaging and it develops that over time and it saves me from having to filter through, create super complicated filters in my email and it makes sure I'm attending to the right things. Do the same thing with Slack. I'm sure like you and everyone else, you get 4 million Slacks a day. It's just really helpful to understand, okay, how can I self identify who should be in my VIP category? How do I respond to these folks? What are the summaries? And so those tools are great.
Also use AI around frankly a lot of synthesis of documentation. I like to read specs. I actually will go in and sort of use AI to understand here's a PRD, here's a tech spec, here's the code. Did we actually produce what we wanted to produce? And use that as an interesting framing for or an interesting investigation into like, are we getting the right outcomes from the tech? We use it a ton around diagnostics. So we actually use it in terms of here's a bunch of log data. What can we go in and actually look at and find anomalies? How can we actually use that to then drive improvements in the product? Some of those agent type experiences around a lot of the task based parts of the job I think can be somewhat outsourced to agents.
Now, it still requires a human in the loop. In my email thing, I'll be honest, I started out having it send email for me, quickly stopped doing that. That was a bad idea. What was a good idea was like, "Hey, just read it. I'll summarize it and give me the cliff notes of it and then let me go back in and really look at the detailed parts of it to just separate from what was important and what was less important." Any planning, any synthesis, any... I'll actually have whole projects in both in Anthropic and in OpenAI where I can actually create projects around things like, for example, employee promotion documents. And so I'll actually have a project for sudden such employees promotion. I'll put all their code in there. I'll put all the documentation they've written in there.
I can have it help me summarize from that and then use that as an input to actually go and when I actually write the promo doc, use that as a way to make sure that I'm co-working with it. I can also use it to actually do research. So this is a common thing I'll go in and I'll say, "Hey, I'm looking at this particular competitive product, customer use case, whatever, actually chat with me about it and help me understand how this relates to other products, other technologies, other offerings, other types of things." And so I just think it's super important tool for everyone, not just for code generation. I think it has to have a human in the loop at every step in those areas, but I do think it's a significantly better way of aggregating unstructured data and trying to make more sense of it in a way that you can do with a natural language interface.
Ben Matthews:
Eric, thank you so much for joining. This has been fantastic. I think you got a lot of cool insights on how we can use AI engineering and even outside that level and really excited to hear how things go at Intuit and what's going to come next.
Eric Anderson:
Thank you so much, Ben. I am a huge fan of the work you do over at Stack Overflow. Thank you so much and I look forward to seeing what happens next.
Eira May:
Okay, that's going to do it for this episode. Today we spoke with Stack Engineering Director Ben Matthews and Intuit Engineering Director Eric Anderson. My name is Eira May and I'm the B2B editor at Stack Overflow. If you have any suggestions for topics you'd like us to cover or guests you'd like to hear from, you can email podcast@stackoverflow.com. Thanks for listening and we will see you on the next episode of Leaders of Code.