Podcast

Partnerem tohoto podcastu Datatalk je K-Tone Networks. K-Tone Networks je globální technologická firma s kořeny v Izraeli a pobočkou v Praze. Jejich zakladatel a CEO Shlomo Kramer je legendou v oblasti kybernetické bezpečnosti. Založil firmu Checkpoint, byl prvním investorem v Palo Alto Networks a nyní disruptuje trh se síťovou bezpečností právě skrze K-Tone.

K-Tone Networks nabízí platformu pro zabezpečení sítí postavenou na cloudu a umělé inteligenci a je lídrem v Gartnerem nově definované kategorii SAS-E, což je Security Access Service Edge. Díky tomu stále roste i při současné evaluaci v miliardách dolarů o desítky procent ročně.

Vy máte možnost se na tomto zázraku podílet. Pražská pobočka totiž raketově roste a nabírá IT profesionály různých zaměření. Samozřejmě jim nabízí i ESOP, neboli zaměstnanecké akcie. Pokud tedy hledáte novou výzvu, baví vás řešit náročné IT infrastrukturní problémy a chcete udělat svět o trochu bezpečnější, podívejte se na volné pozice v K-Tone Networks.

A nyní k samotné epizodě.

Dobrý den, moje jméno je Jirka Vicherek a vítám vás u dalšího dílu podcastu Datatalk. Mým dnešním zvláštním hostem, který k nám přijel až z daleké Kalifornie, je Vašek Mleňský, zakladatel a CEO jednoho z nejžhavějších českých startupů Eat2Be. Ahoj, Vašku.

Ahoj, díky za pozvání.

My se dneska podíváme znovu na Eat2Be. Naposledy tady byla kolegyně Terka Tíškova, ale už je rok 2024, takže po roce a půl si uděláme důležitý a vyčerpávající update, jak se Eat2Be daří, co vlastně dělají a jak se to celé posunulo. Jak se posunul i jejich AI stack, protože stavíte AI infrastrukturu.

Pro mě by bylo dobré začít úplně na začátku, protože příběh Eat2Be se zdá magický. Přesně jako „too good to be true“.

Jo, přesně. Ta špička ledovce, kdy řekneš, že kluci mají Series A za necelé dva roky, totálně hypeované, tak já bych se rád podíval na to, co tomu předcházelo, protože to tomu dává důležitý kontext. Tak kde to u tebe vlastně začalo?

Jo, to je ten známý overnight success, ale to overnight trvalo šest let. My jsme Eat2Be založili s mým spolupracovníkem Tomem v roce 2023, někdy v březnu, ale předtím jsme už asi čtyři až pět let dělali primárně devtooly. My se známe přes osmnáct let ze střední školy, z Gimplu.

Konkrétně před Eat2Be jsme vždycky dělali devtooly, protože jsme chtěli řešit vlastní problémy jako vývojáři. A přímo před Eat2Be jsme dělali něco, čemu jsme říkali devbook. To mělo za cíl změnit, jak vývojáři používají dokumentaci. Nechtěli jsme, aby jenom četli dokumentaci, ale aby to bylo interaktivní prostředí. Šel jsi na web, tam měl připravený svůj sandbox pro ten devtool, kde sis mohl vyzkoušet, jak ho používat, aniž bys musel googlit různé věci.

To byla úplně první prototypová verze sandboxu, který dnes už je hodně jiný, ale který jsme použili při tvorbě prototypu Eat2Be.

Když jsme se bavili s Tomášem, znáte se teda z Gimplu, už tam jste dělali různé projekty. My jsme tehdy dělali hry, takže vždycky první věc, co chceš dělat, jsou hry. My jsme dokonce vydali i iOS hru pro iPhone už v roce 2013 nebo možná 2012 či 2013, což byl racing simulátor, kde se procedurálně generovalo prostředí. Byla to taková hra připomínající Flappy Bird, pokud si vzpomínáš. Jezdil jsi tam autem s trochu divnou fyzikou.

Potom jsme oba studovali informatiku, já na Matematicko-fyzikální fakultě, Tom v Brně na Masarykově univerzitě, ale ani jeden jsme studia nakonec nedokončili. Jsme dropouts.

Mezi tím jsme vždycky dělali nějaké projekty, většinou během prázdnin. Potkávali jsme se hlavně u mě v Praze a stavěli různorodé projekty, což bylo všechno od open source až po knihovny, které jsme potřebovali. Například já jsem stavěl knihovnu v C++ pro neuronové sítě, ještě před tím, než se objevily skutečné velké jazykové modely (LLM). Byl to takový mix čehokoliv, co nás napadlo. Hlavně šlo o zkoušení věcí a řešení různých problémů.

Od her jsme se posunuli poté, co jsem si ještě na střední přečetl esej Paula Grahama, ve které si uvědomíš, že programovat můžeš i něco jiného než hry, a že to může být ještě zajímavější. Tehdy jsme začali hodně přemýšlet o problémech, které lze řešit přes software.

Když mluvíš o Paulovi Grahamovi, vy jste se prý i mnohokrát hlásili do Y Combinatoru (YC). Pro mě jste teď takoví poster boys české startupové scény, takhle se to podle mě má dělat. To je vlastně cookbook, a vy to děláte opravdu dobře. Nemyslím si, že stačí jen chtít štěstí a pracovat, ale vidím, jak hodně chytrých a šikovných lidí nemá startupové základy 101, a u vás vidím, že klasický YC startup school opravdu žijete. A protože jste se do YC hlásili mnohokrát, zajímalo by mě, co všechno jste posílali a jaká byla vaše zkušenost?

Já si úplně nepamatuji všechny projekty, ale byly to třeba aplikace pro stavbu backendu jako low-code nebo no-code, taky podcastové aplikace. V jednu chvíli jsme dokonce dělali i AI už v roce 2018-2019, když AI bylo ještě takové začínající.

Konkrétně šlo o machine learning, deep learning a naše AI byla chatbot sidekick, kde jsi popsal svůj problém a on ti na základě toho, co bylo natrénované na code stackoverflow, vyhodil kód.

Do YC jsme se hlásili podle mého asi jedenáctkrát. Měli jsme přibližně tři interview, ale nikdy jsme se tam nedostali. Jednou jsme se hlásili už s E2B, a dneska je asi pět nebo šest firem, které jsou něčím podobné tomu, co děláme my.

Byli jste tedy na YC prostě ještě příliš brzo?

Přesně tak, bylo to „too early“. V YC pošlou i po interview letter odmítnutí, kde píšou, že se často mýlí, ať jim dáš vědět, pokud si myslíš, že se mýlí. Já jsem jim před rokem napsal, že they were actually wrong, že to rosteme a jde nám to dobře. Odpověděli mi hezky „Good for you“. Ale byla to taková malá forma zpětné vazby a učení. Když zkoušíš dvanáctkrát, smysl to dává.

