TypeScript przepisany na Rust za 420 tys. dolarów — i zrobiły to agenty AI

O czym jest ten film

Theo ogłasza TSC RS (TypeScript Rust): kompletny port kompilatora TypeScriptu, sprawdzarki typów i serwera LSP do Rusta, dostępny jako zwykły pakiet na NPM. Autor nie przeczytał ani jednej linijki tego kodu.
Całość zbudowały autonomiczne agenty: pięć miesięcy prób, w tym 400 tys. dolarów tokenów Codexa (wynik: około 84% kompatybilności) i 20 tys. dolarów na Opusie 5.5, który dokończył robotę w dwa tygodnie.
Realny koszt przy subskrypcjach Claude to około 500 dolarów (mniej więcej dziesięć tygodniowych limitów jednego konta), mimo „nagłówkowych” 420 tysięcy.
Wyniki: około 12,5× szybciej niż TypeScript 6 (wersja w JavaScripcie) i około 2× szybciej niż TypeScript 7, czyli oficjalny port Microsoftu w Go; na projekcie T3 Code nawet do 20× względem TS 6, z wbudowanym wsparciem dla Effect.
Smaczek inżynierski: agenty nie szły z JavaScriptu, tylko przenosiły linię w linię wersję Go Microsoftu — łącznie z biblioteką standardową Go i goroutines przeniesionymi do Rusta.
Wierność portu: pięć z sześciu zgłoszonych błędów to defekty samego TSC 7, przeniesione razem z kodem. Bun Check bywa szybszy, ale na repozytoriach Sentry i tRPC zgłaszał błędy, których nie było.
Lekcja historii: zamiana TS na JS jest banalna (stąd esbuild), prawdziwy koszt to sprawdzanie typów — dlatego kiedyś na Twitchu Theo ze skuteczności hot reloadu liczonych w minutach zszedł do pięciu sekund przez rozdzielenie obu ścieżek.
Uzasadnienie wyboru Go przez Microsoft: wbudowana współbieżność, składnia łudząco podobna do JS, a odśmiecanie pamięci przy wielosekundowej pracy kompilatora ma znikomy udział w czasie.
Prawdziwy motyw Theo to nie wydajność, lecz WASM: Rust doskonale kompiluje się do WebAssembly, dzięki czemu cała pętla deweloperska może działać w izolacie V8 — w przeglądarce czy Cloudflare Workers.
Teza ekonomiczna: cena inferencji spada o rząd wielkości rocznie, ceny maszyn wirtualnych rosną o 25–30% — moc obliczeniowa dla agentów stanie się wąskim gardłem. Dowód: kompletna aplikacja zbudowana i uruchomiona w izolacie V8 na mniej niż 216 MB RAM.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Dobierz model pod zadanie, zamiast dosypywać tokenów

Na czym polega: 400 tys. dolarów na modelach OpenAI dało maksymalnie 84% kompatybilności. Dalsze tokeni nie pomogły, bo ostatnie 16% to najtrudniejsze przypadki. Za to 20 tys. dolarów na Opusie 5.5 zamknęło zadanie w dwa tygodnie.

Jak stosować: Zanim uruchomisz długi, kosztowny bieg agentów, zrób tanie próby kontrolne na dwóch–trzech modelach i sprawdź, który realnie rusza z miejsca. Kontynuuj tylko ze zwycięzcą.

Na co uważać: Pułapka utopionych kosztów — jeśli model utknął na płaskiej górce postępu, zmiana modelu jest prawie zawsze tańsza niż dalsze dokarmianie tego samego.

2.Portuj przez najbliższy język pośredni, nie przez skok między paradygmatami

Na czym polega: Agenty nie dały rady na trasie JavaScript → Rust, ale poradziły sobie na trasie JavaScript → Go (Microsoft) → Rust. Opus przeniósł wersję Go linią w linię, razem z biblioteką standardową Go i reimplementacją goroutines w Ruście.

Jak stosować: Przy zlecaniu portów agentom szukaj istniejącego, wiernego tłumaczenia projektu na język bliższy docelowemu i każ startować z niego. Jeden skok paradygmatyczny naraz.

Na co uważać: Wierny port 1:1 jest początkowo wolniejszy od oryginału (tu: 2–3×) i wymaga osobnej fazy optymalizacji — wlicz ją w plan.

3.Dawaj agentom twardy, mierzalny cel końcowy

Na czym polega: Agent urywał pracę po „osiągnięciu pełnej kompatybilności” i pojedynczych poprawkach. Cel sformułowany jako „minimum dwukrotnie szybciej niż wersja Go, iteruj, aż dojdziesz” utrzymał go w ruchu przez dwa tygodnie.

Jak stosować: Formułuj cele jako weryfikowalne progi — liczbę, benchmark, zestaw testów — a nie jako ogólniki typu „popraw i dokończ”.

Na co uważać: Źle dobrany próg potrafi zatrzymać pracę przedwcześnie albo zachęcić do „nabijania” metryki zamiast realnej poprawy.

4.Pracuj z agentami jak menedżer zespołu, nie jak autor promptów

Na czym polega: Sednem sukcesu nie były prompty, lecz środowisko: równoległe workflowy i subagenty, ciągły audyt blokad, naprawianie powtarzających się awarii (m.in. crashe z braku pamięci), a wreszcie dopisanie dostępu SSH do kolejnych maszyn z floty.

Jak stosować: Prowadź obok wątek czysto obserwacyjny: notuj, co spowalnia agentów i które błędy wracają jak bumerang, i poprawiaj infrastrukturę oraz konfigurację, zamiast przepisywać instrukcje.

Na co uważać: Bez izolacji zadań agenty wchodzą sobie w drogę i nadpisują efekty pracy — równoległość trzeba zaprojektować.

5.Odśmiecanie pamięci „rozmazuje się” w długich zadaniach batchowych

Na czym polega: Garbage collector powoduje losowe skoki opóźnień — fatalne, gdy każde żądanie ma się wykonać w 25 ms. Ale gdy jedno wolniejsze żądanie przypada na tysiąc, całość zwalnia o mniej niż procent. W wielosekundowej pracy kompilatora udział odśmiecania jest pomijalny.

Jak stosować: Do serwisów wrażliwych na opóźnienia rozważ języki bez odśmiecania (np. Rust). Do narzędzi typu kompilator czy builder — bierz wygodę Go, bo GC praktycznie nie kosztuje.

Na co uważać: Oceniaj według charakterystyki własnego obciążenia: pojedynczy wolny request psuje percentyle, choć średnio nic nie znaczy.

6.Wierny port przenosi także błędy — audytuj zgłoszenia przed oceną

Na czym polega: Ze zgłoszonych do TS Rust sześć problemów tylko jeden dotyczył samego portu; pięć to bugi TSC 7, przeniesione razem z kodem. To dowód pełnej kompatybilności, nie wady.

