onboarding time to get a new engineer onboarded.
It takes like two weeks or three weeks or a week or whatever it may be.
Just like setting up a new project usually takes a bunch of time and developers waste
about 56% of their productive time just on development environment issues.
So like can we get all that out of the way?
Hello, welcome to DevTools FM.
This is a podcast about developer tools and the people who make them.
I'm Andrew and this is my co-host Justin.
Hey everyone.
I would like to introduce our guest today, Ivan Boraisin.
Did I say that right?
You said that pretty good.
Thank you.
That was awesome.
Okay, cool.
So, Ivan, we've had a chance to meet at a lot of the social events that you put on.
You put on a Daytona DevTools, like social hour, and you've done it New York, NSF,
and London, and like everywhere.
Everywhere.
I would love to talk more about like how you managed to run a company and travel so much.
But you are one of the co-founders of Daytona, and we're really excited to talk about that.
But before we dive in, would you like to tell our listeners a little bit more about yourself?
Sure.
Thanks for having me.
I'm super excited about this one.
I've like listened to the podcast quite a bit.
Also am a proud owner of a bunch of swag that more than 1% has stopped me and asked me
where have I gotten it?
So, that was pretty awesome.
So, myself co-founder of Daytona before Daytona, I co-founded or I founded, sorry,
this developer conference company called Shift, which was acquired.
And I worked at the company that acquired it for two and a half years.
Before that, I co-founded a similar company called Code Anywhere.
And before that, I did just a bunch of other things that might not be related to what we're doing.
But Post, Code Anywhere, Shift, and Daytona,
they've all been basically four developers specifically.
Cool.
So, before we get into the stuff you code on, let's go back to what Justin said.
You travel more than I think any person I know.
Like you actually live somewhere in Europe, but I don't know if you're ever actually there.
So, why do you travel so much?
And like, as Justin said, how do you manage doing that while like running a company?
Sure.
Yeah, I travel quite a bit.
Wife gets angry on that.
I'm not that much home.
So, wife and child are in Croatia.
I am born Canadian, raised in Canada by Croatian heritage.
So, moved to Croatia at some point while I was at school, finished school there, got my first job.
I did then live abroad, went to Boston, lived there for a while, lived to other places,
NSF back and forth for a while, but ended up getting married and sort of having a family in Croatia.
It's a really good setup that we have, especially with a child, but there's not much things to do outside of
people come to Croatia for a yacht week.
We live on the Mediterranean coast here.
It's a wonderful place for holiday, but not the best place to get work done.
And because of that, it is sort of my job to, you know, make this the best company it can.
And a lot of it has to do with interacting with people and you're going to interact with people,
probably not in Croatia except on the summertime.
So then I mostly am in New York.
So I'm there at least a week a month.
I'm there so quite often, but I'm also in San Francisco and London or whatever.
And because when you are on a plane already, it is super easy for me to hop into another place for, you know,
an event, a conference or whatever it may be.
And so I sort of made a thing of it inspired by our common friend, Swix,
and Angel Vester and Daytona, who usually when he lands in a place,
does this sort of like ad hoc meetup where he just buys everyone drinks.
And I'm like, oh, I'm going to steal this from you.
This is super cool.
And that's how the DevTools meetups began.
And now they're fairly big.
I mean, the one in San Francisco last time was I think 75 people, something like that,
for an ad hoc meetup, just like founders and investors in the DevTools space.
It was pretty good.
The one in New York last time, I think was like 30, 40 people just in was there.
So it's really, you know, picking up.
The interesting part is we even have sponsors for them now, which is insane.
As something I just do as a hobby.
And I think it comes back from the conference days as well.
So that is something I do.
I try to get the most out of traveling.
So if I'm not at home, I'm either meeting with someone at an event, creating your event
or, or, or something that's connected to the tone specifically.
Do you have any given that you travel so much?
Do you have any like hard fault travel tips?
Like do this one thing if you're going to travel a lot.
So I have no jet lag ever.
And I actually, I think wrote a post about this quite a while ago.
And again, not DevTools, but like one thing I read a long, long time ago
and it actually works for me.
I sort of brainwash for myself.
I think for it to work is that I change all my clocks on wheels up.
So when your plane takes wheels up, set all your clocks, your laptop,
your phone, everything to the destination time and act like it's that.
So let's say if I'm flying from Europe to the US, I will not sleep at the plane
at all.
I just work because just days just longer.
But if I'm flying the other way around, it's night.
So it's like 2 a.m.
As soon as it's wheels up and then you try to go to sleep right away.
And then when you land, you go to sleep at the time.
You're supposed to sleep in that place.
And obviously if you can't get any cardio in the morning, get a lot of caffeine
in the morning, melatonin in the evening and do all these things
sort of just to hack your circadian rhythm.
And I do that.
So I'll hop across an ocean and just be ready to go.
I think the last meetup I did in New York, like I literally landed
from Europe to New York that day, did the event and just went sleep afterward.
So yeah, I guess that's something you have to teach yourself to do.
Cool.
So let's switch up gears a little bit and get into what you make as a company.
Let's talk about Daytona.
And then after that, I want to roll it back because you've been in this space
for way longer than I realized before researching you.
Yeah, I'm a super old person in this space, like very long.
So Daytona essentially is a open source development environment manager.
Sometimes some people call a CDE.
We say it's not the CDE means cloud development environment.
Daytona is not necessarily doesn't necessarily manage just the cloud development environment.
It manages all your dev environments together.
And so basically what does it automates everything so that you have this seamless
experience, no matter where the dev environment is running, if it's local,
local hosts on Amazon or wherever, maybe, and you as developer, you know,
just get into coding.
You don't have to think about anything.
You have to go through a read me file.
You don't care about these things.
It's all automated for you.
And so that is what Daytona is.
And yeah, the journey as you mentioned, it started in 2009.
I didn't know.
I don't know how many people actually realized that specifically.
Yeah, I was very surprised that 2009 it started as PHP anywhere, I think, right?
Yeah.
Yeah, PHP anywhere.
Yeah.
So we founded the very first, I think, I think browser based ID in 2009.
And I don't know how many of the listeners here.
There are people that are older, I'm aware, but there are probably people that
weren't doing this thing back in 2009.
So a lot of time has passed since we've done this with one of the first
or the first that started it.
And when we started, it was basically just like a notepad type editor
and FTP connector as time progressed sort of.
And as web 2.0, for those of you remember, actually happened.
We could actually do like syntax highlighting and all these things in the browser.
And because this was such a long time ago, we had to build everything.
So we built our own IDE, like multiple versions of it, our own orchestration platform.
I mean, we even created our own authentication.
Like we did everything by ourselves.
And Code Anywhere had some success.
I think 2.5 million people have signed up on the platform throughout the years.
And it's still interesting that when I meet people today, they're like, oh,
I've used Code Anywhere.
I'm like, wow, I didn't know it was like that popular.
It was never going to be a super successful company for two reasons.
One, it was very, very early in sort of the technological lifecycle.
But also at the time, we had no idea what the difference between a user and a buyer was.
And we were trying to sell to a user, being the individual developer, versus a buyer,
which we now know as like an CTO type office, engineering manager type person,
or CISO, not the individual person self.
And so those are two things that we sort of didn't know when we started.
And that's why it was sort of never was that successful.
But it did teach us a bunch of things, especially and specifically
about the infrastructure layer that we had to build to offer a browser based IDE.
And that's sort of where Daytona came from.
That's sort of like the idea behind Daytona.
So Daytona, would you describe it similar to GitHub Codespaces or Gitpod?
And then it's like the all inclusive.
It's your environment, like what it's running on, and the editor and everything put together?
Or is it more focused on getting just common dependencies and everything sort of packaged up together
and letting you kind of interact with it however you want to?
I've seen a lot of like a tenet set creating like unified development environments
and Docker containers to varying degrees.
So like how far along the access do you all go?
Sure, there's a lot of things that we actually do.
And I might take it back to why we actually created Daytona,
because it's also sort of like why the hell would you make a same company twice?
It's not the same, but it's very similar.
Especially when you got burned the first time.
And so the reason why we were actually at some point code anywhere had about a million dollars invested.
We ended up buying back all the shares from investors and just sort of stayed online.
It still exists, but it's basically just the founding team owns it.
We went to do other things that created the conference sold that.
I was working at this other company, which was supposed to stay for a lot, lot longer.
I was running the developer experience there, but ended up leaving because about two years ago,
we started the founding team started to get a bunch of inbound interest
around code anywhere or more specifically the infrastructure behind that.
We got inbound from like potential customers, analysts and even acquires.
And all of them were asking a similar question.
And it was, we don't want the browser ID.
We don't care about that.
Like nothing of that is needed, but our developers are wasting so much time.
There's a couple, there's actually three issues, but we're in so much time setting this up.
Can we have something that will automate and make their lives easier?
But there is a constraint.
Like we have to be able to run this thing like self managed.
And so as we were like talking to all these people, we found that all of them
have a similar set of issues.
And we even went further and started interviewing other people, searching
the internet for anyone that's mentioned cloud development environments or
something similar.
We found like just a bunch of people and reached out to all of them.
We found that most tech companies are tech first companies.
So you're, you're slack, you're Shopify, you're Spotify, you're LinkedIn,
Eventbrite, like these companies have built something internally just to
solve this, but you're non, what I call non tech first companies.
So, you know, anyone in aerospace, insurance, banking, whatever, have
not created these things.
And then we sort of distilled further.
So why did they create them?
And so they created them for three different, three main reasons.
One is developer productivity or happiness, meaning, you know,
onboarding time to get a new engineer onboard it.
It takes like two weeks or three weeks or a week or whatever, maybe,
but not even that, just like setting up a new project usually takes a bunch
of time and developers waste about 56% of their productive time just on
development environment issues.
So like, can we get all that out of the way?
The other thing, the second thing is scalability or compute restrictions.
So we might have like M3 max and they work awesome and whatnot, but
even that is not enough.
If you want to, you know, spin up another dev environment that you want
to help someone without with, without shutting out, you're shutting down
yours, or it just might be too big that it can't fit on that, or even
you like a lot of people now want GPUs, like how do you solve these issues?
Well, basically, you'll call up your DevOps team, they'll enable an EC2
instance, you'll have to connect to that.
It's just like a pain.
And the last reason is actually security.
So a lot of very like stringent compliance focused companies offer
their engineers a single way of work, and that is through a virtual desktop
interface, and a lot of people do this.
So using remote desktop or Citrix to log into a server and then have
your ID there with all that lag is a very shitty experience.
It is terrible, right?
But these companies want to make sure that the source code stays within
the bounds of the company.
And so how do you solve that?
The only way to do that is either through that or a system like Daytona,
which enables you to have everything set up on that server, but have an
ID on your own.
So sort of to culminate how we started, we got about a bunch of inbound
interests from all these companies needing these things.
And we actually figured that out, that it was essentially the infrastructure
layer of code anywhere, or that was the basis of it.
We ended up creating a new one.
This is what these companies want, and they want to self manage it.
And we went off to sort of build this new product, which ended up
being Daytona.
So to answer your question, it is about the security automation
scalability of these dev environments and deliver it to an engineer
using their favorite ID.
So there is a browser based ID if they want, most often than not,
they choose not to do that, but they use their JetBrains or cursor
or VS code or whatever they want.
Do those IDE integrations require any work on your part?
Are you like creating plugins that plug into VS code to do something?
Yeah, we have to create integrations for all of them.
It can work with just all of these IDs have the ability to connect
to remote dev environments.
So they can do that by hand to connect to a Daytona instance.
But the whole pitch is that it's like super seamless and easy to use.
So developers can basically use a web UI or the CLI or the plugins
that are in these IDs to create a new workspace and it just spins up
for the magic.
That's awesome.
Like what stage of company do you typically see that your customers
are at?
Is it like a larger established company that is like a non traditional
tech company?
So they haven't like yet got to the point where they've like built
their own solution, but they have like a big enough team where it's
like a really painful thing.
Do you see it at any like earlier companies?
Like what is the sort of like licycle?
Yeah, absolutely.
So it's mostly like very, very large company.
So I'd say like 1000 engineers plus is what we've been seeing, where
the biggest pain point is because we also know this as engineers.
Like if the three of us are working together on a startup, the
pain points are not that terrible because you know, we figured out
through osmosis, you know, it sort of works and then as you grow,
it's sort of there.
But when you have those paper cuts times 1000, 2000, 5000 engineers,
then it becomes very, very, very painful and everything slows down
to flip to a halt.
And so that's why we've seen that these are the companies that want
this the most.
Now recently we've started getting inbound from like smaller
companies, like 20 developers and whatnot.
And we're happy to take them on board.
We even have like special types of contracts for these because
from our perspective, it's more interesting to have them as a use
case than it is as a customer.
Nothing wrong with that, but I think we can help them even more
because of their size and they can help us in other ways that these
traditional companies cannot because the feedback loop from these
large, large companies is very, very slow.
I have to tell you, it's insanely slow.
The sales cycle is insanely slow and the feedback is so so like what
we do when we work with smaller companies, it is mostly can we get
that feedback loop faster so that we can iterate faster and solve problems faster.
We'd like to stop and thank our sponsor for this week, but we don't have one.
So if you'd like to sponsor DevTools FM, head over to DevTools FM
slash sponsor to apply.
Et si vous voulez trouver un autre moyen pour soutenir le podcast,
head over to shop.devtools.fm où vous pouvez acheter un merch et
repeter le podcast.
Avec ça, nous allons retourner au épisode.
Donc, l'une des points de main-selling, je pense, de Daytona est la
possibilité de se faire hoster et le tout est en source.
Donc, où est le contrat?
Comment je vais payer pour vous, qu'il n'y a que pour utiliser la technologie?
Absolument.
Donc, le tout n'est pas en source.
Donc, c'est très spécifique.
Donc, on a fait beaucoup de research sur l'en source.
Je me sens que chaque semaine, il y a un nouveau drama en source.
Tout le week.
Il y a un nouveau, peut-être pas tout le week, mais il y a un drama en
source.
Et donc, quand nous commençons, on a commencé par un
premier solution de la solution entreprise.
C'est pourquoi on a commencé.
Parce que nous n'avons pas été sûrs de créer un en source en source
de licence ou de product.
Que nous ne serons pas sûrs de créer ou de créer nos
utilisateurs ou de créer quelque chose de long terme.
Et donc, on a pensé sur ça depuis très longtemps.
Je pense que c'était pendant 9, 10 mois que nous avons
créé sur le bas de la burnère, en essayant de faire
ça en parlant avec tout le monde que nous pouvons.
Et ce que nous avons compris, c'est que si nous voulons
évoquer un projet en source en source, vous ne devriez pas
en source de la valeur de la course de la course, ou, pour être
plus précise, vous ne devriez pas en source de la valeur de la course
de votre client.
Vous devriez en source de la valeur de la course de votre
client, si vous pouvez.
Et c'est quelque chose qui nous a pris un temps pour nous
de se faire en savoir.
Et quand nous pensons à qui est notre client, c'est le
développeur.
Ils ne caresent pas de la scalability, ils ne caresent pas
de l'authentisation, ils ne caresent pas de l'audit, ils ne
caresent pas de la compagnie de SOC2, ils ne caresent pas
d'autres choses.
Ils justent qu'il y a un command et ça se tourne automatiquement.
On se dit, ok, ça a été un temps pour se faire en savoir,
je le dois.
C'est lorsqu'ils de la constructive, les locaux, être
golués, nous n'est même pas en avant, alors qu'ils

