Dispatch from the Future: building an AI-native Company – Dan Shipper, Every, AI & I

Transcript

I'm the last speaker of the day, so I'm just between you and dinner or drinks, so I'm going to try to make this fun and hopefully a little bit short. So first of all, I just want to say I'm very glad to see everybody, and I'm actually surprised to see so many people here because I've been traveling. I was in Portugal last week, and I was on Twitter, and someone said that everyone was moving to San Francisco, but it's great to have everybody here instead because I fucking love New York. Come on, come on. So I'm supposed to talk today about how to build a playbook for how to build an AI native company, and I actually don't have one, unfortunately, and that's because I think the playbook is actually being invented right now. So we're doing it at the company that I run every day, but all of you are doing it here today as well, and so I don't want to do this talk from the perspective of I have all the answers, and I'm going to tell you the framework and the playbook and all that stuff. But I do think it is helpful when we're in this beginning stage of learning how to use AI to do engineering to build companies, to share the personal experiences that we're having inside of our companies, and collaboratively figure out the playbook together. So I think the best that I can offer is really dispatches from the future, notes on what I've figured out, and the work that we've done inside of Every. And I think the first big thing I really noticed is that there is definitely a huge 10x difference between an org where 90% of the engineers are using AI versus an org where 100% of the engineers are using AI. It's totally different. I think the big thing is if even 10% of your company is using a more traditional engineering method, you sort of have to lean all the way back over into that world. And so it prevents you from doing some of the things that you might do if everyone was not typing into a code editor all the time. And I know this because this is what we do at Every, which is the company that I run, and it has totally transformed what we are able to do as a small company. And so I think of us as a little bit of a lab for what's possible that I'm excited to share with you. So for people who don't know, I run Every. Inside of Every, we have six business units. We have four software products. We run four software products with just 15 people, which is crazy. And these software products are not toys. We've grown at Every, we've grown MRR by double digits every month for the last six months. We have over 7,000 paying subscribers and over 100,000 free subscribers. And we've done this in a very capital light way. We've only raised about a million dollars in total. And very importantly for this audience and for this discussion, 99% of our code is written by AI agents. No one is handwriting code. No one is writing code at all. It's all done with Cloud Code, Codex, Droid, whatever coding agent of your choice. And also really importantly for the size of team we are, each one of our apps is built by a single developer, which is crazy. And these are not little apps. Here's an example. This is Quora, which is an AI email management app. It's an assistant for your email. On the left over here, it summarizes all of your emails that come in so you can read your email that way. This is what my inbox looks like. On the right is an email assistant that you can ask questions. Like I asked, when's my AI engineer talk today? And it gave me the answer. And this is built primarily by one engineer. He's got one or two contractors that have helped in certain ways, but almost all of this is built by one guy. Same thing for this app, which is another one that we make called Monologue, which is a speech to text app. It's sort of like Super Whisper or Whisper Flow if you know of those. Again, one guy, thousands of users. I love it. It's beautifully done. And it's not simple. It's complicated. There's a lot of stuff to it. Same thing for this app called Spiral. You can see it's big. And again, one engineer. So obviously this would not have been possible a few years ago. It would not have been possible even a year ago. And I think the big change that happened that we're all starting to catch up to is it started with Cloud Code, a sort of terminal UI that gets rid of the code editor, which really pushed us into a place where we are delegating tasks to these agents. And that allows us to work in parallel and do much more than we would have ordinarily. So some of the things that I've noticed that we can do that I assume people in this room are starting to see, but I think it's important to put our finger on is the reason we can go much faster is we can work on multiple features and bugs in parallel. And I think there's a meme of the vibe coder on Twitter that is, oh, they have four panes open, but they're not actually doing any work. And I actually, you can do it that way. And I think there are also definitely engineers, and I know that they are because they work at Every, that are productively using four panes of agents at the same time. And that's crazy, and that contributes a lot to the ability for a single developer to build and run a production application. Another really important thing about this, a really big unlock is because code is cheap, you can prototype risky ideas. And that allows you to do more experiments than you would ordinarily. And that lets you make way more progress because the starting energy to try something is so much lower because you just say, oh, go do this, go do some research on this big refactor I might want to do. And then you go off and do something else. And that's a really big deal. And another really interesting thing that I love about this stuff that I've noticed inside of our organization is we move more toward a demo culture where instead of previously if you wanted to make something you'd have to be like... You can prototype risky ideas. And that allows you to do more experiments than you would ordinarily. And that lets you make way more progress because the starting energy to try something is so much lower because you just say, oh, go do this, go do some research on this, a big refactor I might want to do. And then you go off and do something else. And that's a really big deal. And another really interesting thing that I love about this stuff that I've noticed inside of our organization is we're moving a bit more toward a demo culture where instead of previously if you wanted to make something you'd have to write a memo or do a deck or convince a bunch of people that it was a good idea to spend time on. Because you can code something in a couple hours that shows the thing that you want to make. It allows you to show everybody. And I think being a demo culture allows you to do weirder things that you only get if you can feel it, which is really amazing. And beyond the basic productivity unlocks, AI and the way that we use it has caused us to invent an entirely new set of engineering primitives and processes, which I am sure that everybody in this room is starting to do already. I think everyone is approaching the same things from different angles. And a lot of them definitely echo engineering processes from the past. But I think it's really helpful to try to put our finger on, okay, what is the new way of programming if we're moving up a level of the stack and we're moving from Python and JavaScript and scripting languages up into English. And the name that we've given to this process is compounding engineering. And the way that I talk about compounding engineering is in traditional engineering, each feature makes the next feature harder to build. In compounding engineering, your goal is to make sure that each feature makes the next feature easier to build. And we do that in this loop. The loop has four steps. The first one is plan. And if you've been here today and you've been paying attention, you know how important it is when you're working with agents to make a really detailed plan. So I think everyone is doing that. Second step is delegate. Just go tell the agent to do it. Everyone's doing that too. Third step is assess and we have tons of ways to assess whether the work that the agent did is any good. There's tests, there's trying it, there's having the agent figure it out. There's code review, there's agent code review, there's all those types of stuff. And then the last step, which is the most interesting one, is codify. And this is the money step, which is where you compound everything that you've learned from the planning stage, the delegation stage, the assessment stage, back into prompts that go into your cloud MD file or your sub agents or your slash commands. And you start to create this library. You take all the tacit knowledge that you pick up, that all your engineers are picking up as they find bugs, fix plans, delegate work, and you make it into an explicit collection of prompts that you can spread for your entire organization. And when you do that really well, there's a lot of really interesting second order effects that are not well understood or commonly talked about that I think would be interesting to bring here. Because my guess is that some people are already seeing this, but maybe it needs to be pushed on a little bit more to really be brought out. And some people, it might be an interesting way to get more of your organization to buy into using these tools 100% of the time. So the first thing that you notice if you set up this process and you're 100% bought in on something like compounding engineering is that tacit code sharing becomes much easier. So we have multiple products. A lot of products a lot of times need to implement similar things, even if they use different technologies. Like implementing similar things like a Teams feature or a certain type of OAuth or whatever. Previously, in order to share code, you'd have to abstract out whatever you did into a library and then allow someone else to download it, and it'd be hard to do or you'd have to talk about it. With agents, you can just point your cloud code instance at the repo from the developer sitting next to you and learn the process that they went through to build the feature that you need to reimplement and reimplement it yourself in your own tech stack, in your own framework, and in your own way. And that's really cool to have this. The more developers you have working on different things inside of the org, the more you can share without any extra cost because AI can just go read all the code and use it. Another really cool thing that I've noticed is that new hires are productive on their first day because you've taken all of the things that you've learned about like, okay, how do I set up an environment and what does a good commit look like and all this kind of stuff. And on the first day, they have all that set up in their cloud MD files or their cursor files or codex files or whatever. And the agent just sets up their local environment and knows how to write a good PR. That's really cool. It also helps if you want to hire expert freelancers. Like there's one person who is really good at this one specific thing. You can have them come in for a day and do that thing. I think of it a little bit like a DJ who can go in on a couple bars of a song. You can just sort of drop in and that's really helpful. It would ordinarily be too hard to collaborate because the startup cost is too high, but you can do that much better now. Another thing that I've noticed, which is really cool too, is developers inside commit to other products. So we have four products that run internally. Everybody uses all the products. If someone runs into a bug or a paper cut, a little minor quality of life thing that they want, they will often just submit a pull request for it to the other team of the app because it's very easy for them to go download the repo and figure out how to have cloud or codex figure out, okay, this is how we fix the bug or this is how we fix the paper cut. And that's really cool because you have this much easier way of collaborating across apps that I think over the next couple of years, I imagine that you will also be able to let customers do this to some extent. Like if you run into a bug, this is speculative, but if you run into a bug, you can have your little agent fix it and submit it as a pull request. It's a weird open source thing, but yeah, this is really cool and definitely is happening a lot inside of our company. Another really cool thing is we have not, this may get different as we scale, but we have not yet had to standardize onto a particular stack or language. We instead let everyone who's building different products pick the thing that they like best. And the reason is because AI makes it much easier to translate between them. And it makes it much easier to jump into any language and framework and environment and be productive. And so we don't, it's easier for us to let people just do the thing that they like. It's a weird open source thing, but yeah, this is really cool and definitely is happening a lot inside of our company. Another really cool thing is we have not, this may get different as we scale, but we have not yet had to standardize onto a particular stack or language. We instead let everyone who's building different products pick the thing that they like best. And the reason is because AI makes it much easier to translate between them. And it makes it much easier to jump into any language and framework and environment and be productive. And so we don't, it's easier for us to let people just do the thing that they like and let AI handle the translation in between. And the last thing, which is my favorite, but is also the horror, I think, of some developers and to some degree, maybe the horror of my team, is that managers can commit code if you're technical, even the CEO. And for me, I have no business committing code because we've got four products, we've got 15 people, we're growing really fast. I'm doing tons of other things, but I can and I have committed production code over the last couple months. And the reason for that is AI allows engineers to work with fractured attention. So previously you might have needed a three or four hour block of focus time in order to get anything done. But with Quad Code, you can get out of a meeting and say, hey, I want you to investigate this bug, and then go do something else, and then come back and you have a plan or a root cause fix. And then you can submit a PR. And it's not easy, it's not magic, but it is actually possible. And I think that's a totally new way of thinking about how managers interact with the products that they make. So just to summarize, I really think there's a 10x difference in how things work when you hit 100% AI adoption. I think from what we've seen, a single engineer should be able to build and maintain a complex production product. I think it's not what we call compounding engineering, but I think what all of us are pointing to is, I think it really works to make each feature easier to build and then creates all of these non-obvious second order effects that makes it easier for the entire organization to collaborate together. And very importantly, many people in San Francisco don't know this yet. So you're the first to hear it. So that is my talk. So if you're interested in what we do, I run Every. Every is the only subscription you need to stay at the edge of AI. You can find us at every.to. We have a daily newsletter about AI, so we do ideas, apps, and training. On the ideas side, we have a daily newsletter. We review all the new models when they come out and all the new products when they come out. The apps, you already saw, we have a bundle of all these apps. And then we do training and consulting with big companies to help them use AI. And it's all bundled into one subscription, so you get everything for one price. And that's it. Thank you very much. Thank you. Thank you. Thank you. It's complicated. There's a lot of stuff to it. Same thing for this app called Spiral. You can see it's big. And again, one engineer. So obviously this would not have been possible a few years ago. It would not have been possible even a year ago. And I think the big change that happened that we're all starting to catch up to is, it started with Cloud Codes, a sort of like terminal UI that gets rid of the code editor, really pushed us into a place where we are delegating tasks to these agents. And that allows us to work in parallel and do much more than we would have ordinarily. So some of the things that I've noticed that we can do that I assume people in this room are starting to see, but I think it's sort of important to put our finger on is the reason we can go much faster is we can work on multiple features and bugs in parallel. And I think that there's a, there's like a little bit of a meme of the vibe coder on Twitter that is, oh, like they have four panes open, but they're not actually doing any work. And I actually, you can do it that way. And I think there are also definitely engineers, and I know that they are because they work at every, that are productively using four panes of agents at the same time. And that's, that's crazy. And that, that contributes a lot to the ability for a single developer to build and run a production application. Another like really important thing about this, a really big unlock is because code is cheap, you can prototype risky ideas. And that allows you to do more experiments than you would ordinarily. And that lets you make way more progress because the starting energy to try something is so much lower because you just like say, oh, go do this, go do some research on this like big refactor I might want to do. And then you go off and do something else. And that's a really big deal. And another really interesting thing that I love about this stuff that I've noticed inside of, inside of our organization is we move, we're moving a bit more toward a demo culture where instead of, you know, previously if you wanted to make something you'd have to be like, maybe write a memo or do a, do a deck or, or, you know, convince a bunch of people that it was a good idea to spend time on because you can vibe code something in a couple hours that sort of shows the thing that you're, that you want to make. It allows you to show everybody. And I think that being a, being a sort of demo culture allows you to do weirder things that you only get if you can feel it, which is, I think, really amazing. And beyond just like sort of the basic productivity unlocks, AI is, and the way that we use it has caused us to sort of invent an entirely new set of engineering primitives and processes, which I am sure that everybody in this room is starting to do already. I think everyone is sort of approaching the same things from different angles. And a lot of them definitely do echo engineering processes from the past. But I think it's really helpful to try to put our finger on, okay, what is the new way of programming if we're moving up a level of the stack and we're moving from, you know, Python and JavaScript and scripting languages up into, up into English. And the name that we've given to this process is compounding engineering. And the way that I talk about compounding engineering is in traditional engineering, each feature makes the next feature harder to build. In compounding engineering, your goal is to make sure that each feature makes the next feature easier to build. And we do that in this loop. The loop has four steps. The first one is plan. And if you've been here today, you've been paying attention, you know how important it is when you're working with agents to make a really, really detailed plan. So I think everyone is doing that. Second step is delegate. Just like go tell the agent to do it. Everyone's doing that too. Third step is assess and we have tons and tons of ways to assess whether the work that the agent did is any good. There's tests, there's trying it, there's having the agent figure it out. There's code review, there's agent code review, there's all those types of stuff. And then the last step, which is, I think the most interesting one is codify. And this is kind of like the money step, which is where you compound everything that you've learned from the planning stage, the delegation stage, the assessment stage, back into prompts that go into your, you know, your cloud MD file or your, your sub agents or your slash commands. And you start to basically create this library. You take all the tacit knowledge that you pick up, that all your engineers are picking up as they find bugs, fix plans, delegate work, and you make it into an explicit collection of prompts that you can spread for your entire organization. And when you do that really well, there's a lot of like really interesting second order effects that are not, I think, that well understood or that commonly talked about that I think would be interesting to bring here. Because my guess is that some people are already seeing this, but like maybe it needs to be pushed on a little bit more to like really be brought out. And some people, it might be an interesting way to get more of your organization to buy into using these tools 100% of the time. So the first thing that you notice if you set up this process and you're like 100% bought in on something like compounding engineering is that tacit code sharing becomes much easier. So we have multiple products at every. A lot of products a lot of times need to implement similar things, even if they use different technologies or implementing similar things like a Teams feature or a certain type of OAuth or whatever. Previously, in order to share code, you'd have to like abstract out whatever you did into a library and then like allow someone else to download and it'd be hard to do or you'd have to talk about it. With agents, you can just point your cloud code instance at the repo from the developer sitting next to you and learn the process that they went through to build the feature that you need to reimplement and reimplement it yourself in your own tech stack, in your own framework, and in your own way. And that's really, really cool to kind of have this. The more developers you have working on different things inside of the org, the more you can share without any extra cost because AI can just go read all the code and use it. Another really cool thing that I've noticed is that new hires are productive on their first day because you've taken all of the things that you've learned about like, okay, how do I set up an environment and what does a good commit look like and all this kind of stuff. And on the first day, they have all that set up in their cloud MD files or their cursor files or codex files or whatever. And the agent just sets up their local environment and knows how to write a good PR. That's really cool. It also helps if you want to hire like expert freelancers. Like there's some, there's one guy, there's one person who just is really good at this one specific thing. You can have them come in for a day and like do that thing. I think of it a little bit like a DJ or whatever can like go in on like a couple bars of a song. Like you can just sort of drop in and that's really helpful. It's, it would ordinarily be like too hard to collaborate because the, the startup cost is too high, but you can do that a lot better now. Another thing that I've noticed, which is really cool too, is developers inside of every commit to other products. So, you know, we have four products that run internally. Everybody uses all the products. If someone runs into a bug or a paper cutter, like a little minor quality of life thing that they want, they will often just, they will often just, just submit a pull request for it to the other GM of the app because it's very easy for them to go download the repo and figure out how to have really have cloud or codex figure out, okay, this is how we fix the bug or this is how we fix the paper cut. And that's really, really cool because you have this much, much easier way of collaborating across apps that I think over the next couple of years, I imagine that you will also be able to let customers do this to some extent. Like if you run into a bug, this is, you know, speculative, but if you run into a bug, you can have your little agent fix it and submit it as a pull request. It's a weird open source thing, but yeah, this is really, really cool and definitely is happening a lot inside of our company. Another really cool thing is we have not, this may get different as we scale, but we have not yet had to standardize onto a particular stack or language. We instead let everyone who's building different products, like pick the thing that they like best. And the reason is because it makes it, AI makes it much easier to translate between them. And it makes it much easier to jump into any language and framework and environment and be productive. And so we don't, it's easier for us to let people just do the thing that they like and let AI kind of like handle the translation in between. And the last thing, which is my favorite, but like is also the horror, I think, of some developers and to some degree, maybe the horror of my team, is that managers can commit code if you're technical, even the CEO. And for me, like I have no business committing code because we've got four products, we've got 15 people, we're growing really fast. I'm doing tons and tons of other things, but I can and I have like committed production code over the last couple months. And the reason for that is AI allows engineers to work with fractured attention. So previously you might have needed like a three or four hour block of focus time in order to like get anything done. But with quad code, you can kind of like get out of a meeting and say, hey, like I want you to investigate this bug and then go do something else and then come back and you have like a plan or like a root cause fix. And then you can submit a PR. And it's not easy, it's not magic, but it is actually possible. And I think that's just a totally new way of thinking about how managers interact with the products that they make. So just to summarize, I really think there's a 10x difference in how things work when you hit 100% AI adoption. I think from what we've seen, a single engineer should be able to build and maintain a complex production product. I think it's not what we call compounding engineering, but I think what all of us are sort of pointing to is, I think it really works to make each feature easier to build and then creates all of these sort of non-obvious second order effects that makes it easier for the entire organization to collaborate together. And very importantly, many people in San Francisco don't know this yet. So you're the first to hear it. So that is my talk. So if you're interested in what we do, I run Every. Every is the only subscription you need to stay at the edge of AI. You can find us at every.to. We have a daily newsletter about AI, so we do ideas, apps, and training. On the ideas side, we have a daily newsletter. We review all the new models when they come out and all the new products when they come out. The apps, you already saw, we have a bundle of all these apps. And then we do training and consulting with big companies to help them use AI. And it's all bundled into one subscription, so you get everything for one price. And that's it. Thank you very much. Thank you. Thank you. Thank you.