Jak stosować: Przy weryfikacji portów porównuj zgłoszenia z trackerem projektu źródłowego, zanim obarczysz port winą. Buduj testy zgodności zachowań, łącznie z zachowaniami błędnymi.

Na co uważać: Kompatybilność „1:1” oznacza też kompatybilność defektów — utrudnia to odróżnienie regresji portu od oryginalnej wady.

7.Szybkość nie równa się wierności: testuj narzędzia na własnym repozytorium

Na czym polega: Bun Check bywa szybszy niż TS Rust, ale na bazach Sentry i tRPC zgłaszał nieistniejące błędy, a na kodzie Effecta nie przeszedł. Wierny port takich fałszywek nie generuje.

Jak stosować: Zanim podmienisz kompilator na szybszy odpowiednik, przepuść przez niego swoje dwa–trzy największe projekty i porównaj diagnostykę z oryginałem.

Na co uważać: Autor sam przyznaje, że do większości zastosowań poleca Bun Check, bo ma większą szansę na długie utrzymanie — projekt jednoosobowy (nawet autorytetu) to większe ryzyko operacyjne.

8.Subskrypcje zmieniają rachunek ekonomiczny projektu agentowego

Na czym polega: Pełny koszt w cenach API to około 24 tys. dolarów, ale w ramach subskrypcji Claude ta sama praza zajęła 925–983% tygodniowego limitu jednego konta — czyli jakieś 2,5 miesiąca użytkowania, realnie około 500 dolarów.

Jak stosować: Przy długich biegach autonomicznych licz koszt w zużyciu limitów subskrypcji, nie w cenniku API; planuj pulę kont i momenty resetów.

Na co uważać: Porównując koszty, zawsze podawaj obie kwoty — „subskrypcyjną” i API — inaczej liczby działają jak clickbait i psują wiarygodność.

9.Gdy celem jest WASM albo izolat V8 — wybieraj Rust, nie Go

Na czym polega: Garbage collector w Go rozdyma pakiet WebAssembly (trudno zejść pod 10 MB) i psuje charakterystykę wydajności — z tym latami męczył się esbuild. Rust kompiluje się do WASM naturalnie i dlatego TS Rust mieści się w izolacie V8, a TS Go nie.

Jak stosować: Jeśli planujesz uruchamiać narzędzie w przeglądarce, Cloudflare Workers albo izolacie V8, już na etapie wyboru języka eliminuj środowiska z odśmiecaniem pamięci.

Na co uważać: W izolacie nie ma systemu plików ani kodu natywnego — potrzebujesz warstw emulacji (w stylu just-bash) i narzędzi, które same mieszczą się w tym środowisku.

10.Projektuj tam, gdzie bezczynność nic nie kosztuje

Na czym polega: Cena inferencji spada o rząd wielkości rocznie (nawet około 1000× w ujęciu rocznym na danym poziomie inteligencji), a wynajem maszyn z RAM-em drożeje o 25–30% rocznie. W pętli zdarzeń V8 kod, który czeka na kolejny token, nie zużywa procesora — w przeciwieństwie do zarezerwowanej maszyny wirtualnej.

Jak stosować: Projektując środowiska agentowe, rozważ przeniesienie całej pętli „buduj–sprawdź–uruchom” do izolatów. Dowód skali: kompletne demo (agent, kompilacja, sprawdzanie typów, działająca aplikacja) zamknęło się w 216 MB RAM i szczycie 4% CPU.

Na co uważać: Darmowe maszyny od Cursora czy kredyty compute od Claude Code to stan przejściowy — nie opieraj architektury produktu na czyjejkolwiek dotacji.

Redakcyjne tłumaczenie

Ogłoszenie: TSC RS, czyli TypeScript przepisany na Rust

Ogłaszam TSC RS — TypeScript Rust — kompletny, napisany od zera w Ruście port kompilatora TypeScriptu wraz ze sprawdzarką typów i serwerem LSP. (Informacja dodatkowa: LSP, Language Server Protocol, to protokół, przez który edytory otrzymują podpowiedzi typów i diagnostykę.) Nad projektem pracowały moje agenty od pięciu miesięcy. Najpierw spaliłem 400 tysięcy dolarów na tokenach Codexa — bez efektu. Potem 20 tysięcy na Opusie 5.5 i w dwa tygodnie było zrobione. Ważny szczegół: ani jednej linijki tego kodu nie przeczytałem.

Jeśli oglądasz mnie od dłuższego czasu, wiesz, że port TypeScriptu do Rusta służył mi jako ulubiony poligon do testowania nowych modeli. Szukałem zadań, które wydawały się maszynom po prostu nie po silom. Wzięło się to stąd, że przy przedpremierowym dostępie do GPT 5.6 Soul miałem gigantyczną pulę inferencji, a model rozgniatał wszystko, co mu podrzuciłem. Sięgnąłem więc po coś śmielszego. Nie śmielszego — po coś niemożliwego. Przepisanie całego TypeScriptu do Rusta nie wydawało się wykonalne; wydawało się żartem. I żartem było.

Z modelami OpenAI najdalej zaszedłem do około 84-procentowej kompatybilności. Brzmi imponująco, ale dalej już było zwyczajnie nieprzejdzie — ostatnie szesnaście procent jest wielokrotnie trudniejsze, a im bliżej mety, tym brzydsze przypadki zostają do ogarnięcia. Dlatego tym bardziej nie mieści mi się w głowie, że TS Rust już jest — jako normalny pakiet na NPM — a przede wszystkim, że jest znacznie szybszy. Wobec TypeScriptu 6, ostatniej wersji pisanej w JavaScripcie, jest 12,5 raza szybszy. Wobec TS Go, czyli TypeScripta 7 od zespołu Microsoftu — około dwa razy.

Nie jesteśmy zresztą jedyni: Bun wydał Bun Check, własny port sprawdzarki TypeScriptu do Rusta, również znacznie szybszy — i szczerze mówiąc, jeszcze szybszy od mojego. Ale każda z tych rzeczy ma swoje haczyki: od sposobu, w jaki to budowałem, przez metodę weryfikacji, po sekretny powód, dla którego w ogóle chciałem, żeby coś takiego istniało. I nie, nie chodzi wyłącznie o zużycie pamięci i czas kompilacji. Mam jeden bardzo ciekawy, zatajony motyw — i mam już działające demo. To niepozorne demo z kategorii vibe codingu jest znacznie fajniejsze, niż wygląda na pierwszy rzut oka.

Zamierzam opowiedzieć o wszystkim: ile to kosztowało, jak to działało, dlaczego tak bardzo mi na tym zależy i — najważniejsze — co to oznacza dla inżynierii. Ale po spaleniu 420 tysięcy dolarów na tokenach mam nadzieję, że wybaczycie mi krótką przerwę na sponsora.

