Unlocking Enterprise Value // Ricky Doar

Demetrios Brinkmann [00:00:04]: How's it going? I'm good, man. How you doing?

Ricky Doar [00:00:08]: I'm doing well. I'm doing well. I'm excited to be here.

Demetrios Brinkmann [00:00:11]: First of all, thanks for coming on here. Thanks for doing this. I'm super excited to chat with you about Cursor. It's pretty much every single developer that I know is either a die hard user of Cursor or they are playing around with it and getting a ton of value from it. You've been leading the whole solutions team. You talk with forward deployed engineers every day. That's like literally your job. And so I want to go over all of the cool stuff that you've been seeing out there in the wild.

Ricky Doar [00:00:41]: Yeah, I would love that. Sounds awesome. It's been a wild year, definitely. Cursor has been having quite the year, quite the kind of year of growth and we've been talking to hundreds and hundreds, if not thousands of enterprise companies at this point.

Demetrios Brinkmann [00:00:57]: That's huge, man. And congrats on the huge announcement last week. I think everybody saw the number in the raise and had to do a double take. So that is very cool, very exciting. I know you've done a bunch of stuff. You were at Vercel, you were doing. I mean, you've been doing this kind of thing for ages. I know you're excited about what's going on in Cursor and maybe we can just go into this real fast with like, what patterns are you seeing the most successful folks doing when your forward deployed engineers who are on the front lines are coming back and saying like, dude, you'll never believe how these guys are using Cursor.

Ricky Doar [00:01:37]: Yeah, yeah. I mean it's definitely, you know, engineers everywhere are kind of learning how to build with AI. They have been for the past few years, but it's really kind of accelerating this past year. I think first and foremost it is good to recognize that working with AI is, is a new skill. It is a skill that is adjacent to engineering. It's not exactly engineering and just, just like, you know, great engineers learn the right ways to think first and that's kind of more important than, you know, memorizing syntax. It's very, very similar in the AI space is there's kind of a new way to kind of think, think alongside these lms. Whether you're kind of working with AI in the foreground and kind of working as a pair programmer with AI or spinning up these agents in the background and kind of spinning up these tasks.

Ricky Doar [00:02:28]: Kind of the best people that we work with on a day to Day basis are the ones that are really, really good at breaking down large problems into bite sized tasks that the AI is far more likely to be able to accomplish, rather than either going way too small or way too large and kind of running into these areas where AI hallucinates. So I think that that's probably the first and foremost skill we see that separates the power users from the people that in the early days struggle is can you understand the right size of problem to hand off to AI. And it's really all about how do you manage context and how do you build your prompts?

Demetrios Brinkmann [00:03:05]: Yeah, the context is so huge. I actually, if you stick around, you'll see I made a video about context while I am here in Amsterdam enjoying myself. But is there like a rubric that you have looked through on how to separate what is too big and what is too small, or is it just like trial and error, throwing things at the wall?

Ricky Doar [00:03:30]: It's a little of both. Right. You know, as these models get smarter, you know, this has been obviously again a huge year for AI. We've seen tons of model releases through the year. You know, if we take like anthropic as an example, you know, Claude, 3, 5, turned into 3.7 turned into 4 turn into 4, 5. There's also Sonnet, there's opus. As these models get better and they get smarter, it kind of changes what they're able to accomplish. And you know, there's also no substitute for just kind of getting to know these models.

Ricky Doar [00:03:58]: These models have different levels of intelligence. They also tend to have, I mean, if you talk to engineers that work with these models on a day to day basis, they have personalities and what they're good at and what they're bad at. And I wish there was some easy answer of just a framework of how big a problem should be so that the AI can accomplish it. But a lot of it is getting to know how good the AI is at the given task that you're working on and really kind of learning what size tasks can a model like GPT5, one Codex that just released recently solve that maybe GPT4 or even GPT5 couldn't solve to, you know, two months ago. So a lot of this is just getting familiarity with the tools you're building with, and then you kind of build this internal barometer of, you know, what can this model accomplish and what can't it? Where does it often go wrong or hallucinate?

Demetrios Brinkmann [00:04:48]: All right, Randy, I got to take off my glasses because I need to see you for this one. I need you to see me for this one. What are some anti patterns? What are some ways that we shouldn't be using cursor?

