Twórca agenta Pi o swoim warsztacie inżynierii agentowej (oryg. Pi Agent dev reveals his Agentic Engineering Workflow)

O czym jest ten film

1. Dlaczego Pi — opakowanie agenta oparte niemal wyłącznie na bashu — wygrywa porównania z Claude Code i Codexem: model sam łączy polecenia w potoki i oszczędza kontekst.
2. O przyszłości „harnessów” decydują dane treningowe i to, co da się wytrenować metodą wzmacniania; nowe możliwości modeli (np. komunikaty systemowe wtrącane w rozmowę) otwierają dotąd niedostępne wzorce.
3. Historia przejęcia Pi: wszystko zaczęło się od rozmów z twórcą projektu, Mario Zechnerem; celem firmy nie jest „bycie firmą od opakowań”, lecz AI działające dla wszystkich.
4. Metafora DOS-a: dzisiejsze agenty to wczesna, niewygodna forma tego, czym kiedyś będzie interfejs AI — za cztery lata nie będziemy pracować z nimi w obecnej postaci.
5. Braki do uzupełnienia: przenośność sesji (kompresja po stronie serwera zamyka w ekosystemie), trwałość agentów, pełnoprawne interfejsy w przeglądarce i dostęp agentów do baz danych zamiast „pamięci”.
6. Dlaczego nie trzeba czekać na przełom w AI: agenty taniej obsługują złożoność, więc wzrośnie popularność Rusta, NixOS czy Kafki — to klasyczne problemy architektury, nie inteligencji.
7. Człowiek zostaje w pętli: gospodarkę napędzają ludzie, odpowiedzialność wymaga winnego (banki nie będą „vibe code’ować”), stąd wygrywa Markdown, JSON i uniksowe potoki — to, co czyta człowiek.
8. Warsztat Armina: praca lokalna na własnych maszynach, SSH, GitHub Actions; chmurowe środowiska potrafią zamockować Postgresa tak, że testy bazodanowe nigdy tak naprawdę nie działały.
9. Krytyczny bilans AI: koszty i liczba commitów rosną szybciej niż wymierne wyniki firm; projekty poboczne odnoszą dziś więcej sukcesów niż firmowe wdrożenia na masową skalę.
10. Open source i Europa: otwarty kod to dziś marketing, darmowa infrastruktura i droga do danych treningowych; dobre projekty ocenia się dopiero po 10–15 latach; Europa przegrywa przez brak jednolitego rynku i wyjazdy zmotywowanych.

Redakcyjne tłumaczenie

(Informacja dodatkowa: gościem jest Armin Ronacher — twórca frameworka Flask i współzałożyciel Sentry, dziś prowadzący firmę rozwijającą Pi, minimalistyczny agent do programowania autorstwa Mario Zechnera. Transkrypcja automatyczna zniekształca część nazw własnych, m.in. nazwisko gościa i nazwę jego firmy.)

David Ondrej: To Armin Ronacher — twórca Flaska, dziś stojący na czele firmy odpowiedzialnej za agenta Pi. Rozmawiamy o tym, dlaczego Pi wygrywa z Claude Code i Codexem, o jego własnym setupie do inżynierii agentowej i o tym, jak budować dobre oprogramowanie w czasach, gdy kod pisze AI. To podcast Davida Ondreja. Zapraszam.

Dlaczego minimalizm wygrywa

David Ondrej: Zacznijmy od Pi i tego, dlaczego wygrywa ono w tylu testach i porównaniach opakowań, choć jest jednym z najbardziej minimalistycznych na rynku. Skąd ten wynik?

Armin Ronacher: Same modele coraz lepiej radzą sobie z obsługą komputera, a Pi w gruncie rzeczy daje modelowi po prostu basha. Opakowania w ogóle coraz lepiej ogarniają podstawy i z czasem robiło się to coraz oczywistsze. W pewnym momencie Pi było tu może na przedzie, ale dziś to raczej standard. Dobry przykład: Codex pokazuje, że „odkrywa” pliki, ale w praktyce niewiele narzędzi mu zostało — jako opakowanie również opiera się na bashu, a szukając plików po prostu woła ripgrep. Poleganie na bashu sprawdziło się bardzo dobrze, i to z konkretnego powodu: zamiast wciągać wszystko do kontekstu, można łączyć polecenia w potoki. W jednym poleceniu model znajdzie pliki i od razu doda znaczniki oddzielające, żeby wiedzieć, gdzie kończy się wynik pierwszego programu, a zaczyna drugi. Jak się przyjrzeć, jak te komendy faktycznie powstają, widać sporo pomysłowości w oszczędzaniu kontekstu.

David Ondrej: I dokąd to zmierza? Za sześć, dwanaście miesięcy modele będą schodzić na coraz niższy poziom?

Armin Ronacher: Już rok temu czułem się w miarę pewnie, przewidując, że tak to pójdzie — bo o przyszłości mówi nam to, gdzie są dane treningowe i co da się łatwo wytrenować metodą wzmacniania. Teraz, gdy temat trafił do centrum uwagi — gdy agenty do kodu przestały być „jednym z podejść do AI”, a stały się podejściem — na chwilę zrobiło się to mniej klarowne, bo same laboratoria zaczną się ścigać też o wprowadzanie innych danych treningowych. Jednocześnie wszystkie konkurują na tym, by być naprawdę dobrymi agentami programistycznymi, i w podstawowym pomyśle na wywoływanie narzędzi specjalnie się od siebie nie różnią. Widzimy natomiast zmiany w warstwie inferencji, które mogą zapowiadać inne podejścia. Największa, jaką zauważyłem: w wielu czołowych modelach można teraz wtrącać komunikaty systemowe w trakcie rozmowy, co pozwala m.in. na opóźniane ładowanie narzędzi. To nie rewolucja w pisaniu opakowania, ale zmiana na tyle znacząca, że stają się możliwe wzorce, które wcześniej nie były. Nie sądzę jednak, żeby radykalnie odmieniła to to, czym wszyscy się na co dzień zajmujemy.

Przerwa sponsorska: PostHog

W połowie odcinka pada blok sponsora. (Informacja dodatkowa: sekcja reklamowa, ujęta skrótowo.) Prowadzący przypomina, że najczęstszy błąd nowych założycieli to za mało informacji zwrotnych od prawdziwych użytkowników — im szybciej budujesz dzięki AI, tym ważniejsze stają się dane o klientach. PostHog pokazuje, jak ludzie realnie korzystają z produktu: gdzie utykają, których funkcji używają, czy wracają, a dzięki nagraniom sesji można zobaczyć, co użytkownik faktycznie robił. Korzystają z niego m.in. Y Combinator, Supabase, Fireworks AI, ElevenLabs i Railway — Supabase dzięki tym danym zauważyło falę użytkowników pochodzących z narzędzi do budowy aplikacji AI i podjęło z nimi współpracę. Link pod filmem: go.posthog.com/david.

Skąd popularność Pi

David Ondrej: Co sprawiło, że Pi wystrzeliło? Ludzie doceniają możliwość dostosowania i minimalizm, ale przecież cały świat buduje opakowania — co tydzień wychodzą nowe i tempo rośnie. Skąd stosunkowo mała ekipa spoza Doliny Krzemowej utrzymuje się na przedzie? Głębsze przemyślenie? Dobry gust?

Armin Ronacher: Nigdy specjalnie nie analizowaliśmy, dlaczego Pi jest popularne. Nie zajmuję się też tym, by zatrzymać ludzi przy dzisiejszej wersji — bardziej interesuje mnie, dokąd powinniśmy iść i jak to będzie wtedy wyglądać. Ale jeśli pytasz, dlaczego Pi stało się popularne mniej więcej w okresie świąt: pierwsze, na co ludzie się złapali, to rozszerzalność. To był bardzo minimalny agent, ale taki, który można było zrobić swoim. I rozegrało się to w momencie, gdy inni szli w przeciwną stronę — w masywne ilości narzędzi. Pamiętam, że każda aktualizacja Claude Code mocno wstrząsała czyimś przepływem pracy. Teraz widać, że Claude powoli zawraca, bo ma dziś mniej narzędzi niż w szczycie ich nagromadzenia. A OpenCode 2 jest w całości oparty na wtyczkach. Ta idea samorozszerzalnego oprogramowania… Pi było tu może dość wcześnie. Choć szczerze: nie wiem, dlaczego rzeczy stają się popularne. Pi trafiło w niezłą równowagę — i tyle, jeśli chodzi o samo oprogramowanie. Poza tym wyróżniało je pytanie, które chyba wyróżnia też naszą firmę: mamy tu potężną maszynę w postaci modelu językowego — jak sprawić, żeby naprawdę nam służyła? To pytanie o pozycjonowanie. Z jednej strony uważamy, że AI jest świetne, z drugiej żywimy do niego sporo sceptycyzmu i próbujemy balansować między tymi nastawieniami. To chyba bardziej europejski sposób myślenia.

