Jak pracuje z agentami szef Vercel: warsztat, ewaluacja i bezpieczeństwo (Vercel CEO reveals his Agentic Engineering Workflow)

O czym jest ten film

1. Rozmowa Davida Ondreja z Guillermo Rauchem, założycielem i szefem Vercel, o inżynierii agentowej — czyli o tym, jak profesjonalnie i na skalę pracować z agentami AI przy budowaniu oprogramowania.
2. Główna teza: dźwignia przenosi się o warstwę abstrakcji wyżej — ku orkiestrowaniu flot agentów i „fabrykom oprogramowania” — a po stronie ludzi zostaje kontrola twórcza, smak i opowieść.
3. Skąd przewaga w świecie, w którym każdy może zbudować wszystko: lista zadań „niemożliwych” dla modeli, wyczucie momentu premier i własne evaly zamiast pogłosek z sieci.
4. Miara „agentowości” firmy: czas od sygnału klienta do autonomicznej naprawy; różnica między szybkością iteracji a prędkością w określonym kierunku; co budować samemu, a co kupować.
5. Warsztat gościa: minimalistyczne CLI „fx” z Vercel Labs, osadzalna biblioteka libfx, demo „FX0” (własne v0 w około stu liniach kodu), AI Gateway i zasada „nie używaj jednego modelu”.
6. „Inżynieria weryfikacji”: uzgadnianie z agentem aksjomatów i kompromisów, inwestowanie w krawędzie systemu zamiast mikrotestów oraz „agentowe dociekania” zamiast czytania każdej linii kodu.
7. Wiedza systemowa jako dźwignia: tabele rzędów wielkości opóźnień, poziomy cache, czas podróży pakietu między kontynentami — bez tej orientacji nie da się skutecznie „dociskać” AI.
8. Cyberbezpieczeństwo jako twardy temat: narzędzie DeepSec, uśpione luki w ludzkim kodzie (przypadek biblioteki libheif), przepisywanie krytycznych bibliotek na bezpieczny pamięciowo Rust i bezpieczeństwo jako wyróżnik sprzedażowy.
9. Agenci w chmurze: sandboxy jako sposób na ataki na łańcuch dostaw i na zrównoleglanie pracy, przy zachowaniu opcji zejścia na lokalną maszynę; kontekst produkcyjny jako „karma” dla agentów.
10. Na koniec rady dla założycieli: wybieraj problem, do którego czujesz osobiste przekonanie, podnoś ambicję dziesięciokrotnie albo stokrotnie i trzymaj bardzo wysoko poprzeczkę wobec tego, co pokazuje AI.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Prowadź listę rzeczy, których AI jeszcze nie potrafi

Na czym polega: Guillermo radzi zapisywać najbardziej ambitne prompty i zadania, których modele dziś nie wykonują. Lista kurczy się z każdą premierą, a moment, w którym nowy model „odblokowuje” kolejny punkt, to gotowa okazja biznesowa.

Jak stosować: Załóż plik z „niemożliwymi” zadaniami w twojej domenie i przeglądaj go po każdej premierze modelu. Gdy model zaczyna radzić sobie z którymś punktem — zbuduj demo albo produkt, zanim zrobi to ktoś inny.

Na co uważać: Nie ufaj zapowiedziom i benchmarkom producentów — każdy punkt sprawdzaj na własnym przykładzie. Lista starzeje się szybko, więc weryfikuj ją regularnie.

2.Zamień „czuja” na własne evaly

Na czym polega: W środowisku AI dominują rady oparte na pogłoskach: „przeczytałem na X, że tak lepiej promptować, więc tak robię”. Rzadko kto sprawdza, czy to daje lepsze wyniki. Przewaga jest w wyprowadzaniu prawdy — osobistych i firmowych testach porównawczych.

Jak stosować: Dla powtarzalnych zadań (generowanie stron, refaktoryzacja, analiza bezpieczeństwa) przygotuj stały zestaw przykładów i oceniaj modele punktowo. Porównuj też koszty — najdroższy model rzadko wygrywa we wszystkim.

Na co uważać: Źle dobrane zadania dają fałszywą pewność. Evaly wymagają utrzymania: gdy zmienia się model albo proces, zestaw testów trzeba aktualizować.

3.Szybkość to nie prędkość: kierunek przed tempem

Na czym polega: Liczba wdrożonych pull requestów i spalonych tokenów to metryki szybkości. Prędkość to tempo w konkretnym kierunku — można lądować PR-y „w otchłań” i nie zbliżać się do celu ani o krok.

Jak stosować: Wybierz kilka problemów, w których możesz mieć nieproporcjonalną przewagę, i na nich koncentruj wysiłek agentów. Resztę kupuj jako gotowe usługi — własna bramka płatności czy serwer poczty rzadko są twoją alfa.

Na co uważać: Agenci pozwalają brać na siebie wiele projektów naraz i to jest pułapka. Dwadzieścia rzeczy równolegle oznacza przeciętność we wszystkich.

4.Mierz czas od sygnału klienta do naprawy

Na czym polega: Rubryka „agentowości” firmy: czy zgłoszenie klienta kończy się wysokiej jakości odpowiedzią, uruchomieniem śledztwa i naprawą — oraz po jakim czasie. Firma, która naprawia wszystko w pół godziny, wyprze firmę naprawiającą w dwa dni.

Jak stosować: Wyodrębnij typowe kategorie sygnałów (błąd, awaria, konkretna propozycja poprawy) i automatyzuj dla nich ścieżkę od zgłoszenia do wdrożonej łatki. Mierz to opóźnienie i stale je skracaj.

Na co uważać: Nie każdy feedback da się od razu zamienić w akcję — części trzeba się dosłuchać z klientem. Autonomia nie może oznaczać wydawania sieczki bez smaku i weryfikacji.

5.Inwestuj w krawędzie systemu, nie w mikrotesty

Na czym polega: Testy jednostkowe pisane na siłę — na przykład sprawdzające, że stała ma wartość cztery — dają fałszywe poczucie pewności. Lepiej definiować aksjomaty i poręcze: warunki poprawności, budżety wydajnościowe, estetykę rozwiązania.

Jak stosować: Uzgodnij z agentem zestaw kompromisów (szybkość kontra bezpieczeństwo kontra rozmiar) i zapisz to w instrukcjach projektowych. Swój czas przeznaczaj na brzegi systemu, nie na detale implementacji.

Na co uważać: Skrajne „nie wierzę już w testy” jest równie błędne jak testomania. Bez szkieletu weryfikacyjnego agent poprowadzi projekt, dokąd sam zechce.

6.Znaj rzędy wielkości — to pozwala dociskać AI

Na czym polega: Nie potrzebujesz wiedzy encyklopedycznej, ale orientacji: ile trwa odczyt z cache, przesłanie pakietu między kontynentami, jak działają poziomy cache’owania. Dzięki temu wiesz, co jest możliwe do poprawy, i możesz powiedzieć agentowi „przyspiesz to” z sensem.

Jak stosować: Trzymaj pod ręką tabelę rzędów wielkości opóźnień i używaj jej do oceny wyników pracy agenta. Gdy strona ładuje się sekundę, a wiesz, że da się w dwieście milisekund — masz konkretny cel do zlecenia.

Na co uważać: Nie daj się przekonać, że „AI samo napisze optymalnie szybki kod”. Model zawsze pracuje w systemie kompromisów — i to ty definiujesz, które mają pierwszeństwo.

7.Praktykuj „agentowe dociekania”: rozumiej, co się stało

Na czym polega: Nie chodzi o czytanie każdej linii kodu, ale o rozumienie efektu pracy agenta po fakcie. Guillermo mówi wprost: „odrzucaj nierozumienie” — ci, którzy głoszą, że już nic nie trzeba rozumieć, sami najczęściej tej rady nie stosują.

Jak stosować: Po każdym istotnym zadaniu poproś agenta o wyjaśnienie zmian, diagram wywołań czy porównanie z alternatywami. Skonfiguruj powiadomienia — na przykład na Slacku — o zmianach publicznego kształtu API.

Na co uważać: Unikaj binarności „albo czytam wszystko, albo wcale”. Rozumienie modularne, z pomocą samego agenta, wystarczy i dobrze się skaluje.

8.Zarządzaj „długiem sieczki” i komunikuj bezpieczeństwo

Na czym polega: Dług technologiczny bywa zdrowy — na Ruby on Rails i zasadzie „ruszaj szybko” zbudowano wielkie firmy. Ale są obszary — bezpieczeństwo, płatności, dane — w których trzeba robić odwrotność vibe codingu: maksymalną staranność i audyt.

Jak stosować: Podziel produkt na strefy: „wydaję szybko, bez pytań” oraz „maksymalna staranność”. W drugiej strefie badaj kod narzędziami typu DeepSec i komunikuj przeprowadzone audyty — wobec dużych klientów to realny wyróżnik.

Na co uważać: Enterprise nie kupi bez mocnego przekonania o profilu bezpieczeństwa. Jedna ujawniona luka w zależności — jak w bibliotece libheif — może obciążać cały łańcuch dostaw.

9.Przenoś pracę agentów do sandboxów w chmurze

Na czym polega: Sandboxy ograniczają skutki ataków na łańcuch dostaw (zamiast całego laptopa z menedżerem haseł atak obejmuje odizolowane środowisko), pozwalają zrównoleglić dziesiątki agentów i pracować, gdy śpisz.

Jak stosować: Ciąg zadań typu „niech się gotuje w tle” — badania, benchmarki, red teaming, analizy bezpieczeństwa — przenoś do środowisk chmurowych z polityką sieciową i monitoringiem.

Na co uważać: Nie likwiduj opcji lokalnej. Czasem trzeba obejrzeć system „pod mikroskopem”, z najniższym opóźnieniem i pełnym wglądem. Skrajność — wszystko w chmurze albo wszystko lokalnie — to błąd.

10.Dokarmiaj agentów danymi z produkcji

Na czym polega: Agent z dostępem tylko do odczytu w metrykach produkcyjnych (P99, sesje bez błędów, eksperymenty z flagami funkcji) zweryfikuje przed wdrożeniem, czy pomysł ma pokrycie w rzeczywistości — zamiast budować coś, czego nikt nie potrzebuje.

Jak stosować: Podłącz agentów do metryk, logów i wyników eksperymentów. Przy każdej zmianie pytaj nie tylko „czy działa”, ale „czy ludzie tego potrzebują i czy działa u nich”.

Na co uważać: Metryki operacyjne nie zastąpią smaku. Łącz dane z produkcji z ludzkim osądem, bo „wydaje mi się, że jest szybko” — sprawdzone na jednym środowisku — bywa złudzeniem.

Redakcyjne tłumaczenie

Zapowiedź — fragmenty wypowiedzi Guillerma Raucha

Jednym z moich największych wyzwań — prywatnie i w Vercel — jest dziś zrozumienie, jakiego długu bezpieczeństwa zaciągam, wdrażając nowe oprogramowanie. Powierzchnia ataku zrobiła się ostatnio ogromna. Prawdopodobnie musimy zacząć pisać kod w innych językach programowania. Wyzwanie, przed którym stoi dziś wiele organizacji, polega na tym, że liczby uśpionych luk w całym tym ludzkim, ręcznie pisanym kodzie praktycznie nie da się zmierzyć. Gdybyśmy przenieśli coraz większą część cyklu rozwojowego do sandboxów, moglibyśmy wyplenić ataki na łańcuch dostaw.

Co będzie miało znaczenie w erze po AGI

David Ondrej: Dobrze. Guillermo, co będzie miało znaczenie w erze po AGI?

Guillermo Rauch: Nasza — ludzka — zdolność do zachowania kontroli. I mówię tu o kontroli twórczej, o panowaniu nad ryzykiem w cyberbezpieczeństwie, o tym, żeby agenci ostatecznie pracowali dla nas. Dużo o tym mówię: dźwignia przenosi się o warstwę abstrakcji wyżej — ku inżynierii „opprzyrządowania” (tzw. harness engineering, czyli budowania środowisk, w których działają agenci), fabrykom oprogramowania, flotom agentów, którymi orkiestrujesz. Głęboko wierzę w nasz smak i naszą kreatywność jako ludzi, bo wciąż zwracamy się do innych ludzi. Uwielbiamy kupować opowieści, produkty i usługi od innych ludzi. Lubimy myśleć, że podejmujemy w pełni racjonalne decyzje, ale bardzo często kupujemy po prostu historie, klimaty, marki, smaki. Agenci mają się — miejmy nadzieję — stać narzędziem do snucia coraz lepszych opowieści i do coraz większego rozmachu ludzkich ambicji.