Další věc, která mě fascinuje na E2B, je, že jste US-based company. Od začátku jste v San Franciscu, trávíte tam většinu času, snažíte se to maximalizovat. Jste tam, kde se to děje, a v AI je to právě ta pravá lokalita. Zdá se, že jsi tam vždycky chtěl být, a teď to navíc dává ještě větší smysl. Nebo vždy to tak bylo?

Myslím si, že je důležité být tam, kde jsou tvoji uživatelé. Kdybych zakládal módní značku, tak být v San Franciscu asi nedává smysl, pokud se neorientuje na zakladatele startupů. Ale pro nás to dává obrovský smysl, protože naši první uživatelé byli často právě YC firmy a zakladatelé v San Franciscu.

Od roku 2022, 2023 začal tam vznikat AI hub, kde lidi stále hledali, jestli bude in-person, nebo ne, po covidu se nejistota vracela. My jsme ale viděli uživatele a byli jsme tam už jednou díky jinému online akcelerátoru Pioneer, kde jsme to San Francisco krásně mohli zažít.

Je to tak. Ta atmosféra tě opravdu změní, jak přemýšlíš.

Přesně tak. Když to chceš říct trochu arogantně, tak když si v Praze, tak je to jedno, vyřešíš to doma na počítači. Ale přijedeš do San Francisca a tam je 10, 20, 30 firem, co dělají to samé, a během šesti měsíců to množství vzroste desetkrát.

Najednou je tlak obrovský, žiješ v bublině, což je sice výhoda, protože vidíš věci dopředu, máš momentum, můžeš vést zajímavé konverzace, které jinde nezískáš, ale zároveň máš pocit, že nevíš, jestli ten směr, co je pár kroků napřed, je správný.

Nicméně v AI je to podle mě hodně deriskované, že AI tu zůstane. Možná otázkou je, jestli hype trošku splaskne a dva roky bude klidněji, než pak se to zase rozjede ve větším.

Říkáš, že lidi a laťka v bublině jsou velmi nároční. Když jste byli poprvé v San Franciscu, určitě jste narazili na úžasnou bublinu, to muselo být zásadní.

Ano, nějaký uživatel na internetu před lety sdílel formuli: špatní zakladatelé a špatný trh = žádný úspěch, skvělí zakladatelé a špatný trh = průměrný úspěch, špatní zakladatelé a dobrý trh = velký úspěch, skvělí zakladatelé a dobrý trh = úžasný úspěch.

Trh je něco, co nemůžeš úplně ovlivnit, ale můžeš hledat správné načasování a sledovat trendy trhu. Pokud zkoušíš šest let různé věci, jsi v devtool trhu, a najednou vidíš, že přichází AI a první lepší modely jako GPT-3.5, které umí lépe generovat kód, můžeš si udělat predikci, kam to směřuje.

Do určité míry jde o správný čas na správném místě, ale ovládáš to, kde jsi ty a jak myslíš.

Zvolili jste nádherný trh, na druhou stranu je to také nejnáročnější trh.

Co tedy bylo MVP Eat2Be? Čím jste začínali a co používali první uživatelé?

My jsme si dali pauzu od devbooku, někdy v březnu 2023, a postavili jsme něco jako „Cursor“ – agenta CloudCode/kurzoru (lovable pro backend). V té době modely ještě nebyly dostatečně dobré na generování celé codebase, a proto jsme potřebovali model někam pustit, spustit ten generovaný kód a ověřit, jestli opravdu funguje.

Proto jsme použili náš první sandbox, se záměrem, že agent bude jen jedna funkce – feature.

Já jsem hodně postoval na Twitteru demo toho, co stavíme, a jedno z nich získalo značný ohlas, dokonce ho retweetoval CTO OpenAI Greg Brockman. To byla opravdu dobrá traction.

Začali jsme experimentovat, ale rychle jsme si uvědomili, že mnohem zajímavější je stavět sandboxy než agenty. Protože agenti budou jen funkcí v softwaru, stejně jako dnes máme databáze.

Velmi silná byla kombinace obrovského množství kódu na internetu, který lze rychle ověřit, jestli funguje, a schopnosti LLM generovat kvalitní kód. Navíc jsme si uvědomili, že je nutné těmito sandboxy spouštět AI generovaný kód, protože nevíme, co kód dělá.

Začali jsme přemýšlet, že kód by mohl být univerzálním jazykem LLM pro dosahování různých cílů, bude sloužit ke stavbě softwaru i automatizací.

Postavíme tedy sandbox, který bude nejlepší prostředí pro spouštění AI generovaného kódu a zároveň nejlepší prostředí pro AI agenty, kteří budou založeni na dynamickém generování kódu.

Proč AI generativní kód potřebuje vlastní sandbox?

Technicky můžeš kód spustit i lokálně na počítači, ale sandbox v cloudu ti dává možnost běžet hodiny či dny, spouštět více instancí bez přítomnosti člověka.

Důležité je i to, že prostředí musí být izolované, aby neovlivnily produkční kód a navzájem se neovlivňovaly různé agenti.

Zároveň chceš mít offshore přehled o tom, co se děje, protože nevíš, co přesně agent udělá – hrozí prompt injections nebo nečekané chování.

Vysvětluji si to tak, že si představíš, že do týmu přijde člověk, kterému chceš dát co nejvíc nástrojů, aby byl efektivní, ale je velmi nepředvídatelný a nevíš, co udělá.

Ideálně bys mu dal root access, ale kdyby smazal root folder, tak by to nemělo nic způsobit, protože má připravená další izolovaná prostředí.

Takto přemýšlíme o agentech a sandboxu – je to prostředí bezpečné, kde agent může dělat, co chce, ale izolované.

Na to navazují i vyšší, více sofistikované funkce, které jsou specifické pro AI.

Proč současné standardní sandboxy nefungují na AI agenty?

Dnes se především používají kontejnery, které ale nikdy nebyly dělané k izolaci, ale k přenositelnosti aplikací.

Při spouštění nespolehlivého kódu (tj. AI agentů) v hyperscale cloudech jako Google nebo AWS čelíš pravidelným bezpečnostním zranitelnostem, kdy se útočník může dostat z kontejneru na hostitelský systém nebo do dalších kontejnerů.

Proto používáme virtual machines, konkrétně malou virtual machine jménem Firecracker od AWS, kterou jsme si upravili a vlastníme fork.

Firecracker má vlastní Linux kernel a celé prostředí je izolované, přičemž dokážeš řídit, co která instanci dovolíš či zakážeš.