Si on fait ça et nous décide d'explorer ce


et ce qui est le code propriétaire et ce qui est le code d'open source.
Et puis, nous pensions sur l'open core,
l'application de GitLab, ou autre chose.
Et notre pensée derrière cela est
comment beaucoup de contributaires nous en aurons,
si c'est une grande repository avec plusieurs folders
qui ont plusieurs licences,
qui disent, oh, qu'est-ce que je peux faire,
qu'est-ce que je peux travailler, qu'est-ce que je peux pas.
Et donc, nous avons décidé de se plier en deux repositories,
qui sont plus difficiles pour nous,
en long terme, pour le manager,
mais nous sentons que c'est plus facile pour l'utiliser
et ou contributaires,
parce que c'est une petite repository,
c'est un projet très petit,
c'est en une langue,
vous pouvez juste vérifier,
faire le travail et le travailler,
et ça nous donne le travail.
Et donc, c'est ce que nous avons décidé,
ou ce que nous avons décidé de l'open source.
Et la dernière partie était, en fait,
la licence,
elle ne s'est pas installée dans cet ordre,
mais quand nous pensions sur la licence,
maintenant que nous avons pu détenir
ce qui est le valeur pour l'utilisateur,
mais pas la preuve,
ça n'a pas vraiment pas mal à ce que la licence soit,
alors que nous pouvons le faire,
comme libre possible.
Et donc, on a basically put ça comme un Apache 2.0,
on a décidé de le faire vers la licence,
juste pour le nom des Daytona,
qu'on a fait,
donc vous pouvez juste,
vous devez le référer,
mais c'est la seule restriction réelle
qui est dans la licence,
vers les autres licences plus complexes,
et comme je l'ai parlé de l'open source,
je n'ai pas,
ou je n'étais pas au niveau du niveau de la licence,
pour tous les licences.
Non que tout le monde aille les licences,
mais il y a des tribus,
des gens qui ont hésité les autres licences,
et si vous êtes comme MIT et Apache,
vous êtes tous bons,
comme personne ne vous aille.
Donc, quand nous pensons sur ça,
et sortez de votre question originale,
c'est que nous avons l'open source,
ce qui est valorisé pour l'utilisateur,
et que la source de Daytona,
devient un moyen de travail
pour tout seul individuel
ou développeur dans le monde,
c'est le plan,
et les gens peuvent,
sur le top de cette fourche,
faire tout ce qu'ils veulent,
contribuer à ça, c'est génial.
Mais tout ce que l'actuale buyer veut,
c'est propriétaire,
et ce n'est pas l'open source.
Donc, essentiellement,
oui, vous avez le biais à la charge,
mais vous aussi,
parce que vous ne pouvez pas le faire sans license.
Je pense que ça fait beaucoup de sens.
C'est un...
ce sort d'open source,
model business,
contention,
on le voit dans beaucoup de places,
comme les entreprises de database,
surtout, je pense que vous avez
ce long moment
de juste tenter de se faire,
comme,
construire un company de database possible
sur une liste de personnes standardes,
qui ont la license.
Et en général,
ça semble que la réponse est la chose à savoir,
parce que je pense que l'un des conseils ici,
c'est ce que vous avez dit,
c'est comme,
est-ce que vous êtes en train de sourcer
pour l'usage,
ou est-ce que vous êtes en train de sourcer
pour le...
comme,
le company,
et...
ou pour l'interprète,
et je pense que,
vous savez,
si votre produit est difficile à séparer,
l'un de l'autre,
alors, vous savez,
ça devient un peu un challenge,
et vous devez penser
plus critiquement à la license.
Je vais dire que je suis certain de ça.
Nous savons que des entreprises d'open source
sont en train de faire grand,
donc,
le database,
les CEOs et l'agile,
et les Daytona aussi,
ils en aiment vraiment bien,
mais vous avez beaucoup de ces
des entreprises database de point de vue
où
c'est l'open source
et le seul valeur qu'ils ont donné
est la plateforme de SaaS.
Encore ça.
Maintenant, peut-être que
certains de eux sont en train de construire
des choses extraites dans le SaaS,
qui est essentiellement propriétaire,
qui fait le sens.
Mais,
d'autres que ça,
c'est un business très très rigolo,
long terme,
parce que
si quelqu'un,
vous savez ce qui s'est passé à l'élastique,
mais si quelqu'un d'autre
peut l'aider et le faire,
un autre
spécifique,
c'est où les gens
vont juste mettre le tout
sur la GPL,
qui est comme,
oh,
Amazon ne peut pas faire ça,
bien sûr,
mais votre acheteur peut,
et ils ne sont pas achetés de vous,
ce qui est aussi un problème.
Donc, je me sens que
il y a beaucoup de problèmes avec ça,
et ça semble être plus mal,
parce que les gens,
surtout avec la dernière issue
d'un mois plus tard,
où les gens sont en train de
même bouger de l'open source,
parce que les founders
et les investisseurs
sont en train de comprendre les nuances de ça,
et personne n'a pas eu le temps
de lire ces licences.
Et maintenant,
l'entraînement est que
tout est libre
ou qu'on n'est pas allowed
à faire quelque chose,
ce qui n'est pas
pas le cas,
et les gens sont en train de
bouger,
ce qui est très mal
ou très malade
pour l'industrie,
en général,
surtout pour les gens.
Oui, je me sens
que l'A.I. a presque
poussé
ce problème un peu plus,
parce que,
maintenant,
on a un face de bouger,
qui est
un GitHub de l'A.I.
et ça me semble,
quand vous regardez,
comme,
oh,
ce sont toutes les choses
que je pouvais utiliser,
leur open source,
je sais les wates,
mais ensuite,
vous vous entrez dans les licences,
et c'est comme,
n'importe quoi,
je peux construire une compagnie,
et c'est comme,
je peux comprendre
la réaction de ne pas être le plus drôle,
oh,
n'importe quoi,
mais ces deux licences,
c'est comme,
c'est comme,
trop difficile
ou impossible de utiliser.
Oui, c'est très complexe
pour l'utilisateur,
et je me souviens,
quand on parle de l'un des,
comme,
on consulte avec
un peu de lois,
pour se faire en sorte,
et ils sont comme,
les entreprises ne vont pas
utiliser ça,
si c'est l'un des licences
qu'ils comprennent,
parce qu'ils sont comme,
compliqués,
ils n'ont pas de temps
à utiliser,
et la question est,
est-ce que c'est même valable
d'être open source,
comme,
qu'est-ce que,
qu'est-ce que vous essayez de
mettre,
en mettant ça,
si c'est trop compliqué
pour les gens à utiliser ça,
oui,
donc,
je veux dire,
c'est mon idée,
comme,
il y a un source disponible,
qui n'est pas open source,
mais c'est juste,
le code est là-bas,
et je pense que c'est bien,
si il y a un cas de utilisation pour ça.
Donc,
on peut mettre
notre code prioritaire,
pour essayer de l'utiliser,
essentiellement,
comme un démon,
mais c'est la seule valeur que je vois,
et que,
n'importe quoi,
à votre point,
je pense que c'est super complexe,
et vous pouvez aussi,
juste ne le faire,
parce que c'est trop d'efforts,
pour une très petite valeur,
pour quelqu'un d'autre.
Ouais,
si vous commencez un business,
sur l'open source,
c'est absolument important,
de penser à ça,
en plus.
Cool,
donc,
on parle d'un peu de Dayton,
un peu plus,
donc,
je me suis demandé,
avant,
comme,
OK,
comment est-ce,
que vous comparez,
avec quelque chose,
comme des codespaces,
ou des codespaces,
dans sa forme originale.
Et donc,
pouvez-vous parler un peu plus,
de la démonstration,
de,
comme,
oh,
vous êtes,
vous avez une URL,
vous avez une idée,
d'idées,
qui a tout le truc,
à ce que vous essayez de dédouer,
pour le démonstrer,
pour le Daytona?
Bien sûr,
je peux parler de codespaces,
par exemple,
et des différences,
et il y a des,
des très obvies,
et il y a des,
des plus nuages,
les obvies,
sont,
les codespaces,
sont des products de sas,
qui signifie,
si vous voulez le self-manager,
pour une raison,
c'est,
c'est juste de la faute,
vous voulez juste de la tourner,
vers les codespaces,
le service,
qui est à l'Asie,
sous-en-arrière,
mais vous voulez faire le GCP,
comme,
vous ne pouvez pas faire ça.
Le autre chose,
c'est que,
ça ne fonctionne qu'à GitHub.com,
et nous avons un bunch de customers,
qui ne sont pas seulement,
qui ne travaillent pas avec GitHub.com,
mais qui travaillent avec,
vous savez,
GitLab,
et GitLab en prime,
ou Bitbucket,
et Bitbucket en prime.
Vous devez avoir plusieurs de ces,
des providers Git,
qui n'ont pas,
et c'est juste,
vous savez,
juste la partie de la première,
dont beaucoup de companies ne peuvent pas consommer ça.
Mais plus que ça,
si vous voulez un environnement complexe,
donc,
les codespaces apportent un containers de service,
qui est bien,
Daytona aussi,
mais ils apportent seulement,

