Can AI Really Build Enterprise-Grade Software? | Maor Shlomo & Base44

9,688 words · about 39 min to read · YouTube’s automatic captions

0:00 When you're looking to create like really complex software using LLM, it's important to take away as much of the complexity from the LLM as possible. If you would need to give like a very long and complex speech, obviously it will be easier to speak at your native language. Every large organization has tons of software needs. Think of an organization like Pepsi or something like that, right? The more that you build tools, the more that you build automations, the more that the business becomes more efficient. When you build a web app in B 44, you already have everything you need to make it functional. User management, a database integrations with sending emails or leveraging LLMs and analytics and logs and all those kind of things.

0:44 So with all of these advancements and all the capabilities that B 44 is building, like what's your prediction about how long does it take till you can build a base 44 with B 44? Um

Opinionated App Builders Bridge the Gap

1:04 hello everyone. Welcome back to the AI native dev. Uh today we have a really fun episode where we'll talk a little bit about sort of startups and entrepreneurship. We'll talk about uh building uh in in sort of AI powered ways and five coding and kind of this brave new world, but also how do you actually build a company uh and uh and use AI to uh to make that a possibility. And to talk about all of that, we have Mo Lammo, who is the founder of B 44.

1:30 Tell us a little bit about what B 44 is and what was different about how you built it or not how you built it, but rather the thing that you built.

1:38 Um, B 44 is is an AI app builder. Uh, kind of like the text to app that you see a lot these days. uh I think we're taking a very different approach, a very opinionated approach which is uh help people build actual full stack functional applications. So sometimes the way I like to put it in perspective is saying vibe coding has been awesome at first um for building websites and building user interfaces and some MVPs like mainly front end. Um and then B 44 was I think the first one but maybe one of the first ones to introduce this concept of uh batteries included app builder which means that when you build a web app in B 44 you already have everything you need to make it functional already built in. So user management, the database integrations with like sending emails or leveraging LLMs and analytics and logs and all those kind of things that you need when

2:38 you're actually building a fully functional or even complex application. Uh and that's what B 44 basically does. It's helping users create software that either they or their users or customers are going to use dayto-day. And is it is it more about the choice of uh the opinionated stack? Hey, I chose a database. I chose you know all these other aspects. Uh or is it uh about the continuation because I know you also you know you deploy an application you kind of handle the operational aspect of it.

3:14 uh do they have to go hand in hand? Is it uh like how do how do you see the uh the interaction between like the choice of stack and managing the operation of it as well?

3:24 Yeah, I think it's to some degree both. I think the choice of stack will become less important throughout times. So like I can see that with our developer community as they gain more trust in like what base 44 does and like the fact that it's becoming slightly less and less importance like what's the tax stack that you're using and how you're going to handle deployment and those things. Uh because VIP coding is getting better. It's not perfect yet. It's still hard to build production applications. I think on base 44 it's slightly easier but there's still a long way to go. Um, and I think it's like this opinionated approach is basically trying to correct the actual experience of how you want VIP coding to look like. Like you don't want to start stitching together different services and say, "Oh, you know what? Now I want to connect an LLM.

4:18 I need to go to OpenAI, bring my API key, fit it into the VIP coding platform, and I want to connect the database. I need to look at the tables and run migrations and stuff like that." things that nobody really wants to uh to deal with or at least in the future I'm imagining a future where those things are are entirely being handled uh behind the scenes and you can just literally build what you want to build and

Tailoring the Tech Stack to LLM Proficiencies

1 Highlight · Designing Backend-as-a-Service Specifically for LLMs

4:44 literally program in English without needing to understand again what an API key is and so on. Um, obviously to do that we had to take a lot of like opinionated decisions on the tax deck and so on.

4:57 And I'm I'm still curious on how much is it that you are uh uh picking specific stacks that you have seen the LLM to be good at or that you've just really invested in making LLMs create well with versus where is it things that you've just taken out of the LLM's uh domain. you know, like uh I'll give an example like in in in Tessle, you know, when we create software, you know, for a while, we actually don't need that now, but used to be that, you know, the LLMs just wouldn't stick to the dependencies we told them to do. It's like, hey, create this code here, use library A and B, and it would just sort of use B and Z and whatever. It would invent things. Uh until eventually, uh we said like, okay, you're not allowed to choose dependencies anymore. We'll we'll put the import A, import B over there, and you you fill in the rest. Uh we've since removed that because they got better at it. But uh but that was like to me like commandeering control like I guess is it similar like the LM just has nothing has no choice has no say in the choice of a database. You just have to use what you've been given or is it about

5:57 choosing a database that you made it use very very well. So I think one of the advantages of building base 44 uh I would say late to the game is the fact that uh we really designed a lot of the things around the LLM. So B4 obviously employs a concept called backend as a service uh which is like for for the devs probably familiar with like Firebase or Superbase and so on.

