Founder & CPO Ty Dunn on AI Coding Agents

So Ty, I was recently reading the Q2 State of AI report by Artificial Analysis and there is a section for demand for AI coding tools. And at the top you had GitHub, Copilot, Cursor, Claude code, a few others, but then your company was there. Continue. So you are at the forefront of dev copilots. What do you think is still missing in today's AI coding tools?

Yeah, definitely the kind of, I think first thing and is like we have to do more to help people kind of build trust and actually gain experiences. And so it's actually not the most obvious when it comes to like using this technology to build software. And so you need people that can play, right? And so there just has to be many more examples. Has to be much easier to kind of get the encouragement, the clarity, kind of the inspiration you need to build trust in kind of what is AI capable of doing? Where can it be reliable and how can you apply it? Right? And so that then leads to kind of the ability to integrate these tools into your workflows. Like how does it meet you where you're at, how do you end up in a situation where it not only can help you in a generic sense, but specific to your situation, how can you customize it to, to better fit where, where things are going? And so once that kind of foundation is set up, I think what, what then comes is kind of the ability to add as you're using these tools, you realize, wow, I don't want to just be using, say one agent at a time, I want to be using many. But in order for that to happen, right, if you close your laptop, you need them to be able to continue. If you're working on five at a time, why not just pool all those with your team and have everybody work together on them? And so I think where the frontier is moving towards asynchronous code agents and in particular kind of this idea of continuous AI. And so for that to happen, there's a lot of kind of sandbox environments to make sure that only the real world changes that should be made are made and that, you know, I mean, no security and privacy and other things kind of get disrupted. And that's a huge kind of infrastructure build out in order to make that happen. And so you kind of then need the ability to go from kind of these asynchronous workflows that are running in the background that are remote agents and bring those back into the loop, right? Because this technology in some cases really needs the human to be able to pause, take over and hand back control to them and then in some ways go back and forth between that and once all of that, that's kind of going. I think kind of the last missing piece that I can see at this point is minimizing kind of developer intervention and setting people up with the tools to do that. And I think that is the frontier of what it means to build software in the future is similar to build time and continuous AI in the idea or in continuous integration and continuous AI. It's about kind of making sure that, okay, where am I intervening? How do I make this like a shorter intervention? How can I make the whole task go shorter? And that's kind of the future of the engineering. You're taking a step back. Instead of building the API, you're now building the agent that builds the API. In order to do that, there's quite a bit of engineering work that needs to be done.

Okay, so you are a founder, you went through Y Combinator, you raised seed funding from Heavybit, you're one of maybe 10 AI coding tools that's really gaining traction in the market. As a founder building with AI, how do you evaluate foundation models or inference providers?

That's a great question. Um, so when you think about it, right, like the best benchmark, right, there's all these benchmarks where it's like put it through a series of tasks. And often kind of the way that models get better is by having benchmarks. But I always like to say that the best benchmark is are developers using it on a day to day basis, are they getting value from it? Right? And so with kind of continue being at the forefront and because we allow people to have maximum flexibility of where they run their models, how they run them, so that you can use it say locally with Olama or Lemp, LLM Studio or Llama, CPP or do cloud deployments like together replicate Groq or put it, put a model that you can find in AWS Bedrock or Vertex or, or even use it directly from the labs like OpenAI and Anthropic and Mistral. You have access to run all of that. We kind of get to see ahead to head in a way that very few others do by actually kind of with our anonymous telemetry and our open source see like what people are using and that allows us to then say, okay, let's prioritize more time and on these models because these seem to be the best ones, right? And so that's at a kind of high level, at the kind of widest range in terms of continue. But then also there's kind of the zooming in for every individual. It's about playing with it, right? Seeing what works for you, trying it on different tasks. And for certain people in different situations, one model might be better, another one might, might be better. And for many people, right, it's not always about what is the best, but what's the best for them, right? And so as costs grow, as you need certain accuracy on a particular task, as you kind of have certain compute resources, whether those are GPUs or a partnership with someone like Groq, right, you end up in a situation where kind of the best might not just be like purely which one gives you the greatest code, right? In some cases, like some of the new open weights models, for example, are in many cases about 90% as good as say, the frontier proprietary models. But the nice thing is they, they have about 90% less cost in many situations. And so in that case, right, if your task can handle it, why wouldn't you go with the one that's much more, much cheaper and more performant for that situation? And so in many ways, I think this is ends up in a situation, right, where you're just kind of constantly evaluating models because there's so many new ones coming out, constantly evaluating infant providers and figuring out which one works for your situation. I love it.

