Agent kodujący Pi: Tworzenie elastycznych narzędzi AI do rzeczywistych przepływów pracy

Wprowadzenie

Kod nigdy nie jest darmowy. To główny argument, który Mario Zechner, twórca Pi, wysuwa podczas dyskusji o stanie programowania wspomaganego przez AI w 2026 roku. Choć agenci potrafią szybko generować ogromne ilości kodu, konsekwencje tego kodu w końcu nas dopadną. Pi istnieje, ponieważ Zechner uznał, że istniejące agenty kodujące nie pasują do jego przepływów pracy, więc zamiast się dostosowywać, stworzył narzędzie, które dostosowuje się do niego.

Ta rozmowa obejmuje powody, dla których stabilność przepływu pracy jest ważniejsza niż szybkość dodawania funkcji, jak faktycznie pracować z agentami kodującymi bez wypalenia oraz dlaczego branża może powtarzać 30-letni błąd związany z programowaniem opartym na specyfikacji.

Dlaczego Pi istnieje: Elastyczność przepływu pracy ponad stabilność

Kiedy Claude Code zadebiutował, Zechner był z niego zadowolony. Z czasem jednak wysoka częstotliwość aktualizacji narzędzia stała się problemem. Claude Code otrzymuje od jednej do trzech aktualizacji dziennie, a z każdą z nich pojawiają się zmiany w definicjach narzędzi, promptach systemowych i podstawowym zachowaniu. Dla kogoś, kto buduje własne szablony promptów, komendy typu slash i opisy przepływów pracy, te niewidoczne zmiany psują wszystko.

Sam model wydawał się zachowywać inaczej z dnia na dzień, mimo że wersja modelu pozostawała ta sama. Zechner przypisuje to częściowo zmianom w „uprzęży” (harness) — infrastrukturze i promptach systemowych, które kształtują sposób odpowiedzi modelu. Testowanie wpływu zmian w uprzęży na jakość wyników jest trudne, ponieważ nie ma deterministycznego sposobu, aby to zmierzyć. W rezultacie programiści tacy jak Zechner nie mogą polegać na spójnym zachowaniu narzędzia, co niweczy sens budowania wokół niego niestandardowych przepływów pracy.

Pi narodziło się z tej frustracji. Jest to minimalny, rozszerzalny agent kodujący, który może modyfikować się tak, aby pasował do Twoich przepływów pracy, zamiast zmuszać Cię do adaptacji do jego ograniczeń. Podstawowa architektura abstrahuje dostawców LLM, zawiera bibliotekę interfejsu terminala i zapewnia ogólne abstrakcje pętli agenta. Kluczową różnicą jest jednak kontrola: Zechner dyktuje projekt i może go zmieniać bez czekania na cykl wydawniczy dostawcy.

Jak faktycznie działa Pi: Przetwarzanie równoległe i ręczna weryfikacja

Codzienny przepływ pracy Zechnera z Pi jest metodyczny i celowo niskotechnologiczny. Nie uruchamia armii agentów równolegle. Zamiast tego stosuje podejście „jaskiniowca”: kolejkuje wiele sesji, z których każda analizuje inny problem ze zgłoszenia, a następnie przegląda i iteruje każdą z nich.

W przypadku poprawek błędów i implementacji funkcji proces zaczyna się od opisu problemu. Zechner przekazuje problem agentowi z niestandardowym szablonem promptu, który mówi: pobierz wszystkie istotne informacje, zignoruj analizę zawartą w zgłoszeniu i przeprowadź własną analizę w oparciu o to, co chcemy osiągnąć. Ten etap analizy zajmuje około pięciu minut na zgłoszenie. Otwiera drugą sesję dla kolejnego problemu, trzecią dla następnego, tworząc równoległy potok przetwarzania wstępnego.

Gdy agent kończy analizę problemu, Zechner przegląda sugestie, samodzielnie sprawdza kod i w razie potrzeby ręcznie odtwarza problemy. Używa agenta jako „gumowej kaczuszki” — partnera do myślenia — dopóki nie zgodzi się sam ze sobą co do podejścia do implementacji. Zanim poleci agentowi wdrożenie, kontekst zawiera tak wiele zabezpieczeń, że agent dokładnie wie, które interfejsy zmodyfikować, które moduły dotknąć i jak powinny działać testy.