6:25 Um, but those are like products that were built pre the LLM era and had their own like endpoints and syntax and so on. And so when when I started base 44 and started kind like building the first couple of apps and so you see what the LLM uh is uh trying to do and in some places like you try to like limit it further. So you tell it like hey don't use those packages and it tries to use those packages. So, so you like try to I don't know write in the prompt important exclamation point exclamation point exclamation but like don't do that or the other way around which I think work really well for us is like just uh uh run with it like see what the LM is trying to do when it gets confused and build it almost in the same syntax that it's using. So for example, if it's constantly using like one package over another and you're trying to use the other, but there's no real difference between those two, maybe the the stack

7:25 stack will be should be built with package A. So

7:29 in some places sometimes it's better to just uh go with whatever the LLM was trained on because it will likely bring you better results. And I think a lot of the design of our SDK, our backend services, the packages, the text tech was more around uh what LLMs are really good at doing and writing code with.

2 Highlight · Optimizing for LLM Strengths in Language Choices

7:53 Yeah. And I think this was an important decision because again when you're looking to create like really complex software using LLMs which obviously as we all know in the space LMS are struggling with it's important to take away as much of the complexity from the LLM as possible and if you can make it easier so think about it as like think if you would need to give like a very long and complex speech right obviously it will be easier to speak at your native language So that's what that's what I tried doing with the LM is like trying to understand what's the easiest way for the LLM to create functional software and then build the text tech design the SDK design the end points around that.

8:37 Yeah. Yeah, it makes a lot of sense and it sounds like it's a bit of both of the things that I talked about. there's some back end as a service that is outside their the scope of the LLM's decisions at least as you build a base 44 application and then on top of that you have the uh the sort of the choice of stacks that uh go with uh go with the flow or go with sort of the uh uh I guess kind of prevalence and knowledge and the u and you've uh we're going to talk about your own tech stack but you've chosen Python for instance

9:06 and I'm I'm guessing that's sort of a similar logic of like Python was the language the LLM are most proficient at.

9:14 Yeah. For back end, yeah. Um for front end, there's also some controversial decisions that I've taken. So, one of them is uh LLMs are having an easier time using writing JavaScript than writing TypeScript. Uh and they get confused. Uh so like some of our a lot of our front end is still written only in JavaScript which could uh can shake can shake

9:41 there are there are firm opinions about this and in the amidst the technologists

9:46 yeah I'm sure but also like things change right like um I think if we get back to like uh in the places where you actually limit LLM or you say okay to okay this is the building block that you should and and can be used uh like you should use nothing else besides that. So yeah, so as you mentioned what you guys have seen in Tesla is like LM get better and better or change and adapt and in some ways like uh even in the the tech that people build apps in base 44 these days like as LMS progress we take away some of the some of those guard rails to

Democratizing Software Creation for Non-Developers

10:23 allow the LM more flexibility.

10:26 Yeah, makes a lot of sense. And the uh maybe let's just sort of on base 44 still kind of as a user base. So the target audience of that is is what is it? Non-developers is it developer adjacent but technical people? Is it none of the above? People that are entirely non-technical. Who did you build it for?

10:45 Definitely for the nontechnical people. Um the first couple of users were like a restaurant manager, a marketing guy, like some of my best friends, right? But I know their connection to code was uh something distant. Um but I think what's surprising to me is that as time goes I see more and more like there's like a big community of like developers using base 44 and obviously as time goes we we're developing more features for like semi developers people who do understand like uh some technicalities.

11:21 Uh but I see a future where where it's like it doesn't matter anymore. It's like um if you look at like building a landing page or a just a landing page, right? Uh think about it before the age of LLM, right? Um obviously at some point even if you're a developer, it would be easier to use Wix than to code a landing page. Even if you do know like HTML, PHP whatever and host it and deploy it and whatever like nobody wants to do that. Um me myself even before like before LLMs were like vibe coding were a big thing I've built my uh my girlfriend's website using Wix and I think in some ways for a large portion of software that that's what we'll see. So even if you're super technical, it will be an advantage when you're vibe coding stuff. Um but it won't matter that much like it will be clear that that's an easier choice than to open up a new GitHub repository,

12:23 start writing code, deploy it, run test.

12:26 Yeah. Why reinvent the wheel when you uh

12:28 Yeah.

12:28 But how do you how do you think about so for the non-technical user trying to think about the sort of the lines, right? So if you're uh a developer, I think a lot of vibe coding, whether it is in platforms like B 44 or if it's things that you do more locally, the cloud code sort of cursors of the world, um you in in those worlds, you have a very tight relationship to the code. The the LLM modifies the agents modify the code, but when there's a problem, your sort of supervision happens on the code.

12:58 I think in base 44 you can see the code but it is it is a kind of a hidden entity or it is not it's not designed to put the code in your face too much. How do you how have you seen and what maybe there's like learnings learnings about how you have built for people who don't understand code to be able