un,
c'est-à-dire un containers de service,
des environs de service,
qui est bien,
un containers de repos,
qui est bien,
mais si vous avez besoin d'un certain hardware,
vous ne pouvez pas avoir ça.
Mais plus que ça,
si vous avez besoin d'un complexe,
comme Polyrepo,
des configurations,
comme ça n'est pas là,
comme ils ne peuvent pas se résoudre.
Donc,
il y a beaucoup de choses,
et je peux vous dire,
comme,
les deux companies que nous parlons,
à chaque stage de nos pipelines de sales,
comme les deux,
comme,
oh,
comment on a fait,
vous savez,
des repos multi-repo,
et comment on va faire ça,
et chaque company a une manière différente de faire ça,
et c'est la façon de se résoudre.
Et donc,
un service comme les codespaces,
ne peut pas se résoudre tout ça.
Donc,
juste,
quand vous regardez ça,
comme, pour la grande majorité,
ce n'est pas même un chose de fausse.
Donc,
avec Daytona,
c'est-à-dire,
ce que nous essayons de faire,
c'est de solider ces
très complexes
des environnements de dev,
que ces grandes entreprises
ont en fait,
et que tout a créé
des études bizarres
de se rassembler ensemble,
à l'internel,
et nous pouvons leur donner
essentiellement ce qu'on clique,
pour le développement,
mais aussi,
ce qu'on trouve dans la complexité.
Et c'est ça,
ce qui est là où nous nous réveillons,
et on essaye d'acheter.
Donc,
sur la page de la maison,
je vois quelque chose de l'un des containers de dev,
qui est mentionné beaucoup.
C'est comme,
même l'un des items de la top-line
sur la page de la maison.
Donc,
qu'est-ce que les containers de dev
et comment les utilise de Daytona?
Bien sûr,
les containers de dev,
les containers de dev
sont des codes de infrastructure
pour des standards de dev environnement.
Donc,
la container de dev
a été créée par Microsoft.
C'est pourquoi on sort
d'initialement,
avec eux.
La preuve de dev
est,
parce que c'est Microsoft,
vous allez avoir un peu de public,
GitHub,
repositions d'open source,
en utilisant ça.
Et parce que c'est part de Microsoft,
il y a des choses qui sont en place
dans la code de dev,
donc dans l'édit de la
salle de dev.
Ce qui veut dire,
c'est que,
si quelqu'un a installé
un container de dev,
vous n'avez pas de la recueillie.
Vous n'avez pas de
voir les portes d'open,
vous n'avez pas de penser
sur les libraries à installer,
vous n'avez pas de penser
sur les plugins de dev
en code de dev.
Ça va
tourner
toutes ces choses
et vous allez construire
votre environnement
à spec.
Et ça va fonctionner
instantanément.
Et c'est quelque chose
qu'ils ont fait.
Et nous voulions
évaluer ça
initialement
par code de dev.
Donc code de dev
juste pour faire un tour
de dev,
sorry code de dev.
De dev,
il y a beaucoup de mots.
De dev,
quand ça commence,
il va créer une machine virtual
pour vous,
ou un container
de son host local.
Il va ensuite check
le repository,
il va recueillir le repository.
Il va regarder
si il y a un file de configuration,
donc en ce cas,
un container de dev,
mais il y a aussi des multiples
lesquels on va en faire un second.
Si il y a,
il va exécuter contre ceux.
Et si il n'y a pas,
il y a des images de base
de container
que les container
ont utilisé
et tentent de faire
le meilleur possible.
Puis,
il va connecter
votre idea local,
il va changer les clés,
il va ajouter
les proches,
alors que je peux
vous donner un preview
de ce que je fais.
Il fait tous ces choses.
Et tout est déterminant,
mais
la configuration
de la dev
environnement,
si il n'y a pas
de container de dev.
Donc,
c'est pourquoi
on a vu beaucoup de gens,
c'est devenu
des standards de de facto.
Les autres des
des des des des de facto
existent,
c'est la dev file.
Il y a des nix,
évidemment,
ce nix est en train
d'être en train.
Il y a des flux,
qui sont des variations
des nix.
Et donc,
il y a un peu
de ces standards
pour créer
des environnements
pour travailler
au bout de la boxe.
Mais les niges
ont été
offres
dans le sens
que chaque
environnement
a ça,
d'exception
pour le fait
que la dev container
a plus d'autres
que nous.
Et c'est pourquoi
c'était un bête pour nous,
originalement.
On va
supporter la dev container
et nous nous avons
ajouté de support
pour les nix,
des flux,
et des files,
et d'autres.
Et c'est aussi
une des raisons
qu'on a mentionnées
avant,
c'est que la dev container
est une projet