Przerwa na sponsora: wyszukiwanie wektorowe (Quadrant)

Jak do tego doszliśmy? Modele potrafią przepisać praktycznie dowolny program od zera w dowolnym języku, ale poproście agenta o znalezienie trzech właściwych wierszy w bazie — i prawie na pewno polegnie. Wystarczy, że dane nie są idealnie ustrukturyzowane i nie zawierają dokładnego słowa kluczowego, którego model szuka, a już tego nie znajdzie. Dlatego porządne wyszukiwanie wektorowe i systemy wyszukiwania są tak ważne, a dzisiejszy sponsor, Quadrant, ma to dopracowane. Dwie rzeczy dla niezadowolonych: projekt jest w pełni open source i napisany w Ruście; można korzystać z chmury albo hostować samodzielnie.

Przykład: szukam filmów, w których opowiadam o moim pliku AGENTS.md. Zwykłe wyszukiwanie słowem kluczowym zwraca dziesięć wyników, z których żaden nie pasuje. Quadrant zwraca wyniki ułożone według tego, jak dobrze treść rzeczywiście odpowiada pytaniu. Mogę też zapytać o coś ogólniejszego, na przykład „anti-claude” — i wyszukiwanie wektorowe podaje filmy, w których faktycznie jestem nastawiony krytycznie do Anthropic, podczas gdy słownikowe klepie te same nietrafienia co wcześniej. Im bardziej ogólne zapytanie, tym większa wartość. Da się tym również przejrzeć issues i pull requesty na GitHubie: na opis „T3 Code zamula mi cały komputer z Windowsem, nawet gdy nic nie robi” wyszukiwanie po słowach nie zwraca nic, a Quadrant osiem trafnych wątków — co ogromnie ułatwia scalanie duplikatów. Indeksujemy nawet twarze z miniatur: wystarczy wpisać „wzruszenie ramionami” albo „złość”. Nie bez powodu firmy takie jak Canva czy Discord przenoszą się na Quadrant.

Lekcja historii: co właściwie robi kompilator TypeScriptu

TypeScript to język — w pewnym sensie. Jego sens to dobudowanie do JavaScriptu warstwy, dzięki której mamy większą pewność, jak zachowają się nasze aplikacje. Bohaterem dnia jest jednak TSC, kompilator: on zamienia kod z edytora na JavaScript, bo przeglądarka TypeScripta nie rozumie. Jeśli do przeglądarki albo Node trafi funkcja z opisem typu przy parametrze — obiekt z polem name typu string — od razu poleci błąd, bo taka składnia w JavaScripcie nie istnieje. (Tak, po drodze żartuję na żywo z pisania dwóch linijek kodu — dawno tego nie robiłem, fajnie było.)

I tu pierwsza ważna rzecz: zamiana plików TypeScriptu na pliki JS jest łatwa, wręcz banalna. Dobrych narzędzi do tego jest od lat; kilka lat temu szczególnie wystrzelił esbuild. Napisał go Evan Wallace, CTO Figmy, bo chciał, żeby zmiana w edytorze szybciej pojawiała się w interfejsie, a przepuszczanie całego kodu przez JavaScript tylko po to, by coś z niego wyciąć, było wybitnie nieefektywne. esbuild wziął na siebie cały łańcuch: transpilację, dołączanie CSS, budowanie zasobów i składanie wszystkiego w jeden plik dla przeglądarki. Napisany w Go, żeby działał jak najwydajniej, ale bez rewidowania wszechświata i ręcznego zarządzania pamięcią. I był znakomity — brakowało mu jednak jednej rzeczy.

Bo transpilacja to łatwa część. Trudna część to sprawdzanie typów: upewnienie się, że typy są poprawne i że respektuje je cała aplikacja. Transpilacja była tak tania, że nawet robienie jej w JavaScripcie nie bolało; sprawdzanie typów jest i trudniejsze, i dużo wolniejsze — i to na nim spędzało się najwięcej czasu. Dlatego opiekunowie dużych baz kodu rozdzielili ścieżkę transpilacji od ścieżki weryfikacji typów. Pamiętam, jak fatalny był hot reloading na Twitchu: polecenie deweloperskie startowało dwie minuty, a po zapisaniu pliku zmiana pojawiała się w przeglądarce po trzydziestu sekundach do minuty. Cieszyłem się jak dziecko, gdy zeszliśmy pod pięć sekund — a udało się to przez oddzielenie ścieżki wpuszczającej kod do przeglądarki od tej, która sprawdza typy. Narzędzia typu esbuild skracają jeszcze bardziej czas od zapisu do odświeżenia, ale nie powiedzą ci, czy typy się zgadzają.

A system typów TypeScriptu — jak widzieliście w moich starych filmach — jest niesłychanie złożony i elastyczny. Jest kompletny w sensie Turinga. Mój znajomy przeniósł cały Doom do typów TypeScriptu; nie do języka — do samego systemu typów. Osobny projekt, gorąco polecam. Sedno: złożoność bierze się stąd, że system typów musi oddać wszystko, co da się zrobić w JS. A to oznacza, że przepisanie sprawdzarki na język inny niż JavaScript z natury boli — przez wszystkie dziwactwa JS: typy zmiennych zmieniające się w trakcie działania, dziedziczenie obiektów, prototypy. Całą tę dziwność, którą TypeScript wiernie koduje, łatwiej opisać, gdy język opisujący jest tym samym językiem, który opisujemy. Głupsza analogia: łatwiej wyjaśnić po angielsku, jak działa angielski, niż zrobić to samo po hiszpańsku. Wyobraźcie sobie tę złożoność pomnożoną przez sto.

Dlaczego Microsoft wybrał Go

Ale to nie zatrzymało Microsoftu. Zdecydowali się przepisać TSC — natywnie i błyskawicznie — i wybrali Go. Mam opinię, że to był słuszny wybór, choć jestem notorycznym hejterem tego języka; nigdy specjalnie mnie nie ciągnął. Rozumiem jego zalety, po prostu programowanie w nim czuć bardziej jak tresurę małpy niż inżynierię.

Czemu więc Go miał sens? Przede wszystkim elastyczność — nie próbuje z takim zapałem być super bezpieczny typowo i pamięciowo; jego system typów to raczej dowcip niż konstrukcja. Za to wbudowana współbieżność jest znakomita: w środku goroutines kryją się naprawdę fajne rzeczy (kanały są głupie, ale rdzeń — jak najbardziej). A współbieżność była jednym z głównych wymagań przy porcie, żeby wykorzystać więcej rdzeni. Składnia Go jest łudząco podobna do JS, co ułatwiało porównywanie funkcji w obu wersjach. Ale największy kawałek to odśmiecanie pamięci.