David Ondrej: Przeszedłeś w pełni na Pi w grudniu, a cztery miesiące później przejąłeś projekt. Co zdecydowało? Mario? To, że projekt wystartował?

Armin Ronacher: Z Mario rozmawialiśmy o dołączeniu do zespołu już w lecie 2025 roku. W startupie wyzwaniem przy zatrudnianiu jest często samo to, by w ogóle na siebie wpaść. W wielu sensach pytanie mniej dotyczyło Pi, a bardziej tego: co musimy zrobić, żeby Mario do nas przyszedł? Przynajmniej taka jest moja wersja historii — Mario sporo napisał na blogu o tym, jak dołączył. Nasza firma dziś wygląda jak „firma Pi”, ale to naprawdę nie jest nasz cel. Jeszcze przez jakiś czas pewnie będzie, bo mamy listę rzeczy do ogarnięcia, ale naszą przyszłością raczej nie jest „bycie firmą od opakowań”. Chcemy sprawiać, że AI działa dla każdego. Po prostu musimy zacząć od opakowania.

Dokąd zmierza firma: AI także dla nie-programistów

David Ondrej: Jak to ma wyglądać dalej? Słuchacie ludzi z laboratoriów? Testujecie sami? Jak próbujesz dostrzec, dokąd świat biegnie?

Armin Ronacher: To złożone pytanie… Najprościej: ktoś wpłaca pieniądze w centrum danych i ono powstaje; inna firma wpłaca pieniądze w modele i je trenuje; a te dwa składniki to świetna baza, by — miejmy nadzieję — napędzić masę naprawdę ciekawych interakcji między modelem a człowiekiem za sterami. Pod wieloma względami jesteśmy niesamowicie wcześnie i nie mamy sztywnej wizji, jak dokładnie ma się to rozwinąć. Nie bylibyśmy jednak zadowoleni, gdyby praca z agentem nie dawała wartości także nie-programiście. Widzę, że świat rusza w tę stronę — choćby z Claude Cowork i podobnymi rozwiązaniami — ale programista i tak wyciśnie z modelu znacznie więcej niż zwykły użytkownik ChatGPT. I właśnie próbujemy zrozumieć, jak spiąć tę przepaść.

David Ondrej: Czy to w ogóle możliwe? Muszę podważyć ten optymizm: ludzie o technicznym zacięciu używają więcej agentów — ogarniają dziesiątki, setki, tysiące, wiedzą, jakie modele i opakowania wybrać, co puścić lokalnie, a co w chmurze. Pięknie byłoby zrobić z każdego zaawansowanego użytkownika AI, ale widać, że ci, którzy umieją, wyciągają z tego coraz więcej — jak w powiedzeniu, że sprytni stają się sprytniejsi.

Armin Ronacher: Nie mówię, że każdy zostanie programistą — ani tak na to nie patrzymy, ani nie jest to cel. Wychowałem się na DOS-ie…

David Ondrej: Wiem, co to jest.

Armin Ronacher: …czyli na tym gorszym. Ciekawostka: dzisiejsze agenty do kodu świetnie piszą w bashu, a Unix od początku był znakomitym systemem dla zaawansowanego użytkownika. DOS był po prostu bardzo słabym, tekstowym komputerem osobistym, mocno zoptymalizowanym pod wykorzystanie zasobów. Nikt nie siedziałby przy DOS-ie, mając wybór. Potrzeba było wielu iteracji, zanim komputer z biurkiem stał się czymś, czego każdy mógł i chciał używać. I z agentami jesteśmy mniej więcej w tym samym punkcie: w obecnej formie to nie jest interfejs, którego ktokolwiek powinien używać. Trudno mi wyobrazić sobie, że za cztery lata wszyscy będziemy pracować z agentami do kodowania w dzisiejszej postaci. Z jednej strony ci, którzy pchają tokeny na maksa, przeniosą wszystko do fabryk oprogramowania, gdzie nikt nie poświęca czasu pojedynczemu agentowi; z drugiej — ci, którzy chcą agentów do pracy specjalistycznej, też nie będą siedzieć w dzisiejszym interfejsie agentowym. Są też techniczne powody, dla których to, co mamy dziś, nie wystarczy do naprawdę dobrego oprogramowania przyszłości. Ale ktoś to zbuduje — to wydaje mi się oczywiste — i my też chcemy spróbować, a przynajmniej postawić naprawdę dobrą infrastrukturę, żeby mógł to zrobić ktoś inny. Chcielibyśmy dojść do świata, w którym ludzie używają naszych fundamentów do budowy własnych, naprawdę dobrych agentów. Równocześnie chcemy te fundamenty rozwijać — wszystkie elementy potrzebne dobrym agentom — żeby móc na nich stawiać także własne rozwiązania dostępne dla nie-inżynierów.

Czego jeszcze brakuje

David Ondrej: Poza samym opakowaniem — co są największymi klockami, które trzeba jeszcze ułożyć?

Armin Ronacher: Mniej chodzi o pojedynczy element, a bardziej o to, żeby cała ekonomia tej branży ruszyła w stronę prawdziwej konkurencji na modelach. Dobra wiadomość: coś takiego się dzieje — wybór modeli mamy spory. Niepokojące jest natomiast to, że nowe funkcje w niektórych zamkniętych modelach z USA coraz mocniej przywiązują cię do ekosystemu. Mój klasyczny przykład: kompresja sesji po stronie serwera tworzy sesję, której nie da się przenieść. To po prostu słabe. Rzecz do rozwiązania to trwałość: żeby agenta dało się uśpić i wznowić dokładnie tam, gdzie skończył. Z opakowaniami do kodu radzimy sobie dziś nieźle, ale wciąż nie na poziomie, na którym da się budować systemy działające bez człowieka w pętli. I jeszcze jedno: nikomu do końca nie udało się przenieść agenta z terminala do przeglądarki tak, żeby było to najmocniejsze możliwe doświadczenie. Większość agentów w sieci wygląda jak nakładka www na agenta terminalowego — a tam jest dużo do odkrycia. Wreszcie: nie jesteśmy zwolennikami „pamięci”, ale wierzymy w dawanie agentom sposobów operowania danymi. Pytanie brzmi: jak zapewnić agentom naprawdę dobry dostęp do baz danych, żeby mogły zapisywać własne dane i pokazywać je człowiekowi? Lista wyzwań, nad którymi wszyscy teraz pracują, jest niemal nieskończona — po to, by agenty dawały wartość każdemu, a nie były wyłącznie agentami do kodowania.

David Ondrej: Problem interfejsu jest ciekawy, bo dziś wybór to terminal albo jakieś GUI, a ja wyobrażam sobie coś bardziej w stylu gry: drużyny agentów, twoje zasoby, limity…

Armin Ronacher: Nie przywiązuję do tego aż takiej wagi. Na bardzo podstawowym poziomie: świetnie, że OpenClaw, Hermes i podobne systemy pokazują wartość agentów, ale wielu moich problemów nie da się rozwiązać samym tekstem, a te agenty nie potrafią trwale wyświetlać własnych, dedykowanych interfejsów. Jeśli chcę, żeby agent obsługiwał moje Home Assistant, to przecież nie powinien tylko wykonywać poleceń — powinien też pokazać mi wizualizację domu i wszystkich urządzeń. Dzisiejsze agenty potrafią wygenerować odrobinę interfejsu, ale niewiele, i to samo w sobie jest problemem do rozwiązania. Fakt, że agent jest uwięziony w zapisie rozmowy, po prostu nie jest optymalny.

David Ondrej: Czy to problem architektury? Bo brak gustu czy kreatywności siedzi chyba w samym transformerze. Czy to w ogóle rozwiązywalne, czy potrzebujemy przełomu w AI?