Implementacja zajmuje kolejne 10 do 30 minut. Gdy agent sygnalizuje zakończenie, Zechner otwiera przeglądarkę diff i dodaje adnotacje do poszczególnych linii z informacją zwrotną. Klika „zakończ”, informacja zwrotna automatycznie trafia do agenta i iteracja trwa, aż kod będzie dobry. W przypadku kluczowych mechanizmów przegląda każdą zmianę tak, jak robiłby to z człowiekiem. W przypadku innych elementów zatwierdza je bez głębokiej inspekcji.

Ten przepływ pracy działa, ponieważ Zechner ma ponad 10-letnie doświadczenie w bazach kodu. Wie, co działa, a co nie. Dla nowych programistów lub osób bez takiego doświadczenia podejście to byłoby inne — i bardziej ryzykowne.

Realia programowania opartego na specyfikacji

Branża powtarza 30-letni błąd. Programowanie kaskadowe (Waterfall) okazało się nieskuteczne dekady temu, a jednak dzięki agentom AI wróciliśmy do „hiper-kaskady”: pisania szczegółowych specyfikacji i zlecania ich implementacji agentom. Jedyna różnica polega na tym, że teraz nawet nie piszesz specyfikacji samodzielnie — używasz „vibe promptingu”, aby agent napisał bardzo szczegółową specyfikację, którą następnie implementuje inny agent.

Problem jest fundamentalny. Kompletna specyfikacja jest w istocie samym programem. Jeśli piszesz specyfikację w języku naturalnym, pozostawiasz luki. Agent wypełnia te luki wzorcami, których nauczył się z 20 lat kodu w internecie — z czego większość to śmieci. Rezultatem jest baza kodu, która wygląda jak oprogramowanie stworzone „na wyczucie”, ponieważ tak właśnie jest.

Istnieje kontrargument: kod jest teraz tani, a iteracja szybka. Wcześniej implementacja specyfikacji kaskadowej mogła zająć miesiące. Teraz może zająć dzień. Możesz przetestować to ręcznie. Jednak Zechner nie widział jeszcze dowodów na to, że faktycznie sprawdza się to w oprogramowaniu produkcyjnym. Podejrzewa, że w końcu programiści będą budzić się w nocy, zdając sobie sprawę, że wszystko jest zepsute.

Niemniej jednak istnieją ograniczenia, w których programowanie sterowane przez agentów ma sens. Przepisanie Bun z Zig na Rust zadziałało, ponieważ projekt miał rozbudowany zestaw testów. Agent mógł w pewnym stopniu zweryfikować własną pracę. W takich przypadkach narzędzia tego typu są naprawdę przydatne. Ale dla większości oprogramowania podejście to jest ryzykowne.

Zarządzanie open source na dużą skalę: Problem „Clankerów”

Przed erą agentów udany projekt open source mógł otrzymywać jeden lub dwa pull requesty tygodniowo. Pi otrzymuje teraz 50 do 60 pull requestów dziennie — wszystkie od agentów (Zechner nazywa je „clankerami”). Każdy PR ma opis długości książki o Harrym Potterze i zawiera od 10 do 1000 zmian w plikach.

Domyślną pozycją jest uznanie każdego wygenerowanego przez agenta PR za śmieci i automatyczne zamknięcie go. Zechner znalazł jednak rozwiązanie: wymagać od ludzi, aby najpierw napisali zgłoszenie (issue) własnym głosem, nie dłuższe niż jeden ekran, wyjaśniając dokładnie, co chcą zrobić i dlaczego. Jeśli zgłoszenie jest dobre, zatwierdza je i dana osoba może wysłać PR. To dowodzi, że są ludźmi, rozumieją problem i rozumieją rozwiązanie.

Po zatwierdzeniu napływają sensowne PR-y. PR-y od „clankerów” przestają się pojawiać. Zgłoszenia nadal napływają, ale Zechner segreguje je ręcznie. Czyta od 30 do 60 zamkniętych zgłoszeń dziennie, identyfikując, które są uzasadnione, a które są śmieciami. W jego ostatniej sesji segregacji wpłynęło 50 zgłoszeń, a przetrwały 2. Zajmuje to około 30 minut, ponieważ większość łatwo zidentyfikować jako szum.

