Office Hours: Building the case for leaders who ship with DoorDash

At DoorDash, Claude Code runs across the entire company, all 4,000 employees have Cowork, and co-founder and CTO Andy Fang is shipping production code again for the first time since the dorm room. Boris Cherny sat down with Andy to talk about giving everyone tokens to experiment, landing projects in 3 to 5x less time, and why leaders have to play with the tools themselves.

Read the full transcript: 

Boris Cherny, Creator of Claude Code, Anthropic: I want to get into it a little bit. But before we do, I want to, like, step back a bit. Sure. How did you get into coding?

Andy Fang, Co-founder and CTO, DoorDash: I grew up in the Bay Area. So very exposed to the tech industry as a kid. So the first exposure I actually had to coding was, when I was nine years old. And, my mom was trying to get my brother to be occupied for the summer, and so she sent him to this random coding camp, and then I had nothing to do. She just had me join this camp with him. It was intended for him, but I ended up being the one who picked it up. Since then, I just stayed with it. Rewinding back a bit, in terms of the journey I went on with coding at DoorDash: back in 2013, I was writing all the code directly myself in our dorm room at Stanford. And then after a while, as the company was scaling, I kind of stopped coding. It wasn't until I was using Claude Code that I actually was shipping production code in our code base again. So I had a major comeback.

Boris: And then fast forward to today. Tell me a little bit about your setup. How do you use code? Do you like a terminal or desktop, or are you on a laptop or on screen?

Andy: For coding, I'll just use the terminal usually, or I'll experiment with using the desktop app. I set a goal for myself to, like, not write code manually. So, I try to have the agent Claude Code basically write everything.

Boris: Do you have like one session at a time? Do you have like a bunch of sessions? Oh, yeah.

Andy: So I have multiple repositories set up, and then I will basically, if I have a repository that I want to have multiple sessions on, I'll use like a git work tree to basically allow myself to code in the repo without conflicts. And then, I try to have a couple of sessions going at a time.

Boris: What was the first experience using Claude Code? Do you remember?

Andy: I distinctly remember like, okay, I'm going to try to like code actual features in production. And I made it a goal for myself to not ask anyone for help and see how far I went. Unfortunately, at that point, I did not make it to shipping the code to production without help, because I wasn't able to get the agent to understand how to configure my local environment correctly. Then fast forward to, like, I think it's probably the beginning of this year, 2026, I did the same thing and it just worked. And I think, I mean, you've definitely seen this. I've heard you talk about this where like, there's really been an inflection point with the latest models of being able to just figure things out. Yeah. And I've gotten to a point where, like, I was shipping in five different languages to production. And I think it's just super powerful, and I think it's very hard to believe it until you actually force yourself to play with it.

‍Boris: Funny. There's this thing that happens where you try something and you use an old model, and the product doesn't really work. Yeah, this doesn't work. And then you just, like, try again in a couple of months. It might just work. And this used to be like the worst idea before LLMs because it's sort of dysfunctional to take the same idea and then just, like, try it over and over again. It's like you should be learning, but actually now trying just that same exact idea with the newer model. Sometimes it just works.

Andy: I think something that we've tried to get the teams to unlearn at DoorDash is like, it's okay to throw away your idea. Like, because I think sometimes with engineers, you have a real strong affinity to something you've built that works. But I think as the models change to the capabilities, channels like, hey, look like whether it's your setup or like maybe an agent that you're building, it's like you got to reimagine how you're building this stuff with how the capabilities are changing so fast. And so I think it's as a leader, if you can really lean in and play with this stuff yourself. I set a goal for our engineering managers like, hey, every engineering manager, you should try to set a goal to ship production code. Not like a prototype, because you can ship a prototype on your own local setup pretty easily. But try to go through all the hoops at DoorDash to get something merged in production and do it yourself. It'll open your eyes both in terms of the capabilities of the models, but also like, hey, for the engineers on the team, what's blocking them or what's causing them to not move as fast as they ideally could?

Boris: How has this worked? Is it working well? Is every manager like, yeah, let's go?

Andy: I think what's really landed with people, DoorDash is we are here to invest in you all, to give you all the token budgets and the tools for you to play around, explore these coding agents and get them to work well for you. And I think that message is really stark. And I think for managers and particularly, as they've kind of played around with it, they start to understand it too. And so I think, you know, I wouldn't say we're perfect by any means, but I think we're definitely getting people to, to go along the curve.