Garbage collector to zarazem jedna ze słabości Go: skoro pamięcią nie zarządzasz sam, w pewnym momencie trzeba ją posprzątać — a to oznacza, że charakterystyka wydajności nie jest przewidywalna. Zwykle żądanie obsłużysz szybko, ale jeśli akurat zabraknie pamięci i ruszy sprzątanie, dostajesz losowe skoki opóźnień. Budujesz system, w którym każde żądanie ma się wykonać w mniej niż 25 milisekund? Go może nie być właściwym wyborem, bo czasem wstrzyma wykonanie kodu do końca sprzątania. Dla jasności: JavaScript i TypeScript też są odśmiecane — Go jest po prostu ciekawy, bo naraz niskopoziomowy i odśmiecany.

Skoro tak, czemu używać go w kompilatorze? Bo matematyka wygląda inaczej. Gby tysiąc żądań przychodzi po 25 milisekund, a tysiąc pierwsze zajmuje 300 — to jedno żądanie jest dziesięciokrotnie wolniejsze od reszty, ale całość zwalnia o mniej niż procent. Nic. Wpływ odśmiecania na długi proces z górą pracy jest pomijalny w porównaniu ze sytuacją, gdy mierzysz każde żądanie osobno. Jeśli chcesz odpowiadać w milisekundach, język odśmiecany będzie miał wady, które trzeba obchodzić. Ale jeśli średnie zadanie trwa ponad 100 milisekund — nie wiem, kilka sekund, bo kompilujesz gigantyczną aplikację — nie obchodzi mnie, czy odśmiecanie odpali raz, dziesięć czy sto razy; to ułamki procentu czasu, one się rozmazują w szumie. Buduję usługę, która ma reagować błyskawicznie? Nie Go. Przyspieszam coś napisanego w JavaScripcie, co trwa minuty, i dokładam współbieżności? Go jest do tego jednym z najlepszych języków.

TS Rust: port z Go, nie z JavaScriptu

No dobrze — skoro agent zrobił to w dwa tygodnie, to zespół Microsoftu zmarnował czas i pieniądze na Go, tak? Nie. Przepisanie TypeScriptu wprost z JS do Rusta nie było wykonalne — wiem to, bo modele typu 5.6 Soul i Astra grzęzły w tych próbach. Duża część problemu to sama droga z JavaScriptu do Rusta przy czymś tak złożonym jak TypeScript. A tu robi się ciekawie. Gdy zaglądamy do crate’ów w TS Ruscie, znajdujemy rzeczy… „wątpliwe” to uczciwe słowo. Na przykład Go STD: biblioteka standardowa Go przeniesiona do Rusta. Bo Opus nie tłumaczył TypeScriptu z JS. Wziął wersję Go i przeniósł ją do Rusta linia po linii, wiernie. W środku jest nawet runtime.rs — goroutines przeniesione do Rusta. Nie wiedziałem o tym, dopóki ktoś nie wypunktował tego na Twitterze; wtedy puknąłem się w czoło: ha, to wszystko wyjaśnia. Go był znacznie lepszym punktem wyjścia do sportowania na Rust niż JavaScript. Zespół Microsoftu przeszedł ręcznie każdą linijkę TypeScriptu, przeniósł ją do Go i zaczął szlifować pod wydajność. Moje agenty zrobiły dokładnie to samo — z wersji Go do Rusta — i im się udało. Gdy TS Rust pierwszy raz ruszył, był dwa–trzy razy wolniejszy od oryginału, bo reimplementacja czegoś w rodzaju goroutines kosztuje. Wpisałem więc agentowi cel: „Twoim zadaniem jest być co najmniej dwa razy szybszym w każdej mierze”. I zostawiłem to tak na dwa tygodnie. Co ważne — na moich sześciu kontach Claude.

Ile to naprawdę kosztowało

Cała praca Opusa 5.5, który w praktyce porzucił poprzednią wersję i zaczął od zera, to około 24 tysięcy dolarów inferencji w cenach pełnego API. Tyle że ja płacę subskrypcjami. Przeliczyłem własne logi: zajęło to między 925 a 983 procent tygodniowego limitu jednego konta, czyli jakieś dwa i pół miesiąca użytkowania subskrypcji Claude. Uwzględniając darmowe resety limitów, realny wydatek to około 500 dolarów. I w tej cenie to jest świetny interes: mieć TypeScript w Ruście, oszczędniejszy na pamięci i dwa razy szybszy od wersji Go. Wiem, że nagłówkowe „20 tysięcy” albo „420 tysięcy” brzmią jak obłęd, ale po dofinansowaniu z subskrypcji dziesięć tygodniowych limitów za taki efekt to moim zdaniem cena z kosmosu — w dobrym sensie.

I jeśli teraz myślisz: „ech, Microsoft zmarnował tyle środków na Go, wystarczyło poczekać i kazać AI zrobić Rust” — nie. Nie sądzę, żeby sztuczna inteligencja wykonała to sensownie wprost z JavaScriptu i TypeScriptu. Ale z Go — względnie lekko. Efekt jest w praktyce stuprocentowym zamiennikiem na podmianę dla TS Go i TSC 7. Wiem to z bardzo głupiego powodu: z listy zgłoszeń. Było ich pięć, zostały cztery. Audytowaliśmy je z agentem: z sześciu zgłoszeń łącznie tylko jedno dotyczyło specyficznie TS Rusta. Pozostałe pięć to problemy istniejące w TSC 7, wersji, na którą celowaliśmy. To nie są błędy portu — to bugi samego TypeScriptu, które wiernie przeniosłem do Rusta. I bawi mnie to ogromnie: przeniosłem nie tylko zamierzone zachowania, przeniosłem również bugi. Bo to dopiero pełna kompatybilność.

Wyniki i pojedynek z Bun Check

Czas na liczby. Zanim Bun Check w ogóle zaświtał w głowie Jareda, porównywałem wszystko z TypeScriptem 7. Na prawdziwych projektach, jak T3 Code, wyszło dwukrotne przyspieszenie względem TS7 (TS Go) i aż dwudziestokrotne względem TSC 6, ostatniego kompilatora w JavaScripcie. Zacząłem od T3 Code, bo zrobiłem tam coś zabawnego: Effect — popularna biblioteka do budowania niezawodnych systemów współbieżnych w TypeScripcie — używa i nadużywa typów tak mocno, że utrzymuje własną, zmodyfikowaną wersję TypeScriptu: łatkę nakładaną na pakiet, by wycisnąć z typów więcej diagnostyki i możliwości. Wbudowałem to prosto w TS Rust, bo w T3 Code mocno na tym polegamy. Dzięki temu w naszym przypadku jesteśmy nie tylko znacznie szybsi od TS7 z wtyczką Effect, ale też jakieś cztery razy szybsi od Buna — nie dlatego, że Bun Check jest wolny; jest śmigli. Ale u nas na Bun trzeba by jeszcze nałożyć sprawdzanie Effect na wierzch i całościowo robi się z tego spory wysiłek.

