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

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 kind of surprised to see so many people here, because I've been I live here, but 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 inventedright now. So we're doing it at the company that I run every 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 kind of 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 sort of collaboratively figure out the playbook together. So I think the best that I can offer is really just sort of 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, the first big thing I really noticed is that there is definitely a huge there's a 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 kind of crazy. And these software products are not toys. We've grown at Every. We've grown at 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 $1 million 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 Claude Code, Codex, Droid, what have you,

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 Kora, which is an AI email management app.

It's sort of an assistant for your email. On the left over here, it summarizes all of your emails that come in, so you can kind of read your email that way. This is what my inbox looks like. On theright is an email assistant that you can ask questions, like I asked, where's my AI engineer talk today?

And it just 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 WhisperFlow, if you know of those. Again, one guy, thousands of users. I love it. It's just a beautifully done app, 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, this sort of 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 little bit of 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 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're moving a bit more toward a demo culture, where instead of previously, if you wanted to make something, you'd have to maybe 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 Vibe Code something in a couple of hours that sort of shows the thing that you want to make, it allows you to show everybody. And I think that 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 sort of the basic productivity unlocks,

AI 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, OK, 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, 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 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 these 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 Cloud MD file or your subagents 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 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 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 at Every. A lot of products, a lot of times, need to implement similar things, even if they use different technologies or are 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 re-implement and re-implement 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, OK, 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. 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 do that thing.

I think of it a little bit like a DJ or whatever 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 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 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 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 or really have Cloud or Codex figure out, OK, 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 easier way of collaborating across apps that I think, over the next couple years, I imagine that you will also be able to let customers do this to some extent.

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, 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 it's easier for us to let people just do the thing that they like and let AI kind of 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 and 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 Cloud Code, you can kind of 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 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.

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.