AWS toto vyvinulo původně pro spouštění lambd a fargat – untrusted code – takže je to robustní základ.

V našem vlastním developu máme micro-virtuální stroj s plnou izolací a s ovládáním, například můžeš mít seznam povolených i zakázaných síťových requestů.

Navíc monitorujeme práci s filesystemem a informujeme uživatele, které soubory byly otevřeny či změněny.

V současné době přidáváme management secrets, abychom agentovi mohli bezpečně poskytnout přístup k API klíčům, aniž by došlo k jejich úniku do LLM nebo k uživateli volajícímu LLM.

To vyžaduje například nějaký formální...

Firewall nebo secrets vault okolo toho sandboxu dokáže ty klíče, tedy nějaké jako dummy values, vyměnit za skutečné správné hodnoty při síťové žádosti (network requestu). A teď to všechno zároveň musíš dělat ve velkém měřítku, což znamená, že to nespouštíš jenom v sandboxu. Když sandbox spustíš jednorázově, je to velmi jednoduché, ale najednou ho spouštíš desetitisíckrát a milionykrát za den a to ti začne ukazovat zcela nové problémy v distribuovaném systému. Bugy, které bys předtím vůbec neviděl, protože jsi nepracoval ve velkém měřítku, se ti začnou objevovat denně a potřebuješ to všechno dělat efektivně a rychle.

Obrovskou věcí je persistence, což znamená, že chceš, aby měl agent neustálý přístup ke svému sandboxu v cloudu a tento sandbox tam zůstal i tehdy, když ho agent zrovna nepotřebuje. Takže si představ, že máš MacBook, který zavřeš, odložíš a vrátíš se k němu za týden, otevřeš ho a všechno je pořád v paměti, ve filesystému, vše. Takto přemýšlíme o sandboxu, kam ho chceme dostat, a zároveň chceme využít výhod cloudu, takže si můžeš zvolit, kolik chceš CPU, RAM, kolik chceš diskového prostoru, napojit si různé volumes, více sandboxů běžících současně může komunikovat navzájem. Je to takové flexibilní cloudové prostředí pro agenta.

K tomu, co jsi teď popisoval, tedy problémům se škálou a rozdílu mezi tím, když si něco pustíš na localhostu versus mít to jako součást infrastruktury v otevřeném prostředí, třeba v cloudu, se ještě dostaneme.

Pojďme si říct: máte tedy nějaký základní MVP, sázíte na sandbox, protože vidíte, že to je unikátní. Zatímco agentů a podobných nástrojů bude spousta, ta hlavní funkce, ten základní podvozek, tedy infrastruktura, tu zatím nikdo nemá, a nikdo ji nedělá.

To mě hrozně baví, protože je to asi jeden ze základních principů: při zlaté horečce se prodávají krumpáče. AI je určitě zlatá horečka a vy jste přišli se skvělým krumpáčem. Ale určitě to nebylo jednoduché.

Když se teď vrátím do minulosti, do roku 2023, už jste věděli, že bude sandbox, co se děje pak a jak to stavíte?

Velkou část roku 2024 jsme strávili tím, že jsme vysvětlovali vývojářům, proč to dává smysl. Když se ohlédnu zpětně, často reakce v roce 2023 a částečně i v roce 2024 byla: „Proč to potřebuju? Nedává mi to smysl.“ A to bylo z velké části tím, že modely velkých jazykových modelů (LLM) nedokázaly generovat větší kusy kódu, větší části codebase.

Takže lidi to viděli tak, že pustí menší kódový snippet, například nějakou AWS Lambdu. Ale když se na to začal někdo více zamýšlet, řekne si: toto je to, jak to vypadá teď, ale nás nezajímá, jak to vypadá nyní, my stavíme pro to, jak to bude vypadat v budoucnu.

Toto přestane stačit ve chvíli, kdy LLM budou schopny generovat celé projekty. Samozřejmě trvalo nějaký čas, než jsme se do toho dostali, a my jsme hodně na začátku iterovali.

Velká komunita vývojářů je na Twitteru (nyní X), od začátku jsme byli open source, dělali jsme hodně příkladů v našem cookbooku, jak použít e2b a různé projekty.

A to si začali všímat vývojáři, ať už jednotlivci, nebo malé startupové foundry po dvou až třech lidech. Spousta z nich byla právě v San Franciscu, protože tam byla ta „bublina“. To je důvod, proč jsme od začátku chtěli být tam, protože mnoho uživatelů bylo právě v San Franciscu.

Hodně jsme s nimi iterovali. Na konci roku 2023 jsme zkoumali, jak power uživatelé používají e2b, protože řešili jsme otázku, proč to ještě neroste tak rychle, jak bychom chtěli.

Byly tam dvě hlavní skupiny použití. Jedna byla ta, že uživatelé spouštěli browser, který ovládal LLM, nebo spouštěli AI generovaný kódový snippet, který pracoval typicky s daty - například CSV souborem, Excel tabulkou.

To druhé, co bych nazval, je to, čemu OpenAI říká „code interpreting” (interpretace kódu), což je typická analýza dat. Výsledkem je, že LLM vygeneruje kód, který spustí nad daty, poskytne správné informace, když máš nějakou otázku ohledně dat, takže to je jako chat s daty, a navíc může vygenerovat i interaktivní grafy.

Nám se tento use case kódování velmi líbil. Browser nám přišel jako velmi snadný nástroj, nepotřebuješ nad tím moc přemýšlet, je jasné, že to bude dávat smysl a rychle se bude stavět infrastruktura pro AI browsery.

Kód je zatím ještě trochu nejistý, ale pokud to bude dávat smysl, nebo pokud LLM budou lepší, myslím, že bude zásadně více kódu generovaného AI než vznikajícího od lidí.

Tento potenciál nám přišel velmi zajímavý. A zároveň jsme měli pocit, že když vyřešíme úroveň kódu a prostředí pro kód, budeme schopni vyřešit i úroveň browserů. A nakonec se to všechno nějak sejde do jednoho.

Začali jsme proto a spustili jsme něco, čemu říkáme Code Interpreter SDK - malou nadstavbu nad naším sandboxem.

To jsme spustili na konci roku 2023 a začátkem roku 2024. Tehdy to začalo růst. Přišlo více vývojářů a začali si všímat, že sandbox se dá využít i pro jiné případy použití. Ty se pak začaly objevovat samy od sebe.

Začali jsme objevovat více a více případů použití společně s vývojáři.

A pak, když jsi v San Franciscu osobně, ptáš se uživatelů, co to znamená? Znamená to posílat jim formulář každý týden? Znamená to pozvat těžké uživatele na kávu do Starbucks? Je to kombinace všeho, protože startup na začátku může poskytovat support velmi osobně jeden na jednoho, což velká firma často nemůže.