T3 Code to jednak jeden projekt. Sprawdziłem kolejne: cały tRPC server, bazę kodu Sentry, Excalidraw, a dla jaj — samego Effecta. Z tego, co pamiętam, Bun nie przeszedł na kodzie Effecta, a na Sentry i tRPC podnosił błędy, których nie było. Bun Check jest więc bardzo imponujący i często szybszy, ale sprawdzanie nie jest dość wierne, żebym ufał mu w dużych projektach. Zresztą świetnie pasuje do reszty ekosystemu Buna: jeśli zaczynasz projekt na Bun i używasz Buna do wszystkiego, to dobre rozwiązanie. Szczerze — w większości przypadków poleciłbym Bun Check ponad TS Rust po prostu dlatego, że mam większą wiarę, że będzie utrzymywany. Ale TS Rust to o wiele wierniejsza rekonstrukcja — dzięki czemu nie wywala dziwnych błędów w takich repozytoriach jak tRPC czy Effect. Typowe przyspieszenie z TSC 6 do TS Rust to trzynastokrotne i więcej; względem wersji Go — zwykle dwukrotne.

Powód błahy: bo modele miały tego nie umieć

Gotowi na pikantną tezę, która wszystko bardziej pogmatwa? Nie zrobiłem tego dla wydajności. Nie przenosiłem TypeScriptu do Rusta po to, żeby mieć coś szybszego od TS Go. To po co? Jest powód głupi i jest powód, który może okazać się przełomowy. Zacznę od głupiego: zrobiłem to, bo LLM-y nie potrafiły. „Przepisać TypeScript na inny język” stało się już klasycznym przykładem niemożliwego. Prowadziłem ostre sprzeczki z ludźmi, twierdząc, że modele za miesiąc przeniosą TypeScript do C++ — dostałem bloka, był cyrk. To jeszcze stare dobre czasy twitterowych wojen o TypeScript, sprzed ery AI. Walczyłem, bo wydawało się oczywiste, że czegoś takiego po prostu się nie da zrobić. Dlatego zawsze było to moje marzenie z kategorii nieosiągalnych — święty Graal web devu. A w takie właśnie rzeczy przyjemnie jest obrzucać praktycznie nieograniczonymi tokenami.

Nigdy nie próbowałem na tym zadaniu żadnego modelu Anthropic — spaliłyby mi limit w okamgnieniu. Ale przy Opusie 5.5 limit schodził tak wolno, a pul miałem tyle, że postanowiłem: zobaczmy. I wyszło o wiele lepiej, niż kiedykolwiek przypuszczałem. Zrobiłem to, bo myślałem, że modele tego nie potrafią — a skoro już potrafią, zaczyna mi się kończyć lista rzeczy do rzucania w LLM-y. Nie wiem, jakie zadanie miałoby być dziś dla nich niewykonalne, a jutro wykonalne. Trudno mi to pojąć — skończyły mi się pomysły inżynierskie, które są „za dużo jak na model”. To było moje „za dużo”. I już zrobione.

Powód prawdziwy: WASM

No dobrze, a po co mi wersja TypeScriptu w Ruście, skoro był już szybki Go? Drobiazgi, jak wbudowany Effect czy łatwiejsze rozszerzanie — tak. Ale główny powód to mała rzecz zwąca się WASM, czyli WebAssembly.

Wróćmy na moment do odśmiecania pamięci. Garbage collector to świetny sposób na zdjęcie z inżyniera brzemienia, by szybciej dostarczał oprogramowanie, które i tak jest naprawdę szybkie. Ale ponieważ odśmiecanie to złożony proces analizujący pamięć, zapakowanie aplikacji Go do WebAssembly nie jest proste: do pakietu musi wejść nie tylko kod dewelopera, ale i cały mechanizm odśmiecania. Efekt: trudno zbudować aplikację Go w WASM poniżej dziesięciu megabajtów, a i tak będzie miała dziwne problemy wydajnościowe. Z tym latami męczył się esbuild, próbując działać w WASM. To też jedna z rzeczy, które straciliśmy wraz z TypeScriptem Go. Kiedyś cały TypeScript był ostatecznie JS-em: mogłeś go wrzucić do przeglądarki, do izolatu V8, odpalić w Node — i działało. Z TS Go to trochę przepadło; przepadło też sporo JavaScriptowych API, którymi kiedyś rozmawiało się z kompilatorem.

Ekonomia: tanieje inteligencja, drożeją maszyny

No i dlaczego ja się tym tak przejmuję? Przecież wszyscy uruchamiamy modele na swoim albo cudzym komputerze, prawda? A jeśli w przyszłości nie będziemy? Inteligencja jest droga. Ludzie tacy jak Lauren, znany jako potato z Cursora i SpaceX, wydają podobno 132 miliony dolarów rocznie (te liczby są — jak wyjaśnię w osobnym filmie — nie do końca prawdziwe; zapiszcie się na kanał, będzie z tego tyrada). Pomijając dokładne kwoty, tempo, w jakim ceny lecą w dół, jest jak najbardziej prawdziwe.

Spójrzcie na wykres efektywności kosztowej z Artificial Analysis — portalu z niezależnymi benchmarkami modeli. Pokazuje on, jak zmienia się cena uzyskania danego poziomu inteligencji. Na prawym końcu robi się oszołamiająco: modele tak zdolne jak Opus 5, który jako pierwszy przekroczył pięćdziesiąt punktów w ich indeksie, kosztowały 5,86 dolara za zadanie w momencie debiutu — a dziś model 61 Soul uzyskuje ten sam wynik za 32 centy. Dziesięciokrotny spadek ceny danego poziomu inteligencji w cztery miesiące. Albo przedział trzydziestu punktów: 2,50 dolara w lutym, trzy centy w grudniu — to osiem razy taniej miesięcznie, w ujęciu rocznym rząd wielkości tysiąca. Cena inteligencji spada absurdalnie szybko; dziesięciokrotność rocznie to szacunek ostrożny.

Ale inteligencja to nie jedyny koszt. Przy budowie aplikacji z AI płacisz za hosting, za bazę danych, za dostawców usług, Apple za dystrybucję… i o jednym jeszcze, o którym mało kto myśli: za moc obliczeniową, na której pracuje agent. Jeśli jesteś z braci serwerowej „VPS za piątkę” — teraz wasze pięć minut, bo musimy pogadać.