Boris: This is something that I hear over and over from leaders. And it's something I feel myself too, that this is just the most fun I've ever had coding. Yeah. And just building in general to the part that I, you know, I enjoy the act of writing code, but also the thing that I always cared about the most is the result. And now I can just prototype really fast and iterate really fast and it's so much fun. But then it has this other side of like, you just have all these agents running and you're constantly context switching. Absolutely. And it's hard. It's a different way of working.

Andy: I think it's very mentally taxing at times. And then there's also things that new problems that come up, which I'm sure you guys are dealing with as well as like if there's all this code that's being shipped now, people start complaining about, oh my gosh, how long it takes for the code to get merged. And like, there's so many processes on CI/CD that we need to reimagine or overhaul as well. And you know, we've invested in AI code review agents to make it easier for people to review the code. But now that there's so much code, people are kind of just rubber stamping the code reviews, based on whatever the agent's telling them. So it's like a very interesting time where, for example, with security-related issues, a lot more security-related issues are cropping up, not just at DoorDash. Industry wide, now we need to figure out how to get AI to also help catch these security issues before we ship it to production as well. So it's kind of like a cat and mouse game and a little bit it's like, as the capabilities are increasing as the throughput's increasing, making sure that people are catching up and we're using AI to help streamline the automation.

Boris: When did you first introduce Claude Code to DoorDash and how did you think about it?

Andy: So sometime in 2025, we introduced Claude Code and then people started using it. We worked pretty closely with our IT security teams to make sure that, like, hey, for this type of stuff, like we're going to have a special like procurement and review process for these AI tools because the industry and the landscape is moving so fast, we want to make sure people get access to the stuff pretty much right away. I would say the true inflection point was probably at the beginning of this year or late last year. And since then, with our coding velocity, we've seen a correlation with the adoption of Claude Code and basically like throughput for the teams. But I would say it all kind of stemmed back to, both executive leadership support, but also like partnership with IT, security and engineering to just make sure that like, hey, with the tools that are available, like try to get people access to it as quickly as possible and not be so stringent on budgets to start with. And just optimize for letting people explore the landscape.

Boris: Yeah. So it's like ‘Give people the ability to explore,’ but then also set the right controls. Yes. Like security is not negotiable.

Andy: Exactly. Security was very much in the loop. And I think our security team has done a phenomenal job of moving quickly with the industry while partnering closely with us to make sure that they have their eyes on the types of tools that we're getting access to.

Boris: So with all these all these different tools, with this totally new way of working, how do you like, make people feel safe experimenting with it?

Andy: Early on our mindset was like, give it, give the tools to the people and see who the early adopters are and just see what they feel like is working. What we've done since then is try to plug examples of success cases, whether it's particular projects or people who have done a good job, and get them to be the advocates within their team. And I think one thing we've tried to emphasize is try to, as much as possible, get people to produce written artifacts. So because like, yes, you can maybe do like all hands or maybe you have some sort of team Slack channel where you're talking about all the cool workflows you've done. But like when it comes to written artifacts and stuff, I can share with the entire company. And so that's why we've seen some success there. But with an organization of our size, it's kind of hard to uniformly enforce that. But that's generally the mindset I've tried to encourage across the organization is like each team needs to have their own channels and forums for people to feel comfortable sharing. Both the wins and the like, the shortcomings, to be honest, it's like it's just as important to showcase, hey, here's something I did that was cool is also important to show, hey, here's this workflow that I tried that didn't work, or here's this integration that I did that like wasted a bunch of tokens. You know, I think we want people to feel comfortable sharing that type of stuff as well. And then return artifacts to that because that's scalable for both for the agents to pick up and learn from. But also just for people to see more across the company.

Boris: Yeah. When I talk to, like, engineering leaders, this is something that I hear all the time, like people are trying to figure out, how do I just give everyone tokens and then, you know, like let them experiment? Or do I start with, like, a pilot with some subset of the org? Yeah. And the advice I usually give is actually really similar to this: give everyone tokens because you don't know who the innovation's going to come from.

Andy: Exactly. Yes. I think that's actually really interesting. I 100% agree. It's like it's hard to predict who the early adopters are going to be, because when there's something so disruptive to your workflow as coding agents, there are some people who are going to be initially resistant to it who might be very productive in their current setup. But there are people who might be really embracing it, who you would not have guessed. And so I think, yeah, it's hard to predict sometimes who the who, the early adopters and the power users are going to be.

Boris: So you started, you know, using code and people started advocating for these tools. And then fast forward to today. How does DoorDash use Claude Code?