Ricky Doar [00:05:00]: Yeah, it's a really great question. I mean, I think one of the things that we've seen that people struggle with is either they get extremely reliant on the AI and they forget that a huge part of building AI is not replacing your brain to strategize and to understand your code base and to build the right. Make the right architectural decisions as you're building out with AI, it's certainly extremely powerful, extremely helpful. You can ask a bunch of questions of your code base. You can use it to ramp up on code bases very quickly. But I think a lot of potentially can skip that first stage of do you know your code base extremely well? There's multiple ways you can use cursor. One of them is just ask mode. It means it's not going to write any code.

Ricky Doar [00:05:49]: It's just going to answer questions about how your code base works. And, you know, one of the downsides of AI is it can make you lazy. And as you get a little bit lazier, you start giving vaguer and vaguer prompts. You start, you know, pushing off a lot of the strategic decisions to AI as well. You know, there's a world where we might get to a place where models are good enough, where that's okay, but for now, it actually just lulls you into a false sense of security. You have to stay in the driver's seat. You have to make the right decisions architecturally. You have to, you have to drive the agent in the right direction.

Ricky Doar [00:06:22]: I think that's the biggest anti pattern we see, you know, across the board.

Demetrios Brinkmann [00:06:26]: That's so true. You get into this false sense of comfort and you keep offloading, offloading, offloading, and then it'll bite you right when you're not expecting it.

Ricky Doar [00:06:37]: Exactly.

Demetrios Brinkmann [00:06:37]: Well, since you said, how are we doing? Like, you gave us that anti pattern and you mentioned searching or getting up to date on a code base really quickly. I'm wondering about Greenfield versus Brownfield, and basically what you're seeing when you're going from zero to one versus what you're seeing when you're dealing with a code base that's 15 years old. Maybe you're still. You got some stuff that's deprecated in that code base to the outside world, but internally it's not. Like, how do you deal with cursor in those instances?

Ricky Doar [00:07:11]: Yeah, I mean, obviously AI is super exciting in the Greenfield space. It's fun to make a prompt and just see something get created before your eyes. But I think this is also kind of one of the biggest advancements over the last year with Cursor, with other tools. But Cursor is phenomenally good at this is how do you take the context of your code base and use that to your advantage. This is also there's discussions, debates in the AI space of what is the best way to use a code base correctly. Some tools, they only grep through the code base as you're writing prompts. Cursor has found phenomenal success indexing your entire code base before you start asking any questions. It indexes your code base.

Ricky Doar [00:07:56]: It creates essentially a semantic search. If I say, hey, I want to add authentication to this page, it can actually look throughout a massive code base, 500,000 files, millions and millions of lines, and determine what area of the code base are most relevant to that prompt and pull that in. So one, the tools have got a lot better at Brownfield because they can pull a lot of the surrounding context and actually have patterns to match off of rather than just purely building whatever they decide to build. And I think this is an area where both the engineer has to be familiar with the space that they're building in, but also the tools can pull context from different codes, different files throughout the code base to have patterns to build on top of. So I think it's actually a little bit of a myth right now that AI is far better at Greenfield than it is at Brownfield. That was true maybe last year when there wasn't good ways to semantically search to quickly grep through your code base. But now with Cursor, we have semantic search. We also have lightning fast parallel grep.

Ricky Doar [00:09:03]: As you ask these questions, the most important part is if you can give AI examples to follow. Right. You know, I have, you know, I'm trying to build out a new API or new infrastructure or new, you know, whatever it is. I try to fix this bug or refactor this area, map it to other areas that you know are built well.

Demetrios Brinkmann [00:09:24]: And do you do that just like kind of give pointers, maybe check this file or I've seen this done well with this API or I want to create an API like this.

Ricky Doar [00:09:35]: Yeah, definitely. So I mean, specifically in Cursor you can add different files and say like, hey, you know, I really love how this API framework is set up. I want to, you know, add a new endpoint to this API, have it map the architectural choices that have been made before. Right. You can add A lot of these different things. This is also, you know, very important when you're building front end. Kind of like, you know, changing front end pieces is you can tell the AI, hey, we have a very specific design system. Please make sure you're using the components, the colors, the design framework that we've used to build the rest of this application.

Ricky Doar [00:10:14]: A lot of building correctly with AI is making sure that you're minimizing the amount of arbitrary decisions that the LLM can make. You know, if the arbitrary decision is right 80% of the time, but it has to make 100 arbitrary decisions. You're going to build something that is not quite correct if you can minimize those arbitrary decisions. And with Brownfield, it actually is easier to minimize those arbitrary decisions because you have a code base to map onto.