qui nous a lancé
assez récemment.
Donc,
quand on regarde
les devs,
les environnements,
la seule chose,
c'est que c'est pas
deterministe,
c'est si il y a un file
là.
Et donc,
notre pensée était,
comment on le fait
pour que chaque
repository dans le monde
ait un file de configuration
sans tout le monde
en avoir à faire.
Le plus facile de la
devs, c'est
peut-être que nous créons
ce projet AI,
c'est un projet
indépendant,
c'est complètement
ouvert,
c'est un Apache 2.0.
C'est pas parfait.
Et la raison est
que nous espérons
que les autres gens
vont contribuer,
les mettre en producteur.
Parce que si nous pouvons
aller à un endroit
où chaque repos
peut être
sur le flai,
en red,
et puis,
générer un file de configuration,
chaque devs
environnement
va travailler automatiquement,
ce qui,
d'ailleurs,
signifie que chaque
nouveau développeur,
n'importe quel
travail qu'ils ont
travaillé,
va être instantanément
pouvoir en faire.
Et c'est bien,
pas seulement pour les entreprises,
mais pour l'opensource,
en général,
parce que vous pouvez
contribuer
à chaque projet,
tout le monde,
parce que ça vous
prend 30 secondes
pour en faire,
sans avoir
à débarasser
le devs,
en faire un devs,
et vous vous dites,
vous savez,
je vais en faire,
je ne vais pas faire,
c'est
ce que le devs