Armin Ronacher: Nie, nie sądzę, żeby był potrzebny przełom w AI. Duża część ograniczeń agenta wynika z czegoś innego: przeszliśmy od świata, w którym kod pisali ludzie, do świata, w którym piszą go agenty — a to, co tanie dla człowieka, bywa drogie dla agenta i odwrotnie. Zauważ: Linux przeżywa teraz renesans także dlatego, że agenty świetnie sobie z nim radzą — w internecie znalazły mnóstwo materiałów o tym, jak działa. Znakomicie pilotują środowiskiem linuksowym: możesz wziąć pudełkowe Ubuntu, Archa albo NixOS i w pełni sterować nim oraz dostosowywać go samym agentem do kodowania. To ogromna zmiana. Ośmielę się nawet powiedzieć, że dziś moja mama miałaby większe szanse na dostosowanie Linuksa agentem niż macOS — bo macOS jest słabiej reprezentowany w danych treningowych, a Windows wręcz wypada z tego rozkładu. Skutek: rzeczy, którymi kiedyś władało garstka, wracają do łask. Jestem dość pewien, że więcej osób będzie pisać w Ruście, sięgnie po NixOS, po naprawdę złożone bazy danych albo Kafkę do strumieniowania zdarzeń — bo to zawsze były lepsze rozwiązania, tylko zbyt trudne dla ludzi. Dla agenta — niekoniecznie. Jesteśmy w fazie, w której nie chodzi o przełom w AI, tylko o zrozumienie, które systemy dobrze współgrają z tym, co już mamy. I kwestia „jak agent wyświetla interfejs” nie jest kwestią kreatywności — to głównie zarządzanie stanem, biblioteki komponentów, bazy danych zaprojektowane tak, by agent mógł z nimi pracować bez niszczenia danych. Żadna z tych rzeczy nie jest problemem AI. To klasyczne problemy architektury systemów.

David Ondrej: Czyli przez ostatnie 20–30 lat zrobiliśmy objazd, optymalizując wszystko pod człowieka, a teraz ten komfort się sypie, bo użytkownikiem staje się agent.

Armin Ronacher: Obydwoje stają się użytkownikami. Ideę, że odtąd wszystko robią wyłącznie agenty, uważam za wątpliwą.

David Ondrej: Ale pociągnijmy to do końca: modele się poprawiają, opakowania też, komunikacja jest coraz łatwiejsza — czy nie stanie się oczywiste, że agenty będą 99,9 procenta użytkowników każdego oprogramowania?

Armin Ronacher: Nie sądzę. Zależy trochę, jak to mierzyć, ale na very podstawowym poziomie: liczba ludzi na świecie, jeśli już, stagnuje. Agenty nie stworzyły więcej ludzi — grono tych, którym na czymś zależy, jest po prostu to samo. Na końcu i tak musi stanąć człowiek. Produkt krajowy napędzają ludzie kupujący rzeczy, a nie agent robiący coś dla własnej rozrywki. System, który działa sam dla siebie, po prostu spala energię na nic. Ktoś musi odnieść korzyść — i tym kimś jest człowiek. Wizja, że wszyscy siedzimy w fotelach, a maszynom co jakiś czas wydajemy polecenia przez urządzenia, nie wydaje mi się prawdopodobna, bo zawsze będzie gorsza od tej samej pracy z człowiekiem na przedzie. Jeśli wszystkim sterują maszyny, ten, kto używa tej samej maszyny co pozostali, ale dokłada do niej człowieka, ma przewagę.

David Ondrej: Zgadzam się.

Armin Ronacher: Zawsze więc będzie oprogramowanie z człowiekiem gdzieś w środku. Można argumentować, że przybędzie oprogramowania wspierającego agenty — pewnie tak, ale oprogramowania służącego innemu oprogramowaniu zawsze było dużo. Weź każdą firmę od obserwowalności: większość kodu nie istnieje po to, by patrzył nań człowiek, tylko by przetwarzać punkty danych. Może kiedyś 70 procent zapytań do takiej platformy pochodziło od ludzi, a 30 od automatyzacji; dziś bywa 30 procent automatyzacji, 60 procent AI i 10 procent ludzi. Ale platforma obserwowalności, która nigdy nie dawałaby człowiekowi dostępu do danych, nie miałaby dla mnie żadnego sensu — bo przewagę zdobędzie ten, kto ten dostęp zostawi. Jest jeszcze pomysł, że agenty będą świetnie pisać asembler albo jego odpowiednik. Nie sądzę, żeby to kiedykolwiek była prawda: gdy człowiek traci zdolność zrozumienia, co się dzieje, traci też zaufanie do systemu, a gdy coś pójdzie źle, ktoś będzie się skarżył. Niedawno argumentowałem, że banki nigdy nie będą „vibe code’ować” — bo w chwili, gdy coś się wysypie, ich klienci nie będą zadowoleni.

David Ondrej: Kwestia odpowiedzialności — kogoś trzeba winić.

Armin Ronacher: Właśnie. A nie da się winić maszyny — społeczeństwo tak nie działa i nigdy działać nie będzie.

David Ondrej: Ale przecież można obwiniać człowieka, który użył maszyny — jak rolnika…

Armin Ronacher: Tylko że w momencie, gdy przyjmie się zasadę „winisz człowieka obsługującego maszynę”, ten człowiek zacznie żądać lepszego wglądu w to, co maszyna robi. A jeśli zostaje mu „patrzę na binarkę i nic nie wiem” — przestanie tej maszyny używać. Te dwie rzeczy się wykluczają.

David Ondrej: Jeśli mamy superinteligentne agenty na modelach o ilorazie 200–300, przecież skleją sobie dedykowany interfejs.

Armin Ronacher: Może w bardzo odległej przyszłości — ale jesteśmy od tego tak daleko, że nie warto się nad tym teraz rozwodzić. W dającej się przewidzieć przyszłości ludzie będą chcieli rozumieć, co się dzieje. I dlatego będą korzystać mniej więcej z tego samego interfejsu co agent — po to, by zobaczyć to, co agent zrozumiał, bez pytania innego agenta, który może kłamać.

David Ondrej: Stąd pewnie wygrywa Markdown. Ironia, że tak proste rzeczy — Markdown, pliki JSON, uniksowe potoki — stają się fundamentem wszystkiego, co się teraz dzieje. Choć z drugiej strony nie dziwi, bo to również to, co rozumieją ludzie.

Jak pracuję na co dzień

David Ondrej: Opowiedz o swoim typowym dnia z agentami. Siadasz rano — jak pracujesz, jak zmienia się twój setup?

Armin Ronacher: Nie jestem szczególnie ciekawym przypadkiem, bo nie prowadzę fabryki oprogramowania. Nie że nie próbuję — po prostu mi się dotąd nie udało. Jesteśmy pewnie jedyną firmą od opakowań, która nie ma automatycznego bota poświęconego zgłoszeniom. Może do tego dojdziemy, ale na razie nasza inżynieria wygląda w zasadzie tak jak kiedyś: agenty uruchamiamy w większości lokalnie, na naszych maszynach — w chmurze siedzi niewiele. Mam stacjonarnego Linuksa, na którym przez SSH trzymam niektóre rzeczy, jeśli mają chodzić bez przerwy, ale większość dzieje się tam, gdzie jest kod. Mamy trochę automatyzacji w GitHub Actions, żeby dało się tam odpalać Pi. Co więcej, spora część mojej pracy to w ogóle nie generowanie kodu, tylko rozumienie, jak coś powinno działać. Dużo czasu spędzam na wspólnym badaniu z maszyną: „mam raport — jak wyciągnąć z niego repozytorium” — takie rzeczy. U nas to wciąż bardzo tradycyjna inżynieria. Na tle tego, co robi wielu ludzi, jesteśmy bardzo zachowawczy. Ja jestem bardzo zachowawczy.

David Ondrej: Mówisz, że siedzisz mocno lokalnie, a wielcy — OpenAI, Cursor — pchają agentów do chmury. Czy argument „wkrótce twoja maszyna przestanie wystarczać, przenoś wszystko do chmury” jest zasadny, czy to raczej taktyka zamykania ludzi w ekosystemie — bo gdy już przeniosą tam środowiska, ucieczka jest bardzo trudna?

Armin Ronacher: Szczerze: nie sądzę, żeby to miało znaczenie, bo konkurencja będzie na tyle duża, że zrobisz, co chcesz — lokalnie albo w chmurze. Kluczowe pytanie brzmi: co konkretnie daje mi chmura, a co praca lokalna? Jednym z powodów, dla których chmura jest mi dziś obojętna, jest to, że mam naprawdę mocnego Maca i lokalnie po prostu wychodzi szybciej. Mam też przyzwoitą maszynę z Linuksem — jest w porządku, ale testy odpala z mniej więcej połową prędkości Maca. Do tego wciąż jest ta niedogodność, że pewne rzeczy chcę mieć u siebie, a przenoszenie tych danych do chmury jest uciążliwsze, niż być powinno. Krótko mówiąc: mam za dużo tarcia i jest za wolno. Przykład sprzed miesiąca czy dwóch: pomagałem komuś debugować problem; używał chmurowego Codexa albo Claude Code — jednej z tych aplikacji — i w tym programował. Pytam: jak tu uruchamiasz testy bazy danych? Okazało się, że on nie wie. Sprawdziliśmy — i żadne testy bazodanowe nigdy nie działały w jego chmurowym środowisku.