Demetrios Brinkmann [00:10:43]: Yeah, of course you can say, oh, yeah, like this is an obvious example. And I like how you said that with the examples. How have you seen the best folks maintain their context windows?

Ricky Doar [00:10:57]: Yeah, so I think there's a lot of, I mean, there's a lot of best practices. There's also a lot of, like, false myths about context. I think, you know, as we go throughout this year, people are learning more and more. But I think there was originally this myth that, like, the more context you give it, the better it's going to be. And if you just add as much context as you possibly can, you're going to get a better and better answer. There's a lot of research and a lot of studies that show that, that even these, you know, these models that have a million token context windows, as they get to about 50% full and they get into 60, 70, 80% full, you're sending, you know, 800,000 tokens to, let's say, Gemini or Sonnet 4 or 5. There's actually a steep drop off in how often these models hallucinate. So one is, when you're scoping these tasks, make sure the only thing that is going into that context window is relevant to the task.

Ricky Doar [00:11:54]: One of the most common pieces of advice we give with cursor is when you start a new task, start a new chat window. There are a lot of engineers that might think, hey, I worked on something adjacent to this problem for a while in a chat window. And a chat window is essentially just a boundary for context. I want to start a new task and maybe this context is going to be helpful. And you, you end up staying in the same chat. You have this bloated context window, and it's really just a recipe for the AI. To again get confused, make an arbitrary decision based off of something you were doing before that is no longer relevant. So the more pristine you can keep your context actually the less, the better it is.

Ricky Doar [00:12:37]: As much context as needed without any superfluous context involved. And that is, that is also a skill you have to learn. But you know, just throwing the kitchen sink at a problem gets you worse and worse results.

Demetrios Brinkmann [00:12:52]: Just enough context as needed. I like that. The other thing that I like about what you're saying is let's not fool ourselves into thinking because there was a similar problem that we had, we can go down that path and continue with that context window or that chat. I wonder also, have you thought about or have you seen folks that will try to turn off pieces of the context when needed? Or is it just like that is too much time, just start a new one.

Ricky Doar [00:13:23]: So I think starting, I mean, there's also ways you can summarize context. There's also ways that you can, you know, create kind of infuse context into a new chat window by making markdown files. One really common way, which actually is now built into the flow of cursor is, is called plan mode. You're kind of building out a plan for maybe a bigger project or a bigger task and it will essentially build a markdown file of this is all the things that we need to do. And then you can use that artifact in a new chat as the starting point of these are all the tasks, all the decisions we made. Plan mode will also ask you, the engineer, hey, do you want to do X or Y? Do you want. It'll be send you these multiple choice questions of different decision trees that you could go down and then you can use that as your starting point. I think one really common, easy to conceptualize way that context can not be your friend is it's also very common.

Ricky Doar [00:14:22]: Let's say you build out. Either you're refactoring something or build a new feature, whatever it is, and you run into a bug. And AI debugging is one of the most frustrating parts of learning how to build with AI because it can just rabbit hole down the same problem. Thing that we see is if you try to solve the bug in the same context window that you created the feature, it has all this context built up that whatever it did was the right thing to do. So it can actually make it harder for it to figure out what the bug is because it is weighed down by all these other decisions that created the bug in the first place.

Demetrios Brinkmann [00:14:57]: Dude, like you're preaching to the choir right there. I feel like I have had that. Everybody in here who has played around and Vibe Coded for a minute has felt that now there is something. It's a little bit more of a nuanced piece, but I was just talking to a friend and they were like, yeah, last time I was using Cursor, there was a moment where I wanted to do something and I knew how I would implement it. And I have my experience, but what Cursor suggested was different. And so I'm at this crossroads. Do I go towards what Cursor suggested, or do I go my way of doing it and why and what is going to be better? How would you recommend that we solve that kind of thing? Because it's like, I know that my way might work, but I also know that I don't know things like the known unknowns and then the unknown unknowns. Right.

Demetrios Brinkmann [00:15:52]: And so now I'm looking at what Cursor is suggesting, and I'm thinking, is that going to cause problems in the future? Because I totally don't understand what is happening here, or is this the better way of doing it?

