Když startup tvrdí, že postavil nový JavaScript runtime za dva a půl týdne, zní to skoro neuvěřitelně. Ještě odvážněji pak působí druhá část sdělení: bez Codexu by stejná práce zabrala zhruba rok. Přesně tak popisuje zkušenost Wasmeru jeho zakladatel a CEO Syrus Akbary Nieto.
Nejde přitom o drobnou interní utilitu ani o kosmetickou úpravu existujícího produktu. Wasmer pracoval na JavaScript runtime, který je schopný běžet na edge. To je technicky náročná oblast, kde se potkává výkon, bezpečnost, infrastruktura i velmi praktická otázka vývojové rychlosti.
Na celé zkušenosti je zajímavé hlavně to, že Codex zde nefiguruje jen jako chytrý doplňovač kódu. Syrus popisuje mnohem širší posun. Codex podle něj pomáhal s vývojem, odhalováním chyb a také s dlouhými samostatnými úlohami, na kterých mohl pracovat celé hodiny bez dalšího zásahu. Výsledek není jen rychlejší programování. Je to změna samotného způsobu práce.
Právě v tom je příběh Wasmeru důležitý. Ukazuje, co se stane, když se AI použije na skutečně složitý inženýrský problém, nikoli jen na zkrácení několika rutinních úkolů. A také naznačuje, jak se může měnit role vývojáře v době, kdy stále větší část implementace vzniká pod vedením člověka, ale nikoli nutně jeho rukama.
Obsah
- 🚀 Rychlost, která mění ekonomiku vývoje
- 🧩 Co Wasmer vlastně stavěl
- 🛠️ Proč padla volba na C++, když tým umí hlavně Rust
- 🐞 Codex jako nástroj pro hledání chyb, ne jen pro generování kódu
- ⏱️ Dlouhé samostatné úlohy mění způsob práce
- 💡 Od psaní kódu k jeho řízení
- 🧠 Co si z toho mohou odnést technické týmy
- 🌍 Proč je tento příběh důležitý pro budoucnost edge computingu
- 🔍 Co tento případ neříká, ale naznačuje
- 📈 Nová pracovní rovnice pro moderní inženýrství
- 🗺️ Kam se vývoj s AI posouvá dál
- ✅ Co si z příběhu Wasmeru odnáším
🚀 Rychlost, která mění ekonomiku vývoje
Nejsilnější výrok z celé zkušenosti zaznívá hned na začátku. Syrus říká, že Wasmer dokázal vytvořit JavaScript runtime za dva týdny až dva a půl týdne. Bez Codexu by to podle něj snadno zabralo jeden rok.
„Dokázali jsme vytvořit JavaScript runtime za dva týdny, dva a půl týdne. Bez Codexu by nám to snadno trvalo jeden rok.“
Tohle není jen efektní číslo. Ve světě startupů a infrastruktury znamená takový rozdíl zásadní změnu v tom, co je možné financovat, testovat a uvádět na trh. Když se vývoj kritické technologie zkrátí z přibližně ročního horizontu na několik týdnů, mění se hned několik věcí:
- Riziko projektu klesá, protože tým se dostane k funkčnímu výsledku mnohem dřív.
- Iterace jsou levnější, takže lze rychleji ověřit, zda zvolený směr funguje.
- Malé týmy zvládnou větší ambice, protože AI pomáhá přemosťovat omezenou kapacitu.
- Time-to-market se dramaticky zkracuje, což je u platformových produktů často klíčové.
Je důležité si všimnout, že Syrus nemluví o automatizaci jedné úzce vymezené činnosti. Nemluví o tom, že Codex ušetřil několik hodin při psaní boilerplate kódu. Mluví o něčem mnohem větším: o urychlení vývoje celé nové runtime vrstvy.
To je přesně ten typ změny, který může ovlivnit strategická rozhodnutí ve firmách stavějících vývojářskou infrastrukturu. Pokud totiž náročné systémy vznikají rychleji, mohou se týmy pouštět i do projektů, které by dříve odložily kvůli nákladům nebo nedostatku specialistů.
🧩 Co Wasmer vlastně stavěl
Středobodem celé práce byl JavaScript runtime schopný běhu na edge. Syrus to popisuje jako něco, co dříve nebylo možné. Tato formulace je stručná, ale velmi výmluvná. Naznačuje, že nešlo o obyčejné zabalení existujícího řešení, ale o technologický krok, který otevírá novou možnost nasazení.
Runtime je prostředí, které umožňuje spouštět JavaScript mimo samotný zdrojový kód aplikace. V praxi jde o vrstvu, která zajišťuje provedení programu, práci s API, správu prostředků a další základní chování systému. Pokud má takový runtime běžet na edge, naráží tým na vysoké nároky na efektivitu, stabilitu i architekturu.
Právě edge prostředí je dnes obzvlášť zajímavé. Vývojáři i firmy chtějí spouštět logiku co nejblíže uživateli nebo místu vzniku požadavku. To může přinést nižší latenci, lepší škálování a v některých scénářích i efektivnější infrastrukturu. Jenže vybudovat pro takové nasazení spolehlivý runtime není triviální úkol.
Na příběhu Wasmeru mě zaujalo, že se zde propojují dvě vrstvy inovace najednou:
- Produktová inovace v podobě nového JavaScript runtime pro edge.
- Procesní inovace v podobě toho, jak takový systém vznikal s pomocí Codexu.
Právě druhá vrstva dává celé věci širší význam. I kdyby měl každý tým jiné technické cíle, otázka zůstává stejná: může AI zkrátit cestu od nápadu k fungující infrastruktuře tak zásadně, že se změní samotná pravidla hry? Wasmer naznačuje, že ano.
🛠️ Proč padla volba na C++, když tým umí hlavně Rust
Jedna z nejzajímavějších částí Syrusova popisu se týká volby jazyka. Nová platforma vznikala v C++, protože právě ten byl pro daný účel ideální. Zároveň ale říká, že tým Wasmeru je ve skutečnosti expertní hlavně v Rustu.
To je velmi realistická situace. V moderním vývoji nebývá hlavní problém jen to, co postavit, ale také v jakém jazyce a s jakou odborností. Týmy často narazí na technologii, která dává architektonicky smysl, ale interně pro ni nemají stejné zázemí jako pro svůj hlavní stack.
Právě zde Codex sehrál důležitou roli. Syrus vysvětluje, že v C++ existují různé jemné nuance a subtilnosti, ve kterých tým nebyl expertní. A právě tyto věci dokázal Codex poměrně brzy odhalit.
Tahle poznámka je cenná, protože posouvá debatu o AI dál než k běžnému tématu produktivity. Codex zde nefunguje jen jako nástroj na rychlejší psaní. Funguje také jako pomocník při orientaci v jazyce, který tým neovládá na absolutní špičce.
To má hned několik dopadů:
- Tým se může pustit do technologie, která je pro problém vhodnější, i když v ní není nejsilnější.
- Riziko přehlédnutí typických jazykových pastí se snižuje.
- Znalostní mezera mezi expertizou týmu a požadavky projektu se dá překlenout rychleji.
Neznamená to, že AI nahrazuje hlubokou expertizu. Spíš funguje jako vrstva podpory, která zvyšuje jistotu při práci mimo hlavní komfortní zónu týmu. To je pro infrastrukturní firmy velmi důležité, protože ty často musí kombinovat více jazyků, knihoven a systémových vrstev podle konkrétního use casu.
🐞 Codex jako nástroj pro hledání chyb, ne jen pro generování kódu
Syrus výslovně zdůrazňuje, že Codex používali nejen k vývoji, ale také k odchytávání chyb. To je zásadní detail. Veřejná debata o AI pro programování se často točí kolem generování nového kódu, návrhů funkcí nebo automatického doplňování. Jenže v reálném vývoji bývá neméně důležité to, jak rychle tým dokáže rozpoznat chyby, rizika a slepé uličky.
V případě Wasmeru byla tato schopnost důležitá právě kvůli práci v C++. Když tým přechází do jazyka, ve kterém není doma tak silně jako v Rustu, nevzniká problém jen při samotném psaní. Komplikace se objevují i při revizi návrhů, hledání subtilních problémů a posuzování, zda implementace odpovídá záměru.
Pokud Codex dokázal tyto subtilnosti rozpoznat brzy, pak nepřinesl jen úsporu času. Přinesl také úsporu nákladů na pozdější opravy. V inženýrství totiž platí jednoduché pravidlo: čím dřív se problém odhalí, tím levněji se řeší.
V širším pohledu z toho vychází užitečný model využití AI ve vývoji:
- Generování návrhu nebo implementace.
- Průběžná kontrola problémových míst a slabin.
- Korekce směru dřív, než se chyba rozroste do architektury.
Tím se AI stává součástí cyklu kvality, nikoli jen rychlosti. A to je pro komplexní systémy mnohem zajímavější než prosté měření počtu napsaných řádků kódu.
⏱️ Dlouhé samostatné úlohy mění způsob práce
Další výrazná část Syrusova popisu se týká autonomie. Wasmer podle něj nechal Codex pracovat několik hodin v kuse bez jakéhokoli vstupu. A na konci dostal to, co potřeboval.
Tohle je mimořádně silné tvrzení, protože ukazuje posun od interaktivní asistence k delší samostatné práci na zadaném cíli. V tradičním modelu vývoje pracuje programátor v krátkých cyklech. Napíše kus kódu, zkontroluje ho, upraví, znovu otestuje a pokračuje dál. AI nástroj v takovém prostředí obvykle poskytuje malé návrhy v reálném čase.
Zkušenost Wasmeru ale naznačuje jiný režim. Vývojář neurčuje každý krok. Místo toho zadá směr, cíl nebo problém a systém pracuje delší dobu relativně samostatně.
Z toho plynou minimálně tři zajímavé změny:
- Vývoj se posouvá od mikrořízení k delegování.
- Hodnota člověka se přesouvá k zadání, hodnocení a směrování.
- Produktivita už není jen o rychlosti psaní, ale o schopnosti formulovat cíl.
To je pro mnoho týmů úplně nová dovednost. Nestačí umět dobře implementovat. Je potřeba umět přesně popsat problém, určit hranice řešení a zkontrolovat, zda výsledek odpovídá záměru. V praxi tak roste význam architektonického myšlení, prioritizace a kritického vyhodnocení.
Zároveň je fér dodat, že právě u takto dlouhých samostatných úloh bude kvalita zadání mimořádně důležitá. Čím delší běh bez zásahu, tím větší význam má to, jak jasně je cíl definovaný. Wasmer tím vlastně ukazuje, že AI nástroj není jen zkratka k implementaci. Je to partner, kterého je potřeba dobře vést.
💡 Od psaní kódu k jeho řízení
Možná nejzajímavější myšlenka z celého sdělení je tato: tým se podle Syruse začíná přesouvat mimo samotné IDE. Nezasahují tolik přímo do kódu. Spíš vedou systém tam, kam potřebují.
„Ve skutečnosti se posouváme mimo samotné IDE. Kódu se už tolik nedotýkáme, jen ho vedeme tam, kam chceme dojít.“
Tato věta hezky vystihuje hlubší proměnu vývojářské práce. Dlouhá léta byl základní jednotkou softwarové tvorby ručně napsaný kód. Vývojář seděl v editoru, psal, refaktoroval a detailně řídil implementaci. Nový model, který Wasmer popisuje, vypadá jinak.
Člověk stále zůstává klíčový, ale jeho role se přesouvá směrem k:
- formulaci cíle,
- určení architektonického směru,
- kontrole výstupu,
- průběžnému korigování systému.
To neznamená konec IDE ani konec klasického programování. Znamená to ale, že část práce, která byla dříve neoddělitelně svázaná s ruční manipulací se zdrojovým kódem, se přesouvá do vrstvy zadávání a vedení.
Z pohledu produktivity je to zásadní. Z pohledu identity vývojáře možná ještě víc. Čím dál méně může rozhodovat schopnost rychle a bezchybně napsat každou řádku ručně. Čím dál víc bude důležité umět:
- vybrat správný problém k řešení,
- zvolit vhodný technický přístup,
- popsat očekávaný výsledek,
- ověřit kvalitu výsledku,
- udržet systém v souladu s produkčními požadavky.
Wasmer tak nepřímo ukazuje, že AI nemění jen rychlost práce. Mění samotnou ergonomii vývoje.
🧠 Co si z toho mohou odnést technické týmy
I když zkušenost Wasmeru vznikla kolem konkrétního JavaScript runtime a konkrétního týmu, její poučení je mnohem širší. Vidím v ní několik praktických lekcí pro technické organizace, které chtějí AI zapojit smysluplně, ne jen jako módní doplněk.
1. AI má největší hodnotu u složitých problémů
Největší síla Codexu zde nevyniká na jednoduchých šablonách, ale na projektu s vysokou technickou náročností. To je dobrá zpráva pro týmy, které řeší infrastrukturu, runtime systémy nebo jiné hluboké technické vrstvy. Právě tam se totiž často rozhoduje o tom, zda projekt bude trvat měsíce, nebo týdny.
2. AI pomáhá překlenout jazykové a znalostní mezery
Wasmer je silný v Rustu, ale projekt dával smysl v C++. To je situace, kterou zná spousta firem. Codex zde fungoval jako podpůrná vrstva, která pomohla odhalit jazykové nuance dřív, než se staly problémem. To neznamená, že lze ignorovat expertizu. Znamená to ale, že se s menším třením dá pracovat i mimo hlavní technologickou doménu týmu.
3. Chytré použití AI není pasivní
Syrus nepopsal Codex jako kouzelné tlačítko. Popsal ho jako systém, který tým vede, zadává mu směr a nechává ho pracovat. Úspěch tedy nestojí jen na kvalitě modelu, ale i na schopnosti týmu určit cíle a vyhodnocovat výsledky.
4. Mění se definice produktivity
Dříve se produktivita ve vývoji často zaměňovala za rychlost implementace. Tady je ale vidět širší pojetí. Produktivní není ten, kdo napíše nejvíc kódu. Produktivní je ten, kdo dovede rychle dovést systém od zadání k funkčnímu a použitelnému výsledku.
🌍 Proč je tento příběh důležitý pro budoucnost edge computingu
Wasmer nepopisuje jen interní zlepšení workflow. V sázce je i širší technologický trend. Pokud AI dokáže výrazně urychlit vývoj runtime technologií pro edge, může to zrychlit i celé tempo inovací v této oblasti.
Edge computing bývá náročný z několika důvodů. Je potřeba řešit omezené zdroje, rychlé spouštění, efektivní běh a spolehlivost. Každé zlepšení nástrojů, které pomáhají takové systémy navrhovat a stavět, může mít násobný efekt.
Na příkladu Wasmeru je patrné, že AI může snížit bariéru vstupu pro ambiciózní infrastrukturní projekty. To neznamená, že se stanou snadnými. Znamená to ale, že menší nebo úzce zaměřené týmy mohou zvládnout něco, co by dřív vyžadovalo delší runway, větší rozpočet nebo specializovanější personální složení.
Právě to je na edge a infrastruktuře zásadní. Inovace zde často nevzniká tam, kde je největší počet lidí, ale tam, kde se podaří správně zkombinovat architekturu, výkon a rychlost exekuce. Pokud Codex pomohl Wasmeru zkrátit rok práce na několik týdnů, jde o víc než o působivou produktovou historku. Je to známka toho, že nástroje pro tvorbu hlubokého software se začínají výrazně měnit.
🔍 Co tento případ neříká, ale naznačuje
Na celé zkušenosti je užitečné i to, co mezi řádky naznačuje. Syrus nemluví o AI jako o náhradě týmu. Mluví o ní jako o násobiteli schopností. To je důležitý rozdíl.
Z jeho slov vyplývá, že rozhodující stále zůstává člověk:
- vybírá problém,
- volí jazyk a architekturu,
- pozná, co je „to, co jsme chtěli“,
- koriguje směr.
Codex pak přidává rychlost, kapacitu a pomoc s detaily, které by jinak vyžadovaly více času nebo hlubší specializaci. Tento model je velmi pravděpodobně bližší reálné budoucnosti vývoje než jednoduchá představa, že AI software sama „napíše“ a člověk už jen přihlíží.
Ve skutečnosti se role člověka spíš posouvá výš nad úroveň jednotlivých řádků. Méně času může padnout na mechanickou implementaci, více času na zadání, validaci a technická rozhodnutí. To je dobrá zpráva pro týmy, které chtějí budovat komplexní systémy bez ztráty kontroly nad jejich kvalitou.
📈 Nová pracovní rovnice pro moderní inženýrství
Když shrnu zkušenost Wasmeru do jedné rovnice, vypadá asi takto:
Silný technický cíl + AI, která zvládne dlouhé úlohy + lidské vedení = dramaticky rychlejší cesta k výsledku.
Na tom je cenné, že tato rovnice není o nahodilé úspoře času. Je o změně výrobního modelu software. Dříve mohl být úzkým místem počet zkušených inženýrů, kteří dokázali konkrétní systém ručně vystavět a bezpečně dotáhnout. Dnes může být úzkým místem spíš schopnost správně zadat úkol, zorganizovat iterace a poznat kvalitní výstup.
To klade nové nároky i na vedení technických týmů. Nestačí přemýšlet o tom, jaké frameworky nebo jazyky se budou používat. Je potřeba přemýšlet také o tom:
- jak zadávat práci AI systémům,
- jak ověřovat jejich výstupy,
- kde je vhodné nechat je pracovat samostatně,
- kde je naopak nutná přímá lidská kontrola.
Zkušenost Wasmeru tak nepůsobí jen jako zajímavý benchmark Codexu. Působí jako náznak nového operačního modelu pro software engineering.
🗺️ Kam se vývoj s AI posouvá dál
Pokud je možné během několika týdnů vytvořit JavaScript runtime pro edge a využít k tomu AI nejen jako pomocníka, ale i jako samostatně pracujícího partnera, pak se otevírá důležitá otázka: co bude dál standardem za rok nebo dva?
Už teď je zřejmé, že se posouváme od jednoduchého doplňování kódu k systémům, které zvládají delší pracovní kontext, odhalují chyby, orientují se v méně známém jazyce a pracují na komplexních úkolech po delší dobu. Wasmer ukazuje, že tento přechod není teorie. Je to praktická zkušenost z reálného inženýrského nasazení.
Nejzajímavější možná není ani samotná rychlost, ale změna mentality. Místo otázky „jak rychle to napíšeme“ přichází otázka „jak přesně to zadáme a kam to chceme dovést“. To je jemná, ale zásadní změna.
V takovém světě budou mít výhodu týmy, které dokážou spojit:
- silné technické porozumění,
- jasné zadávání cílů,
- disciplinovanou validaci,
- ochotu přenechat část implementace automatizovaným systémům.
Wasmer svým příkladem ukazuje, že tato kombinace už není vzdálená vize. Je to funkční přístup, který může přinést reálný produkt v čase, jenž by ještě nedávno působil jako sci-fi.
✅ Co si z příběhu Wasmeru odnáším
Když se podívám na celý případ jako celek, vystupují z něj čtyři hlavní závěry.
- Codex může dramaticky urychlit i velmi náročný vývoj, nejen drobné úkoly v editoru.
- AI může být užitečná i jako nástroj na odhalování chyb a jazykových subtilností, zejména když tým pracuje mimo svou nejsilnější specializaci.
- Dlouhé samostatné běhy mění charakter spolupráce mezi člověkem a strojem, protože člověk více řídí a méně mikroimplementuje.
- Budoucnost vývoje možná nebude o tom, kdo píše nejrychleji kód, ale kdo nejlépe vede systémy k výsledku.
To je na zkušenosti Wasmeru nejzajímavější. Nejde jen o působivý údaj o zkrácení času z roku na dva a půl týdne. Jde o konkrétní ukázku toho, že AI se ve vývoji software posouvá od role asistenta k roli spolupracovníka, kterého lze nasměrovat, nechat pracovat a následně jeho práci vyhodnotit.
A pokud tento model funguje při stavbě JavaScript runtime pro edge, je těžké nevidět, jak široký dopad může mít i v dalších oblastech moderního softwarového inženýrství.