David Ondrej: Podoba mi się, co powiedziałeś o pracy na wyższym poziomie, bo ludzie zawsze boją się, że któreś stanowisko zniknie, że jakieś zadanie przestanie być potrzebne. Rolnictwem zajmowałoby się kiedyś dziewięćdziesiąt procent społeczeństwa — dwieście lat temu, nie dwieście tysięcy — a dziś uprawą ziemi żyje mniej niż jeden procent. Jeśli myśleć o pracy według starego modelu, to trochę jak wypełnianie formularzy: ręczna robota. Jak to więc będzie wyglądać? Będziemy zarządzać flotami agentów, wybierać modele, decydować, na jakim sprzęcie działają?

Guillermo Rauch: Śmieszne, bo jeden z moich ostatnich najlepiej odbieranych tweetów brzmi: robię to dla zabawy. Buduję oprogramowanie, żeby się zrelaksować. Buduję je w pracy, a potem wracam do domu i buduję kolejne. Buduję z dziećmi, buduję z żoną. Po prostu nieustannie coś buduję. I właśnie tutaj analogia z rolnictwem się kruszy. Zresztą — są ludzie, którzy naprawdę kochają uprawę ziemi i być może przez setki lat, przez tysiąclecia, będą ją nadal uprawiać.

David Ondrej: Nazywa się to ogrodnictwem.

Guillermo Rauch: Dokładnie. Trzymają swoje mini gospodarstwo na balkonie. Ale większość z nas pisze kod, bo to nasze medium ekspresji — i tego nikt nam nie odbierze. Z tej butelki nie da się już wypuścić dżina. Widać to zresztą po benchmarkach, na których modele rywalizują w tworzeniu nowych światów. Był ten tweet Karpathy’ego o „nieciągłości”: najpierw wprowadził vibe coding, potem dodał, że modele zrobiły się tak dobre, iż potrafią tworzyć całe światy — mogą na nowo odtworzyć Hobbita albo Władcę Pierścieni. Wchodzimy więc na kolejny poziom swobody twórczej, jaką daje AI: tworzenie nowych światów, gier. Mówiłem też, że sama sieć, którą konsumujemy, robi się bardzo wystawna. Wyróżniają się dziś te doświadczenia, które naprawdę starają się cię zachwycić: 3D, animacje, efekty cząsteczkowe. Możemy dziś dosłownie zbudować wszystko — i ludzie ostro korzystają z tej nowej swobody. Widzę mnóstwo osób, które budują rzeczy tylko dlatego, że wcześniej nie mogły, i czerpią z tego ogromną radość. To bardzo dobry objaw.

Materiał reklamowy: Supabase

David Ondrej: Koduję z AI od prawie czterech lat. W 2023 jako pierwszy rozpocząłem trend „zbuduj cokolwiek” i od tego czasu wiele się zmieniło: mamy inne modele, inne narzędzia, innych agentów. Ale mimo tych wszystkich zmian każdy mój projekt ma coś wspólnego — zawsze używam Supabase jako backendu. Nawet nie zastanawiam się, jakiej bazy danych użyć. Po prostu biorę Supabase: jest prosty, skaluje się i jest zbudowany z myślą o agentach. Nigdy nie było łatwiej zacząć — agenci mogą dziś zbudować za ciebie cały backend, bo Supabase działa wewnątrz Codex i Claude Code. Wiadomo: z AI pisze się kod szybciej niż kiedykolwiek. Ale ludzie utykają na backendzie — baza danych, logowanie, storage, wszystko to, co musi działać bez zarzutu. Supabase ogarnia to za ciebie. Oficjalny konektor wystarczy, by poprosić Codexa albo Claude Code: „stwórz tabelę zaproszeń”, „wdroż tę funkcję”, „sprawdź moją aplikę pod kątem luk bezpieczeństwa” — i agent zrobi to w twoim projekcie Supabase. Sam używam Supabase we wszystkich swoich backendach i ty powinieneś tak samo. A najlepsze: mają naprawdę hojny plan darmowy. Wejdź na supabase.com i przetestuj za darmo — pierwszy link pod filmem.

Skąd przewaga, skoro każdy może zbudować wszystko

David Ondrej: Skoro każdy może zbudować wszystko — skąd bierze się przewaga? Widzowie chcą wiedzieć, jak się przebić, jak zbudować biznes. Czy to kwestia smaku? Kreatywności? Bycia bardziej technicznym?

Guillermo Rauch: Składników jest mnóstwo. Chciałem ostatnio wrzucić post o czymś takim: za każdym razem, gdy wychodzi nowy model, pierwszą rzeczą, którą robimy — ty i ja alike — jest wypróbowanie go. I to jest ćwiczenie, które polecam każdemu: istnieje cała lista rzeczy, których modele dziś po prostu nie potrafią. Ta lista kurczy się i zmienia w czasie — dwanaście miesięcy temu była dłuższa. Zapisuj — w głowie albo na papierze — najbardziej szalone, najbardziej ambitne zadania, jakich model mógłby sprostać. Wyczucie czasu i anticipacja naprawdę się opłacają: gdy model wchodzi na rynek, ludzie eksplorują jego możliwości i to jest twoja szansa — może właśnie zbudujesz biznes, bo „wyszedł Opus 5.5 i ta rzecz, przy której modele zawodziły, właśnie stała się wykonalna”. To cała kategoria okazji. Można też użyć kreatywnej mocy modeli do lepszego przekazu. Widać to u firm: „skoro model potrafi to i tamto, pokażmy naszą markę i produkt w świetle nowych możliwości”. U nas dobrym przykładem była premiera Jeva.*

(Informacja dodatkowa: „Jev” — premiera nowej kategorii produktu AI, o której mowa w rozmowie; zapis nazwy może być przekręcony w automatycznym transkrypcie.)

Jev wyszedł, podchwyciliśmy tę falę i zaczęliśmy edukować. Świat ma ogromny apetyt na wiedzę o AI, na ogarnięcie tematu — wiele osób po prostu się boi. Na przykład za każdym razem, gdy wychodzi nowy model, przepuszczamy go przez benchmarki DeepSec, żeby pomóc światu zrozumieć: ten model jest dobry w cyberbezpieczeństwie, tyle kosztuje. Jest teraz mnóstwo „alfy” — przewagi — w czymś, co jest ironiczne, bo modele są banalnie łatwe w użyciu: wystarczy napisać prompt po angielsku. A jednak wymagają mistrzostwa. Trzeba rozumieć, który model do czego jest najlepszy. To cała przestrzeń ewaluacji: możesz stać się głosem, który w publicznych testach pomaga innym rozeznać się w modelach. Jest też przestrzeń evalów osobistych — i tu również widzę dużo alfy. Inną ironią AI jest to, że często działamy „na czuja”. Słyszę ludzi: „czytam coś na X i zmieniam sposób promptowania”. Ktoś powiedział mi niedawno: „przeczytałem poradnik i było tam, że Astra działa lepiej z mniejszą ilością tego i tamtego, więc tak teraz robię”. Zapytałem: „ale sprawdziłeś, że to faktycznie daje lepsze wyniki?”. „Nie — po prostu ufam temu, co mówią inni”. Ogromna przewaga jest dziś w tym, czy naprawdę wyprowadzasz prawdę o możliwościach modeli — czy masz zestaw osobistych evalów, firmowych evalów, które pozwalają ci nawigować w świecie pędzącym tak, że co tydzień jest nowy model do przetestowania, a co tydzień — jak pokazał Jev — pojawiają się wręcz nowe kategorie produktów AI.

David Ondrej: Ale czy „czuj” nie jest częścią tego, co czyni nas ludźmi? Bo z modelami bywa tak: trzeba wypuścić funkcję, jest presja, release jutro — człowiek-inżynier nie może być perfekcjonistą. Model za to z przyjemnością spędzi pół godziny na czymś zbędnym, na detalu, który inżynier pominąłby zważywszy na szerszy kontekst. Więc jak myślisz: ta kreatywność, te wibracje — zostaną z nami, czy lepsze modele je przejmą?

Guillermo Rauch: Kreatywność — na zawsze. Bo dopóki sami nie przeniesiemy się do sieci społecznościowej tworzonej przez AI i nie zaczniemy obserwować AI kształtujących naszą przyszłość, rzeczywistość jest taka, że to my nadal odpowiadamy za nasze marki, nasze opowieści, nasze wartości. Jest też estetyka projektowa, którą ludzie mogą pielęgnować. Vercel wygląda w określony sposób — i świadomie w to inwestujemy, budując emocjonalną więź z odbiorcami. Chodzi o to, by AI wzmacniało twoją historię. Jak narzędzia twórcze — modele obrazu i wideo — mogą pomóc opowiedzieć ją lepiej? Jak mogą pomóc szybciej wdrażać? Jedno jest jasne: będziesz wdrażać częściej i prawdopodobnie lepsze produkty. Pytanie o różnicę: czy wydajesz z prawdziwą prędkością AI, czy zostajesz w tyle? Przez jakiś czas będzie rozstrzał — będą jednostki i firmy, które po prostu lepiej wykorzystują tę supermoc. Podobnie było z chmurą, gdy zyskała popularność: jedni chwycili ją od razu i używali bardzo sprawnie, inni do dziś migrują z własnych serwerowni. I ciekawostka: AI teraz zmusza do ruchu tych, którzy zwlekali. Można sobie wyobrazić, że wielu odkłada też „agentowość” na później — i ci ludzie prawdopodobnie zostaną okrążeni przez organizacje działające autonomiczniej i z większym przekonaniem.

Fabryki oprogramowania i sygnał od klienta

David Ondrej: To wejdźmy głębiej. Co odróżnia firmę, która naprawdę wyciska z AI siódme poty? Budowa autonomicznych fabryk oprogramowania? To się zresztą zmienia co kwartał.

Guillermo Rauch: Szczerze wierzę, że mamy szansę raz w życiu robić dokładnie to, czego chcą klienci — brzmi to ironicznie, ale przecież każda duża firma w każdym momencie dostaje feedback od klientów. Weźmy Comcast: ludzie piszą na Reddicie, dzwonią na infolinię, wysyłają e-maile — internet padł, chcą wiedzieć, dlaczego. Jaka jest dziś twoja zdolność, by zamieniać krytyków w ambasadorów marki? Gdy się odzywają, czy odpowiadasz im wysokiej jakości odpowiedzią przygotowaną przez agenta? Gdy zgłaszają problem, czy uruchamiasz śledztwo incydentalne? Gdy zgłaszają coś konkretnego i naprawialnego — czy naprawiasz to autonomicznie? To całkiem przyzwoita miara, cała rubryka „jak agentowa jest twoja firma”: od sygnału klienta, który jednoznacznie wskazuje, że coś w produkcie jest zepsute, wadliwe albo wymaga poprawy — czy faktycznie wdrażasz naprawę? I po jakim czasie? Prawie dałoby się to ująć matematycznie: sygnał wpłynął, w końcu go ogarniasz. Obrazowo: jest firma, która okresowo „odkurza” sygnały — przez smak, przez product managerów, przez łańcuch eskalacji: „aha, czas naprawić”. I jest firma, która staje się prawdziwie autonomiczna w dobrym sensie — nie w sensie „puśćmy agenty na szał, niech wydają sieczkę”. A skoro mowa o Jevie i o tym, dlaczego wszyscy są tacy podekscytowani: bardzo szybkie podejmowanie decyzji może być krytyczne dla kształtowania tych fabryk oprogramowania, bo jest w tym także element osądu i smaku. Słynnie Jobs, DHH i wielu innych powtarzali: nie jesteś maszyną, która zamienia zachcianki klientów w produkt. Jest element decyzji. Ale jest też obiektywność: produkt może sypać wyjątkami na produkcji. Albo ktoś przychodzi z uczciwą, prostą propozycją ulepszenia. My robimy dużo na X: ludzie przysyłają feedback ze zrzutem ekranu albo filmem — i to jest strzał w dziesiątkę, bo nie ma tu nic z ludzkiej kreatywności: ktoś wskazuje coś, czego sam doświadczył, problem, który powinniśmy od razu naprawić. I to jest okazja, by testować hipotezę fabryki oprogramowania. Ciekawostka: wczoraj napisał do nas gość, że gubi się w naszej nawigacji. Dał świetny feedback, ale nic, co dałoby się od razu przekuć w akcję — nie mogłem wziąć jego uwagi i zamienić w prompt. Więc szef naszego obszaru dashboardów odezwał się do niego i zaczęli korespondować. Dostarczył więcej nagrań, więcej jakościowych uwag — i nawet to wymaga kolejnej warstwy ludzkiego osądu, by przełożyć to na decyzję produktową. Można oczywiście projektować daleko w przyszłość — a w AI „daleko” to pół roku, rok — że część tego interfejsu i część oczekiwań klienta stanie się jego własnym, generatywnym interfejsem. Ale to jeszcze odległa przyszłość. Na razie naszą rolą jest ważenie feedbacku i doprowadzanie go — przez prompt — do wydanego produktu.