Strávili jsme mnoho času tím, že jsme se potkávali s uživateli, vedle nich kódovali, co potřebovali, dělali PR do jejich codebase. Několik uživatelů podepsalo NDA, takže jsme dosáhli i na jejich interní codebase, tam jsme programovali, přidávali nové funkce.

Voláme s nimi, když se něco pokazí, když něco potřebují, píšeme si. Máme hodně kanálů na Slacku, více než 400 Slack Connect kanálů s různými týmy, odkud máme zpětnou vazbu prakticky denně.

Tyto kanály také slouží jako podpůrné kanály pro týmy, takže vidíme veškeré bugy a problémy.

Když se teď ohlédneš zpětně, co tě tehdy na té cestě překvapilo? Protože dnes to zní tak logicky, jako rozhodnutí, které nebylo jinou volbou, ale všechno bylo živé.

Byl to spíše každodenní postupný proces, nebo jsi zažil nějaký zásadní moment: „tohle mění všechno“?

Nemyslím si, že tam byl jeden takový moment. Ano, možná se to občas stane, ale to je vzácné. Je to spíš tak, že den za dnem vstáváš, pracuješ, a pak jednoho dne si řekneš „wow, tohle opravdu funguje“.

Když se díváš zpětně, je to jasné, ale v té chvíli, a to platí dosud, rozhoduješ s omezeným množstvím dat.

Když jsme se podívali na naše power uživatele, bylo jich vlastně pět, i když to působilo, jako by jich bylo sto.

Z toho tři dělali něco s kódem a dva s browserem.

A teď se musíš rozhodnout: kterou cestou půjdeš?

Je mnohem lepší, a to je zásadní, pracovat s lidmi, kteří jsou v pohodě s tím, že věci se rychle mění.

Je lepší zvolit nějaký směr, který bude špatný, a po měsíci to zjistit a směr změnit, než hledat perfektní směr, který nikdy nenajdeš.

Ve výsledku rychlost vždy vítězí nad správností, v 99 % případů.

To je přesně startupové know-how – jde o rychlost růstu, o akceschopnost, která je jedinou konkurenční výhodou startupů vůči větším firmám. Startup má agilitu, flexibilitu, rychlost.

Jak se to projevovalo u vás? Co to znamená v reálném životě a firemní kultuře? Koho nabíráš?

To zní možná jako ideál – mladé, dynamické lidi z rychle se rozvíjející firmy, s vysokou odolností vůči stresu, inteligentní a mající silný ownership.

To chce přece každý, tak jak to máte vy?

Myslím, že tvoje otázka má dvě části: co znamená rychlost a jak najít ty správné lidi. A myslím, že odpověď odpovídá tvému ideálu.

Rychlost vychází ze dvou věcí.

První je interakce s uživateli: nejen je kontaktovat a ptát se, ale také jim rychle pomoci.

Ve startupu neexistuje moc „business hours“. Po dvou, čtyřech lidech můžeš podporu dělat 24/7.

Samozřejmě později musíš prioritizovat, když už máš mnoho uživatelů, a možná dáš přednost těm, kteří tě užívají více, občas podle smluv.

Ale pokud uživatel používá produkt tak, jak by měl, nezáleží, zda jde o velkou enterprise firmu nebo jednotlivce o víkendu.

Všichni by měli mít skvělou zkušenost.

Musíš být nápomocný, proaktivní, komunikovat a rychle reagovat.

Další tlak přichází z okolí, například v San Franciscu, kde to dělají všichni – společnosti, které mají stovky až tisíce zaměstnanců.

Laťka a očekávání jsou tam někde úplně jinde.

Další věc, která možná překvapuje, je, že nejde jen o funkci klientské podpory nebo upsell usage.

Stále hledáš product-market fit (PMF).

Pořád jsi v kontaktu se svým trhem, abys věděl, jestli máš správný trh, správný produkt a kam jít dál.

Když nemluvís s uživateli, tak podle české či obecně evropské mentality je to „build it and they will come“ – prostě budeš sedět u kódu a čekat, že budou přicházet uživatelé.

Ale jít co nejrychleji k lidem a otevřeně komunikovat s trhem je klíčem vašeho ohromného úspěchu.

A co se týče product-market fit – je důležité ho neustále hledat, protože zvláště v AI se vyvíjí rychle.

Dříve jsi mohl mít PMF a produkt fungoval pět až deset let, dnes musíš přemýšlet, jestli ho budeš mít za tři nebo za šest měsíců, protože LLM se rychle vyvíjejí a mají stále více funkcionality.

Nestane se, že jsi nástrojem, který byl relevantní před rokem, ale protože modely jsou silnější a mají více funkcionalit, potřebují více nástrojů.

Agentové například potřebují přístup k GPU, další zdroje a musíš jim to zajistit.

Musíš vždy držet krok, být půl kroku až šest měsíců dopředu přemýšlet o tržních potřebách.

Občas se může stát, že „bet“ nevýjde – to je v pořádku – ale když modely umí, co potřebují, agenti jsou tam a můžeš ukázat vývojářům, že to funguje.

Já dnes chci s těmi lidmi komunikovat, protože tu hektiku v San Franciscu tvoří dva lidé, kteří staví něco, co dnes ještě není stoprocentní, ale za rok to bude velké a fungovat.

Můžeš dát příklad „bet“, která vyšla, a jedné, která úplně nevyšla?

Bet, která vyšla, je třeba Code Interpreter SDK. V roce 2023 fungoval tak, že vygeneroval kódový snippet, který fungoval ve 7 z 10 případů, a ve třech případech ne.

V tu chvíli, kdyby ses na to díval bez kontextu a budoucnosti, řekl bys, že to nedává smysl, a máš pravdu.

Ale nezáleží na tom, jak je to teď, ale jak to bude fungovat v budoucnosti.

Tato bet stále vychází a funguje.

Bet, která zatím úplně nevychází, ale myslím, že vyjde tento rok, je computer use. Vychází první modely, které mohou ovládat nejen browser, ale celý počítač s grafickým prostředím, spouštět aplikace, dělat úkony.

My máme sandbox, který umožňuje spustit grafické prostředí, kde můžeš aplikace používat podobně jako na MacBooku.

Toto bylo zatím hodně experimentální.

Ale poslední měsíc či dva vidíme výrazné zrychlení a zlepšení modelů v této oblasti, a myslíme si, že to bude velmi relevantní v nadcházejícím roce.

Co tedy teď musíme udělat, abychom byli relevantní platformou pro computer use?

Budeme to muset přepracovat, relaunchovat, podporovat různé operační systémy – nejen Linux a Windows, ale i MacOS.