Cursor robi dziś coś ciekawego: chmurowe wątki. Każdy z nich dostaje pełną maszynę wirtualną — bodajże z 32 GB RAM (może 16, ale chyba jednak 32) — z prawdziwym Linuksem, żeby agent mógł odpalić twoją aplikację i przetestować ją na prawdziwym komputerze. Odpalasz cztery wątki — 128 GB RAM zarezerwowane dla ciebie na dziś. I Cursor za to nie liczy. Dlaczego? Bo inferencja jest tak droga, że koszt maszyn to niemal błąd zaokrąglenia. Ale pamiętasz, co mówiłem? Cena inferencji spada lawinowo. A cena maszyn? Wypożyczenie szesnasto- czy trzydziestodwugigabajtowego pudła drożeje z każdym rokiem, bo AI wsysa cały popyt na pamięć. Jedno rośnie o 25–30 procent rocznie, drugie spada dziesięć–sto razy. Szybko dojdziemy do punktu, w którym inferencja będzie tańsza niż maszyna, na której agent pracuje. Model klasy GLM 5.3 Flash uruchomiony na godzinę kosztuje kilka dolarów — a stojąca pod spodem maszyna pewnie więcej. Gdy modele z tej półki będą coraz sprytniejsze i coraz tańsze, ten moment nadejdzie szybko.

Wtedy moc obliczeniowa stanie się wąskim gardłem przy budowaniu z agentami. Dziś dostajemy maszyny za darmo — ale to się nie utrzyma. Claude Code już tak nie robi: subskrybenci dostają kredyt do wydania na chmurowe zasoby. Problem w tym, że nasi agenci są przyzwyczajeni do prawdziwego komputera: prawdziwego terminala, prawdziwego basha, żeby mogły odpalać polecenia, ripgrep, przeszukiwać repozytorium. Oczekują narzędzi do edycji plików, sprawdzania obciążenia procesora, wykonywania poleceń gita. Są trenowane na prawdziwych Linuksach i Makach. Można je jakoś odizolować, ale każda dodatkowa warstwa izolacji kosztuje zasoby. Twardsze sandboxowanie nie zrobi mocy obliczeniowej tańszą — raczej droższą. Potrzebujemy lepszej warstwy abstrakcji. W przyszłości, w której modele i pisanie kodu będą tanie, to, na czym ten kod powstaje i jest testowany, nie powinno kosztować majątku.

Cloudflare i izolaty V8

Tutaj wracamy do starego boju, o którym dawno nie rozmawialiśmy. Wielki Pomarańczowy — Cloudflare. Jakie słowo wam się z nim kojarzy? Chat sypie: „tanie”, „darmowe”, „koszt”. I o to chodzi — powodem jest architektura. Gdy wdrażam backend na Cloudflare, nie pakuję go w obraz Dockera wdrażany na serwerze. Kod w ogóle nie „działa” — czeka. Gdy przychodzi żądanie, Cloudflare odpala workera: odizolowany proces JavaScriptowy w V8, silniku napędzającym Chrome i Node. To nie jest Linuks ani pełny system operacyjny — to wydzielona warstwa wykonywania, w której można uruchamiać JavaScript w bezpiecznej kapsule.

Dzięki takim izolatom Chrome trzyma osobne karty, które nie mieszają sobie nawzajem w danych — albo kilka niezależnych procesów w jednej karcie, mogących się komunikować, ale nie przeszkadzać. Cloudflare wziął te izolaty, utwardził je i zrobił z nich platformę: gdy użytkownik wchodzi na waszą stronę, system wyjmuje kod z magazynu, wrzuca na czekający izolat, wykonuje i zabija. Na Vercelu, Heroku czy Hetznerze ty i ja dostajemy każdy swoją instancję Linuksa z naszym kodem. Na Cloudflare twój i mój kod wykonują się w tej samej instancji systemu — tylko rozdzielonej wyżej, na warstwie V8, a nie maszynami wirtualnymi i Dockerem. (Jeśli to nie gra — zapytajcie swojego agenta, nie będę tego rozwijał; mówiłem o tym w wielu filmach.)

To się jednak wiąże z ograniczeniami. W izolacie JS nie odczytasz plików z systemu plików — bo go tam nie ma, a dostęp pozwoliłby uciec i grzebać w cudzych rzeczach. Nie uruchomisz kodu natywnego — natywny kod wychodzi poza izolat i musi działać w prawdziwym systemie. Nie zrobisz tradycyjnych, trwałych serwerów. Cloudflare dorobił sprytne obejścia wielu z tych problemów, ale sedno pozostaje: JavaScript żyje w wirtualnej warstwie nad V8, a nie na poziomie maszyn wirtualnych. I właśnie dlatego platforma jest tania — naprawdę tania w utrzymaniu. Nie robią cen promocyjnych, żeby wygrać; mogą tak kosztować, bo architektura im na to pozwala, i mimo to mają marżę. Vercel nie jest drogi z chciwości — jego koszty są po prostu wyższe.

Ale skoro w izolacie nie zapiszesz plików ani nie odpalisz serwera deweloperskiego, to nie uruchomisz w nim agenta: nie sprawdzisz typów, nie da się agentowi wytłumaczyć, co jest nie tak z jego kodem… O. Hm. Dziwne. Bo właśnie dokładnie to zrobiłem.

Demo: cała pętla deweloperska w izolacie

To demo budowałem w Astrze, ale miało głupie decyzje żrące pamięć, więc pokażę wersję zrobioną przez Opusa — lepiej obrazuje, o co mi chodzi. Zanim usprawiedliwię chaos, ostatnia wzmianka: just-bash, biblioteka Maltego z Vercela, która wyrosła na poważny projekt. Jej sens: dać agentowi w pamięci, w JavaScripcie, pełne udawane środowisko bashowe — fałszywy system plików, fałszywe procesy, fałszywe wszystko — by agent mógł pracować, jakby siedział w bashu. Do eksplorowania plików przez agenta — świetne. Ale żeby na tym realnie budować, trzeba też umieć kompilować i sprawdzać typy tak jak na normalnym systemie plików. Sama emulacja to za mało.

A teraz, z TypeScriptem w Ruście, możemy robić naprawdę głupie rzeczy. Na przykład: kazałem GPT-61 Soul zbudować kompletną, działającą aplikację — w całości w izolacie V8. To akurat chodzi w Node na serwerze, ale równie dobrze mogłoby działać w przeglądarce. Ograniczeń jest mniej, niż myślicie. Wszystko to się wykonało i działało: agent, komputer, na którym pracował, zasoby samej aplikacji, sprawdzanie typów, kompilacja — wszystko w moim izolacie, poniżej 216 MB RAM i ze szczytem około czterech procent procesora.