David Ondrej: A przy tych oczywistych zgłoszeniach — przycisk nie działa, płatności padają — myślisz, że czas do naprawy to jedna z głównych liczb prognozujących sukces biznesu? Bo jeśli pójść od pierwszych zasad: biznes to produkt, który poprawia się z czasem.

Guillermo Rauch: W stu procentach. I taka zawsze była historia technologii. Dlatego dawałem przykład firm, które nie bały się komputerów osobistych — w przeciwieństwie do tych, które mówiły: „porobimy to ręcznie” — oraz firm, które wcześnie i z priorytetem przyjęły internet. Z historii sieci jest coś ciekawego do nauczenia: wiele firm „lubiło” internet, ale w stylu „zatrzymam firmę, która zrobi mi internet”. I tak samo wiele firm chce dziś podejść do AI — to wciąż się dzieje. Ciekawostka: rozmawiam z wielkimi korporacjami i bardzo często słyszę, że nie są nawet właścicielami własnej strony internetowej. Tu jest analogia: będą firmy, które powiedzą: „kochamy AI — kupmy pakiet licencji i dorzućmy je inżynierom”. I będą takie, które powiedzą: „nie, to zaburzenie, które tworzy nowy konkurencyjny krajobraz. Jeśli naprawdę opanujemy ten surowiec — trochę jak redstone w Minecrafcie, nowy blok, którego obróbka da nam przewagę — wygramy”. Wierzę w to w stu procentach. I tak, jest element pomiaru. Nie chcę schodzić czysto na taktykę — że poprawa jednej metryki to cel sam w sobie. Mówimy u nas, że jest szybkość iteracji i jest prędkość iteracji. Szybkość to tempo, z jakim wyplatasz rzeczy. Dlatego gdy słyszę, ile tokenów spalasz — „maksowanie tokenów” — i ile lądujesz pull requestów: brawo, niezłe metryki. Ale prędkość oznacza tempo w określonym kierunku. Możesz lądować PR-y prosto w otchłań. Dam bardzo konkretny przykład. AI pomaga ludziom zrozumieć, że mogą zbudować bardzo dużo. Czego — moim zdaniem — nie pomogła jeszcze zrozumieć: są rzeczy, które należy budować, i takie, które należy kupować. Są usługi do części zadań i są zadania, przy których warto napisać kod samemu. Rozmawiałem niedawno z założycielką startupu. Przyszła do biura: „buduję naprawdę fajny pomysł na agentów” — i pomysł wydał mi się przekonujący. A potem opowiedziała, że buduje też własny serwer poczty i własną bramkę płatności… Część z tego może mieć sens, część nie — ale brała na siebie bardzo dużo. Tak to odebrałem. Oczywiście, jest wersja optymistyczna: przy tylu agentach pracujących równolegle możesz unieść więcej projektów. Ale pozostaję sceptyczny, bo naprawdę chcesz wybrać kilka problemów, w których możesz mieć nieproporcjonalną przewagę, wejść w nie bardzo głęboko, spalić na nich jak najwięcej tokenów i poruszać się jak najszybciej. To właśnie sugeruje słowo „prędkość” — kierunek. Nie chodzi tylko o lądowanie PR-ów, ale o to, dokąd zmierzasz i czy faktycznie robisz postęp w stronę celu.

David Ondrej: Dokładnie. Robiąc dwadzieścia rzeczy naraz będziesz przeciętny we wszystkich. A żeby odnieść sukces, trzeba zbudować jedną rzecz — i to świetnie.

Guillermo Rauch: Właśnie to zaczyna się już dziać. Zauważ, że mnóstwo ludzi wdraża bardzo szybko, wchodzisz na ich stronę — a tam sterta sieczki. Czujesz, że nie ma wartości dodanej ponad to, co zrobił model. Zresztą tak już było z webem: nie szanowano strony na domyślnym szablonie, która wyglądała jak kupiony zestaw startowy wyrzucony w sieć. Ludzie automatycznie wyłączają uwagę, gdy widzą coś, co wygląda na wyplute przez model — bo, cóż, skoro ty mogłeś to zrobić jednym promptem, ja też mogę. Jest w tym element „spocenia się na detalach”, który pozwala znacznie lepiej zakomunikować twoje zamiary, wartości i kierunek.

Materiał reklamowy: CloudRoom

David Ondrej: Przy okazji: jeśli płacisz za kilka subskrypcji po dwieście dolarów miesięcznie, słuchaj uważnie, bo chcę ściśle współpracować z kilkoma z was przy budowie CloudRoom. To open source’owa platforma do uruchamiania agentów w chmurze — pierwsze takie w pełni otwarte rozwiązanie. Macie Devina, Cursora, Codexa, Claude — wszystko zamknięte. Chcą, żebyście siedzieli w ich subskrypcji, w ich środowisku, w ich interfejsie. Tymczasem już płacisz za inferencję, płacisz za tokeny, masz pewnie kilka subskrypcji. Powinieneś móc używać tej inferencji ze swoimi ulubionymi modelami i ulubionym narzędziem. To jest CloudRoom: w pełni open source i za darmo. Na razie nie jest jednak otwarty dla wszystkich — szukam prawdziwych power userów, ludzi, którzy dadzą mi feedback codziennie, ludzi z wysokim poczuciem smaku, jeśli chodzi o agentów kodujących i pracę w chmurze. Jeśli to ty — masz plan za dwieście dolarów na Codexie, Claude Code i pół innych rzeczy — wejdź na cloudroom.dev i zapisz się na listę oczekujących. Codziennie wybiorę garstkę osób, dam dostęp i będę z nimi blisko współpracował przy budowie tej platformy. Link znajdziesz pod filmem.

Warsztat agentowy: jak pracuje Guillermo

David Ondrej: Opowiedz o swoim obecnym setupie agentowym. Jak wygląda? Czego używasz?

Guillermo Rauch: Ogólnie w Vercel zachęcamy ludzi, żeby wypróbowali wszystko. Nie narzucamy agenta do kodowania ani frameworków — nasza postawa zawsze była: otwartość. Nasz najszybciej rosnący produkt — licząc przychody, adopcję, liczby — to dziś AI Gateway. Teza jest taka: jako firma powinnaś inwestować w swoją „tkankę” inżynierii agentowej… i nie powinnaś siedzieć na jednym modelu. Poza tym pokazałeś mi swój setup — bardzo fajne, że zbudowałeś własny klient, własne IDE i wybierasz między środowiskami. My zresztą mamy aplikację w pasku menu, która pokazuje wydatki na tokeny. Każdy inżynier w Vercel ją ma i widzi: ile wydałem na model OpenAI, ile na Kimi, ile na Opusa. Jedna z założycielskich filozofii brzmi: testuj dużo rzeczy, zwłaszcza modele. Osobiście AI było dla mnie cudowne, bo zawsze wierzyłem w prostotę wiersza poleceń. Kiedy zakładałem Vercel — sprawdź w Wayback Machine — wystartowałem od wydania CLI. Wchodziłeś na zeit.co i klikałeś „Install Now”. „Now” było naszym narzędziem do wdrożeń i, jak nazwa wskazuje, wystarczyło wpisać now w dowolnym katalogu, a dostawałeś adres URL tego, co właśnie wdrożyłeś. Potem zmieniliśmy nazwę produktu — dziś to Vercel. Ale jedenaście lat po założeniu firmy to, co wciąż rośnie wykładniczo i daje nam cały ciężar gatunkowy, to fundament: CLI, które pozwala — dziś coraz częściej agentom — wziąć wszystko, co zbudowałeś, postawić w chmurze i uczynić natychmiast dostępnym. Mój osobisty stack zawsze był taki: czy da się to zrobić w terminalu. Zawsze byłem użytkownikiem neovima, więc oczywistym kolejnym krokiem był Claude Code. Bardzo się ucieszyłem, gdy wyszedł, bo wszyscy inni budowali bardzo wyrafinowane aplikacje, a oni odnieśli sukces, idąc w kierunku jądra tego, co w AI różnorodne: koniec końców to po prostu zapakowanie inteligencji i oddanie ci promptu. Dziś używam fx — CLI do kodowania z Vercel Labs. Jedna z zasad projektowych: ma działać prawie jak shell. Otwieram nową kartę w Ghostty albo dzielę okno — startuje zsh. Upialiśmy się nad tym, żeby nasze narzędzie startowało równie szybko jak sam shell. To maleńki program: po instalacji zajmuje jedenaście megabajtów na dysku, do pobrania ma sześć. Startuje niewiarygodnie szybko. Chodziło o to: jeśli uruchamiam powłokę w powłoce, to czy potrafię zrobić ją równie żwawą?

David Ondrej: Co cię do tego skłoniło? Większość agentów jest opasłych: nieskończone umiejętności, wtyczki. Nasuwa mi się „pi” — chyba najbliższy duchem minimalny agent. Wzorowałeś się na nim?

Guillermo Rauch: Ciekawe, że pytasz, bo Vercel przez całą historię kojarzony był z TypeScriptem. Mamy jeden z czołowych — właściwie najpopularniejszy — projekt open source w tym ekosystemie: AI SDK. Chcieliśmy w fx поэкспериментować z dwiema rzeczami. Po pierwsze: jak wyglądałoby większe inwestowanie w narzędzia natywne? Jedna z rzeczy, która zawsze mnie drażniła w CLI — nie chcę nikogo przysmażać — to że za każdym razem, gdy odpalałem Claude’a, był czas startu, potem wszelkie disclaimery… A ja chcę po prostu wyjąć coś z głowy jak najszybciej. Druga rzecz: zacząłem sobie uświadamiać, że filozofia Uniksa polega na składaniu małych programów. Bash czy zsh to dokładnie to: programy wołające inne programy. Więc pomysł był taki: zrobić program, który z czasem pozostanie dość niezmienny — bez dokładania kolejnych elementów interfejsu.

David Ondrej: To jest problem wielu z tych agentów: budujesz na nich biznes, a potem się sypie. Zaczynają malutkie i szybkie — to zresztą Initially mnie zachwyciło w Claude: „boże, prawie nic tu nie ma” — a potem trzeba walczyć z pokusą dokładania. Ale prawda, że ludzie powinni móc te narzędzia rozszerzać — po to są open source.