David Ondrej: Brakowało zmiennych środowiskowych?

Armin Ronacher: Nie — po prostu nie było żadnego Postgresa. To środowisko nigdy nie zdołało go postawić; wszystko było zamockowane. I do dziś jest to całkiem poważny problem: zamiast walczyć z chmurowymi rozwiązaniami przy codziennej inżynierii projektu, dużo lepiej sprawdza mi się maszyna z przygotowanym środowiskiem, do której się wchodzi zdalnie (są lepsze sposoby niż SSH) i na której wszystko już chodzi. Tamte na pewno dojdą do formy, ale ja mam za dużo rzeczy, które muszą działać, i prościej mi mieć maszynę, którą kontroluję — wszystko jest na niej. Oczywiście przeniesiemy się w tę stronę. Historycznie największym powodem, dla którego to nie działało, było to, że nikt nie poświęcał czasu na budowanie jednorazowych środowisk deweloperskich. Pamiętam, jak wdrażaliśmy inżynierów w Sentry: postawienie środowiska zajmowało im w pierwszym tygodniu dwa–trzy dni. Mieliśmy przez pewien czas trzyosobowy zespół, który przez jakiś czas robił nic innego, jak tylko poprawiać ten setup. I tak czy siak zostawało ci jedno środowisko. A jeśli chcesz uruchomić na jednej maszynie siedem agentów, potrzebujesz siedmiu baz danych, siedmiu klastrów Kafki… Przy dostatecznie złożonym oprogramowaniu bardzo trudno było to wszystko postawić. Nie wiem, jak Sentry robi to dziś, ale jestem dość pewien, że od zera — nawet z pamięcią podręczną — start środowiska zająłby jakieś siedem minut. A to dla agenta wciąż drogo, bo każda zmiana dostaje dodatkowy czas doładowania. Możesz trzymać pulę środowisk — ale to też robi się bardzo złożone. Jestem pewien, że niektórzy mają to perfekcyjnie ogarnięte dla siebie. U mnie po prostu jeszcze nie zadziałało — albo znalazłem coś prostszego, co wciąż działa. Ale przenoszenie pracy do chmury ma mnóstwo sensu i to z wielu powodów. Choćby dostęp do własnego Maca: używam do tego Tailscale, działa prosto, ale i tak muszę wszystko ustawić sam. A rozwiązania w rodzaju OrbStack czy chmurowego Codexa są dużo wygodniejsze niż ogarnianie Tailscale i SSH. Z perspektywy wygody mój setup ewidentnie kuleje. Będzie lepiej.

David Ondrej: Ja jestem teraz podobnie — większość u mnie lokalnie. Może o to pytam, bo łapię syndrom straconych okazji na punkcie chmurowych agentów, i myślę od podstaw: jeśli agentów będzie sto razy, tysiąc razy więcej, przyjdzie moment… Też mam bardzo drogiego Maca i czasem się grzeje, gdy kilka agentów pracuje na kilku drzewach roboczych i wszystkie naraz wpadną na pomysł odpalenia testów — widać, jak wentylatory przyspieszają, co na topowym MacBooku się nie zdarza. Gdzie jest granica? Czy kolejna generacja modeli będzie aż tak dobra, że fizycznie nie zdążę trzymać wszystkich agentów u siebie?

Armin Ronacher: Pytanie właściwie brzmi: po co my to wszystko robimy? To bardzo ważne pytanie. Najprościej popatrzeć tak: ile przedsiębiorstwa wydają dziś na AI do kodowania — i czy ich przychody realnie poszły w górę? Nie kwestionuję, że jest mnóstwo startupów AI i że zarabiają kupę pieniędzy. Ale weź tradycyjne przedsiębiorstwo wdrażające agenty do kodowania na masową skalę — czy widać to w liczbach, czy po prostu stało się drożej? Bo mamy dziś pozycję w budżecie, którą płacimy wszyscy: modele zrobiły się tak dobre w badaniach nad lukami bezpieczeństwa, że musimy teraz płacić za ciągłe skanowanie naszych baz kodu, bo w przeciwnym razie zrobi to ktoś przeciwko nam. Na razie uczyniliśmy więc głównie wszystko droższym. Z drugiej strony mnóstwo inżynierów znajduje po godzinach motywację, by budować projekt poboczny od projektu pobocznego od projektu pobocznego — i to też na wiele sposobów służy gospodarce, nawet jeśli nikt tego specjalnie nie używa. Te eksperymenty nie są bezużyteczne. Kto więc na tym korzysta? Moim zdaniem ludzie z projektami pobocznymi odnoszą dziś znacznie więcej sukcesów niż firmy wdrażające to na skalę. To moje tendencyjne spojrzenie — niektórzy powiedzą: „wprowadziliśmy to u nas i mamy liczby, które pokazują, że działa”. Ale przy tym, o ile droższa stała się siła robocza, nie widzę jeszcze wspaniałych przykładów w stylu „wydatki na tokeny wzrosły nam o 500 procent, ale przenieśliśmy w firmie to i tamto”. Może da się pokazać jakiś wynik — tyle zamkniętych zgłoszeń wsparcia — ale większości ludzi bardzo trudno dostrzec cokolwiek poza liczbą commitów. I czy nam w ogóle potrzeba tyle równoległości? Produkujemy znacznie więcej kodu — to prawda i bardzo to widać: GitHub ledwo wytrzymuje, bo commitów przybywa lawinowo. A jednak rano wsiadam do pociągu, do autobusu, jadę rowerem — i wszystkie sklepy wokół zachowują się mniej więcej tak samo jak trzy lata temu. Nie widziałem jeszcze tej wielkiej zmiany w społeczeństwie. Z drugiej strony: poprzednią taką zmianą były telefony — i dziś na koncercie sto procent ludzi przed sceną trzyma w górze telefon; to weszło w nasze życie bardzo agresywnie. ChatGPT też widać już wszędzie. Ale tego skutku jeszcze nie zobaczyłem. Na pewno przyjdzie — na razie wszyscy próbujemy to zrozumieć.

David Ondrej: Ekscytujące czasy, bez dwóch zdań — świetnie się to odkrywa. Ale zarazem nietrudno zachować odrobinę sceptycyzmu co do realnego wpływu, bo efekty w wynikach przychodzą z wyraźnym opóźnieniem — natomiast w kosztach, rozbudowie infrastruktury i wszystkim pozostałym pokazują się błyskawicznie. To zresztą klasyczna reakcja: gdy ktoś na Twitterze szczycił się, ile tokenów pali, ktoś z opencode odpowiedział mu chłodno: „to czemu nie odniosłeś większego sukcesu?”. Tylu ludzi kotłuje swoje dziesięć fabryk oprogramowania i nie produkuje nic. A twoja uwaga to świetne przejście do następnego pytania: dlaczego tyle udanych projektów zaczyna się jako żart, projekt poboczny albo coś, o czym twórca myśli, że innym się nie spodoba — a właśnie to łapie i rośnie? Twoja historia z Flaskiem jest tego świetnym przykładem. Co tu jest magią?

Armin Ronacher: Myślę, że w pewnym stopniu to nie tyle żart, co autentyczna ciekawość. Jeśli zmusisz się do budowania czegoś, w co nie wierzysz, się nie powiedzie. Jeśli masz swędzącą plamkę — choćby dla zabawy… Większość systemów istnieje po prostu dlatego, że ludzie nie przestają w coś wkładać pracy. Przychodzisz rano, robisz coś i robisz to dalej — to jest prawdziwy wskaźnik. Flask może zaczynał się jako żart, ale potem zamienił się po prostu w pracę: mnóstwo commitów, ogarnianie zgłoszeń, doprowadzanie do działania — i to wystarczająco długo. To nie jest sukces z dnia na dzień. Wszystko idzie dziś dużo szybciej, ale gdybyś spojrzał, ile commitów Mario włożył we wczesne Pi — jego sukces nie był wielkim zaskoczeniem. Nie tylko było inne; po prostu działało naprawdę dobrze na tle wszystkiego, co było wtedy na rynku. Wkładasz czas w coś — a czasu, oczywista, nie da się wkładać w coś, na czym nikomu nie zależy. Wiele moich projektów otwartych to „moja rzecz, bo nikogo innego to nie obchodzi”. Dopiero potem możesz marketingowo sprawdzić, czy jest dość ludzi, którym zależy. Musi być dość ludzi, którzy zostają i przynoszą ci swoje problemy — bo dopiero wtedy widzisz, gdzie są prawdziwe trudności — i z tego się rusza dalej.