Ricky Doar [00:16:03]: Yeah, and I think this is kind of the biggest difference between, like, Vibe coding on the weekend and building something fun and then building sustainable software in the enterprise. I would definitely say it's not really an either or, but I would not build anything for an enterprise solution that has to go out to maybe millions of billions of users. That I don't understand. Right. A huge part of this has to be like, I need to understand the solution that I'm putting out. And even if the AI wrote it, like, the engineer is responsible for the PR that they ship to production. You know, we also see it a lot. A lot of companies, you know, a bug will surface in production and someone's like, oh, what happened here? And, you know, it's a very obvious feeling, but, oh, I don't know, the AI wrote it.

Demetrios Brinkmann [00:16:49]: That's Cloudflare today.

Ricky Doar [00:16:52]: I mean, yeah, we have half the Internet down right now.

Demetrios Brinkmann [00:16:55]: I swear, man, these AI, they just did that. But, sorry, I didn't mean to cut you off. No, no, don't worry.

Ricky Doar [00:17:02]: You know, the kind of best culture I've seen built around AI is that you can't blame the AI if a bug comes out. You have to be responsible for understanding what the code was and what was written. But that doesn't mean that you always have to choose your solution. It just means if there's a solution path that looks promising but you don't fully understand why it chose that. I mean, one of the beauties of AI is you can say, hey, I would have done it this way. What are the pros and cons of my way versus your way? Right? You use AI to make yourself more informed about the choices that are happening. You know, it is really enticing to, you know, get, get into that flow of moving so fast and just building constantly and shipping code and writing lines of code. But you kind of, you have to, especially in the enterprise world, slow yourself down at key decision points, inform yourself, learn, dive in, ask questions, understand, and then make the best decision path forward.

Ricky Doar [00:18:00]: Because especially if you branch off into completely different areas, if you've chose the one that you understand less, it's just going to make the next 20 steps harder.

Demetrios Brinkmann [00:18:10]: Totally. That's so true. So maybe you have a special way of dealing with this next problem that I've encountered where I have my rules, but some rules, you know, it's like playing the guitar and you have your scales, but scales are like a recommendation sometimes or scales can really make the sound not sound good. So I have like hard rules that I want the agent to follow and I have like recommendations and how do I distinguish between those and make it so that this rule like if for example, it's don't output a function longer than 21 lines of code and that's like a recommendation. If it really needs to be, it can be 23, but like keep it at 21ish. I can't say that in the rules like 21ish.

Ricky Doar [00:19:04]: Yeah, it's a great question. I mean, I think this is one of the probably biggest learning curves of working with AI is just fundamentally you're working with a non deterministic system and even if you write a rule, I mean this is, you know, a huge frustration for a lot of engineers working across any AI tool. You could write a rule that is like, this is the most important rule. Never, you know, start a new server, a new dev server, right? I think that's the most common one I see for front end developers is like never NPM run dev because I already have the host running.

Demetrios Brinkmann [00:19:35]: I know where this is going.

Ricky Doar [00:19:36]: Do it, you know, one out of ten times. I mean this is actually a thing that a lot of AI researchers are currently working on is like, how do you build a model that is thoughtful and creative, but also closely follows instructions and is easily steerable and guidable? The honest answer is it's not a solved problem yet. There's no way to know deterministically a Lot of tools. Cursor has built this. There's this idea of hooks in Cursor where you can actually put deterministic hooks into the agent flow so that at given moments, either right before your prompt sends, right before, right after your prompt gets back, before the code's generated, after the code's generated, you can actually do deterministic things. This is not as creative as AI, but if you have to, let's say always check after code is written for certain things. Some companies, they'll check for copy left data in the code that is outputted. That is something you want to do in a deterministic hook rather than a rule.

Ricky Doar [00:20:38]: But if you have just a strong rule versus a soft rule, really the best way to do it today is it's like you're dealing with like a junior engineer, right? You can say in plain English like, this is a rule to always follow, like most highest priority. And it will follow it generally more than say, like, hey, I want it to stay generally under 21 lines of code. If it goes over, it's not a big deal. But like, please, whenever you can try to prioritize under 21 lines of code outputted that actually will work. It will, it will like loosely follow one and try to strongly follow the other. But again, models have different personalities. Some are hard to steer, some are easier to steer. Your mileage may vary.

Demetrios Brinkmann [00:21:25]: I often think about it as like, wow, wouldn't it be nice if we just had, you know, a volume knob that we could crank up or crank down? Because exactly what you're saying is so fuzzy in the language piece where it's like, yeah, this one hard rule. This, never break this rule. And then on the other side, this is kind of a rule and you have to put that in your language and it can be interpreted in different ways every time at like every single turn, right?