I love that. I love the metric you said in the beginning about just what are the developers think and how are they getting there. You were an engineer, then a product manager, and now you're a founder building one of the fastest growing AI coding tools in the market. How do you hire for a team that is building on the edge of what's possible?

Yeah, it's a great fit. I think the thing that you do, no matter what team you're building, at least in my kind of view, is you first evaluate culture, fit, right? And values. You got to be able to build trust. That has to be the foundation of what you're doing in order to do anything with the team, right? To kind of center around yourselves around a shared idea, which I think is what a startup is. It's a group of people focused on a shared idea. And so that's the foundation. If you can kind of get that, that's the first thing, right? And then the next thing for kind of our space, right, where we're building tools for software engineers that we ourselves use, right, we're software engineers ourselves. And it's then about actually finding people who are super excited and enthusiastic to actually take our tool Continue and apply it in their day to day workflows to go and set up continuous AI workflows using Continue's new cli. Right. And so it's all about people who are super excited to do that, who will dog food, or at our company, we call it eat our own pizza because generally we don't want to eat dog food as humans. And so we end up in a, in a, in a place that we want people who really are using it. And that's kind of the basis for building an amazing developer experience is like first for yourself, making sure that it's great. And then many of our engineers also interact with our community and so making sure that they're kind of building that empathy and having that relationship. And so it goes beyond kind of the hard skills of how good of a technical engineer they are, but also like the soft skills of how do they communicate, how do they work with the community, how do they work with the rest of the team. And so I think those are the two main pieces that I would say are most important when we think about team building and in this situation.

I was reading the Q2 State of AI report by Artificial Analysis and there's a section about demand for AI coding tools. You had GitHub, Copilot, Cursor, Cloud code, and then a few others, and then your company Continue. So you're building one of the fastest growing AI coding tools in the market. There's a growing debate about open source versus proprietary models. Where do you stand?

Yeah, I think both of them have different value, right. Depending on the use case. Right. The nice thing about Continue is you can use open models, you can use proprietary, you can use both of them at the same time. Something often people don't know is AI code assistants are generally actually multiple models depending on kind of the part of the AI code assistant. And so you can kind of mix and match. Right. And so for us, we're also open source and so we love kind of open models, open weights, open source models, but we also love the proprietary ones because it's like three clicks often and you can just get set up and get going and have the best open weights. That said, have an advantage in many ways that the other models don't have. Right. Where maybe in some cases it's harder to actually go about setting them up. In other cases it's not because there's awesome inference providers who make it as easy as the frontier. But the nice thing about the open weights models, you have greater portability, right. You can run them anywhere, whether that's kind of renting some AWS GPUs or having your own data center or using something like together or grok. Right. You also have accountability with the open weights models where like the model won't change underneath you. Sometimes with the labs APIs, people will post on Twitter about how, how they feel like the models have been lobotomized. Right. Or something has happened that it doesn't work like it used to and they're frustrated. That can happen with the open weights models if you're kind of running themselves. And then especially on a longer time horizon, kind of the cost efficiency is I think kind of pointing towards an ecosystem with a singular model, all competing and trying to build better chips, trying to build better inference engines, trying to build better utilization of particular hardware. And so by having an ecosystem, and this is the awesome part about open openness and open source is you end up in a situation where kind of in many places you're able to make improvements over here and one company can, and the others can learn from that and also make improvements. And so you end up with some great competition for everyone optimizing together rather than a particular company optimizing. Right. Without that kind of competitive pressure. And then that also even applies to kind of the open weights models in general. Right. Where people can learn. If you look at a lot of the Chinese labs, they're learning a ton from each other and distilling each other and using kind of data generated by the other models to make theirs better. And in many ways I think that's why you're seeing the open weights open source models from China in particular. But now even the US catch up to the frontier models. And so on a longer time horizon, I think it also unlocks kind of open weights like model adapting, whether that be like fine tuning or domain adaptive pre training or at some point maybe even pre training from scratch or today it's often like RO post training. All of those things are much easier and much more powerful when you have open weights models. But at the moment the best models are the frontier models. They're often the easiest to do to get started with. And so I think the future is a mix, right? I don't believe in a single model to the rule of them all. I think it's definitely a multi model future. Many models that you will use in different contexts.