Rozumiecie, jakie to jest fajne? Agent buduje aplikację, a zarówno on, jak i maszyna, na której pracuje — nie inferencja, lecz środowisko do uruchamiania i budowania kodu — wszystko razem kosztuje grosze. W Go to by bolało, bo TS Go marnuje górę zasobów w WebAssembly. WASM nie pasuje do Go; do Rusta pasuje znakomicie. Dla podkreślenia: gdy kazałem Astrze budować to demo, wybrała do pakowania esbuild — i sama, w bezczynności, żre dwa razy więcej RAM-u niż wersja na TS Ruscie, bo pakiet oparty na Go z samej natury łyka pamięć, do tego trzeba wczytać znacznie większy plik.

Widzę zamieszanie, jak to miałoby działać na Cloudflare. A co łączy Cloudflare, Chrome i Node? Wszystkie używają izolatów V8. Rozszerzenie Chrome, nowy plik, proces WASM — to wszystko osobne izolaty, które mogą się komunikować, jeśli im na to pozwolono, ale nie mogą sobie przeszkadzać. I nie, to nie jest imponujące dlatego, że przepisałem Bolta na TS Rust. (Informacja dodatkowa: Bolt, dawniej StackBlitz — narzędzie do generowania i uruchamiania aplikacji bezpośrednio w przeglądarce.) Jest imponujące dlatego, że mogę przełączyć system plików serwera na tylko do odczytu — a demo nadal działa. Nic tu nie wyszło poza pamięć, nic nie wyszło poza V8. Cała pętla deweloperska istnieje w V8. Nie ma na rynku nic porównywalnego. Widzę ludzi wymieniających losowe bazy danych pozwalające wykonywać u siebie kod — nie, nie o to chodzi. Jeśli moja widownia na streamie tego nie łapie, nie bardzo wiem, jak wytłumaczyć to innym.

Stos systemowy: Docker kontra izolaty

Szybko o tym, jak działają komputery. Na dole sprzęt: procesor, pamięć, reszta. Wyżej sterowniki — dostarczane przez warstwę nad nimi, czyli jądro; przez sterowniki jądro rozmawia ze sprzętem. Nad jądrystem operacyjny, potem system plików, na szczycie aplikacje. Jak działa normalny cloud — Heroku, Hetzner, AWS? Wdrażając obraz Dockera, nie wdrażasz go „u siebie”: te warstwy muszą leżeć na sprzęcie dostawcy. Więc w warstwie aplikacji AWS kładzie Dockera, a potem — kopiujesz-wklejasz cały stos i robisz to samo jeszcze raz. Tak właśnie działa hosting na zwykłych VPS-ach: nad systemem operacyjnym i plikami leży aplikacja w rodzaju Dockera (technicznie często z warstwą pośrednią przy jądrze, dzięki której nie odpala się pełnej nowej instancji jądra, tylko sprytnie pomija kroki — nie do końca to wszystko ogarniam, ale taka kosmetyka na styku Dockera i jądra na pewno poprawia wydajność). I na tym stawiasz kolejny system operacyjny — dlatego na jednej maszynie AWS jeden klient ma Ubuntu, drugi Windows Server, trzeci Debiana. Każda z tych warstw zjada RAM. Dlatego każdy nowy kontener na twoim komputerze żre chmarę zasobów: uruchamianie systemów operacyjnych wewnątrz systemu operacyjnego kosztuje.

A jak działa JavaScript? Weźmy ten sam stos, tylko aplikacją jest Chrome. W Chrome siedzi V8 — środowisko uruchomieniowe JS — a w V8 wszystkie te izolaty, z których każdy potrafi równolegle wykonywać inne pliki i funkcje. To ogromnie wydajniejsze: aplikacja, jeśli mieści się w izolacie, nie musi schodzić do jądra, uruchamiać systemu operacyjnego i kraść góry zasobów. Bądźmy szczerzy: co żre więcej na twoim komputerze — nowy kontener z Postgresem czy nowa karta Chrome? Karty, choć wydaje wam się, że Chrome jest wolny, zużywają wielokrotnie mniej. Rzecz w tym, że Google wlał w V8 miliardy dolarów — chciał, żeby web był tak dobrą platformą, że przestaną powstawać fatalne aplikacje okienkowe. Ta praca przyniosła korzyści całemu ekosystemowi w sposób trudny do przecenienia, łącznie z całym Cloudflare. Ich platforma opiera się na przekonaniu, że wirtualizacja na poziomie systemu operacyjnego — wpychanie całego OS-u do warstwy aplikacji — jest głupia, a V8 to znacznie lepsza podstawa pod kod klientów.

Haczyk: to tylko JavaScript. Bez pełnego dostępu do systemu, bez jądra, bez systemu plików. Czego nie zrobi karta Chrome, tego nie zrobi izolat V8. Izolaty są świetnym miejscem na kod już zbudowany — ale nie do budowania. Na Vercelu sandboxy działają na tej samej infrastrukturze co hosting; sandboxy Cloudflare są słabe, bo Docker to nie ich bajka — ich dumą jest warstwa izolatów, więc ich środowiska do wykonywania kodu chodzą na zupełnie innym sprzęcie i platformie niż tradycyjny hosting workerów.

I właśnie to zrobiłem, inspirując się just-bash — bo jego magia polega na mówieniu agentom żyjącym w warstwie izolatów, że mają system plików i inne sprawy. Gdybym na serwerze z tym demo przestawił system plików na tryb tylko do odczytu — dosłownie nie mógłbym edytować żadnego pliku, wszystko działałoby wyłącznie w pamięci, w izolacie i Node — demo zachowywałoby się identycznie. To jest sedno. Całość dałoby się odpalić w workerze Cloudflare. Zamiast pół giga RAM i zarezerwowanych rdzeni — koszt bliski zeru.

Jeszcze jedna rzecz: alokacja procesora. Ty masz maszynę z dwoma rdzeniami, ja mam maszynę z dwoma rdzeniami, obie czekają bezczynnie — marnujemy cztery wirtualne CPU. W modelu Cloudflare działa wbudowana pętla zdarzeń: gdy twój kod nic nie robi, nic nie kosztuje poza odrobiną pamięci. Czekasz na kolejny token od dostawcy modelu? Procesor stoi, nie płacisz — te cykle świadczy komuś innemu. Przychodzą dane — wykonuje się następne zadanie. Twoja aplikacja, moja i program sąsiada dzielą tę samą pętlę zdarzeń, wspólny planistę zadań. Nawet wielogodzinne zadanie spędza większość czasu na czekaniu — a tu płacisz tylko za moment, w którym przychodzi token, nie za czas między tokenami. Jeśli inferencja będzie dalej tanieć, ten styl budowania stanie się nieodzowny: środowiska deweloperskie dla agentów tanie z każdej strony — i sam model, i zasoby, na których pracuje.

Widzę, że część z was łapie i pyta o Lakebed. Nie powiem nic więcej — muszę wam zostawić coś do ekscytacji. Sedno jest takie: TS Rust to jeden z ostatnich klocków, których potrzebowałem, żeby pełne, kompleksowe doświadczenie deweloperskie TypeScriptu uruchomić w izolacie zamiast w maszynie wirtualnej.