13:18 to to interact and get the system over the hump when it fails to deliver something right when it fails to accomplish something. Is it all just like give it more guidance, give it more guidance and and hope it gets it right?

13:30 Yeah. Um, not only I think the interaction when you're building an app in base 44 versus, for example, if you're building an app using cloud code or cursor, it's a different interaction and and many times it's a different user and a lot of times currently it's a different piece of software. Mhm.

13:50 So I'll start with obviously the way that um B4's users do iterations and experimentations and so on has a lot to do with visual like you see the app in front of your face. You know if something is wrong you'll see that in the interaction or you'll see a bug being thrown away or something like that before you even look at the code. Um I think platforms like base 44 still there's obviously like a limited set of software that they can build. Um and this this set is going to expand further and further and further as time goes and that's what we're working on. But it's still important to be very honest and say there's a set of software that you'll be better off building using Kurser than than than using B 44. Um so for example base 44 itself put aside the front end which is obviously built using B 44 but the back end for B 44 is not built using B 44 it's like built using cursor and code and so on

14:52 um because you need to look at the code and you need to understand the code and so

14:57 this whole thing like this is the situation and reality right now I think this is this will aggressively change in the next few months even but definitely few years again as as you'll be able to visually or or like prompts only uh without looking at the code, you'll be able to build an increasing percentage of the software that you're currently building,

15:22 right?

15:23 Um and yeah, and so the tools that we're giving our users are are a different set of tools to how how they experiment and iterate with their software. It has to do a lot with visual. you have to see the the the application all the time. It has to do a lot with trying to explain better what's going on. So, for example, we have this uh small feature, but people really love it where when you prompt something in base 44 and it starts coding. So, obviously we like most of our users don't want to see the code. It's just it's terrifying for them. So, they don't understand what's going on. And so we have another small LLM that basically watches the coding agent, see what it does, and kind of like explains to you in real time like what's the coding agents currently doing. And it's like a small like now it's changing the uh UI from light team to dark theme and whatever. And so

16:18 yeah, we're building a set of tools to help people build software without the need to look at code.

16:23 Yeah. Yeah. That's so smart. progress indications and and engagement are super important. So I think that makes sense to me. If I echo this back, I feel you're saying um there sort of the two domains maybe that base 44 today is most helpful are cases where a lot of the validation and a lot of the decisions are much more product oriented and a lot more visual specifically oriented uh and uh as opposed to sort of technical and how did you implement and the second is that maybe a lot of them are are places where that visual is also the innovation like a lot of the technology you're not looking to uh make a product that sort of works that's not some sort of the world's fanciest progressive web app that uh does a lot of things. A lot of your your creation is a lot more about the content uh and the navigation and all that might be sort of similar and common and so the LLMs know how to do it well and you can do it very efficiently but you're innovating on sort of the the content and the looks uh more uh is that does that sound fair

17:22 and then it will expand over time?

17:24 Definitely. But I'll add on top of that, I think it has more to do with the type of software that you're building, right? So if you're building nowadays something that that's like performance is super important,

17:38 right? Like you can't v code your way through it, like it's like if you're building, I don't know, a VPN software. Let's take this for example. Um

17:48 yeah,

17:49 so obviously like it's it's going to be really hard or something that relies very heavily on like back end and stuff like that. So

17:58 previous company probably can't vibe code sneak.

18:01 Yeah.

18:02 Uh at least not yet. uh I think for other set of applications it's not necessarily the visuals but more of like if you're building an application that that can do what it needs to to do with a database a set of integrations APIs and so on um I think like you you'll be like you can do a really good job using B 44 and it will likely be an easier experience than try to code it via cursor

18:30 right yeah

18:31 uh so it has to do with like the lowlevelness of stuff and complexity on the back end side. Uh but we are getting better at that.

18:41 So uh I have one more question on base 44 but maybe let's first switch to how you built it. We'll talk about your

Accelerating Solo Development Through Infrastructure

18:47 stack and then we'll combine a little bit. I'd like to uh touch a bit on longevity like building a disposable app. I think you're creative doing it versus what do you build for long term? But take us behind the scenes a sec. So you've built you know like single person built substantial platform and also scaled it. Uh I guess tell us a bit of the uh of the tips and tricks. I heard you shared a few of you know what what helped you uh create that and maybe started with like do you think you could have done this? I know you used AI your creation like was that critical? Do you feel you could have pulled off a base 44

3 Highlight · Building a Solo Startup with High Velocity via AI

19:22 without AI dev help uh as a builder? Uh short answer is definitely not. I was at least not in the same structure and way that I did it with B 44. So when I started B 44 even before knowing what I was going to do, I knew that we're in a different era. I've been like leveraging AI, working with AI in my previous company, both as like AI inside the product and also coding with AI. Mhm.