et pourquoi
on regarde
ça,
j'espère.
Donc,
le devs,
l'AI,
on va juste
regarder un repo
et générer
ce que c'est que le devs
qui sera

à cause
de la
package,
des son,
etc.
Oui,
il va
lire le read me,
il va
regarder le code source
et essayer de figure
ce qu'il faut.
Donc,
c'est essentiellement
pour vous,
comme un humain,
qui va lire tout,
et puis,
le write-out.
Et donc,
ça marche,
80% de l'heure,
mais ça ne marche pas
complètement.
Il y a
encore beaucoup à faire,
et c'est pourquoi,
on n'a pas officiellement
embedé
le product de Daytona,
on va,
quand il y a un point,
où il y a,
mais,
j'espère que les autres
gens vont le faire,
et ils vont le vendre
dans leurs produits,
ou pour weight hollow.







si vous avez un







Enester une


tous,

des autres configurations.
Donc, nous avons quelque chose de ce que nous appelons les « builders »
et donc nous avons des « builders » pour ces, et nous avons
construit des versions de tests pour tous les autres.
Nous devons probablement déployer cela publiément très bientôt.
Ils ont tous travaillé, le logic behind eux est tout identique,
ce qui est génial, parce que ça fait que notre vie
d'une perspective interface est super facile.
C'est juste que, à la fois, on va vérifier si il y a d'autres
des des à l'intérieur et si il y en a, on va juste construire
l'environnement qui est à l'intérieur.
C'est vraiment facile pour nous de faire pour Nix.
D'un grapho est le plus facile, parce que vous pouvez
mettre un grapho dans un containers de défis,
et ça va juste être expérimenté.
C'est facile.
Nix et Flux, ils travaillent dans le même logic,
et ça fonctionne très bien.
Nous sommes juste prêts à la lancer.
Donc, l'idée est que nous avons ces « builders »
et on va vérifier si les autres sont là automatiquement.
Et si il y a plus que l'un, vous pouvez évoquer
l'autre que l'autre, et que l'autre, on va construire
l'environnement contre ça.
Donc, ce produit est un peu difficile
et compliqué à construire, et vous avez aussi
mis le rinclin de « nous voulons pouvoir
rouler sur la premises et pour servir
les clients d'entreprises ».
Qu'est-ce qui a été le plus difficile de construire
quelque chose comme ça, depuis que vous l'avez fait
deux fois ?
Oui, deux fois.
Je pense que le plus difficile est
toutes les integrations qui se sont
construites dans une interface
visable.
Comment vous avez pu avoir tout ça ?
Parce que vous êtes essentiellement
un infra-lèvres, vous êtes connecté
sur les deux côtés, donc vous êtes connecté
sur un point, vous avez le point de « rouler
sur AWS, GCP, Azure et tout autre
infrastructure que vous voulez.
Vous avez le point de connecter
tous ces providers, vous avez les
« builders » et vous avez le point de connecter
tous ces idées.
Donc, il s'agit de que vous êtes
dans l'intersection de tout tout,
et que le flow,
en tant que les intérêts des
autres vendredats,
doit être le même
en utilisant le détail.
Et donc, le plus difficile
est que, quand nous nous sommes
regardés maintenant sur comment
se résoudre les projets
poly-repo,
c'est-à-dire que c'est
que vous êtes utilisant un
Kubernetes Helm,
ou que vous êtes utilisant Terraform,
ou quelque chose d'autre.
Comment vous créez ça,
pour que ça se regarde
comme l'envier de l'envier de l'adresse
classique,



