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