To je příklad bety, která zatím nevyšla, ale může vyjít.

To je k rychlosti.

Teď si ukážeme ještě tým.

Uvědomil jsem si, že vy žijete v budoucnosti. Nejenže jste v Kalifornii, ve startupové bublině, ale také stále sledujete trh a stavíte něco, co bude relevantní za půl roku či rok.

Jak vidíš budoucnost? Vnímám, že je rozdělená nerovnoměrně.

Co jsou „safe bets“ ve tvé bublině? Co třeba u nás, v Česku, kde o tom ještě debatujeme, zda je to jisté?

O šest měsíců a patnáct kilometrů dál už je to realita a přítomnost.

V roce 2005 šlo hodně o to, že různé lovebills (prorůstové billiny) a produkty byly buildovány jako jednorázové projekty.

Postavil jsi MVP a pak jsi vývojáře najal, ale bylo problém postupně nad tím iterovat.

Myslím, že...

[Text končí zde.]

026 bude hodně o tom, že tohle prostě už bude fungovat. To bude vyřešený problém, ale zároveň ti agenti začnou být schopní budovat i části infrastruktury a najednou deploovat celé systémy a spravovat systémy sami. Agent bude z velké části jenom AI model a nějaké prostředí, kde ten AI model může fungovat. AI model má to know-how, to knowledge, a to prostředí je tam, kde používáš ty tuhle, to je ten sandbox, to je ten runtime, co stavíme my. A propojíš tyhle dvě věci a dostaneš velmi jednoduše funkčního agenta, kterého potřebuješ, kde pak…

Když to chceš mít ještě lepší, budeš na tom dělat asi nějakou nadstavbu a budeš tam pracovat s různými promptami a tak, ale myslím si, že modely jako víc a víc budou pohlcovat funkcionalitu různých AI frameworků. Vlastně bych čekal, že… No, když do toho skočím, tak to jsme viděli, že jo? Na začátku všechny RAG GPT produkty byly jen promptované, potom custom řešení pro RAG a najednou, že jo? Dejme tomu Google, když jsi na Google, tak tam jen zaškrtneš a on má ten RAG a má to všechno vyřešené a tak. Často mi tady nejvíc chybí to, že lidé ve San Francisku víc jako dělají… Představují si, jak ta budoucnost vlastně vypadá teď, ale přitom si představují, jak bude vypadat za šest měsíců. Vezmeš to, co funguje teď, a uděláš to jako desetkrát lepší v hlavě a řekneš si, jak bude ten systém fungovat, když už to fakt bude úplně autonomní, bude to běžet prostě dny a možná pak ne jenom dny – to poběží pořád a ty to nebudeš muset vůbec řešit. A nechceš na to koukat jako na jeden diskrétní bod v čase.

A to je podle mě to, co se tady děje. Podíváš se na to a vidíš věci, které teď nejdou, ale chceš si říct, kolik z těch věcí, co nejdou, je řešitelných v dalších šesti měsících či roce. To už je mentální cvičení, které si asi každý udělá sám, ale myslím, že jsme na cestě, kdy agenti už začínají fungovat hodiny bez problémů, poběží dny a kontext začíná být vyřešený problém. Bavím se vše u kódu. Počítačové využití si myslím, že bude velmi relevantní a myslím, že se hodně přesuneme od běhu kódu v cloudu či terminálu lokálně k běhu v cloudu. Vznikne hodně produktů, které budou jako UI nadstavbou nad tím a hodně lidí se bude ptát, jakou hodnotu může mít firma, když je to jen UI nadstavba nad tím. Ale bude to stejný příběh jako u Level, kde si všichni říkali, že je to jen GPT wrapper, OpenAI postaví to stejné a firma bude mimo byznys, ale myslím si, že to tak úplně nebude.

Co to znamená pro vás? Teď když zastavím a udělám to česky, podívám se na leden 2026 – jak jste velcí? Pokud jde o první e-to-bí, tak v tuto chvíli máme asi 16 lidí, asi za dva, tři lidé přijdou a máme podepsané smlouvy na další měsíce, takže dejme tomu, že se dostaneme na zhruba 20 lidí. To je skvělé. Když to rychle shrnu, vy jste po financování série A, po roce a půl, tak jste rejdžovali? My jsme rejdžovali v červnu 2024, získali jsme 21 milionů, celkem máme získáno 32 milionů dolarů. Super.

Ještě jeden vstup, který je pro mě neskutečný – jaké máte klienty? Mezi klienty máte Perplexity, Grok, Hugging Face, Manus. Manus teď koupil Meta. Meta, přesně. Grok koupil… no, Harnula koupila NVIDIA. My jsme to asi ani pořádně nezveřejnili online, ale další klienti jsou třeba Microsoft, Salesforce, Mistral. Chápu, koho nemáte, je možná lepší. Jak jste se dostali k takovým firmám? Spojeno to je s tím, že jste sanfranciská firma, máte tam nějaký hack, nebo to prostě děláte správně?

Ne, ne vždy je to tím, že jsi ze San Francisca. Někdy ti to pomůže otevřít nějaké dveře či diskuse, ale základ našeho produktu, a to si myslím u moderních dev tools, je, že máš dobrý self-serve. Vývojáři jsou chytří, a i CTOn nebo Head of Engineering byl vývojář, obzvlášť novější generace, a nechtějí jít přes sales call, aby začali používat nástroj. Chceš jim dát co nejvíc dobře napsaných, zpracovaných informací, aby si to mohli vyzkoušet sami. Máme desítky příkladů na našem GitHubu, open source příklady aplikací, různé open source knihovny, jak postavit YouTube agenty, datové analytické agenty, kódovací agenty.

Hodně cílíme na vývojáře na Twitteru (nyní X), kde je velká komunita, a to funguje velmi dobře. Chceš inspirovat vývojáře, například i Microsoft nebo firmy, kde máme kontrakt za 100 tisíc dolarů, začnou tak, že seniorní vývojář přijde na náš web, registruje se, projde dokumentaci, vyzkouší si něco a zjistí, že by to mohlo fungovat pro jejich případ použití, začnou to zkoumat dál. Potom vybuduješ Slack kanál, zavoláš si, vidíš, že jsou registrovaní, proaktivně oslovíš, zjistíš jejich use case. Vše vzniká z toho, že hodně lidí o nás ví, jsme v tom prostředí lídři, což musíš každý den potvrzovat tím, že dáváš stále víc technického obsahu ven, a vývojáři jsou chytří. Chceš zanechat pozitivní myšlenku v hlavě vývojáře, i když tě třeba teď nepotřebuje a jen zkoumá, jestli je nástroj k něčemu, nebo jak ho využít. Za šest měsíců se může dotyčný vývojář dostat do bodu, kdy už tě potřebuje.

