Building Enterprise Infrastructure with Bit & AI with Gilad Shoham - JSJ 676 - podcast episode cover

Building Enterprise Infrastructure with Bit & AI with Gilad Shoham - JSJ 676

May 08, 202558 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

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:
  • 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.

Transcript

Speaker 1

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 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 about yourself, Gilaud, your dev history and anything else you want to tell us.

Speaker 2

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 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

What do you say coffee in the code.

Speaker 2

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

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

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 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 this episode.

Speaker 1

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 and how AI will on top of those.

Speaker 2

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

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 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 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

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 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 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 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 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 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

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 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 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

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 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

Have Okay, so that's that's a lot to unpack.

Speaker 2

Yeah, a short version of the of it.

Speaker 1

Okay, so let's go back. So let's go back. And 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 the front end. Are there specific maybe languages or frameworks that you don't support or work with. How does that work?

Speaker 2

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, 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 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

Okay, so you know, so on the back end, is it just no then? Is that correct?

Speaker 2

Yes?

Speaker 1

Okay? So there though Ruby, any any PHP based languages.

Speaker 2

That's not supported, not at the moment.

Speaker 1

No, okay, all right, that's good to know. Okay, So 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 say a view single file component or a reacting component.

Speaker 2

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, 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.

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 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

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

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, 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, 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. So everything is built with bit internally.

Speaker 1

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

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, 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, 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. 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 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, merge mechanism, conflict resolution everything from sketch.

Speaker 1

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. 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

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 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 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 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

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

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 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. 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

Okay, now you mentioned your vs code extension. Do you have extensions for other tools like in Talents, heads, PhD.

Speaker 2

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

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

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 the browser. So if you used to intelligence or something like as of shortcuts and you need to set it up.

Speaker 1

Okay, so let's say so, then so you've got your 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 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

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 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. BIT will do the the wiring from the node models to your source code. If you're on an editing mode, okay.

Speaker 1

But you're not using the main NPM repository right, this is using your own BIT repository. You're just using the NPM tool.

Speaker 2

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 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 team working on all the Angular integration. So we have like kind of nice team here.

Speaker 1

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

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 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, 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

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

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, 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, 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 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 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,

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 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 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, 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 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 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

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 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, 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 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 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 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 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,

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 to make AI work for enterprises. Okay, so.

Speaker 1

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

Right.

Speaker 1

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, 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

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. 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 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 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 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

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

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 for this, and a bit component for this and a bit component for this.

Speaker 2

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 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 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

regardless of AI. So you're already doing it for many organizations.

Speaker 1

Yeah, that would that considering that you know, like you said, 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 new features because it has the knowledge of your code base right exactly.

Speaker 2

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 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 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 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, 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 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, 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, 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. 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 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

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 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

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 at one hundred percent, probably will not be there anytime soon.

Speaker 1

What in terms of test cabbaging quality, one.

Speaker 2

Like that you can take the code of for the 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 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 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. 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. 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 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,

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, 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 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 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 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.

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 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, 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 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

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 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 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 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, 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. 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

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 are you using for your l models?

Speaker 2

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 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 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 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

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

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

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 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 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

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. 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 get and how it works, and don't expect the same because it's not the same as other tools.

Speaker 1

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

Word?

Speaker 1

Yes, people can follow you.

Speaker 2

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 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

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

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 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

Nice.

Speaker 1

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

All right?

Speaker 1

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

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 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.

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 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 it like alone and also like a national crowd of his dual.

Speaker 1

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, and thanks everybody for watching listening and we'll talk to you next time on job ascript Ever

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android