Jak tym sterowałem: środowisko, nie prompty

Dla ciekawych — oto bardzo złożone prompty, jakimi budowałem TS Rust: „Pracuj w CodeSandbox, TS Rust, na tym komputerze. Najpierw przeczytaj AGENTS.md i pliki rozliczania sprawdzania typów. Te pliki zawierały notatki z szesnastogodzinnego biegu i kilka próśb: zrób liczbę zadań cargo konfigurowalną, dodaj podział skryptów i tak dalej. Potem zaktualizuj AGENTS.md, żeby móc pracować bardziej równolegle”. Odpowiedziałem: „Zrób to. Świetna robota. W pełni ufam twojemu osądowi. Kontynuuj i rób, co uważasz za najlepsze dla kompatybilności i wydajności. Pewnie już niedługo możesz przejść na main”. Potem dorzuciłem: „Weź najlepszy obecny stan pracy i ustaw jako główną gałąź jak najszybciej. Nie obchodzi mnie, jak. Ufam twojemu osądowi”. W pewnym momencie poprawiałem poziom wysiłku, bo siedziałem na złym: chciałem tryb ultra, a po awariach z braku pamięci — które przy okazji miotały systemd — spadało na średni; po naprawie paru rzeczy na poziomie systemu ustawiłem z powrotem ultra. I cel: „Dokończ port, maksymalnie zbliż się do stuprocentowej kompatybilności z TS Go, poprawiaj wydajność. Pracuj równolegle: wiele przepływów pracy i subagentów ma działać bez przerwy, żeby zmaksymalizować równoległość. Orkiestruj, jak chcesz, byle pracowały niezależnie, wszystko na tej maszynie”. Gdy zauważyłem, że ciągle brakuje mocy, skonfigurowałem dostęp SSH na pozostałych maszynach z mojej floty i powiedziałem: „Masz teraz dostęp SSH do innych maszyn”. A gdy zobaczyłem, że agent zatrzymuje się po dojściu do pełnej kompatybilności i pojedynczej poprawce wydajności — doprecyzowałem: „Cel: minimum dwukrotnie szybciej niż build w Go. Iteruj, aż dojdziemy”. I iterował. Dwa tygodnie.

Jak widzicie, mega-prompting najwyższej klasy. A tak serio: sedno nie tkwiło w promptach, tylko w środowisku i konfiguracji, które na to pozwoliły. Prowadziłem równolegle inne wątki, w których nieustannie audytowałem — gdzie blokada, co trwa za długo, które tryby awarii wracają jak bumerang — i poprawiałem otoczenie tak, żeby agenty mogły pracować równolegle, nie depcząc sobie po piętach. Po jakimś czasie mieliśmy systemy, które to umożliwiały, i tempo dostarczania wyraźnie poszło w górę. Mój wysiłek wyglądał jak praca menedżera: nie siedziałem w okopach przy kodzie, tylko dbałem, żeby zespół miał wszystko, czego potrzebuje, i szukałem, co go spowalnia, żeby to usunąć. I było świetną zabawą.

Przy okazji — zostałem grzecznie poproszony, żeby wspomnieć o Mega Dev. Pierwszy raz w życiu prowadzę płatny kurs. Czuję się z tym dziwnie i chcę być jasny: wszystko, co pomoże wam zdobyć pracę, ląduje za darmo na kanale. Kurs jest dla pracujących deweloperów, którzy chcą wycisnąć z AI maksimum i dostarczać prawdziwe oprogramowanie w prawdziwym świecie. Prowadzę go z trzema znakomitymi instruktorami — z Angie, którą kocham, z Kentem, od którego kiedyś nauczyłem się połowy tego, co wiem o Reakcie, i z Johnem Lindquistem, twórcą Egghead. Gdybyście mieli płacić z własnej kieszeni — nie polecam. Ale jeśli przekonasz szefa, żeby pokrył to z budżetu szkoleniowego, będzie fajnie. Będzie też warsztat na żywo, właśnie o tych chaotycznych strategiach maksymalizowania agentów.

Zamiast podsumowania: inżynieria, jaką znamy, właśnie się skończyła

Co to była za podróż. Moja „psychoza AI” i tak była już poważna, a tu nagle wszystkie te szalone pomysły, które nosiłem w głowie od lat, okazują się wykonalne. Zawsze chciałem pełnego środowiska deweloperskiego działającego czysto w V8. Gdy Bolt był jeszcze StackBlitzem i pokazali swój runtime JS w WASM — pełne środowisko w stylu VS Code w przeglądarce, pakujące aplikacje lokalnie — byłem zachwycony. Chciałem pójść dalej z Cloudflare; poszedłem na tyle daleko, że próbowałem zrekonstruować, jak StackBlitz to robi, rozkodowując binarny plik JS w ich WASM. Wtedy właśnie zaprzyjaźniłem się z Erikiem. Zawsze byłem nurkiem w to, jak nasz kod naprawdę się wykonuje i jak te systemy się składają. A teraz mogę próbować własnych szalonych pomysłów. Kiedyś większość z nich żyła tylko w mojej głowie; gdy któryś dojrzał, mogłem go opowiedzieć mądrzejszej osobie i może zainspirować ją, żeby zbudowała coś podobnego za pięć lat. Dziś opowiadam pomysł Opusowi — i sprawdzam, czy działa. Chciałem się właśnie przekonać, czy to demo ruszy na Cloudflare? Powiedziałem Opusowi: zrób to. Pewnie zrobi.

Z jednej strony: inżynieria, którą znamy i kochamy, nie żyje — i to bardzo. Takie projekty „na hurra” nie powinny być wykonalne. Nie powinny przechodzić testów, a co dopiero działać jako pełny zamiennik TypeScriptu. Ale jeśli nadal uważasz, że deweloperka z AI to nie przyszłość i nie jest oczywistym kierunkiem całego oprogramowania — zasługujesz na brak zatrudnienia za trzy miesiące, bo to, co się dzieje, jest nie do ogarnięcia. Naprawdę trudno pojąć, jak zdolne stały się te narzędzia.

To wszystko, co miałem powiedzieć. Siedziałem do szóstej rano, przygotowując te dema, i jestem ogromnie dumny z tego, co ugotowaliśmy z Opusem — nie dlatego, że wszyscy powinni tego używać, tylko dlatego, że mogę sprawdzić, czy te idee działają, w tempie trudnym do wyobrażenia. Czasem mam wrażenie, że zaglądamy w przyszłość. Nie potrafię sobie wyobrazić, gdzie będziemy za rok. Mam nadzieję, że zabieracie się ze mną w tę podróż, bo będzie tylko bardziej chaotycznie. I tym akcentem — na razie, nerdzi.