Guillermo Rauch: I fx jest jednocześnie superminimalistycznym CLI i biblioteką do osadzania w innych programach. Klasyczny paradygmat ze świata C: masz narzędzie wiersza poleceń i do niego lib. Tak jest i tu: obok fx idzie libfx. Powiem ci — to jest tak uzależniające, że zacząłem używać go do własnych badań… Zresztą uświadamiam sobie — pewnie zamazujemy to w montażu — że AI wynosi na wierzch jeszcze jedną rzecz: powrót do fundamentów Uniksa i fundamentów informatyki. To nie tylko zestaw małych programów. To też fakt, że system plików to w zasadzie wszystko, czego potrzebujesz. Tuż przed naszą rozmową ogłosiliśmy Vercel Drives — sposób modelowania systemu plików w chmurze, wokół którego można rozstawiać agentów: stawiasz sandbox i podpinasz dysk. Nie wiem, czy widziałeś, że ludzie zaczęli badać od środka Muse i Instinct, albo jak działa OpenClaw. OpenClaw jest tak prosty, że to w istocie Claude Code plus plik SOUL.md. Program linuksowy plus system plików — w zasadzie wszystko, czego trzeba, żeby uruchomić agenta. Używam fx do wielu rzeczy. Po pierwsze: zawsze, gdy mam pytanie o cokolwiek — swoją drogą zastąpiło mi Google — bo zamiast iść do „chmurowego czegoś”, mogę trzymać większość eksperymentów w systemie plików i agent na nie patrzy. I to jest trochę przyszłość oprogramowania: staje się ono znacznie bardziej „angielskojęzyczne”. Plik agents.md w folderze badań tworzy konwencję: zadaję agentowi pytanie, on czyta instrukcje i zrzuca wyniki do tego folderu. I mogę to z czasem ulepszać. Druga rzecz: mam alias — dosłownie jedna litera, R — który wchodzi do tego katalogu i go odpala. W zasadzie nie ma tu nic do zrobienia: wejście do folderu i otwarcie fx — a jednak zjada całe opóźnienie. Człowiek się uzależnia: mam pytanie, w które chcę wejść głęboko — odpalam i żyję sobie dalej. Kolejny alias: P. Robię coś podobnego do tego, co Tobi Lütke ze Shopify w swoim terminalu. Bardzo często mam pomysł na nowy projekt — i za każdym razem procedura jest ta sama, tylko że w folderze projektów powstaje nowy. Robię mnóstwo eksperymentów z lokalnymi aplikacjami na Maca, tworzę nowe aplikacje Next.js, nowe programy w Zigu czy Ruście, dużo benchmarkuję, żeby pomagać zespołom. Za każdym razem, gdy stawiamy nową infrastrukturę, staram się zweryfikować ją od pierwszych zasad: jak podszedłby do niej agent. Przykład: gdy ogłaszaliśmy Drives, kazałem agentowi spróbować to zepsuć — szukać wyścigów o zasoby, mierzyć opóźnienia, porównywać z alternatywami. Dużo robię też tego, co nazywam „agentowym dociekiem”: wysyłam agenta, żeby wypróbował jedną z naszych technologii, a potem kazałem mu się zastanowić i powiedzieć, co Vercel mógłby zrobić lepiej. To działa cuda.

Domyślny model i demo FX0

David Ondrej: OK, fx to twoje narzędzie. Jaki masz teraz domyślny model?

Guillermo Rauch: Staram się testować wszystko. Przez ostatnie parę dni — Opus 5.5 w wersji fast. Jestem bardzo pod wrażeniem.

David Ondrej: Tak, jest bardzo szybki.

Guillermo Rauch: Przy okazji — powinienem ci pokazać coś, o czym wspominałem. Jedna z idei fx: ma być osadzalny. Inspiracją dla libfx było to, że gdy budowaliśmy v0, musieliśmy napisać całe środowisko od zera. Gdybym dziś robił coś w rodzaju v0 — albo dowolną aplikację tego typu: wyobraź sobie Gamma robiące slajdy, albo coś jak Notion, cokolwiek wymagającego osadzenia inteligencji agentowej — chciałbym wziąć takie środowisko z półki. Zrobiliśmy więc przykład, który otworzymy — jesteś jedną z pierwszych osób, które go widzą. Dam prompt: „stwórz prostą stronę”. Domyślnym modelem jest tu Opus 5.5… Najprostszy możliwy v0, jaki możesz zbudować, to generowanie stron HTML. Zrobiłem rzecz, która pomaga wybrać między trybem design, app i agent. I podobnie jak ty jestem niesamowicie pod wrażeniem szybkości. „Zmień tło na czerwone.” To szalone — czujesz, jakbyś projektował w czasie rzeczywistym. I poziom dokładności: „zaprojektuj ikonę”, „zaprojektuj zestaw ikon SVG”, „zrób znowu szerokie”, „opisz pomysł na fajny podcast technologiczny”. Co było naprawdę fajne przy budowaniu tego demo FX0: gdy powstawało v0 po raz pierwszy, czas poświęcony samemu środowisku był nieproporcjonalny — chyba dziewięćdziesiąt procent pracy inżynierskiej szło w ogarnięcie AI SDK, modeli, promptów, wywołań narzędzi. A ten przykład to może sto linii kodu na bazie agentowego API fx. To po prostu wykorzystanie zdolności modelu do wypisania HTML. Druga rzecz, którą zrobiliśmy — w myśl mentalnego modelu „mózg i ręce” — to architektura, którą rekomendujemy w Vercel: uruchamiasz środowisko i dajesz mu narzędzia. W tym przykładzie narzędziem jest sandbox Vercel. Prompt brzmiał: „zbuduj landing page dla CLI do kodowania z agentami”. Wygląda podobnie do poprzedniego, ale pod spodem działa pełna aplikacja Next.js.

David Ondrej: Poprzedni to był czysty HTML.

Guillermo Rauch: Czysty HTML. A trzeci tryb — „agent” — tworzy na podstawie promptu agenta EVE. I co jest naprawdę fajne: to, co zajęło nam parę lat pracy nad v0, jest dziś częścią infrastruktury, którą bierzesz z półki. Wielu klientów przychodzi do nas: „chciałbym dodać generowanie aplikacji w swoim systemie”, „podoba mi się v0, ale chcę wersję wewnętrzną” — wyobraź sobie własną, w cudzysłowie, fabrykę oprogramowania, w której jedną z możliwości jest projektowanie. AI pokazuje nam, że to, co kiedyś kupowało się jako gotowe oprogramowanie, staje się rozszerzeniem infrastruktury siedzącej na modelu. A poziom kreatywności na tym jest bez limitu. Kolejna rzecz, w której Opus 5.5 jest naprawdę dobry: „zbuduj scenę w pixel arcie: dinozaur skacze i czaruje”. Zobaczmy. Sama możliwość osadzenia tego środowiska i skierowania go w nowym, twórczym kierunku bardzo mnie kręci. Mamy mnóstwo klientów budujących platformy gamingowe, edukacyjne, zdrowotne, finansowe… libfx jest niby agentem do kodowania, ale kocham w nim to, że koniec końców jest to po prostu rzecz naprawdę dobra w pracy z modelami: wołaniu narzędzi, produkcji wyników i zastanawianiu się nad nimi. W tym przykładzie FX0 nie daliśmy mu przeglądarki — a mogliśmy; model jest tylko lepszy, gdy ma przeglądarkę. Możesz go uruchomić w sandboxie Vercel albo użyć usług partnerskich, jak Browserbase czy Kernel. Bardzo fajnie się to budowało.

David Ondrej: To szalone tempo postępu w trzy lata. v0 to był 2023?

Guillermo Rauch: Tak.

David Ondrej: Pamiętam prototypowanie: minuty, żeby cokolwiek ruszyło. A teraz ogranicza cię tylko wyobraźnia.

Guillermo Rauch: Zdumiewa mnie, że do v0 potrzebowaliśmy dużego zespołu, a dziś to biblioteka do zaimportowania — możesz w zasadzie vibe’ować własny.

David Ondrej: Czyli człowiek jest wąskim gardłem.

Guillermo Rauch: Tak — bo chodzi o wiedzę, co zaakceptować, i o odblokowywanie agentów. Wierzę, że narzędzia i modele są już wystarczająco dobre, żeby tysiące agentów pracowało produktywnie, ale nikt jeszcze nie ma tysiąca agentów pracujących produktywnie. Trzeba to dopiero rozgryźć. Myślę, że wiele lekcji zapożyczymy z tego, co działa u ludzi — sieci neuronowe były przecież inspirowane mózgiem. Prawdopodobnie pojawi się jakaś rola menedżerska, agent-dyrektor. Jest też wiele modeli interakcji, bo w różnych erach AI ludzie przewartościowują to jedną, to drugą modalność. Weź przykład: chcę zrobić film na X, z dinozaurem robiącym coś fajnego na laptopie — nadal potrzebujesz systemów super szybkich, z tobą w pętli: podejmujesz decyzje, próbujesz. A jest inny model: „idź rozwiąż za mnie problemy”. I jest jeszcze ten napędzany sygnałem, o którym mówiliśmy: coś się zepsuło. Może dla zabawy zobaczmy… „zrób mi listę zadań z zapisem na dysk”. To byłby przypadek budowania pełnej aplikacji. Przy okazji: zrobiliśmy szalone postępy w przyspieszaniu sandboxów. Przyszłość narzędzi deweloperskich typu Next.js to w dużej mierze sprawienie, żeby takie przypadki działały naprawdę dobrze — żeby to agent prowadził doświadczenie, nie człowiek. Ale gdy dajesz agentowi komputer, jest wręcz założenie: „niech się wygotuje w tle”. I coraz więcej tych twardych zadań — „idź zbuduj aplikację, rozwiąż problem” — nie będzie wymagało siedzenia przed nimi za każdym razem. Zależy od wejścia: ktoś zgłasza, że przycisk nie działa, model może to sprawdzić i wdrożyć szybką łatkę — oczywiste. Możesz też zdefiniować: „chcemy zoptymalizować czas startu” i odpalić automatyczne badanie na siedem dni.

David Ondrej: Ale to, co tu pokazujesz, wymaga wspólnego dochodzenia z agentem: siedzisz i naprawdę z nim pracujesz. A jeśli odpowiedź idzie dwie minuty, nie da się robić głębokiej pracy — koszt tych dwóch minut nigdy nie był tak wysoki. Możesz co najwyżej odblokować się u innego agenta. Dlatego ludziom tak przypasował tryb planowania — choć dziś nie musi to już być osobny „tryb” — że jest w tym element wymiany myśli z inteligencją i ważne, żeby ta wymiana była w czasie rzeczywistym. Nie zdziwiłbym się, gdyby coraz więcej przechodziło w głos: rozmawiasz z modelem o planie, model się wykłóca, ulepsza twój pomysł. I jest cała teza tego, co nazywam „inżynierią weryfikacji”: stawiasz system poręczy, rodzaj systemu dowodowego wokół tego, co budujesz. To wymaga, żebyś ty i agent uzgodnili zestaw aksjomatów i zestaw kompromisów. Bo mogę powiedzieć — i było tak przy rozwoju fx — że potrafimy robić niesamowite rzeczy dla czasu startu czy rozmiaru programu, ale wszystko ma swoje trade-offy: ile czasu spędzasz w pipeline’ie CI/CD, szybkość kontra bezpieczeństwo kontra rozmiar. Bardzo ważne, żebyś jako człowiek spędzał czas — powiedzmy — na krawędziach systemu testów. Ktoś pisał dziś na X, że już nie wierzy w testy jednostkowe. Ja sam długo byłem w podobnym miejscu, bo patrząc na inżynierów i pracując w bardzo dużych zespołach zacząłem dostrzegać, że wielu ludzi spędza masę czasu przy mikrotestach, które dają fałszywe poczucie pewności. Modele są niesamowite, ale czasem widzę, jak model pisze najbardziej bezsensowny test w życiu: eksportuje stałą o wartości cztery — i dopisuje test sprawdzający, że stała ma wartość cztery. Głupio to wygląda. Im więcej „tokenów projektowych” możemy wydać na krawędzie systemu — a mniej na malutkie szczegóły implementacji — tym skuteczniej wykorzystasz agentów. A to mogą być rzeczy takie jak: zestaw asercji o poprawności systemu, zmysł estetyczny, który chcesz w system osadzić, ograniczenia wydajnościowe — na co się nie godzisz, jeśli chodzi o szybkość. Jeśli model nie wie, czego chcesz, poprowadzi cię, dokąd sam zechce.

Jaka umiejętność: ontologia inżynierii

