Speaker 1: Hello everybody, Welcome to another exciting episode of JavaScript Jobber.
Speaker 1: I am Steve Edwards, the host with the face for
Speaker 1: radio and the voice for being a mine. But I'm
Speaker 1: still your host. I am flying solo today on the
Speaker 1: panel Checkscott an anniversary, who knows about AJ and Dan
Speaker 1: Busy lives Anyway, I am here with Gilad Shoham. I
Speaker 1: believe I said that right, right, yes, hopefully right? All right.
Speaker 1: Gilad is coming to us from Israel, and we are
Speaker 1: here to talk about AI and using AI to generate
Speaker 1: enterprise infrastructure, I believe. So before we get started into
Speaker 1: the topic, why don't you tell us a little bit
Speaker 1: about yourself, Gilaud, your dev history and anything else you
Speaker 1: want to tell us.
Speaker 2: Sure. So, my name is Gilad Trump. I'm vipop engineering
Speaker 2: at pitt Cloud, and apart from this, I'm also like
Speaker 2: a mentor for start ups, for developers, for fiam deaders,
Speaker 2: and also from doing some engine investments in startups. I
Speaker 2: also have like a brand with a blog and podcast,
Speaker 2: a YouTube channel about small homes in Hebrew and love coding.
Speaker 2: Usually that's that's what I'm doing, No making transforming coffee
Speaker 2: into code.
Speaker 1: What do you say coffee in the code.
Speaker 2: Yeah, but but usually for me it's a bit different.
Speaker 2: Like during the day, I'm transforming coffee into code, and
Speaker 2: at night I'm transforming code into coffee. So I'm connecting
Speaker 2: my writing codes that build me a coffee.
Speaker 1: That's great, Mede, Yeah, I prefer my caffeine in cold form.
Speaker 1: But yeah, I get what you need, get what you
Speaker 1: mean for sure. Okay, So tell us about uh bit.
Speaker 1: What is Bit's purposes? Dot there I think it did
Speaker 1: dot cloud.
Speaker 2: Right, yeah, yeah, yeah, so biot cloud. It's like the
Speaker 2: company we have, like a big open source called bit.
Speaker 2: The website for the open source is bit oft dev,
Speaker 2: and we are building a platform for composable software. We
Speaker 2: help organizations to improve their develocity DEV quality by helping
Speaker 2: them to compose applications from independent features and components, and
Speaker 2: help them to manage and share and collaborate these features
Speaker 2: and components between projects, between teams. By increasing reuse and
Speaker 2: collaboration and discovery of existing code, we are improving the
Speaker 2: quality and velocity. And now we are also building AI
Speaker 2: on top of this approach that we will discuss in
Speaker 2: this episode.
Speaker 1: Okay, so a lot of that's pretty high level description
Speaker 1: of what you're doing sounds something I would see in
Speaker 1: a job description or company description. Can you give a
Speaker 1: little more detail or maybe an example of a company
Speaker 1: where or where you would use your UH, your tools,
Speaker 1: your big tools, and then when you talk about AI
Speaker 1: and how AI will on top of those.
Speaker 2: Yes, sure so. So usually organizations come to us when
Speaker 2: they want to UH to increase, increase or improve their
Speaker 2: dev DEIR methodology and the environments. We we help them
Speaker 2: to componentize their their code base and then help them
Speaker 2: to share and reuse components. For example, the popular use
Speaker 2: case is sharing design systems as individual components. So once
Speaker 2: you have the ability to easily create individual components and
Speaker 2: install them in different places and see history for each
Speaker 2: component individually, plus a way to find these components too,
Speaker 2: to experience disse components, it helps them to to improve
Speaker 2: the reusability and collaboration. And we also have another project,
Speaker 2: another open source we which we all start integrating into
Speaker 2: large organizations. It's called it called Harmony. You can find
Speaker 2: it in our homepages. One of the most in the
Speaker 2: initial pages and how many is the project that helped
Speaker 2: organization to build features that are individual. It uses principles
Speaker 2: like in version of control, so so the platform team
Speaker 2: is building the shell application, and each product team can
Speaker 2: integrate itself to the platform. So this reduced the buttonneck
Speaker 2: from the platform team. It helps the dev experience for
Speaker 2: each team. So the so the platform team only provides
Speaker 2: APIs what we call usually like slots for the other
Speaker 2: teams to integrate into them. For example, this works both
Speaker 2: influnted and back end. For example, let's say you have
Speaker 2: like users features or users team. They will add a
Speaker 2: logo in the like an avatar on the on the menubal,
Speaker 2: they will register an icon. They will register a route
Speaker 2: in the front end that is Slash a sign up
Speaker 2: or Slash login or something like this. They will register
Speaker 2: graph q l APIs or rest APIs on the back end,
Speaker 2: and that's the way each feature is integrated itself to
Speaker 2: the platform and can provide APIs for other features to
Speaker 2: integrate into it. So for example, if I have like
Speaker 2: an e commerce product and they have like the the
Speaker 2: product team products teams that render a grade of products,
Speaker 2: they grade of products and they can provide an API
Speaker 2: for the for the billing team to add the d
Speaker 2: to CUD button to each cloud. So this button is
Speaker 2: now responsibility of the building team. And it's integrated into
Speaker 2: the product team and not the opposite. And this helps
Speaker 2: to increase velocity and increase like to scan the development
Speaker 2: because now everything is standardized how you connect yourself to
Speaker 2: the platform. And it also helped with the deployment and
Speaker 2: making funding and back end as one atomic entity that
Speaker 2: is part of it, so you have like one entity.
Speaker 2: It's the feature that it's like a manifest or like
Speaker 2: the API of your feature. And this contains both the
Speaker 2: FUNTA and the back end, so now you can deploy
Speaker 2: funding and back end together or roll back FUNTA and
Speaker 2: backen together, which helped reduce issues on run time's derived
Speaker 2: from inconsistency between Bacon and FONTA and or between versions
Speaker 2: of of FUNTA and backen or different features. So that's
Speaker 2: like a very high level and and on top of it,
Speaker 2: for each component, we provide a set of tools like
Speaker 2: discovery portals where you can see the dogs, the rendering,
Speaker 2: the test results, the dependency graph, and we do version
Speaker 2: management for it. We are kind of competing with Git
Speaker 2: and gitub. Okay, we don't use Git and geitub internally
Speaker 2: in our company because we are doing version management for
Speaker 2: components and we have the entire features of the entire
Speaker 2: life cycle of each component, so we don't need get
Speaker 2: and git ub. Usually we just bring the components we
Speaker 2: want to change into a workspace, edit them, and then
Speaker 2: saw away this workspace. And then on the cloud we
Speaker 2: have like the third we have c i FO components,
Speaker 2: which is something unique. It's propagating ci which you can
Speaker 2: change one component. Let's say a button. We will run
Speaker 2: the test for this button, and then we'll run the
Speaker 2: test of the card that uses this button with the
Speaker 2: virtual version of the button, and then the test for
Speaker 2: grid with a virtual version of the card with the
Speaker 2: virtual version of the button. So we can propagate the
Speaker 2: updates and test all the updates cause the graph in
Speaker 2: parallel and give you, like the insights about what happens
Speaker 2: with you changing the button. Now it affects any component,
Speaker 2: any dependent in the graph, so we.
Speaker 1: Have Okay, so that's that's a lot to unpack.
Speaker 2: Yeah, a short version of the of it.
Speaker 1: Okay, so let's go back. So let's go back. And
Speaker 1: then in terms of you know, being the low level developer,
Speaker 1: you know who is thinking about tools, is this length
Speaker 1: with the agnostic I mean, can your infrastructure work with
Speaker 1: any number of languages, say, for instance, Larra Belle, Ruby
Speaker 1: node on the back end, View Angular, spelled React on
Speaker 1: the front end. Are there specific maybe languages or frameworks
Speaker 1: that you don't support or work with. How does that work?
Speaker 2: Okay, good, great question. So the core of bit is
Speaker 2: language agnostic. However, there are many places which are language specific.
Speaker 2: For example, we know to recognize dependencies automatically from you
Speaker 2: est from your source code, or we know to install
Speaker 2: dependencies automatically, which are of course language specific. At the moment,
Speaker 2: we are supporting all JavaScript types slip ecosystem, which means
Speaker 2: no JS on the back end, JavaScript not typescript on
Speaker 2: the front end, all the major frameworks React, View, Angular,
Speaker 2: web components, frameworks like cleat and stuff like this, and
Speaker 2: of course all the other stuff of the web like
Speaker 2: htmils is this and stuff like this, sas says everything.
Speaker 2: We do have plans to support more languages, but not
Speaker 2: in the near future. I don't know when will it happen,
Speaker 2: So I cannot commit on as languages with the moment.
Speaker 1: Okay, so you know, so on the back end, is
Speaker 1: it just no then? Is that correct?
Speaker 2: Yes?
Speaker 1: Okay? So there though Ruby, any any PHP based languages.
Speaker 2: That's not supported, not at the moment.
Speaker 1: No, okay, all right, that's good to know. Okay, So
Speaker 1: that makes it a little more easier to understand in
Speaker 1: terms of components, because most any JavaScript framework structure on
Speaker 1: the front end is going to have support components by themselves, right,
Speaker 1: or your components different than when you talk about components
Speaker 1: that you're creating a component and that that's different than
Speaker 1: say a view single file component or a reacting component.
Speaker 2: Is that correct? Yes and no. So so it is
Speaker 2: not touching your source code. So the act component of
Speaker 2: your component is completely the same with or without bit
Speaker 2: bit component is like it's like a wrapper around it
Speaker 2: that manage all the meta data of this component. So
Speaker 2: let's say you have the act component, I don't know,
Speaker 2: a button, a card, whatever. The bit component of this
Speaker 2: card will have different aspects of this component, so fist,
Speaker 2: it will have the source files okay, maybe one file,
Speaker 2: maybe more than one file. It will have artifacts of
Speaker 2: this component for example the compiled files or the band
Speaker 2: or the package the out that you install from NPM.
Speaker 2: It's part of this component as well. It will have
Speaker 2: the dependency graphs, so all of your dependencies, all the
Speaker 2: three of dependencies you have it's also part of the
Speaker 2: bit component and also as of meta data like description labels,
Speaker 2: how to compile this component like to use typeestip you
Speaker 2: use Babel, or which framework you used to test it
Speaker 2: like jest or moca or v test and which configuration.
Speaker 2: So all of this meta data is also part of
Speaker 2: this component. And we take all of this meta data
Speaker 2: with the dependency graph, the source falde, the artifact, and
Speaker 2: we version this so you have a version of component
Speaker 2: with all this meta data and each one is individual components.
Speaker 1: Okay, so what is what languages is this BIT used
Speaker 1: to do all this? What's under the bit codebase? Is
Speaker 1: it c is it C plus plus? Is it JavaScript?
Speaker 1: Is it node? Is it what I would assume it's
Speaker 1: something like node?
Speaker 2: Right, yes, correct, So it's it's node type script. And
Speaker 2: we build everything in bit using bit and how many
Speaker 2: we are doing radical dog footing. We are the largest
Speaker 2: user of the bit ecosystem. We build everything with bit
Speaker 2: components now cutting conels both like front end and back end,
Speaker 2: and also the c l I. Okay, the c l
Speaker 2: I as well. The c l is open source. It's
Speaker 2: also built with BIT and with Harmony. So if you
Speaker 2: look for example on the main file of the bit
Speaker 2: c l I. You'll just see the Harmony manifest which
Speaker 2: which mentioned which features uh the bitt l I have.
Speaker 2: And if you want your own version of the bt I,
Speaker 2: you can just remove lines from there and you get
Speaker 2: another composition of the bit, the bit c l I.
Speaker 2: And that's why everything is also extensible, so you can
Speaker 2: the same poet you can apply on BIT. So if
Speaker 2: you want a new commanding bit, you can register a
Speaker 2: new command. If you want new tab in the U
Speaker 2: I in the front end, you can register a tab
Speaker 2: for yourself in in our UI, same for our backend.
Speaker 2: So everything is built with bit internally.
Speaker 1: Okay, Now the other thing I picked my interest was
Speaker 1: you talked about get and get hub and not needing them.
Speaker 1: So so in terms of versioning, the different your bit
Speaker 1: components and all that, do you have like your own
Speaker 1: version of you get written, or there's get under the
Speaker 1: hood you just don't need getthub or do you just
Speaker 1: use your own your eye or how how does that work?
Speaker 2: Okay? So there is no GIT under the hood at all,
Speaker 2: No GIT, no geit ub, nothing related to geit except
Speaker 2: from some general ideas about like the how like the
Speaker 2: distributed then database, but we build everything from scratch and
Speaker 2: each component is like I said, it's like you can
Speaker 2: think about each component is kind of like a mini repository, okay,
Speaker 2: with all the stuff that we mentioned before, and it
Speaker 2: it allow you to edit any component or set of
Speaker 2: components from any fold there. So if you are now
Speaker 2: working on a feature, let's say a head there, you're
Speaker 2: bringing the components you need for these changes in the
Speaker 2: head or you will bring logo, you'll bring the the
Speaker 2: search box, you will bring menu items I don't know,
Speaker 2: and you can change them, but you don't need the
Speaker 2: code of the foot or the code of the products.
Speaker 2: If you're working on a header, so you bring set
Speaker 2: of components, you put them on what we called a lane.
Speaker 2: A lane is kind of similar to git brench in
Speaker 2: some sense, but it's like cross components, so you can
Speaker 2: think about it like a cross rip a branch kind of.
Speaker 2: And then you make a change request in our in
Speaker 2: our cloud platform, and there you can do a review
Speaker 2: process which is similar to GitHub but a bit more
Speaker 2: advanced because on gitub you're only reviewing source code changes.
Speaker 2: And then bit because we have all of this, you
Speaker 2: can review and we can give you side by side
Speaker 2: the source code of course, and also the rendered examples,
Speaker 2: so you can see how the button, how the example
Speaker 2: of the button renders before and after the docommentation side
Speaker 2: by side, the testing side by side, the dependencies side
Speaker 2: by side, and then you can review all of it,
Speaker 2: then merge it and we have we implement this branching mechanism,
Speaker 2: merge mechanism, conflict resolution everything from sketch.
Speaker 1: Okay, So then if I'm it sounds like this is
Speaker 1: is it almost a no code solution in terms of
Speaker 1: a non coder can create these bit components to place wherever?
Speaker 1: Or is this a is still a developer tool? You
Speaker 1: said something about using an example of the building department.
Speaker 1: Having worked in building departments, usually there's not coders in there,
Speaker 1: so they need some sort of drag and drop tool.
Speaker 1: Is it still just a developer tool for managing components
Speaker 1: and then you can, you know, put it as needed
Speaker 1: or is it like a no code tool that a
Speaker 1: non developer to use.
Speaker 2: Okay, so it's it's completely a tool for developers. It's
Speaker 2: not a no code tool at all. It's like regular codes.
Speaker 2: It's written by developers and we help them just to
Speaker 2: wiring everything, sharing it so for example, creating one other
Speaker 2: packages manually, it's a long process. And to try to
Speaker 2: change someone else code. If you're using like a design
Speaker 2: system component from some other team and you want to
Speaker 2: change it, it's a complicated process. If you want to
Speaker 2: search code search component in your organization, you have no
Speaker 2: Google inside your organization, it's complicated. So we are helping
Speaker 2: the developers to manage all these complexities and help them
Speaker 2: not only with tech but also with methodologies. We help
Speaker 2: you to get insight about if you're doing stuff right
Speaker 2: and help to form not only with tech, like how
Speaker 2: stuff should be formulated in the organization, for example, the
Speaker 2: world component. Is this something related to R and D
Speaker 2: to product to designer? This is a question, okay, Like
Speaker 2: how you name stuff, how you put boundaries and split
Speaker 2: the organization into teams, and we help you to standardize
Speaker 2: this entire process and make it effective.
Speaker 1: Okay, So this all managed from you mentioned a cli?
Speaker 1: Is this all managed from a CLI? Is or sort
Speaker 1: of a UI for managing components and the tendencies? Or
Speaker 1: is it all done from the from the command line?
Speaker 2: So we have a CLI that you can do all
Speaker 2: the base operations. We also have like a vis Code extension,
Speaker 2: so we don't need the cl I if you don't
Speaker 2: want to mess with the CLI. Similar to it's similar
Speaker 2: to like the GIT extension for viscode. We even like
Speaker 2: using the same tubs on the VS code. So if
Speaker 2: you go to the version control tabs that you use
Speaker 2: for Git, you will see bit components for example, and
Speaker 2: you will see not only code differences, you will see
Speaker 2: dependencies differences. We can put them on inside viscode side
Speaker 2: by side for example. So we have the c alliance
Speaker 2: and we have the cloud where we host your component,
Speaker 2: and then you can see for each component, you can
Speaker 2: see the documentation. You can see example and how it's rendered.
Speaker 2: If it's a UI component, you can see the test.
Speaker 2: You can see a graph visual graph of all your
Speaker 2: dependencies and dependence you know, filter it by teams or
Speaker 2: by levels or stuff like this.
Speaker 1: Okay, now you mentioned your vs code extension. Do you
Speaker 1: have extensions for other tools like in Talents, heads, PhD.
Speaker 2: Okay, at the moment, it's on our roadmap. But we
Speaker 2: are a small startup working on this for like almost
Speaker 2: ten years right now. But since we're still a small team,
Speaker 2: then right now we have god.
Speaker 1: Only Okay, all right, I know as an intelligent user,
Speaker 1: I can say we're almost always discriminated against the vs
Speaker 1: code users that always get the first plug ins and stuff.
Speaker 1: But that's okay, we're used to it.
Speaker 2: We do have a feature which called cloud Walkspace, which
Speaker 2: allow you to edit any component from the cloud. It's
Speaker 2: like opening like a viscode on the cloud, but this
Speaker 2: is like a real vis code, so you can have
Speaker 2: you have like a docal container behind it, so you
Speaker 2: can develop like no gs or beacon stuff from the
Speaker 2: browser as well. But it's also like a viscode on
Speaker 2: the browser. So if you used to intelligence or something
Speaker 2: like as of shortcuts and you need to set it up.
Speaker 1: Okay, so let's say so, then so you've got your
Speaker 1: bit component creer, you know of a header or a
Speaker 1: button or something like that that you're using. I don't
Speaker 1: know if this is something you can go into detail about,
Speaker 1: but how is that implemented into my actual view app
Speaker 1: or my React app or some on is this is
Speaker 1: like an important statement you know in a component imported this,
Speaker 1: but you're importing your bit component that and has everything,
Speaker 1: or how is that implemented in your application?
Speaker 2: So so behind the scene, bit can bit transforms any
Speaker 2: component you have into a regular NPM package, so you
Speaker 2: can just install it even even without installing BIT. You
Speaker 2: can just install it with NPM like any other package
Speaker 2: from NPMGS. And if you have and if you create
Speaker 2: a work special, BIT works best. You can bring all
Speaker 2: the components of any components you want and BIT will
Speaker 2: know to kind of sim link it to the package
Speaker 2: name behind the scene, so you have like you can
Speaker 2: change the source code and it will reflect into your
Speaker 2: consumer components that uses it. From the node models similar
Speaker 2: to like monoiple tools like like NX or something like this.
Speaker 2: BIT will do the the wiring from the node models
Speaker 2: to your source code. If you're on an editing mode, okay.
Speaker 1: But you're not using the main NPM repository right, this
Speaker 1: is using your own BIT repository. You're just using the
Speaker 1: NPM tool.
Speaker 2: So we have we have like our registry on the
Speaker 2: cloud that you can use or you can you can
Speaker 2: use NPMGS or artifactory. We have guides for it. We
Speaker 2: don't care if you're hosting the packages on our register
Speaker 2: or other registry. So you can definitely do this. And
Speaker 2: behind the scene for client and installation and everything, we're
Speaker 2: using pm PM. Sultan, the creator of pn PM, is
Speaker 2: part of the company, is full time employee in Beat
Speaker 2: and so we are kind of maintaining pn PM as
Speaker 2: well as a company. So we have Sultan for pn PM,
Speaker 2: and we have jj who is part of the View
Speaker 2: gs code team working on all the view integration. And
Speaker 2: we have Olivier which was part of the Angular core
Speaker 2: team working on all the Angular integration. So we have
Speaker 2: like kind of nice team here.
Speaker 1: Wow heavy hitters. Okay, excuse me. Now in terms of
Speaker 1: hosting before we move into the AI, so is this
Speaker 1: something you can self host if you want to sell
Speaker 1: host bit or you can host in the bit cloud.
Speaker 2: Is that correct? So we have like the SaaS product
Speaker 2: and you can we also have we offer different different
Speaker 2: ways to host, like the remote server, so either our
Speaker 2: SaaS platform, we have a way to manage a dedicated
Speaker 2: server for you as a company, and we have like
Speaker 2: a full on prem solution. And also we have like
Speaker 2: part of our open source is a simplified version of
Speaker 2: the austing platform, so you can even do sell host
Speaker 2: without bit cloud and host like remote bit server so
Speaker 2: you can export components into it and see them. But
Speaker 2: this will not have like many features like the AI,
Speaker 2: the cloud walk space, the CI that we described before,
Speaker 2: permission stuff like all the enterprise feature like SSL permissions
Speaker 2: or not part of the open source. But there are
Speaker 2: companies we are doing sellf host and and it's enough
Speaker 2: for them.
Speaker 1: Okay, all right, So that's the platform as a whole.
Speaker 1: So let's talk about AI. So if I understand correctly,
Speaker 1: So you've got your base platform that we just talked about,
Speaker 1: that's installed. So now you're adding AI on top of
Speaker 1: that or integrating AI into it as a sort of
Speaker 1: a second phase.
Speaker 2: Is that correct? Yes? So basically, if you look on
Speaker 2: all thee itols today for developers, okay, o AI. In
Speaker 2: this context of AI FO code generation. I'm not talking
Speaker 2: about image generation, video generation, but on e itols today
Speaker 2: are are splitting into kind of let's say, two families. Okay,
Speaker 2: if you think about like let's talk kind of the child,
Speaker 2: the simple child. And I know this is like voice only,
Speaker 2: but it's it's an easy one which we have like
Speaker 2: let's say on the y axis, we have the code size. Okay,
Speaker 2: small code base or luge code base in this large
Speaker 2: here I'm talking about like not not Google large, Okay,
Speaker 2: even like a small startup like three four developers working
Speaker 2: for year. It's kind of large like company code base.
Speaker 2: And on the X axis you have like the complexity
Speaker 2: of the task you ask from the AI from a
Speaker 2: small snippet like a function to build me a real
Speaker 2: feature on the right side, so only I todays today
Speaker 2: are either good in it on one of these axes,
Speaker 2: so you can either use tools like love a Bell,
Speaker 2: Bold wind self many of them. Probably during other sessions
Speaker 2: there will be a new one which can help you
Speaker 2: build a full project from a prompt. If it's like
Speaker 2: you know, a poc a side project you build in
Speaker 2: the weekend, and the I would do pretty good job
Speaker 2: building this initial version for you for a hobby project.
Speaker 2: On the other side, we have tools that are more
Speaker 2: for organization or existing code bases, which are help you
Speaker 2: like caresee or get up co pilot which help you
Speaker 2: to do some autocomplete or snippets for existing code base,
Speaker 2: which is great, okay exist in case productivity. It saved
Speaker 2: time from you know, googling and copy paste from stack overflow,
Speaker 2: which is amazing. But what we really want to do
Speaker 2: and no way I can do today is build real
Speaker 2: features for real code based for organization code based. If
Speaker 2: you're trying to take now new product, no matter which
Speaker 2: company you're working on, and you will ask a co
Speaker 2: pilot adding analytics features to my product, it will not
Speaker 2: work at all, Like you cannot. There is no even
Speaker 2: point to try it because it's not there yet. And
Speaker 2: the reason it's not there yet it's because we are
Speaker 2: looking at AI and we are asking AI. We are
Speaker 2: using using AI in the wrong way, not using by
Speaker 2: the end user, using by the AI developers, like the
Speaker 2: people who develop these tools. We're doing it, I think
Speaker 2: in the wrong way. We are trying to teach the
Speaker 2: AI to read code and ask it to write code.
Speaker 2: It's like you know, it's like you know to read books,
Speaker 2: but do you know to write a best seller? Best seller?
Speaker 2: Probably no, It's different stuff, and we think that you
Speaker 2: need to change. We need to change. And in steath
Speaker 2: asking the I to write code, we need to ask
Speaker 2: the I to play lego. Okay, not just a general lego.
Speaker 2: We need to play your lego, your lego bricks. It
Speaker 2: needs to do composition. In stealth generation, generation of code
Speaker 2: is just the last step in the process of building software. Right,
Speaker 2: we are not getting paid by writing lines of code rights,
Speaker 2: getting more money if he write small lines of code,
Speaker 2: even the opposite. Usually we are our task is not
Speaker 2: to build code to write code. Our task is to
Speaker 2: build features for our software. And we and with AI
Speaker 2: we kind of moving backward. We are asking you to
Speaker 2: just write code every time from a clean slate. So
Speaker 2: what happens is that the E is duplicating God again
Speaker 2: and again. You ask it for something today, it will
Speaker 2: generate a button. Tomorrow, you ask something else, it will
Speaker 2: generate another button, and the day after. So if you
Speaker 2: do it for some time, you will get such inflation
Speaker 2: in a code base that you cannot maintain it anymore
Speaker 2: as a human developers, because it will go from I
Speaker 2: don't know ten times lines of code to a million
Speaker 2: lines of code if you just do it for a
Speaker 2: month with few developers. And this is one of the
Speaker 2: major blockers from really making a I use the BELL
Speaker 2: for organizations enterprises because of this, and and what we
Speaker 2: are doing is we are changing it from the base.
Speaker 2: We are giving the AI your dependency graph. Like I said,
Speaker 2: we have big components, we have the graph, we have
Speaker 2: the relationship in a structured way, and we ask the AI.
Speaker 2: When you ask the OURI to build a feature. His
Speaker 2: task internally is to see and which nodes in the
Speaker 2: graph he needs to add, or to modify or to
Speaker 2: reuse in order to implement this feature. So it's all
Speaker 2: the time work and prioritizing reuse other than generation. Okay.
Speaker 2: So for example, if we take like an example flow
Speaker 2: of how it looks like text, a U ask for
Speaker 2: AI to generate a header. I need a header, a
Speaker 2: new header for my company what it What will happen
Speaker 2: is that I will go to the graph search for header.
Speaker 2: It will not find any header. It will. We will
Speaker 2: ask the I to generate a potential dependency graph of
Speaker 2: header okay, stuff like logo, avatar, search box, menu okay,
Speaker 2: and then the I will reclusively do the same. It
Speaker 2: will go and search for logo if it found it,
Speaker 2: it will use it. If it found it and it
Speaker 2: needs modification like a new API to be in the
Speaker 2: context of header, it will add a new API to
Speaker 2: the existing logo or to existing search box. If it
Speaker 2: cannot find it, let's say it didn't find search box,
Speaker 2: it will again build a virtual graph of search box.
Speaker 2: Will understand that search box is built from I don't
Speaker 2: know an input and the button, and then it will
Speaker 2: search for input and a button a new company and
Speaker 2: will use them. Once you use them or generate them,
Speaker 2: it will move up one level above. And now we
Speaker 2: can generate the search box from the input and the button,
Speaker 2: and then after we get all the dependencies of the header,
Speaker 2: it will generate the header from all of this. And
Speaker 2: this this concept implement few very important principles in order
Speaker 2: to make AI work for enterprises. Okay, so.
Speaker 1: Okay, So let's step back for a minute. So I
Speaker 1: think I understand what you're saying in that. You know,
Speaker 1: even for a developer coming into a new application, you
Speaker 1: can't just say, okay, they one, okay, go write this
Speaker 1: feature without understanding the underlying application.
Speaker 2: Right.
Speaker 1: You got to know how it's built, how it's worked.
Speaker 1: There's you can have a view component, but you could
Speaker 1: have a bazillion different ways that your view component is
Speaker 1: is written. Right, you need to know how your app
Speaker 1: uses it, how your company uses it. So that leads
Speaker 1: me to this question, does does bit have to be
Speaker 1: implemented from the beginning of your application? In other words,
Speaker 1: could I have a large view application that uses a
Speaker 1: note on the back end. It's been up and running
Speaker 1: for a while, and then I can I implement BIT
Speaker 1: on top of that? Will that work or do BIT
Speaker 1: need to be part of the structure, part of the
Speaker 1: process from the very beginning in order for it to
Speaker 1: work efficiently.
Speaker 2: Okay, so of course if you already have BIT components,
Speaker 2: it will be much easier for the I to to
Speaker 2: do this because it can finally reuse what you have. Unfortunately,
Speaker 2: most organizations have large code bases which don't use BIT
Speaker 2: at the moment because they started a long time ago whatever.
Speaker 2: So so usually what we see is like a kind
Speaker 2: of a graduate graduate programs. So you ask AI to
Speaker 2: build the new fictionals tomorrow, and as part of it,
Speaker 2: the AI will create reusable components. Because the II will
Speaker 2: create like, it will not just put terms of code
Speaker 2: that implement an analytics stashboard. It if you ask it
Speaker 2: for analytics stashboard, it will create components for a line chart,
Speaker 2: and components for bou ch out, and components for card
Speaker 2: that render a child and component for grid of card.
Speaker 2: You will get like, I don't know, fifty components as
Speaker 2: a result of this prompt, and these components are reusable components.
Speaker 2: So now you can take these components and install them
Speaker 2: on your existing code base, and then you can start
Speaker 2: removing like you not componentize code base, and you can
Speaker 2: like modernize its architecture. You are always thinking about how
Speaker 2: to architecture, how to architect the features and the relationship
Speaker 2: between the components. And then you can also use this
Speaker 2: AI output to to kind of like eating the legacy
Speaker 2: piece by piece. Tomorrow you will have another feature you
Speaker 2: will get It will recognize the fifty components for yesterday,
Speaker 2: it will generate twenty new ones, and then you can
Speaker 2: use them in the legacy. So after some time, your
Speaker 2: existing codebase will become will become modular. Okay, So even
Speaker 2: regardless of the AI. Okay, even if you at this
Speaker 2: point you're just not using the AI anymore, your code
Speaker 2: base is now much more modular and much more clear
Speaker 2: to understand, much more clear and easy to extend and
Speaker 2: maintain because the clear components and boundaries that composing your application.
Speaker 1: Okay. So I so if I'm an existing large enterprise application,
Speaker 1: right and I bring in in it, I've been around
Speaker 1: for two or three years, ten years, whatever, Right, So
Speaker 1: I'm going to implement bits. So that's a manual process
Speaker 1: to go through and GA rate all your bit components.
Speaker 1: It's not something that did this automatically, right, You need
Speaker 1: to go, okay, I need to create a bad component
Speaker 1: for this, and a bit component for this and a
Speaker 1: bit component for this.
Speaker 2: Is that right? Yes, So we we know to help organizations,
Speaker 2: especially loge organizations, to do this process with us together
Speaker 2: and help them to like better like internal tools to
Speaker 2: kind of spitting it up, not in THEI tools at
Speaker 2: the moment they're doing it, but for example, a bit
Speaker 2: note to take like a folder which like twenty subfolders
Speaker 2: and in one line can make them twenty components. Okay,
Speaker 2: So of course it depends on how you existing products
Speaker 2: is structured at the moment, but you can do this migration.
Speaker 2: It's not that long to do sometimes, and I believe
Speaker 2: soon we will start working on some AI features that
Speaker 2: will help you take existing code based and kind of
Speaker 2: componentize it. This is something that we don't yet provide
Speaker 2: at the moment, but we do help and we do
Speaker 2: this process of componentizing projects with many organizations, very loud organizations,
Speaker 2: even before AI starts and AI going to the mixed
Speaker 2: because there is a lot of value of doing it
Speaker 2: regardless of AI. So you're already doing it for many organizations.
Speaker 1: Yeah, that would that considering that you know, like you said,
Speaker 1: you have to build a structure from the ground up,
Speaker 1: it would seem like that would be the primary benefit
Speaker 1: of AI is to be able to componentize your existing
Speaker 1: application right, so that you have bit components right, and
Speaker 1: then from there, once it's componentized and AI has that
Speaker 1: information stored, then you can use it to start generating
Speaker 1: new features because it has the knowledge of your code
Speaker 1: base right exactly.
Speaker 2: Then if you start from stretch now with the II
Speaker 2: that knows to build correct architecture, then you're kind of
Speaker 2: flipping the equition. So if you're using most tools of
Speaker 2: the I today, you will get like the inflation effected
Speaker 2: we discussed, like, you'll get duplications again and again. You'll
Speaker 2: get after a week, you will have fifty buttons. What
Speaker 2: will happen with with our AI is that you're building
Speaker 2: these lego pieces again and again. So the I in
Speaker 2: a week from now will be much more powerful because
Speaker 2: you have already a week like kind of compounding effect
Speaker 2: like a Fibonacci. The I today is equal TODAI yesterday
Speaker 2: plus d I two days ago because it uses the
Speaker 2: components from yesterday and two days ago. So now it
Speaker 2: can build better feature and faster because it's already had
Speaker 2: the lego bricks. So like like as a human developer, Okay,
Speaker 2: if you have a good building blocks the human developers
Speaker 2: and you need to build a new feature, you will
Speaker 2: did quickly and the II will do the same. It's
Speaker 2: not only about building, it's also about like the quality.
Speaker 2: So for example AI today is one of the main
Speaker 2: issues is the code quality. Like a I needs to
Speaker 2: write test, but you know it puts like you ask
Speaker 2: for a feature, it wrote you ten like thousand lines
Speaker 2: of code and you can test it. It's it's how
Speaker 2: task for human also for AI. But if you take
Speaker 2: this and break it into fifty components, each one is small,
Speaker 2: it's focused, it's reusable, and then you ask the I
Speaker 2: to build test for each one of these, it will
Speaker 2: do much better job because it's much easier for human
Speaker 2: and for AI to write test for a small components.
Speaker 2: Then you when you combine this also with like the
Speaker 2: bit infrastructures and the bit CI which knows to add
Speaker 2: meta data and to standardize this built pipeline for each
Speaker 2: component individually, then eventually what you get. And this is
Speaker 2: not fully fully implemented at the moment like partially yeah,
Speaker 2: but will be soon. Think about this today you are
Speaker 2: getting code from there. You asked, you get pumped. I
Speaker 2: give you tons of code. Now what you're doing, okay,
Speaker 2: Like after the l lamp out, you have like a
Speaker 2: very long manual process of integration. You need to rename it,
Speaker 2: you need to put it and move stuff around, and
Speaker 2: then you need to start review it and start testing it.
Speaker 2: You need to make I don't know, a pull request,
Speaker 2: so it depends on like on your existing CI and tooling,
Speaker 2: which are not part of the AI. But tomorrow what
Speaker 2: you can do is AI generate components the right test
Speaker 2: for each component. We have the power to run the
Speaker 2: test for all these components in parallel CD issues gives
Speaker 2: them back to the AI. I will fix them, will
Speaker 2: run them again. It runs fast because it's parallelized everything.
Speaker 2: And then the linking, the linking configuration or the formatting
Speaker 2: configuration is also part of the meta data. So AI
Speaker 2: is started doing review to itself, getting issues, fix them,
Speaker 2: getting issues, fix them. And when you as a human
Speaker 2: get the code, it's already being reviewed by the AI
Speaker 2: and fixed five times. So now the show now that
Speaker 2: the path from this point to use it, it's much easier.
Speaker 2: It's already in much better quality than today because of
Speaker 2: this process.
Speaker 1: Okay, I would imagine you still want a human to
Speaker 1: review it, though, I mean AI is only effective as
Speaker 1: how well it's created. You know, good stuff in, good
Speaker 1: stuff out, garbage in, garbage out. So I know my
Speaker 1: tendency is, as someone who does a lot of debop
Speaker 1: stuff would be, I'd want to be eyeballing it as
Speaker 1: a human, you know, have a human look at it
Speaker 1: first before it's actually deployed. But I would assume that
Speaker 1: you know, you could easily implement that as part of
Speaker 1: your process.
Speaker 2: Correct, Yes, so for sure you still need the human
Speaker 2: equivalent review for sure. But the question is how how
Speaker 2: how long did this human needs to to like how
Speaker 2: much work you need to do, Like it gets like
Speaker 2: a fifty percent or it gets like eight or ninety percent. Okay,
Speaker 2: big difference, and we are trying, you know, we're not
Speaker 2: at one hundred percent, probably will not be there anytime soon.
Speaker 1: What in terms of test cabbaging quality, one.
Speaker 2: Like that you can take the code of for the
Speaker 2: I and not doing a review at all because it's
Speaker 2: like perfect confidence, right Okay, yes, okay, so most of
Speaker 2: AI today is give you like I don't know fifty percent,
Speaker 2: and we're trying to give you like ninety percent, okay,
Speaker 2: which is a lot of time and a lot oft
Speaker 2: to say. And another thing that you described and it's
Speaker 2: important and interesting is like the albage in garbage out okay.
Speaker 2: Out of the main issues of how AI generating god
Speaker 2: and the quality of the code even before like writing
Speaker 2: tests and everything is like what you give the AI
Speaker 2: as the input? Okay. And let's talk about like, let's
Speaker 2: say three main principles of how the AI, what do
Speaker 2: I get as an imput and how it uses it?
Speaker 2: So the first principle is that we want a YI
Speaker 2: to get an input a higher level, higher level of structure, okay,
Speaker 2: like a composite instead of atom. A EI today is
Speaker 2: walk with tokens. Right, they get like English or language tokens.
Speaker 2: It can be like the world if or like four
Speaker 2: and it knows like it equal signs or stuff like this.
Speaker 2: But as a human, we don't read the code like this.
Speaker 2: We have boundaries, right, we're working with higher structure. We
Speaker 2: are working with business parts with features with product boundaries. Okay.
Speaker 2: If we take an example from let's say you're looking
Speaker 2: on a map. Okay, if AI look on this map,
Speaker 2: you see like I don't know, pixels or mountains and
Speaker 2: sand and water. If you look on the map, you
Speaker 2: see countries, right, you see this in Spain. You know
Speaker 2: that Spain has like different characters. And you see French
Speaker 2: and you see like countries and each country has like
Speaker 2: meaning with it. Okay. And this true not for not
Speaker 2: only for code generation, for even for architecture. Right, we
Speaker 2: have like templates that we combine together to build like
Speaker 2: bigger structure. And we want the EI to understand not tokens,
Speaker 2: but to get components with meaning instead of tokens. And
Speaker 2: this is the first principles, Like components is better than tokens. Okay.
Speaker 2: The second is what the EI can can see, which components,
Speaker 2: which part of the code base it can see. For example,
Speaker 2: the when we developers, let's let's think about like an
Speaker 2: architect or like very productive developers in the company. Okay,
Speaker 2: anyone knows someone like this, someone who is smart as
Speaker 2: a general, who is very good on the tech on
Speaker 2: the specific tech stack. Is like I don't know, great
Speaker 2: view developers, a great no JS developer whatever. And the yie,
Speaker 2: by the way, is smart and knows pretty much any
Speaker 2: framework better than any human. Okay, but these developers also
Speaker 2: have like a big advantage that he knows all the
Speaker 2: code base in and out has been there from day one.
Speaker 2: When he is trying to build a feature, then he
Speaker 2: thinks about different stuff like what can I use where
Speaker 2: is it? Who can I discuss about how to use it?
Speaker 2: And is focusing like on the input statement and you
Speaker 2: see the entire picture. He can go and open another repository, okay,
Speaker 2: or the Becket repository. It can open like the Design
Speaker 2: System repository. But what we do is a YI is
Speaker 2: we give it a very small context. And why we
Speaker 2: give it a small gold because because of different stuff.
Speaker 2: One is the window size. Okay, we cannot We are
Speaker 2: technical limitation with AI about how many code you can read.
Speaker 2: This is one issue and it's improved all the time. Okay.
Speaker 2: The second issue is availability. Okay, maybe today tomorrow AI
Speaker 2: can read like a full rippo. But what if our
Speaker 2: implementation is on a different repot. We have a font
Speaker 2: and ripple and the bacon ripple. AI now to need
Speaker 2: to build a feature on the front end that uses
Speaker 2: the back and API. Even if you can read the
Speaker 2: entire ripple of the front end. The back end is
Speaker 2: a different place. You cannot read it. You cannot read
Speaker 2: the design system REPO. So the availability is also a problem.
Speaker 2: What we want to do is to give the AI
Speaker 2: like holistic visibility. We want to give the EI the
Speaker 2: power to see the entire code base. And the way
Speaker 2: we do it is by we are taking these components,
Speaker 2: no matter which report it to is they are coming from.
Speaker 2: We model them as a graph. So we have the
Speaker 2: notes which is components with the meta data and we
Speaker 2: don't even need implementation. We will discuss it in a second.
Speaker 2: And we have made a data on the relationship like
Speaker 2: which API this component is using from a different component,
Speaker 2: how they are connected, it's a dev dependency, it's a
Speaker 2: random dependency, whatever, whatever. And we want to give the
Speaker 2: AI this full picture and not only like asking him
Speaker 2: to look under the lamp, because even if it's not
Speaker 2: to reuse, if you don't have access to read this
Speaker 2: relevant code base, we will not know how to reuse.
Speaker 2: This is like the second principle is like relistic is
Speaker 2: better than local. I think we want to give the
Speaker 2: realistic view. And the third principle is we have this
Speaker 2: race about like increasing the window side of the context
Speaker 2: make it bigger, bigger, bigger. Great. But we all know
Speaker 2: that if you put more context, which is context to
Speaker 2: get wose results. Right, we don't want to give the
Speaker 2: I all the context in the world because it will
Speaker 2: confuse them. We want to give them only the relevant
Speaker 2: and most important part. So the principle is about accurate
Speaker 2: context is better than bigger context. Okay, And what we
Speaker 2: do is we have this we have this graph, for example,
Speaker 2: and then we ask the I to make a virtual
Speaker 2: graph or potential graph, and then we go to the graph.
Speaker 2: And before the II is not talking directly to the graph,
Speaker 2: is going through a semantic search. And this semantic search
Speaker 2: is looking for these specific components that might be related
Speaker 2: and give only these components to THEI as like an input,
Speaker 2: so we can read this API. And it also don't
Speaker 2: contain the implementation because all the implementation of components. When
Speaker 2: you try to build a new component, you don't care
Speaker 2: about the implementation of the component you're using, right, You
Speaker 2: only care about what it does, the description and the API,
Speaker 2: like what is the public API this component? If I
Speaker 2: give the AI all the full and if statement inside
Speaker 2: of it, of the entire code base. First I will
Speaker 2: get the context, window size issues, and second I will
Speaker 2: just put a lot of not relevant information for him.
Speaker 2: So what we do We provide the AI only with
Speaker 2: the signatures, with the description, with the labels for example.
Speaker 2: So then we can give the I much better and
Speaker 2: we filter it only the relevant component. So we give
Speaker 2: the EI an realistic view of everything it needs, but
Speaker 2: only the necessary information of each of it. So the
Speaker 2: results you get are much higher quality.
Speaker 1: Yes, I think you can shorten that to quality or quantity. Yeah,
Speaker 1: you only want a good step and not everything. Okay,
Speaker 1: So last question list that I can think of, is
Speaker 1: your LLLM, your models that you're using. What are you
Speaker 1: using your own lll ms, are using chat, GPT four,
Speaker 1: chat gpt zer A one or a cloud or what
Speaker 1: are you using for your l models?
Speaker 2: Yes, so first we don't have our own LM our
Speaker 2: own model we are using At the moment, we're using
Speaker 2: Gemini two, but we're playing with it, so we're changing
Speaker 2: it and test different models. What interesting is that if
Speaker 2: you give the AIS today, all the models today the
Speaker 2: correct and small task, they are doing a great job
Speaker 2: any of them. If you're asking any of the models
Speaker 2: no matter which one of them to build a cloud
Speaker 2: component and react or in view, they will do great job. Today.
Speaker 2: The problem is that we want we don't want to
Speaker 2: ask them to build the car. We want them to
Speaker 2: build the future. So what we do is we are
Speaker 2: breaking it kind of like a kind of like an
Speaker 2: agent method. It's like it's an engineering problem, not an
Speaker 2: EI problem. We're asking thei AI, what components do you need?
Speaker 2: Then for each one of these components were we're doing
Speaker 2: some manipulations, and then we separate it, like if you
Speaker 2: put one pompt asking for an application in our a GUI.
Speaker 2: Behind the scenes, we will probably send like four hundred
Speaker 2: prompts or something like this behind one prompt of yours
Speaker 2: because we're splitting it and then you're splitting it again.
Speaker 2: And then for each component, we're asking to build a
Speaker 2: component to describe the responsibility and then to write test
Speaker 2: for this components specifically. And then even with the existing
Speaker 2: AI today, the existing NLMs, we get really really good components,
Speaker 2: a component that probably built better than many human developers
Speaker 2: will do, and then you can use it by AI
Speaker 2: or by develop post tomorrow, combination of both of them.
Speaker 1: Probably yeah, okay, yeah, that makes sense. That makes sense
Speaker 1: for sure. All right, So before we move on the pics,
Speaker 1: is there anything else you wanted to cover that we
Speaker 1: regarding bit or AI that you want to talk about.
Speaker 2: Just want to share that this AI is getting into
Speaker 2: review version a few days ago at the moment with
Speaker 2: recording recording today it's about ten I'm not sure when
Speaker 2: we'll be released, but it's it's pretty new. Probably it
Speaker 2: will be still pretty new when you tried, so feel
Speaker 2: free to try it. It's like just go to bid
Speaker 2: dot cloud and you can write a prompt. Keep in
Speaker 2: mind that this is a different type of AI, like
Speaker 2: the difference between writing a question to GPT or to
Speaker 2: deep search to deep research, which takes an hour. It's
Speaker 2: the same with our REI. It's breaking the problems sending
Speaker 2: a lot of a lot of prompts. It takes some times.
Speaker 2: So don't expect like a bold experience of after twenty
Speaker 2: seconds you get something running. It's much bigger. And keep
Speaker 2: in mind that in return you get like a platform
Speaker 2: that is enterprise eddy. It build a real backoned by
Speaker 2: the way, it's not like connecting to super base or
Speaker 2: something like this like beacons for ward. It's building also
Speaker 2: Bacon like real micro services, Real Express or grap cuel
Speaker 2: micro services. It gives you test and connect everything together,
Speaker 2: but it of course takes some time to generate and
Speaker 2: it's probably won't walk out of the box on the field.
Speaker 2: Try so you get like I don't know, seventy components.
Speaker 2: Some of them will have some issues that we will
Speaker 2: probably into ask AI to fix or manual fix them.
Speaker 2: But after this process of one hour of generation and
Speaker 2: one or two hours of fixing, you get something that
Speaker 2: is really ready for for for scale and for using
Speaker 2: in real organization. So just like expectations about what you
Speaker 2: get and how it works, and don't expect the same
Speaker 2: because it's not the same as other tools.
Speaker 1: All right, all right, So we mentioned bit dot cloud
Speaker 1: and bid dot dev as the websites to get more information.
Speaker 1: Is there any other channels like x, Twitter, blue Sky
Speaker 1: anything else?
Speaker 2: Word?
Speaker 1: Yes, people can follow you.
Speaker 2: Yes, So first if you want to follow me or
Speaker 2: talking to me directly, just go to gilad dot dev
Speaker 2: gilad g I l A d dot dev. It's my
Speaker 2: personal website. You can find many podcasts and talks and
Speaker 2: whatever and all the socials, bitter linking whatever that you
Speaker 2: can reach out to me if you want. Uh, if
Speaker 2: you go to bit cloud, you'll find all the like
Speaker 2: the socials of the comp and the our slick community
Speaker 2: community slack that you can reach out to our team
Speaker 2: and then talk to us if you have any questions
Speaker 2: and stuff like this. Everything you can find on a
Speaker 2: bit bit dev find all the communication each other with beat.
Speaker 1: Alrighty sounds good. All right, well, thank you for coming
Speaker 1: and enlightening. It's about bid and AI sounds like quite
Speaker 1: the the tool for managing an enterprise size app. I
Speaker 1: work in one every day, so I can appreciate how
Speaker 1: nice that would be to have something like that. All right,
Speaker 1: We'll move on to picks picks, the part of the
Speaker 1: show where we get to talk about anything we want
Speaker 1: to talk about. I'll go first and do you. I
Speaker 1: don't really have anything other off topic other than I'm
Speaker 1: in Arizona and I'm loving the warmth and sunshine as
Speaker 1: compared to my Oregon where it's a little cooler and rainier.
Speaker 1: So I'll do that for my pick of the day,
Speaker 1: visiting my parents, and then we'll move on to the
Speaker 1: dad jokes of the week. Yeah, my mind, the high
Speaker 1: point of any podcast episode. But I might be alone
Speaker 1: in thinking that, so start out, so my doctor. I
Speaker 1: went and see my doctor the other day and he
Speaker 1: only gave me six months to live, so I shot him,
Speaker 1: and the judge gave me twenty years.
Speaker 2: Nice.
Speaker 1: The end of the day, a detective shut up my
Speaker 1: door and asked me where I was between five and six.
Speaker 1: I said, well, I was probably at school, you know,
Speaker 1: five and six years of age, right? And then did
Speaker 1: you know I love cow jokes? Did you know that
Speaker 1: cows kill more people than sharks. I'm surprised that cows
Speaker 1: killed any sharks at all?
Speaker 2: All right?
Speaker 1: Oh, a little double whammy there, double all right? Those
Speaker 1: are the dad jokes of the week, do you lie?
Speaker 1: Do you have any picks for us?
Speaker 2: Yes? Actually I want to to building English, but to
Speaker 2: pick kind of competitor to us. It's uh, it's a
Speaker 2: new tool from an Israeli guy. It's called base forty four.
Speaker 2: And you can try it like just a little based
Speaker 2: forty four like the number. And this is like a
Speaker 2: kind of a competitor to to bold and lovable and everything,
Speaker 2: which is great if you're doing like a side project,
Speaker 2: a weekend project, and it can build you also like
Speaker 2: kind of taking the authentication and every and some other
Speaker 2: aspects of the application right away from you for from
Speaker 2: your prompt and this is built by one guy from Israel.
Speaker 2: So it's like a great uh, it's it's it's great
Speaker 2: to see like someone alone today is kind of competing
Speaker 2: with all these giants that raised tons of money and
Speaker 2: you have like large teams and it is like building
Speaker 2: this like a side project for a few months, is
Speaker 2: studied like a few months ago and uh, seeing really
Speaker 2: good results. So if you're doing like a site logic
Speaker 2: or something, you should try it. If you're trying to
Speaker 2: use the if enterprises, probably just use tool. But is
Speaker 2: really great and deserve like all the respect of building
Speaker 2: it like alone and also like a national crowd of
Speaker 2: his dual.
Speaker 1: Yeah, it looks yeah, it's not necessarily in your space.
Speaker 1: I've heard of some tools like this looks pretty interesting,
Speaker 1: especially looking at the website. It's really pretty. But one
Speaker 1: person doing that, that's that's pretty amazing. So it's base
Speaker 1: for for the digits for Ford dot com. Yeah right,
Speaker 1: alrighty well, thank you Giloud for coming and talking to
Speaker 1: us today. Great to hear about what you got going on,
Speaker 1: and thanks everybody for watching listening and we'll talk to
Speaker 1: you next time on job ascript Ever