Dla projektów na skalę OpenClaw to ręczne podejście nie działa. Zużycie tokenów Petera Steinbergera osiągnęło 1,3 miliona dolarów miesięcznie, częściowo dlatego, że automatyzacja filtrowania zgłoszeń i PR-ów na taką skalę wymaga zaawansowanej infrastruktury. Zechner napisał kilka narzędzi wizualizacyjnych, aby pomóc w grupowaniu podobnych zgłoszeń, ale nawet to nie wystarczyło. Skala jest o rzędy wielkości większa.

Wnioskowanie lokalne i przyszłość mniejszych modeli

Zechner jest optymistą w kwestii uruchamiania wydajnych modeli AI lokalnie na sprzęcie konsumenckim. Do swojego projektu robota — zabawki z smartfonem jako mikrokontrolerem uruchamiającym agenta kodującego — używa Gemma 4 i Qwen 3.6, mniejszych modeli typu mixture-of-experts. Są one więcej niż wystarczające dla chatbota z kontrolą silnika i kamery, a do tego są szybkie.

Konfiguracja jest przystępna cenowo. Zamiana mowy na tekst (speech-to-text) za pomocą Parakeet zajmuje około 10 gigabajtów zunifikowanej pamięci. Zamiana tekstu na mowę (text-to-speech) z Qwen TTS zajmuje kolejne 10 gigabajtów. Qwen 3.6 zajmuje 4 gigabajty. Łącznie: 14 gigabajtów zunifikowanej pamięci na macOS lub równoważnej konfiguracji NVIDIA na Windows. Jest to przystępne dla wielu osób, może nie dla całego świata, ale dla znacznej jego części.

Denise Asaves z DeepMind zasugerowała, że obecne gigantyczne modele nie potrzebują wszystkich swoich parametrów i mogą zostać destylowane do znacznie mniejszych modeli bez utraty jakości wyników. Zechner ma nadzieję, że przyszłość będzie polegać na destylowaniu dużych modeli do mniejszych, które zachowują większość możliwości, zamiast trenowania wyspecjalizowanych modeli do konkretnych zadań. Antirez z Redis zaczął pracować nad niestandardowym silnikiem wnioskowania dla DeepSeek V4 o nazwie ds4, uruchamiając go na laptopie ze 128 gigabajtami pamięci. To naprawdę wydajny model, który mógłby obsłużyć 60 do 70 procent problemów, z którymi Zechner radzi sobie za pomocą Pi.

Koszt kodu i dyscyplina rzemiosła

Zechner widział ludzi generujących 500 000 linii kodu za pomocą agentów w ciągu tygodnia. Wynik jest zawsze ten sam: katastrofa. Kod nigdy nie jest darmowy, ponieważ konsekwencje w końcu cię dopadną. Jeśli myślisz, że jakakolwiek ilość kodu jest teraz dobra, po prostu odroczyłeś karę.

Prawdziwym wąskim gardłem w tworzeniu oprogramowania nie jest szybkość pisania na klawiaturze ani generowanie kodu. Jest nim myślenie, projektowanie i eksploracja przestrzeni rozwiązań. Agenci są naprawdę przydatni na tym etapie — możesz polecić wielu agentom zbadanie różnych podejść i zobaczyć wyniki szybciej. Ale wyniki tych eksploracji nie nadają się automatycznie do ponownego użycia. Nadal musisz je zrozumieć, zrefaktoryzować i utrzymywać.

Dla Zechnera największy wzrost produktywności dzięki agentom wynika z asynchronicznej natury pracy. Może dać agentowi zadanie, pójść na spotkanie i wrócić do wyników. Nie wierzy jednak, że uruchomienie 10 agentów równolegle zwiększy jego wydajność 10-krotnie. Samo przełączanie kontekstu jest wyczerpujące. Robił to raz lub dwa razy w miesiącu, przetwarzając 30 zgłoszeń dziennie, i po tym jego mózg był jak papka.