David Ondrej: Czyli być bardzo konkretnym i pełnym pasji wokół jednej rzeczy, siedzieć na jej przedzie — i to daje nieoczywiste spostrzeżenia: to mogłoby być lepsze, tamto inne.

Armin Ronacher: Nie wiem, czy trzeba być na przedzie. Klasyczny przykład z ostatnich lat: Mitchell Hashimoto zbudował Ghostty…

David Ondrej: Ghostty…

Armin Ronacher: Ghostty być może jest dziś na przedzie, bo robi bardzo dużo, ale przez długi czas… nie chcę nic przekręcić… zawsze było szybkie, ale miało sporo do nadrobienia. Pamiętam, jak używałem go bardzo wcześnie: brakowało wielu rzeczy, ale na tle innych opcji było na tyle dobre, że aż interesujące — i bardzo rzucało się w oczy, ile energii w to wchodzi. Czuło się: jeśli będę tego dalej używał, w końcu będzie świetne. Ale na przedzie nie było, bo tyle rzeczy brakowało, że przedem były kitty i kilka innych. Nie sądzę więc, żeby „bycie na przedzie” miało znaczenie. Musi być jedno nieoczywiste spojrzenie, jeden własny pomysł, coś świeżego.

David Ondrej: Nie musi być nawet nowe…

Armin Ronacher: …musi być coś, co ludzi w tym pobudza. Pytanie „dlaczego to buduję”. Ghostty powstało, bo twórca chciał, żeby było szybkie. Pamiętam, jak bardzo wcześnie oglądałem jego blogi deweloperskie: ma być natywne dla platformy i szybkie. Były rzeczy natywne albo szybkie — ale nie obie naraz. Jeśli mu się uda, będzie dość powodu, żebym z tego korzystał. W tym sensie to była dobra historia i stało za nią mnóstwo energii. Ale weź Django — framework, do którego do dziś czuję sentyment. Trochę nowatorski panel administracyjny „do wszystkiego”, ale przede wszystkim: ludzie nie przestawali go budować, utrzymywać i zasilać energią — i czuło się, że można na nim w pełni polegać, bo będzie tu jeszcze za dekadę. I jest, dwie dekady później. A curl to idealny przykład: używa go każdy, a przecież curl nie jest unikalny ani na przedzie — jest po prostu niezawodny i właśnie dlatego to znakomity wybór. W pierwszym czy drugim roku projektu nie było to oczywiste; dziś jest. Niektóre rzeczy istnieją dosłownie dlatego, że ktoś ciągle wkłada w nie pracę. Sentry tak samo: czy było najlepszym wyborem, gdy zaczynaliśmy? Uważam, że tak, ale konkurencji było mnóstwo i wielu zabrakło długodystansowości. W końcu zostało tylko Sentry. Niektóre projekty to po prostu „rób dalej”. Tylko że to oczywiście nie jest sukces z dnia na dzień — zajmie ci lata. Jeśli pytasz „co zbudować, żeby po pół roku sprzedać kolejnemu naiwniakowi”, to pracujesz inaczej — ale to nigdy nie było moją motywacją.

Open source: darmowa infrastruktura, dane treningowe, trwałość

David Ondrej: Porozmawiajmy o otwartym oprogramowaniu, bo coraz więcej projektów, które startują i wystrzeliowują, jest otwartych. To kwestia zaufania — można zajrzeć do środka, budować na wierzchu, łatwo zforkować? Jak widzisz odsetek otwartego kodu na świecie: rośnie czy stoi? Dostrzegasz ciekawe trendy?

Armin Ronacher: Nie wiem, ale mam kilka spostrzeżeń. Po pierwsze: ogólny ruch to niekoniecznie „więcej open source”. Bardzo klasyczny, bardzo irytujący schemat to zaczynać otwarcie, a potem zamykać kod. Tak było od zawsze, a w AI jest to niesamowicie częste — znane firmy z tej branży zaczynały jako open source i znajdowały potem argument, żeby przestać. Nawet Cal.com, które mówiło „jesteśmy świetni i otwarci”, już nie jest w pełni otwarte. Uważaj więc: kto buduje projekt otwarty i pozostaje przy nim, to zupełnie inna rzecz niż ktoś, kto kiedyś projekt otwarty zaczął. Jest za to powód, dla którego zobaczysz mnóstwo kodu AI jako otwartego, całkiem niezwiązany z przekonaniami twórców: projekt otwarty dostaje darmową infrastrukturę. Różnica w kosztach GitHub Actions między projektem otwartym a zamkniętym to duże pieniądze. A koszt sklonowania cudzego kodu jest zapewne minimalny. Jeśli chcesz darmowej infrastruktury, budujesz otwarcie — taki jest obecnie stan rzeczy. Jak długo Microsoft będzie to utrzymywał, to osobne pytanie. W każdym razie dziś start jako open source daje ogromną przewagę finansową: marketing plus infrastruktura za darmo. Boję się tylko, że w dłuższym terminie to open source trochę niszczy, bo wielu ludzi, którzy teraz otwierają kod, nie ma pojęcia o licencjach, o tym, co to znaczy być projektem otwartym, jak rozwiązać jego finansowanie. Dla nich to głównie kanał marketingowy. I jako ktoś, kto długo pracuje w open source, jestem tym lekko zirytowany. Może to przejściowe i jakoś się ułoży.

David Ondrej: Pytałem z drugiej strony. Nie mówię, że za rok czy dwa. Ale skoro — jak wspominałeś — koszt powielania oprogramowania spada, a agenty i modele się poprawiają, ludzie będą umieli odtwarzać coraz więcej. Nie twierdzę, że każdy zrobi sobie własnego Slacka czy własny CRM. Pytam o coś innego: gdy agenty piszą więcej kodu i budowanie czegokolwiek staje się łatwiejsze, czy więcej tego będzie publikowane jako open source — choćby z powodów marketingowych? Powód nieistotny — czy trend tam prowadzi?

Armin Ronacher: Naprawdę nie wiem. Nie wiem nawet, jak miałbym się tego dowiedzieć, bo nie znam odsetka kodu otwartego do zamkniętego w przeszłości, tym bardziej dziś. Jedno jest jasne: jest wbudowana przewaga w budowaniu rzeczy, na których mają dalej budować agenty, kiedy są otwarte — bo, chyba że coś się zmieni, trafią one do danych treningowych. I to jest naprawdę istotna kwestia. Rozmawiałem nawet z ludźmi w Microsofcie, którzy porównywali jakość pracy modeli na kodzie zewnętrznym z tym, co znaczy napisanie gry na Xboxa — bo kodu na konsole publicznie prawie nigdy nie było, wręcz było to niedozwolone. I była, o ile wiem, wewnątrz Microsoftu opozycja wobec udostępnienia kodu Xboxa modelom — bali się skutków. Nie wiem, jak to się skończyło. Ale wniosek się nasuwa sam: jeśli chcesz, żeby inni budowali na twoich fundamentach z użyciem agentów, świetnie, jeśli są one przynajmniej częściowo otwarte — bo wylądują w danych treningowych. Znowu: ta dziedzina zmienia się tak szybko, że kto wie, co będzie za dwa–trzy lata. I zresztą nieważne — wybory specjalnie się nikomu nie zmienią; ludzie i tak zrobią, co chcą. Robią to, co przychodzi im naturalnie. Mam nadzieję, że będą nadal utrzymywać wspaniałe otwarte oprogramowanie. Tyle że moim zdaniem wiele projektów startujących teraz nie ma właściwych powodów, by być otwartych. Pewnie tak było zawsze — teraz jest to po prostu bardzo widoczne.

David Ondrej: Co więc oddziela przeciętny projekt otwarty od świetnego? Surowa zdolność techniczna? Myślenie?