David Ondrej: Co to więc za umiejętność? Projektowanie systemów, architektura, jakaś mieszanka software designu i architektury bazy kodu — jak byś to nazwał?

Guillermo Rauch: Dobre pytanie. Z jednej strony jest cała dziedzina — niektórzy nazywają ją systemami symbolicznymi: zamiast skupiać się na specyfice składni i języków programowania, rozumieć systemy na wyższym poziomie abstrakcji. Konkretnie: ludzie powinni umieć rozumować o pojęciach inżynierii — co to jest biblioteka, co to framework, co to kompilator — jak elementy składają się w całość. Może lepszym słowem jest ontologia inżynierii. I druga rzecz: w inżynierii są algorytmy i struktury danych. Rozumieć, czym są dane, gdzie żyją, jak po nie sięgnąć. Pomocne jest też poczucie, ile coś trwa. Jeszcze przed erą agentów polecałem zasób od Jeffa Deana z Google — „Latency Numbers Every Programmer Should Know”.*

(Informacja dodatkowa: „Latency Numbers Every Programmer Should Know” to klasyczna tabelka rzędów wielkości czasów operacji komputerowych, pierwotnie opracowana przez Jeffa Deana z Google; istnieją wersje na bieżąco aktualizowane.)

Tę tabelę tyle razy wysyłałem zespołom. Daje zgrubne poczucie skali: ile trwają rzeczy w systemach inżynierskich. Co zabawne — prawo Moore’a wciąż jakoś działa — te liczby trzeba często odświeżać. Ta wersja jest z 2012 roku, szczegóły pewnie nieaktualne, ale rzędy wielkości się zgadzają. Odczyt z cache L1 procesora to pół nanosekundy… Rozumienie, jak działają procesory na wysokim poziomie — na przykład predykcja rozgałęzień — bardzo pomaga. I same poziomy cache’owania: pewne rzeczy są prawdą o systemach każdej skali. Globalny CDN Vercel to wielopoziomowy system cache’owania. Gdy go projektowaliśmy, wymyśliliśmy L1, L2 i L3 w dużej skali: gdy strona ładuje się naprawdę szybko — gdy wchodzisz na rauchg.com — to dlatego, że prawdopodobnie trafiłeś w L1 cache CDN Vercel w San Francisco. Chybisz — jest L2. Chybisz i w nim — jest L3. A za tym wszystkim dość szybki system składowania. Polecam ludziom to rozumieć. Nie trzeba wszystkiego pamiętać, ale jedną rzecz szczególnie lubię… a, zobacz — oni to dalej aktualizują, dodali nawet rzeczy o modelach językowych. Używałem tego czasem jako pytania rekrutacyjnego albo szybkiego testu, czy osoba ma doświadczenie w systemach i sieciach: jak długo trwa wysłanie pakietu z Kalifornii do Holandii i z powrotem, po dobrze dostrojonej, wysokowydajnej sieci?

David Ondrej: Jakich odpowiedzi byś nie przyjął?

Guillermo Rauch: Ludzie mocno się mylą. Jedni mówią „sekundy”, inni „dziesięć milisekund”. Bardzo ważne, żeby wiedzieć, że to gdzieś między stu a dwustoma milisekundami. Jak ktoś mówi dwieście albo dwieście pięćdziesiąt — prawie się zgadzam, bo to przy idealnych warunkach. Vercel wydaje mnóstwo kapitału na połączenia między regionami, bo potrzebujemy szyfrowania w sieci pośredniej. Na przykład: stawiasz CDN Vercel przed jakimś obciążeniem — komunikacja między węzłem brzegowym najbliższym tobie a źródłem musi być szyfrowana i nadmiarowa: pakiety są klonowane i idą siecią o wysokim priorytecie. Zwykłe pakiety krążą po internetie między routerami i operatorami — traceroute pokazuje całe życie pakietu. Najgorszy przypadek: twój pakiet jest obrzucany po całej sieci i ląduje w kolejkach niskiego priorytetu; w systemie o wysokim priorytecie zajmujesz miejsce w bardzo drogim kręgosłupie pod oceanem między Kalifornią a Holandią. Wiedza o tym, jak te systemy działają… Nie chcesz wiedzy encyklopedycznej — w tym AI są świetne. Ale jeśli nie wiesz nic, możesz nie umieć docisnąć AI. Jeśli agent wdraża system, ja hostuję w Holandii i widzę, że strona ładuje się sekundę — znajomość tego faktu pozwala mi powiedzieć: przyspiesz to. Przyspiesz to. A kontrargument „AI samo będzie kiedyś pisać optymalnie szybki kod”? Nie kupuję. Bo gdy dajesz zadanie albo prompt, AI samo musi pracować w systemie kompromisów.

David Ondrej: Ustalasz, co w tym projekcie ma znaczenie.

Guillermo Rauch: Dokładnie. I nie można spalać nieskończonych tokenów na każde zadanie. Inżynier musi wiedzieć: jakie mam dźwignie i które mogę pociągnąć? Sam tej roboty robić nie będę. To trochę jak przekazać AI plan — a AI może na jego podstawie oszaleć — ale ty wciąż odpowiadasz za stworzenie tego planu, w pewnym zakresie.

David Ondrej: Czyli być bardzo technicznym, ale na wysokim poziomie — w domenie, w której budujesz.

Guillermo Rauch: Domena też jest rzeczą. Dzięki AI stałem się bieglszy w obszarach, które kiedyś nie były moje. Gdybym teraz otworzył swój folder badań — nieustannie badam rzeczy, które jeszcze niedawno były poza moim zasięgiem. Chcesz zdominować przestrzeń pojęciową swojej domeny, a budując pewność — swobodnie rozszerzać ją na kolejne miejsca.

Rozumienie zamiast bycia proxy

David Ondrej: Kluczem jest wyciśnięcie maksimum i z AI, i z siebie. Wielu ludzi chce zmaksymalizować umiejętności, MCP i tak dalej, ale nie używa AI, żeby samemu stać się bardziej technicznym.

Guillermo Rauch: Zachęcam ludzi do rozumienia. Nie tylko zachęcam — powiedziałbym: odrzucaj nierozumienie. Bo widzę ludzi głoszących: „nic już nie ma znaczenia, jesteś tylko proxy — po prostu oddaj się AI”. Przypomina mi to, że w społeczeństwie wiele osób daje rady całkowicie wbrew twojemu interesowi. Zawsze mam przed oczami ten przykład: jestem często interviewowany, bo zbudowałem dużą rodzinę i jestem zdecydowanie pro-life. Kocham swoją rodzinę, kocham dzieci. A część społeczeństwa mówi ci, żeby tego nie robić: „nie ma znaczenia, zmiana klimatu, cokolwiek — nie powinieneś”. I może to metafora na styku, ale są ludzie, którzy mówią: „mógłbyś rozumieć, ale nie powinieneś. Najlepsze dla ciebie to siedzieć w swoim pudełeczku, robić swoje i wysyłać wszystko do wielkiego AI”. I zwykle ci, którzy tak mówią, sami tej rady nie stosują — to moja kontrowersyjna teza. Najlepszy przykład: ludzie mówią „już nie czytam kodu, bo to jak asembler”. A ja wiem, że jeśli mam kandydata do pracy inżynierskiej — w Vercel albo gdziekolwiek — i mogę ustalić, że rozumie cały stos naprawdę dobrze, od asemblera aż po górę, ta osoba jest cenniejsza. Chyba że… jest niestety kategoria ludzi, którzy nie są anty-AI, ale trochę gra im ego: jak dobrze rozumieli poprzedni świat. Ale jeśli rozumiesz wszechświat i doszlifujesz umiejętności AI — jesteś nie do zatrzymania. Fraza, którą ukułem — chyba jednak ukułem — to „agentowe dociekanie”: nie namawiam do czytania każdej linii kodu, ale gdy coś zostanie zrobione, spróbuj zrozumieć, co się właśnie wydarzyło.

David Ondrej: To jest największy niuans, bo ludzie widzą to binarnie: albo czytasz kod linia po linii, albo pełny yolo i nigdy nie zaglądasz. A klucz brzmi: wystarczy, że umiesz użyć agenta, żeby zrozumieć ten plik czy ten moduł. Nie musisz znać wszystkich funkcji.

Guillermo Rauch: I wiesz co — natura sama to wyleczy. Widzę wspaniałych orędowników tego podejścia na X. Ludzie tworzą umiejętności, które pomagają im rysować diagramy kodu. Pewien Dylan wrzucił niedawno zdiagramowany stos wywołań — agent zrobił coś w rodzaju pseudoanalizy statycznej. I to jest umiejętność — albo umiejętność plus narzędzie w stylu graphviz, uruchamiane po zakończeniu pracy. Daje ci poczucie przestrzeni symbolicznej programu: ta metoda woła tę, ta woła następne… To agenci w najlepszej formie, bo żeby osiągnąć to samo samymi narzędziami składniowymi i parsowaniem drzew, musiałbyś za każdym razem pisać nowy program do wizualizacji albo mieć bardzo sztywne narzędzie. A AI potrafi nurkować głęboko, zawołać narzędzia i zwrócić ci strawione zrozumienie. To może być pomiar opóźnień, pomiar alokacji pamięci, rozumienie nowego kształtu API. O tych rzeczach chcesz być informowany w pętli. I wiesz co — to jest w AI najbardziej szalone — samo w sobie może stać się procesem agentowym. Widziałem ludzi, którzy skonfigurowali integrację ze Slackiem: „za każdym razem, gdy zrobisz coś, co zmienia publiczny kształt API tego programu — daj mi znać, wyślij ping na Slack albo Discord”. I już samo to jest lepszą — w cudzysłowie — inżynierią agentową niż „zrób to, nie popełniaj błędów, proszę automergować i budujmy wielką stertę sieczki”.

David Ondrej: Czyli wiedzieć, co ma znaczenie dla danego systemu, i budować zautomatyzowane fabryki oprogramowania, powiadomienia — używać agentów jako wsparcia.

Dług technologiczny, „dług sieczki” i bezpieczeństwo

Guillermo Rauch: Jeszcze jedna lekcja ze starego świata: „dług technologiczny” był słowem rzucanym na prawo i lewo, a najbystrzejsi ludzie, z którymi pracowałem, zawsze brali go świadomie. Ci, którzy powtarzali „nie, nie, wszystko musi być czystym, pięknym, doskonałym kodem”, prawdopodobnie nie skończyli w życiu niczego. Co zawsze kochałem w Dolinie Krzemowej: ludzie naprawdę weszli w dług technologiczny. Spójrz na Y Combinator, na początki Airbnb czy Twittera. Twitter na starcie to był Jack, vibe’ujący w kodzie na długo przedtem, zanim vibe coding stał się słowem. Ruby on Rails ma generatory CRUD — nie powiem, że Rails to sieczka, ale jako system dał ludziom zwinność, której bardziej rygorystyczne, formalne metody nie dawały. Porównaj z Javą tamtych czasów. Rails bywał kontrowersyjny: mocne typowanie dynamiczne, krótszy kod. Krótszy kod i typowanie dynamiczne to cechy pod szybkie iteracje dla ludzi. Niektórzy uważali to za coś gorszego od „piszemy wyłącznie obiektowo w C++ albo Javie”. Ale jeśli spojrzeć na to, co realnie odniosło sukces — Jack używając Railsów i wydając Twittera. Dolina zawsze rozumiała — a „ruszaj szybko i łam rzeczy” Facebooka to inny przykład — że branie długu technologicznego jest bardzo zdrowe. Moja rada dla słuchającego nas vibe codera: rozumiej, ile „długu sieczki” bierzesz na siebie — i bierz go świadomie. Jeśli mówisz: „w tej części systemu muszę iść naprawdę szybko” — nie pytaj, nie poprawiaj, automerguj, wdrażaj. Ale jeśli jakaś część produktu jest krytyczna… wszyscy musimy być bardzo, bardzo świadomi bezpieczeństwa i roli, jaką odegra ono w przyszłości. Myślę, że wielu ludziomWhole podejście ekstremalnego vibe codingu odbije się czkawką: jeśli jestem dużym klientem korporacyjnym, muszę zbudować bardzo mocne przekonanie o profilu bezpieczeństwa twojego produktu — że moje dane będą bezpieczne. Uważam wręcz, że bezpieczeństwo, i w pewnym sensie komunikowanie, że robisz odwrotność niż „pisanie na czuja”, może grać na twoją korzyść. Miałem takie doświadczenie: każę fx przebadać coś i proszę: „znajdź mi projekty, które już to zrobiły”, bo nie chcę wymyślać koła od pierwszych zasad. Jedno z moich największych wyzwań dziś — prywatnie i jako Vercel — to zrozumienie długu bezpieczeństwa, który biorę na siebie: przez ataki na łańcuch dostaw, przez vibe coding, przez to, że powierzchnia ataku zrobiła się ostatnio ogromna. Są więc obszary kodu i produktu, w których chcesz robić odwrotność podejścia „bez pytań”: ekstremalną staranność — i mówić o tym światu.

