Transcription
What does 5 years from now look like? I think you'll actually be able to be much more efficient in this journey from like idea to solution to a problem where maybe instead of a thousand people, you only need 10 people.
There are going to be software problems that need to get solved that are just so massive, all of the engineers on earth wouldn't be able to do it. These individuals have these problems, and then they can use this army of virtual engineers to solve the problems. We are used to thinking on linear scales. A lot of technology works on exponential scales.
What are some of the techniques used behind the scenes? Three of the most important things: First is…
All right, Matan, thank you so much for joining me today. I'm excited to talk to you about Factory. I'm excited to talk to you about the future of uh software engineering, where you see it going. Um, so let's let's get right into it. Uh, Factory is built very different uh from from a traditional IDE. It's really not a traditional IDE, and that's probably a reflection of your belief of not only where software engineering is today with AI but where it's going to go in the future. So let's start with why you built Factory. Give us that that background story.
Yeah. So um maybe to start uh why I why I started, you know, building Factory, working on Factory. So prior to Factory, I was a theoretical physicist for 10 years, um working on string theory. Um, for a number of reasons, I was kind of uh just stubbornly pursuing that not out of a place of uh, you know, thinking that it's exactly the right thing for me, but instead because I thought it was very difficult. Um, ended up coming to Berkeley to do a PhD, and while at Berkeley, I ended up exploring some AI grad courses and really fell in love with what was then called program synthesis; now we just call it code generation. Um, kind of got got nerd sniped by that and ended up, you know, switching over completely into into AI research.
What year was that Matan?
So this was uh in 2022, uh the very beginning 2022. Yeah. Um, I think the reason why code generation was really interesting is after 10 years of theoretical physics and like string theory in particular, you really get trained to appreciate things that are very fundamental um and kind of general, and there's a very general role that coding or software development plays uh within artificial intelligence broadly, um because of the intimate relationship that ability that models have in terms of coding correlates to ability on any other downstream task. Whether it's um, you know, writing poetry or creating thoughtful uh uh responses to to like research questions, generally the better the better models are at software engineering, the better they are at almost every other task, which, you know, means it's kind of a very core functionality, and that's the type of thing that attracts mathematicians and physicists, which is why there are so many um in the field. Um, so that was kind of the initial thing that got me interested in it.
And I think maybe to to the first half of your question, what got me interested in particular in this new interaction pattern that's outside of the IDE? Um, I think to answer that, maybe first I'll step back and share this uh the Henry Ford quote that I think a lot of people are familiar with that we really take to heart at Factory, which is Henry Ford was like, you know, if I asked people what they want, they would say faster horses. Um, and the way we see the future of software engineering is, you know, we have these existing paradigms that's basically, you know, the IDE has been around for like 20 years; developers are very familiar, have very ingrained patterns uh in terms of how they use the IDE uh to build, um, and everyone also, you know, has this general consensus view that software development is going to look very different in the next 5 years, um, and there's a little bit of incongruence where, you know, we had this world where uh, you know, developers are using the IDE and writing every line of code and this world that we're going to where developers are essentially going to write 0% of their code. Um, and there's one approach which is let's iterate from this world where developers write every line of code to uh the the optimal platform for when they write 0% of their code. Um, our take is that that approach is kind of like trying to iterate from a horse to a car. Um, and you know, you don't really need to be a historian to know we did not iterate from a horse to a car. Uh, you know, we built the car from scratch. Uh, from first principles, understanding the kind of uh the differences in these these approaches to to the problem of transportation here. I think it's somewhat analogous to the different approaches towards agentic software development or what we like to call like agent-native software development, and how do these approaches differ? Well, well in the the kind of ideality of the developer is always how can I, you know, figure out what this task is and then go about it, implement it as fast as possible, um and obviously as reliable as possible, so you'll do things like testing, you'll write your code faster with things like autocomplete. Um, and that's kind of the paradigm that gets pushed forward there. Whereas the approach that we're taking with this agent-native approach is the mentality will shift in the mind of the software developer from how can I get this done faster to if I have this large task, how can I separate it out into discrete separable verifiable steps that I can then delegate to agents, and then they can go and work on them in parallel um to get things done faster. And uh, you know, the difference here is like working on something in series faster versus parallelizing something. Um, obviously this the the speed ups are going to be much more dramatic when you can parallelize the same problem into four steps versus work on it in series, you know, slightly faster.
Yeah. Um, so a couple things. The wow moment, like the biggest wow moment that I usually get while using any AI product is when I can parallelize it. I think the first time it really hit me was when I saw U chat GBT operator or OpenAI operator. Uh, I would kick off a task, and this would be a long horizon task over minutes, tens of minutes potentially. Uh, and then I would kick off a second task and just knowing I had multiple agents doing this thing that I would have had to done serially. Um, it it was just like so impressive to me. And so I I do believe in that vision of multiple agents running in parallel accomplishing tasks.
I want to I want to actually take a second. You said something really interesting, um uh like co-generation ability is um upstream of other strong abilities for from these models. Um, did you happen to see the Apple paper that came out over the weekend? It made its rounds. I I assume you you did cuz you're laughing, but it's essentially it's like the illusion of reasoning. And they put out this paper which showed maybe the models aren't necessarily reasoning in natural language. And to do that, they set up these puzzles, and the the um the the models weren't really able to after a certain complexity solve the puzzles. But one thing that was missing from the paper was the um agents or the the LLM's ability to write code to solve the puzzles, which they can do flawlessly at any complexity. So I wanted to I want to ask you first of all is an uh LLM's ability to write code to do logic to do reasoning to solve puzzles is that intelligence? Like what what is your take on that paper? Because you said that, and I I'm just so curious.
Yeah. So uh full disclosure, I didn't read the paper. Uh, I classic read the abstract and then uh, you know, didn't have time to read the whole thing, but um, yeah, I think uh it was uh the the timing of that was pretty interesting with uh with Apple's current place in the uh in the AI market. But yeah, I mean, is coding intelligence? I think I think one thing that's really fun about the time that we're in now is the idea of intelligence itself is being really questioned because anytime an LLM does something, we kind of like we as humans try to say, "Oh, but that's not intelligence. That's just like memorization." Or like, "Oh, it's just like it's training data, right? Like it's just regurgitate. It's interpolating between its training data." Um, I think it's hard to say. Um, I I don't know if I have a I've I don't know if I've seen a really good concise and consistent definition of intelligence that will kind of qualify it in or out. Um, I mean, I think one thing that I find compelling is like the ARC prize; I think has done some pretty interesting stuff about like generalization of of intelligence and like pattern matching and things like that. I think one thing is abundantly clear is the more present things are in its the more present certain types of problems are in a model's training data or in its like post-training like RL, the better it'll be at those tasks. Um, and so that kind of makes us naturally want to say, oh well, it's not actually learning because it's only you know only if it's studied will it actually be good at this, but that's the same with humans. Yeah. Right. Like the we maybe we have a better ability to generalize like from this type of problem to that type of problem. Um, and uh, I think Sarah Guo said this the other day, which was when people talk about AGI or intelligence, what they really are alluding to is consciousness, like by accident. Um, and I think these things kind of get subconsciously conflated quite a bit uh, when when we talk about it. But um, to more directly answer your question, I think it does require intelligence to solve a certain coding problem. Um, and so by that metric, these models certainly have intelligence. Um, now, do they have the most generalizable intelligence outside of their training data? No. But that's what the labs are working on.
Yeah, absolutely. I do think that the model's ability to write code gives it more generalization than just solving things in natural language. It's interesting, but okay, I want to I want to go back to parallelization. That's really interesting. um for, you know, the last few decades, human teams of engineers work together; they're not typically working on like the same part piece of code, right? There's going to be a lot of conflicts there; we had git for solving some of those conflicts; how do agents work together in parallel that might be different from the way human teams did?
Yeah, great question, and I think this also gets to the answer of like the role of the human as we have more and more capable software development agents; where does the human fit in? I think one of the biggest things is like, okay, if they're two completely different tasks like implement feature one and feature two, obviously you can parallelize those, um, and but then, you know, like you mentioned, you have to deal with any merge conflicts if they uh are making changes on like some uh similar like kind of core functionality. Um, I think the thing that humans will end up being really important for is within like, let's say feature one, figuring out what is the optimal way to separate it uh into subproblems. And importantly, you know, you want these subproblems to be separable in that you can work on them in parallel. And what is a skill that would allow a human engineer to understand how to do that in the optimal way? Well, that's systems thinking. And systems thinking is what has made the best engineers anyway. The best engineers are not the ones who are know every little nuance detail of every programming language. The best engineers have always been the ones that are the best at systems thinking and understanding how to reason around constraints. And now we just have a new uh interaction pattern and a new approach to building software where it's not like you need to, you know, do your systems thinking thing around these constraints and then go and implement. Instead, what you need to do and kind of the thing that you want to get to as quick as possible is a nice packaged uh set of uh uh kind of steps for an agent to do as well as a set of verification or validation criteria to know that these steps were accomplished. And once you have that package, you throw it off to your agent for it to go and implement.
Yeah, I'm I'm glad you mentioned systems thinking. I get asked this a lot, and and you probably do too in in your position, which is is it still worth learning to code? I asked the GitHub CEO this. I have two young kids. The the most important skill set I ever learned was was learning to code. It allowed me to take the ideas in my head, not rely on somebody else, and go build them. Um, and and a few years ago, I would have said, "Yes, my children, this is the most important thing. Go learn to code." Um, but then I I did there was a period where I had some doubt, but let me now tie it back to systems thinking. Again, one of the most important skill sets I ever learned was not only coding but the systems thinking element of it. And so even if agents are going to write the the vast majority of our code, the systems thinking is still critically important to the workflow, and I would say in life in general. Um, that's my opinion. What what do you think?
I could not agree more. I actually I think it maybe something that's a little bit hotter of a take is I actually don't think it matters as much if it's um, you know, for for uh kids who are in like high school or college right now, I don't think it matters as much if it's computer science or mathematics or physics or biology, but being able to go into any of these disciplines that have where the problem space looks like there's a huge amount of dense information and like hundreds of years of history that realistically you don't have time to learn every single detail. Um, and so having this ability to go into this field that already there have been many geniuses who have spent their lifetimes uh, you know, pushing the field forward, going in and within a few years understanding, you know, the the mountain that you kind of stand upon, um, and then having that ability to reach out and pull in the things that are necessary and be comfortable with the some of the nuance details that you won't have time to learn and still like kind of push the horizon like a little bit further. Um, I may be biased in saying this because I spent, you know, 10 years of my life doing physics, but I think an analogy there is like, you know, every time I was uh working on a chalkboard and using an equation, you wouldn't like I wouldn't rederive every theorem that I would use because that would be so inefficient. However, I think it's really important that at some point in my life I did that derivation, and if I had to like done to my head, I could go through and rederive it. And I think it's somewhat similar with uh software development like, you know, in most standard uh curricula at universities, you'll go through kind of the like from the bare metal all the way up uh into the like higher-level programming languages, and any like as a software engineer, are you ever going to actually use like machine code? Probably not. But it's really helpful to have that understanding, and like again, it kind of comes back to this systems thinking, understanding like the full stack of what it is that you're working on in a similar sense that as a, you know, professional physicist or mathematician, you'll probably use a calculator. You'll probably use theorems that you're not going to reprove on the spot every time. Um, but it's still important to at some point have learned that process and understand how to do it because even though you could just take all these theorems for granted, let's let's say, or you could you know in computer science kind of ignore uh a lot of the fundamentals, it will uh come back to bite you because you won't have that experience um kind of waiting through all of this this mountain of information in these fields, um, and that that skill set that like exactly like you mentioned, there's that skill set of being able to go into a very uh rich field and kind of get your bearings and understand like what is important to know the nuance details of and what it's okay to have like a fuzzy understanding of in the moment um to to keep moving forward.
Yeah. I mean, what I what I hear you describing is abstraction layers and and kind of going back to software engineering and engineering agents. Um, like a lot a lot of people are wondering, okay, am I going to be orchestrating agents? Am I going to be checking the work of the agents? Either way, knowing the fundamentals is going to be important. Even again, if you're not necessarily using or rederiving every single algorithm that that you're implementing, you still like knowing knowing the fundamentals to be able to check the work to be able to orchestrate agents that are actually doing that work is is important. So, I want to I want to continue on on the agents. I mean, just in the last two years, it has been absolutely shocking to see how much software engineering has changed. Um, first of all, surprising that it was software engineering that changed the most with AI. Uh, and then maybe not surprising but to me at least, and then now just the rate of change. So we des you you described your vision of kind of the coming years of orchestrating agents kind of uh an abstraction away from the IDE. What is what is five years from now look like? What does 10 years from now look like? Obviously with the caveat that it is impossible or very difficult to predict so far out, but I just want to hear your vision.
Yeah, I mean, uh, I definitely agree with the caveat that it is very high variance um in predicting out 5 years. I mean, I think there were probably a few people in 2020 who were could have predicted where we are now, but I think very few um just because there are uh there there a lot of compounding effects of each like model generation and like the degree to which it gets better, um, and then that kind of affects, you know, each subsequent year. Uh, when it comes to these forecasts, I think what's really important is uh one to be aware that humans are really bad at thinking about compounding. Um, this is something I'm certainly not the first, I won't be the last person to mention this, but we are used to thinking on linear scales, and the reality is a lot of technology works on exponential scales. Um, there's a meme about this. Wait, I want to I want to share it with you cuz it's it's one of my favorites. Um, this is from Daniel uh I'm probably going to butcher his last name, Coco Tylo's blog.
Yeah.
Yeah. So this this really kind of emphasizes how we're we're really not good at reasoning around exponentials and understanding nonlinearities. Like in this example, you know, world GDP is on one of the most ridiculous exponentials. Yet, you know, like from the years 2010 to 2020, I don't think people felt like there was that much like crazy progress or things were like getting that much better. Meanwhile, it's like almost vertical, right? Um, and so I think to a to a similar extent, thinking about the next you know 5 to 10 years, I think it's pretty hard for us to have high confidence prediction about what things will look like. I think what I can say as a guiding principle at least when I try to think about these things is what were what was our initial goal? Like software engineering wasn't just developed for the sake of like software; like it wasn't we didn't start coding just to write code; the point was we wanted to build certain things and use these computers that can do calculations way p way faster than anything that we as humans could do. But that is like a means to an end. It wasn't just for the sake of computation, right? Like there were things we wanted to be able to communicate across the world extremely quickly. um the like that is kind of like an end that matters. Or um, you know, we want to be able to like simulate certain scientific phenomena in order to discover new drugs or something as simple as like, you know, you want to be able to coordinate such that like drivers can come and pick you up and take you places and you don't need to uh, you know, wait 30 minutes to call a taxi and you know you have these…
Things more efficiently. Those are the ends and the means. Has been software because we want to use machines to do this more efficiently than just some system of humans could. And in order to communicate with machines, we need to learn this very precise language. Um, and then we slowly made that language more and more abstract. Uh, because you know it's pretty inefficient to speak to the machines in bytes. Um, and so it's actually more, you know, efficient to have these higher levels of abstraction with these languages.
And so I think that trend will continue where, you know, for a while we had uh—and even there's so many good essays from like, I mean there's one uh that comes to mind—uh, I think it was from Steve Jobs maybe in the late '70s or early '80s, um, about like the the dream of thinking machines and where where we're going with these. And I think this trend of like, okay, we had to, you know, go deep into coding just to figure out how we can work with these machines, and I now we're kind of coming back out where we can focus again on the ends of what it is that we actually want to get done.
And so, long-winded way coming around to answer your question, I think in the next 5 to 10 years, we will be able to solve a lot more problems a lot faster. So before a problem that might have taken a thousand engineers and 10 years to build a company around, I think you'll actually be able to be much more efficient in this journey from like idea to solution to a problem where maybe instead of a thousand people you only need 10 people. But at the same time, so that if you take that alone, that's that would say, okay, the number of people in companies is going to go down; there's never going to be any more like 10,000-person companies, you know, that kind of trajectory. But I think there's actually a competing force, which is if you have 10,000 engineers that all can delegate task to h tasks to hundreds of agents, what becomes possible in terms of the scale and scope of software also dramatically increases. Um, things that we can't even conceive of—like even now it's hard to think about how to coordinate an organization of 100,000 software engineers—but there are organizations like Microsoft that do this, and the question is how efficiently—um, you know, certainly there is an inefficiency there—but this world 5 to 10 years from now, you can have complexity of software that we truly cannot even like comprehend right now because the idea that you have the output of a million software engineers like doesn't even makes sense. It's hard to even imagine what that entails.
So, you, if I'm hearing you correctly, you seem to actually have a very aligned view, a very optimistic view of the future, which I—I put out a video a few days ago, and it was all about the future job market, the economics, what does the future look like? And a lot of people think if—as you said—there were a thousand engineers to build a product and now you only need 10, they're going to lay off—they being the company—990 of them. But I—I had the counter example, and I have a much more optimistic view, which is no, the total universe of addressable problems increases dramatically because now it only takes 10 to solve problem X, but now we have problem Y, Z, and alpha whatever after that, and all of those engineers can be put towards that; they're just going to be superpowered. And so I don't think in the long run, we're just going to have like one-person companies that are, you know, there's—there's like 10 companies, each of them have one person at the top, and they're just full of armies of agents. I just don't think that's going to be the case. I think the the economics of longtail problems—not less valuable problems—just the the math of the um intelligence investment to solve that problem didn't make sense and may make sense very soon. 100%. Like generally the—the—the um like total addressable market of a certain problem loosely determines how many engineers or how much money will go behind solving it. Um, and so if you—if there's some problem that only is applicable to let's say 200,000 people in the world—um, obviously like the spending power of those 200,000 people determines like the TAM of that particular problem. In the previous world, that might entail, you know, only a couple hundred engineers worth of work to solve that problem. But now you could have 200,000 engine—you could have a problem that's only applicable to a couple thousand people and have the equivalent of 100,000 engineers working to solve that. And I think that's really cool. That means that we're going to have—I mean, still if there's a problem for 2,000 people, I think it's worth solving because I think 2,000 people having some issue—like in an ideal world they don't—uh, and now you can go and like direct this firepower to solve that problem and—and—and maybe it even gets scoped down to a problem of one, right? And—and at that point the software becomes so inexpensive to create that the ROI on a solution for a problem of a set of one person becomes profitable. Um, and that's really interesting. But that's like, you know, we're talking about the very long tail. We're talking about very, very small addressable problems. But then I think there's also going to be—as we're accelerating towards this future—massive problems as you said, we can't even think of, we don't even know. Um, as we, you know, maybe this is many years in the future, but as we expand into the stars, there are going to be software problems that need to get solved that are just so massive, all of—all of the engineers on Earth, the human engineers wouldn't be able to do it. And so now we have this future in which each of the human engineers are supercharged with their own army of engineers, and maybe those problems become tractable after all.
Totally. And again, even in the way you describe it, what I love about that is it's not about software engineering as an end in itself, but rather these individuals have these problems, and then they can use this army of virtual engineers to solve the problems—um—to do whatever, you know, exploring the universe, whatever it is—like they have problems along the way, and they get it solved more efficiently. Um, and I think that that increase in efficiency is—is clearly a net good.
Yeah. And so okay, let's—let's bring it back to Factory for a moment. I think one of the most impressive things—uh, at least when I—when I started using it, when I continue to use it—is the design and—and it's not just the actual UI, but it's the UX as well. It's the experience of using it. It clearly isn't an IDE. Um, like talk to me about the design. Talk to me about where the UX/UI is headed within Factory and—and what that means for the human and how they interact with the product.
Yeah, so—um, for one—a huge shout out to our designer Cal, who actually happens to be my older brother. Um, it's—it's a blast being able to work with him. Um, and I think so a couple things about our design. I think one thing that's really great is—Kyle's background is actually, you know, in industrial design. Like he went to RISD, the best art school in America, and—you know, at Factory we have 22 of the best engineers in the world, and I think something that's really important for us is embracing the different perspectives when it comes to even designing something that is built for software developers because, you know, naively you might think, oh, you know, it's a product built by developers for developers that—like let's just talk to developers, and that's like how we decide like if this thing is going to be here, if that thing's going to be there. But I think also having the—a little bit of like an outsider's perspective from, you know, his background in design and UI/UX more broadly—um, has been really valuable as we rethink this because part of the name of the game that we're doing is moving away from the IDE, and you know the best developers in the world have been using the IDE for the last however many years that they've been building, and so it actually is helpful to have someone who's never worked in the IDE because you don't even have the—the habits like ingrained in you, so you have this like fresh perspective, which—it's funny—it's so similar to like physics as well where a lot of times why—like in physics—27 seems always like the best age where—like the best discoveries come—like when a physicist is 27 is typically when their best ideas come, and it's because of this balance of having context about, you know, the space, but then also not being so ingrained and so used and so like habitual about how you think about things. So, you still have that ability to like question everything. And I think that's been super helpful on the design front—um—and where things are going.
Well, as I mentioned, we're trying to build—in that analogy—the car—um—and moving away from this iterative approach of like faster horses, you know, making more AI in the IDE. And so, the dream here is getting closer and closer to this world where the human doesn't need to go in and manually edit the code—um—making it such that if the software developer provides a clear plan for what it is that they want to get done and that requires not just being like, hey, make this—hey, make me a dashboard. It's like, no, you want to elicit behavior, or you want to—you want to elicit—um—the right constraints from the software developer so that whatever it is that they're actually thinking you can be as true to it as possible when you actually go about implementing it. Um, and you also want to make sure you have some deterministic ways of verifying it. So, this is kind of a silly example, but suppose I wanted to make some blue dashboard. Or if I ask Factory, hey, make me a dashboard that—that's in line with Factory's uh theme, and it goes and, you know, creates some—something that's like pink, it's clearly like a violation of our current like design system. And what we want is for Factory—even if it were to make that mistake—and you know, make something that kind of violates whatever constraint I was thinking about—it should have a way to go and see that and then iterate on it so that it's not going to ping me and say, hey, I'm done, and I go and look, and it's pink, and I'm like, hey, by the way, we do it in, you know, our color is like dark mode typically. Um, and so molding the interaction pattern such that we get more of these constraints explicitly from the human developer or we learn it over time so that they don't need to say it every time. Um, and then also on kind of the software side of things, making sure that our retrieval—um—and our like code generation performance is cutting edge. Making sure that, you know, the droids that are going and executing this code are able to iterate based on output and based on—um, you know, objective—like, you know, we ran these tests, and we see that this thing failed; let's now iterate based on that. The more we can nail that, the less the human has to go in and manually edit the code. Uh, which is pushing us towards this agent-native future where really all the software developer has to do is have their explicit, you know, plan and scope of what it is they want done and then send it off to the agent, and it'll go and work on that.
Um, so Factory understands a company's codebase really well. What are some of the techniques used behind the scenes—whatever you're willing to share—that allow Factory's droids to actually understand and write code with similar patterns—um—not make changes that it shouldn't—what—what are some of those techniques that—that is unique to Factory?
Yeah, I think probably three of the most important things—um—and so we can go into each of them. So first is first-party integrations—um—second is memory, and then third is—um—local and remote codecs execution. So, I'll go through each of these and explain real quick. So, first-party integrations, LLM servers are great. Um, I think they are a little overhyped right now because—so first of all, it's a great way to get information into a model if you're using like an IDE. Um, the downside for like large codebases or large orgs is a lot of this is computed ad hoc, and that's very dissimilar from how human engineers work. Like a human engineer working in a codebase doesn't have like a blank memory, and then they're working on a problem, and then they'll go and like find anything semantically related to what they're working on, study it, and then go and work. Like they generally—they have a precomputed understanding of like the state of their codebase or the state of their engineering org, and then when they go into a problem, they'll kind of think about, oh, hey, I know this relates to that, so if I'm going to go work on this—like they kind of already know—um—some like shortcuts as to how they're going to go and—uh—solve this problem. And we do something similar, so we have first-party integrations with like GitHub, Slack, Jira, Sentry, Data Dog—um, you know, these sorts of things—and uh, we precompute the relationships between these. So if there was some document in Notion outlining—uh—an engineering design doc outlining some changes that you're going to be making—um—it also might have some customer requests or customer issues that informed that, and then there's a PR associated with this when you actually, you know, shipped that change or shipped that feature, and then we see an outage in Sentry based on that PR. Now, instead of needing to like LLM and pull in all this different stuff and trying to figure out what's related in advance, we know, oh, hey, here's this issue which was associated with this line of code which was added in from this PR because of this design doc. It allows you to go in and solve these problems or make these changes that much faster. Um, okay. So, LLM is great, but first-party integrations when you are dealing with a large enterprise or a large codebase saves you a lot of time—um—and just gives you much higher quality results. Yeah. A little—a little less brittle.
All right. Yeah. Tell me about memory because that's—I—I had it on my list of things to ask you about. How—because ChatGPT's memory was such a crucial—crucial feature and it made it such—so many better interactions from it. So I wanted to know like how does memory—um—get incorporated into Factory?
Yeah, absolutely. So memory is something that basically allows Factory to learn—uh—about you and basically different levels of—of abstraction. So if we're working with a large org, um, there is—organizational memory. So how your entire org works, certain things about the product that you're shipping, the customers that you face, something about your stack, these sorts of things. But then it also will have memory at the team level. So if you're a sub team within that org, there might be certain things that your team does that other teams don't do. Um, and so Factory will learn about those as well. And then also down to the individual level about the way that you code and the certain thing—maybe you always forget to do this certain thing. Uh, Factory will learn that, and we'll know over time of, okay, hey, this person's trying to submit a PR. They always forget to write their tests. So let me go and write their tests for them. Or this team, we have these stringent requirements about what a PR needs to look like. And so Factory will then—every time you're trying to submit a PR—it'll go and, you know, adjust so that you fit those constraints. Um, and this is something that over time—uh—it learns and gets better at, and also, you know, you as a leader of your org or your team or you as an individual can go and modify any of this memory if you want to manually change some things.
Okay. And then there was a third factor as well.
Yeah. And the—the third factor here is just the ability to execute code. Um, and importantly, we have basically two ways that you can do that. You can either spin up multiple droids in cloud environments and just send them off, and you have 100 in parallel, they can go work on different tasks for you. Or you can do it in your local environment, so like on your device. Um, and the idea there is if there's a task that you know is well scoped and you're pretty happy to just like send it off, go send it to a droid in a remote environment. If it's something that you're a little bit more—you want to be more hands-on about and—um—kind of like monitor and maybe take the reins—uh, you can have it executed in your local environment on your machine. Um, and having that actual execution allows it such that you're not just generating code, shooting it from the hip, and hoping that it works, but you're actually running it and verifying that, you know, it compiles and that it passes your tests and that, you know, it functionally performs how you expect it to, which is much more similar to how a human engineer works, right? Humans don't just submit PRs that they think are going to work. They actually run it and verify, hey, you know, did this actually do what I wanted it to do? Is everything passing all that?
Okay. So I want to go back to—so Factory is making writing code, writing high-quality code, and writing a lot of code—not for the sake of writing a lot but writing—solving a lot of problems as we were talking about earlier. It's making it a lot easier, and I—I've been thinking about where this leaves vertical SaaS companies. Um, and—and specifically if—like previously if you were an enterprise organization but you were non-technical—right—so not a software company, not building a technical product, you don't have spare engineers to build solutions for yourself internally—um, do you think Factory—do you think companies that are non-technical enterprise companies that can—do you think they should be adopting Factory and building their own tooling internally?
Absolutely—um—in fact, some of our largest customers—um—are, you know, at the end of the day, their core competence is not building software. Like one of them, for example, is Bayer, the German pharmaceutical company that makes aspirin—um—they're one of our customers, and obviously, you know, they're not shipping software, but the reality is is every enterprise today has software at some—like a significant amount, and even if it's not the—the thing that you are selling, it's incredibly important to increase your leverage as an organization if you can now have these droids that you delegate tasks to, or there's this, you know, huge legacy software that you might be paying a ridiculous amount of money for, but in fact, you only need it for some subset of what it actually provides. It's like, okay, well, you can just build it for yourself internally. Um, or you can ship things much faster given that you're probably going to have fewer engineers if software isn't like the core competency of your business. So for the engineers that you do have, you want to make sure that they're armed with—um—you know, the most kind of cutting-edge and productive tools, and you can also get multiplicative effects when they can now delegate to these—to these multiple agents per engineer.
Okay. So—so yes, non-technical companies, and especially—that's probably the case because Factory is making it easy for folks with not long or a lot of experience building software to actually build great software. Um, so I—I think that makes a lot of sense. I—I want to continue on that line, and—and you know, products like Factory are driving the cost of building software to zero. So again—like where does that leave vertical SaaS companies?
Yeah. Yeah, I mean, I think right now is a really interesting time where—and this actually goes back to something you were mentioning of—um—you know, the idea of, oh, if—if this like 10xes every engineer, are you now going to cut headcount? And that would be true if there was no such thing as competition. The reality is every competitor now can 10x each of their engineers. And so great, you can cut headcount and keep your productivity, but now your competitor that didn't cut their headcount is going to be like 100x more productive than you, and they're going to leave you in the dust. And so this is great for consumers of software because now the bar for each piece of
Software that you're consuming is that much higher. Um, because each of these there's still this game theory where if you're the only company in the world that has access to AI, fine. Yeah, you could get you could uh you know, cut headcount and stay like cutting edge. Um, but the competitive dynamics are such that the bar for good software is just going to rise dramatically.
Kind of in a similar way to how in the '90s having a really cool website took a lot of time. And then now, because of how how many like tools there are out there that allow you to um uh make like a cool website pretty quickly, the bar for what is an incredible website has gone up dramatically. Like what was a great website in the 90s is now like table stakes, right?
Yeah, absolutely. Um, okay. So, so last question for you, Matan. Uh, what should people be excited about? What are you guys thinking about building? What are you building in the next 6-12 months?
Yeah. I mean, I think the things to be excited about, um, agents are going to get much more reliable, much higher quality. They'll be able they'll be able to get what you want done with far less guidance. I think what we're seeing is right now I think people that are very leaning into this like agent-native software development use Factory and have a magical time, but they're still at these orgs of like 10,000 developers. There are people who are just not as like hyped up about AI and agents and they maybe aren't as like willing to go in and you know, it does require some uh some uh kind of good faith effort to go in and actually like describe what you want done to get it out. I think in the next six months we'll be at a point where even if you do not give a about AI agents and you're like you want to stay in your like Emacs where there's no AI and you're just things as they used to be, but you go in and try Factory just for like a minute, you are going to get a magical experience and it will really convert people to this new world where you just have higher leverage as a developer in a way that empowers you. Um, and I think people will be really really excited for that.
All right, Matan. Uh, thank you so much for talking to me today. Uh, very excited. Factory AI. I will drop all the links in the description below. Thanks again. Thank you for having me.