Ricky Doar [00:21:52]: So 100%.

Demetrios Brinkmann [00:21:54]: It's like, wow, sometimes I ponder in the shower, couldn't we have just some knobs that will give me more steerability or more control in that regard? But also I understand that that kind of like defeats the purpose of. This is so cool. We get to just talk to it and then it does it. And if you now are breaking out knobs for this, where does it end? So, yeah, I don't.

Ricky Doar [00:22:16]: You know, this is like the original idea of like temperature when you're, you're, you're like talking to an API is like, you can set that really high temperature and it's going to come up with novel and crazy ideas. It's going to be like this really creative partner to work with or you can set a really, really low temperature and it's like fairly deterministic to the point answers. But there is that Goldilocks zone of like what's the point of working with an AI if it's like very, it's. It's only going to tell me one solution every single time, even if it's a bad solution, versus try to be creative, try to think of new things.

Demetrios Brinkmann [00:22:49]: Yeah. So I think this might be the last question for you and it's one that I've been grappling with for a while. How much harness is too much harness and how do you think about that when you're letting the agents do what they want?

Ricky Doar [00:23:06]: Yeah, when you say harness because like when we say harness at cursor, we talk about our agent harness and like what we do that you don't have to do in your prompt. That's how we think of harness at cursor. But I just want to make sure we're on the same page.

Demetrios Brinkmann [00:23:19]: We can go down that rope. I was also thinking about as I'm building my agent, how do I make sure that I am giving it enough freedom on that temperature gauge, but also not saying this is where you go, this is how you do it. And the opposite side of that, making sure that if something is very well known, it does it every time.

Ricky Doar [00:23:45]: Yeah, no, it's a great question. So I mean, I think we have a lot of experience building our own harness, which can be very helpful for customers building their own agents. You know, in the enterprise space there is, you know, kind of as you're working, it's always been true that like data is very important. You should measure the outcome of these things in production. You know, what, what leads to better outcomes versus worse. It's almost more true. In the AI space, working with these non deterministic elements is when we build our own harness, right? Like, you know, you hear these like bench scores with, with alarms of how good are they at solving certain problems. Bench scores inherently are imperfect because you can game bench scores, you can, you know, build things specifically for those things.

Ricky Doar [00:24:31]: But one thing that we noticed is like, you know, depending on what that agent is supposed to do, is it just supposed to output, you know, is it a chatbot is just supposed to like talk with you, in which case you can be a little bit loose with the harness. You can like give it some, some guidelines. Obviously, you know, most of the elements you're going to be using under the Hood have a lot of the safety guidelines already built in, so you don't have to give it too much direction in the harness. But, like, for something like cursor, where it can do almost anything within a code base, we have to build a very extensive harness of, like, how does it work with tools? You know, there's an edit tool, there's a search tool, there's a web tool, there's a, like, planning tool. And there you need, like, a very prescriptive harness of how do you work with these things? Especially, like, if your agent is interacting with a lot of MCPs, right. Those become MCP tools that you have to work with. And in that case, you do really want to kind of fiddle with that harness and test and see what gives you the best outcomes. And, you know, like, for us, our GPT5 harness, like, two months ago, we actually figured out we had a bug in it.

Ricky Doar [00:25:35]: It wasn't actually the best possible harness for GPT5. And when we fixed it, the bench score went from like, 45% to 65%. So it can make a huge difference to kind of optimize this harness, especially in this world where I can output, you know, it can hallucinate and it can give you great solutions.

Demetrios Brinkmann [00:25:57]: Yeah. Ab test that harness. I like it, dude. Randy, thank you so much for coming on here. I know that this was something that you probably did not realize you were getting yourself into when you signed up for it. You've been really a great sport, and I want to just, like, thank you from the bottom of my heart for jumping on here and sharing this with everybody on the live stream.

Ricky Doar [00:26:22]: Yeah, this was great. I, I've been on a lot of Fireside chats. I've never seen someone dress this well for a Fireside chat. This was awesome. Thank you for having me.

Demetrios Brinkmann [00:26:30]: Next time, feel free to come in your best Halloween costume.

Ricky Doar [00:26:34]: I, I, I, I didn't realize I should have dressed up.

Demetrios Brinkmann [00:26:37]: Yeah, you.