Tsunami of capabilities

Ben and I used to live together — best friends. Alexis and I met in college and quickly became really close friends, started a company, took it through the Series B, sold it to Coinbase. This was around the time ChatGPT came out. Ben was a designer at Apple, first an engineer then a designer, and just one of the most talented people I have ever met, and a close friend. So we started hacking on things together after ChatGPT came out, and quickly realized we had so much fun working together that we had to do something. We were able to lure him away from Apple after four years there.

If you look at designers who leave Apple, you will notice there are not many successful founders that come out of that. It is not because they are not talented. I think if you look at the design team specifically, it is very easy to feel like the success of something is because of you, because industrial design is the most important thing. But you can mistake the “designing the iPhone part” for the success of the iPhone part, feeling like you built the iPhone, when a lot of the iPhone’s success comes down to how you translate what the thing is to people.

The other thing that is very different is that when you are at Apple – everyone cares about what you are making. The whole world. Even the Vision Pro, which I do not think is Apple’s most successful product, the whole world saw it and engaged with it and talked about it. Whereas the default for startups is that no one cares. Even if everyone cares for a minute, they forget instantly. So you have to learn this sense of rejection, of people not running toward what you are doing right away.

The first thing we worked on was a tool called Sidekick. This was over three years ago. Cursor had just pivoted, they were originally building an IDE in Rust and then moved to VS Code. We were all engineers, and we had this idea. There used to be a class of scribes who were the only people able to write. So all of history only reflects the class of people designated as scribes. We felt like we were entering a new era where engineers are the scribes of code, and now everyone is going to be able to code. That was very exciting to us.

We built for engineers. Our own AI product with Sidekick was pretty successful, but it was actually very hard to get a sense of where our agents were failing in production. There was all this data, and using that understanding to make the product better — that whole loop did not exist. So we started building tools for ourselves, and then realized that everyone building an agent, which was going to be everyone, had this problem. So we launched what became Raindrop last summer, and it was insanely resonant. Some of the best AI companies in the world, Vercel all the way to Fortune 500s, are using us. It has been bigger than we expected. We have started calling it humanity’s last problem internally, because agents are being deployed in finance, military, healthcare, and when they fail it is catastrophic.

The really weird thing is what a failure even means. A year or two ago, the failures people thought about were things like outputting JSON incorrectly, or hallucinating something completely random. Those still happen, but a lot of what people mean by failure now is that the agent did not do the thing they wanted, which is a little different.

There was this lawsuit with Air Canada where a user requested a refund and the agent gave it to them, and then the company said no, we do not refund that, and the user said but you told me I would get it, and they won. The customer won, because you cannot tell people they are going to get a refund if they are not. There was another with Virgin where the chat would end whenever someone used the word Virgin, because it flagged as NSFW, so it would say it could not engage with that language. Any of those things, a different person might have wanted the agent to actually give the refund, or to check first. So it comes down to what you actually want the agent to do.

This is the thread that runs through everything for me. I always chase design problems that feel unbounded, where the input space and the output space are both very large. You can come to an agent and say anything, and it can do anything. How do you create some framework around that without limiting it, without constraining it, but still letting people comprehend it. That is where our team really shines. It is a lot of applied ML but you also see product making a huge difference in how people actually use it.

One is being honest with yourself. This is one of the hardest things for designers to do, and it is why our team would never want to build in a space where we were not also the user. It is so easy to fool yourself into thinking, oh, I would love to have X button or X feature, when nobody wants that. Or the classic, what if we did not do this, and you realize it would be fine. So everyone has to be an actual user. We use Raindrop a ton internally.

We look for people who are very curious in general. From a product design standpoint, I almost see design as unraveling fundamental rules about the universe. It sounds grand, but think about working on the Vision Pro. From an OS perspective, we had to figure out the right way to do it. What is an app, what is a window, how do you move windows, how do they interact, how do you think about a VR app versus a window. The answers seem a lot more obvious now. Regardless of whether the Vision Pro goes anywhere, those ideas feel like they unraveled something true about how to design that kind of thing.

We feel the same way about Raindrop. When we started, there really was no production observability platform for agents. Every single platform at the time would just do token counting, maybe a hallucination score, or sentiment, positive or negative, which is completely useless. If someone says “I hate my life,” that is super negative sentiment and it does not mean anything. It was super contrarian at the time. The predominant wisdom was that every team needs to write a ton of evals, and we are building agents, and we do not love writing evals, the same way we do not write that many unit tests except for the core parts of the app. What we love is that we have Sentry, and when something goes wrong we get an alert, and that lets us ship really fast on the things that are less critical. That is what we wanted. I got into a Twitter fight with one of the big eval companies of the time over this, and they said it was completely wrong.

