The models today are good at adding features. They're not necessarily good about figuring out what to cut out of the product. You can get it to go zero, not just zero to one, but zero to end pretty quickly over the matter of hours. It's made a lot of decisions along the way. And some of the sort of intuitions you build about what are the right things to put in there, I think you build over time. I feel like that is the art and science of software design in 2026.
Work moves fast. And in the age of AI, the pressure isn't just to move faster. It's to make sure that what you send actually sounds like you. From emails to proposals to stakeholder updates, generic and rush just doesn't cut it. If you've ever stared at a blank page, knowing exactly what you want to say, but not how to start, Grammarly fixes that. Grammarly gives you one place to think, write, and finish your work. Write where you already write. Most AI tools either take over or stay out of the way. Grammarly does neither. It helps you break the blank page, adjust your tone so a message lands right for the specific person reading it, and works seamlessly across more than 500,000 apps and sites that you're already using. It's loaded with agents built for every step of your process. And 90% of professionals say it saved them time. 93% say it helps them get more done. This is AI that works with you, not over you. In a world of generic AI, don't sound like everyone else. With Grammarly, you never will. Download Grammarly for free at grammarly.com. That's grammarly.com.
Mike, welcome to the show.
Great to be here. Thanks for having me on.
Great to have you. I'm super excited. For people who don't know, you are the co-founder of Instagram and now you are at Anthropic Labs. I've admired your work from afar both at Anthropic and Instagram for a really long time and you're obviously at the forefront of building products and AI. So, thank you for coming on.
Where should we start? Like what we were talking about just now in the pre-production is what has gotten easier and what has gotten harder or stayed maybe stayed the same in product building as the underlying substrate or the process by which we build products has changed completely. So like tell me about your experience now versus earlier in Anthropic versus Instagram and how you think things are changing.
Yeah, I was doing the thought exercise a couple weeks ago of, you know, we know the Instagram story. We had another product called Bourbon. We worked on that for almost a year. It wasn't working. We pivoted. We basically spent 3 months building what became Instagram, launched it, and then scaled it. And asking the question like what is now trivial and what was actually inherent in that building process that doesn't get easier, right? And that year we probably could have hit some of the dead ends we had eventually hit sooner, but there was value in getting there too, right? Like we overcomplicated the product so that we then had to simplify it. I find even the models today are good at adding features. They're not necessarily good about figuring out what to cut out of the product and that took a lot of just sort of hitting actual real world usage. And there was something about the process of incrementally adding things right now. I mean today, especially some of the stuff we're building in labs, like you can get it to go zero, not just zero to one, but zero to end pretty quickly over the matter of hours, but it's made a lot of decisions along the way and yeah, you can ask it to follow up with you and do input, but some of the sort of intuitions you build about what are the right things to put in there, I think you build over time. And so I've been reflecting like there haven't been a lot of breakout consumer products even in the age of accelerated AI building. And I think part of it is because it just still takes time to sort of hone your view of what sort of intervention you want to make on the world and then build from there. Now the actual building part once you know what to build is of course so much easier. I had Claude basically rebuild Bourbon. It took about two hours. It was feature complete. It added filters which Bourbon didn't have. We added those for Instagram but I think it knew the eventual future of the product so it decided to build that in. So I think that part feels really different. But I think there's also, you know, I remember there was a week where Kevin went off and built all the filters for Instagram v1. I went off and built like sort of the rest of the app. And you know, sitting there was I would stay up till 4:00 a.m. and then sleep till noon. That's like my natural daylight cycle. And like in that process, you're making so many decisions like how should location work? And you know, we got to find a way of accelerating building while still sort of helping people build intuition of those decisions along the way because otherwise I think you either get just very generic products that are unlikely to break out or ones that just don't reflect some deeper intuition that you come to about your space or your product.
This is great. I love this. It's making me think of two things. One is I have this like little thing in my head that if you grow a tree without it being indoors, without being exposed to wind, it doesn't get as strong because as it's growing, it needs all these forces pushing it like back and forth in order to make a real tree. And so if you have it indoors without wind, you're going to grow a tree, but it leans and it gets all and it's not as strong and it's not the same thing. And I think there's something that you're saying here where because we've accelerated the pace of development so drastically, what would normally be this sort of incremental thing where you're doing things one at a time and then you're exposing it to users, you can actually kind of grow an entire tree indoors and then you have this whole thing that you're just like it doesn't have the same level of intuition and exposure to experience at each step that creates a great product. Is that is that is that...
I love that. I love that metaphor too. We, you know, when we were starting Instagram, we had this, we were very into like Eric Ries and lean startup and the whole like YAGNI, like you ain't going to need it principle. And I have found and actually even one of the things I was working on in labs recently, we way overbuilt for V1 before we even got to early access because you can. You're like, oh well, we have this option. Why not add this one as well? That's like a PR of work. And if you get a really good flow in Claude Code, you know, you're firing things off, you're going to lunch, you're coming back, the thing is done, you're like, great, we added it. And the thing we realized was we created this sort of matrix of functionality that was actually quite hard to test and keep up with right before launch or even to explain to people like they're arriving. The metaphor somebody else gave me which I really like is the difference between sort of getting episode by episode getting to know characters in a TV show versus imagine like you're thrown into the final episode. You're like wait what are all these things and who are all these people and like I already am expected to have all of this context. I think there's the same kind of feeling around like developing something over time. But the tree metaphor I think sticks too as well. And so like showing somebody the fully formed tree is also kind of a lot all at once. And I think there's definitely something there. And how do you build product these days and still keep it simple and not be just because you can doesn't necessarily mean that it should be in at least the first version. I'm having the same problem because, you know, I was literally up until 4 a.m. debugging and fixing this app that I made like on the side at Every called Proof, which is an agent native collaborative marketing editor. So, you can like share really quick plan docs and stuff with your team or with other agents and you have little presences and it's really fun. And this is like my second or third iteration of the full product end to end which is really interesting that you can do now. But the first couple iterations, I just found myself because vibe coding is so fun and so addictive. I just found myself being like, 'Yeah, like I'll do this and I'll do this' and it just created this monstrosity that wasn't that good to use. And I got really inspired by we have another product called Monologue, which I'm not sure if you've run into or not, but I got really inspired by Monologue, which is a really simple speech to text app run by GM Naveen, who he's just so focused on making one simple thing work so well. And I saw how well that works in this age of just like anyone can make a product is like something that's super polished and just super good at what it does. And so I just basically threw out the product and started over with this very simple like it's just a sharable markdown link and that then just started growing virally inside of every like everyone started using it all the time. And then now we launched it and it just blew up and so I spent all last night like not sleeping trying to fix it and being like I'm too old for this shit I can't be doing this anymore because it just reminded me of like being in my 20s or like being in college and like hacking on stuff and whatever which is fun but also exhausting. And so yeah, I've found that I've had to really modify my psychology because so much is possible. How are you dealing with that?
Yeah. And just as a brief aside on that, I remember with Bourbon our biggest mistake was adding functionality over time rather than deleting it, right? And oh, you know, eight features doesn't make for good product. Maybe the ninth one will. Instead, it just made for, you know, something that felt really complicated. I mean, I think a couple of things are also like part of how we're dealing with it is actually being more willing to do rewrites. You know, like classic, you know, Fred Brooks mythical man month like you shouldn't rewrite software because all the things that were imbued in V1, you're going to mess up and...
Exactly. And the whole second system syndrome and there's still a lot of truth to that, but one, you know, the models can help you sort of diff and basically see did you miss anything that was in that first one? But second, it's just it's no longer you're not like talking about a year-long rewrite that might have killed a company like you know famous like Netscape like these are like days probably especially off a given source. So we've actually had several initiatives like usually pre-launch rarely post launch but at least pre-launch like have built the full blown thing realized we've overcomplicated or made some kind of core assumption and then like tore it down a V2 and then iterate on it from there. It doesn't surprise me that that's become sort of part of what you've had to do as well, but it doesn't feel as painful. You're not like, oh, like a year of building this thing. It's like, oh, that was last week and then I get to do it this week and I get to cut out a lot of what was there as well. I think functionality wise and how we're dealing with it from a product development standpoint. I think we are learning to launch earlier. And it's definitely a balance around, you know, we've grown, we have like a strong enterprise footprint. People have expectations about like what the initial version is. But not assuming that we're going to know what every connector or everything that we need to add to the product is ahead of launch because people still will absolutely surprise us, right? We have a strong contingent of we call them ant fooders because we're ants at Anthropic. But only that only gets you so far before you need that real world contact. Like take co-work for example. We'd been noodling on a product of that shape for a long time. And then once we decided no, let's get this out. Let's actually build a V1 that we think solves the problem in the most minimal way possible and get that out in 10 days was really a good push around yes, there are 100 things that V1 should or could have had. But it didn't. And at the same time, it was useful enough to prove something out there. And I'm not sure developing it for another two months, adding, you know, 50 features would have been more useful. In fact, we probably would have been building the indoor tree and then the second it hit real world use, it's like actually nobody wants to do that. They want to do this other piece. So I think that piece like again there's like the intuitions of the original lean startup ideas are still here. It's just they manifest at different time scale and in a different way.
I'm really curious to hear how you think about product design and how products should work because the I've been anyone at Every will tell you the phrase that I use the most or the word that I use the most about the software build is it has to be agent native. So agents have to be able to like use it as anything that an agent a user can do in the app, the agent can do. There's a couple other like little principles of being agent native, but I basically stole that from you guys. Like I think that Claude Code is the canonical thing that taught me about how that kind of product can work so well where it's like it's an agent. It can do anything on your computer that you can do. And it's customizable and flexible and extensible. So, it's easy to start, but it can do all sorts of unexpected things that the designers didn't really think about beforehand. And I think that that's such a good model for AI product development and AI. And I'm kind of curious like this is just sort of what I've cribbed from watching what you guys do and then like kind of put my own spin on, but how do you think about it and how do you talk about making products like that?
Yeah, there's so much in here. And I love the agent native write up you all did. It's like to me the canonical like exploration of this. So, thanks for putting those ideas out in a really clear way. So, I think a few threads to pull on this. One is a conversation I had with somebody recently where they said you know like you all they're a non-technical person. They're like you are talking about like agents and all this stuff like they're just like actually computers just work now. I always wanted computers to work and they didn't work and now they do. And it's just such a funny thing where if you knew the incantations to properly get on the command line and brew install the thing that like nobody is going to do that but now Claude can do it for you and therefore like the computer now feels like a tool that is alongside you. And I think that core insight is it's more than even just adding power and functionality to new software. It's also just unlocking the functionality that always should have been there or available and just felt like extremely hard for people. So that's like maybe thought number one. Thought two is actually comparing our products that do this well versus not. I think Claude Code does it well. I think Claude AI still needs to evolve a lot. So as an example, I was watching somebody use Claude and they were in a project. And they had built I think an artifact or a new document and they said great can you add this to my project knowledge and Claude's like yeah let me tell you the steps to go add it to my project knowledge. It's like no that should just be a thing that it can do really natively. And so I think even in that you see a product that was a 2024 product that has been iterated on and evolved a lot but still I don't think has been baked in from the very beginning the idea that every single one of its primitives it should have knowledge about and the ability to modify and I think that's essential in products these days and I think Claude Code is the 2025 vintage of that and I think there's even further aspects of it when you see what some of the harnesses that folks are experimenting with where that can actually sort of modify the harness itself that starts getting to the next maybe level of that or you know it's probably esoteric for most people but even unlocking that functionality means that you don't have to sit there and be like oh I wish it did this a little bit differently you know I wish Gmail worked in this slightly different way and instead just asking it to and I think that feels like the big next step but even within like Claude Code just teaching Claude Code about Claude Code was a really valuable experience. I loved your write up on agent native and I was like I want this as a skill. So whenever I'm prototyping something it thinks in an agent native way. So I had it packaged it up as a skill and that whole process was you know hey Claude in Claude Code I you know can you create a skill for this? It's like sure I'm looking up my skill. I'm going to create a skill about it. I'm going to install it. I'm like great is that available now or do I need to reload? It said right I think you need to restart it. Let me check. Yep you do. All right, let's get and everything was it has knowledge about itself and that unlocks so much capability in there as well which maybe is like the last thread to pull on. I think all of these could be hourlong conversations which is I think and one of the things that we're really thinking about in labs is how do you imbue the software that Claude builds to be more Claude native sort of building aware so that it even thinks to build in that way to start with because it still won't partially because decades of software is not that right. So, how do you get new software to have that principle baked in?
That's the thing I was about to ask you about. Like, so A, I'm super honored that you read the write up and you're using you made a skill for it. That's amazing. And B, like yeah, you're pointing to a real problem that I have found is I think actually Claude models are the best for this. Like a Codex model generally is not as good at building an agent native because they're models in general unless you push them. They think like traditional engineers and that's a whole different set of you know you want to have guardrails and tests. You want to make sure that there's like one path the user can go down versus we're creating this extensible thing that's super flexible. So yeah, how do you architect your product to teach the models and the harness to teach the models to think and work in this way?
Yeah, I think there's two parts to it. One is the more sort of mundane part and the second one I think is the one that's more sort of interesting in developing. The first one is like even just having good patterns and paradigms available to the model while it builds has been really valuable. Like finding the right balance of templatized to skillified, right? And like what that right balance is. But having, you know, one of the things that we have now is a skill about the Claude API, which sounds super obvious, but even just having that is really valuable because you would sometimes find, you know, we'd launch a new model, it wasn't in the model's sort of innate knowledge, and then you'd get into these really funny arguments like, 'No, no, you made a typo. It's set 45.' You're like, 'No, I know it's like, no, no, no.' So like having that capability having like good templatized examples of that and skills I think helps. But then the second part is what's also interesting is that class of software is just a different type of test. Like it's much harder to sort of write an end-to-end functional test around an agent native product because part of it is that unpredictability. And so another idea we've been kicking around a lot in labs is like how do you increase like the sort of fidelity of the verification? The other day I had an agent native iOS app that I was working on and I was having Claude interact with it and Claude was ended up having a conversation with itself in like a chat feature in the app. It was very funny watching Claude talk to Claude because it's like somebody's pretending to be what humans are. This particular one was like a prototype I was doing about like a sort of work journal reflections and the Claude was like, 'Yeah, my boss is really rough on me. Like I had a hard day.' And then the Claude's like, 'Oh, I'm so sorry to hear that.' And you're just going back and forth. But you wouldn't have written a unit test for this and you know maybe it would have come up with some other emergent idea as well. So I think you just have to go much more towards setting up harnesses that are actually exercising as much of that agent native capability as possible because you don't exactly know what things are going to and things are going to end up in a weird place where Claude's going to try to do something that you wouldn't even think it was going to do and it might put your app in a new state. So maybe circling all the way back to still like what's hard. It's like having the underlying architecture still be robust to that is really important, right? It's like it's agent native, but it's also able to flex in a way that you might not have anticipated, but you've got the right primitives, right? I feel like that is the art and science of software design in 2026.
That's really interesting. I totally agree with you. Yeah, you wanted to have a playground within a safe environment. That's the only way you can have playground is if it's safe around the edges. But I think initially we made the playground like way too small and constrained. And now the models have changed and so we can open it up a lot. But we still haven't figured out exactly like at least I have not figured out exactly what the lines are. Yeah, I think that there's so much here. Like one thing that this is making me think of is I have this idea in the back of my head and I'm wondering if you have a way to put this that is more succinct is like the unit of value in products right now is it's like proof of work or proof of use where when someone on the team submits a PR to me, I want to see not necessarily did all the tests pass because I just assumed that it did, but like send me a loom of you using it or your agent using it so I can tell is it good or not, you know. How are you thinking about that?
Yeah, I think there's probably like three layers to that. Like the first one is like Claude, prove to me that you've exercised this in some way. You know, I've started doing that in all my prompts. I end you know when it's working on a feature I'm like and by the end you know before you PR like prove to yourself and then to me that it works as intended like find the right way of doing it which actually ends up you have to change your own sort of way you build and scaffold around saying what is the right way to get Claude able to at least test this change you know succinctly rather than what it likes to do it's like I read the code it looks good I'm like you wrote the code I don't trust you so you know you got to really test this thing. And then the second one is that what you described is like you know everything having some sort of proof around like is it working as intended and as you intended too because Claude is going to make or any of these models is going to make a lot of decisions for you and sometimes you'll I'll have engineers on the team put up a PR and I'm like oh why did you choose to do this versus that and many times the answer is they didn't choose it was just the choice the model made and maybe it was a reasonable choice it was probably a reasonable-ish choice but it was like the optimal choice does it fit into the paradigm I feel like that is the it's like it's not just proof of work but it's like proof of thoughtfulness, like did you think this through? And I was talking to an engineer yesterday and they were like, 'Oh, I was really I knew you were going to ask me a lot of questions about this.' So, I was reviewing what Claude had done so that I wouldn't be like, 'Uh, I'm not sure.' You know, and that's I don't push on that for most PRs, but when there's one that's like, 'Oh, I'm refactoring this system and there's going to be these new primitives.' Like, great. Let's make sure those are good and that you've thought through how they interrelate because it's very easy to end up otherwise with sort of this sort of tower of assumptions that you're not fully aware of.
I had literally the same experience today because I made Proof totally vibe coded and it's growing really fast right now but it's going down a lot and so I've been spending the last 12 hours like trying to fix it and so we have a little SWAT team internally at Every that like signed up to help me fix it and so I had to like onboard them and I was like fuck how do I explain how this codebase works and so I had to like go back and forth with the model a bunch to be like, 'Okay, help me like define these terms. Help me like figure out how I can explain this so I don't look like a total idiot because like yeah, there's I understand like some of it, but not all of it. Definitely not enough to like the way that I would used to have to know.' And it's a whole different thing to be like, do I need to know that anymore? Is it like where's the line now? It's hard to tell. Which maybe gets to something else and I haven't tried to articulate this so bear with me as I like kind of get there which is yeah there's products that you use that feel robust underneath and there's ones that you use that you're like it feels like it's one wrong command or click away from the whole thing either like freezing or being slow. For us at Instagram like we had Instagram direct messaging v1 and that like who knows if you send a message it might or may not arrive to the other person like we like wrote I wrote our own like bespoke real-time system it was like you fell over a bunch of just you would not trust that to send a message that you really needed somebody else to see. It was just a social thing and when we built V2 it was really important that we really hammered like no like if you send a message we're not probably going to get to WhatsApp level of like you know you can be in the middle of absolutely nowhere with like one bar of edge and it will probably try to still go through. Maybe that's not the bar but still a bar of when I load messages it feels robust when it's sent it's really sent. I feel like there's like a little check. That's like one small example but I think that that is a thing that we still need to figure out how to make you know feel like an essential part of shipping on anything not just at Anthropic but in general like you've built this thing does it feel like it's built on sand or does it feel robust and the agent native part adds something totally even beyond that which...
Is can I push it a little bit and is that going to fall over, or does it feel like, great, I've got a solid trunk and yeah, you can push me in different ways, but you know your data is safe and it's underneath here and it's not just like one deploy away from completely falling over.
So if that's the bar, which I agree like that's where you definitely want to get to, how have you changed who you hire and how your teams are structured as the models have gotten better? Because for us, for example, one of our products, Spiral, we just hired a new GM who is like, I would say he's lightly technical, but he spikes super high on product and writing sense. Spiral is a writing product and now we can like hire someone like that where a year ago we wouldn't have been able to because the coding models weren't good enough. I'm curious like, but the downside is it's maybe the product won't feel quite as robust if there's not someone who's like super technical in all the details. So like, how do you think about who builds products right now inside of the labs team and how that has changed over time and how it will change?
Yeah, I love that. I think it's actually you get pulled in two directions but they're both important. There's the sort of primitives and architectural robustness which I think still need a sort of senior technical force. I was laughing with somebody. They're like, I thought you know my skills in distributed systems were like not going to be useful anymore, but actually those are maybe some of the most useful skills and reasoning about that and you know thinking things through. Like I had a long debate with Claude last week around like whether the system that I was building needed Redis or not or could go away with just Postgres and you know it was a healthy debate where like only because I was grounded in having used a lot of those technologies before. But then there's the other side of robustness which is have you just papered over all the problems with like fixes to your system prompt and additional instructions or have you sort of architected the actual like set of tools correctly? And so the latter is as important and it's probably where this GM can be really valuable and that okay like I'm making changes but just like you wouldn't patch a sort of flakiness in your distributed system by just being like well just retry it in 5 seconds. I'm sure it'll work. Like also not doing the same thing with never ever you know all caps use you know marked out or whatever the thing that you're trying to patch is like they're both actually symptoms of the same thing which is is the underlying piece robust or not. And Claude actually I'd say this about all the models, but I think Claude could be much better at both. It's like still a place that still needs a lot of human oversight on the systems part. You know, it's now able to debug production systems, which is really valuable, but architecting them in the first place. I feel like we're still benefits from somebody who's really thought these things through or has experience. And on the prompting side, you know, if you give it a I've seen people get into this dev loop even internally here, like here's the prompt, here's a mistake that the system made, iterate on the prompt. Its natural tendency is to just add more things to the prompt. And then eventually just get to this thing that, you know, if you onboarded a new employee and you gave them a hundred instructions on their first day, like always answer in markdown except when they, you know, they'll be like, I'm just going to remember the last thing you told me or I'm going to like short circuit it. So then rethinking, okay, is these are these actually two different tools? Is actually two agents that each have a smaller amount of context that then you can break apart. So back to your original question, we're hiring for people with you know systems expertise even within labs which you think of as like more zero to one prototypes like it's still really valuable because again that robustness matters and also just who's going to be you know helpful in sorting through you know systems permissions and provisioning and early testing like that stuff is still you know it's still hard even for Claude when it can't edit the permissions itself which it can't for good reasons. And then on the robustness side actually we've had a lot of success pairing our product teams with our applied AI teams. So our applied teams are the teams that are in the field every day helping customers iterate on their prompts and we've found that we actually are very we're customer zero now for those you know efforts because we have a lot of products that are you know very AI powered. So how do we bring that expertise in here because that expertise does not sit with our software engineers today for example.
What about the in between of like okay it's not the underlying architecture it's not the prompt it's like the UI and the flow who's doing that?