19:52 Um and I felt like I felt strongly that we're in a new era where doesn't matter the number of people building software anymore. more meta about like if you have a unique take unique product kind like uh and you can design well like design software well not I'm not speaking about like UI design then it's not anymore about like hey throw as many people at the problem as you can those people will write more code faster and that's where you'll get to so I was like I'm going to do this alone from day one I'm going to set up the repository and spend 20% of my time content constantly on how can I further uh increase the velocity and speed. So a lot of what I did is like experimentation with how LMS write uh code better. Obviously I did it for base 44's product as well but but even for my own repository right so I find those tips and tricks like what I I've spoken about like javascript versus typescript

20:54 maybe now it's changing with cloud 4 and so on but back then like I could write

20:59 uh front ends like the speed of light uh just because of the setup

21:05 uh another thing is is I've built this from the backend side I built this very high level uh infrastructure uh that handles like the database and user management and so on. So that even if I would have pivoted to a completely different idea, 80% of the code would stay the same. And so I had this like really good infrastructure um that stayed the same and that's what those were like the parts of code that it was slightly more me than the AI actually writing and making sure that it's perfect and from there once you have those infrastructure and so now adding a new feature that I don't know has like a new table in a database and has some integr some interaction with with other parts of the platform became super easy. Uh the way I'd measure that is for the LLM to implement a new feature, I wanted to write at the least code possible to implement the feature end to end. And so I built a lot of like

22:06 those things obviously and rules and so on into the repository so that I could run on my own but still keep the same velocity as my competitors if not even better, faster. And I think I think to some degree I've done that like I think the the competitors in this category are super heavily funded um and in many ways and aspects base 44 executed uh extremely fast if not faster than than a lot of the players in the in the category

22:40 and I give a lot of credit to the AI like most of the credit is to to the AI of like structuring it

22:46 for getting me the

22:48 yeah I want to thank second Oscar. I get the

22:52 I think uh so so so I love that. I guess again kind of echoing back a little bit. I think you know the first thing you're sort of touting is like the value of a good architecture uh where you anticipate uh what would be future changes and you write the ability to write compartmentalized code and I guess I'm I'm hearing something that is almost similar like to hiring either junior developers or outsourcing you know places in which if you build the right architecture then you could have clear instructions to someone else who's maybe a little bit less trustworthy uh to write pieces of software within it uh and be able to assess whether they've done their job well and be uh I guess can be able to to guide them. Does that sound like a fair analogy?

23:36 Yeah. Yeah. Exactly. Because also one one other thing that like I've noticed is like when you're leveraging AI for coding so think about it this way like you let's say you're building like a simple full stack web app, right? So, uh, you tell, hey, I want it to be, um, a to-do list app or whatever. So, the AI implements like some of the routes and connects the front end and so on. And then you open up a new chat, right, in carousel or something and you want to implement another features like write an admin panel or so on. Uh, so it will look at your code and it will do the task, but an AI is really good at that, but AI is not really good at stop and saying, "Oh, you know what? There's actually like common concepts here that I could like combine to like this infrastructure or package that I can later use in other features and oh I'm writing the same code again and again like let's stop and before I do like the the task that you gave me let's kind of like implement yeah let's refactor the code so that I

24:38 won't need to write as much code and so on. So I think this is something that a lot of developers currently don't notice about AI like it will it will implement the task as you told it to

24:48 but it's still lacking the hey let's stop for a second we need to refactor the code because I find this common layer or whatever

24:56 and I think that's that's

24:57 and so those that's something you still did manually like you would observe what the AI has built and you would kind of go off and and modify it a lot of a lot of what we see with AI which I think touches on the topic you said right now is is about the initial creation, right? And it would go off and even there you sort of see the sort of reward seeking, right? It might burn down the house to sort of be able to accomplish this thing that you've just like break all the other features, you know, just to be able to make this feature you just asked to to make it work. But um but but the other aspect is indeed maintainability.

25:28 It's indeed code duplication. It's all these things that are sort of bad practices uh when it comes to sort of quality software creation. Um, so I guess I'm asking like I think you've you you did it on your own in B 44 for your codebase. How do you think about that in terms of building applications that are built by B 44 um to to have longevity? So in two ways, one, when you build an app in B 44 these days, like there's a lot of infrastructure and setup that happens before the LLM even writes code

26:06 that in some ways limits it, but not really, not in terms of like what it needs to, but it's kind like it it those are guardrails that the LLM should keep

26:15 and as long as it keeps that, then then it should be fine to some degree. Um so again we automatically create the entire uh uh read update delete kind like the CRUD SDK and and we make it like really good and we implement like rate limits on top of that and things like that that LLMs wouldn't really care about