Armin Ronacher: Czy ten projekt będzie istniał za dziesięć–piętnaście lat? To jedyne pytanie, które naprawdę się liczy. Będzie istniał i nadal będzie otwarty? Jeśli tak — dobry projekt. Jeśli nie — zły. Zły projekt to taki, który znika, nie ma przyszłości, zamyka kod, jest porzucany albo nie ma użytkowników. A jeśli jest użyteczny dla społeczeństwa, jest utrzymywany i ludzie na nim budują — to świetny projekt. Tyle że ocenić to można tylko po latach, nie dziś. Przykład: nie wiem, czy pobrałeś kiedyś PHP 1.0 albo 2.0. Możesz wejść na museum.php.net i ściągnąć stare archiwa. To straszne — stare PHP wygląda obiektywnie przerażająco. Pamiętam swoje wczesne kroki w PHP, potem przyszła wersja trzecia i to była już dobra odsłona. Ileż osób mówiło wtedy: PHP to śmieci, ten gość nie umie zaprojektować języka. A popatrz na PHP dziś: to naprawdę porządny język, wszyscy, którzy nad nim pracowali, mnóstwo się nauczyli, da się w nim pisać bardzo produktywnie — Laravel to świetny ekosystem. Gdybyś ocenił PHP w pierwszym roku, po tym, co robił Rasmus na starcie, miałbyś o tym języku fatalne zdanie. Dziś możesz powiedzieć: to wspaniały projekt, bo po pierwsze — wciąż istnieje, wciąż się rozwija i wciąż mają go wspierający. Możemy to ocenić dopiero po fakcie.

David Ondrej: Świetna pointa: połowa sukcesu to po prostu trzymanie się tematu i ulepszanie w czasie — tak zyskujesz zaufanie ludzi, którzy zbudują na twojej pracy.

Armin Ronacher: Pi będzie wspaniałym projektem otwartym, jeśli za kilka lat będzie jeszcze miało znaczenie. Jeśli okaże się zbędne — było ciekawym epizodem, ale nie wielkim projektem.

Obecność w danych treningowych jako przewaga

David Ondrej: Rozwińmy wątek danych treningowych, bo to bardzo ciekawe — i już to widać: gdy zaczynasz nowy projekt, modele pchają cię w określone wybory technologii i platform wdrożeniowych. Czy dużo jest już przesądzone — system kontroli wersji to zawsze git, system operacyjny to Linux, bo jego jest najwięcej w danych, wobec Windows czy macOS? Jak to wpłynie na przyszłość?

Armin Ronacher: Przy dzisiejszej architekturze modeli obecność w danych treningowych to ogromny atut — przynajmniej takie jest, sądzę, powszechnie przyjęte odczytanie i nie mam kontrargumentu. I to idzie tak daleko, że ci, którzy w danych już są, na tym jadą. Znam zespoły w firmach słabo reprezentowanych w danych, które próbują wymyślić, jak się tam dostać. Bo jeśli jesteś pierwszym wyborem agenta w swojej kategorii… Nie pamiętam, która to była firma, ale jedna z nich odkryła, że we wszystkich modelach wypada świetnie — i, jeśli dobrze pamiętam, kupiła reklamę na autobusie w San Francisco z przekazem: „potrzebujesz tego i tego? Zapytaj swoją AI, czego by użyła”. Dało się wykonać ruch z pozycji siły, bo było się domyślnym wyborem. Korzyść jest oczywista, tym bardziej że ludzie coraz częściej używają modeli zamiast wyszukiwarki. Częściowo — jeśli agent ma dostęp do sieci — to też kwestia pozycji w wynikach, bo agent może prowadzić rozeznanie, zamiast sięgać wyłącznie do wag. Ale samo to nie wystarcza, choćby dlatego, że agenty zawsze będą musiały rozwiązywać problemy z twojego kodu, który miejmy nadzieję nigdy nie trafi do wag — chyba że pracujesz na kodzie otwartym. Więc sporo pracy i treningu musi pójść w uczenie się w kontekście i doprowadzenie go do doskonałości. Może nie jest to nawet aż tak krytyczne, bo zawsze można kierować ludzi do dokumentacji. Ale ogólnie: ludzie zrobią wszystko, by w jednej czy drugiej formie trafić do wag. Nie sądzę, żeby się to zmieniło.

Wydatki na inferencję i ceny tokenów

David Ondrej: Przejdźmy do rzeczy bardziej przyszłościowych. Ostatnio dotarło do mnie, że inferencja będzie pochłaniać coraz większą część budżetów. Mogę spojrzeć na siebie: nie wydam więcej na losowe „vibe code’owane” aplikacje, ale co miesiąc wydaję więcej na inferencję — i nie widzę, by się to kończyło. Jasne, każdy chce to zoptymalizować, spłaszczyć rachunek za tokeny, wziąć subskrypcje zamiast płacić stawki API. Ale zakładając, że postęp modeli i opakowań potrwa: czy to będzie zjadać coraz większy kawał rynku oprogramowania? Ktoś, kto kiedyś płacił konsultantowi czy analitykowi, dziś zada dwa prompty w trybie głębokiego researchu i dostanie odpowiedź od agenta — ten wydatek przepływa od konsultanta do inferencji. Czy po prostu pochłonie ten rynek?

Armin Ronacher: To zależy od ceny tokenów. Ona dziś spada, ale jednocześnie faktyczny koszt rozwiązania zadania — przynajmniej według mojej obserwacji — raczej rośnie: moje sesje nie tanieją, a ogólne wydatki na to, co robię, nie mają trendu spadkowego. I gdybym musiał płacić stawki API zamiast subskrypcyjnych, chyba wcale nie używałbym AI. Dziwnie by mi było palić tyle kapitału inwestorów na AI. Może nie powinno — bo zapewne na tym im zależy — ale osobiście miałbym opór przed tak ciężką pozycją „inferencja” w firmie. Wszystko rozstrzygnie więc cena. Bo jeśli człowiek potrafi przy tym być godny zaufania i niezawodny, a przy okazji sam wzmacnia się AI — to może być lepszy interes niż pozbywanie się wszystkich ludzi z firmy na rzecz czystego AI, zwłaszcza w cenach, w których już jesteśmy. Przyszłości nie przewidzę. Dużo zależy też od tego, czego zechce społeczeństwo. Poza programowaniem AI to work z mieszaniną: ludzie tego używają, ale w ten sam sposób, w jaki używają smartfonów, TikToka i YouTube’a — mnóstwo mówi „używam, ale i tak nie znoszę firm, które to robią”, albo „nie znoszę, że to pochłania tyle energii”, albo „że prąd mi drożeje”. Można więc uznawać tę technologię za trochę użyteczną i jednocześnie jej nie lubić. A od tego, ile jej będą lubić, bardzo zależy to, co zrobią firmy i społeczeństwo — i tego nie umiem przewidzieć w żadną stronę.

David Ondrej: Dwie uwagi. Pierwsza: twój rachunek za tokeny mógłby spadać, gdybyś go optymalizował — przy naprawdę małym budżecie i spiętych subskrypcjach dostawałbyś co miesiąc więcej za mniejsze pieniądze, wraz z lepszymi modeli otwartymi. Częścią zagadki jest więc to, że po prostu nie zależy ci na zbijaniu tego wydatku. Gdyby cię nie było stać, znalazłbyś sposób, by AI prowadzić — może na gorszych modelach, na tańszych subskrypcjach. Druga: tak, w niektórych sprawach wciąż chcesz rozmawiać z człowiekiem — a jeśli ten człowiek używa AI, to taki księgowy czy doradca podatkowy obsłuży więcej klientów. Może więc brać mniej od klienta, ale przyjąć ich dziesięć razy więcej i podcinać ceny konkurentom bez AI. To i tak przesuwa koszt do inferencji — bo zarobi więcej, ale jego marże będą niższe, skoro pracę wykonuje AI.

Armin Ronacher: Ogólna rzecz, która mnie niepokoi, jest taka, że procentowo — w proporcji do europejskiego produktu krajowego — więcej pieniędzy popłynie do firm amerykańskich. To mój ogólny niepokój.

David Ondrej: No właśnie…