Andy: It's pretty much widespread across the org. In terms of people either using Claude Code or using Claude models within like other harnesses. We're investing a lot more in automation and basically able to tap into the increased throughput. How do you make sure that's as frictionless as possible? So investments into CI/CD, using Claude to build AI code review agents for us, we actually have built an internal platform, that we call Flex. It's an infrastructure investment where we have VMs that are in the DoorDash cloud, where you can spin up Claude sessions that are, blessed by security, that have access to the right type of tools. And that way you can actually fire off Claude sessions in the cloud. And that's actually how our AI code review agent is powered as well, on top of that platform.

Boris: Super cool. That's like the Claude Agent SDK.

Andy: Yeah. Using the Claude Agent SDK. And the Claude models are cool. And so that's been super helpful for us to use those frameworks to basically build that.

Boris: Yeah. Like the thing that you were saying before about how you start with the coding and then you kind of go like a bottleneck at a time and just break down the next wall, like over and over and over again. That's that's just like, so similar to what we've been going through too.

Andy: Actually, one thing that I forgot to mention in terms of how Claude's being adopted in software engineering is, we're actually encouraging adjacent functions to really adopt as well. So we actually set some goals for our designers to actually start shipping code to production. It didn't go 100% smoothly, but I think directionally it was very good because it really forced designers to think about how to get directly embedded into the software development process. So I think that's been really cool to see. And I think we've gone to a point now where I would say a lot of our best teams have designers and product managers embedded directly in the software development cycle. And they're all using Claude to basically empower themselves. So now that we have a bunch of Claude adoption across the org, and we're seeing, you know, massive increases in throughput, the challenge I've posed to the entire team is like, try to get projects done in 3 to 5x less time. So, like, if a project last year would have taken you 12 weeks, try to get it done in at max four weeks and using AI to do so. And I think when you set those kind of constraints, it it's pretty eye opening in terms of the types of challenges people run into. And so a lot of it is around how they use coding agents and how people use standardized skills so that people can all get the learnings of the most prolific people. There is an engineer who did a massive code migration that would have historically taken four engineers over a quarter to do. One person did it in three weeks. 

And I think, there's other products where we shave the timelines by more than half of these massive products that we're trying to launch. And we pulled the launch timelines in significantly. And so I think it's like finding pockets where we're seeing those and figuring out, okay, what did you do that was so successful getting them to publish written artifacts, as I mentioned earlier, so that people can, like, see what's going on. Right now what we're doing is we're like, handpicking a couple of teams to really dive deep and, and give this kind of charter to, and just see what they come up with and like, kind of in a like, you know, in a blameless way in terms of like, you know, it's okay. Like, this is a stretch goal. We're going to see if we can hit it. And just we want to maximize obviously, the effort, but also the learnings in terms of what's causing you friction or what are the hurdles that you're facing.

Boris: So what are some of the learnings from that from you know like experimenting and figuring out what are the pockets of adoption, what works to accelerate development, what doesn't work like what's like one surprising thing that works and one thing that doesn't?

Andy: One thing for sure is smaller teams, is a great accelerant. Each person can kind of own a thing or a couple different domains, and you don't have to, like, coordinate as much with each other or like, hey, I accidentally like stepping on your toes or whatever. Another good learning was actually like, it actually pays off to do some upfront investment to setting up your code base to be agent friendly. And one of our successful examples, the tech lead he jotted down on it like a couple dozen, maybe 50 plus like principles of architectural principles that he cared about for a particular code base. And he jotted it down in these markdown files within the GitHub repository and, basically so that when the agent was coding that he could reference these architectural principles. And it actually was super helpful. Another thing that was really helpful was standardizing skills across the team. So for example, for our mobile development, the team put together skills around basically making it really easy to spin up the simulator and test particular workflows, things that would be super manual and annoying for an engineer to instrument themselves is now just like a skill that you can call and kind of run in the background. 

So I'd say those are some positive use cases that we saw in terms of AI adoption. The challenge that we ran into was particularly for more user facing features where you're not just coding a platform change or code migration. It requires cross-functional buy-in. You need the designs to be aligned. You need to make sure that from a product perspective, you're solving the right problems. And we have a lot of these processes that we've put in place for good reason, like product review or ship review or design review, things that historically were very important for us to get alignment with each other. But now, given how fast things are moving, it's just like it's a huge friction point. And so we've had to really build alignment with cross-functional leaders to make sure that if we want to really take advantage of AI velocity, it's not just an engineering problem, it's a whole company problem. Cross-functional leaders need to be brought in to change the way they work in order to unlock this type of velocity. Like we need to be okay with not necessarily having product review work in the same way. Or do we even need to have product review? 