ответivise,

l'éUpp or le
c'est normal.
Je pense que c'est plusieurs
en difficulté.
Another motherboard
to be
technically
less
predominant.
Donc Daytona, automatiquement, il y a plusieurs niveaux.
En producteur entreprise, il y a un niveau de team, un niveau de team et une organisation,
c'est-à-dire niveau.
Et donc, vous pouvez mettre des quies de SSH et des variables environnementales
dans un de ces niveaux.
Et il y a aussi des niveaux de projet, pardon, il y a plusieurs de ces.
Je l'ai oublié aussi.
Donc, moi, comme un usuaire, je peux le définir pour moi et je vais être injecté dans chaque workspace.
Et puis, quelqu'un qui a un team peut le définir pour le team et ça sera injecté dans le workspace.
Ou quelqu'un qui a un projet pour ce projet, et ça sera injecté.
Donc, oui, on le déploie tout ça, donc c'est le plus facile possible pour le développeur.
Oui, je trouve que c'est une frustration assez commune avec tout le company.
C'est comme, oh, ici c'est un file environnemental, on va voir comment on partage ça.
Et beaucoup de les entreprises qui ont travaillé avec, recentement, ont été un peu unifiées
et on a des questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions
sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les

questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur





les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions
sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les
questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur les questions sur