Armin Ronacher: Najprawdopodobniej tak się stanie w jednej czy drugiej formie; gdzie to wyląduje, nie wiem. Przykład: kiedyś nie znalazłbyś projektanta używającego AI — ale mogłeś pójść do ChatGPT i zrobić sobie obrazek. Potem był odsetek projektantów pracujących z tobą przy wsparciu AI — mówiłeś „chcę to i to”, ale 30 procent wychodziło jako „slop”, bo w twoim obrazie pojawiały się wygenerowane fragmenty. W pewnym momencie stało się to, przynajmniej w niektórych kręgach, na tyle źle odbieranym sygnałem, że dziś prawie płaci się premię za to, żeby dana osoba z AI nie korzystała. Wiem, że to żywy temat w reklamie: reklama reprezentuje twój produkt i ludzie płacą dziś premię, by w ich reklamie nie było widać AI — przynajmniej oczywistego AI — bo klienci odbierają to źle. Bardzo zależy więc na tym, czym się zajmujesz. I jest szansa, że gdy coraz więcej prawników użyje AI, a część spraw przegra, bo były słabo przygotowane albo częściowo zmyślone, ustali się nowa równowaga. Na samym szczycie może nadal będą używać AI — ale płacisz im wtedy nie za to, że prowadzą więcej spraw, tylko za to, że wygrywają je lepiej, bo znalazły dobry sposób użycia. Nie jest to jednak tak proste, jak „damy każdemu lekarzowi na świecie AI i przyjmie dziesięć razy więcej pacjentów, a więc jakość opieki wzrośnie”.

David Ondrej: Nie mówiłem o jakości — o odsetku wydatków na oprogramowanie, który idzie po prostu w inferencję.

Armin Ronacher: Ale zapewne działa tu ruch przeciwny… Może działa, może nie. Najprawdopodobniej to, ile wydajemy dziś na tokeny, to ułamek tego, co będziemy wydawać za rok, dwa, trzy, cztery — przynajmniej jako społeczeństwo. To pewnie prawda. Ale czy tokeny pozostaną tak drogie, jeśli nie dostarczą aż tyle wartości, ile zakładamy? To inne pytanie. Nie jest całkiem wykluczone, że budujemy za dużo centrów danych w stosunku do tego, ile nas to kosztuje i ile firmy będą w stanie tego naliczyć. Konkurencja jest zacięta — może ceny po prostu będą musiały spaść, tak jak ceny energii spadają albo powinny spadać przy dostatecznej podaży. Energia słoneczna tanieje, więc może kiedyś tanieją i tokeny. Nie wiem, naprawdę nie wiem. Mam nadzieję, że społeczeństwo jakoś się wokół tego zbalansuje i nie skończy się tak, jak z mediami społecznościowymi — bo podejrzewam, że przynajmniej w Europie większość ludzi ich nie znosi, a mimo to ich używa.

David Ondrej: Mediów społecznościowych czy AI?

Armin Ronacher: Mediów — tego krótkiego wideo. Wszyscy tego używają. Ale gdyby zrobić sondaż, ludzie są niesamowicie sfrustrowani, a jednocześnie czują coś w rodzaju uzależnienia — jak z papierosów. I bardzo bym nie chciał, żebyśmy zbudowali AI podobnie: żeby wszyscy używali i jednocześnie wszyscy nienawidzili. To byłby nieszczęśliwy finał.

Europa

David Ondrej: Porozmawiajmy o Europie — wspominałeś o niej kilka razy. Ty jesteś z Austrii, ja z Czech. Czy po prostu odpływamy? Jak uratować ten kontynent?

Armin Ronacher: Odpływamy — to chyba prawda. Jak uratować kontynent? Dobre pytanie. Znam sporo sposobów, w jakie go nie ratujemy. Na pewno dzieje się teraz to, że zmotywowani ludzie — nie wszyscy, ale wystarczająco wielu — po prostu wyjeżdżają. To pewnie nie służy niczemu dobremu. Sytuacja wyjściowa nie jest zachwycająca. Fundamentalny problem Europy w obecnym stadium jest taki, że jest ona cała nastawiona na zachowanie tego, co było, a nie na umożliwianie tego, co nadejdzie. Przykładów mnóstwo. Ale Europa ma też pewne rzeczy lepiej poukładane niż inni — i gdyby inni znaleźli się w jej położeniu, też musieliby je poukładać. Rosnąca klasa średnia w Chinach będzie miała inne oczekiwania wobec życia niż Chiny do tej pory. Europa to społeczeństwo, w którym ludzie chcą wielu praw i w którym sprawy są bardziej wyrównane — a to utrudnia zaczynanie nowych rzeczy, bo wpadasz prosto w całą obowiązującą regulację. I to nie jest kwestia polityków, tylko tego, czego społeczeństwo chce — a społeczeństwo chce tego tak, jak jest. Nie chce centrów danych w stopniu, w jakim chcą je inne kraje; nie żywi wielkiego optymizmu wobec wielkich firm technologicznych, a jeśli już, to cieszy się, że ich tu nie ma. Mając to w pamięci, sytuacja jest po prostu trudna. Największym problemem Europy jest to, że nie jest ona jednym krajem. Stany Zjednoczone to ogromny jednolity rynek. Chiny to ogromny jednolity rynek. Indie to ogromny jednolity rynek. Rosja to w jakimś stopniu całkiem spory rynek — przynajmniej razem z tamtymi kilkoma krajami. Europa to 27 krajów, które nieustannie się szarpią — a potem Brytyjczycy wyszli w ogóle. To nie jest nawet kwestia języków. To dosłownie kwestia: czy każdy kraj europejski daje pełne prawa pracownicze każdemu obywatelowi Europy? Odpowiedź wciąż brzmi: każdy kraj stara się włożyć w to jak najwięcej tarcia, by chronić lokalną ludność kosztem pozostałych. Mamy 27 armii, 27 systemów prawnych, 27 pakietów regulacji pracowniczych. Zakładasz firmę — VAT w każdym kraju. To okropne. Dużo tego jest, a wynika to z tego, że nie przeszliśmy jeszcze do końca przez ideę, że po prostu jesteśmy Europejczykami. Nastawienie jeszcze na to nie pozwala. Może to musi być pierwszy krok, albo przynajmniej krok bardzo znaczący. W porównaniu z czasami mojego dzieciństwa poszło w dobrą stronę, bo pamiętam Austriaków głęboko krytykujących każdego sąsiada, który nie mówił po niemiecku. To się zmieniło. Dziś, jeśli już, chodzi o kraje spoza Unii: Czarnogórów, Albańczyków, może częściowo Ukraińców. Nieufność wobec innych Europejczyków, jeśli gdzieś siedzi, to na obrzeżach Unii — plus minus Norwegia, Wielka Brytania i Szwajcaria. Jest jej mniej niż kiedyś, ale wciąż dużo — i to trzyma Europę w miejscu od środka. I nie sądzę, żeby politycy mogli to naprawić. To kwestia tego, jak społeczeństwo do tego dojdzie — a społeczeństwo będzie musiać zaczynać sprzeciwiać się części tego, co dzieje się na poziomie unijnym. I dzieje się tak nie dlatego, że unijna biurokracja składa się z idiotów, tylko dlatego, że te kompromisy rodzą się z konieczności dogadania się 27 krajów — i to jest to, co z tego wychodzi. Taka jest nieszczęsna rzeczywistość.

Zakończenie

David Ondrej: Chyba możemy tu zakończyć — chcę uszanować twój czas. Dzięki, że przyszedłeś, Arminie. Gdzie mamy kierować ludzi?

Armin Ronacher: Gdzie kierować ludzi? Na pi.dev i stronę firmy. Prawdopodobnie tam.

David Ondrej: Podlinkuję wszystko pod filmem, razem z twoimi profilami. Jeszcze raz dzięki i miłego dnia.

Armin Ronacher: Dzięki za zaproszenie.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Bash i potoki zamiast stosu narzędzi

Na czym polega: Pi wygrywa nie pomysłowością interfejsu, a tym, że daje modelowi niemal wyłącznie bash. Model sam układa polecenia w potoki, dodaje znaczniki oddzielające wyniki i tym samym oszczędza kontekst — a nawet rozbudowane narzędzia, takie jak Codex, w praktyce i tak schodzą do ripgrepa i powłoki.

Jak stosować: Przy wyborze lub budowaniu opakowania agenta pytaj nie „ile ma narzędzi”, lecz „jak sprawnie gospodaruje kontekstem”. Własne automatyzacje buduj jako skrypty powłoki, które agent może łączyć w łańcuchy, a nie jako osobne funkcje narzędziowe.

Na co uważać: Każde dodane narzędzie to dodatkowy opis w kontekście i potencjalne źródło zamieszania; nadmiar własnych rozszerzeń potrafi pogorszyć wyniki zamiast je poprawić.

2.Wybieraj technologie dobrze reprezentowane w danych treningowych

