Enterprise & AI | Mike Krieger, Chief Product Officer, Anthropic & Jeetu Patel

Yeah, maybe the throughline, I've always been interested in the combination of what's possible with software and computing and then how do you actually make that real for people. And so when I was at Stanford, I studied symbolic systems, which is this very odd degree, although it's gotten more popular in the years since, which was this combination between cognitive science, design, computer science, philosophy, psychology, and AI. And AI at the time was still mostly finding paths through mazes, not what we call AI today. But I loved that kind of intersection of, you know, you can have the world's most powerful software, but if it's not comprehensible to people, have you actually succeeded in doing anything real? And kind of carrying forward in that, I first worked at a company called Meebo, which was actually great training because the company culture and the recruiting and the hiring was so strong there. And from that, co-founded Instagram. And Instagram, a lot of what we were focused on, you have to rewind to 2009, mobile apps were still emerging. Cameras were starting to become more ubiquitous, but most people still felt like their photos were kind of stuck on their devices. A lot of what we were trying to do is on every screen, is it very clear what is the one thing that we want you to do? Is it stupidly easy to figure out how to create a graph to become good at Instagram and still be able to progress in that as well? And then did another startup with the same co-founder as Instagram called Artifact at the beginning of AI. So it's AI-powered news recommendations. I still get probably at every event there's one person that comes up to me that's like, 'Man, I loved Artifact, why'd you shut it down?' We did it for about three years and realized it was not on the trajectory to be the kind of place we wanted to spend the next three years. So, we ended up selling it to Yahoo. It lives on as Yahoo News. And then I had this intersection moment where, you know, do I go start another company? I love founding things. I love zero to one. Or do I go join somewhere? And my previous three years at Artifact had showed me two things. One is coding was about to change. So, I had started using early coding models to accelerate my own work at Artifact. It was so early still though. The models didn't have vision yet. So I would draw as part of the screens I wanted to implement and say, 'Hey, ask Claude,' you know, dots and dashes, and say, 'Great, please implement this in Swift.' I'd hit enter and it was, you know, two tokens per second. I'd go make a coffee, maybe take a walk, and when I got back it was like a start of what was actually going to be good. But you can see the trajectory was already there. So number one, coding was going to change and number two, the models were going to provide this intelligence layer that were going to take months of development time of a feature down to, you know, potentially hours. So for us, some of the intelligence that we baked into Artifact were things like take an article and summarize it. Take a headline that's written to be super clickbaity and then rewrite it to be factual. These are features that if we had to spin up a research team would have taken us months to do well. But in this it was already, this is 2020, 2021, an API call away even for those initial versions. So it was really clear to me that the next generation of software was going to be built and powered by these labs. And I talked to the folks at Anthropic, they shared that vision, also just loved the culture there. We can talk more about that as well but it felt like that was going to be the real springboard and I wanted to be a part of that. I think what Anthropic is doing is actually not only amazing but also it was crazy unlikely when you folks started and what you've accomplished is no small feat.

Huh. There's this belief that design is going to go away right now and it's, you know, that you can prompt the models, they'll create software. By the way, what's that? Dylan was here. Yeah. So Dylan, I guess we both share this contrarian belief. To me there is still the difference between software you use and software you love. And I think that that gap of, I actually come back to this, I'm choosing this, I've changed my behavior because of this, I've gone off and told a bunch of other people about it. I've yet to see that with a lot of sort of, you know, off-the-cuff, you know, vibe-coded stuff. I think there's still that need for what's the craft, what's the reason, like why does this exist, what's the brand, right? Why does it all mean to a person? So that's one where I feel like the demise of thoughtful designed software is overstated. Now the actual role and how you get there will absolutely have to evolve. But I still think that there's a need. I see it internally. We could talk about my transition to working on labs now. I spend so much time talking to designers now and their role has definitely shifted. But it's I think as essential as ever.

Yeah, I mean I think one really significant one is staying too much in sort of mockup or sort of, you know, faked prototype land before you actually get something real that you can actually then get a sense of the model capabilities. A lot of what we do is try to build products that don't work yet and then wait till the next model release and see, well, does the product work now? Like we built a computer use, so, you know, Claude driving your computer and clicking as a prototype in my third month at Anthropic, so this was 2024 still. Wow. And it was terrible. Like it was, you know, it was clicking all over the place, like it just didn't work. But even that prototype taught us, all right, where are the model capabilities? And every time the research team had another research model we'd throw it in there and be like, 'Well, it got past the file menu. Now it got to the open, you know, it got a little bit further.' And then there was this moment, I think it was Sonnet 3.5, where we threw it in there and actually we didn't expect it to have improved that much. So we kind of did it as a good practice. And I suddenly got a ping from one of the researchers like, 'Look, it actually got good. We can actually productize this now.' But we wouldn't have known it if we didn't have that harness throughout. So I think you just need to reframe your sort of purpose as a product person from being, 'I deliver a beautiful product requirements doc. I deliver beautiful wireframes with my designer and it gets handed off to engineering,' to software is now a living, breathing system with this non-deterministic, wonderful but also, you know, infuriating sometimes engine at its core. You need to get to that sort of moment where you're experiencing that as quickly as possible.

Even, especially in the enterprise. Yeah.