26:40 and when you leverage um I don't know APIs and integrations and so on like we kept a very strict schema there's like a lot of things that we implement mented built into the application so that LLM won't kind like be this reward seeking of like I'll do whatever but I'll I'll keep your app exposed and and so on. The other the other thing is yes at some points uh we automatically feedback the LLM whether the user knows about it or not that it needs to refactor something. So for example, uh one of the things that makes LLM confused the most um and people feel that like across the the the vibe coding category is uh when they're saying like hey I asked it to do something it didn't do it it did the opposite it deleted a feature or whatever um is when code files are are getting too long uh right

27:38 right if if like you've implemented so you ask it initially or early on Hey, implement this page, create a to-do list up, and it did something simple. It's like a very simple to-do list up like in any other React and then start layering in features, right? So, the LM does what what you asked it to and and it start adding like uh AI features to write the tasks description and then user management to like assign different teams and boards and whatever. And at some point, you have like if you're not careful, you might have like this very large code file. Right.

28:11 So one of the things is like we're running behind the scenes refactoring tests uh to maybe tell the LLM, hey like you passed the threshold, you should now refactor this file. Even if like okay the user ask you something. First refactor the file then implement what the user has asked you to. And I think like there's a lot more to do there. But yeah, it's somewhat of like this uh code quality agent that that's keep nudging the LLM at some points if it finds that it's past the first threshold of like hey like there's this code here and this

Rethinking Testing and Specs for AI Workflows

28:44 code here like do something refactor that

28:46 right yeah makes sense I think um a couple of questions about specs and tests so we um know we we talk a lot about specs here it's kind of tessel's uh uh kind of a claim for existence of you know, products coming soon. Uh, and uh, and you know, we I think in general there's also like growing appreciation in the in the world of AI development that you want to capture knowledge that's outside your code or summaries of it and then test those as guard rails. I guess how do you how have you used maybe tests for sure and maybe specs uh, as part of creation in B 44? People start with tests even, right? like how do you how do you think

29:30 tests? Uh I think just like like the way you guys think at TESL I think is like software is changing right

4 Highlight · Replacing Unit Tests with End-to-End Browser Agent Tests

29:40 so some of the paradigms that we've built uh throughout the years are not really relevant anymore uh some of them become like more relevant but even if like if you look at the testdriven development it will likely look like look very different so in the first few months of base 44 there were no unit tests. Um there were like very different tests.

30:08 Uh so a lot of the tests were an actual agent going into a browser opening up a local host like a local version of B 44 tries different features and the way that I'll write test would be like prompts saying like hey when a user first logs in with a new like and that's a first user make sure this popup exists. uh go into the like go into the homepage, write a prompt, uh run it, then uh you should see in in less than 3 minutes, you should see like this and that. And so a lot of the tests that I built early on inside B even for B 44 to keep velocity high but still maintain a quality piece of software or like end to end tests um that are not even like they're not written with code. It's like more high level tell an agent go into a browser and test it. Interesting. Is that your reason for that? Was that just sort of reality? You needed the end to end tests anyway and then so you might as well spare yourself the uh the need to uh to create the unit tests or uh or

31:11 is it sort of some fundamental like I don't think unit tests are right for it because I don't care about the implementation as much. So yeah, cuz implementation changes and so I was changing the code so much throughout the day that like keeping a set of unit test would have been more often a headache

31:29 than like uh that you constantly need to refactor and you constantly and so what you want to like at the end of the day what you want to make sure is that your code works and when when it doesn't that you can easily get to the like what doesn't work right that's some of the p some of like the reason behind unit test is like it's easier like to understand oh this unit fails so you know where even in the code is a problem that you're having cuz otherwise like okay just write as as many end to end flows and if those work then your your software does what what it should be doing um and so I think that's why a lot of like at the first few months when I was refactoring so much I was like I found this way of like doing end to end test that really is scalable almost as if you had like team of like manual QA engineers

32:20 that you could go into your software and change things. Obviously, if you want to scale and you want to work inside a team, unit tests are important. They're like they're they're explaining some of the things that that should happen with your software and especially when

32:34 when back end becomes like really uh large and complex. Um,

32:41 so and these are this way that you found to sort of run the end to end test. Was that also AI powered? Is that sort of browser based? Uh, hey find a button and press the button and such as opposed to

32:52 telling it whatever the dome ID and when you're absolutely and when you're changing the UI a lot and so on and it's more around the logic and AI agents running browsers nowadays are pretty good with the logic. So even if like

33:08 I remember like I remember UI testing used to look like uh you'd have like this um HTML selector like like a jQuery selector well to find a button then you change something the whole test would break and you spend like 20 30 40% of your time just refactoring the tests after you change the UI a lot

33:28 and so yeah I think I'm still wrapping my head around this. I'm not sure that we're doing a great job with like rethinking how uh things change as AI is writing more and more code.

