I asked Convex's CTO 34 spicy questions

Could I vibe out a production database like Convex tomorrow? No. No. I mean, go for it. No one trusts you if you do it right. He was right. Official. Jamie's always right. Loops, graphs, swarms, all these terms. Should I care any of that? Who gives a [ __ ] Don't try to cheat in the interviews. It's just so obvious. I can see your eyes moving at the same time as just a mountain of absolute trash software is getting produced. Who' you hire? The great engineer who's a jerk or the average engineer you would trust in delight? Neither. James Cowling, Mike, co-founder, CTO of Convex. We're back again chatting. Nice to see you. Welcome back to the States. Yeah. And we're sat in front of the entrance way to Convex this time. the you know it's official cuz there's a wooden sign on the wall. You know we're definitely not in Hawaii or something. Um so listen, I thought I would ask you a bunch of questions because you've always got really interesting answers and so I hope so. I've got a bunch of spicy questions here. I wonder whether you would uh mind entertaining me with I think Mike no restrictions I think. All right. Okay. Okay. I love it. Okay. All right. So let's go with the first one then. Do I still need to learn to code? Yeah. I mean it depends on what role you want to have in the software industry, right? If you are a product person, you want to build CRUD app for example, you're more of a consumer of computing technology, right? Then no, you you don't need to learn to code to be on the consumption side. Even if you're a producer, you know, uh, of existing technologies, if you want to be someone who's actively contributing to advancing the software industry, you know, improving the the concepts that we use, the frameworks that we have, you know, designing technologies. No, I I think you do need to learn to code still. And that might not mean that you're using your coding skills that heavily. Now, at a company like Convex, you do have to know how to code. Like, you cannot land code at Convex if you don't know how to write it. and review it even if you're using an LM for doing that. But I would say yeah, I think it's um there may be some degree of kind of a even like a class system evolving for the foreseeable, you know, some number of years where there are people who understand the code and can step over that threshold when they need to uh and know what is possible and people who are only on the kind of consumption side. Mhm. Would you ever hire somebody who doesn't know how to code? I don't want to say never. Now, firstly, we're talking about engineering roles here, right? Absolutely. I'm going to hire people at convex in other roles who can't code. Currently at convex, no hard no. I mean, yeah, you can our our responsibility here is to build new technology and if you don't have a deep understanding of the concepts at play, I don't think you're currently capable of designing uh APIs and systems. Are junior developers screwed because of AI? I think there are some structural disadvantages for junior engineers right now. I think it's a tricky time and I think um I'm going to say something perhaps a lot of people disagree with. I think the biggest obstacle to the advancement of junior engineers right now is that the petri dish is being taken away from them. Right? And when I say petri dish, I mean the the opportunity to be bad, the opportunity to spend some time building crappy stuff cuz you're not very good at coding yet and you're not and and and and growing and learning. I think there's this mindset right now that you have to be excellent several months into your career and that is a genuine inhibition to developing excellence. And so I think if someone is a junior engineer who wants to be an excellent engineer one day, finding some way to fail, to try to learn, to be building, to not be trying to do worldclass work all the time, allow yourself to to suck. I think that's a pretty important part of the developmental experience. Tell me what is the biggest disagreement you and your co-founder Jamie have had about Convex and who was right in the end. Yeah, I mean I have to choose one where Jamie was right because that would be unfair otherwise. Uh now you might know know Jamie and I are very close friends. We do not always get along [laughter] like you know I'm very nice to the team here. Jamie and I are not always nice to each other. you know, it's it's it's pretty um uncompromising sometimes. Um I think the biggest disagreement we had was one before we had developed a relationship cuz now that we have a relationship, all disagreements, you know, are in the context of us deeply respecting, trusting, understanding each other. I was Jaime's manager very early on at his uh his career at Dropbox. And I remember the biggest disagreement from my perspectives was when I asked him to um to work on a project to improve this Python prototype of a storage system we're working on in a team meeting and Jamie just flat out said no I refused to do that [laughter] in front of the team and I had to cancel the meeting and say okay everyone leave the room. Oh [ __ ] Uh Jamie has refused to do the work I have asked him to do. uh and instead he wanted to rewrite the whole thing and go. And you know what? He was right. We did it. Yeah, we rewrote it. And sometimes it's very hard. There was a lot of downsides from that decision, too. Sometimes it's very hard to like to take the hit of saying, "No, we're not going to ship anything for the next few months. We're going to do a full rewrite." Uh and yeah, Jamie was right about it. We did it. There you go. Official. Jamie's always right. [laughter] uh should we open source our f tests again? I do not know the answer to this and so the answer currently is no. Um, I feel very uncomfortable about this because I like to think of myself as a positive contributor to the software industry and I I do a lot of like free advice and I and I um give stuff away for free and I do free mentorship, etc., etc. And we made a conscious decision to not release all of our tests. And that feels icky, you know, it feels a bit mean-spirited. I don't know. But the reason we did that was because a lot of folks were telling me that they were cloning Convex using our tests uh and that they were kind of excited about competing with Convex. And look, I I actually don't care if a small team tries to do that, but you know, there are larger companies with more money than us who are doing that and have told me that. And so I thought, well, you know what? Like I don't think someone can clone Convex right now. I don't think you can use an LLM to just rebuild Convex and run it competently, but you can certainly get a head start on building a pretty good prototype. And I just felt until the dust settles, we're going to keep our source code out there. So you can see the code, you can use it, you can run Convex locally, but we're not going to open source our development processes. So a lot of the tests that we use to ensure ComX is correct, many of those are currently private. What's one thing you believe about AI that everyone else gets wrong? Yeah, so currently a lot of the opinions about AI are defined by software engineers, you know, us particularly software engineers in this Silicon Valley bubble. And I think this huge mistake they make is to think that other people are like them, right? And I in particular, a lot of people think that the world is going to be excited about building everything from scratch. Won't it be incredible when you can just build your own iPhone? I'm like, I don't I don't want to make my own iPhone. I don't want to go to a restaurant and have the chef say, "James, what do you want to eat today? I'll make you anything you want." There is actually great value in constraints and decisions and choices made by someone on your behalf. And that is the heart of product experience right so um yes coding has been democratized largely and yes there's going to be tremendous success of like general purpose agents and I use town every day for example but I do think still there is tremendous value in product because the average person even if they can code up their own operating system I think has no desire to do so and that job largely should be left to people who are deeply passionate about Mhm. Why shouldn't I just use Postgress? Yeah, I think you can replay the answer to the previous question, right? I mean, if you are a database expert, if you deeply care about infrastructure, if you know what um repeatable read is or read committed is, if you want to build your own stack and reason about distributed data sync or type safe transactions or how to design API servers, great. go for it. Right? People have been doing that for the past 35 odd years Postgress has been around. Right? But if you are someone who wants to focus on developing your product and not developing expertise in an area that's frankly not at all differentiated for you, then you should use a platform like Convex which abstracts away backend engineering. So Convex is not just a database. Convex is kind of the min cut, right? the API, the interface between your application you built and the stack that it runs on top of an abstraction so to speak. Oh yeah, I use that word a little bit too much, but it is an API designed to make infrastructure problems go away, which is a much bigger thing than just a database. Fantastic. What do you love about Agentic Coding? I mean, one thing I love about aentic coding is that I'm able to solve problems now that I previously would not have bothered solving. You know, I I go home and I have this home assistant automation system at home and I have automated all sorts of things with dehumidifiers turning on and and and sprinklers and and uh you know measuring the water in the soil and and all these things that to be honest are a little bit useless. I actually don't really need these things. They make my life a little bit better and more fun. But I am enjoying again the ability cuz you know I'm a relatively busy person with a startup and I'm enjoying the ability to engage in meaningless development again [laughter] uh in a way that's relatively has a relatively low cognitive overhead. Yep. So I guess on the flip side, what do you hate about agentic development? I think I hate a lot of the narrative around agentic development. Right. And I think I hate some of the anti-intellectualism that comes with identic development. Right? Because a tool and it's a very powerful tool. And that tool is best wielded currently by people with a lot of skill and wisdom. And you see this because all the labs for example are hiring very very senior people with a lot of experience. Right? So there is deep leverage value of knowing how to do things yourself and then using a development as a tool. Um, and so I love that part. I love the the craftsmanship, the craftsmanship, like you know. Um, and so I'm very progent development. I'm very anti- this whole idea of just turn your brain off, let the robot take care of things because at the end of the day, I care a lot about our engagement with the technology. Do you worry about prompt injection? You mean do I worry about convex being attacked? No, just in general like in agentic coding it gets mentioned prompt injection is something to worry about and it's something that I know in the back of my head that is there if I visit the wrong GitHub issue and it's got a comment in there it could potentially steal everything on my computer. Do you ever worry about prompt injection? I mean, I certainly worry about it all day, but I have worried about security for the longest time because I spent most of my career running large systems and frankly large systems that have been under attack by um state actors and foreign governments and things. So, it's not a new thing that people are attacking systems and it's not a new thing that that there are vulnerabilities that put you at risk. What is new is that it's much easier um to perform these attacks now and it's um and they're and the people who are the victims a much broader set once upon a time someone had to genuinely care to want to attack you. So um I care about it um and I think the solution to this is architecture. I think the solution to this is designing systems that really do limit what activities can be performed. And similarly, I think the solution is probably not that every person in the world writes their own software and has Fable analyze it for security. I mean, the solution is probably that people use existing systems with guardrails. We saw this with crypto, right? We saw this crypto came along, this trustless society thing, but it is super easy to lose all your money by having your wallet stolen or accidentally transferring to the wrong person. And all of a sudden, you're like, "Ah, that's why banks exist. Right? Because it's I I have those guardrails. Most people don't want to have to care about security and so they want to make that someone else's problem. It's a big problem right now during this transitionary phase. I think we're going to go back to eventually I think probably trusting institutions to take care of security on your behalf. Interesting. Loops, graphs, swarms, all these terms. Should I care about any of that? Who gives a [ __ ] That is not foundational fundamental knowledge right now. I I don't know what the hot thing is. Is it a hot thing right now a swarm or a graph? I look you can learn this in one literally one minute. And if there's an idea that you can learn in one minute, it's probably not particularly leveraged. It's probably not going to make you that much better than everybody else in your career, right? So yes, be on top of the latest ways people develop applications. By the way, the agents, the um harnesses are going to sort this out, right? So like as the product experience of coding harnesses improve, it's going to get to the point where it takes care of this for you. It's not going to be the fact that someone is the world's best programmer because they know to use a graph or a loop, right? This will get taken care of by the product. And then what will be differentiated is not the latest thing you read on Twitter today. What's differentiated is the is the skills that you have and the passion you have for advancing in a certain area. So, sure, I guess they matter. Um, I don't care. If someone doesn't know what they are, they'll learn them in 5 seconds. Finish the sentence. Convex died because eventually the sun will expand [laughter] and the sun will expand and the earth will eventually collide with it. Uh, and I currently don't have much desire to be part of an interplanetary species. So, it could be that Convex is a Earthbound company. We'll see. Okay. But I can't predict. Yeah. RIP Chef or Good Riddens. This is for Convex insiders. Yeah. So, Chef was a coding app we launched about a year ago and then we got rid of it. Um, and so the reason for uh launching Chef was maybe you could say it was cynical. The reason for launching Chef was just to show people it was possible. We built a coding app on ComX in um in 10 days. And I think it was truly best-in-class at the time. Got a lot of attention. But the goal of Chef was not to make Chef a product. It was just to get people to realize that you could build code very effectively on Convex very easily because agents love the guardrails convex producers. So, uh, Chef lived out its life. Um, we might it might come back, but as far as I'm concerned, Chef Chef succeeded because it succeeded in making people understand that, you know, convex is a good set of primitives for agentic development and not that like agents love SQL. Agents can write SQL, but again, write SQL is the easy part. Comx makes it easy to architect systems. What single interview question tells you the most about somebody? This is going to vary a lot on the seniority candidate, right? If someone's junior, a lot of what you're looking for is is is in intellectual aptitude, clarity of thought, um you know, how they're now, when they're doing a coding question, I don't care that they get the answer right. Generally, they do have to get the answer right, but is how they get to that answer. We've seen lots of people cheating on interviews lately where they just kind of give the answer top to bottom like they're reading off a script. Oh, like when it's being filmed. Oh, there's a lot of cheating. Yeah, there's a lot of cheating going on. That is Thanks, Clue. That is not a good That person's not going to get an offer, right? Uh but typically the interview that stands out to me the most for senior candidates is the deep dive. And the deep dive is when I ask someone to go through a system they've built, explain how it was architected, but also explain why it was done and what compromises were made in the process. So I think in one in one respect we get to see that someone has good conceptual thinking skills because they can think in terms of building blocks and explain how a systems architected. But it really gets do they understand why systems are built? Because there's plenty of people who will come out of a big company like Google for example who are I guess good software engineers but when asked why they did something the answer is uh the VP told me to so I did it those people are not going to perform well at convex right because they haven't developed the un the ability to understand their work in context it's not about are you doing the work it's about what work are you doing and why who do you hire the great engineer who's a jerk or the average engineer you would trust in your Neither neither of them get a job unfortunately. Now the average engineer actually might have might have skills that haven't been developed yet. Right? So I do care a lot about developing talent here. By the way, I'm a little bit dismayed as how how few of my colleagues care about developing talent right now. It's a bit of a strange moment where a lot of a lot of companies are not thinking a lot about developing talent. It's really you know development is really skewed how people think about teams right now. I think talent develop is important and if that second person is just a an uncut gem, I want to help hone them into, you know, a sparkling diamond of engineering productivity. But um no jokes allowed and and the reason for no jokes is not because I want to be like touchyfey friendly, right? Because you're in an organization and some people every engineer has an additive contribution and a multiplicative contribution, right? So they produce some amount of output themselves and then they also affect the people around them, right? And a really excellent engineer comes in and everyone around just starts operating 20% better, right? Because they're giving really good guidance. They're really good at building abstractions and building blocks that accelerate the company. Maybe they go and kill a project that needed to be killed, right? So an engineer who's great at collaboration can make the whole company better. Mhm. A jerk can make everyone produce at 90% output or 80% output. Or maybe people start stopping bringing up ideas cuz they're nervous they're going to get judged, right? The jerks can perform quite well in very small teams. Once a team gets beyond a certain size, the the side effects of being a jerk um really bring a company down. And if you have jerks in your company, the only people you'll be left with in the end are the jerks, right? Like the the culture you have is viral and self- sustained. So, no, I have a really high bar for this. And you got to make some tough calls sometimes, but you know, people who are kind, collaborative, you can have very high standards. You can be demanding that you can give blunt feedback. These are all fine. That doesn't make you a jerk, right? But if you hire jerks, you're going to be in trouble. Y in 5 years time what profession will be the most valuable? It depends how you define value because you might say which profession will make the most money uh which profession is best for the world. I do think that there is still a lot of money to be made as a software engineer. I think uh at the extremes obviously the entrepreneurs are going to make the most money at the extremes of the distribution because you're taking on a very high risk for a very high return but the likelihood of success is also very low right so one thing I often tell young folks is to ignore any example of the 23-year-old billionaire it's not a repeatable motion right it's just it's very unlikely to happen to you and so if you want to structure your career I would just find as a a career where you're contributing some value right um doing what feels most gratifying and I still think there's a lot of value in engineering what do you know about software that the models don't yet well I want to I don't want to give too much away because they could very well be getting trained on this uh interview um no so I I hope this doesn't come across is arrogant. I mean, I can design distributed systems better than than any of the models right now. And that's not cuz I'm particularly special. It's cuz I've devoted my entire life towards it. Anyone in my situation can do so as well, right? Um the what what I why can I do that? Well, the models probably know all the facts. Most of the facts I know there, by the way, some facts that you don't even that aren't even in the training set. There's some facts from running very large like exabyte scale systems that no one's written down, right? uh but I think what I can do is is is understand the context around why decisions are made. So one thing you'll see models and agents love to kind of add new layers of complexity like to add new features because they don't currently um possess the discretion to know when it's worth adding some level of complexity. And I think very experienced systems engineers have that that context, that judgment to know that sometimes an optimization's not worth it. And and that sometimes what you're not designing for is today or the feature set today. Sometimes you're designing something that's amendable to changes over a series of years to get where you want to be in a couple of years time. So I guess related to that question is could I vibe out a production database like convex tomorrow? No. No. I mean, go for it. I I No one's going to use it. I hope no one uses it. I hope no one trusts you if you do it right now. That you can absolutely ask an agent to build a database and just keep feeding it tokens and something will come out right. Um, now it'll be trained on a bunch of databases already. So, are you innovating? I don't know. Right. Now, can someone can a skilled person with good taste use ages to build a database? Yeah, you really can. But in that circumstance, you have someone with a genuine passion for for what they're doing. Now, what I'll say about databases in particular, this is a system that that really can't fail, right? The consequences of failure are extremely high. Uh and when you're designing a database, it's not really about designing something that stores documents, returns them to you. It's designing a system that can can be modified over time, can scale over time, works under under varying workloads. So yeah, I wouldn't trust I I mean this is not just about databases. I wouldn't trust any system built by someone who doesn't have a deep passion for that system. Following on from abstracts, the talk with the and stuff. It got me thinking. I'm wondering is I'm 40 years old. I think you're around the same age. Is our old man knowledge holding us back in the agentic era? Do you think? I don't think knowledge ever holds someone back. I think stubbornness can hold someone back. and they're related, right? So knowledge can be preconceived notions and if you have a preconception about how engineering has to work, that can absolutely hold you back. So being a lite right now is is really tricky because it is possible the world a little bit passes you by, right? Uh we could be here at convex saying all code's written by hand and but no, that's that's not how we operate. I think knowledge is of tremendous benefit but you you do have to marry knowledge with humility. Now the nice thing about having a startup is that it keeps you humble because you don't get to feel successful very often. Every day you're confronted with with scaling and leading your own company at the same time as everyone else's success. And I think that I think that that keeps the arrogance tempered enough to to to keep you. Okay. Um, what decision is baked into convex that you would take back if you could? Yeah. I mean, there are convex is both too large and too small at the same time. And so there are parts of the convex product that are not core to it. One of those is is is storage is is file storage. Uh there's quite a few others that were um cron jobs as well. I don't love how cron jobs are represented in convex. These are things that we we baked into the platform because we did not yet have the good primitives to build them on top of the platform. Now we have the component system. File storage can absolutely be on top of convex and and um people use the R2 component all the time instead of our convex storage. So I think um there's a now as we do this more and more that pressure tests our our APIs to say like if you can't express a convex feature on top of the convex platform what's missing and there are a lot of primitives in convex that are missing currently we're very actively working on like suspend and memory tables and spawn all these things that we have to add. So I say the the I don't I can't say I regret this because we just didn't know the right parameters at the time and I think you know I can talk about abstractions all day but but it's foolish to think that you can just sit down and write a good abstraction on day one. It's it's normally a huge mistake to generalize something before you've solved the problem in the specific case. So in the process of building convex we understand convex more. If I went back to the start, it would look quite a lot smaller and most of the stack would most of the complex functionality would be built up top of its components. So in the age agentic development and you can vibe everything out now. Um what is a moat for a company now? Yeah. I mean there are a lot of people that will tell you the only moat is distribution and I don't like that idea, right? Um that doesn't mean it's not true. I actually don't think it's true. Right? There are certain applications for which the only mode is distribution right um a lot of applications are easy to replicate frankly right and if you're building something that you don't have unique interest in a unique insight in a unique passion for that's hard to build right that someone else could clone relatively easy then yes your moat is network effects marketing etc right I don't enjoy that kind of that's not why I got into the software industry right so I think there are certain domains where the moat is talent, the moat is wisdom, the moat is strategic direction is to be able to anticipate the needs of of users in the future. And this is the case for convex. And by the way, it's the case for the research labs too, right? And the reason you know this is because they keep their weights closed. They keep their training harnesses closed. They hire very experienced senior engineers and they pay them a lot of money. Right? Clearly, there's a recognition that something about how they operate is better than how the other companies operate. And so, I do think that talent is definitely still a mode, but you have to be working in an area where you're being flexed. And if I message I'll say to anyone is if you're finding software development easy, then you're probably not in a sustainable business, right? Because the thing about capitalism, it will extract value out of things that are easy, right? So if you want to be succeeding in a certain domain, either you capture a market and then you have monopoly power over it or you take on something that's hard. So there was this rumor going around for a while that Dario said Dario the CEO of Anthropic said in an internal meeting that Anthropic will be the only private company left in the world. Is this true? What a horrible future that would be. Right. And I think the reason why that's likely untrue is because there's no societal appetite for this future, right? I mean, it's until the robots take over and we're imprisoned by the machine. What we want matters as consumers, right? I think there'll be tremendously boring future to have one company making all the decisions on behalf of of the world. [laughter] And I think for the for the foreseeable future, there is tremendous value. like I said before is it's the I I there is value in being a general purpose provider of intelligence and there is also tremendous value in someone making some decisions and producing a nice product right and if you think that all products go away and everyone builds everything from scratch and it's all through a chat interface or spoken word then sure they might that might be a winner takes all situation but from my perspective that is not what the consumer wants If you were 18 today, would you still choose to do computer science? Uh, so there's two questions. Should should 18-year-olds go into computer science and would I do it? You know, I think it's possible I wouldn't. Uh, and the reason why is because what drew me to engineering was was the craftsmanship. Like what I'm really passionate about is caring and thinking and dedicating yourself. computer science felt like just this ultimate domain of just investing deeply in something and that is by the way still the case but it's not the narrative right and I think if I was a young impressionable 18-year-old and I was pretty naive at 18 I would have maybe thought oh well you know software engineering is just about distribution and marketing and faking it till you make it and all that kind of stuff not the case but probably the narrative would have got to me and I would have gone into precision manufacturing or Uh but you know I think there I think if if you're passionate about something go into that by the way right most of the world has people going into jobs because they want to do those jobs right the the question about like just choosing the job that pays the most is a is a is really go you know people do need to pay the bills but um if you're passionate about problem solving and uh and thinking about user needs and dealing with constraints then software engineering is a tremendous career it's going to change a lot and that's scary, right? But I don't think those skills are the kind of skills that are a waste of time to develop. Does shipping five times more with AI make you trust somebody more or less? Another way of phrasing it, if somebody outputs a lot more stuff, does it make them more or less trustworthy, more or less productive? Is that Yeah, I mean, no, I understand the question. I I think it depends on the domain, right? Because there are certain domains where it's obvious that you're going to produce five times more now, right? certainly the higher in the stack, the more front-end folks, but then once you get more senior, you're the bottleneck is not cove, you know, the and even if you're a a designer, the bottleneck is not mocking something up in Figma, right? Uh it's it's far more cerebral and and and involves long-term thinking. So, if you were a database engineer who all of a sudden is producing five times as much work, I'll be like, "Oh, what are you you what what are you you doing?" But a lot of folks will produce a lot more. I just I just a caution against like software engineering is not coding, right? That is and the more senior you get, the less the coding matters to be honest. This is based upon one we were talking about the other day, but have you ever written a restful HTTP API? Ju just kidding. Just kidding. Now what's what's a common mistake that you see people making in um in job candidates making these days? Yeah, I mean the reason why you're asking this question is I made a joke that currently if you were to look at a 100 job applications some significant fraction approaching half have the phrase restful APIs in bold. I don't know why no one ever used the phrase restful APIs five years ago and no one felt I mean we people used rest but they weren't proud of it enough to put in a resume and I guess Chad GPT or Claude or someone decided that's the thing to put on resumes right so when I'm looking through resumes uh candidates might not realize this but when you're looking at a 100 resumes in a row the the brain is very good at pattern matching and you can just filter out all the nonsense that says nothing about someone and it just say says whatever the machine put in Yeah. Right. So, the mistake I see with candidates is trying to be something they're not. Right? When I'm hiring something, I am trying to get at to the essence of who this person is. Throwing in filler words or kind of thinking that you have to make up an interest to look good. It makes you look very bad, right? And maybe you can trick me. I mean, it's it's possible that someone can make up a fake resume that kind of gets through, but do you want to trick your way into a job? You know, that's that's just day one to getting the job. Then you have to do the job, right? So, my advice to to to people applying for jobs, I know it's hard. I know it's a hard market, right? Is to try to be as human as possible, right? Try to be as genuinely you. Try to say what you think. Don't try to cheat in the interviews. It's just so obvious. I can see your eyes moving. Like, it's I'm not an idiot, right? And so the more you can be a human, the better because I am hiring humans. I have the tokens already. What I'm hiring is the is the person. In the next 12 months, will we see more or fewer bugs in popular software? More 100% more. Well, two things. We're going to see we're going to see more crappy software and we're going to see more unearthing of existing bugs. Both of those. So, you know, live by the sword, die by the sword, right? coding agents are going to do a good job of finding longstanding bugs. There's there's so many vulnerabilities in existing software that are going to get unearthed in the next year. At the same time, there's just a mountain of absolute trash software getting produced um by a lot of people who don't currently have an incentive. So, you know, we're not in steady state currently. There's not an incentive for folks to care a lot about quality because a lot of us are about recognition, mind share distribution. Uh, and I speak to people that how they build their software. There's a lot of really bad software out there. So, it'll change. They'll they'll quality will come back in style, but it's not it's not the MMO right now. Is AI making us dumber? Yeah. Yes. Well, it's certainly reducing our ability to perform certain tasks. And maybe one example I'll give is I am bad at navigating now, but I grew up and you probably did too in the old days of using that the the the you the hand um you know street directory and so I was really good at navigating a city back then. GPS came along and my my ability to navigate is just worse now. Um but I traded that for a whole bunch of other things. So I'm not it's it's not always strict loss when we lose certain abilities. I am a terrible hunter gatherer. I couldn't I couldn't skin an animal. There's all sorts of skills I lose, right? And so AI is is is going to take some of these skills away from us because we're not going to be um writing code every day. The but you know, the average college graduate is demonstrabably worse at writing software than they were a few years ago. I see this. They are worse at fundamentals than they were before. that does make them in some respects worse engineers currently. Um but it makes us better and more powerful in other ways. I think we're in a place where we have gotten dumber more than we've got smarter but but the capabilities will increase and it might balance out. When did you last seriously think about quitting? Quitting Convex? I haven't ever considered quitting Convex. And without saying too much, I think folks here know that we've had a lot of opportunities, Jamie and I, as founders, to kind of get off the ride and take large sums of money to do so. And this is just not not how we operate here. This is not why we got into this game. We started Convex because we wanted to change how applications were developed. We started commerce because we looked at the set of tools that existed you know memcache and postgress and and cafka etc. We realized that the ability to to weave these in to a scalable, sensible infrastructure back end, we're diminishing so fast. To your question about are we getting dumber, we as an industry are getting so much worse at building infrastructure, right? People just do not have good infrastructural sensibilities right now. So we recognize that these skills are going away and that we wanted to build an abstraction that that that ameliorates the negative impacts from that and we haven't succeeded at that yet. And so that's a that's a personal mission. I I pretty caught up in that emotionally. Are docs for humans for agents now? Well, the reality is most people are not reading docs anymore. But I don't think that means that they don't matter because I think the process of writing docs in a way that is easily understandable by a human uh is valuable in two ways. one like clearly documenting something is one of the best activities for for evaluating your own cognitive connection with what you've done, right? So to explain something clearly involves weaving into a narrative and breaking down the building blocks and doing so really um improves your own mental thought processes. It also ensures that you express those things in a very intuitive way to to an end user and and then that gets picked up by LLMs and goes into the training set. So I don't think that means you know you can just slap your source code out there and just say hey agents go figure out how to think about our system because to understand convex is not just understanding this the software you got to understand the philosophy behind it. So currently at convex we write docs for human beings we make sure that you can get the markdown files really easily. We understand it's mostly agents reading them but I think by virtue of writing them for humans helps you write the law for agents. Is Convex the end game for databases? The current version of Convex, absolutely not. Right. The whole point of this is to evolve over time. You know, it's funny. My my my mom in Australia, she's not a startup person, you know, and she's often asked me, "Hey, James, when's Convex done? Like, is is it done yet?" And I I say, "Mom, it's never done. It's never going to be done." Right? This is uh Convex's mission is to is to provide the abstraction the platform for the application development and that won't finish and we have to keep innovating to stay at the forefront of that. If we stop innovating we'll fall behind and someone else will come along but no I don't think I don't think the end state of anything exists right now. This is a question that was asked at abstract during the week as well. But u is code review going to become a relic of the past. Do you think code review uh in many organizations already is a relic of the past? Uh many people are not reviewing the code at context. We do review the code but I want to be pretty clear about why we do it. I have never been much of a believer in code review for the purposes of correctness right at least on experienced teams. Right? If you have a junior engineer, you review their code to make sure it's good, right? But beyond a certain level of experience, seniority, I expect the engineer to be responsible for their own correctness. So then you ask, well, why would you even have code of view? And it's for two things primarily. One is to have another mind having a look at your design. How did you go about a problem? Are you thinking about it the right way? And code of view is quite valuable at that. The second is education. Code review is one of the best mechanisms for providing peer feedback on how people think about system. And I've noticed a lot of frustration amongst reviewers when they write a thoughtful review and it doesn't get read by a human being. this gets read by an agent and a PR comes back because there is a social contract we have currently around code review which is that if I'm given a code review I spend time doing it and then I expect the other person to read that feedback appreciate that feedback learn from that feedback and if I don't think they're learning somehow it feels less gratifying so I do think code of review is probably going to fade away for most teams but we do have to find alternative mechanisms terms of self-improvement cuz code of view is was one of the best ways to improve your mental models. Yep. Has Convex ever made a decision that hurt growth but protected user trust? Convex constantly makes decisions every day that that limit our short-term growth uh for the benefit of of users. And now one example of this is just if we've had outages we published um you know postmortems and we've you know uh we had a very prominent outage very early on when Theo had moved T3 chat to convex and we went down and uh that was very embarrassing. I was on call and and we published an article about this and said why it happened and I think that helped Theo trust us more and I think that was actually turned into a positive for the company. Um the engineers here know that we have a very high bar for adding something to our abstraction. We have very high bar for just like adding another complexity to our interface because that can hurt our users, right? If we add a whole bunch of stuff, complicate how they use the system and then start taking them away. Yeah, they might negatively impact their projects. And so it's tricky. This is a company that in some respects moves slower or in a lot of respects moves slower than someone who's iterating on their fitness tracker app or whatever where you can move fast and there's not that expectation of correctness. I take I mean the number one company value at comx is to be worthy of trust and your company values are not worth anything unless you're willing to take a hit for them, right? And people know like it's just the amount of work we go to to avoid someone losing their data or to to avoid leaking anyone's private state. It it it is a huge amount of the work, right? Um but it it it matters because um it's it's part of our brand. It's part of of of why this product exists. Yep. What's a widely loved technology that you think is a mistake? Uh yeah. Um I I won't I don't want to mention company names here. Maybe we'll skip. No, no, let's answer the question. [laughter] I I the reason we started Convex is we didn't like where um platforms were heading, right? And uh for example, I do have tremendous respect for Firebase. Very innovative product, but I didn't like how it it funneled developers towards this model where you had most of your business logic on the client and you and then you therefore had to figure out how to secure your database with role level security. You see this in a lot of other app products right now. This model that that went from okay cool the developer is now the full stack application developer. We went from the platform engineer, API engineer to the full stack developer. Therefore, we have to democratize access to the stack. Therefore, we have to push all the business logic to the client where it's running on untrusted client hardware. It's very hard to run transactions on the server. And so, part of the genesis of Convex was like this is the wrong architectural model for a good reason because it did succeed in democratizing access to development. And so the idea of convex is can't we take the old model of having secure code running as transactions on the server locked down and run safely next to the database but democratize it by allowing developers to write it in Typescript and have it automatically sync to the server. So yeah that's that's the genesis of convex. haven't succeeded in eliminating that development practice. But I would be stunned if that's the the default mode of building systems in in in 10 years time. I we'll look back on that like we'll look back at eventual consistency as maybe an artifact of the time. I think we'll look back at this kind of client side business logic as maybe an artifact of of the current time. And final question, um, build versus buy. Build a buy almost everything you can buy. Right now, there's a few caveats to this. So why? Well, why is because you want to focus on what's uniquely differentiated about your business, right? The more you can make things someone else's problem, the more you can take that energy that you have and devote it to making the best thing in the world. Now, there is a one big caveat to that, right? which is that you don't want to outsource expertise in your space. And there's been articles published about companies like Boeing, you know, that ended up kind of outsourcing so much of the development practice that at the end there's no one left that knows how to build a plane. Mhm. And if you don't know how to build a plane, it makes it pretty hard to design the next plane. This is why I think, by the way, CS fundamentals still matter, right? This is even the case for codegen. Should I outsource all coding knowledge to an agent? Currently, no. According to me, if you want to build sophisticated, challenging software, right? Because even if you're not writing the code, knowing what's possible and knowing how your stack works allows you to innovate because you can't just ask a coding agent, tell me all the things that are possible right now. You can, but it's not going to be any better than what anyone else could do. If you want to be continuing to innovate and at the forefront of your industry, you have to have some unique domain experience and unique perspective on your product. And that requires not outsourcing areas of your core competency. And that's it. Thank you very much, James. Thank you. Thank you, Mike. They weren't too spicy. I don't think next time we'll see if I get spicier questions. Okay, guys. If you've got spicy questions for James, leave them down below because he just said he said he wants more spicy questions. We'll see if I get in trouble then maybe they were spicy. But next time around, feel free. I love love answering answering questions. So, thank you. Perfect. Thanks, James. All right. Thanks, everyone. Cheers.