O czym jest ten film
- Theo przyznaje się do podwójnego błędu: najpierw przewidywał płaskowyż możliwości AI (jego film sprzed dwóch lat), a później twierdził, że modele są już dość inteligentne i nie trzeba ich dalszego rozwoju.
- Opus 5.5 przekonał go do odwrotu: mądrzejsze modele są potrzebne — nie jemu, lecz grupom, które dotąd nie potrafiły wykorzystać AI w pełni.
- Katalizatorem okazały się fanowskie miksówki gier (m.in. Halo × Call of Duty), powstające dzięki dekompilacji i przepisywaniu silników w Ruście z biblioteką Bevy.
- Autor buduje ramy czterech poziomów pracy z AI: od wspomagania własnych kompetencji, przez personalizację narzędzi, po tworzenie rzeczy niezrozumiałych dla użytkownika i inżynierię wsteczną starych systemów.
- Kluczowa grupa beneficjentów to „ludzie techniczni” — sprawni z komputerem nieprogramiści; dla nich Opus 5.5 to skok, bo jeden, dobrze wyceniony model w abonamencie potrafi wszystko.
- Deweloperzy również zyskują: przykład Lawn — otwarta alternatywa dla Frame.io (produktu, za który Adobe zapłaciło 1,3 mld USD), sklecona w kilka dni na Gemini 3 Pro i Opus 4.6.
- Ostra teza: deweloperzy nie są kreatywni, a ludzie techniczni — właśnie dlatego, że nie znają ograniczeń — myślą śmielej (Zapier, absurdalne konfiguracje OBS z 40 tysiącami scen).
- Kultura „PR musi zostać scalony” oraz przywiązanie do utrwalonych praktyk (np. zakaz dodawania plików .env do repozytorium) blokują kreatywność inżynierów.
- Recepta: elastyczność co do poziomu abstrakcji i środowisko projektowane pod agentów — przykład T3OS (Bash zamiast Zsh, bo ponad 30% błędów Claude’a wynikało z różnic w formatowaniu końców linii).
- Wniosek końcowy: przepaść między deweloperami a ludźmi technicznymi przestanie rosnąć; jeśli programiści nie zmienią nastawienia, zostaną wyprzedzeni o kilka długości.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Oceniaj nowy model po tym, kogo przesuwa wyżej, a nie tylko po benchmarkach
Na czym polega: Opus 5.5 nie dał Theo nowych, nieosiągalnych wcześniej możliwości — za to skonsolidował całą paletę umiejętności w jednym, dostępnym w abonamencie modelu, co gwałtownie podniosło lot osoby techniczne, wcześniej niekodujące.
Jak stosować: Przy premierze modelu pytaj nie tylko „o ile jest lepszy”, ale „które grupy użytkowników i które poziomy zadań odblokowuje” oraz „jaki jest realny próg wejścia: cena, limity, dostępność”.
Na co uważać: Własna perspektywa zawodowa zniekształca ocenę — model, który tobie wydaje się „ewolucyjny”, dla kogoś innego może być rewolucją.
2.Rozpoznaj, na którym z czterech poziomów pracujesz
Na czym polega: Poziomy: (1) AI pomaga w tym, co już umiesz; (2) AI modyfikuje narzędzia, których używasz; (3) AI buduje rzeczy, których w pełni nie rozumiesz; (4) AI dekompiluje i przebudowuje systemy uznawane za niezrozumiałe.
Jak stosować: Świadomie dobieraj poziom do zadania — prosty skrypt do Discorda nie wymaga najwyższej półki; odwrotnie, nie ograniczaj śmiałego projektu tylko dlatego, że „tak się nie robi”.
Na co uważać: Wyższy poziom to większe ryzyko: trudniejsza dystrybucja, bezpieczeństwo i utrzymanie cudzego kodu, którego nie rozumiesz.
3.„Ludzie techniczni” to niedoceniana grupa odbiorców AI
Na czym polega: To osoby bystre i sprawne z komputerami, które nigdy nie wybrały programowania jako zawodu. Mądrzejsze modele łatają ich braki wiedzy o ekosystemach — model potrafi odpowiedzieć, dlaczego aplikacja tnie, i poprowadzić analizę.
Jak stosować: Jeśli należysz do tej grupy — forkuje, modyfikuj i pytaj model „dlaczego”; jeśli budujesz produkty — projektuj interfejsy i dokumentację pod tę właśnie publiczność.
Na co uważać: Brak zrozumienia fundamentów to gotowy przepis na błędną diagnozę (przykład z przerzucaniem bazy między regionami zamiast znaleźć prawdziwą przyczynę) oraz na koszty i luki bezpieczeństwa.
4.Traktuj utrwalone praktyki jako hipotezy, nie prawa natury
Na czym polega: Pytanie „dlaczego nie commitujemy plików .env?” okazuje się testem kreatywnego myślenia: wiele praktyk istnieje wyłącznie dlatego, że „zawsze tak było”, a nie dlatego, że jest to najlepsze rozwiązanie.
Jak stosować: Przy każdej istotnej decyzji architektonicznej zatrzymaj się i zapytaj: dlaczego to robimy? Bo to słuszne, czy bo tak przywykliśmy? To samo pytanie zadawaj agentowi, gdy proponuje „standardowe” podejście.
Na co uważać: Kwestionowanie nie oznacza odrzucania — sekrety w repozytorium to nadal zwykle zły pomysł; celem jest świadoma analiza, a nie chaos.
5.Obniżaj koszt porażki i ucz się ją wyrzucać do kosza
Na czym polega: Projekty uznawane kiedyś za wielomiesięczne szaleństwa (własny silnik, własny protokół, przepisanie kompilatora) dziś trwają godziny lub dni — ale tylko dla tych, którzy są gotowi je podjąć i porzucić.
Jak stosować: Rzucaj się na śmiałe pomysły z górnolotnym założeniem, że większość wyląduje w koszu; mierz wynik, a nie włożony sentyment.
Na co uważać: Kulturowy nawyk „PR musi zostać scalony” i wyrzuty sumienia przy odrzucaniu cudzej pracy — to one, nie technologia, blokują eksperymenty.
6.Bądź elastyczny co do poziomu abstrakcji
Na czym polega: Theo chce SwiftUI, ale zostaje przy React Native, bo agenci operują na nim szybciej i dochodzą aktualizacje OTA. Wygrywa ten, kto bez żalu porzuca własne preferencje, by szybciej osiągnąć cel.
Jak stosować: Wybieraj stack pod cel i tempo pracy agentów, nie pod osobisty gust; traktuj hierarchię cel > środek jako zasadę, nie wyjątek.
Na co uważać: Elastyczność to nie brak zasad — decyzje wbrew preferencjom muszą mieć mierzalne uzasadnienie (szybkość, koszt, ryzyko).
7.Buduj środowisko pod agentów, nie pod siebie
Na czym polega: T3OS powstaje wbrew gustom autora: headless Ubuntu z Bashem (nie Zsh), bo audyt wykazał, że ponad 30% błędów Claude’a wynikało z różnic w formatowaniu końców linii w Zsh, psujących komendy ripgrep.
Jak stosować: Regularnie przeglądaj błędy swoich agentów i dostosowuj system do ich słabych stron — traktuj środowisko jak interfejs dla AI, który można optymalizować.
Na co uważać: Dostosowanie środowiska nie zastąpi precyzyjnego zadania; agent w „wygodnym” systemie wciąż zrobi głupotę bez dobrego promptu i testów.
8.Dostępność bywa ważniejsza od surowej inteligencji
Na czym polega: Skok nastąpił nie dlatego, że Opus 5.5 jest niebywale mądrzejszy, lecz dlatego, że jeden model — dobrze wyceniony i dostępny w subskrypcji — potrafi wszystko: to obniżyło próg wejścia dla całej grupy użytkowników.
Jak stosować: Przy wyborze narzędzi dla zespołu lub mniej technicznych współpracowników licz całkowity koszt i barierę wejścia, nie tylko wyniki benchmarków.
Na co uważać: „W abonamencie” nie znaczy „za darmo” — limity, throttlingi i koszty przy skali potrafią zjeść oszczędności.
9.Osoby nietechniczne to wciąż pula niezagospodarowanych odbiorców
Na czym polega: Ludzie grający w miksówkę Halo × Call of Duty nie mają pojęcia, jak działa — dostali plik EXE od kumpla, który wszystko ogarnął. Dystrybucja przez zaufanie działa już dziś.
Jak stosować: Jeśli jesteś domowym „magikiem od komputerów” — szukaj problemów rodziny i znajomych, które da się rozwiązać gotowym narzędziem AI albo czymś, co szybko zbudujesz; potem to rozdaj.
Na co uważać: Wysyłanie plików wykonywalnych to naturalny wektor ryzyka — dbaj o aktualizacje, źródło i bezpieczny kanał dystrybucji.
10.Nie zakładaj z góry, że coś jest niewykonalne — zweryfikuj tanio
Na czym polega: Przepisanie całego kompilatora TypeScriptu do Rusta wydawało się fantastyką; zajęło AI mniej niż 20 godzin, a efekt jest 2–3 razy szybszy od TS Go, działa w WASM i osiąga 99,99% zgodności z oryginałem na realnych projektach.
Jak stosować: Zanim odrzucisz pomysł jako niemożliwy, zrób tani, ograniczony w czasie test — koszt weryfikacji „niemożliwości” drastycznie spadł.
Na co uważać: Jeden spektakularny sukces nie znaczy, że wszystko się uda; wymagaj pomiarów na prawdziwych danych i projektach, nie na przykładowych fragmentach.
Redakcyjne tłumaczenie
Dwa razy się myliłem
Powiem wam szczerze: sztuczna inteligencja zrobiła się naprawdę sprytna. Dużo sprytniejsza, niż kiedykolwiek przypuszczałem. Jeszcze dwa lata temu pewien blondyn z wąsem, który jakimś cudem miał dostęp do tego kanału, nagrał film „AI nie będzie już zyskiwać na inteligencji” („AI isn’t going to keep improving”), w którym dość pewnie twierdził, że możliwości modeli wejdą na płaskowyż, a każda kolejna nowość da się coraz skromniejszy zysk. Nagrywałem go, zanim Opus 4.5 trafił nawet do treningu — a tego, ile się od tamtej pory zmieniło, trudno po prostu objąć rozumem. Zaczynało się od autouzupełniania, które od czasu do czasu coś podpowiedziało. Potem mogliśmy zadawać modelowi realne pytania o nasz kod i wskazywać mu pliki do edycji. Dziś wrzucamy mu zrzut ekranu z bugiem i ufamy, że sam go rozwikła, przetestuje i doprowadzi zmiany do scalenia. To nieprawdopodobne.
Ale przy całej tej drodze moje zdanie znów drgnęło — tym razem w przeciwnym kierunku. Z twierdzenia, że AI przestanie się mądrzeć, przeszedłem do tezy śmielszej: może w ogóle nie potrzebujemy mądrzejszych modeli. To uczucie nachodziło mnie przy każdej premierze: jest o klasę lepiej, a ja ledwo nadążam z wykorzystaniem obecnej inteligencji — po co mi cokolwiek mądrzejszego? Tak miałem z Fable 5. A potem wyszedł Opus 5.5 i wybił mi to z głowy. Nie dlatego, że lepiej wykonuje moją codzienną robotę, że jest szybszy albo tańszy — dlatego, że jest mądrzejszy. I nie sądzę, że to dobra wiadomość wyłącznie dla programistów; zyska na niej znacznie szerszy krąg ludzi, niż bym przewidział. Kiedyś zakładałem, że z postępu skorzysta wąska grupa siedząca na samym przedzie i wyciskająca z narzędzi maksimum. Myliłem się. A powód tej zmiany zdania jest błahszy, niż myślicie.
Halo spotyka Call of Duty
Tak — chodzi o Halo i Call of Duty. Chętnie przyznam, że mam słabość do wszystkiego, co związane ze skateboardingiem, ale moim zdaniem te miksówki zwiastują coś większego: rosnące możliwości modeli odczują na sobie znacznie liczniejsi ludzie niż sami deweloperzy. (Informacja dodatkowa: „miksówki” to fanowskie projekty łączące mapy, mechaniki i grafikę różnych gier; ostatnio powstają dzięki dekompilacji i przepisywaniu silników, w czym coraz mocniej pomaga AI.) Zaraz wytłumaczę, dlaczego na tym zyskają wszyscy — po krótkim słowie o dzisiejszym sponsorze.
Sekcja sponsorska: Browserbase, czyli trzecia era agentów
Wiem, że to ma być reklama, ale zacznę od krótkiej lekcji historii. Kiedy AI zaczęło przyciągać uwagę, służyło do odpowiadania na podstawowe pytania na podstawie własnej wiedzy. Bardzo szybko doszliśmy do etapu, w którym za pomocą narzędzi takich jak Claude Code edytowało się pliki na naszych komputerach. Uważam, że wchodzimy właśnie w trzecią erę — erę, w której agenci nie będą zamknięci w ramce strony internetowej ani w naszym komputerze, tylko zaczną wykonywać dla nas prawdziwą pracę. Żeby to było możliwe, muszą umieć wyjść do sieci i tam działać, a więc potrzebują platformy, która im to umożliwi.
Dzisiejszym sponsorem jest Browserbase i mówię wam — szkoda, że nie korzysta z niego żaden z moich asystentów osobistych. Powodów, dla których uważam tę platformę za najlepszy sposób na działanie agentów w internecie, jest sporo, ale zacznę od tego, który doprowadza mnie do białej gorączki, im mocniej wkręcam się w Grok Bota: logowania. Gdy chcę, żeby mój Grok Bot dotarł do usługi, dla której nie ma wtyczki, muszę pozwolić mu postawić maszynę w chmurze, otworzyć ją samemu, wejść na stronę i zalogować się. Gdyby korzystali z Browserbase, podpiąłbym konto 1Password i temat zamknięty. Platforma ogarnia nie samo logowanie, ale też zarządzanie sesjami i ich utrwalanie — agent nie loguje się od nowa przy każdym zapytaniu. Wiem, że brzmi to drobno, ale nie macie pojęcia, jak bardzo inni to psują, w tym wielkie laboratoria we własnych narzędziach asystujących.
To wszystko dotyczy świata po zalogowaniu, ale duża część pracy agenta to szukanie rzeczy w sieci i dostęp do nich. Dlatego tak przydaje się search API, które zwraca wyniki, których agent może potrzebować, oraz fetch API, zamieniający te wyniki i strony na HTML, JSON albo Markdown. To działa o niebo pewniej niż curl — wszak 85% API w sieci jest przez curl nieosiągalnych. To wszystko składa się w naprawdę potężne doświadczenie. Uwolnijcie swoich agentów i zobaczcie, na co ich stać, pod toydev.link/browserbase.
Najpierw najprostsze: deweloperzy produkują więcej i szybciej
Mógłbym cały dzień siedzieć i patrzeć, jak moje ulubione gry z dzieciństwa są dekompilowane, rozkładane na części i składane w szalonych konfiguracjach — ale to naprawdę tylko czubek góry lodowej. Widzę teraz, że sprawa sięga znacznie dalej, niż kiedykolwiek zgadywałem, zwłaszcza dla ludzi, którzy niekoniecznie są inżynierami. Trochę głupio, że dopiero te składanki uświadomiły mi, że na mądrzejszych modelach zyskują wszyscy — ale w mojej głowie wtedy kliknęło.
Jest kilka spojrzeń na tę sprawę. Najbardziej oczywisty znamy wszyscy od dawna: mądrzejsze modele pozwalają deweloperom robić lepszy software szybciej. To działa, szczerze mówiąc, od mniej więcej czasów Sonnet 4 — AI pozwala przejść przez roadmapę i plany szybciej i dostarczać użytkownikom to, czego chcą, skuteczniej niż kiedykolwiek. A wraz z kolejnymi poziomami możliwości modeli to, co jest w stanie dokonać jeden deweloper, rośnie lawinowo. Dziś wypuszczam więcej kodu w tydzień niż przez cały zeszły rok. Głowa mała.
I wiem, że zaraz posypie się: „to wszystko slop, wygenerowane śmieci”. Ludzie, po prostu się mylicie. Połowa kodu, który pisze dla mnie AI, jest lepsza niż wszystko, co niejeden z was stworzył w życiu — jeśli naprawdę tak myślicie. Niebezpiecznie daleko zaszedł postęp tych narzędzi w podejmowaniu dobrych decyzji i odprawianiu prawdziwej roboty. Ale przy całym tym zachwycie wciąż zakładamy, że użytkownik ma doświadczenie — bo bez niego trudno wycisnąć z tych narzędzi maksimum.
Deweloperzy mogą więc więcej, a kiedy budują lepszy software, korzystają na tym wszyscy — bo zyskują programy, których wcześniej po prostu nie opłacało się budować.
Lawn, czyli 1,3 miliarda dolarów odtworzone w kilka dni
Głupi przykład z mojego podwórka: zbudowałem usługę o nazwie Lawn. Korzystałem z Frame.io i coraz bardziej mnie drażniło, jak wolno działa, ile kosztuje, jak bardzo zaczyna pachnieć Adobe i jak uciążliwe bywa wysłanie marka jednego linku do przeglądu materiału. Więc w kilka dni skleiłem własną, otwartą alternatywę — i działa świetnie. Dziś mój zespół robi w ten sposób całą produkcję wideo. Dla skali: Adobe kupiło Frame.io w październiku 2021 roku za 1,3 miliarda dolarów, a ja uczciwie oceniam, że mamy około 70% funkcji, jakie produkt miał w chwili przejęcia, plus mnóstwo dodatków, których oni do dziś nie mają. To, co niedawno uchodziło za produkt wart 1,3 miliarda, na początku roku odtworzyłem i otworzyłem źródła — bo czemu nie. Niemal bez wysiłku. Szalone, jak opłacalne stały się takie przedsięwzięcia, choć jeszcze niedawno były kompletnie nie do pomyślenia. A robiłem to na Gemini 3 Pro i Opus 4.6 — wyobrażacie sobie, ile od tego czasu przeszło?
Nie musiałem przy tym niczego poddawać inżynierii wstecznej, bo logika rdzenia produktu była dla mnie jasna; trudne były integracje i wszystkie zakamarki, które trzeba obsłużyć, żeby to naprawdę działało. I to właśnie program, z którego skorzystało sporo innych ludzi. Nie jest to jakiś gigant, ale kilkaset osób napędza w Lawn swoje potoki wideo dla kanałów YouTube, które oglądamy my wszyscy — co jest bardzo fajne. Ludzie forkuje projekt i budują na nim własne rzeczy. I to był punkt startowy dla kolejnej warstwy.
Ludzie techniczni: sprawni z komputerem, choć nie piszą na życie
Obok profesjonalnych deweloperów zaczęła mnie interesować grupa, którą nazwę „ludźmi technicznymi” — nie ma dobrego określenia, a nie chciałbym nikogo urazić. To ludzie, którzy może trochę bawili się kodem i uznali, że to nie dla nich. Bystrzy, sprawni, po prostu nie wybrali programowania jako zawodu. Ktoś w stylu Linusa z Linus Tech Tips w pewnym stopniu wpisuje się w ten typ. To nie skrypt-kiddies — raczej osoby, które znają się na komputerach i dobrze wyczuwają, co software potrafi, a czego nie, ale nie mają pojęcia, co jest realne do zbudowania ich własnymi rękami.
I w tej grupie tkwi siła, jaką dają mądrzejsze modele — bo jej członkowie nie rozumieją ograniczeń kodu tak jak my. Rozumieją ograniczenia rzeczy, którą kod się tworzy, ale niekoniecznie ograniczeń frameworków, narzędzi i ekosystemów. Jeśli ich aplikacja w Railsach zwalnia, nie wiedzą dlaczego. Usłyszą, że PlanetScale jest szybkie i Railway jest szybkie, odpalą jedno i drugie w różnych regionach — aplikacja nadal tnie, a oni nie rozumieją, o co chodzi. Mądrzejsze modele zaczynają łatać te dziury: można zapytać „dlaczego aplikacja nagle zwalnia?” i model przeprowadzi analizę, która da odpowiedź. Wysoce zmotywowana osoba techniczna, która nigdy nie ogarnęła kodowania, potrafi dziś znacznie więcej. Może sforkować software, od którego zależy. Może debugować systemy daleko wykraczające poza jej rozumienie. Może sklecić skrypt albo sforkować program, a jeśli nie zadziała zgodnie z oczekiwaniami — poprawić i dostroić. Tak jak kiedyś można było otworzyć obudowę komputera i wymienić podzespół, dziś ta sama osoba może otworzyć swój software i coś w nim podmienić. Dawniej mogła z pomocą AI zbudować małą aplikację na własny użytek. Dziś może poprosić AI o sforkowanie narzędzia, z którego korzysta, i dopasowanie go do własnych upodobań. Może poddać inżynierii wstecznej programy codziennego użytku — Codex, ChatGPT czy Discord — i wstrzyknąć JavaScript, zmieniający działanie produktu.
Wszystko to super ekscytujące, ale bardzo osobiste. Nie skalowało się, bo modele nie potrafiły porządnie „opakować” wykonanej pracy tak, żeby inni mogli z niej skorzystać. Mógłeś zrobić fajny plugin do swojego lokalnego Discorda, ale rozdanie go innym w bezpieczny sposób było wciąż złożone, ryzykowne i trudne do ogarnięcia. Deweloperzy potrafili budować rzeczy do udostępniania; ludzie techniczni mogli dostosowywać to, czego już używali — ale nie umieli tego przekształcić w produkt i oddać innym. I to jest punkt wyjścia do uporządkowania całości.
Cztery poziomy pracy z AI
Poziom pierwszy: AI pomaga w rzeczach, w których jestem dobry. Edytuję kod i proszę AI o dopracowanie funkcji albo pozwalam autouzupełnianiu poprowadzić kilka linijek. To ja wyznaczam ograniczenia i wokół nich wszystko buduję.
Poziom drugi: AI modyfikuje rzeczy, których często używam. Customizacja codziennego narzędzia, sforkowanie biblioteki i drobne poprawki pod swoją robotę — wciąż bardzo osobiste: to, co buduję z AI, nie opuszcza mojej bańki. Ten poziom obejmuje też prywatne rozszerzenie do Chrome, skrypt zmieniający działanie Discorda pod ciebie, osobistych asystentów AI. Pozwalam modelowi trochę więcej — wchodzi na obszary, których słabiej znam — ale wciąż jesteśmy zamknięci w moim kręgu i moim software.
Poziom trzeci zaczyna się tam, gdzie AI buduje rzeczy, których ja w pełni nie rozumiem. Mam kilka projektów w Ruście — a nie piszę w Ruście. Ledwo rozumiem ten język, trochę się nim bawiłem, uważam go za nużący i irytujący — a jednak prowadzę w nim sporo projektów, nawet jeśli to nie ja piszę kod. I mogę je rozdawać: wiele z nich wkrótce trafi do prawdziwych użytkowników.
A na samym końcu jest nowy, właśnie odblokowany poziom, na który można tylko westchnąć: kurczę — można tym dekompilować, rozkręcać inżynierię wsteczną i przebudowywać od nowa rzeczy istniejące w świecie, aż do samego rdzenia. Rzeczy w zasadzie niemożliwe do zrozumienia. Nikt w pełni nie ogarnia zdekompilowanej bazy kodu Super Mario 64 — to po prostu nie jest wykonalne dla człowieka. I jest w tym magia, naprawdę niebywała, że te narzędzia potrafią zbudować wystarczająco dobre rozeznanie czegoś takiego, żeby w tym operować.
Krótka historia skoków: od pierwszego Copilota do Astry
Warstwy porobiłem celowo, bo każdy skok jakości modeli dotyka różnych grup w różnym stopniu. Gdy kodowanie z AI raczkowało z pierwszym, jeszcze pierwotnym Copilotem, pomagał deweloperom w rzeczach, w których byli dobrzy — a ludzie techniczni w tym ujęciu nie mieli nic. Mogli pytać i dostawać odpowiedzi, jasne, ale jeszcze niczego nie budowali.
Potem modele się poprawiły — do punktu, w którym potrafiły użyć narzędzia i edytować kod. Wtedy nastąpiło przesunięcie: ludzie techniczni mogli customizować swoje strony domowe, grzebać w witrynach na Wixie i tym podobne. Deweloperzy nagle mogli modyfikować narzędzia swojej codziennej pracy, edytować pakiety, od których zależą, wprowadzać prawdziwe, wieloplikowe zmiany w bazie kodu.
Potem modele znowu zyskały. Wyszedł Opus 4.5 i wszystko znów się przesunęło. Ludzie techniczni nagle byli w stanie budować całe, w miarę działające aplikacje. Znalazły się osoby, które miesiąc wcześniej w ogóle nie kodowały, budujące benchmarki, których nie umiały przeczytać, do rzeczy, których nie rozumiały. Deweloperzy mogli zejść głębiej — to wtedy wielu z nas zaczęło budować gry jako projekty poboczne, przenosić biblioteki, automatyzować procesy dekompilacji.
Potem modele znów się poprawiły. Przy Fable 5, a później Astrze, skok dla deweloperów był natychmiastowy i ogromny, ale dla ludzi technicznych wyraźnie skromniejszy — i pomyślałem, że w pewnym sensie to może być koniec. Że przepaść między niekodującymi ludźmi technicznymi a deweloperami z całym bagażem wiedzy będzie rosła bez końca.
Opus 5.5: mniej nowych możliwości, więcej dostępności
A potem przyszedł Opus 5.5. Najciekawsze w nim jest to, że wcale specjalnie nie poruszył mojej własnej pracy z AI. Robię dziś znacznie więcej, ale nie odblokował mi wielu nowych rzeczy, których nie mógłbym poskładać z innych narzędzi. Za to sam fakt, że istnieje jeden model, który potrafi to wszystko, jest dobrze wyceniony i dostępny w abonamentach, wprowadził ludzi technicznych głęboko na poziom budowania rzeczy, których nie rozumieją. Są dziś ludzie, którzy nigdy nie kodowali, nigdy nie otwierali Blendera — a za pomocą subskrypcji Claude’a za 200 dolarów miesięcznie przenoszą mapy ze swoich starych, ulubionych gier do nowych tytułów, na podstawie dekompilacji. To chore.
Pozostaje jeszcze jedna grupa: osoby nietechniczne. One na tym pociągu jeszcze nie podjechały tak mocno. Ale to właśnie okazja dla ludzi z pozostałych grup. Jeśli to ty przez lata naprawiałeś mamie komputer, możesz odkrywać coraz więcej jej problemów, które da się rozwiązać — pokazując jej narzędzie AI albo budując dla niej coś użytecznego. Możesz też zacząć modować gry w sposób, którego z tej pozycji kompletnie nie ogarniasz — i dzielić się modami ze znajomymi. Jestem pewien, że masa ludzi grających w tę składankę Halo i Call of Duty nie ma pojęcia, jak ona działa. Dostali plik EXE od kumpla, który wszystko zrozumiał — a tacy ludzie techniczni mogą się dziś dzielić ze znajomymi o wiele fajniejszymi rzeczami.
Ostra teza: deweloperzy nie są kreatywni
I tu wchodzi moja najostrzejsza teza. Musimy porozmawiać o deweloperach, bo mam gorzką prawdę, przy której wielu z was potrzebuje przebudzenia.
Nie jesteśmy specjalnie kreatywni. I im bardziej sądzisz, że jako deweloper jesteś kreatywny, tym większa szansa, że generalnie masz naprawdę złe pomysły. Deweloperzy nie są dobrzy w większości rzeczy poza dostarczaniem kodu. Taka jest rzeczywistość. Mój kanał jest popularny nie dlatego, że jestem super inteligentny albo świetny w brandingu i clickbaitowych miniaturkach, tylko dlatego, że jestem może szóstką z dziesięciu w komunikacji — w przestrzeni, gdzie średnia to trójka. Dlatego mówi się mnie słucha niż przeciętnemu deweloperowi opowiadającemu o tych samych sprawach. I dlatego tyle zespołów programistycznych zatrudnia nietechnicznego projektanta i product managera, którzy nie mają pojęcia o kodzie, a dostają ponad sto tysięcy dolarów rocznie. Bo są nam potrzebni — bo nam brakuje smaku i kreatywności, by zrobić cokolwiek ponad spięcie dwóch bibliotek w nowatorski sposób. Nie jesteśmy w tym dobrzy.
A tu dochodzi przyprawa: ludzie techniczni, którzy nie kodują, są w tym z konieczności całkiem niezłi. To oni zakochali się kiedyś w Zapier, bo nie wiedzieli, jak działają API i webhooki, więc tymi narzędziami zmuszali rzeczy do współpracy w sposób, który nie miał żadnego sensu. Widziałem konfiguracje OBS, które bolały mózg, bo były tak daleko od tego, jak program został pomyślany. Znam osobę, która ma ponad czterdzieści tysięcy scen w OBS — używa ich wszystkich jako dynamicznych warstw, które się łączą i nakładają, tworząc szalone, zmienne ustawienia w sytuacjach, które sama wymyśla. Widziałem niebywałe rzeczy. I to wszystko jest dziwne, twórcze myślenie. Tym ludziom nagle ktoś zdjął pęta.
I ekscytuje mnie, co się wydarzy, gdy ludzie, którzy nie rozumieją, jak to wszystko działa — którzy nie mają wpojonego, że gra zrobiona na IW4 nie powinna działać w tym samym silniku co gra na UE3, ani na czym tam gotowało EA w tamtych czasach — zaczną z tym robić rzeczy. (Informacja dodatkowa: IW4 to silnik serii Call of Duty z tamtych lat, UE3 — Unreal Engine 3; obie technologie były niekompatybilne.) Ludzie bez tego mocnego, fundamentalnego przekonania, że „te rzeczy są różne, więc nie da się ich łączyć” albo że „tak to działa, bo tak działało przez dwadzieścia lat”. To wszystko jest dla nas trudne do ogarnięcia.
„Dlaczego nie commitujemy plików .env?”
I wiem to z powodu naprawdę głupiego: z mojego najpopularniejszego shorta.
„Dlaczego nie dodajemy plików środowiskowych do repozytorium? Brzmi głupio, kiedy stoi to na slajdzie, ale chcę, żebyście pomyśleli chwilę. Kiedy mam zespół inżynierów pracujących nad projektem, dlaczego muszę budować osobny system do dzielenia się tym jednym konkretnym plikiem, skoro wszystkie pozostałe przechodzą przez gita bez problemu? Musimy się cofnąć i zadać sobie pytanie: robimy tak, bo tak jest słusznie — czy dlatego, że zawsze tak robiliśmy?”
(Informacja dodatkowa: pliki .env przechowują konfigurację i sekrety, np. klucze API; konwencja zabrania ich wersjonowania, stąd zdziwienie autora reakcją na to pytanie.)
Puściłem tego shorta, bo nauczyłem się, że ta teza jest — nie chcę mówić „testem inteligencji” — raczej ćwiczeniem z kreatywnego myślenia dla inżynierów, którzy nie są dobrzy w kreatywności, a często nie są też dobrzy w myśleniu. Wspomniałem o tym w moim wystąpieniu na AI World Fair, bo chcę, żebyśmy jako inżynierowie zaczęli rozplątywać głęboko zakorzenione przekonania. Czas się zatrzymać i przyjrzeć się temu, co robimy i dlaczego. A jeden z najlepszych sposobów to wpuścić ludzi z zewnątrz, którzy powiedzą: „to nie ma sensu” — i zrobią inaczej, bo nie wiedzą, że „się nie da”.
W muzyce dzieje się to od lat: jakiś dzieciak z odległego kraju polubi coś, co usłyszał gdzie indziej, i zrobi własną wersję — a zanim zauważą ją ludzie z kultury źródłowej, jest już tak dopracowana, że trudno w niej znaleźć dziury. Wchodzimy właśnie w taką erę w software: ludzie, którzy nie mają pojęcia, co robią, przyniosą pomysły, które dla nas nie mają sensu, bo my inżynierujemy od ponad dwudziestu lat, a te dzieciaki nie wiedzą, czym Java różni się od JavaScriptu — i zrobią rzeczy naprawdę fajne i zaskakująco potężne, bo nie wiedzą, że o takie rzeczy nie wypada prosić.
I wiem, że jako inżynierowie nie będziemy w tym dobrzy — bo mam sekcję komentarzy. „Dlaczego nie mogę wrzucić zdjęcia swojej karty do Twittera?” — „Co to za technologiczna zgnilizna mózgu?” — „Saga tonącego Theo trwa. Koleś dopiero odkrywa, że mydła istnieją.” — „Mogę ci podać kilka powodów: rozdzielenie pozyskiwania kluczy.” — „Czasem w firmie chcesz zobaczyć kod kolegi, ale nie możesz go uruchomić.” — „Zakładasz, że wszystko działa tak jak dziś.” Chodzi mi o to, że model, w którym repozytorium daje każdemu z dostępem wszystkie pliki, może wcale nie być właściwym sposobem zarządzania kodem źródłowym. A ten komentarz od Shiva po prostu kocham: „O, chcesz, żebym pomyślał? Nie, za dużo. Jestem software inżynierem, człowieku.” — „Właśnie, nie płacę ci za myślenie. Płacę ci za pisanie kodu.” — „Zgarnąć cały ocean? Przecież my nawet oceanu nie umiemy znaleźć.”
Mówię o tym, bo myślę, że deweloperzy tacy jak wy będziecie sobie radzić świetnie — bo jest mnóstwo deweloperów-kreatywnych dziwaków robiących z kodem dziwne rzeczy, którzy z różnych, zwykle głupich powodów nie mogli znaleźć pracy. To się bardzo zmieniło. Ludzie wysoce zmotywowani, z odrobiną wyobraźni i gotowością rzucenia się na rzeczy, których w pełni nie rozumieją, będą w tej erze absurdalnie hojnie nagradzani. Im mniej jesteś przywiązany do tego, jak wszystko musi działać dzisiaj, tym łatwiej wyjdziesz z utartych ścieżek i wymyślisz coś bardziej unikalnego. A gdy coś nie działa, możesz pytać i dociekać dlaczego.
Prosty sposób ujęcia tego, który naprawdę lubię — z czatu, od użytkownika chorus: „Najpierw próbuj zrozumieć »dlaczego«, a nie »bo«”. Bo mnóstwo praktyk w programowaniu to w gruncie rzeczy właśnie „bo”: narzędzia tak działały od zawsze, a zmiana byłaby za droga. Kompilatory pisane w jednym języku — przeniesienie w inny to za dużo wysiłku, czasu i ryzyka, a utrzymanie synchronizacji się nie spina. Aplikacje pisane w jednym języku, których nie opłaca się przenosić w drugi, bo to drogie. Albo sprzęt audio, który cię wkurza: technicznie rzecz biorąc, gdybym poświęcił od kilku miesięcy do kilku lat, mógłbym zdekompilować mojego Rodecastera i napisać własny firmware. Zajęłoby mi to bardzo, bardzo długo. Dziś takie rzeczy są znacznie bardziej w zasięgu — próg wysiłku i doświadczenia potrzebny do tych szalonych wyczynów jest o wiele niższy.
„PR-y się scala” — nawyk, który trzeba rozmontować
I robiłem takie rzeczy, zanim AI mogło mi pomóc. Rzucałem się na śmiałe pomysły: własny stack technologiczny, własny silnik gier (co, co oczywiste, nie poszło tak dobrze jak pozostałe), własny protokół dla serwerów STUN w WebRTC, by poprawić jakość połączeń bez narzucania opóźnień. Prowadzę takie szalone misje przez większą część kariery. Teraz te eksploracje są znacznie tańsze i dostępniejsze — więc trzeba być gotowym w nie wchodzić. I trzeba być gotowym na to, że się nie uda.
A tu widzę, że wielu deweloperów radzi sobie gorzej. Przywykli pracować w systemach, które znają — choćby nie w pełni — i przywykli do porażek, ale takiego rodzaju: zmieniam pięć linii, nie działa, zmieniam jeszcze kilka razy. Tak rzadko się zdarza, żeby PR dewelopera ostatecznie nie wszedł, że prawie czujemy się niezręcznie. Kto z was scalał PR-a, bo żal było odrzucać — wiedząc, że autor naprawdę się napracował? Ja wiem, że ja. Niech czat pokaże jedynki, jeśli kiedykolwiek scaliliście coś z wyrzutów sumienia. Widzicie?
Dzieje się tak, bo wyrzucać czyjąś pracę jest przykro — ale też przyzwyczailiśmy się, że celem wystawienia PR-a jest jego scalenie. I to kulturowe przyzwyczajenie musimy zaczynać rozmontowywać.
Bądźmy szczerzy. Profesjonalny deweloper z wieloletnim stażem spędza dwie godziny nad czymś „slopowym” — PR na dwa tysiące linii. Osoba techniczna, nie-deweloper, spędza nad tym samym pięć godzin i wystawia niemal identyczny PR. Komu będzie przykro, kiedy go zamkniesz, bo nie chcesz tego w produkcie? Inżynierowi, który spędził dwie godziny, czy osobie technicznej, która spędziła pięć? Myślę, że wszyscy znamy odpowiedź: oczywiście inżynierowi. Wyżej ceni swój czas. Ma oczekiwania. Przywykł, że jego PR-y wchodzą. Jeśli umie zrobić tydzień pracy w dwie godziny, wystawiany PR i tak „waży” tamten tydzień — i kiedy go nie scalisz, czuje się tak samo jak kiedyś. Ludzie techniczni, którzy wcześniej nie kodowali, tego bagażu nie mają — ale nie mają też oczekiwań. Nie wchodzą w projekt z myślą, że to zadziała i trafi do produktu. Wchodzą dla frajdy. I ta różnica oczekiwań na starcie pozwoliła im ostatnio robić niebywałe rzeczy.
Przepis na tę erę: pytaj „dlaczego” i pozwól rzeczom umrzeć
Chcę przez to powiedzieć: musimy jako deweloperzy trochę zejść z piedestału. Musimy być skłonniejsi cofnąć się i podważać. Musimy mniej przeżywać, kiedy to, co zrobiliśmy, nie działa i powinno pójść do kosza. Musimy zadawać więcej pytań — agentom i sobie — co budujemy, dlaczego to budujemy i co można zrobić inaczej. Musimy być odrobinę bardziej skłonni rzucać się na absurdalne, wielkie rzeczy, które „nie mają sensu”.
Pamiętam, że jeszcze kilka miesięcy temu mój szalony projekt — przepisanie całego kompilatora TypeScriptu do Rusta — wydawał mi się świętym Graalem AI, o którym można było co najwyżej pomarzyć. Może kiedyś, w odległej przyszłości, AI zrobi w tym choć krok. Tymczasem nie tylko zadziałał w niecałe dwadzieścia godzin — jest teraz dwa, trzy razy szybszy od TS Go, a co najważniejsze dla mojego prawdziwego celu: działa w WASM. (Informacja dodatkowa: typescript-go to oficjalny port kompilatora TypeScriptu napisany w Go, rozwijany pod szyldem Microsoftu.) Nie sądziłem, że ten projekt kiedykolwiek realnie się uda. W najlepszym razie przeszłaby pojedyncza kompilacja, tu i ówdzie. Dziś działa na wszystkich realnych projektach, na których mi zależy, z zgodnością 99,99% względem innych wersji TypeScriptu. I nie chcę ciągle wyciągać czatu, ale użytkownik raging powiedział, że gdy zaczynałem, tak mocno się ze mnie naśmiewali, bo nigdy nie uwierzyli, że to zadziała. Dlatego w ogóle go zacząłem — jako próbę wymyślenia czegoś, czego AI nigdy nie dokona. A teraz wydaje mi się za prosty. No jasne, że AI potrafi przepisać znany cel, jak skompilowaną aplikację, w innym języku. Ale kilka tygodni temu wydawało się to niewykonalne. Głowa mała, jak wiele się zmieniło. A ja nawet nie myślę wystarczająco śmiało — choć to moja robota: myśleć zbyt śmiało, żeby mieć z czego robić filmy.
Podoba mi się takie ujęcie z czatu, od Game Mechanica: „Jestem software inżynierem i inżynierem systemów, a moja gorąca teza: większość deweloperów jest całkiem zadowolona, pisząc w kółko tę samą listę wiązaną, którą każdy inny napisał przed nimi. Nie lubią zróżnicowanej pracy. Jako inżynier systemów irytuje mnie pisanie kodu, który już został napisany. Wygrają ci, którzy potrafią pracować na wyższych poziomach abstrakcji i nie przejmują się niskopoziomowymi szczegółami.” Zgadzam się niemal w całości. Zmieniłbym jedno: najbardziej skorzystają ludzie elastyczni co do poziomu, na którym pracują — czasem nisko, czasem wysoko. Ci, którzy potrafią wyrzucić przez okno własne preferencje, żeby zrobić coś lepiej pod swój cel. Macie pojęcie, ile decyzji technicznych w moich projektach podjąłem wbrew pierwszej preferencji — bo to była najszybsza droga do celu? Szczerze chcę przejść naszą aplikację mobilną na przepisaną wersję SwiftUI, ale tempo, w jakim agenci operują na aplikacji React Native, aktualizacje OTA i wszystko, co Julius i Jay zrobili, by wydajność nie tylko dorównywała, ale w wielu miejscach przewyższała — sprawiają, że raczej nie wydam wersji, którą wolę, choć technicznie jest bardziej wydajna. Bo zasoby agentów, tokenów i czasu idą w co innego.
Elastyczność zamiast sentymentu — i system zbudowany dla agentów
Albo przykład głupszy: mój park maszynowy. Może zauważyliście, że niektóre pudełka dostały nowy system operacyjny. Wyobrażalibyście sobie, że T3OS będzie pełen moich opinii. No właśnie: jeśli go wydam, nie będzie wyglądał tak, jak myślicie — bo nie ma w nim ani jednej z moich opinii. Nie robię tej dystrybucji po to, żeby spełniała moje zachcianki. Robię ją tak, żeby nie miała nic z tego, czego ja chcę. Jest zaprojektowana pod to, czego potrzebują agenci. T3OS po starcie nie ma interfejsu graficznego — jest headless — ale potrafi podnosić środowiska graficzne, forki XFCE, do użytku przez agentów, z kontrolą na poziomie sterowników, tak żeby każdy wątek agenta miał własny pulpit do pracy z interfejsem graficznym (computer use). Działa na Bashu zamiast na Zsh czy Fish, bo choć wolę Zsh — bardzo wolę Zsh — niedawno przeaudytowałem wszystkie błędy moich agentów i ponad 30% błędów, w jakie wpada Claude na moich maszynach, wynika z tego, że Zsh odrobinę inaczej formatuje znaki nowej linii, przez co Claude krzywo składa komendy ripgrep. Nauczyłem się też, że moi agenci gorzej radzą sobie z Archem i CachyOS jako maszyną deweloperską. I choć wolałbym prowadzić wszystko na Cachy — zaakceptowałem, że to nie najlepszy wybór do wielu zadań i wielu maszyn. Więc robię teraz takiego nie-do-końca forka Ubuntu: mocno dostosowany obraz Ubuntu, szyty na miarę agentów, nie mnie.
To ciekawe rozdwojenie: z jednej strony schodzę głębiej, bo customizuję system operacyjny, a z drugiej płycej — bo decyzje podejmuję nie dla siebie. Elastyczność w górę i w dół całego spektrum głębokości. Bo nie buduję produktu dla siebie — tak bym to ujął. Nie buduję T3OS dla siebie. Buduję go dla moich agentów, żeby mogli budować rzeczy dla mnie.
I jeśli jako deweloperzy nie będziemy skłonniejsi tak myśleć, nie tylko przestaniemy korzystać na mądrzejszych modelach — ci ludzie techniczni, którzy nie mają w głowach tych samych barier, przyspieszą daleko przed nas. Ta osoba, która irytowała cię w liceum, bo na wszystko odpowiadała „zainstaluj Ubuntu”, choć nigdy nie programowała — ta osoba wyprzedzi was o kilka długości, jeśli nie uważacie.
Zakończenie: jesteśmy bardzo, bardzo wcześnie
Mówię to wszystko, bo się myliłem. Miałem głupie przekonanie, że modele zaczną produkować rzeczy tak złożone, że zrozumieją je wyłącznie deweloperzy, a ludziom technicznym wyrwie się grunt. I okazuje się, że ta sama wiedza, która czyniła nas sprawniejszymi w operowaniu Opusem 4.5, a później Fable, zaczyna nas hamować.
A co się stanie, kiedy to wszystko dotknie ludzi nietechnicznych? Nie mam pojęcia. Mi po prostu płacą za gadanie o kodzie, ludzie. A tak na poważnie: za dużo o tym myślałem i chciałem wyrzucić te myśli z głowy, bo zmiany postępują szybciej, niż zakładałem, i wciąż nabierają tempa. Okazuje się, że model, który potrafi napisać własny kompilator, jest użyteczny dla ludzi, którzy chcą przepisać swoje stare, ulubione gry. Nigdy nie sądziłem, że tak zdolny model przyda się moim znajomym z liceum — ale też nie sądziłem, że ktoś będzie przepisywał swoje ulubione gry z Xboxa 360 z dekompilowanych portów do Rusta z Bevy i sklejał je ze sobą.
Jesteśmy na samym czubku tej szalonej góry lodowej i mam nadzieję, że jesteście gotowi na nadciągającą przyszłość. Bo, mówię wam, nie zwolni. Chcę powiedzieć jedno: myliłem się, dużo to przemyślałem i wiem, że wielu z was myśli dokładnie tak, jak ja myślałem zaledwie kilka tygodni temu. Mam nadzieję, że ten film przekona was, żeby na nowo przemyśleć, dokąd te modele zmierzają i kto będzie mógł z nich korzystać — bo mnie to, co potrafimy dziś, rozbraja. Za każdym razem, kiedy dostaję wiadomość od starego kumpla z liceum albo od kogoś, z whom robiłem kiedyś rzeczy przy inżynierii dźwięku, z pokazaniem szalonych projektów budowanych z pomocą AI — uświadamiam sobie, że wciąż jesteśmy bardzo, bardzo wcześnie. A tam, dokąd zmierzamy, będzie naprawdę, ale to naprawdę fajnie.
To tyle, co miałem. Dajcie znać, co myślicie — i do następnego razu.
Naraz, nerdzi.