Scott Wu

Honestly, we expect it to be a decent bit more than half by the end of the year.

Building companies well sometimes just comes down to doing those three to five things just even more than you could possibly expect. And so, with us, it's like... And everyone says we go fast, but it's like, yeah, we had a hackathon in November, we had another hackathon in December, we started the company officially in January, we got the prototypes out to initial users in February, we did a launch in March, we got our first customers in April.

Most folks on the team are definitely working with up to five Devins at once, and so Devin merges like several hundred pull requests into production in the Devin code bases every month. Our whole team is only like 15 engineers a year.

I think there's going to be way more programmers and way more engineers a few years from now. Pretty quickly. The form factor of what it means to be a programmer obviously is going to change, but at the end of the day, of course the discipline is all about just being able to tell your computer what's do. And so in that lens, I really think that programming is only going to become more and more important as AI gets more powerful.

The biggest thing I would say is it really is just treat Devin like your new junior engineer. I think folks come in and they see the blank page and they think of all sorts of various things that they want to try out. But a lot of it is just like, 'Yeah, let's figure out what tickets we want to get done today or this week and let's have Devin get started on those and let's start with the easier ones and then work with Devin and understand what things Devin needs to get set up to be able to test its own code and do this well. And then let's scale up over time.'

You want to be giving Devin tasks, not problems. And a lot of these things like what you just saw, which was kind of like a quick front-end feature request or a bug fix or adding testing and documentation or things like that. One of the things that makes a loop really nice obviously is a quick way to iterate and test.

I think it's often less about moats and more about stickiness. And what I mean by that is moats are in some sense, typically what folks mean by moats is something that means that a competitor couldn't even enter the market. I think what does exist is stickiness, which I would kind of define as once you have a product experience that you really like, are you excited to keep using that experience.

You really want to do your best, and put everything you can into it, and do everything you can to... Basically, you want to put it all out on the field. But at the same time, you want to be okay with both wins and losses, and you want to be able to move on, and go into the next one each time. And somehow it also actually makes you more successful, I think, too. It's like, you are just more able to give it your best, and to do the things that will lead to success if you're not tying it up in your own personal worth.

One of the ways that we've kind of thought about Devin in building Devin is really allowing engineers to go from bricklayer to architect, so to speak. A lot of it is just getting to the point where you can do the high-level directing and you can basically specify things exactly how you want. I think it's very much about still having the human in control and having the human able to do the full specification, but just multiplying the magnitude of what you can do and what you can build in one day or one hour or however long.

As you use Devin and as your whole team uses Devin, it's the same thing with an engineer. If you're joining on day one versus you've been at the company for five years, you wrote half the code yourself, you've touched every file you've built every single piece, you know all the engineers. And so similarly, it's like Devin will really learn and build its representation of your code base and of your stack and of your process over time and will be able to do a lot more with that.