33:41 Yeah. I think also part of it is like um part of like the reason why we haven't I haven't built a lot of like unit test starting on is is again AI does a really good job with also identifying if you tell it what the bug is like it will search and it will try and understand and you'll get really fast to like where does this happens and I think that's also part of the reason why I haven't invested a lot of time in unit test.

34:07 Yeah. Uh but I'm not sure this is like the right

34:10 I'm like I have stronger opinions on on other stuff. I'm not sure we've yet to correct uh testing uh how it looks like in this new new

34:22 and how uh how have you how do you think about specs or sort of I guess docs are the sort of the more core did you find uh that you got benefit from creating documentation in a more standard way uh I guess what uh what has been the

34:37 yeah um this is really interesting I think angle and base as I see also a lot of like the a lot of like base 44 users sometimes I see what they're doing is like they'll go and chat with chat GPD they'll build like some sort of like a pr or something like that or a spec of like what they're looking to build um and only then they'll upload it to base 44 because base 44 is slightly more uh tipping towards action I'll say so even if you say hey like let's shed repeat about the app that that we want to build and maybe we'll

35:16 yeah maybe we'll we'll add this stage before creating an app like if you want to just chat about it before and create some uh spec and then make sure that throughout time as you build your app and adapt it and whatever like the LLM constantly sees and validates that the spec is still like still happening in reality. Uh, I think that's also one of like the top requested features that I've yet to wrap my head around as to how to approach it is like have some sort of like a spec of what your app should be doing. And then even if you like when you ask the LLM to make it prettier or change the button or add functionality or whatever, it should constantly get back to the spec and make sure that it's not does not overrides or changes anything because obviously

36:04 as as mo as many people know, this is the biggest pain right now with VIP coding. It's like you ask it to do one thing or it might not entirely understand you and and it did it but messed up another thing or it didn't do what exactly what you you wanted and so yeah

36:21 again two places test and uh and specs that I feel like we could be

36:27 the horizon you know both both on base 44 as its own app and and in the apps created on top of it.

36:35 Yeah. Let me you you actually touched on something I wanted to ask which is about

Lean Teams and the Shift Toward Agentic Software

36:39 team members and so uh this has been sort of super interesting. You built them also you can zig and zag because you know you're just you and so the LLM changes you changed your opinion you feel like a thing you don't need to convince anybody else or align them. Uh now you know postacquisition

36:58 um I guess maybe first it's a question like how what do you anticipate will happen? And I anticipate you have a plan probably in terms of growing the team. Do you still think, hey, we're going to be three people, you know, we'll triple the size of the team or uh or do you think you're going to be 30? And then, you know, how much how much is the methodology that you've described viable when it's a team that or multiple teams that need to collaborate versus a solo developer? like code thesis is that uh for building great software now you need way smaller teams.

5 Highlight · Scaling Lean Teams with Broad Context and AI

37:35 It's not actually that like it's actually that if you're smaller you'll be like it will be easier because when you're smaller you have more context right I'd rather have someone that knows entirely the repository so that they can change multiple things at once. Um well the way I'm structuring the team right now so is is keeping very lean and efficient in terms of like team member for every I don't know million or two or3 dollars in in ARL um and then having those team members with as wide context as possible. So I don't want any more of like this. Hey, I built this part of the back end. Now I'm going to hand it over to the other person that will build the user interface. We'll hand it over back to build like a different thing. Oh, now we have an info problem. So we need the third guy. Um, and so I'm trying to build a team very small. All of them have like a lot of context. And the way that I'm trying to manage the tasks is

38:39 isolate as much as possible and like have every person to work almost like as an individual. So take like big chunks of your product, hand it over to this person. This person is going to work mostly alone. Um it's like I don't want I want to see very few team meetings of like sinking on something because like you can now again every person becomes like if you hire a 10x engineer nowadays there are thousandx engineers because

39:09 they can like throw as many AI coding agents as as as they want and it's not anymore about oh this this task is really big so I should be putting like four or five people on it because again it's not anymore about the amount code that every person writes like say you can write as much code as you want it to.

39:28 Yeah. It's

39:29 there's probably still a case for like

39:31 for pairs uh in in the sense at least for a single like someone goes on vacation, right? or

39:37 or leaves the company or such then one person sounds makes me like a little bit uncomfortable but uh but I get the point about tiny teams you know that's a

39:48 I agree and also like it's very hard to find people that are also they're awesome with back end but they also understand some design and they also understand some like front end concepts and so on but as much as I can I'm trying to like keep a small team and Then the way they operate is like divide and conquer.

40:10 Yeah. So, so and you anticipate them working in the same fashion give or take. Uh and the solution to that is is architecture. Uh and and just set up. Yeah.

40:22 Yeah. Which uh again is actually not new. It's actually you know the way that you would scale you know the Amazon sort of two pizza teams. When I think about how we build Tesla, it is about okay having software boundaries, having data model boundaries, and eventually even aiming to to allow timeline independence of being able to ship whenever it is that you ship. And all of those are never perfectly correct, but they are um they they are aspirational like you want to invest in ensuring those lines are are there and that makes sense. Um