Aspekt współpracy jest tym, co ceni najbardziej. Posiadanie agenta jako partnera do programowania w parach — zadawanie pytań, proponowanie opcji, wyjaśnianie kodu — jest jak rower dla umysłu. Pomaga mu lepiej przemyśleć problemy niż siedzenie w samotności. Ale wymaga to dyscypliny: nie delegowania wszystkiego na maszynę, ponieważ za każdym razem, gdy to robi, kończy w kącie płacząc, bo nic już nie jest dobre i wszystko się rozpada.

Refaktoryzacja Pi: Budowanie na przyszłość

Pi zgromadziło historyczny bagaż. Części z niego powstały przed użyciem agentów przez Zechnera i są solidne. Inne części, jak eksport do HTML, nigdy go nie interesowały i nie dba o nie, dopóki działają. Niektóre elementy są stworzone „na wyczucie”.

Prace nad refaktoryzacją mają kilka celów. Po pierwsze, łatwiejsze rozszerzanie o inne typy interfejsów użytkownika — web, natywne, cokolwiek — bez psucia istniejących rozszerzeń. Po drugie, umożliwienie pracy zdalnej: uruchomienie jednej sesji Pi na jednej maszynie i połączenie się z nią z innej, z odpowiednią trwałością i obserwowalnością. Po trzecie, sprawienie, by SDK Pi było możliwe do wdrożenia na Cloudflare Workers, Vercel i innych środowiskach, a nie tylko na lokalnych komputerach z bash.

Zechner refaktoryzuje główną gałąź (main branch), ponieważ nie dba o stabilność w tradycyjnym sensie. Robi to kawałek po kawałku, zaczynając od pakietów najniższego poziomu, które komunikują się z dostawcami LLM. Sam agent kodujący nadal będzie wyglądał i działał tak samo, ale cała podstawowa infrastruktura będzie czysta i gotowa do ponownego użycia. Ma nadzieję zakończyć tę fazę w tydzień lub dwa, a następnie poświęcić kilka kolejnych tygodni na nowy mechanizm rozszerzeń, w którym rozszerzenia mają komponenty po stronie serwera i interfejsu użytkownika.

Dlaczego Pi domyślnie działa w trybie YOLO

Pi nie prosi o pozwolenie przed wykonaniem kodu. Jest to zamierzone. Mówiąc ludziom, że tryb YOLO jest niebezpieczny i powinni o tym pomyśleć, Zechner faktycznie zmusza ich do myślenia o bezpieczeństwie. Chce, aby szukali świadomości bezpieczeństwa w sobie i decydowali, jak zabezpieczyć pracę agentową we własnym środowisku.

Odpowiedzią jest zazwyczaj konteneryzacja. Jeśli nie chcesz, aby agent zepsuł twój komputer, konteneryzuj agenta lub narzędzia, których używa — odczyt/zapis plików, bash, cokolwiek. To rozwiązuje problem. Ale Zechner nie może zdecydować tego za ciebie. Mógłby dołączyć piaskownicę Anthropic lub bubble wrap, ale są to niekompletne rozwiązania. W środowisku korporacyjnym z określonymi ograniczeniami infrastrukturalnymi wbudowana piaskownica może w ogóle nie działać.

To, co istnieje w Claude Code, to głównie teatr bezpieczeństwa. Claude Code prosi teraz LLM, czy komenda bash jest bezpieczna, zanim wykona ją w trybie automatycznym. Zechner nie uważa, że to dobrze. LLM nie może wiarygodnie określić, czy komenda jest bezpieczna — może tylko zgadywać na podstawie wzorców.

Podsumowanie

Pi reprezentuje inną filozofię: buduj narzędzia, które programiści mogą posiadać i modyfikować, a nie narzędzia, które posiadają programistów. Sukces Pi nie jest mierzony funkcjami czy benchmarkami, ale tym, czy Zechner może utrzymać mały zespół i kontynuować odkrywanie zastosowań pracy agentowej — od kodowania po robotykę i wnioskowanie lokalne.

Szersza lekcja jest taka, że przepływy pracy znaczą więcej niż szum medialny. Stabilność, przewidywalność i możliwość dostosowania narzędzi są warte więcej niż najnowsza funkcja. A kod nigdy nie jest darmowy — konsekwencje twoich działań w końcu cię dopadną.