No, it was the complete opposite. Nobody really thought it mattered, which is crazy. There was a lot of cognitive dissonance. You have something that is working and you do not want to change it. We were also really early. A lot of products were not at the scale yet where it mattered. We have this idea internally we call a tsunami of capabilities. The problem becomes more important as agents become more complex, because their capabilities become more open ended, the things they can do are wider and harder to test in advance – especially as agents become more capable they get deployed at higher and higher stakes, in healthcare, in law. At the time, even the biggest companies besides ChatGPT only had a few thousand interactions, so it did not really matter. Now we have customers with millions and millions a day, and that is where professional observability really matters.

As an engineering company, the most core part of taste is the nouns we have, the way people understand our platform. We have core pillars. The first is what we call stumbles. Every time a user in your app hits any kind of trouble, it shows up as a stumble. It is a firehose of stumbles. Not all of them are things you want to fix, but these are the problems people are having. Then if there is a real issue, something new breaks, a tool breaks, you push a change and suddenly the agent is lying to people or does not know who they are, that graduates into what we call an issue. An issue shows you how many people are affected and all the relevant tags. For very long running things, issues are meant to be solvable. But there are kinds of things in AI products that are not solvable. People complaining about aesthetics, for instance. If you are making a vibe coding platform, people will complain no matter what, because not everyone is at the same skill level. What you want to do there is track it over time, see if it spikes, and use it in experiments and A/B tests. That leads to the last unit we have, which is an experiment. You can test a feature flag, test a model, and see how things changed. Pretty much every other platform ends up either complicated or having a weird story where you have to buy into some whole world rather than just plugging into the agent you are building. One of the founders of a very large coding company said the other day that we are the only people who actually made the right solution in this space, in terms of his mental model for it. And that mental model translates to the SDKs, to the UI, even through MCP, the parts you do not see as UI. It permeates through.

It is another example of being honest with ourselves. We try to use Raindrop the most. Up until we released Workshop, everybody working on agents locally would use some remote eval or tracing dashboard, whether Raindrop or something else, to see their traces. But you are waiting seconds for things to show up. At one point I had Raindrop side by side with the agent, watching the agent stream every token in, watching things show up one span at a time, and thought, this is kind of silly. If I am running my agent locally I should be able to see my traces locally. And wouldn’t it be cool if my coding agent could see my traces, without even needing a server. Someone could just build it, and there are really nice things about us being the ones to build it, because it can be tightly integrated with the rest of our platform. That is the being honest with yourself part. A lot of people would rather cram it into their app somehow, and we would rather build the thing that should exist.

Raindrop is designed for agents as much as for humans. It makes sense, because a lot of the way humans use us now is through agents. We had a launch with Devin from Cognition recently where Raindrop has first party support for Devin to do auto self healing loops. Raindrop finds an issue, pushes that to Devin, and Devin fixes the problem in your agent based on all the context Raindrop has. That will only become more true.

The most important thing is the vocabulary. Imagine if we did not call issues issues, if we called them alerts. A user comes and asks what issues exist, and you have to say there are no issues. Weird things like that. Creating and defining your own vocabulary, because this is an entirely new problem set, is very important. The hardest thing is keeping that vocabulary clear and consistent, especially because the space is changing constantly. The reason our company is doing well right now is that we are constantly at the bleeding edge of what is possible and how agents are changing, building the tools people will need a month or so out. Keeping the nouns consistent all the way down to the DB layer, for users and for agents and in the SDK, is hard.

Right now it is self healing, and making that real. Everyone’s sales pitch in the last month or two has been self improving, self healing, and mostly it just does not work. That is the being honest with yourself part too. I think what we have built actually works. We recorded a video with the CTO of Speak the other day, the language learning app with 15 million users, talking about exactly how they use it and how it heals itself. There are right ways to do it, and a lot of our launches are laying the groundwork. Workshop is part of that. You can ask Devin to install Workshop, run your agent, and check the traces in Workshop, reducing latency a ton, isolated from your production data from a security perspective.

None of these launches are random. The whole next phase of agents has two buckets of issues. There are issues you can just fix, something breaks, a tool stops returning data, it times out. Then there is another class that is longer running and more behavioral, around personalization or tone. Those you cannot just fix. You have to run experiments. That is what we are focused on.