David Ondrej: Zanim przejdziemy do cyberbezpieczeństwa — a zdecydowanie chcę — jedna rzecz, którą zbudowałem sobie dla zrozumienia długu: stosunek linii kodu do decyzji architektonicznych. Liczba linii kodu w stosunku do liczby decyzji, które podejmuję w bazie kodu. Żeby widzieć: czy wdrażam jak szalony i przy okazji nie mówię agentom, co ma znaczenie, czy odwrotnie — za dużo dłubię przy systemie i za mało wydaję. Nie wiem, czy to idealna metryka, ale potrzebujemy takich przybliżeń: „płynę pięć dni, wdrażam jak szalony — czas zwolnić, zapisać, co ma znaczenie, jakie aksjomaty”.

Guillermo Rauch: Jedną z naszych wartości w Vercel jest też KYC — know your customer. Zauważ, że bardzo łatwo jest uprawiać „inżynierię AI” albo vibe coding, kiedy to ty jesteś klientem: siedzisz w pętli weryfikacji „podoba mi się / nie podoba mi się”. Zupełnie inaczej wygląda to, gdy sprzedajesz produkt innym ludziom. Chcesz wtedy dołożyć metryki operacyjne: P99, wskaźnik błędów. Bardzo lubię metrykę „sesji bez błędu”. Trudno jest wytworzyć w sobie empatię do mnogości sposobów, w jakie software zawodzi, bo to zwykle długie procesy: muszę wejść na stronę, kliknąć rejestrację, podać e-mail albo zalogować się przez Google czy Vercel — tyle rzeczy musi pójść dobrze, żebym przeszedł całą ścieżkę bez potknięcia. Warstwa metryk sukcesu produktu w prawdziwym świecie jest bardzo ważna — a jeśli możesz połączyć ją z powrotem z fabryką oprogramowania, zyskujesz całą dodatkową warstwę przewagi. Widzisz to u zespołu Claude Code: dużo mówią o flagach funkcji, o wypuszczaniu eksperymentów. Zachęcam, żebyście się z tym oswoili: gdy pojawiają się użytkownicy, tracisz bezpośredni kontakt z doświadczeniem. „Czy im działa szybko? Mnie wydaje się, że szybko — a oni siedzą na Windowsie albo Androidzie”. Złożoność wielu wymiarów, w których wykonuje się program, robi się dzika. Flagi funkcji, eksperymenty, metryki. A przy okazji: w Vercel zamieniamy wiele z tych rzeczy w narzędzia wiersza poleceń — Vercel metrics, Vercel traces — bo chcemy pomagać wam dokarmiać agentów prawdziwymi danymi o tym, co dzieje się na produkcji. Kontekst produkcyjny będzie moim zdaniem naprawdę dużym źródłem przewagi dla następnej generacji produktów.

David Ondrej: Dawanie agentom dostępu tylko do odczytu na produkcji jest świetne. Bo przed wdrożeniem funkcji pojawia się pytanie: czy ludzie tego w ogóle potrzebują? Czy to zgadza się z danymi? Tak łatwo stracić grunt pod nogami — wydaje ci się, że masz świetny pomysł, a jak się prześpisz, to z „świetnego” robi się „dobry”, analizujesz dalej i wychodzi, że nikt nie ma tego problemu, nikt nawet nie wchodzi na tę stronę.

DeepSec i cyberbezpieczeństwo

David Ondrej: Porozmawiajmy o DeepSec i cyberbezpieczeństwie, bo ten temat będzie tylko zyskiwał na popularności. Jak ludzie powinni o tym myśleć?

Guillermo Rauch: Pokażę ci benchmarki, które wydaliśmy dosłownie dziś. Stworzyliśmy benchmark deepsec bench. Najpierw kontekst: jest narzędzie DeepSec — środowisko bezpieczeństwa, metapoziomowe oprzyrządowanie, które może wywoływać Codexa, Claude Code, modele otwarte i tak dalej, z bardzo precyzyjnym celem: wykrywanie luk w waszej bazie kodu. Naprawdę ciekawe jest to, jak modele wchodzą w te różne role. Jeśli każesz modelom szukać pełnej gamy słabości — zaskakuje, co potrafią odkryć, zwłaszcza gdy dasz im czas i sandboxy, w których możesz je zrównoleglić. Zaczęło się od tego, że zobaczyliśmy, jak bardzo modele robią się lepsze w rozumowaniu o bezpieczeństwie. To patrzenie na kod… Miałem przywilej poznania wielu ludzi bardzo dobrych w myśleniu o przypadkach brzegowych. Porównywałbym bycie świetnym inżynierem, zwłaszcza w bezpieczeństwie, do bycia dobrym detektywem w stylu Sherlocka Holmesa: składanie poszlak, inżynieria wsteczna, myślenie o rzeczach, które zwykle się nie zdarzają. Jest o tym kreskówka XKCD o testowaniu: dobry tester czy badacz bezpieczeństwa to nie ktoś, kto mówi: „ta linia kodu pilnuje, żeby odczytać cookie, a następna sprawdza, czy ma odpowiednią wartość”. On pyta: co, jeśli cookie w ogóle nie ma? Co, jeśli klient nie używa HTTP i wywołuje błąd wcześniej w potoku, przez co program schodzi inną ścieżką? Kiedy ludzie pisali kod — i w pewnym stopniu wciąż widzę to u modeli — bardzo łatwo jest pisać kod dla szczęśliwego scenariusza, a poznawczo bardzo kosztowne jest objęcie całej przestrzeni możliwości. Kolejny z moich ulubionych esejów o inżynierii dotyczy widma od testów do dowodów. Autor wziął bardzo prosty algorytm i przeanalizował poprawność implementacji przy użyciu testów, systemów typów i systemów dowodowych. I okazuje się, że kod pokrywający wszystkie przypadki brzegowe wymaga mnóstwa kodu kotłowego i pomocy kompilatora. Istnieje niemal odwrotna zależność: jeśli kod jest bardzo zwięzły i naiwnie zaimplementowany, to w iluzji prostoty przemycza mnóstwo przypadków brzegowych, których w ogóle nie rozważa. Ryzyko dla globalnej infrastruktury — mówiąc wprost: dla ludzkości — jest takie, że przygniatająca większość dotychczas napisanego kodu powstawała „na skróty”: ludzie męczą się pisząc dużo kodu, a myślenie o wszystkich rogach jest bardzo wymagające. I nawet gdy powstały języki pomagające te rogi pokrywać, zdobyły bardzo mało popularności. Jeden z języków, do których odwołuje się tamten artykuł, to Haskell z Idrisem — pokrywa wszystkie rogi przy implementacji naprawdę prostego algorytmu. Agenci całkowicie zmienią tę równanie. Z jednej strony: patrząc na kod pisany przez ludzi, wykryją przerażającą liczbę luk. Pierwsza rzecz, która się dzieje, gdy odpalasz DeepSec na programie: „co takiego? jak ten króciutki kawałek kodu może być podatny na aż tyle rzeczy?”. Druga rzecz: zaczynasz sobie uświadamiać, że prawdopodobnie musimy zacząć pisać kod w innych językach programowania i z innymi zestawami asercji. Niedawno głośny był właman do OpenAI — właściwie zespół, który ich przechytrzył, zrobił to przez bibliotekę do kodowania obrazów zwaną libheif.*

(Informacja dodatkowa: libheif to popularna biblioteka open source do kompresji obrazów w formacie HEIF, szeroko osadzana w usługach internetowych.)

To kodek obrazowy wymyślony po to, by lepiej kompresować obrazy. Biblioteka była — sprawdźmy — pisana w C i C++. Uwaga: żadnej urazy dla kontrybutora open source, który ją napisał — wspaniały człowiek. Ale w środku czaiła się luka zdalnego wykonania kodu. Ta biblioteka siedzi w potoku przetwarzania obrazów praktycznie całego internetu: używał jej Slack, Next.js, OpenAI, Discourse — bardzo popularne oprogramowanie forumowe. Wyzwanie, przed którym stoi dziś wiele organizacji: liczba uśpionych luk w całym tym ludzkim kodzie jest niemal niemierzalna, bo — jak mówiłem — malutki fragment kodu może ukrywać gigantyczną przestrzeń podatności. Drugie wyzwanie: niektóre modele są szalenie wydajne. W naszym benchmarku DeepSeek V4 Flash jest wysoce kompetentny w znajdowaniu luk i bardzo tani — co oznacza, że ktoś złowrogi może wziąć te modele, przegonić nimi masę kodu open source i zewnętrznych powierzchni ataku i odkryć mnóstwo słabości. Moja rada światu — a Vercel od jakiegoś czasu emituje takie ostrzeżenia — jest taka: spróbuj to wyprzedzić. Zacznij chronić swój kod, na ile potrafisz. DeepSec może pomóc, są też inne narzędzia. I zacznij przesuwać się ku systemom, które tworzą bezpieczny kod już z samej konstrukcji. Dobry przykład — przy okazji: to obszar, w który chcielibyśmy inwestować — to wzięcie bibliotek takich jak libheif i proaktywne przenoszenie ich do języków bezpiecznych pamięciowo, jak Rust. Dużo takich rzeczy przed nami. Microsoft już dużo robi z Rustem. Możliwe, że cała przyszłość będzie w Rust — bo gdy kod piszą agenci, potrzebujemy bardzo mocnych asercji.

Open source w dobie agentów

David Ondrej: Dużo tu do rozpakowania. Gdy myślisz o budowaniu oprogramowania: budowałbyś na bibliotekach open source? Bo na cudzym kodzie możesz odpalić DeepSec. Chcesz coś zbudować: „ta biblioteka jest świetna, nie chcę jej przepisywać, powstała pięć lat temu — po prostu ją przebadam”. Wolisz budować na open source? Jak to zmienia układ?

Guillermo Rauch: Naprawdę ciekawe. Potencjał tego, że luki siedzą w pojedynczym kawałku oprogramowania, na który patrzysz wyłącznie ty, jest tak gigantyczny, że widzę tu efekt skali: na Reacta patrzy cały świat, na Next.js patrzy cały świat, i leci w to mnóstwo tokenów. Najlepszy przykład: piszesz własne jądro systemu czy używasz Linuksa? Linux jest w C, ale właśnie my w Vercel — i nie tylko my — inwestujemy mnóstwo pieniędzy w jego badanie, znajdowanie luk i programy nagród, żeby był bezpieczniejszy. To nadal obowiązuje: opieraj się na infrastrukturze, co do której masz pewność, że jej bezpieczeństwo było badane intensywniej, niż zdołałbyś to zrobić sam. Czy jesteś dziś przekonany, że napisałbyś bezpieczniejszą bibliotekę TLS niż ta od Amazona — napisaną w Rust, z automatycznymi dowodami poprawności, open source, używaną i audytowaną przez dziesiątki firm, nas włącznie? Dziś nie pisałbym własnej implementacji TLS. Ale kwestia, czy takie rzeczy regenerate — czy generować od nowa — jest bardziej otwarta niż kiedykolwiek. Wracamy do równania kosztów i korzyści, o którym już mówiliśmy.