If we want designers to be coding directly, making changes. You know, historically, an engineer would have to spend a lot of time getting the design to be pixel perfect. But if the engineers can get it in a workable state, and then we can pass it off to the designer who can get to pixel perfect self sufficiently, that's really powerful. I think something that we've generally found to be true is the more self-sufficient a team is or an individual is, the faster they can move. And so that's kind of the philosophy that we're trying to really push when we are encouraging people to be more AI forward.

Boris: So less process, less design docs, less reviews.

Andy: And just like working directly in prototypes, if you're a designer, like working directly in the code. Yeah. Basically streamlining a lot of the process or reimagining it maybe because like some of this process is there for important reasons. Maybe there's compliance related things that need to go on, but then it's just asking the team like, hey, if we want to shrink the timeline by 3x, like, what's a way we can leverage agents to automate a lot of it, or make it faster? And I think the mindset in terms of how teams should change is like, hey, you don't necessarily need everybody to be a domain expert, and in fact, you should encourage people to be as fluid across the code base as possible. 

A lot of our mobile engineers, we actually encourage them now to try to be more full stack, which is a lot more accessible now than it was even a year ago. We still need domain experts in, for example, iOS to make sure that there's particular parts of the architecture or kind of how we manage memory or latency and performance. There's certainly domain expertise is important, but you don't need your whole team to be an iOS expert. You can have much fewer of them. Be gatekeepers and figure out how to build agents to basically check for the things or write in MD files. Their architectural principles are things they care about. And you have a lot more people who can be generalists and moving fluidly across the codebase. And I think that's like a mindset change. Also that we need to get people more comfortable with.

Boris: Yes. So when you have one of these small teams working on something, but you want to give them the space to experiment and to kind of figure out the process, how do you think about staffing this team? What's the ideal kind of profile for it? 

Andy: We try to make sure that for these teams that we're giving these remits to, we want to make sure that they feel safe and experimenting and pushing here. So I will actually directly lean in or I'll ask, like executives from like the engineering or, various adjacent functions to actually lean in with these teams and basically have like executive VP level sponsorship on that particular workstream to figure out, hey, what do you whatever you need to do to get unblocked, like you have the sponsorship from high up leadership to do so? Because one thing that I've seen not necessarily work as well in the beginning is if you ask people to do this, but they're working within the same confines of, kind of their normal job, where, okay, like I need to go through all these processes or all this stuff, then they're going to give up pretty quickly. Unless you empower them to be like, hey, you actually, not only are you going to get a token budget to kind of reimagine the things of AI, but I want you to raise to us your cross-functional leadership team, what is hindering you outside of just generating code? 

And so I think that's worked really well to make people feel safer. We're still trying to figure out how to scale that. But ideally what would happen is as we see these success examples crop up, we share those written artifacts with various leaders. So that people can kind of organically try to adopt these practices.

Boris: Like the limiting factor used to be the speed of coding and that limited kind of the speed of delivery that dictated the team set up, that dictated having to have process in these org reviews and kind of like the cadence of exact check ins and all this stuff. Absolutely. And now, because engineering is so fast, it kind of forces you to rethink all stuff.

Andy: There's actually so much more that a team of 3 to 5 can do. It's almost like you kind of want to invest in making that unit move as fast as possible. Because like if you can get that unit to work 3 to 5 times faster, then that's totally game changing for the org.

Boris: Okay. I wanted to touch on maybe a few, a few final things. So, how were you thinking about ROI? So you talked a little bit before about the first when you're kind of early in the journey, you just want to give people as many tokens as possible with the experiment. Now you're thinking a little bit more about ROI. How do you think about it?

Andy: I think for engineering it's a little bit more straightforward because you can actually, I know, like code throughput, it's not a perfect metric and it's a gameable metric, but it's directionally kind of correct in a lot of ways. And also the fact that, like, you can get more, you can get the same project done faster with fewer people means that the people you have today, you want them using it as much as possible. I think in knowledge work, I think we're so early and I think to a point you made, I think there's a lot of things outside of just like the triaging my email type use cases that I think are really powerful with Cowork that we're just scratching the surface on, like, I think for sales teams, having to do outreach with like tens of thousands of merchants. Right? Like that's a lot of manual work. And if we can really streamline that and make it more accurate and vetted, like with consistency via AI, that's super powerful. 