To se nám stává běžně, že onboarding trvá tři až šest měsíců, protože prostě timing nebyl dobrý. Už o tobě ví, ale nemá use case. Je to tedy hodně o tom mít dobrý první krok, dobrý self-serve, a o tom dát o sobě vědět distribuováním technických příkladů a marketingem. Product-led growth je u nás hlavní typ růstu.

Zní to jednoduše, ale základ je mít product-market fit. Kdybychom jej neměli, můžeme dělat tutoriály, videa, obsah, kolik chceme, ale nemáme stickiness – lidé se nevracejí. Jakou roli v tom hraje open source? Aby se snížila bariéra, všichni jsou na to zvyklí, mohou se podívat do zdrojového kódu, což programátor nechce mít black box, chce vědět, co to dělá. Open source má několik úrovní, první je, že kolem toho buduješ komunitu, lidé se mohou podívat, co děláš. Je to také super, protože si to někdo může vzít, spustit u sebe, nepotřebuje k tomu povolení od tebe ani od firmy, protože běží u nich. Takto například začalo Manus.

Je to skvělé i v tom, že lidé ti reportují chyby, udělají fork a upraví věci, můžeš se na to podívat. Reálně se to děje? Ano, tím, že používají a nový lidé přicházejí, jsou i bugy. Více se to začalo dít až ke konci Q2 2025. Už je relevantní vědět, že nepodporuješ něco, co zanikne za tři měsíce, ale tvůj kód tam bude pořád. To jde ruku v ruce s tím, že trh zraje a edukace vývojářů se dostala na určitou úroveň.

To souvisí i s tím, že děláš videa nebo obsah. Product-market fit by sám o sobě nestačil, ale kruh je takový, že musíš začít dělat obsah, získat feedback, abys měl product-market fit. Feedback je základ, i když je špatný, víš, co nemáš dělat, nebo jak to měnit. Dostávat feedback je důležité. Musíš být jako houba, která přijímá všechny informace, být proaktivní, psát lidem e-maily, na Twitteru, posílat zprávy, „hej, vyzkoušej tohle, postavil jsem to“. Nebo jít ještě dál, postavit to přímo a poslat někomu, například vzali jsme váš open source agenta, dali na YouTube video, vypadá to super. Na začátku jsme hodně rostli integracemi s dalšími nástroji, vzájemně jsme si pomáhali i marketingem.

Co monetizace? Open source zní krásně, ale zároveň to snižuje momentum, protože konkurence se může inspirovat. Někdy je také složité nastavit tarify a řešit monetizaci.

Z mé zkušenosti se první zakladatelé, kteří nemají tolik zkušeností, často bojí open source kvůli konkurenci. Ale já říkám: „Pokud je to problém, pravděpodobně generujete miliony dolarů ročně a máte dobrý business, takže vás kopíruje AWS.“ Historie ukazuje, že i když se to stalo, například Elastic, který AWS zkopíroval, Elastic stále roste. Snowflake je částečně open source a generuje 80miliardový byznys.

Open source vnímám spíše jako unfair advantage. Chceš být transparentní, zvláště pokud je to něco nového a pracuješ s daty uživatelů, protože do sandboxu přichází spousta dat. Chceš vybudovat důvěru. Monetizace je taková, že si to můžeš spravovat sám, ale ne mnoho firem chce řídit vše samy. Chtějí začít self-hostem, ale jak systém roste, chtějí službu as-a-service. I když běží na jejich VPC nebo on-premise, chtějí nějakou formu „bring your own cloud“ nebo chtějí, aby to běželo u nich v cloudu, ale stále bylo spravované.

U enterprise dealů často začalo tím, že zákazníci self-hostovali, ale častěji používali službu. Nechtějí všechno zdarma, ale chtějí více funkcí. My máme některé high-level funkce closed source, ale API endpointy, na kterých stavíme tyto funkce, jsou open source. Pokud chceš, můžeš si celý stack postavit sám, ale proč bys to dělal, pokud to není tvůj produkt? Měl by ses soustředit na svůj produkt, ne na vylepšování infrastruktury pod tím.

To mě přivádí k otázce, jak se rozhodujete, co vyvíjet sami a co koupit, do čeho investovat? Kdy říct, že něco musí být vlastní duševní vlastnictví, například micro VM, které funguje skvěle? V jakých případech si říct: chceme si napsat vlastní Firecracker?

To je jedna z věcí, co už děláme – máme vlastní fork Firecrackeru, který upravujeme, stavíme přímo sandbox s lidmi, co na Firecrackeru a Firecrackeru pracovali. To víme od začátku, že jednou takový tým postavíme, protože chceme být v tomhle hluboko, to je základ naší inovace. Nejde jen o to, že chceme vlastnit tu technologii, ale chceme stavět nové funkce a nechceme být omezeni tím, že technologicky nevíme, jak to udělat.

Věděli jsme, že můžeme někam dospět i bez toho, že to budeme stavět sami, což na začátku chceš, abys optimalizoval rychlost, ale časem postavíš tým. Dívám se na to jako na mentální cvičení – představ si, že firma má nějaké inovační tokeny. Máš tři tokeny a už žádné další nedostaneš. Na co je chceš utratit? Jeden určitě na Firecracker. Druhý na AI funkce nad Firecrackerem, například jak vypadá sandbox pro reinforcement learning, když soupeříš s AI firmami nebo labouratořemi. Jak vypadá sandbox pro firmy jako Lavabo, co potřebují. To je další inovace, kterou stavíme, spolupracující se sandbox týmem, je to tým AI inženýrů, kteří musí rozumět agentům a jejich použití ve firmách.

A třetí token si necháváš na něco dalšího, zatím nevíš co. Nechceš ho utratit třeba na psaní vlastního frameworku pro tvorbu webu. Nedává smysl si psát vlastní Next.js nebo React. Prostě použiješ existující technologii. Nejlepší firmy přemýšlejí tak, že i když je náklad na tvorbu softwaru stále menší, software musíš udržovat. To je nejdražší část. Utratit token na vývojářský tým okolo kódu, to tě stojí nejvíce peněz a odvádí to od jiných příležitostí, na které by ses měl soustředit.

To je historie pokroku – stojíš na ramenou obrů. Máš cloud, AWS, stavíš na něm, nestavíš serverovnu ve sklepě. V jednu chvíli ale můžeš vyrůst natolik, že bude mít smysl postavit vlastní farmu. Farmu, ale ne ve sklepě. Atomovou elektrárnu. Pro většinu firem bude výhodnější vyvinout vlastního agenta a investovat spoustu práce spíše tam než do infrastruktury pro správu sandboxů.