des environnements, des environnements de château,
où ils peuvent faire ces tests,
à moins un,
pendant que vous, comme un humain,
travaillent avec eux.
Et donc, comment ils se réservent?
Et je ne pense pas que vous le réserviez par la main
en place d'un humain,
mais ça sera un service
que le curseur n'aura pas de...
On peut peut-être utiliser nous,
quelqu'un d'autre,
construire leur propre, ou autre.
Mais je crois que c'est le seul moyen
de se réservier à ce problème.
Ça me fait plaisir
que d'autres intéressants,
c'est un peu parallèle,
un peu différent,
qui sera un problème,
de savoir
que l'AIS a accès à ce service.
C'est une autre raison
que je pense aux containers de décembre,
surtout quand vous vous entrez
dans des contacts interpris.
Vous vous dites,
on comprend
leur valeur
en avoir un service de service
ou un composant
dans notre infrastructure,
ou quelque chose
pour aider nos travailleurs
à se faire vite.
Mais il y a des parts
de recode
qui sont,
peut-être,
auditées
et sont supposées
être très secrètes
et que vous voulez
les traiter très séparément
que d'autres parts
de votre base de recode.
Et
juste avoir le contrôle
de l'accès
et de l'indexing
et de
comment ces choses
interagissent
avec votre infrastructure,
je pense,
c'est probablement
un autre challenge
parce que si vous avez
un développeur
dans votre équipe
et qu'ils sont
en train d'éliminer un agent
en utilisant
un autre outil
sur le code
sur leur système de file,
c'est peut-être
un accesse de la full scale
à ce que ce soit
le système de file
qui est en train d'établir.
Donc,
il semble qu'il y aura
un futur
de
comment
l'AI
interagisse
à un scale d'interpréhensible.
Et je suspecte
que beaucoup de ce que
le défi
de la conteneur
est un peu
aidant à
l'accès.
Mais je suis curieux
de voir vos conseils.
Oui, absolument.
C'est quelque chose
que vous devez penser.
Donc,
une des valeurs
auxquelles nous avons dit
que la la sécurité
de la management
est de quoi
le développeur
peut faire
ce qu'ils ont accès
à,
ce qu'ils ont repos
pour les réposer
dans ces différents environnements.
C'est similaire à ça.
À chaque
essentiel,
et c'est
une très
nouvelle chose
qu'on pense
à chaque
user
qui aussi
doit
avoir des credentials
spécifiques
pour leur AI
de l'engineur.
Ce que peut-il

pour accéder
à ce répôt
pour les réposer
à cette infrastructure.
Peut-il faire ces choses-là?
Et quand il fait ces choses-là,
vous savez
que celui-là l'a fait.
Donc,
a-t-il
l'aie de l'avion
ou
l'avion de Justin
ou
l'Angeur?
Qui l'a fait
et qui a accès à ce qu'il a accès?
Essentiellement,
est-ce que ce soit
une autre personne
dans votre
contrôle de contrôle de roule
ou peut-être pas?
Mais il y a
un espace
dans le produit
où vous vous définissez
ce que l'humain
peut faire,
spécifiquement,
et ce que l'on peut faire.
Et puis,
ce que l'avion de l'avion peut faire,
c'est de se faire
pour être sûr,
comme vous l'avez mentionné,
qu'ils ont accès à,
qu'ils se couvrent,
qu'ils se déploient,
qu'ils se contrôlent.
Ce qu'ils vont faire
est très, très intéressant.
Et c'est une des choses
que vous ne pourrez pas
se faire
encore
comme un produit SaaS
pour ces grandes entreprises
parce qu'elles sont très,
très scères
de ce qui peut arriver.
Oui.
C'est très fascinant
de vous penser.
Donc,
vous avez
travaillé sur ce problème
de les environnement de développement
dans plusieurs formes
depuis plusieurs ans.
Donc, en regardant ce que vous savez,
et où vous êtes,
quand vous pensez
sur comment on réétonnera
l'influence de l'avenir,
ou comment vous interfacez
avec l'environnement de développement
dans l'organisation,
ou tout ce qui peut être.
Qu'est-ce que vous pensez
que ce sera les plus grands changements
que nous allons voir
dans les prochaines 5 ans?
Je parle beaucoup de gens
sur ce problème.
Et il y a
beaucoup de gens
qui ont des différents
réponses sur ce qu'ils pensent
seraient le futur.
De ce que je suis dédié,
je pense que c'est
deux
qui sont très similaires
à ce que nous avons aujourd'hui.
Donc,
maintenant, nous avons
l'IDE,
le texte éditor,
ou quelque chose.
Et je pense que ça
sera là
pour les prochaines 5 ans,
pour sûr.
Il y aura des variations,
il y aura des nouveaux
réputés.
Mais je pense
que c'est
où ça va.
En même temps,
il y aura des
nouvelles...
Ils peuvent même
exister
dans le sens de
des choses de la code
de la mode.
Donc,
une app de webflow
type,
qui n'est pas pour
les développeurs
et le sens d'égin.
Mais c'est pour les gens
qui veulent faire des choses.
Peut-être que ça existe.
Mais je pense que c'est
un verdict différent,
un verdict de la mode de code
de la mode de code.
D'ailleurs, ce n'est
pas un nouveau interface.
Le autre,
c'est juste
créer des problèmes,
comme des textes de plainte,
naturels,
comme l'anglais,
ou quelque chose.
D'où c'est
ici,
un ticket,

ici c'est ce qu'on doit faire.
Et l'AI
va se faire
et se défendre.
Je pense que c'est
le le 보통 de laенить
de quel Je missions,
aller faire ces choses
et donner un barbecue
sur ce pipeline.
adapter
rel Bonsoir
je crois que
ce Surmi
dans le milieu, je ne pense pas qu'il y ait un endroit dans le monde.
Je peux dire que je suis d'accord avec ça.
Je peux absolument être d'accord avec ça.
En étant dans un espace, j'ai construit un couple de versions d'ID.
Les seulement entreprises qui ont réussi,
les seulement entreprises qui ont réussi
dans les dernières années de créer un ID ou un éditeur texte,
sont Microsoft.
Et c'est parce qu'ils ont mis beaucoup de support financier
pour avoir fait ça, parce que c'est partie de leur mission d'envoi.
La autre compagnie, qui est là, c'est JetBrains,
qui a été chacune pour longtemps,
et qui a été réussie.
Mais avant ça, vous avez Eclipse et Visual Studio.
Je ne vois pas d'autres entreprises qui sont venus,
même si nous avons vu beaucoup de entreprises créant l'ID AI.
Ça fait du sens d'une perspective de temps de développement.
Vous voulez avoir cette interface,
mais c'est une interface expensive pour avoir.
Vous avez une interface expensive pour avoir,





Vous avez une interface expensive pour avoir.
Vous avez une interface expensive pour avoir.