How do you see the role of AI evolving in the software development lifecycle over the next three years?

Yeah, I think in many ways it's hard to tell, right? This space is moving. I Don't know if I can predict the next six months, but if you're pressing me, then the thing I would say is I think we're going to move from kind of human in the loop, direct monitoring, kind of watching over everything that's happening step by step in real time, to actually multi threaded workflows where you have multiple agents going on where events happen. So either like on a daily, weekly, monthly cadence, you often have tasks that need to be done, or there's event driven tasks where maybe a pull request opens or a JIRA tickets created that kicks off workflows. And so I think we're moving kind of from directly monitoring all day, every day at one agent to kind of be able to have to directly monitor, indirectly monitor and manage many AI code assistants at once, code agents at once. And so I think this requires a shift in your thinking as a developer when instead of having your approach be how do I do this task? You have to think about how can you change it to how can I structure this workflow I'm doing? Or how does my workflow work so that continuous AI can take over? How can you end up in a situation where it's okay, this part can be done by the AI coding agent, this part can be done by human, this part can be done by AI code agent. And how do you set those up so you and the agents can kind of work together? And there's the places where the human touch and the human feedback and the human permissions gathering are set up in a way that works for you. And so kind of in the long run I think that ends up increasingly causing things to look asynchronous, to look multiplayer. And kind of the term we like to use is continuous AI where you're just constantly having events happen, the time of the week or the day. Daily task that you do is just kicked off in the morning, right, and runs. And then you come in and you're drinking coffee and you review the thing that's going on. And, and by lunchtime, right, you've, you've kicked it off again. By lunchtime it finishes, right? Or in other scenarios, maybe it's a 15 step task and you end up getting, or the agent ends up getting to step seven and kind of goes wrong. And so you're reviewing and you're like, you give feedback on step seven and then have it continue and maybe it gets to step 11 and that's a step where it needs to get your approval before moving forward. You give it the approval and then it can then move forward. And so in summary, I think that the next three years are definitely about kind of increasingly moving towards a lot more inference, powering many more kind of AI coding agents that are running kind of, of course in, in the loop with the human, but also increasingly outside the loop of. Of the human and the outer loop.

I love that it. I was at. I don't know if you may have remembered, I was at Kubia for this by Heavybit as well. And it reminds me that was. That's kind of DevOps for, you know, agent, but a lot of, you know, Jira ticket kicking it off or something, event.

So anyway, yeah, we're finally getting there. QBA was at the forefront of it where we were actually chatting with Jesse, the investor in both us and Cubia, and he's like. I was like, yeah, I think we're heading in QB's direction. He's like, no, y' all have slammed into each other. Right? But we start from like a basic building blocks, right? How can we give you GROK plus, like an open model on GROK plus, some rules and some prompts and kind of enable you to build it yourself rather than kind of a SaaS platform that does it for you.

What's the single biggest mindset shift that helped you go from engineer to founder?

Yeah, the biggest mindset shift is you have to like realize that often as an engineer, in most situations you kind of are in a situation where things are pretty well defined, where there isn't that much complexity and ambiguity that you need to factor in, where there's a lot of clarity to a situation where the problems are undefined. There is a lot of ambiguity, there's often a lot of confusion. It's not clear what to prioritize, where to start, what is success. And so often that is something that you collaborate with and you have really smart people around you. And some of those things are even figured out for you as an engineer to being a founder is you have to take ownership of all of that. Right? And you have to be the person that, that ultimately figures out what bets to make and how to go about testing those hypotheses you have and running the experiments that matter and letting the things go that don't. Right. I always like to say anything that's important in an early stage startup will come up again. So don't worry about creating a giant task list of all the things you want to do. If it comes up again, it will be important. If it doesn't, it probably wasn't that important. And so luckily I moved from being an engineer to a product manager to a founder, which I think actually helps you. You kind of with this spectrum, because as a product manager, you have a little bit more ambiguity, a little bit less defined problems, a little bit more confusion that you don't necessarily have as an engineer.