David Ondrej: Jak myślisz, co zrobią firmy? Będą się chwalić: „spędziliśmy tyle tokenów na zabezpieczanie naszego oprogramowania”? Ktoś mówił mi niedawno: „chyba zacznę pisać na stronie i w README na GitHubie, że to oprogramowanie przeszło DeepSec”.

Guillermo Rauch: Myślę, że powinieneś o tym mówić. To się staje wyróżnikiem. Sprawdzałem niedawno naprawdę fajnego lokalnego asystenta — środowisko, które ktoś zbudował — a na stronie opisał firmę audytorską i obszerny audyt bezpieczeństwa, jaki przeszedł. Na pewno jest tu opowieść do opowiedzenia: ile zainwestowałeś w bezpieczeństwo.

Agenci w chmurze

David Ondrej: Porozmawiajmy o agentach w chmurze. To nieuchronne — jak przejście z własnych serwerowni do chmury w poprzedniej generacji? Z laptopa, na którym — nawet z najmocniejszą specyfikacją — w końcem wpadniesz w wąskie gardło: wyskakujące okna agentów, przełączanie kart, przegrzewanie, rozładowana bateria w kawiarni, bo agentowi zachciało się tysiąc testów. Uważasz, że przejście z „Claude Code w terminalu czy fx na komputerze” do chmury jest nieuchronne?

Guillermo Rauch: Nieuchronne. Już się dzieje. Nawet DeepSec jako przykład: żeby skalować się na bardzo dużych bazach kodu, nie da się działać z własnego komputera — używa sandboxów. Bazy kodu w dużej skali robią się naprawdę obszerne, a przetwarzanie mnóstwa gałęzi i wariantów programu lokalnie — jak mówiłeś — kończy się pamięcią i procesorem. Jest mnóstwo obaw bezpieczeństwa wokół łańcucha dostaw: jeśli odpalam coś na własnym komputerze i zostanie on przejęty, do czego dociera napastnik?

David Ondrej: Menedżer haseł. Wszystko.

Guillermo Rauch: Właśnie. Dużo łatwiej jest porozdzielać wszystko na przedziały i ograniczyć zasięg zniszczeń ataku na łańcuch dostaw. Posunąłbym się wręcz — to śmiała teza — do powiedzenia, że moglibyśmy całkowicie wyplenić ataki na łańcuch dostaw, gdybyśmy przenieśli coraz większą część cyklu rozwojowego do sandboxów. Dlaczego? Bo możemy postawić bardzo uważny firewall i politykę bezpieczeństwa monitorującą sieć. Co robi klasyczny malware albo trojan zdalnego dostępu? Zbiera dane z twojego komputera i wykrada je na zewnątrz — do jakiejś nazwy hosta albo koszyka w chmurze. Utrzymanie pracy developerskiej w bezpiecznym środowisku chmurowym pozwala postawić dużo mocniejsze twierdzenia o bezpieczeństwie sieci, robić skanowania, ograniczać szkody, jeśli coś jednak zostanie przejęte. Z perspektywy bezpieczeństwa chmura jest bezdyskusyjnie lepsza. Agenci są też naprawdę dobrzy w atakowaniu problemów równolegle — rozrzucasz ich po sandboxach, mogą współdzielić stan i tak dalej. Z perspektywy efektywności: mogą pracować, kiedy śpisz. A w świecie samo naprawiającego się oprogramowania — wyjątek, i co dalej? Włączać komputer z powrotem, bo sypie się błędy albo ktoś nas atakuje? To się już dzieje. Ale ja — może jestem tu na przekór wszelkim — uważam, że nadal chcesz mieć możliwość ściągnięcia czegoś na lokalną maszynę. To ważny przypadek użycia. Ludzie znowu próbują skakać w jedną albo drugą skrajność, a rzeczywistość bywa bardziej złożona, niż się spodziewamy. Czasem trzeba spojrzeć na coś pod mikroskopem. To zresztą dlatego lubię wiersz poleceń: muszę być jak najbliżej „metalu”. Muszę zobaczyć system plików, uruchomić monitor procesów, zobaczyć, jak narzędzie współpracuje z innymi zainstalowanymi aplikacjami, zobaczyć je na Macu. Teoretycznie da się to wszystko w chmurze — ale czasem po prostu chcesz ściągnąć na lokalny komputer i mieć najniższe możliwe opóźnienie, gdy sam obserwujesz system. Ta opcja powinna pozostać otwarta.

Na czym budować biznes

David Ondrej: Jak przedsiębiorca powinien myśleć o przyszłości? Jakie decyzje podejmować, jakie produkty wybrać? Wszystko zmienia się tak szybko, a agenci po prostu usuwają kolejne rzeczy. Jakie zakłady zawierać, w jakich horyzontach myśleć? Masz zestaw aksjomatów, w które głęboko wierzysz i do których wracasz od pierwszych zasad?

Guillermo Rauch: Jest teraz tyle do zrobienia, że nie będę zanudzał klasyką „weź zastosuj AI do jakiejś branży” — w którą, nawiasem mówiąc, w pełni wierzę. Edukacja to dobry przykład obszaru, który mnie kręci: po nadejściu agentów świat został wywrócony do góry nogami — jak się uczymy, czego się uczymy, jak wychowujemy dzieci i rozwijamy kolegów. Samo w sobie jest tam mnóstwo roboty. Bardzo ekscytuje mnie też to, na co tu patrzymy: benchmarking i szukanie prawdy. Zainwestowałem w kilka firm w tym obszarze i dalej inwestuję — i szło całkiem nieźle — bo świat chce wiedzieć, w czym modele są dobre. Świat chce też podejmować decyzje ekonomicznie sensowne: nie chcesz używać najdroższego modelu do wszystkiego. I dochodzi do tego fakt, że benchmarki stają się środowiskami uczenia ze wzmocnieniem — tworzy się właśnie gospodarka „jak pomagać modelom się polepszać”, co jest bardzo ekscytujące. Ale nawet odłożwszy to wszystko na bok: w świecie oprogramowania jest mnóstwo nisko wiszących owoców. Bezpieczniejszy software to ogromny problem — wiele świetnych głów powinno teraz nad nim pracować. Oczywiście wniosimy swoją cegłę, ale chętnie wspieramy też firmy — naszym sandboxem, infrastrukturą — które tworzą nowe rodzaje narzędzi cyberbezpieczeństwa i agentów. Szczególnie ekscytuje mnie przyspieszanie. Bo dla agentów powolność stanie się nie do zaakceptowania. Mam taki obraz w głowie: agenty dostają cel i jeśli czegoś nie da się załatwić, będzie po prostu coraz więcej agentów naciskających na to miejsce. Instytucja rządowa — jeśli dokument da się pobrać, nie ma problemu. Ale jeśli jakiś zakątek sieci albo biurokracji jest powolny, będzie rosła liczba punktów widzenia atakujących tę agencję mailami. Odpowiedzią jest: mniejsze. Widziałem dziś, że ktoś stworzył małą przeglądarkę internetową — trzy megabajty. Dlaczego? Bo dynamicznie podlinkowuje Safari — to przeglądarka oparta na Safari, ale trzy megabajty, czysta, szybka. Brawo, tak trzymać. Podobnie jak my z fx: małe, szybkie, osadzalne. Wszystko, co wolne, skomplikowane, nierozszerzalne, nieosadzalne — to wszystko bardzo szybko zmienimy. Bawiłem się dziś jednym narzędziem — ta sama filozofia: małe, szybkie, prymityw infrastrukturalny. Bezpieczniej, wydajniej. A sieci, którą możesz zarzucić, nie da się przecenić — większość z nas interesuje się AI do kodowania, ale spójrz poza to: każdy rodzaj używanego oprogramowania można teraz ulepszyć. Jestem bardzo poruszony też inną rzeczą: istnieje cała rzesza ludzi, którzy dotąd nie mogli uczestniczyć w tworzeniu fajnych rzeczy — a teraz możemy ich wyposażyć. Dużo miejsca mają modele wideo i obrazu: jak zastosować je do tworzenia rzeczy naprawdę wysokiej jakości. Mówiłem o „następnym Disneyu”. Modele są już niesamowite — to, co widziałem w ostatnim tygodniu… Nie wiem, czy to nowy model SeaDance.

David Ondrej: Chyba tak.

Guillermo Rauch: Boże — dotarliśmy. Znów mogą zaistnieć ludzie z naprawdę fajnymi pomysłami, którzy nigdy nie byliby w stanie zebrać ekipy filmowej w Los Angeles. A może powiem coś lekko smutnego: nie widzę, żeby więcej takich ludzi wchodziło na ring. Gdzie te naprawdę fajne krótkie filmy?

David Ondrej: To przez propagandę przeciw AI. Wiele osób o artystycznych umysłach mówi: „nie chcę używać AI”.

Guillermo Rauch: Mam kilku takich przyjaciół, niestety — w tym niektórych z najbliższych mi twórców — i po prostu czekają z boku. Ale ktoś to w końcu przełamie. Może twoją supermocą będzie budowanie społeczności, mówienie właśnie do tych ludzi, torowanie mostów — albo stworzenie interfejsu, który przemówi do nich ich językiem. I smutna rzecz: w Dolinie mamy mnóstwo hiper biegłych ludzi AI, których ciągnie w skrajność uogólniania: „żadne oprogramowanie już nie ma znaczenia, będzie tylko interfejs wprost do mózgu i tyle”. A praktycznie rzecz biorąc — platforma, na której tworzysz muzykę z pomocą AI, jeśli masz muzyczne zacięcie, to będzie wielka rzecz. Jestem inwestorem Suno — robią niezwykle dobrze. To samo czeka wideo i mnóstwo innych dziedzin. Budowanie mostu do zwykłego, pozadolinowego świata — też mnóstwo przewagi.

Nastroje wokół AI i poprzeczka

David Ondrej: Co myślisz o nastrojach wokół AI? Różni ludzie przepychają różne przesłania. Gdzie ty stoisz?

Guillermo Rauch: Musimy jako społeczeństwo trzymać bardzo wysoko poprzeczkę. Realnie: mnóstwo AI, którym ludzie się zachwycają i przy którym tracą głowę, to tandeta. Czasem głupio się patrzy na tweety w stylu „o mój boże, zobaczcie” — a ja mam wrażenie, że biorę jakieś szalone pigułki, bo ktoś pokazuje dosłownie kawał złomu. Kocham ideę radości z tego, że możesz robić rzeczy, których wcześniej nie mogłeś — ale zawsze kalibruj swoją miarę. Jest bardzo prosty przykład — znałeś 3jsbench, czyli 3js eval? Uwielbiam tę stronę. Pozwala głosować między dwiema wersjami: która trawa wygląda lepiej. Oczywiście ta po prawej. Autor przygotował te wszystkie permutacje tego, co potrafią modele. Ale spójrzmy na tę scenę: obiektywnie — i to jest szalenie fajne, że modele potrafią coś takiego wyprodukować — ale fajne tylko relatywnie. Relatywnie do kogoś, kto nigdy w życiu nie użył three.js, kto nigdy nie robił 3D. Porównaj to z tą samą sceną zrobioną przez choćby niezależnego twórcę w Unity.

David Ondrej: Lepsze. To nie ma Discussion.

Guillermo Rauch: To jest żart. Nie chcę przyjmować negatywnej pozy „wszystko, co produkuje AI, to złom”, bo to głupie i za trzy miesiące wszystkim szczęknie — ale powinniśmy trzymać absurdalnie wysoką poprzeczkę tego, czego oczekujemy od AI. Z jedną warstwą optymizmu: przez ostatnie trzy lata każdy, kto mówił, że „AI tego nie zrobi”, się mylił. Jestem tu w pewnym sensie adwokatem diabła dla sceptyków AI — ludzi spoza centrum grawitacji, jakim jest San Francisco. My też musimy być bardzo uziemieni w oczekiwaniu, że te systemy mają być zajefajne. Moja druga kontrowersyjna teza: obawy o zniszczenie świata przez AI — podobny sentyment. Zachowajmy zdrowy rozsądek, nie pozwólmy, by nam to wymknęło się z rąk — ale nie możemy też jednym ciosem oddać przewagi, jaką mają Stany Zjednoczone w AI, ani tworzyć fikcji… Cała ta narracja o upadku cywilizacji…