Příklad – funguje to, když máš sto sandboxů denně, ale co když jich máš milion nebo deset milionů? Začneš řešit nové problémy, budeš potřebovat drahé vývojáře, a těch je na světě omezené množství. Takže statisíce dolarů za rok.

Když se podíváme na vývojáře, které jste už nějak oslovili skrze Firecrackery a open source, tak…
(…text končí zde)

Jak se ti daří udržet toto know-how, tu síť, tento způsob uvažování ve vaší organizaci a při jejím budování? Koho vlastně najímáte? Jedná se čistě o softwarové inženýry, nebo už i o AI inženýry, protože potřebujete znát agenty? Jde o několik rolí – jsou tu infrastructure engineers, což už jsou spíše distributed system engineers, dále potom obecnější inženýři, kterým říkám platform engineers, kteří vytvářejí funkce nad infrastrukturou. Pak jsou nízkoúrovňoví system-kernel engineers, kteří pracují se sandboxem a micro VM, a samozřejmě AI engineers, kteří staví naše SDK a musí rozumět trhu, tomu, jak agenti vypadají. Myslím si, že tu jsou také lidé z oblasti devrelu, kteří dělají příklady pro vývojáře.

Jaký stack je pro vás důležitý? Když je to VM, tak máme výjimku v Rustu, ale naše infrastruktura je napsaná v Golangu. Hodně backendově. SDK pak děláme v TypeScriptu a Pythonu. Dashboard je postavený v Next.js. Ten dashboard je stejně důležitý jako sandbox, protože tam je observabilita toho, co se se sandboxy děje, což je extrémně důležité při ladění, když agent nefunguje nebo se něco pokazí.

Zvláště v backendu bych řekl, že těch vývojářů, kteří umí distribuované systémy, není mnoho. Vývojářů se zkušenostmi s Firecrackerem je opravdu málo – těch, kteří ho i stavěli, je asi 15 až 20. Takže výběr není velký. Když na tyto role nabíráme, máme v týmu lidi, kteří byli výborní, i když například neměli zkušenosti s Golangem, ale uměli nad tím přemýšlet a rychle se doučili potřebné věci.

Myslím, že jedna z věcí, které hledáme, je člověk, který se dokáže sám zorganizovat, protože bude mít hodně samostatnosti – tým je pořád velmi malý. Člověk, který dokáže z chaosu vytvořit systém. AI prostředí se rychle mění, je tam chaos, každý týden jsou novinky. Stále si musíš v hlavě dělat zoom in a zoom out, jak to ovlivní byznys a produkt, jestli to, co stavíš, zůstane relevantní, jak se LLM stále zlepšují.

Takže tohle jsou dvě věci – rychlost a zároveň skill. Už se dostáváme do stavu, kdy si například můžeme dovolit nabrat i lidi, kteří ještě nemají úplně vysoký skill, jsou juniorní, ale vidíš, že za šest nebo dvanáct měsíců budou opravdu skvělí. A teď už si můžeme dovolit mít někoho takového v týmu, kde mu někdo může věnovat dostatek pozornosti. Aby ho práce bavila – protože jinak by byl hodně vystaven tlaku a kritice.

Pro mě je to hodně o práci s lidmi, protože nikdo nechce pracovat v týmu, kde nejsou kvalitní kolegové. To je taková ta známá rada „hire A players“, díky, ale já chci najmout B hráče, kteří se zlepší. Ale ve skutečnosti nechceš dělat kompromisy, chceš pracovat s nejlepšími lidmi a ti nejlepší chtějí pracovat s nejlepšími. A nakonec zjistíš, že nepotřebuješ sto lidí, ale třeba padesát, abys dosáhl dalšího milníku. A až bude potřeba více, tak to zase bude další krok.

Za poslední rok, dva to hodně firem pochopilo, že bylo hodně průměrných vývojářů. Ale to bylo i před AI. Podle mě AI to ještě výrazně prohloubí. V startupovém prostředí byl vždy jeden fullstack vývojář lepší než specializovaný front-end a back-end, protože nebylo tření, viděl celý kontext a mohl rychleji reagovat. Přijde mi, že vibe coding je teď jako ten samý princip, ale na steroidech.

Pokud víš, co chceš stavět, jsou nástroje extrémně silné, protože zároveň víš, jestli vygenerovaný kód je správný. Pokud dokážeš dát dobrý plán a nasměrovat vše správným směrem, může to být extrémně rychlý nástroj, který umožňuje i lidem, kteří nejsou technicky zdatní, vytvářet věci.

Například když máme interní dashboard a potřebuješ něco přidat, stačí na Slacku označit kurzorem, napsat, co chceš přidat, a kurzor to začne řešit. Dostaneš se tak třeba k 80–90 % toho, co potřebuješ, a posledních 10–20 % pak doptáš vývojáře, protože třeba potřebuješ přístup ke specifickému API, které nikdo interně pořádně nezná.

Pokud se bavíme o agentech, co používáte, co není standardní? Používáme standardní agenty jako kurzor, Devin, CloudCode, GitHub. Když máš GitHub, vidíš tam spoustu Copilotů, které pomáhají s code review a pull requesty. Lidé v týmu zkouší, co je lepší a co ne.

Pracujeme také na interním agentovi pro přehledové funkce, něco jako dřívější KPI dashboardy. Ten agent umožní otázky typu: jak vypadá retence za posledních sedm dní, jaký je nejaktivnější use case, nebo které jsou nejčastější support tasky na našem Discordu za poslední týden. Cílem je dát agentovi co nejvíce dat a umožnit týmu přístup k nim.

Vibe coding se implementoval jak do CI/CD, tak do osobní zodpovědnosti za kód. Každý si kód vytváří, recenzuje a komituje sám. Přitom máme formální code reviews, ale můžeš použít AI agenty jako pre-review. To je pro vývojáře v týmu nízkoprahová věc – označíš kurzorem, agent zkontroluje kód a často najde chyby, které jsi přehlédl. Člověk pak nemusí opravy znovu prověřovat a může se soustředit na fungování v kontextu celého systému.

Výzvou je předat agentům dostatečný kontext systému, zejména u větších distribuovaných systémů. Ale myslím, že to teď hodně tlačíme v týmu. Mnoho experimentů, které zvládnou i netechnické osoby, lze dnes dělat přes vibe coding, bez dalšího vývojářského času. Otevřeš labelu, uděláš experiment nebo prototyp, předáš to designérovi nebo vývojáři a ten už to pak dá do produkce.