I think that one of the things that's magical about what these models can do now is given the objective and fairly high-level instructions, find their way there. And, you know, sometimes it's kind of endearing. Somebody just sent me, one of our engineers sent me, he had asked Claude to prepare a vacation preparation doc for his family, but Claude had hit a block loading the website of the vacation rental. So instead of showing photos, it like drew its own imagination of what this house looked like. You're like, 'Well, I'm not sure that was exactly what I wanted.' But it's kind of like it's creatively trying to solve the problem. Like if you've never seen a model try to solve a problem in one of these cases, it's fascinating. It's like, 'Well, I can't do that. Should I try this? Well, I still can't do that. I'm going to pretend.' It really wants to solve that problem. I don't think you want to sort of prevent it from doing that, like hold it entirely, because that is part of the magic of being more agentic. But you do want to sandbox it in the right way. So what we find a lot in the agentic systems that we build inside enterprises is, all right, the box that Claude is running in, what are its permissions, what's the minimum amount of permissions, and what's the sort of conduit between that and the outside world. So that you want autonomy, but you want autonomy in a sandbox with the right sort of abstractions around when it goes off. Exactly. And when it goes off and then what information flows in and out. And that's also a really good point around adding observability. So it's, yeah, autonomy within sandboxes with the right connectivity elsewhere.

Yeah, I love this topic. I feel like I could talk about it for an hour. So, I'll try to be brief and pointed. I'll maybe give a vignette from what it's like right now inside Anthropic on our labs team, which is we are regularly producing two to 3,000-line pull requests with each other, especially on the labs team where we're moving extremely quickly.

Claude is written by Claude. Claude products and Claude Code are being entirely written by Claude. If you know when Dario, I think, was on stage a year-ish ago and was like, 'Oh, by the end of the year 90% of code is going to be written by Claude,' people thought it was crazy, but we were already seeing that trajectory. Right now for most products in Anthropic it's effectively 100%. It's just Claude writing and then what we've done is created all the right scaffolds around it to let us trust it. So the few things that how software development has changed, one is having Claude trained and sort of prompted to be a really good adversarial code reviewer has been fantastic. I'll put up pull requests and Claude will come back and say, 'Here are all the security vulnerabilities, but here's also how it could be refactored, here's how it could be different.' And sometimes it, you know, this sounds adversarial code review, I was talking to the person that had built it internally, I'm like, 'What did you do?' And he showed me the prompt, it's actually not rocket science, it's just really prompting to be like a super tough grader, like what are all the different problems that you can do, what are the different automated checks, and enforcing some softer sort of requirements as well. So that's one of them that I think really matters. The second one is being willing to let Claude rearchitect things. I was working on an iPhone prototype and I just clearly gotten to the point where the initial architecture hit a wall where it was just having trouble parsing it. Asking Claude to step back, first write some verification, then go off and refactor it. You know, we've talked about there's components at Anthropic. We're not an old company. We're only a few years old, but you can accumulate tech debt at a very fast pace, especially in the age of AI. Paying down that tech debt, that calculus has really changed for us, too. So, that's been another interesting aspect of it, too. And then the third one is I felt this a little bit a year ago and I really feel it now is how much all the other processes become bottlenecks. So we had an outage of our continuous integration system yesterday and, you know, that would have been a mild annoyance because you maybe were producing one change set or pull request a day and you have to wait an hour. When you're producing like no joke a dozen at least per engineer on the team, it was just like I felt physically pained because it was like all this stuff is just gumming up the works. It also makes recovery more challenging. And so that focus on developer tooling, on developer efficiency, on the developer infrastructure that was already mildly important is now sort of any blocks or outages or friction becomes a 10x sort of penalty on your team's...

It's reviewing, auditing, integrating, right? Because now you've also got the thing where you've got multiple engineers contributing to the same place as well. And then driving alignment first on like what the product should be, which was in some ways always the hard part. Now it's really clearly seen as the hard part, but also what is the sort of principles and architectures that you're going to want to build within your application. This is even more important in the enterprise. But aligning on that and what are those standards so that when you're reviewing or when Claude is reviewing the code, you're not just kind of duct taping things together but you're evolving towards some consensus north star around architecture, code principles, like problems that you're solving, that ends up becoming the bottleneck.

The place where I see it really showing up in the enterprise or where I've seen success versus failure is sort of if you think about the opposite of that experimentation approach, it's the, all right, what is the sort of single piecemeal piece that I feel safe adopting in this one thing, or I'm going to build one customized agent for this kind of low-value process I have where it's not really costing you that much. All of those have been doomed to failure because one, the problem isn't ambitious enough that you're really going to learn about the capabilities and what it's actually going to take. And then second, you know, if the second it hits a roadblock or it's not performing as well, people give up. People give up and it's on that. So like finding instead, and we've worked with large banks, large insurance companies where we found like some very critical business process where it should feel I think a bit scary that the idea that it's going to get identified with AI through it, but then partnering really closely to say, all right, what does success look like, what are the guardrails, how do we build this out, you know, what's an aggressive timeline that we can build out, how do we push that even faster because you're going to want to stay on the frontier there and then pushing that out, that's been I think the right pattern, bringing some of that experimentation approach in there too. And then finding out, so maybe that's like how to transform internal business processes, there's also how you empower your own product teams because many of you are also powering products with AI that you are then delivering to an end user as well. And finding out that right sort of level of centralization where ideally that central AI team is mostly facilitating access to models and, you know, some auditability and observability and not being too opinionated on it. Are you building on the Claude Agent SDK or something else? Is it LangChain or something else? Like I really think you want to push those decisions as much as possible into the product teams and only kind of treat as commonality like really I think it's a thin layer, it's access to models and observability.