40:55 yeah, I agree with

40:56 let's maybe be off. So we're kind of like tight on time here on it. Maybe we uh should we talk a little bit futures like where this like we talked a lot about sort of you know past and present and I think we talked about like near future. Um maybe I'll start with the big question of like what do you what do you envision developers being you know in in in one year three year five year horizons like what um what is still in the realm of a developer um you know what do you think just entirely goes away? Yeah, obviously I I measure it as like the percentage of software that could be built today with tools like base 44 and and other tools in the category. Um, and again I want to differentiate between the the cursor and cloud code of the world that are obviously targeting developers, semi-developers, uh, versus like the base 44s of the world that that are targeting like the everyday architect, lawyer, physician.

41:58 Yeah, they're expanding the definition of a developer, right? Know you're taking coding as literacy to to a different place. And it's not coding as literacy, it's software creation as literacy. it is about making it available to everybody.

42:11 Yes, absolutely. So, I think there obviously the percentage of of software that could be built uh is going to increase tremendously. Um, two places that I find that that really at least I'm putting a lot of focus on is on the enterprise side. Uh, so again, if I'm putting it on like a timeline, so coding has started building great websites. It was really fun to see that you can build a landing page, maybe some interaction, but great with front end.

42:41 Um, and then base 44 targeted a lot of like build a functional app like a project management tool, CRM, invoice management apps, stuff like that.

42:51 Um, seeing now more and more organizations adopt B 44 to build like internal tools, to build back office systems, to build like things that they used to like pay a lot for like custom software. Um and then so there's two vectors that we really need to get better at like as a category. One is the enterprise side of things like build enterprisegrade applications uh that could really transform the way organizations are being built. Every large organization has tons of software needs and I think like a small percentage of it is like customerf facing. Uh

43:30 but a lot of it is like think of an organization like I don't know Pepsi or something like that like how much software do they need internally to run this uh to this business and the more the marrier right the more that you build tools the more that you build automations uh the more that the business becomes more efficient

43:47 um so there's a lot that yeah

43:50 challenge like I don't actually want to challenge that I agree with it but I think there is a thesis that says um yes a lot of like the uh enterprise automation is a massive opportunity. Just think about how much grunt work happens and how much inefficiency happens that if you could just easily create software to create will make it go away. But there's there is a thesis that says uh well you wouldn't create applications you would just delegate those tasks to agents and so you wouldn't create code that that lives as an application the way we perceive it today.

44:24 You would more outsource it to AI. So that's the second thing which is um lately I've been telling the team that uh vibe coding is awesome obviously made me rich but uh it's currently great at building software the way it used to look pre20223 when chipd came out um it's still very hard to build a agentic applications um and I I think a lot of like the value in software and the latest like groundbreaking software and base 44 is a good example of that is going to become like aic software. Um and I think we'll find that it's not only chat and like connect tools there's like something to correct there. Uh you can see that in coding agents in the UIX and whatever it's like um there's some interaction but it's a different kind of software.

45:21 So the second thing that that uh base 44 is going to invest a whole lot in and we'll see a lot of like updates in the near future is helping everyone build agentic software. Uh an Agentic software could be a software like B 44. It could be that the CRM that you just fcoded now has an embedded agent that can research leads, can send you some updates before a meeting, can enrich some data. It can be that the support ticketing system that you've built internally for your SAS company will now have an agent that auto replies and get trained on like human responses and you'll be able to actually vibe code uh this whole application and so yeah I agree with you definitely I think there's like a combination of like things that like enterprise grade you need either way whether you're building a nice looking uh web app or an actual agentic web application. Uh but yeah the other thing is like taking VIP coding to the place where you can build great agentic

46:22 applications.

46:23 So with all of these advancements and all the capabilities that B 44 is building like what's your prediction about how long does it take till you can build a base 44 with B 44? Um that's a good question and it also has to do with like how like how much will be we will be able to crack this a gentic application thing.

46:51 Um, my guess is like a fully functional base 44 app with like payments and credits and like actually coding agents that are coding like websites inside and so on.

47:07 Uh, about six months.

47:09 Six months

47:09 maybe less. Yeah. I'm looking like I'm looking at sometimes it's like uh I'm looking at the state of where vibe coding and base 44 specifically was at six months ago when it was

47:23 terrible.

47:24 Yeah. And so I think six months maybe less. Uh definitely I would say not more than a year.

47:30 Yeah. Yeah. I mean it's a good it's it's a bold claim but it's a it's one that I can I can get behind. And I think I also think that uh it it not anybody could create a base 44 like you you need certain sort of skills and competences to be able to achieve it but maybe you can use it with those tools. Um and I guess in that context like what is uh