Zdravím Jacka Soubustu, který říká, že vibe coding výrazně pomáhá jeho produktovým manažerům. Ti jsou už dost technologicky zdatní, chápou microservices, vědí, co lze rozbít, a znají kontext kódu. Dobře připravili gathers a kontext, takže si produktáci vytvářejí prototypy sami, testují je na uživatelích a pak říkají jen: „Chci to do produkce.“

Podle mě je hodně důležité mít jednoduchý interní přístup k API endpointům, protože existuje mnoho služeb, databází a dat rozesetých různě. Buď jsou všechna data na jednom místě, nebo máte dobře zdokumentováno, kde co je a jak k tomu přistupovat. Jakmile toto máš, můžeš s nimi pracovat prostřednictvím nástrojů jako kurzor, CloudCode nebo Labelu a můžeš stavět na tom, co potřebuješ.

Uvedu ještě poslední příklad: náš CTO, můj spoluzakladatel Tom, si postavil vlastní debugging a tracing software pro věci, které řešíme v Firecracker group, ve VMQ. Všechno je vibe kódované. Stačí mu „hodit“ trace a vytvoří si custom pohled na data, něco jako Datadog nebo Grafana, ale za odpoledne a zcela specializované a personalizované. To podle mě je budoucnost, kam směřujeme.

Myslím si, že software se stává často throwaway – tedy na jedno použití. Vidím to tak, protože mnoho lidí nezná Lean Startup teorii, kterou považuji za základ. Často potkávám zakladatele firem, kteří nečetli Lean Startup nebo YC Startup School, což jsou základy. Tento přístup malého produktu, který řeší jeden problém a ze kterého pak vyrůstá, začíná být stále důležitější.

Příležitostí dělat nové věci bude časem méně, protože podobné věci už existují. Například Datadog nebo Satismetry začínaly jako velmi jednoduché nástroje na jednu funkci. Teď stačí 12 minut v CloudCode, a hotovo. Nebudu přitom muset řešit bankovní smlouvy nebo další složitosti.

Dnes je kvůli efektivitě levnější programovat věci přímo, než o nich jen mluvit nebo psát dokumentaci. Dříve bys napsal dokument, ten sdílel s týmem, diskutoval, dnes už rovnou naprogramuješ demo a sdílíš ho nebo prototyp.

Podle mě by nástroje a vývojáři měli přemýšlet o tom, jak začít s co nejmenší bolestí a co nejméně překážkami, aby uživatel mohl svého agenta začít jednoduše používat. To je asi důvod, proč jsou agenti v terminálu dnes velmi populární – každý zná terminál, lze tam snadno něco nainstalovat (pip install, upget, brew install), a hned může začít psát příkazy a pracovat efektivněji.

Na závěr bych se tě rád zeptal, jak uvažuješ a jak funguješ v tomto hype období? Rok 2025 ukázal, že AI a LLM nejsou bublinou. Vibe coding a tento přístup minimálně demokratizuje IT a má skutečnou hodnotu. Přitom jsme bombardováni marketingem, jak od doomsayerů, tak pozitivistů typu „AGI přijde 21. prosince příštího roku“ a podobně.

Jak se v tom orientuješ, jak rozlišuješ signál od šumu?

To je dobrá otázka. Kdyby na ni byla jednoduchá odpověď, rád bych ji řekl. Myslím, že existují určité faktory – často něco začne oznámením nebo vydáním produktu. Pokud jde o technologii, kterou používají vývojáři, ti jsou často první, kdo s tím pracují a sahají ke kódu.

Dál se ptám, zda z toho vznikají nové knihovny, integrace do projektů, zda kolem toho vzniká ekosystém a jestli se o tom stále mluví na sociálních sítích. To jsou podle mě první známky, že to může být relevantní měsíc nebo čtvrtletí poté.

Také je důležité ptát se podle first principles, zda to bude dávat smysl i za předpokladu, že modely budou o desetkrát lepší, nebo jestli tím spíše přijdeme o byznys. Třeba AI frameworky v roce 2023 vypadaly jinak – dnes lidé používají spíše LangChain.

My nad tím přemýšlíme podobně – čím lepší jsou modely ve stavbě softwaru, tím je E2B (end to backend) relevantnější na trhu. Když se mě lidé ptají na největší potenciální hrozbu, není to, že AWS pustí vlastní sandbox – to mají i oni – ale spíš, že modely přestanou být lepší.

V současné době jsou modely už velmi dobré, například OpenAI GPT, a trh, ekosystém a tooling bude ještě nějakou dobu dohánět to, co je možné s nimi dělat, jaké UI postavit a jak je integrovat do aplikací. Postupem času se AI stane jen dalším softwarem – software bude AI a AI bude software, rozdíly zmizí.

Děkuji moc, že to říkáš, protože se mi líbí, že i když OpenAI modely nejsou porazitelné, neznamená to, že infrastruktura a služby pro nový svět s těmito modely nejsou otevřenou příležitostí. Vaše pozice na trhu je výborně situovaná, jste v nejvíce aktuálním prostoru, ale zároveň máte pozici, která je velmi dobře založená. To je jako mít krumpáč pro zlatokopy – i když cena zlata trochu klesne, lidé budou dál rýt. Nemusíš mít capex v řádu půl miliardy dolarů na nákup GPU, což je důležitá výhoda.

I z byznysového hlediska je to unikátní, protože je to typický cloudový byznys. My jsme se příliš nesoustředili na optimalizace, protože je teď důležitý růst, ale dosáhneš bodu, kdy margin je 80 až 90 procent a začneš optimalizovat infrastrukturu. SaaS má jiný margin než AI nástroje jako Kurzoru do hlavy – kdežto bez vlastního modelu je margin spíše 30 až 40 procent.

Stále je zde výrazná konkurenceschopnost, protože často utrácíme hodně za servery a kapacitu. Chceš elasticitu a přitom udržet byznys, který už má vyřešen mnoho před tebou.

Ještě jednou děkuji, že jsi dnes přišel do Datatelku, poodkryl spoustu tajemství a „secret sauce“, které nejsou tak tajné, ale jsou na trhu. Gratuluji k výrazné firmě, která to bere za správný konec, a fakt, že jste startup v rámci Y Combinator, znamená, že můžete růst o jednotky procent týdně. Tady máme jenom...

Malinko. Držím moc palce E2B, jsem velký fanoušek a doufám, že to půjde dál a výš. Jsem zvědavý, co zvládnete udělat a jaké další firmy budou E2B používat.

Děkuji moc a děkuji za pozvání. Děkujeme, že jste doposlouchali až sem, a děkujeme také našim stálým partnerům, členům Datatalk klubu.

Sazka, TV Nova, Direct Technologies, GoodData, Miton, Colors of Data, Bystreet, Flow, Karl Data Company a Intex. Díky moc za podporu a nechť vás provázejí data.