O czym jest ten film
- Skala zużycia tokenów na czołówce branży jest ogromna — powstał nawet program „token billionaire” dla osób wydających miliard tokenów tygodniowo.
- Umiejętność, która się liczy, to nie „promptowanie”, lecz budowanie pętli (loops) — a docelowo pętli, które generują kolejne pętle.
- Dobra pętla agentowa ma trzy elementy: specyfikację celu, weryfikację „skąd wiem, że gotowe” oraz listę tego, czego robić nie wolno.
- Konkretne pętli na start projektu: „przepytaj mnie”, cotygodniowy research/burza mózgów oraz domknięcie cyklu wytwarzania (self-healing app czytający logi produkcyjne).
- Czego nigdy nie oddawać AI: warstwy danych (struktur danych) oraz testów z prawdziwymi użytkownikami — modelom brakuje ludzkiej intuicji produktowej.
- „Gust” i selektywność (mówienie „nie” funkcjom) stają się przewagą, gdy każdy potrafi wygenerować 100 wariantów czegokolwiek.
- Frontier zawsze będzie należał do wielkich laboratoriów, ale większość pracy to nudna rutyna — jest miejsce na wyspecjalizowane „agent laby”.
- Nowe, duże modele (Fable, GPT‑5.6) nagradzają eksplorację — trzeba pytać o rzeczy nieoczywiste, a nie powtarzać stare prompty.
- Rada dla founderów: misja ponad autopromocję, odwaga zamiast bojaźliwości, a przy ścieżce VC — realne wdrażanie kapitału (np. własna infrastruktura), nie cienka warstwa na AWS.
- Na horyzoncie 6–12 miesięcy: bardzo szybka inferencja (tysiące, a nawet dziesiątki tysięcy tokenów/s), która zmieni typ produktów, jakie da się zbudować.
Redakcyjne tłumaczenie
David Ondrej: Jesteś założycielem największej na świecie konferencji dla inżynierów AI i właśnie zorganizowałeś ogromne wydarzenie. Czego najważniejszego nauczyłeś się o tym, jak ludzie budują z agentami?
swyx: Widzę u ludzi mocne „maksowanie tokenów”, ale przy jednoczesnej dużej ostrożności co do zwrotu z inwestycji i efektywności. Mamy program „token billionaire”: jeśli wydajesz miliard tokenów tygodniowo, dostajesz taką efektowną złotą kartę, specjalny lounge i tak dalej. Spodziewaliśmy się może 50 osób na 7000 uczestników, a wyszło koło 300 „tokenowych miliarderów”. To daje pojęcie o skali adopcji.
David Ondrej: Pracujesz też w Cognition, do tego jeszcze wrócimy. Widziałem posty ludzi z Cursora, że robią po 8–10 miliardów tokenów dziennie. Czy to pokrywa się z Twoim doświadczeniem — że ludzie w laboratoriach albo w topowych startupach AI zużywają miliardy tokenów dziennie?
swyx: Osiem to bardzo dużo. Nie wiem, czy poznałem kogoś, kto realnie robi osiem. Ale jasne — jeśli tokeny są darmowe, będziesz próbował ich używać więcej. Uważam, że to dobry zakład na karierę, bo nie ma minusów: firma płaci, a plus jest taki, że jako pierwszy znajdziesz jakieś ciekawe, innowacyjne zastosowanie agentów. Sporo z tego będzie „slopem” (Informacja dodatkowa: „slop” to nadprodukcja bylejakich, niskiej jakości wyników generowanych przez AI), ale ludzie, którzy mają żołądek do znoszenia slopu, są wciąż mocno niedoceniani. Domyślny inżynier jest nastawiony na efektywność i nienawidzi slopu. To wręcz niekonsensusowe, żeby slop zaakceptować i dopiero potem szukać, która jego część jest użyteczna.
David Ondrej: No właśnie — kiedy każdy potrafi wygenerować 100 landing page’y albo 100 projektów jednej funkcji, cała gra przenosi się na osąd. Co musiałeś sam u siebie zmienić, zarządzając większą liczbą agentów i paląc więcej tokenów? U mnie kluczowe było świadome trzymanie się jednego zadania, zamiast puszczać 30 agentów równolegle nad 30 różnymi rzeczami. Jakie nawyki pracy zauważasz u siebie?
swyx: Ja zdecydowanie nie robię tylko jednego zadania. Uważam, że warto mieć w sobie trochę „ADHD”: masz jedno zadanie o wysokiej koncentracji, ale obok wiele zadań w tle, które robią rzeczy powtarzalne, researchowe albo prototypowe. Dużo pracujemy w Slacku, intensywnie korzystamy z Devona — jestem jego klientem i jednocześnie doradcą Cognition, więc widzę obie strony. Gdy znajduję buga, mam tę wygodę, że mam bezpośrednią linię do CTO, żeby to naprawić. Widać też sporo Mox — takiego terminalowego, „multi‑code” narzędzia; oni akurat siedzą w przestrzeni coworkingowej obok nas.
Sam wciąż trochę używam Cursora. Powiedziałbym, że potrzeba IDE naprawdę spadła — do roli edytora plików czy sposobu na przejrzenie kodu. Im szybciej pójdziemy w tę stronę, tym lepiej. Ale lubię czasem wyskoczyć do narzędzi typu Claude Code, a jeśli potrzebuję „computer use”, to najlepszym agentem tego typu na świecie jest Codex.
David Ondrej: Aplikacja Codex jest naprawdę dopracowana, zrobili świetną robotę. Myślisz, że potrzebny jest interfejs graficzny, czy zostaniemy w terminalu?
swyx: Mamy prelegenta, Ido Salomona, który dwukrotnie mówił o „agent crafcie” — używał mocno graficznego interfejsu w stylu symulacji Warcrafta: każdy ork budujący budynek to agent. To zależy od tego, jak działa Twój mózg. Jeśli naprawdę chcesz widzieć wizualizację rzeczy w ruchu, to może bardzo pomagać. Większość ludzi siedzi po prostu w niezależnych wątkach i wtedy nie ma korzyści z wizualizacji — wystarczy płaska lista. Prawda leży gdzieś między płaską listą, tablicą typu kanban (podejście „conductora” albo Devon Desktop) a pełnym interfejsem graficznym jak agent craft. Devon był bardzo wcześnie w Slacku, teraz widzimy, że inni próbują tego samego. Więc realna potrzeba istnieje.
Przy okazji — gratulacje z okazji SWE‑1.7, widziałem ogłoszenie dosłownie godzinę temu. Skoro o tym mowa: myślisz, że będzie więcej modeli spoza wielkiej trójki — OpenAI, Anthropic, Gemini? To jest fine‑tune Kimi K2.7, ale i tak z bardzo imponującymi benchmarkami i prędkościami na Cerebrasie. Przyszłość będzie zdominowana przez OpenAI i Anthropic, czy zobaczymy więcej mniejszych, custom modeli?
swyx: Kimi nie jest znowu takim małym modelem, podobnie jak Composer 3. Frontier zawsze będzie należał do frontierowego laboratorium. Ale większość pracy to nie frontier — to nudna rutyna. Więc jest miejsce. AI jest ogromne, może być wielu zwycięzców. Ja to ujmuję tak: są laboratoria modeli, które muszą zbierać badania GPU i najlepszych badaczy i celują w AGI, oraz „agent laby” — jak Cognition — które biorą się za problemy domenowe, np. kodowanie w firmach, i będą w stanie trenować własne modele pod te zastosowania. Mówię „trenować”, nie „fine‑tune’ować”, bo compute po stronie post‑treningu jest dziś co najmniej porównywalny z pre‑treningiem. Publicznie ujawniona liczba z Composera to czterokrotność compute’u pre‑treningu względem post‑treningu — wtedy to już „continued training”, a nie cienka warstwa.
David Ondrej: Czyli to nie tylko przesunięcie alokacji compute’u — mniej pre‑treningu, więcej wyspecjalizowanych fine‑tune’ów i post‑treningów. Jak ludzie powinni o tym myśleć?
swyx: To złoty wiek dla ludzi od post‑treningu, na pewno. Ciekawe pytanie brzmi: czy to zjawisko przejściowe? Klasa modeli typu Fable i to, co przyjdzie po niej w przyszłym roku — ludzie dopiero rozkręcają te klastry GPU. Prawdopodobnie wciąż jesteśmy dwa–trzy cykle od wyczerpania obecnej generacji projektowania modeli i sprzętu. Dużo jest jeszcze do wzięcia. Nadal będziemy mieli przebiegi modeli o 10–20 bilionach parametrów, które po prostu miażdżą resztę — co zobaczysz jutro przy GPT‑5.6. I to się będzie działo dalej. Ludzie, którzy głoszą małe modele, zwykle albo próbują Ci sprzedać swój startup, albo są w „copium”, bo i tak nie mają GPU. Więc — płacz mocniej. Ale jest jakaś droga, żeby wygrali; to duży świat.
David Ondrej: Wspomniałeś najnowszą generację największych modeli — Fable, GPT‑5.6. Zmieniło to sposób, w jaki pracujesz i myślisz o AI?
swyx: Trochę tak. Problem w tym, że te zmiany są bardzo subtelne. Jeśli nie eksplorujesz i po prostu wrzucasz do GPT‑5.6 te same prompty co do GPT‑5, albo do Fable to co do Opusa, dostaniesz nieco lepszą jakość i nie będziesz pod wrażeniem. Szansa leży w próbowaniu naprawdę innych rodzajów promptów — bo tak właśnie „pachną i brzmią” wielkie modele. Ciekawa jest tu prelekcja „field guide to Fable” Tariqa Shipara na AIE; opublikowaliśmy ją w trybie przyspieszonym, bo Fable jest teraz bardzo gorący. Lubię ideę szukania swoich niewiadomych. Kiedy znasz model, wiesz, co robi niezawodnie, i idziesz do niego z tym samym promptem i workflow — to jest kandydat do dystylacji i do małych modeli. Ale gdy masz do czynienia z większym albo nowym modelem, pytaj o dziwne rzeczy, o niewiadome, każ mu z Tobą burzować pomysły, zadawaj otwarte pytania. Dostaniesz ciekawe odpowiedzi, których inaczej byś nie miał. Ludzie, którzy umieją eksplorować możliwości modeli, poradzą sobie znacznie lepiej niż ci, którzy używają AI jak trochę mądrzejszego narzędzia.
David Ondrej: U mnie było tak, że Opus i 5.5 były trochę jak narzędzia — bardzo dobre, ale wciąż musisz im mówić, co robić i jak ma wyglądać. Przy Fable możesz być bardziej abstrakcyjny; oczywiście dalej wykona konkretne zadanie, ale naprawdę czuć, że model w większym stopniu rozumie Twoją intencję. Nie musisz być tak precyzyjny. Masz podobnie? I czy łapiesz się na myśleniu o problemach na wyższym, bardziej abstrakcyjnym poziomie?
swyx: Tak. Bardzo podoba mi się to, co mówi Boris Cherny o myśleniu w kategoriach pętli i wchodzeniu o poziom wyżej — zaczynasz tworzyć pętle, które generują pętle. Dla niego: nie powinieneś pisać promptów, tylko pisać pętlę, która tworzy prompty. Twój pierwszy smak tego to „goal” — ustawiasz cel, który generuje prompty albo w kółko powtarza cel botowi, aż spełni się jakiś warunek. To jeden przypadek z szerszej kategorii, do której należą pętle, a potem potrzebujesz pętli generujących pętle. Wielu ludzi tego dziś eksploruje — jak zmaksymalizować subskrypcję czy budżet tokenów. Lubię ideę, że budujemy „od pętli w górę” — nazywa się to loopcraft. Ale powinniśmy też zaczynać od górnej pętli i schodzić w dół: wszystko, co robimy najpierw ręcznie, próbować pośredniczyć agentem, a potem wymyślać, jak z tego wygenerować pętle. Rozwija się dziś umiejętność takiego myślenia.
David Ondrej: Miałeś keynote właśnie o pętlach. Co czyni świetną pętlę agentową i czego ludziom brakuje?
swyx: Bardzo prosto: świetna pętla ma w sobie dość specyfikacji, żeby agent wiedział, czego szukasz, oraz jakąś weryfikację — skąd wiadomo, że skończone, jak wygląda dobry wynik. Trzeci element, często pomijany dla wygody, ale bardzo pomagający, to czego robić nie wolno — bo znasz wady agentów. Na przykład: „mój model ciągle pisze pliki po 10 000 linii”, a to bardzo trudno utrzymać i zrównoleglić między wieloma agentami. Więc co jakiś czas rób „garbage collection”, refaktoryzuj, przeszukaj bazę kodu i redukuj duplikację. Wydajność i design to też ciekawy przypadek, zwłaszcza przy warstwie wizualnej i frontendzie — chcesz, żeby bot spojrzał na własny wynik, a często tego nie robi; zapomina o wersji mobilnej kontra desktop. Proste rzeczy. Ludzie wciąż za bardzo liczą na „one‑shot” — chcą, żeby domyślne wyrównanie modelu po prostu zadziałało, a to niesprawiedliwe oczekiwanie, żeby wszystko wyszło za pierwszym razem, bez patrzenia na własny wynik. „Napisz kod i miejmy nadzieję, że yolo się ogarnie”. Dojdziemy do tego, ale na razie trzeba modelowi pomagać.
David Ondrej: Załóżmy, że ktoś zaczyna nowy projekt i chce być maksymalnie produktywny. O jakich pierwszych pętlach powinien pomyśleć — jeszcze zanim ma zgłoszenia od klientów, z których można automatycznie robić fixy bugów? Gdybyś dziś zaczynał projekt, jak podszedłbyś do wdrażania pętli, żeby nie robić wszystkiego ręcznie?
swyx: Kilka rzeczy. Pierwsza — to nie do końca pętla, ale można ją odpalać cyklicznie, np. co tydzień — to pętla „grill me” / „interview me”: odwracasz role. Prosisz model, żeby to on zadawał Ci pytania, żeby wyciągnąć z Ciebie, co próbujesz zrobić. Bo my jesteśmy słabi w promptowaniu i w wyrażaniu, czego chcemy. Nie myślimy o rozstajach, dopóki nas przed nimi nie postawią — a wtedy: „no tak, to ważne, doprecyzujmy”. Dla mnie tak właśnie zachowuje się inteligentny pracownik: mówię mu coś do zrobienia, a on: „nie, najpierw odpowiedz mi na te dwa pytania”, i dopiero potem robi. To bardzo ważne i warto zachęcać do tego model.
Druga rzecz, którą lubię w generowaniu pętli, to research i burza mózgów — w zasadzie darmowe. „Przejrzyj moją konkurencję”, „zrób research i wymyśl mi co tydzień trzy pomysły, a potem je sprototypuj i zaimplementuj”. To super prosta pętla. Ten kod możesz wyrzucić — większość będzie śmieciem, ale część to darmowe pomysły, które po prostu dostajesz.
Kolejna sprawa to logowanie feedbacku — domknięcie cyklu wytwarzania oprogramowania (SDLC). Czyli: czy Twoja strona ma logi błędów i logi produkcyjne? Czy podłączyłeś to do agenta, żeby cyklicznie je czytał i na nie reagował? Ideał, do którego chcesz dojść, to samonaprawiająca się aplikacja: jeśli pojawia się bug, pętla już go wykrywa i już proponuje poprawkę. To są bazowe pętle.
A ogólny kierunek, do którego zmierzasz po zbudowaniu pełnego SDLC, to ustalenie celów: „chcę więcej sprzedaży”, „więcej konwersji”, „żeby ludzie spędzali więcej czasu na stronie”. To bardzo długi, wielomiesięczny cel, nad którym pracujesz wspólnie z AI — traktując je jak pełnoprawnego pracownika. Dla mnie tak wygląda „auto‑research”: masz funkcję straty, próbujesz ją optymalizować, próbujesz różnych rzeczy, łatwo cofnąć zmianę, łatwiej eksperymentować — z czasem znajdujesz wygrane i robisz coś w rodzaju spadku gradientu. To pętla napędzana celem, którą zaczynasz od podstawowych intuicji.
Uwaga: przy bardzo dużych projektach można wpaść w kłopoty — przestajesz rozumieć bazę kodu, dochodzisz do punktu, w którym spędziłeś dwa miesiące i musisz to wyrzucić, co jest smutne. Sposób, żeby tego uniknąć: zawsze rozumieć struktury danych. To one wyznaczają jasny podział — co jest rejestrowane, co raportowane, co UI może pokazać i na czym mogą działać workflow. Jeśli danych nie ma, nic nie zrobisz. Więc w pełni rozumiej wszystko, co jest logowane. Rób dużo „wywiadów” i autorefleksji: czy naprawdę potrzebuję tych danych, gdzie je trzymam, jak często są używane? To dla poważniejszych projektów, które chcesz utrzymać w produkcji — bo dużo kodu to jednak rzeczy jednorazowe, na dzień czy tydzień. Ale jeśli chcesz go używać dłużej niż kilka miesięcy, zainwestuj czas w zrozumienie warstwy danych.
David Ondrej: To świetna odpowiedź, mam z tego pięć nowych notatek. Wspomniałeś struktury danych — czego jeszcze nigdy nie oddawać? Nad czym wciąż mieć pełną kontrolę i pełną świadomość, budując z AI, nawet przy zbliżaniu się do miliarda tokenów dziennie?
swyx: Testowanie z użytkownikami. Modele wciąż są słabe w podstawowej ludzkiej intuicji: „kiedy to się przeskaluje, ten przycisk powinien być tutaj”, „ta walidacja oczywiście powinna tu być”. Modele nie żyją w tym samym kontekście co my — nie używają podobnych aplikacji cały dzień, dzień w dzień, do pracy i do życia. My mamy niepisane oczekiwania co do tego, jak wygląda dobra aplikacja. I nie chodzi tylko o wygląd, ale i o backend: gdzie jest mój audit log, gdzie autoryzacja, gdzie rozróżnienie „organizacje kontra zespoły”. Modelowi można to zlecić, ale powinieneś tę logikę wyspecyfikować albo stale ją testować. To nie zniknie.
Chodzi o to, że tak — palisz miliard tokenów dziennie, ale lepiej, żeby Twojej aplikacji naprawdę używali prawdziwi ludzie, zwłaszcza docelowi użytkownicy. Bo bardzo łatwo naklepać tyle slopu, że aplikacja staje się kompletnie bezużyteczna — zmarnujesz mnóstwo pieniędzy i czasu, albo startup po prostu upadnie. Nikt tego nie użyje, jeśli Ci na tym nie zależy. Jeśli Tobie nie zależy, czemu Twoim użytkownikom miałoby zależeć? „Care”, czyli troska, jest łatwo wyczuwalna. Gust i selektywność — to, że nie wysyłasz wszystkiego tylko dlatego, że możesz — ludzie zaczynają wyceniać jako premium. Nawet drobne detale designu: jest tyle sposobów, na które modele są niewystarczające, a ludzie z wysokimi standardami to widzą. Wielu przeżywa „psychozę LLM”: „modele są lepsze ode mnie we wszystkim, usiądę na plaży i niech agent koduje za mnie”. Ci nigdy nie osiągną sukcesu, bo nie mają gustu — a takich ludzi będzie miliard i wszyscy polegną. Porównawczo łatwiej się wyróżnić, po prostu znajdując miejsca, w których rzeczy nadal robi się z rzemiosłem i ludzkim gustem — i to widać w produktach.
David Ondrej: Czyli po prostu ręczne „dogfooding” — testowanie, klikanie przez każdy przycisk, brudzenie sobie rąk każdego dnia.
swyx: Tak. I pytanie do siebie: czy to jest to, czego naprawdę chcą użytkownicy? Czy tylko to, co model miał ochotę dzisiaj zakodować? Bo masz te wszystkie pętle, które są motywowane, żeby zużyć jak najwięcej tokenów. Oczywiście palą mnóstwo pieniędzy — ale czy tego chciał Twój użytkownik? Prosił o to? Faktycznie użyje? Czy może wrzucasz mu 100 różnych opcji konfiguracji, z których użyje dwóch — a potem usunie tę aplikację i zostawi tylko te dwie? Trudno powiedzieć „nie”, bo…
David Ondrej: …kod nigdy nie był trudniejszy, właśnie dlatego, że łatwiej zbudować cokolwiek.
swyx: Tak. „Mam dziś ochotę, dobra, dodam to” — i masz slop, którego nikt nie używa. To nie jest nowe w AI, to ogólny problem projektowy. Jeden z najbardziej wnikliwych komentarzy słyszałem od Bjarne Stroustrupa, twórcy C++ (Informacja dodatkowa: Stroustrup od lat ocenia propozycje zmian w standardzie C++). Ludzie chcą: „chcę tu typ datetime”, „chcę long int”, „chcę short float”. Każda z tych propozycji z osobna ma sens — razem to szaleństwo. Bo jeśli zgodzę się Tobie, muszę zgodzić się tamtemu i tamtemu, i skończę z 200 typami danych, których nikt nie ogarnia; ludzie w ogóle przestają uczyć się języka. Jego zadaniem jako szefa projektu jest zapytać: czy jest tu szersze rozwiązanie, gdzie jedna rzecz załatwia 200, czy te rzeczy są na tyle małe, że można je zrobić w „user landzie” albo się bez nich obejść — i wtedy zostawiam tylko jedno. To wciąż jest premium, może dziś jeszcze bardziej.
David Ondrej: Czyli głębokie rozumienie, czego chcą klienci i tej domeny — znanie jej lepiej niż ktokolwiek — i rozwijanie gustu, o którym mówisz. Co jest różnicą między founderami, którzy mają gust, a tymi, którzy go nie mają?
swyx: To trudne. Nie wiem, czy sam mam gust. Dla mnie AIE World’s Fair jest moim największym wyrazem gustu — wybieram ludzi, którzy wybierają całą resztę. A różnica? Po pierwsze: nie kłam. To proste, a mnóstwo ludzi kłamie.
David Ondrej: Jaki byłby przykład kłamstwa?
swyx: „Mój mały model językowy 4B bije modele klasy Fable”. Widać tego mnóstwo. Część może być trochę legit, ale generalnie ludzie wiedzą, że ściemniasz. Founder, który świadomie tak kłamie, po prostu nie ma gustu — bo nie zależy mu, żeby skala jego twierdzeń pokrywała się z tym, co realnie dostarcza. Wielu odpada już na tym etapie, łatwo ich odsiać. Poza tym ludzie z gustem są bardziej zaangażowani w swój problem niż we własną firmę czy rozwiązanie. Dostaję mnóstwo osób, które przychodzą na AIE i chcą tylko pokazać firmę: „jesteśmy najlepszym providerem inferencji od tego i tamtego”. Fajnie dla Ciebie, ziomek. Nie mówią nic o tym, jak problem jest rozwiązywany, niczego nie uczą o tym, jak my — jako branża — posuwamy się naprzód. Wszystko jest o „was”, nie o „nas”. A my szukamy historii nas jako cywilizacji czy branży, która idzie do przodu. Jeśli podepniesz się pod szerszy cel, którego wszyscy chcą — np. wszyscy chcą szybszej inferencji — to super. Powiedz mi, jakie są mapy drogowe, blokery, kluczowe wnioski z ostatnich dwóch–trzech lat, dzięki którym tam doszliście. Nie musisz wszystkiego open‑source’ować, jesteś closed source, musisz zarabiać — ale naucz mnie czegoś, człowieku. Zamiast „oto moje benchmarki, jesteśmy lepsi od wszystkich, a reszta jest do niczego”. Bo skąd mam wiedzieć albo czemu mam się przejmować? Najlepsi ludzie z gustem czymś się dzielą, bo wiedzą, że mają sto sekretów, a dzielą się dwoma — istotnymi dla dyskusji, nie całą historią; potrafią pokierować branżową rozmową i pozostać istotni. Ludzie bez gustu tego nie robią — są tylko naśladowcami.
David Ondrej: To bardzo częste, mnie też się zdarza — ktoś przepycha swoją rzecz zamiast wnosić coś do dyskusji. Może to desperacja, bo palą dużo pieniędzy i mało rundy zostało. Ale weź Elona Muska: on nie próbuje sprzedać Ci rakiety, tylko mówi, dlaczego musimy dotrzeć na Marsa. Chodzi o większą misję, o wyjaśnienie z pierwszych zasad, dlaczego robi to, co robi — i dlatego ludzie się jarają. Rozumieją misję i to, że wnosi coś do cywilizacji, a nie „kup moją rzecz”.
swyx: Zgadzam się. On jest osobą napędzaną misją. Jeśli masz dobrą misję, każdy chce się przyłączyć, kibicować, wspierać. Jeśli masz kiepską misję — „chcę wygrać kosztem wszystkich konkurentów” — nikogo to nie obchodzi. Ludzie nie rozumieją, jak wygląda dobra misja. Wielu founderów to technolodzy, nie są tego uczeni — nie widzą wielu pozytywnych wzorców i nie umieją ich przełożyć na swoje działanie, nie widzą siebie jako zdolnych do tego. Chciałbym móc zrobić jakiś kurs: naprawdę każdy może to zrobić, każdy może lepiej opowiedzieć swoją historię. A to zaczyna się od przyzwoitej misji — ambitnej, ale wykonalnej — takiej, żebyśmy chcieli Ci kibicować, zamiast słuchać, ile pieniędzy zebrałeś i jak szybko doszedłeś do 100 milionów. To obchodzi tylko inwestorów. Wciągnij nas w projekt, w szerszą misję — wtedy nam zależy. Ludzie potrafią się przejąć nawet wydajnością bazy danych — trzeba tylko uczynić to fajnym i technicznym oraz powiedzieć, dlaczego to wy jesteście najlepszymi na świecie do tego zadania, bo przez całe życie nie robiliście nic innego. Czemu miałbym się przejmować Vitess i PlanetScale? Nie siedzę w świecie wysokowydajnych baz danych. Ale zależy mi na YouTubie i na tym, żeby działał sprawnie — a to samo dotyczy Ubera i LinkedIna. Wtedy mnie to obchodzi. Trzeba jednak opowiedzieć historię tak, dlaczego ludzie mają się przejmować, zamiast: „moje benchmarki są o 50% lepsze, a konkurenci są do niczego”. To bardzo negatywne.
David Ondrej: Jakiej rady udzieliłbyś dziś nowym founderom startupów AI? Krąży mnóstwo opinii: „SaaS jest martwy”, „laby AI Cię zastąpią”, „nie rób tego”, „nie zatrudniaj nikogo, zostań solo aż do miliarda dolarów”. Co najważniejszego chciałbyś przekazać komuś, kto chce założyć startup AI?
swyx: Po pierwsze — nie zajmuję się doradzaniem founderom, nie jestem VC, ja tylko przeprowadzam z nimi wywiady. Ale gdy pada takie pytanie, oferuję dwie rzeczy. Pierwsza, bardzo prosta: warstwa aplikacji wciąż jest bardzo bogata do budowania. Poszukaj mojej „agent lab thesis” / „agent lab playbook”, którą napisałem na Latent Space. Budowanie „agent labu” polega na byciu ekspertem domenowym w danej wertykali — kodowanie, ochrona zdrowia, prawo. Po prostu przejmij wertykal i bądźcie „tymi od AI”. Dlaczego to działa? Po pierwsze, masz dużo więcej oddania niż generalistyczne laby modeli. Po drugie, możesz pivotować, kiedy tylko pojawia się kolejny model — ta niezależność od modelu jest bardzo ważna. Sam Altman zawsze powtarza: buduj taką firmę, która jest szczęśliwsza za każdym razem, gdy wypuszczamy nowy model, a nie taką, która wtedy boi się o życie. Taka firma to właśnie agent lab.
Dla bardziej ambitnych founderów — bo to była opcja niższego ryzyka, prawie gwarantowana wygrana, jeśli tylko dobrze egzekwujesz — jest wariant wysokiego ryzyka i wysokiej nagrody, wymagający researchu: „domain‑specific model lab”. Mówimy o Black Forest Labs, o Thinking Machines, a nawet o bardziej niszowych jak Cartesia czy inne — to wszystko jest częścią łańcucha narzędzi modelowych. Ludzie są bardzo chętni finansować nowy research; Ngram to kolejny przykład. Możesz zebrać o rzędy wielkości więcej pieniędzy niż w tamtym wariancie, ale ryzyko porażki jest wysokie — i nie sądzę, żebyś musiał się tym aż tak przejmować. Powinieneś podjąć wysokie ryzyko, bo inwestorzy i tak je podejmują; jeśli masz w miarę uczciwą, spójną wizję, idź w to — ludzie Cię wesprą. To piękny czas na naprawdę nowy research, bo wszyscy wiedzą, że w pewnym momencie paradygmat autoregresyjnego transformera LLM się skończy — więc już finansują następną rzecz. Wszystko, co jest bardziej kapitałochłonne, jest dobre. Founderzy na ścieżce VC powinni rozumieć, że jesteście opłacani za wdrażanie kapitału z jakimś ROI, a nie tylko za budowanie rentownego biznesu. Oczywiście chcesz zysków, ale ludzie chcą fos (moatów), a fosa to zainwestowanie dużego kapitału, żeby zabezpieczyć przewagę technologiczną albo dystrybucyjną. Wielu founderów jest zbyt bojaźliwych: „zbuduję open‑source’owy framework do orkiestracji agentów, zdobędę mnóstwo gwiazdek na GitHubie, potem trochę konsultingu, trochę zarobię, a potem… zostanę miliarderem”. Nigdy tam nie dojdą. Są zbyt bojaźliwi, nie ma zaangażowanego kapitału. Nazywasz się „infra founderem”, a nie prowadzisz żadnej infry — jesteś tylko warstwą na AWS. Wyjątkowi founderzy, których widzę, naprawdę budują infrastrukturę: ogarniają data center, kupują GPU, zbierają dane. To prawdziwa infra. Cała reszta to gierki.
David Ondrej: Muszę tu wejść głębiej — ta bojaźliwość founderów, oczywiście nie tylko w infrze. Jak ludzie stają się bojaźliwi? Dostają pierwszy smak sukcesu i nie chcą go stracić — jak Elon, który zarobił 180 milionów i reinwestował je w kolejne dwie firmy?
swyx: Jak diabli. Ja sam jestem super bojaźliwy. Wiem, że jestem dobry w content, robię content, umiem zrobić konferencję — jest rentowna, rośnie. Ale to nie jest najbardziej ambitny pomysł, jaki mam. Nie bierz mnie za przykład udanego foundera — jestem przeciętnym founderem, wciąż jakoś udanym, coś to będzie warte, ale naprawdę świetni founderzy, których mam przywilej znać, są dużo lepsi ode mnie w byciu ambitnymi. Znowu wraca to do tego: czy masz dobrą misję, a potem — czy masz dobry sposób, żeby tam dojść, i czy potrafisz zrekrutować po drodze ludzi, którzy Ci pomogą. „Rekrutować” to nie tylko pracownicy, ale też klienci, partnerzy, a nawet konkurenci — jeśli wystarczająco Cię szanują, pomogą. Piękno dobrej misji polega też na tym, że jeśli poniesiesz porażkę, ludzie dadzą Ci drugą szansę. Jeśli musisz przesunąć terminy — nieważne, misja zostaje ta sama.
Co do ambicji: ludzie powinni myśleć o tym, czego ludzie będą oczywiście potrzebować za 30, może 10–30 lat, i budować pod to — bo większość myśli w horyzoncie dwóch–pięciu lat. Twoja ambicja automatycznie rośnie, gdy wydłużasz horyzont czasowy. Jeśli myślisz „nie wiem, czy dam radę, ale ktoś powinien to zrobić, ktoś pewnie zrobi, tylko wymaga to dużo pracy na starcie” — właśnie ten rodzaj lęku jest powodem, żeby to zrobić.
David Ondrej: Kim są najlepsi founderzy, których znasz, i jakie cechy dzielą?
swyx: Tak wielu, zależy, co znaczy „znać”. Miałem w podcaście Marka Zuckerberga, Grega Brockmana — wszyscy byli bardzo hojni ze swoim czasem. Mike’a Krigera niedawno przeprowadzałem na Voltzare — kolejny niesamowity founder, który miał porażkę (Artifact) między Instagramem a Anthropic Labs. Ciekawie się rozmawia z tą klasą ludzi. Bliżej mi znani bardziej udani founderzy to Guillermo Rauch z Vercela czy Paul Copplestone z Supabase — założyli firmy odpowiednio 10 i co najmniej 5 lat temu. Jest też krótsza kohorta firm dwu‑, trzyletnich — jak MatX, zaczynający nowy chip, czy Etched, który właśnie się pojawił. Ci biorą się za Nvidię, z którą nikt nie sądzi, że da się konkurować. Ale z pierwszych zasad widać, że GPU — dosłownie „general purpose graphics processing unit” — nie jest zoptymalizowany pod transformery, a oni mogą zrobić custom krzem. Ta teza jest prawdopodobnie słuszna. Główne ryzyko: czy OpenAI użyje Twojego chipu, czy zbuduje własny. Ale znaczenie ekosystemu jest na tyle duże, że jakiś niezależny dostawca chipów — MatX albo Etched — się przebije. Konkurowanie z Nvidią jest bardzo ambitne. Ngram, próbujący rozwiązać continual learning — bardzo ambitne. Black Forest Labs — obraz i wideo.
Co ciekawe, wiele najbardziej ambitnych firm ma tylko ogólną domenę, bez punktu końcowego. Pytasz: „gdzie to będzie za pięć lat?” — nie mają prawdziwej odpowiedzi, po prostu „lepiej, moja rzecz, ale lepiej”. Są w tym na długi dystans. Albo jesteś z nimi na misji, albo nie zainwestujesz i nie zaprzyjaźnisz się z nimi. Może ich misja jest zła. Ale gdybyś rozumiał znaczenie głosu, zainwestowałbyś w ElevenLabs, dziś jeden z topowych startupów. Gdybyś rozumiał znaczenie tego, że nietechniczni ludzie robią strony marketingowe, zainwestowałbyś w Lovable, dziś kolejny „decacorn”. To samo z sandboxami: Modal, E2B, Daytona — wszystkie bardzo ambitne, bo w zasadzie wymyślają na nowo serverless / chmurę dla agentów. To mniej seksowna, infrastrukturalna innowacja, ale chmura ma cykle co 5–10 lat: nowa fala paradygmatów wdrożeniowych, która zawsze sprowadza się do tego, że chcesz, żeby komputery wstawały coraz szybciej. Oni byli pierwsi i dziś dostają śmieszne wyceny.
David Ondrej: Myślisz, że wszystko, co zaprojektowano przed falą ChatGPT — przed współczesną eksplozją AI — ma szansę zostać zdysruptowane albo zoptymalizowane? Bo z pierwszych zasad: jeśli istniało przed agentami i LLM‑ami, to pewnie nie było pod nie zoptymalizowane.
swyx: Dokładnie. Zadałeś łatwiejszą wersję pytania: czy ma szansę? Oczywiście, wszystko ma szansę zostać wymyślone na nowo. Ale rzeczy są „lepkie”. Git wymyślono, zanim internet naprawdę wystartował. Czy git zostanie zastąpiony? Ludzie próbują, ale szanse są małe, bo protokoły i formaty danych są bardzo lepkie. Co więc zostanie wymyślone na nowo? Myślę, że MCP kontra REST i GraphQL — te protokoły komunikacji backend–frontend, protokoły integracji — są przerabiane. Ale nie sądzę, żeby zmieniła się duża część fundamentalnej warstwy internetu. To głównie powierzchniowe trendy.
David Ondrej: A jaka jest trudniejsza wersja tego pytania? Powiedziałeś, że zadałem łatwiejszą.
swyx: Trudniejsza to: co konkretnie zostanie wymyślone na nowo — czyli robienie prognoz, a nie ogólników. Git prawdopodobnie zostanie, ale GitHub jest dysruptowany z wielu stron.
David Ondrej: Rozumiem. Budując nowe rzeczy, ludzie powinni myśleć o budowaniu dla ludzi czy czysto dla agentów? Bo miałem parę fajnych pomysłów i myślałem: „jak zdefiniuję pętlę /go i Codex, to cały ten produkt jest przestarzały”. Jak o tym myśleć? Czy webowy UI i SaaS jeszcze się liczą, czy chodzi tylko o to, jak wzmocnić agentów?
swyx: To dobre pytanie, na które jeszcze nie mam odpowiedzi. Oba są ważne — w statystykach użycia jakiejkolwiek strony dokumentacji czy narzędzi deweloperskich to mniej więcej 50/50. Więc rób jedno i drugie, po co wybierać? To, co dobre dla ludzi, jest zwykle dobre też dla agentów — to fałszywa dychotomia. Ale „agents first” to raczej kwestia skali. Gdy zaczynasz od zera, prawdopodobnie startujesz od ludzi, bo i tak zajmie chwilę, zanim zarejestrujesz się w AEO (Informacja dodatkowa: AEO — „Answer Engine Optimization”, czyli optymalizacja pod to, żeby treść była wychwytywana przez wyszukiwarki oparte na AI/agenty).
David Ondrej: Dam Ci swój przykład, żeby wyjaśnić, czemu pytam. Mieszkam teraz w Polsce i chciałem znaleźć najlepszych inżynierów i deweloperów w okolicy. Pomyślałem: zbuduję jakiś miks Obsidiana, proaktywnego kontaktu, deep researchu i agenta, i będę miał wizualny graf pokazujący, kto jest najlepszy do danej roli. Gdy budowałem to w Codeksie — a testowałem w czasie, gdy Fable był zbanowany — Codex podczas testów już wyprodukował mój wynik: znalazł najlepszych ludzi w okolicy przez dwie–trzy pętle /go. Więc porzuciłem cały pomysł budowania ładnego wizualnego grafu. Dlatego pytam — łapię się na tym, że coraz więcej pracy robię przez Codex, Cursor czy Claude Code, rozmawiając z agentem, a agent wykonuje zadania.
swyx: Jakie jest pytanie?
David Ondrej: Pytanie brzmi: czy widzisz u siebie ten sam wzorzec — że robisz mniej pojedynczych zadań, a więcej pracy przez te główne agenty — i jaki wpływ to będzie miało? Wspomniałeś, że aplikacja Codex jest super dopracowana i będzie tylko lepsza, jutro wychodzi GPT‑5.6. Jest kilka głównych agentów, z którymi ludzie wchodzą w interakcję coraz częściej, albo mają własnego osobistego agenta. W miarę jak ludzie coraz więcej robią przez swojego agenta, a agent załatwia całą resztę — jakie to ma implikacje dla internetu, dla tego, jakie produkty budować?
swyx: To bardzo szerokie pytanie społeczne, nie wiem, czy potrafię odpowiedzieć wyczerpująco.
David Ondrej: Zacznij od siebie.
swyx: Definicja pojedynczego zadania się zmienia — moje słupki się przesunęły. Dla mnie zadanie to teraz po prostu prompt w Codeksie, np. „opłać mój rachunek medyczny” — dam stronę i tyle. Pojedyncze zadanie poszło w górę pod względem poziomu abstrakcji i to jest bardzo dobre. Co to znaczy dla społeczeństwa? Mam nadzieję, że dużo rutynowej pracy „white collar” zniknie i pozwoli ludziom być bardziej kreatywnymi, w „flow”, oraz obniży energię aktywacji potrzebną do robienia rzeczy eksploracyjnych i twórczych. To pozytywna strona. Negatywna: ludzie użyją tego do spamu — mają złe bodźce, nie mają większego celu poza „spróbujmy szybkiego marketingowego hacka”. Zabijają internet. Ludzie próbują budować „internet bez botów” — w większości polegną. Sam Altman ma ten Worldcoin, skanuje gałkę oczną, żebyś udowodnił, że jesteś człowiekiem; „proof of human” to temat, o którym się mówi. Ale budowanie nowej sieci społecznościowej odseparowanej od botów jest idealistyczne i pewnie się nie uda — bo my chcemy botów w naszym życiu, chcemy, żeby przejmowały ograniczoną autonomię. Czasem czytanie botowego slopu jest przydatne — sam robię to cały czas, bo do podstawowego, rutynowego streszczenia nie potrzeba człowieka. Musimy jako społeczeństwo znaleźć równowagę i może zajmie nam to 30 lat, a nie trzy. Ludzie bywają zbyt niecierpliwi.
David Ondrej: Co trzeba dziś, żeby być na czele AI? Pytanie szerokie — możesz podejść z każdej strony: etyka pracy, samokształcenie, liczba spalonych tokenów, jakie umiejętności i wiedza. Myśląc nie tylko o founderach, ale o inżynierach, designerach — kimkolwiek na najgłębszym froncie AI — co jest do tego potrzebne?
swyx: Bycie poinformowanym jest oczywiście ważne — musisz podłączyć się do przepływu newsów. To trochę interesowne, bo piszę wiadomości o AI i kuratoruję konferencję, na którą ludzie przychodzą, żeby być na bieżąco — ale nie widzę, jak to obejść. Chcesz być choć trochę świadomy, co robią inni. Poza tym: rezygnacja z bycia na czele wszystkiego, bo to i tak niemożliwe. Możesz być na czele w pamięci (memory) — „jestem gościem od pamięci, robię wszystko związane z pamięcią; jeśli robisz model dyfuzyjny, nie gadaj ze mną, idź na drugą stronę pokoju”. Podobnie generatywne media — ludzie robią tylko to i to super. Specjalizacja jest świetna. Wielu ludzi powinno być na czele właśnie jako specjaliści, a pewna mała grupa — jak ja, z „ADHD” i uzależnieniem od bycia szerokim — powinna stanowić szeroką warstwę usługową, żebyś Ty mógł być wąski i głęboki. Głęboka praca to świetny sposób na pracę na najwyższym poziomie. Jest esej, do którego lubię odsyłać — „Solitude and Leadership” (Informacja dodatkowa: esej Williama Deresiewicza wygłoszony do kadetów w West Point). Autor, wojskowy generał, doradza absolwentom szkoły oficerskiej: czasem, żeby przewodzić, nie powinieneś być wśród ludzi, tylko sam — tam, gdzie możesz naprawdę pomyśleć jakościowo i zastanowić się, dokąd ludzie mają iść, a potem ich poprowadzić. Nie poprowadzisz, jeśli zawsze podążasz za tłumem i jesteś w tłumie, bo wtedy robisz tylko to, czego chce tłum — a to nie przywództwo, tylko schlebianie. Dobre przypomnienie, że rolą lidera w danym polu jest wypatrywać ważnych problemów do rozwiązania i kierować branżę w tę stronę, zamiast wiecznie śledzić najnowszy nagłówek „ten zebrał 100 milionów, tamten 2”.
David Ondrej: Wspomniałeś, że misja jest kluczowa, a inny element to rekrutacja. Jak rekrutować w tej epoce? Jedni mówią: szukaj seniorów, bo mają fundamentalne zrozumienie i lepiej lewarują AI. Inni: zatrudniaj dwudziestolatków, którzy są na czele AI i wszystko rozumieją. Jak o tym myślisz?
swyx: Najlepszy jest miks doświadczonych i utalentowanych. Nie przejmuję się zbytnio doświadczeniem „na papierze” — obchodzi mnie, czy potrafisz wykonać pracę. Ale doświadczenie pomaga ją wykonać. Więc bardzo pomaga mieć doświadczonych „supervisorów”, czyli menedżerów, wokół, a do tego młodszych, mniej doświadczonych, ale zdolniejszych, bardziej kreatywnych czy „spiky” — to dobre dla wyników całego zespołu. Powszechna odpowiedź: zrób z nimi „work trial” — kontrakt na miesiąc, trzy miesiące — a potem zatrudnij. Powinieneś też względnie szybko zwalniać, jeśli trzeba. Oczywiście dawaj ludziom szansę i częsty feedback, ale trzymanie złego pracownika wpływa też na pozostałych. Im szybciej ludzie rozumieją, że są w wysokowydajnym zespole, tym chętniej polecą swoich równie dobrych znajomych. Jeśli zespół jest rozlazły i o niskich standardach, cała firma i tak nie pójdzie dobrze. To niewdzięczne zadanie lidera: powiedzieć „jesteś naprawdę wartościowy, ale nie pasujesz do tego zespołu, więc musimy znaleźć kogoś innego”. Bardzo trudna decyzja, bo każdy, kto chce Ci pomóc — zwłaszcza na początku — jest atutem. Ale czasem bywają na minusie, mimo wszystkich plusów. Musiałem podjąć kilka takich decyzji w ostatnim roku, jest to paskudne, ale zespół jest przez to znacznie szczęśliwszy i idzie nam dobrze.
Wciąż dużo rekrutujemy osobiście — mamy zasadę, że zawsze musimy spotkać ludzi twarzą w twarz. Bo na Zoomie ludzie patrzą na inne rzeczy na ekranie, a są subtelne sygnały, których nie wychwycisz, dopóki nie spotkasz kogoś na żywo. To wciąż bardzo „nie‑AI” element rekrutacji. Ludzie eksplorują inne rzeczy — Juicebox robi ciekawe rekrutacyjne AI — ale sam nie mam tam dużego doświadczenia.
David Ondrej: Zakończmy pozytywnie. Na co ludzie powinni się cieszyć w najbliższych 6–12 miesiącach, biorąc pod uwagę tempo AI?
swyx: Prawdopodobnie na bardzo szybką inferencję. Ludzie przyzwyczaili się do 50–100 tokenów na sekundę od głównych labów, ale wszystko, co napędza Cerebras — w tym SWE‑1.7 wypuszczony dzisiaj — jest rzędu tysiąca tokenów na sekundę. Nadchodzi znacznie szybsza. Widziałem demo 10 000 tokenów na sekundę, a także setek tysięcy. Te poprawy o rzędy wielkości są już w demach — teraz to kwestia „produkcjonizacji” na masową skalę. A gdy masz stukrotnie szybszą inferencję, zmienia się typ produktów, jakie robisz.
David Ondrej: Świetnie. Gdzie ludzie powinni Cię szukać — Twitter, Latent Space?
swyx: AI Engineer wszędzie; Latent Space to chyba najczęstszy newsletter. Jeśli lubisz to, o czym tu rozmawialiśmy — omawiamy takie rzeczy cały czas w newsletterze i podcaście — wejdź na laton.space i sprawdź.
David Ondrej: Super, dzięki, swyx.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Przejdź od promptów do pętli — a potem do pętli generujących pętle
Na czym polega: Zamiast pisać pojedyncze prompty, buduj powtarzalne pętle: cel, który sam generuje kolejne prompty do bota, aż spełni się warunek. Wyższy poziom to pętle, które tworzą inne pętle („loopcraft”).
Jak stosować: Każdą czynność, którą dziś robisz ręcznie, najpierw obuduj agentem, a potem zapytaj: „jak zamienić to w pętlę, która robi to cyklicznie sama?”. Zacznij od jednej pętli bazowej i schodź w dół.
Na co uważać: Pętle są motywowane do zużywania tokenów, nie do tworzenia wartości — łatwo wygenerować masę bezużytecznego kodu. Pętla bez weryfikacji i bez limitów potrafi produkować slop w nieskończoność.
2.Dobra pętla ma trzy części, w tym listę zakazów
Na czym polega: Skuteczna pętla agentowa zawiera specyfikację (czego szukasz), weryfikację (skąd wiesz, że gotowe i jak wygląda dobry wynik) oraz — najczęściej pomijane — listę tego, czego robić nie wolno.
Jak stosować: Do promptu dopisuj znane wady modelu: „nie pisz plików po 10 000 linii”, „co jakiś czas refaktoryzuj i usuwaj duplikację”, „sprawdź własny output na mobile i desktopie”.
Na co uważać: Nie licz na „one‑shot” i domyślne wyrównanie modelu. Oczekiwanie, że wszystko zadziała za pierwszym razem, bez patrzenia na własny wynik, to główny błąd.
3.Nigdy nie oddawaj warstwy danych
Na czym polega: Struktury danych wyznaczają, co jest zapisywane, raportowane i co UI oraz workflow mogą w ogóle zrobić. Jeśli danych nie ma, żaden agent nic z tym nie zrobi.
Jak stosować: Przy projektach, które mają żyć dłużej niż kilka miesięcy, zainwestuj czas w pełne zrozumienie tego, co jest logowane, gdzie trzymane i jak często używane. Rób „wywiady” i autorefleksję nad każdym elementem danych.
Na co uważać: Przy dużych projektach grozi Ci przestanie rozumienia bazy kodu i konieczność wyrzucenia dwóch miesięcy pracy. Kod jednorazowy (na dzień/tydzień) nie wymaga tej dyscypliny — nie przeinwestuj w błahostki.
4.Testowanie z prawdziwymi użytkownikami zostaje po Twojej stronie
Na czym polega: Modelom brakuje ludzkiej intuicji produktowej — nie żyją w kontekście codziennego używania aplikacji, więc gubią responsywność, walidacje, audit logi, rozróżnienie org/team itd.
Jak stosować: Codziennie „dogfooduj” — ręcznie klikaj przez każdy przycisk i pytaj: czy tego chce użytkownik, czy to tylko to, co model miał ochotę dziś zakodować? Specyfikuj i testuj oczekiwane zachowania backendu.
Na co uważać: Palenie miliarda tokenów dziennie nic nie daje, jeśli nikt realnie nie używa produktu. Łatwo naklepać slop, który czyni aplikację bezużyteczną i topi pieniądze oraz czas.
5.Selektywność i gust to nowa przewaga
Na czym polega: Gdy każdy generuje 100 wariantów czegokolwiek, wartością staje się mówienie „nie”. Sama możliwość dodania funkcji nie jest powodem, żeby ją dodać.
Jak stosować: Przy każdej propozycji funkcji pytaj (jak Stroustrup w C++): czy istnieje szersze rozwiązanie, które załatwia wiele przypadków naraz, czy da się to zrobić „w user landzie”, czy można się bez tego obejść?
Na co uważać: Dziś trudniej powiedzieć „nie”, bo zbudować cokolwiek jest łatwo. Efektem są konfiguracje z setką opcji, z których użytkownik używa dwóch — i porzuca produkt.
6.Nowe modele nagradzają eksplorację, nie recykling promptów
Na czym polega: Wrzucając do Fable/GPT‑5.6 stare prompty od Opusa/GPT‑5, dostaniesz tylko odrobinę lepszą jakość. Wartość odblokowujesz, próbując zupełnie innych, bardziej abstrakcyjnych promptów.
Jak stosować: Przy nowym lub większym modelu pytaj o rzeczy dziwne, o niewiadome, każ z Tobą burzować pomysły i zadawaj pytania otwarte. Możesz operować na wyższym poziomie intencji, mniej precyzyjnie.
Na co uważać: Stały, przewidywalny prompt‑workflow to sygnał, że zadanie nadaje się do dystylacji i małego modelu — nie marnuj na nim dużego modelu. Odwrotnie: nie ograniczaj wielkiego modelu do roli „trochę mądrzejszego narzędzia”.
7.Zbuduj bazowe pętle: „przepytaj mnie”, research i samonaprawę
Na czym polega: Trzy pętle startowe: „grill me / interview me” (model wypytuje Ciebie, by wydobyć intencję), cotygodniowy research + burza mózgów z prototypowaniem, oraz domknięcie SDLC — agent czyta logi produkcyjne i sam proponuje poprawki (self‑healing app).
Jak stosować: Pętlę „przepytaj mnie” odpalaj cyklicznie (np. co tydzień) — traktuj model jak inteligentnego pracownika, który najpierw zadaje pytania. Podłącz logi błędów do agenta. Kod z pętli researchowej traktuj jako zrywalny.
Na co uważać: Większość wygenerowanego kodu researchowego będzie śmieciem — nie przywiązuj się, wyciągaj z niego tylko darmowe pomysły. Samonaprawa wymaga wpiętych logów, inaczej pętla nie ma z czego wykrywać bugów.
8.Wybierz model biznesowy świadomie: agent lab vs. model lab
Na czym polega: Warstwa aplikacji wciąż jest bogata. „Agent lab” (ekspert domenowy w jednej wertykali) to niższe ryzyko i niezależność od modeli — pivotujesz przy każdym nowym modelu. „Domain‑specific model lab” to wysokie ryzyko, wysoka nagroda i realny research.
Jak stosować: Buduj firmę, która cieszy się z każdego nowego modelu, a nie boi o życie (zasada Altmana). Jeśli idziesz ścieżką VC, rozumiej, że jesteś od wdrażania kapitału z ROI — moaty wymagają realnej inwestycji (infra, dane, GPU).
Na co uważać: „Cienka warstwa na AWS” nazywająca się infrą, framework open‑source liczący na gwiazdki i konsulting — to bojaźliwość, która nie dowozi. Wariant model‑lab daje więcej kapitału, ale realne ryzyko porażki jest wysokie.
9.Misja bije autopromocję
Na czym polega: Ludzie z gustem angażują się w problem, nie w swoją firmę — dzielą się wnioskami i kierują branżową rozmową. Ludzie bez gustu przepychają siebie („jesteśmy najlepsi, reszta jest do niczego”) i kłamią o możliwościach.
Jak stosować: Opowiadaj z pierwszych zasad, dlaczego problem jest ważny dla wszystkich (jak Musk o Marsie), a nie ile zebrałeś pieniędzy. Podziel się dwoma realnymi wnioskami zamiast samymi benchmarkami. Nie kłam o wynikach.
Na co uważać: Przechwalanie się rundami finansowania interesuje tylko inwestorów. Negatywny przekaz („konkurenci ssą”) odpycha; dobra, ambitna, ale wykonalna misja sprawia, że po porażce dostajesz drugą szansę.
10.Przygotuj się na bardzo szybką inferencję
Na czym polega: Standard to dziś 50–100 tokenów/s, ale rozwiązania na Cerebrasie osiągają rzędy tysiąca; w demach są już 10 000, a nawet setki tysięcy tokenów/s. To poprawy o rzędy wielkości.
Jak stosować: Planuj produkty pod założenie, że inferencja będzie ~100× szybsza — to zmieni, co w ogóle da się zbudować (np. gęstsze pętle agentowe, interakcje w czasie rzeczywistym).
Na co uważać: To wciąż głównie dema — realna przewaga zależy od „produkcjonizacji” na masową skalę. Duże modele frontierowe (10–20 bln parametrów) nadal będą dominować jakościowo, więc szybkość to nie wszystko.