There's two ways that we are thinking about it right now. One is just in terms of raising the baseline, like how much time are we saving the average person in terms of tasks that everybody needs to do? And then there's where I think actually might actually end up being more impactful is on a per department or domain basis. Can we identify particular workflows to automate that would make it significantly more efficient to run that department. So that's kind of how we're thinking about it right now, but in the knowledge workspace, to be honest, we're so early that we're in an exploration phase right now.

Boris: Yeah. So for coding, it's about like the volume of code increases. So like the code throughput you can measure and then the speed of delivery, you can measure pretty easily. And just like freed up people to do stuff.

Andy: Yeah. And I think ultimately for engineering well it's not just engineering because it involves like design involves cross-functional support. But at the end of the day, we want customer value to be delivered faster. So if we can actually prove that out, not just in terms of code getting merged, but also like customers seeing the product live faster, I think for us that's like the ultimate success metric.

Boris: Yeah, yeah. And then yeah, and like for knowledge work, we're still figuring it out. It's still domain dependent.

Andy: I think there is a lot of value to be had if we can get everybody to be even 10% more productive with this stuff, that's huge, at a company of our scale. And so I do think there is value in terms of raising the floor. But I do think with knowledge work, there's still a lot of explorations to be had around domain specific workflows.

Boris: And I guess it's like it's just back to the way that innovation actually happens. Like if you're a top down, like, hey, you go automate this workflow, you might actually just pick the wrong workflow or the wrong person to automate it. Totally. But if you give everyone the freedom to experiment, you're going to be surprised by, you know, some person over here automates this thing. Some person over here automates this thing, and you might not even have known it's a bottleneck.

Andy: Totally. And that's why, like, we're trying to call them AI champions internally right now. It's like we're trying to identify champions within each domain, like sales or marketing or operations or, you know, support. And so we're trying to identify who organically is cropping up, who's doing this in their spare time. We're just naturally gravitating and being prolific with these tools to really help figure out, okay, like if you're the champion for this thing, one, I'm going to call you the champion for your domain. And then two is like, what can you what's what are the big pain points within your domain? Because I don't know. And then, can you figure out a way to either make that workflow a lot more streamlined using agents, or can you figure out a way to make it much easier for your coworkers to be streamlined using a shared set of skills

Boris: So like famously you started using AI in coding interviews pretty early, I think, before even we did. How do you think about it? Like, how do you find these people that succeed in this kind of environment that are happy, you know, experimenting and that enjoy this kind of work?

Andy: I think our mindset is give people the tools and just see who ends up naturally picking it up. One thing I've also found to be true is the people who are the most AI-pilled, they tend to find it fun. You know, you want people who are having fun with it, and those people will naturally, you will naturally find out about those people, whether it's through Slack channels, or…

Boris: They're going to tell.

Andy: They're going to tell you. Yeah. Because they're having so much fun and enthusiasm around that they can't help but share the enthusiasm with their peers. So I think it hasn't been that hard for us to find a champion, especially on the non-technical side. And then on the technical side, I think we've just found people who've naturally become power users and taken off of that.

Boris: Okay, I want to close with one last question. What is your advice for engineering leaders? So like other CTOs and leaders at other companies? And then on the flip side, what's your advice for new grads? Sure. In college, right now you're graduating. What would you tell each of them?

Andy: So I would say for the engineering leaders, make sure you use the AI so that, like, you can encourage your teams to use AI. But I also think it also gives you a sense of empathy in terms of the types of anxiety or stress that engineers might go through to change how they work. And it's kind of an identity crisis in some ways for engineers who are so historically, a lot of people are tied to the craft of the code that they're writing. But you kind of gotta let go of that a little bit. And I think as a leader, I think you really need to understand that. And the best way to understand this is play around with it yourself and understand how powerful these tools are, but also how drastically your workflow needs to change. 

And then also encouraging people to share written artifacts. I'll say it again. It's like that's, in my opinion, the most scalable way to distribute learnings at scale. It's also a byproduct of it if you actually end up having artifacts that agents can read. So that's what I would say to engineering leaders. New grads are picking this up so quickly in a lot of ways. My encouragement is like, like stay curious, play around with the tools. I think a lot of companies like DoorDash, what we are really excited about with the new grad talent is people who've grown up with this paradigm of working, who can surprise us in terms of ways that we can leverage technology that we didn't think was previously possible.

Boris: Andy, thank you so much.

Andy: Yeah. Boris, it's a pleasure to be on here. Thanks for having me.