Vous avez une interface expensive pour avoir.
Vous pouvez me dire que je ne vois pas d'autres entreprises
qui sont venus pour avoir.
Parce que c'est un feature AI.
Je ne sais pas, mais c'est mon take.
Je l'ai personnellement essayé de changer de curseur,
mais je ne vois pas de valeur.
Ça prend un grand nombre d'amount de valeur pour moi
de dire que je vais mettre mes 8 ans de la code VS
et de la memoire de la muscle.
Je vais essayer de apprendre un nouveau tutoriel.
Et même sur ça, un curseur est un fort de VS.
C'est la plupart des VSC.
Et des gens dans notre équipe,
les mots étaient curseurs de shinier
ou des variations.
Il y a trop de choses.
Ils ont fallu retourner à either copilot
ou continuer de dev, avec sonnet,
et ça fonctionne comme ce qu'ils ont besoin de faire.
On peut faire ça sans que le interface soit trop obtrinée.
On peut être de l'anage de plus en plus,
mais je pense que c'est un long et long
de battre pour arriver là.
Je ne pense pas qu'il y a un payoff.
Mais je n'ai pas été d'accord.
C'est intéressant.
J'ai joué sur un curseur pour un temps
et une expérience très bonne.
Je pense que
beaucoup de ceci dépend de la construction

et de la capacité, la vitesse et la price.
Si la capacité continue à augmenter,
la suffisamment de la correcté et la réponse
continue à se faire mieux,
on va être en train de regarder un monde différent.
Ma expérience de curseur
est la grande chose
qui me donne un plus grand plus de plus en plus.
C'est un plus de plus en plus.
Je suis en train de renoncer un élément
et un émet de plus en plus.
Tout le renoncer et tout le renoncer.
Les choses comme ça sont plus puissantes.
Mais je pense que,
comme vous l'avez dit,
Yvonne,
quelle est la future de collaboration
sur les équipes,
et surtout avec des contributaires non-techniques
ou des contributaires en haut,
qui créent un problème sur un repos
et qui ont un premier pass de PR
qui est auto-régeneré par un système
qui,
qui,
qui, en quelque sorte,
détecte des détecteurs
qui tentent de se résoudre
et qui donnent un PR
pour les développeurs
et qui ont une valeur de valeur
qui est en train de se déterminer.
Mais je pense que
beaucoup de choses dépendent
de,
peut-on avoir plus d'influence
qui n'est pas tout cloud-based?
Est-ce que nous pouvons faire le prix?
Parce que
l'intervention
peut être assez expérimentée
avec ce truc maintenant.
Et évidemment,
c'est un très ressort intensif
en termes de la coste pure d'énergie.
Et je pense que si nous nous scalez
à la industrie générale,
c'est un peu...
Les prix sont vraiment dépressés
maintenant parce que
c'est un peu comme des sub-sédations
de VC,
mais c'est intéressant de voir
où ça va
et si nous pouvons maintenir
ce prix ou
l'innovation
qui réduit
l'efficience.
Il y a beaucoup de spectacles,
il dépend de
si les lignes de scale sont stilles.
On a vu la curve et on n'a pas vu
tout le monde.
On a vu
que les modèles
ont été dans un endroit similaire
quand on regarde le graph.
Donc, on va faire la loi de scale
et si ils l'applirent,
ça fait du sens.
Mais si ils ne l'ont pas,
je ne sais pas.
Mais si ils ne l'ont pas,
les prix de tokens vont être
sur le point.
Et puis, on va aller au lieu
où je vous ai mentionné,
vous allez probablement
faire un certain nombre de modèles
qui ont un agent
qui a des modèles
qui sont très petits
qui sont très bons à un certain point.
Et puis, vous avez un type de devops
qui est en train de
faire des codes AI,
ou d'autres.
Et si vous vous rendez à ce point,
les prix de tokens sont super petits.
Parce que les prix de tokens vont être
sur leur propre,
mais aussi, les amountes qu'ils vont utiliser
seront super petits, parce qu'ils vont être
très, très finis pour un cas de utilisation spécifique.
Et je pense que ça
s'occupe
quand la loi de scale
sort de s'y couper.
Parce que la seule façon que vous allez
aller au niveau de la succession, si vous êtes un curseur,
c'est de
les connecter ensemble et de
se faire la meilleure façon possible.
Si les lois de scale continuent à se faire,
c'est la plus grande la la la la la
c'est la plus grande, et ça fonctionne.
Et puis vous allez payer pour la compute.
Je pense qu'il y a quelque chose à être dit
selon comment le futur continue
de se produire. C'est comme ça que nous avons ces choses.
Il y a une analogie, je suis un petit peu
en vidéo games comme des enfants, des consoles,
j'ai vu les générations, et c'est toujours
intéressant. Consoles ne sont pas que
beaucoup, je pense, je ne sais pas.
Mais, quand vous avez
le premier jeu vidéo, sur Super Nintendo
ou PlayStation 1, ou tout ça,
les graphiques sur ça, comparé
à la dernière, c'est la crèpe.
C'est parce que vous pouvez figurez
ce que vous pouvez faire avec ces hardwares
en temps, parce que c'est
le seul hardware que vous avez.
Et ce n'est pas absolument le même, ne me le dis pas.
Je ne pense pas que c'est le même argument
pour ce qu'on parle de code AI,
mais si les lois de scale ne s'appliquent
ou ne se produisent pas assez,
il faudra en faire de la meilleure
façon de faire des modèles multiple
pour pouvoir faire la prochaine
qualité de la jump, pour pouvoir
l'utiliser sur tout ce qu'ils font.
Et je pense que ça
croyait la créativité,
pour que ce soit la fin de la
vidéo, que les vécis puissent
payer, et que nous pouvons tout faire
parce que nous sommes en train de faire
le mien et de prendre le plus
expensif. Et à un moment,
le code AI sort de la paix,
ou le code de scale ne s'appliquent,
nous allons donc avoir la créativité
qui sera la plus grande créativité
pour tous les ingénieurs.
C'est un moment incroyable,
on va voir si tous nos doigts se sont en train de se faire

Donc ça nous rapporte pour nos questions
sur cet épisode. Merci pour les
commentaire, c'était un très intéressant
regard pour les envirations de la devine
et pour pouvoir prendre votre cerveau
depuis que vous avez été dans ce space
pour deux décennies maintenant, c'est super
intéressant. Merci pour les commentaire.
Je suis super heureux de vous être ici, merci
pour tous les deux, c'était un honneur
d'être sur un de nos podcasts,
je l'ai apprécié
tout le temps, j'apprécie
Merci Yvonne, merci pour votre soutien
et je vous souhaite un
nouvel épisode de New York, toujours
une bonne fois.