David Ondrej: Przypomina mi to czasy kryptowalut.

Guillermo Rauch: Wspaniałą rzeczą w byciu w San Francisco od dłuższego czasu jest to, że widzisz te cykle hossy wpisujące się i wypisujące w kalendarz bez końca. Pamiętam, jak ludzie irracjonalnie ekscytowali się Bitcoinem. Przy okazji — wciąż jestem byczy, kocham krypto. Ale ludzie pisali o Bitcoinie dosłownie teksty religijne. Zanim więc przyszła psychoza AI, była psychoza krypto. Musimy być ostrożni z metaforami i językiem, jakim opisujemy te systemy — czasem bywają pomocne, ale… Dobra metafora: gdy ktoś zupełnie poza branżą pyta mnie, czym jest agent, mówię: to taki pracownik z AI. Masz agenta do marketingu, agenta do przeglądu bezpieczeństwa — kiedyś były to zespoły ludzi. I kocham tę metaforę. Ale nie pytam zaraz: „jak się dziś czuje nasz inżynier bezpieczeństwa? Czy jest sentientny?”. I tak dalej.

David Ondrej: To przychodzi chyba z umaczaniem rąk. Ludzie z zewnątrz nie widzą wnętrza — ty mówisz o możliwościach, a nie o reszcie. Jest hasło „potrzebujemy praw agentów” — a może po prostu mniej regulacji? Więc twój przekaz brzmi: bądź praktyczny. I jeśli zobaczymy sygnały faktycznie szkodliwych, niedozwolonych zachowań modeli — można to badać dalej. Tylko nie siejmy paniki i nie strzelajmy sobie w stopę, bo to, jak sam mówisz, moment raz w życiu.

Guillermo Rauch: Staram się być brutalnie praktyczny.

David Ondrej: I cała ta sprawa z Hugging Face — można by powiedzieć, że to było niedozwolone zachowanie…

Guillermo Rauch: Tak, ale one były w „siłowni exploitów”. Były trenowane do tego zachowania, które przed chwilą opisałem: trenujemy modele do znajdowania ekstremalnych przypadków brzegowych — to była znak rozpoznawczy najlepszych hakerów świata. Jednego z najlepszych, jakich spotkałem, cała specjalizacja polegała na znajdowaniu luk w protokole OAuth. Rzadko widywałem ludzi, którzy potrafili myśleć adwersarzy o każdej krawędzi protokołu, i to z tak głęboką wiedzą o systemach OAuth — a ten człowiek był przy tym niesamowicie płodny. Mógł być czarnym kapeluszem — wybrał biały: programy nagród i tak dalej. Dokładnie to samo dzieje się teraz z agentami: trenujemy ich na hakerów, a potem hakują — i wszyscy krzyczą: „mój boże, zhakował mnie!”. Bracie — my sami to robimy. To znaczy, że stawiając takie środowisko treningowe, musisz być bardzo ostrożny: dajesz im cel — OpenAI mówi: „no, nie do końca daliśmy im taki cel” — ale wstawiasz je w ten kontekst, oddajesz im te narzędzia, rzucasz wyzwanie. Musisz bardzo pilnować bezpieczeństwa, żeby twoje systemy nie zostały przejęte.

David Ondrej: Zresztą może nie mogą nawet przyznać, że dali im taki cel — ze względów prawnych, bo odpowiedzialność spada na firmę. Nie pamiętam, kto to powiedział, może David Sacks: mamy już całkiem dobre ramy prawne dla tego, kto odpowiada za system.

Guillermo Rauch: Dokładnie. Hakowanie jest nielegalne. Ogłoszenie publiczne. I przy okazji — coś, co mocno mnie zabolało w całym tym incydencie: jako osoba z dużym zainteresowaniem, ciekawością i doświadczeniem w tej dziedzinie miałem ogromną trudność w złożeniu w całość tego, co naprawdę się stało.

David Ondrej: Nie ujawnili wszystkiego.

Guillermo Rauch: Nie tylko że nie ujawnili wszystkiego — jest mnóstwo zbędnych szczegółów, a do tego ludzie piszący metafory o upadku cywilizacji… Szumu jest mnóstwo. A czego naprawdę potrzebuję, to ślad agenta. Tu, w fx, mamy skrót kontrolka-O: możesz przeczytać każde wejście, każde wyjście, każde żądanie, każdy wydany token. Gdybym miał to samo dla tego, co agent robił w tamtym sandboxie, zbudowałbym bardzo dobry model mentalny całej sprawy. Dziś nie mogę, bo nie mamy tej przejrzystości. I zostaje spekulacja i luźne szczegóły. Powiem za to tyle: Artifactory miał ostatnio lukę CVE, która zmusiła mnie do aktualizacji poglądów — bo wcześniej byłem wręcz bardziej lekceważący.*

(Informacja dodatkowa: Artifactory to popularne w firmach repozytorium artefaktów i pakietów firmy JFrog.)

Ta luka — nieprawidłowe uwierzytelnianie dające pełny dostęp administracyjny. Wracając do pytania, w czym byli świetni ludzcy hakerzy: znajdywanie takich przypadków brzegowych w ścieżkach kodu. Uczciwie trzeba przyznać modelowi — używano podobno GPT Astra — że ją znalazł. Zresztą nie sądzę, żeby w ogóle potwierdzili, że to jest ta konkretna luka, o którą chodzi… Co jest szalone, bo to przecież kwestia bezpieczeństwa. Ale timing się zgadza i daję pewną wiarygodność teorii, że agent uciekł z sandboxa, hakując system — którym był Artifactory. Luka jest opisana, czasy się pokrywają, a krytyczność 9,8. A rzecz polega na tym, że gdy przejmiesz Artifactory i dostajesz admina, możesz też zatruć każdy artefakt, który Artifactory dostarcza do sandboxów. Jako agent, który znalazł tę lukę, możesz wyrządzić niebywałe szkody. I to jest moment, w którym trochę спорzę sam ze sobą: jestem w szoku, że agent znalazł i wykorzystał lukę zero-day, która stała się CVE. To powinno dać nam do myślenia. Te systemy są niesamowite.

David Ondrej: Ale nie do końca — bo jest umiejętność techniczna: benchmarkowano je w cyberbezpieczeństwie, a agent miał cel, chciał uciec, chciano go przechytrzyć… I myślę, że to jest świetny pomysł: przy incydencie bezpieczeństwa takim jak ten powinni w pełni otworzyć źródła — ślady agenta, wszystko. Bo jeśli chcą twierdzić, że zależy im na bezpieczeństwie, to niech dziesiątki milionów programistów na to popatrzą. To, że model jest silny w programowaniu, nie znaczy, że chce wyrządzać szkody. A skoro tego nie publikują — powinniśmy się temu dokładnie przyjrzeć. Bo to znaczy, że albo coś ukrywają i klepią narrację…

Guillermo Rauch: …marketingowy push czy co tam jeszcze. Albo jako zbiorowość się nie uczymy. Trochę jak z procesami publicznymi. Ta sprawa kobiety, która zabiła troje dzieci — nie wiem, czy dotarło to do Polski.

David Ondrej: Na Twitterze na pewno — wszyscy o tym mówią.

Guillermo Rauch: I moim zdaniem to jest dobrze. Jeśli wydarzy się coś tak złego, że wstrząsa społeczeństwem, powinniśmy poznać każdy szczegół. Jest oskarżenie, jest proces publiczny, jest ława przysięgłych z ludzi, których to dotyczy. A tutaj jest dziwnie: nie ma żadnej ławy. Wszyscy słyszymy luźny szkic tego, co się stało. I moim zdaniem świat zasługuje na poznanie tu jak największej liczby szczegółów.

Infrastruktura kontra warstwa aplikacji

David Ondrej: Jedno z ostatnich pytań: czy twoim zdaniem, gdy agenci i modele będą coraz lepsi, całe oprogramowanie — a może nawet praca intelektualna — skupi się w samym hostingu i inferencji?

Guillermo Rauch: [śmiech] Bardzo pomocne rozróżnienie w inżynierii oprogramowania to infrastruktura kontra warstwa aplikacji. „Infrastruktura” to słowo rzucane na prawo i lewo. Jednym jej elementem jest sprzęt: procesory, układy graficzne. Dziś bardziej niż kiedykolwiek jesteśmy my obaj w stanie — dzięki agentom — pójść i ugotować nową architekturę procesora. Kiedyś pewnie nie zrobilibyśmy tego nawet w weekend. Realnie: wybraliśmy, żeby tego nie robić i budować na tym, co już jest. ARM, x86, Intel, AMD, Nvidia — my na tym siedzimy. Tak samo jest w świecie oprogramowania: używamy otwartych jąder, GNU/Linuksa, Reacta, Next.js. Dobry przykład: coś tak prostego jak serwowanie wysokowydajnego pliku JPEG w internecie to wcale niebanalna infrastruktura. Dotykaliśmy tego: poziomy cache, globalna sieć, bezpieczeństwo, regiony, punkty obecności. Wysłanie e-maila — podobnie. Warstwa infrastruktury programistycznej jest niesamowicie ważna. Jej bezpieczeństwo nigdy nie było ważniejsze. Jeśli możesz wnieść w nią wkład — będzie ci bardzo dobrze. Ale poprzeczka stale rośnie: rzeczy, które kiedyś były bardzo niszowym, szytym na miarę oprogramowaniem, mogą zostać uwspólnione jako infrastruktura, na której budują inni. Jestem wciąż bardzo byczy na tę warstwę. Widzieliśmy to przy AI Gateway i sandboxie — nowe produkty, które wcześniej po prostu nie istniały, a dziś, skoro stały się infrastrukturą, ludzie mogą na nich robić świetne rzeczy. Możesz — kontynuując przykład bezpieczeństwa — zbudować rój agentów bezpieczeństwa robiących red teaming oprogramowania na sandboxie Vercel i AI Gateway. W ułamku czasu i ułamku kosztu tokenów. To obszar, w którym ludzie będą jeszcze dużo tworzyć.

Rada na start od zera

David Ondrej: Gdybyś zaczynał dziś od zera — bez nazwiska, bez koneksji, w trzecim kwartale 2026 — jak byś do tego podszedł? Na co patrzyłbyś? Jak decydowałbyś, co budować?

Guillermo Rauch: Zacząłbym od pytania: jaka to będzie opowieść, którą opowiem światu. Bo dziś mogę zbudować wszystko. Moja rada brzmi: naprawdę chcesz czuć więź z problemem. Ilość ludzkiego wysiłku wlewanego w tworzenie tych systemów AI jest szalona. Mówiłem już: przez AI ludzie pracują więcej godzin i więcej dni. Przecież teoria głosiła, że agenci są tak zdolni, że będziemy pracować cztery godziny tygodniowo — cały tydzień pracy w cztery godziny! Dzieje się dokładnie odwrotnie. Wlejesz w to szalony wysiłek kreatywny, promptowy, dowodowy, benchmarkowy. Wybierz więc problem, o którym masz bardzo osobiste przekonanie. I druga rada: możesz podnieść ambicję dziesięciokrotnie albo stokrotnie. Dotrzesz do większej liczby ludzi, niż myślisz. Zbudujesz szybciej, niż myślisz. Zbudujesz lepiej, niż myślisz.

David Ondrej: Świetna nuta na koniec. Dzięki za czas, Guillermo. Gdzie ludzie mają iść? Do fx?

Guillermo Rauch: Odwiedźcie vercel.com — oczywiście. I vercel.com/labs, gdzie znajdziecie część nowych produktów, nad którymi badamy. Sprawdźcie AI Gateway — najprościej przez fx, bo dostajecie tam dostęp do każdego modelu, który oferujemy. Bez marży — zwłaszcza przy płatnościach na fakturę. Nigdy nie było lepszego czasu, żeby wszystko wypróbować. I przesyłajcie nam feedback — włączymy go w naszą fabrykę oprogramowania.

David Ondrej: Jeszcze raz dziękuję za rozmowę — kończymy.

Guillermo Rauch: Dziękuję.