Na czym polega: Agenty świetnie radzą sobie z Linuksem, gitem czy Markdownem, bo najwięcej materiałów o nich trafiło do danych treningowych; Windows wypada z tego rozkładu, a macOS jest słabiej reprezentowany. Obecność w danych to dziś realna przewaga — firmy celowo zabiegają o to, by być „pierwszym wyborem agenta”.

Jak stosować: Przy starcie projektu wybieraj stack szeroko obecny w otwartych repozytoriach i dokumentacji (Linux, git, popularne frameworki, formaty tekstowe). Jeśli tworzysz produkt dla programistów, publikuj dokumentację i przykłady tak, aby trafiały do corpusów i wyników wyszukiwania.

Na co uważać: Niszowe, własnościowe narzędzia mogą działać u ludzi, ale agent będzie przy nich błądził; dodatkowo sam model ma pamięć z konkretnej daty granicznej — sprawdzaaj aktualną dokumentację w kontekście, a nie tylko „wiedzę” modelu.

3.Trzymaj środowisko deweloperskie na maszynie, którą kontrolujesz

Na czym polega: Zespół stojący za Pi pracuje „po staremu”: agenty lokalnie, stacjonarny Linux dostępny przez SSH, drobna automatyzacja w GitHub Actions. W chmurze bardzo łatwo o złudzenie działającego środowiska — w historii z rozmowy testy bazodanowe „przechodziły”, bo cała baza była zamockowana i Postgres nigdy tak naprawdę nie wystartował.

Jak stosować: Zanim przeniesiesz pracę agentów do chmury, zweryfikuj, czy kluczowe zależności (bazy, kolejki, usługi) faktycznie tam działają — najlepiej testem dymnym uruchamianym celowo. Dostęp do własnej maszyny zorganizuj przez Tailscale lub SSH.

Na co uważać: To podejście wymaga samodzielnej konfiguracji i bywa niewygodne; wygoda chmury rośnie szybko, więc okresowo weryfikuj, czy tarcie nie przewyższyło już korzyści.

4.Przy wielu agentach planuj osobne środowiska

Na czym polega: Jeden zestaw deweloperski wystarczał, gdy nad kodem pracował jeden człowiek. Siedem równoległych agentów oznacza zapotrzebowanie na siedem baz danych i siedem klastrów Kafki — a start środowiska od zera, nawet z pamięcią podręczną, potrafi zająć kilka minut, co przy każdej zmianie robi się kosztowne.

Jak stosować: Jeśli równolegle używasz wielu agentów (np. na osobnych drzewach roboczych gita), przygotuj z góry pulę środowisk albo mechanizm ich szybkiego odtwarzania; rozdziel też obciążenie testami w czasie, zanim wentylatory w laptopie zacną kręcić na maksimum.

Na co uważać: Pula środowisk szybko komplikuje się w utrzymaniu — to wciąż obszar bez ustalonych standardów i łatwo o własne, nieudokumentowane „patenty”.

5.Pilnuj przenośności sesji i buduj trwałe agenty

Na czym polega: Nowe funkcje zamkniętych modeli potrafią zamykać użytkownika w ekosystemie — kompresja sesji po stronie serwera tworzy sesję, której nie przeniesiesz do innego dostawcy. Do tego brakuje mechanizmów trwałości: agenta nie da się dziś czysto uśpić i wznowić tam, gdzie skończył.

Jak stosować: Przy wyborze modelu i opakowania sprawdzaj, co dzieje się z historią sesji: czy da się ją wyeksportować, przenieść, wznowić po przerwie. Długie zadania projektuj tak, aby dało się je przerwać i dokończyć — np. zapisując stan w plikach, a nie tylko w rozmowie.

Na co uważać: Wygoda funkcji „tylko u nas” bywa pułapką przy zmianie dostawcy lub modelu; koszty migracji rośnie z każdym miesiącem pracy w zamkniętym ekosystemie.

6.Agenty obniżają koszt złożoności — korzystaj z tego świadomie

Na czym polega: Rozwiązania zawsze lepsze, ale zbyt trudne dla ludzi — Rust, NixOS, złożone bazy, Kafka — stają się osiągalne, bo agent wzieł je opanował z materiałów z sieci. To nie wymaga przełomu w AI, lecz dopasowania architektury do nowych „użytkowników”.

Jak stosować: Przy architekturych decyzjach przelicz raz jeszcze opcje odrzucone kiedyś jako „za trudne w utrzymaniu” — z agentem ich koszt utrzymania spada. Problemy interfejsów dla agentów rozwiązuj klasycznie: zarządzanie stanem, komponenty, bezpieczny dostęp do danych.

Na co uważać: Skłonność agentów do danego narzędzia nie zwalnia z weryfikacji, czy ono naprawdę pasuje do problemu; „model to zna” to argument pomocniczy, nie przesądzający.

7.Zostaw człowieka w pętli i czytelne artefakty

Na czym polega: Na końcu każdego łańcucha stoi człowiek — produkt krajowy tworzą ludzie kupujący, a odpowiedzialność wymaga, kogo można winić. Dlatego banki nie będą „vibe code’ować”, a ludzie będą chcieć widzieć to samo, co widzi agent, bez pytania innego agenta, który może kłamać. Stąd wygrywają Markdown, JSON i uniksowe potoki.

Jak stosować: Projektując procesy z agentami, generuj trwałe, czytelne artefakty: dokumenty, raporty, logi, definicje w plikach tekstowych. Takie, które przejrzy człowiek — i które posłużą następnemu agentowi.

Na co uważać: Systemy, w których człowiek widzi tylko wynik binarny, tracą zaufanie w chwili awarii; jeśli nikt nie umie wyjaśnić decyzji, odpowiedzialność spadnie na operatora i ten z czasem odmówi pracy z narzędziem.

8.Mierz wynik biznesowy, nie tokeny i commity

Na czym polega: Wydatki na AI, infrastrukturę i skanowanie bezpieczeństwa rosną błyskawicznie, a wymierny wpływ na wyniki firm — powolnie. Poza liczbą commitów większość organizacji nie potrafi pokazać realnego efektu; lepiej dziś wypadają projekty poboczne entuzjastów niż masowe wdrożenia w korporacjach.

Jak stosować: Przed skalowaniem wdrożenia ustal konkretny, mierzalny wskaźnik (np. liczba zamkniętych zgłoszeń wsparcia, czas dostarczenia zmiany, przychód na pracownika) i porównuj go z całkowitym kosztem, włącznie z czasem poświęcanym na nadzór nad agentami.

Na co uważać: Liczba commitów i spalonych tokenów to mierniki aktywności, nie wartości; pochwała „palam więcej tokenów niż ty” mówi o budżecie, nie o sukcesie.

9.Oceniaj zależności po trwałości, nie po hype

Na czym polega: Dobre projekty otwarte — curl, Django, PHP, Sentry — nie wygrały nowatorskością na starcie, lecz latami nieprzerwanej pracy. Jedynym sensownym kryterium jest pytanie: czy projekt będzie istniał i pozostawał otwarty za dziesięć–piętnaście lat? Oceniamy to dopiero po fakcie.

Jak stosować: Przy wyborze biblioteki czy narzędzia badaj historię utrzymania, regularność wydań, aktywność utrzymujących i sytuację licencyjną, a nie tylko popularność w danym tygodniu. Do własnego projektu wbuduj nawyk ciągłości: rytm wydań i ogarnianie zgłoszeń budują zaufanie skuteczniej niż premiera.

Na co uważać: Coraz więcej projektów otwiera kod wyłącznie jako kanał marketingowy (za darmową infrastrukturę i widoczność), by potem go zamknąć; na starcie sprawdź, kto finansuje utrzymanie i na jakich licencjach.

10.Rozszerzalność ponad rozbudowę

Na czym polega: Pi zdobyło uwagę, bo było minimalne, ale „własne” — dało się je dopasować do siebie. Tymczasem liderzy mnożący narzędzia powoli je redukują, a nowe opakowania przechodzą na wtyczki. Kierunek rynku: samorozszerzalne oprogramowanie, na którym każdy buduje swojego agenta.

Jak stosować: Wybierając narzędzie do pracy z agentami, uprzywilejuj takie, które pozwala dodawać własne polecenia i wtyczki oraz przenosić swoją konfigurację między projektami; własny zestaw rozszerzeń trzymaj w repozytorium, wersjonuj i dokumentuj.

Na co uważać: Rozszerzalność wymaga ogarniania tego, co sam dopisałeś — wtyczki też się starzeją i psują; minimalizm oszczędza kontekst, ale przerzuca odpowiedzialność za pomoce na ciebie.