Moats and Advice in an AI-Commoditized World

47:54 the long-term differentiation you know for a platform like base 44 given this prediction

48:02 you know yesterday I I think yesterday or two days ago I tweeted about something that that was like insane to me where we changed like one line of code it's like change the string and we move the 400k uh workload flowed for like $400,000 from one LLM vendor to another and I was like where's the mo like this is insane cuz like you see those companies and they're really growing like nicely but where is this all headed if if everything becomes a commodity and maybe models at some point become a commodity so I think the model layer is in slightly more problematic way I wouldn't even I wouldn't actually call it problematic it's just it's very easy to switch so there's no real mode but the top players are just printing cash.

48:50 Yeah.

48:50 And so I think

48:51 it's hard to enter that group now and move between the group but it's harder to imagine someone I

48:57 entering the group now.

48:58 Yeah. But it's going to be it's going to be a very interesting um market because it's unlike uh the cloud uh let's say vendor. So obviously it's also a very hard uh uh ticket to get in but but it's also very hard to switch between clouds, right? It's very hard to take your entire setup from Microsoft Azure to AWS. This won't be the case between models because like when a new model comes out and it's slightly better, then for me it's like yeah, I'm going to spend like five minutes and change the and move like hundreds of thousands of dollars a month uh and probably in the future even more from one vendor to another. Um where is the moat? There's many places.

49:41 So one just being ahead, right? If you're four months ahead of the competition these days, it's it's very important, right? So, I I know Yeah,

49:51 I know that some of the some of B 44's competitors are going to come up with like a built-in back end and batteries included kind of like approach of like is seeing kind like what it does to base 44's users, but at that point we'll already be like further ahead. Um and so yeah, just velocity is the I think the number one um mode, but there's also brand distribution, community. I think B 44 is lucky to have the strongest community that I've seen. Uh it's like users are absolutely fantastic and they help each other. Um, and yeah, there's still some places where a unique product take that's hard to replicate um is insanely important. Uh so if you can like again for me and not to sound too cocky but like I was like okay there's this problem with building functional apps in vibe coding and for

50:53 building for like the nontechnical person I can envision how this experience should look like they should just type something they don't need to understand what the database is or whatever everything will be built and then translating that into how to implement that from a tech perspective uh and in a scalable day cuz like people build I think tens of thousands of apps a day uh nowadays and so how do you scale that and and hold this whole thing and the back end and whatever like how do you do that

51:23 there's still some technical mode

51:25 velocity like make good decisions and execute on them fast

51:29 yeah and and it's the same thing right yeah it's the same thing is if you make good decisions and great decisions from an architectural standpoint then your velocity will be

51:38 right

51:38 so I think that's a that's a big mode Yeah. Yeah. Yeah. It's good. Sounds like a a great kind of uh equal cry almost like you do have the brand, you do have the distribution. So, especially now within weeks and so it's not

51:54 um it's not an equal playing ground. Uh but it is uh more equal maybe than ever before uh as you've uh as you've demonstrated. Um, so I guess maybe just as a a final uh question here, what's the sort of the top advice you'd have for developers listening uh to this podcast like as they as they brace themselves to the sort of insanity that is engulfing us uh and change? What's what's sort of the top advice for developer today? Um the way I think the future is headed is that people who can jump between domains so at least understand a little bit between domain so that they can execute with AI agents uh things end to end will be more successful than the people who are currently very deep into something. Uh so there's like a great front end developers that understand the

52:55 ins and outs of of React. I think that won't be as valuable as people who can execute end to end again together with AI agents and have some understanding of front end great understanding of back end some understanding of of design some understanding of like UI and can take something either feature or build a product themselves and can lead that end to end. So my advice for for I think for developers and what I'm advising some of my friends is like take a step back go and build something end to end. It will teach you more about the other places that you haven't touched yet like product and design and and users and community and whatever. Uh depends on on where you're at and what type of developer uh you are. Um but take a step back try to build something uh because I think the future will belong to uh people who have some understanding cost domains um because then you'll have AI agents specializing and and deeper

53:57 understanding of syntax

53:59 is not an advantage anymore like those agents will know the LLMs will know way better than us what's the latest and greatest packages how to use them what's the syntax and so on

54:10 right yeah super super interesting. You know, basically like elevate yourself up uh the the list and you know we talk about you need to either move up the product manager route of understand product better or move up the architect route of sort of understand sort of system architecture but either way you have to broaden uh the perspective

54:29 more uh this was excellent. Thanks a lot for coming on to the show. Massive congrats on on the incredible journey which I understand is just beginning. Still a lot of work ahead uh which I look forward to to following. But thanks uh thanks for coming here and sharing all these insights.

54:45 Thank you guys. This has been awesome.

54:47 Uh and thanks everyone for tuning in and I hope you join us for the next one.