O czym jest ten film
- Autor tłumaczy, dlaczego lokalne modele językowe „zawodzą” w Claude Code — problemem nie jest sam model, lecz narzędzie (harness), które go otacza.
- Claude Code zużywa ok. 20–30 tys. tokenów kontekstu jeszcze przed pierwszą wiadomością użytkownika, co przy małych oknach kontekstowych lokalnych modeli (120–200 tys. tokenów) szybko prowadzi do spadku jakości odpowiedzi.
- Rozwiązaniem jest użycie lekkiego harnessu — Pi Agent SDK (lub OpenCode) — który udostępnia modelowi minimalny zestaw narzędzi.
- Autor pokazuje instalację Pi Agent SDK (przez NPM) oraz Ollamy do uruchamiania modeli lokalnie, wraz z rekomendacją modelu Qwen 3.6 (wersje 27B i 35B parametrów).
- Omawia konfigurację modeli w pliku
models.jsonoraz przełączanie się między nimi komendą/modelw Pi. - Pokazuje działanie plików pamięci projektu (
agents.md), które pozwalają narzucić agentowi stałe zasady, np. trzymanie się systemu projektowego (design.md). - Ponieważ lokalne modele słabo radzą sobie z kreatywnym projektowaniem UI, autor poleca tworzenie systemu projektowego na podstawie zrzutu ekranu (np. z Dribbble) przy pomocy ChatGPT, Claude lub Google Stitch.
- Pi Agent SDK domyślnie nie ma dostępu do internetu ani MCP — trzeba to doinstalować ręcznie z marketplace’u wtyczek (np. wtyczka do wyszukiwania w sieci).
- Kluczowym elementem całego procesu jest szczegółowy plan implementacji przygotowany przez mocniejszy model (ChatGPT/Claude), następnie podzielony na mniejsze, sekwencyjne pliki funkcji, które lokalny model realizuje jedna po drugiej.
- Na koniec autor pokazuje wdrożenie gotowej strony na hosting (Hosting Go) jako statycznej witryny HTML.
Redakcyjne tłumaczenie
Problem nie leży w modelu, lecz w harnessie
Wszyscy powtarzają, że lokalne modele są bezużyteczne do prawdziwego kodowania. Pobierasz model, podpinasz go pod Claude Code i wszystko się sypie. Ale nikt nie mówi ci jednego: winny nie jest model — winny jest harness, czyli narzędzie (agent kodujący), w którym ten model działa.
W momencie, gdy otwierasz Claude Code, do okna kontekstu trafia około 20 tysięcy tokenów systemowego prompta i wewnętrznych narzędzi Anthropic — zanim jeszcze wyślesz pierwszą wiadomość. Nie masz nad tym żadnej kontroli. To wszystko dzieje się zanim w ogóle dodasz MCP czy dodatkowe skille.
Rozwiązaniem jest uruchamianie darmowych, lokalnych modeli w lekkim harnessie. W tym materiale przyjrzymy się Pi Agent SDK — pokażę wam workflow, który pozwala niezawodnie budować oprogramowanie za pomocą darmowych modeli.
(Informacja dodatkowa: „harness” to warstwa oprogramowania otaczająca model — system promptów, zestaw narzędzi i logika sterująca, w której działa agent AI. To ona, a nie sam model, odpowiada za większość zużycia kontekstu.)
Dlaczego okno kontekstu ma znaczenie
Pamiętajcie, że te modele działają na waszym własnym sprzęcie — są ładowane do pamięci VRAM karty graficznej i mogą pomieścić ograniczoną liczbę tokenów. Zwykle jest to około 120 tysięcy tokenów, a w większych modelach — do około 200 tysięcy.
Problem polega na tym, że jeśli korzystacie z harnessu takiego jak Claude Code, który automatycznie zużywa 20–30 tysięcy tokenów, bardzo szybko wchodzicie w tzw. „strefę głupoty”. Wszystkie modele — łącznie z flagowymi modelami Anthropic i OpenAI — mają z tym problem. Po przekroczeniu pewnego progu zapełnienia okna kontekstu (zwykle 50–70%) jakość i inteligencja odpowiedzi modelu zaczynają spadać. Dlatego zaleca się, by instrukcje w ramach sesji były maksymalnie zwięzłe i konkretne — naprawdę nie chcecie zbliżać się do granicy okna kontekstu.
Dla darmowego modelu z zaledwie 120 tysiącami tokenów nie stać nas na to, by 30% tej puli spalić wyłącznie na sam harness Claude Code. Jest jeszcze jedna istotna rzecz: darmowe modele bardzo szybko się gubią i przytłacza je nadmiar informacji. Po prostu nie mają takich zdolności wywoływania narzędzi i rozumowania jak modele flagowe. A skoro harnessy typu Claude Code zawierają mnóstwo narzędzi, takie agenty zaczynają się gubić i nie wiedzą, co robić.
Dlatego warto sięgnąć po lekki harness, np. Pi Agent SDK albo OpenCode (o którym mówiłem w poprzednim materiale). Te narzędzia wstrzykują minimalną liczbę narzędzi potrzebnych agentowi kodującemu. W przypadku Pi Agent SDK jest to naprawdę bardzo niewiele — agent może w zasadzie tylko przeglądać i modyfikować pliki w konkretnym folderze. Natywnie nie obsługuje MCP, skilli, wyszukiwania w sieci ani innych narzędzi, które mogłyby zapychać kontekst. Można jednak łatwo dodać te możliwości samodzielnie, korzystając z ich marketplace’u wtyczek. Idea Pi Agent SDK polega na tym, by dać wam szybki i lekki harness, a potem to wy decydujecie, jakim „bloatem” chcecie go dociążyć.
Instalacja Pi Agent SDK i Ollamy
Żeby zacząć, skonfigurujmy Pi Agent SDK. Wystarczy wejść na pi.dev, wybrać instalację przez NPM, skopiować komendę, a następnie uruchomić ją w terminalu (Command Prompt, PowerShell albo dowolnym innym). Po instalacji można sprawdzić, czy wszystko działa, uruchamiając komendę pi — powinien pojawić się interfejs czatu.
Żeby uruchamiać model lokalnie na własnej maszynie, instalujemy Ollamę. Wchodzimy na ollama.com, klikamy „Download Ollama”, wybieramy system operacyjny i instalujemy. Po instalacji uruchamiamy w terminalu komendę ollama — jeśli pokaże się menu, wszystko zadziałało. Teraz wystarczy pobrać model, wchodząc w sekcję modeli na stronie Ollamy.
(Informacja dodatkowa: warto poprosić ChatGPT lub Claude o rekomendację modeli dopasowanych do konkretnej karty graficznej i ilości VRAM, zanim zdecydujecie się na pobranie dużego modelu.)
Autor poleca Qwen 3.6 jako obecnie najlepszy bazowy model do kodowania, jaki można uruchomić na własnym sprzęcie. Występuje w dwóch wariantach: 27 miliardów parametrów (wymaga ok. 16 GB VRAM) oraz 35 miliardów parametrów (ok. 24 GB VRAM). Wystarczy skopiować nazwę modelu i w terminalu uruchomić ollama pull z tą nazwą. Aby przetestować model, uruchamiamy ollama run z nazwą modelu i wysyłamy prostą wiadomość, np. „Hey” — jeśli odpowiedź pojawia się strumieniowo, wszystko działa.
Podpięcie lokalnego modelu do Pi
Otwórzmy VS Code w pustym folderze projektu, uruchommy terminal i wpiszmy komendę pi. Żeby skonfigurować nowych dostawców i modele, uruchamiamy komendę /model. Jeśli nie zarejestrowaliście się wcześniej w żadnym z usługowych modeli (Gemini, Codex, Claude Code), lista może być pusta — chcemy przecież uruchamiać modele lokalne.
Ten krok jest jedynym w filmie, który może wydawać się nieco bardziej techniczny, ale nie jest trudny. W folderze domowym użytkownika (w Windows będzie to folder użytkownika) znajduje się ukryty folder z kropką na początku nazwy. Wewnątrz niego jest folder agent, a w nim plik models.json. Jeśli plik nie istnieje, można go po prostu utworzyć samodzielnie.
W pliku models.json dodajemy konfigurację modeli z Ollamy lub LM Studio (jeśli ktoś woli korzystać z tego narzędzia do lokalnego wnioskowania). Żeby dodać kolejne modele, wystarczy skopiować istniejący wpis w tablicy models i zmienić nazwę modelu — dla LM Studio działa to identycznie. Plik konfiguracyjny autora jest dostępny do pobrania w opisie filmu, w jego darmowej społeczności.
Po skonfigurowaniu obu źródeł, w Pi uruchamiamy /model i wyszukujemy Qwen 3.6 — ponieważ model jest skonfigurowany zarówno w Ollamie, jak i LM Studio, pojawiają się dwa wpisy. Wybieramy Ollamę i testujemy odpowiedzią „hey”. Jeśli wszystko skonfigurowano poprawnie, powinniśmy otrzymać odpowiedź.
Żeby wyczyścić rozmowę i zacząć nową sesję, wystarczy komenda /new. Aby zamknąć agenta kodującego Pi, używamy komendy /quit.
Pliki pamięci projektu i system projektowy
Pi Coding Agent obsługuje również pliki pamięci. W folderze projektu tworzymy plik agents.md, w którym możemy ustawić dowolne reguły projektu — jako żart autor ustawia regułę „odpowiadaj jak pirat” i po uruchomieniu agenta faktycznie odpowiada on w ten sposób.
Znacznie bardziej praktyczne jest dodanie reguł dotyczących interfejsu i stylistyki, np. „zawsze używaj tego systemu projektowego”, z odniesieniem (tagiem) do pliku design.md. Taki plik trzeba utworzyć w katalogu głównym projektu — będzie on zawierał system projektowy: typografię, kolory, odstępy, zaokrąglenie krawędzi i wszystko inne potrzebne do budowy strony.
Jeśli budujecie strony dla klientów, dobrym pomysłem jest pozyskanie tych informacji bezpośrednio od klienta i zapisanie ich w pliku design.md.
(Informacja dodatkowa: autor wspomina, że posiada osobny, płatny kurs o tworzeniu systemów projektowych — od podstaw po korzystanie z narzędzi takich jak Google Stitch czy Claude, dostępny w ramach jego platformy Agentic Labs.)
Plik design.md można dołączyć do promptu przez przeciągnięcie i upuszczenie w czacie, albo otagowanie go bezpośrednio w wiadomości. Po poleceniu „stwórz system projektowy dla restauracji” — dla kogoś, kto wcześniej korzystał z Claude Code razem z Pi Agentem — różnica jest natychmiast widoczna: ponieważ ten harness jest tak lekki, agent działa błyskawicznie szybko.
Po wygenerowaniu systemu projektowego warto go przejrzeć i poprawić to, czego nie potrzebujemy. Ponieważ system jest otagowany w pliku pamięci, agent powinien z niego korzystać automatycznie. W nowej sesji można polecić: „stwórz landing page dla restauracji ‘The Oak and Barrel’”. Agent potwierdza, że dogłębnie rozumie cały system projektowy, po czym buduje stronę — łącznie z subtelnymi animacjami przy przewijaniu.
Ograniczenia kreatywne modeli lokalnych i alternatywy
Lokalne modele nie radzą sobie zbyt dobrze z tworzeniem dobrych systemów projektowych od zera — brakuje im tej kreatywności. Dlatego autor poleca skorzystanie z serwisu takiego jak Dribbble: znaleźć tam szablon, który się podoba, skopiować obraz i użyć np. ChatGPT lub Claude do stworzenia na jego podstawie systemu projektowego, a następnie pobrać z niego wygenerowany plik.
Inną, darmową alternatywą jest Google Stitch — wystarczy wkleić obraz, polecić „stwórz system projektowy na podstawie tego obrazu”, wybrać tryb web oraz model „Thinking with 3.1 Pro” i wysłać zapytanie. Stitch również wygeneruje system projektowy, który następnie można pobrać (prawy klik → download) i przenieść jako plik design.md do folderu projektu.
To daje kilka sposobów podejścia do systemu projektowego: jeśli projektant przekazał wam zrzut ekranu, po prostu wrzućcie go do Google Stitch i wygenerujcie na jego podstawie system projektowy.
Doinstalowywanie skilli i MCP
Po skonfigurowaniu folderu projektu i systemu projektowego kolejnym krokiem może być instalacja skilli lub serwerów MCP. Domyślnie Pi Agent SDK nie obsługuje tego od razu. Przykład: pytanie „jakie są najnowsze wiadomości od OpenAI?” w Claude Code czy Codex spowoduje automatyczne wywołanie narzędzia do wyszukiwania w sieci. W Pi Coding Agent model odpowiada natomiast, że nie ma dostępu do internetu w czasie rzeczywistym — i tak jest to zaprojektowane celowo.
Harness Pi Coding Agent jest domyślnie lekki, a rozszerzenia dodaje się samodzielnie w sekcji „packages”, gdzie można filtrować rozszerzenia po liczbie pobrań. Znajdziemy tam dodatki niemal do wszystkiego: dostęp do sieci dla Pi, subagentów Pi, adapter MCP dla Pi (pozwalający agentowi wywoływać narzędzia MCP).
Żeby dać agentowi dostęp do internetu, wystarczy przejść do „Pi Web Access”, skopiować komendę instalacyjną i uruchomić ją w terminalu. Po ponownym uruchomieniu agenta i zadaniu tego samego pytania o wiadomości od OpenAI, model tym razem ma dostęp do narzędzia wyszukiwania — otwiera nawet konkretną stronę internetową i przygotowuje krótki dokument badawczy, który można zatwierdzić.
Ponieważ zależy nam na utrzymaniu lekkości harnessu, autor rezygnuje z dalszego instalowania skilli i narzędzi MCP w tym materiale.
Kluczowy element workflow: szczegółowy plan implementacji
Na tym etapie autor zaleca stworzenie szczegółowego planu implementacji dla strony internetowej — i podkreśla, że to najważniejsza część całego workflow. Jeśli plan jest słaby, wynik również będzie słaby. Z bardzo szczegółowym planem można natomiast użyć nawet bardzo słabego modelu i wciąż osiągnąć dobre rezultaty.
Dlatego zamiast korzystać z lokalnego modelu do tworzenia planu, lepiej użyć czegoś w rodzaju ChatGPT lub Claude — nawet w darmowym planie — do jego wygenerowania. W ChatGPT można poprosić: „stwórz szczegółowy plan implementacji. Plan musi zawierać logiczną sekwencję funkcji, które programiści mogą wdrażać jedna po drugiej, aby osiągnąć finalny efekt. Powinien być na tyle szczegółowy, by mógł go zrealizować programista juniorski. Zwróć jako markdown” — a następnie opisać budowaną stronę: w przykładzie autora chodzi o stronę dla restauracji „The Oak and Barrel”, specjalizującej się w stekach, burgerach, winie i piwie rzemieślniczym.
Otrzymany, bardzo szczegółowy plan implementacji trafia z powrotem do folderu projektu — autor tworzy tam folder plans i w nim plik implementation-plan.md. Ten konkretny plan liczy aż 1364 linijki.
Dzielenie planu na mniejsze funkcje
Można by teraz wrzucić cały ten plik do czatu i polecić agentowi jego wdrożenie, ale pamiętajmy o wspomnianej wcześniej „strefie głupoty” — plik tej wielkości znacznie przekroczyłby okno kontekstu agenta. Zamiast tego wczytujemy ten plik i dodajemy polecenie: „muszę podzielić ten duży plik implementacji na osobne funkcje. Funkcje powinny zachować logiczną kolejność, np. 01-fundament itd. Programista powinien być w stanie zbudować całe rozwiązanie, wdrażając funkcje po kolei, z uwzględnieniem zależności między nimi”.
Po uruchomieniu tego polecenia agent dzieli ogromny plan implementacji na mniejsze fragmenty, którymi da się realnie pracować. Powstaje w ten sposób seria pojedynczych plików, które można wdrażać sekwencyjnie, aby zbudować całą stronę. Wdrożenie staje się teraz znacznie prostsze: czyścimy okno kontekstu, wczytujemy pierwszy plik i po prostu polecamy „zaimplementuj to”. Po zakończeniu czyścimy sesję, wczytujemy kolejny plik i ponownie prosimy o wdrożenie danej funkcji — i tak dalej, aż wszystkie zmiany zostaną zaimplementowane.
Autor wspomina, że jeśli ktoś nie chce robić tego wszystkiego ręcznie, Pi ma również rozszerzenie do trybu „goal” (podobne do trybów „goal” znanych z Claude Code czy Codex). Osobiście jednak nie poleca tego rozwiązania przy małych modelach, ponieważ główny wątek rozmowy nadal bardzo szybko się zapełni. Zamiast tego lepiej skupić się na wdrażaniu i testowaniu jednej funkcji na raz.
Praktyczny przykład — zdjęcia z Pexels
W trakcie realizacji planu autor dociera do kroku 15, który dotyczy pobierania zdjęć stockowych z serwisu Pexels — i to właśnie dlatego wcześniej zainstalowano funkcję wyszukiwania w sieci: żeby agent mógł skorzystać z narzędzia wyszukiwania, by znaleźć odpowiednie zdjęcia na Pexels. Pi pobiera te obrazy automatycznie.
Alternatywnie można pobierać zdjęcia z Pexels ręcznie — wyszukać np. „burgery” albo „restauracje”, wybrać zdjęcie w odpowiedniej rozdzielczości dla strony, pobrać je, dodać do projektu i po prostu polecić agentowi, żeby go użył.
Efekt końcowy
Po zakończeniu pracy agenta powstaje gotowa strona z górnym menu nawigacyjnym. W widoku mobilnym strona jest w pełni responsywna — przyciski układają się jedne pod drugimi, a górne menu zamienia się w menu typu „hamburger” przy mniejszych ekranach. Po przewinięciu w dół widać zdjęcia stockowe, czysty design z subtelnymi animacjami — wszystko działa poprawnie. Kliknięcie „zobacz pełne menu” prowadzi do strony z pozycjami menu i cenami, z możliwością filtrowania dań według kategorii.
Aplikację można dalej rozwijać, powtarzając ten sam workflow: dla każdej nowej funkcji tworzymy plan implementacji, dzielimy go na mniejsze funkcje i przekazujemy je pojedynczo agentowi. W ten sposób można dalej rozwijać projekt za darmo, korzystając z lokalnego modelu na własnym sprzęcie.
Wdrożenie strony na hosting
Ostatnim krokiem jest wdrożenie strony do internetu. Istnieje wiele firm hostingowych, ale autor korzysta z Hosting Go, uznając go za przystępny cenowo, niezawodny i łatwy w konfiguracji — link do niego znajduje się w opisie filmu. Dla osób budujących strony dla klientów dostępny plan pozwala hostować do 50 stron internetowych (lub do 100 po podniesieniu planu) i zapewnia darmową domenę na pierwszy rok.
Wystarczy wybrać plan i okres rozliczeniowy, a następnie wprowadzić dowolną domenę — w przykładzie autor wybiera „oakandbarrel.com”, domena będzie darmowa przez pierwszy rok (choć w demonstracji autor rezygnuje z jej rzeczywistej rejestracji). Autor dodaje też bonus: wpisanie kodu rabatowego „leonhosting” daje dodatkowe 10% zniżki.
Po dokończeniu procesu zakupu, z poziomu panelu hostingowego wchodzimy w „Websites” i klikamy „Add Website”, wybierając opcję niestandardowej strony PHP/HTML (w przypadku Next.js lub React należałoby wybrać Node.js). Ponieważ strona została zbudowana w prosty sposób, wybieramy HTML i albo rejestrujemy własną domenę, albo korzystamy z domeny tymczasowej.
Następnie z menu wybieramy „Website”, potem „Migrate Website” i klikamy „Migrate Website” ponownie. Na tej stronie wybieramy opcję przesłania plików kopii zapasowej i klikamy „Next”. Najprostszym sposobem jest otworzenie folderu projektu w Eksploratorze plików. Proces różni się nieco przy React lub Next.js — wtedy wystarczy spakować wszystkie pliki do archiwum ZIP i przesłać je do Hosting Go. Przy stronie w czystym HTML, tak jak w tym przykładzie, tworzymy nowy folder o nazwie public_html, przenosimy do niego wszystkie potrzebne pliki projektu (CSS, obrazy, JavaScript, pliki contact, index, menu), a następnie klikamy prawym przyciskiem na public_html i kompresujemy folder do archiwum ZIP, które dodajemy w Hosting Go. Klikamy „Next”, zatwierdzamy żądanie migracji — i po jej zakończeniu otrzymujemy adres URL, pod którym strona jest już dostępna z dowolnego miejsca. Jeśli przypisano niestandardową domenę, można korzystać z niej zamiast adresu tymczasowego.
Utrzymywanie strony jest równie proste: przy każdej zmianie w projekcie dodajemy zaktualizowane pliki do archiwum ZIP, wracamy na stronę hostingu, klikamy „Migrate” i ponownie „Migrate Website”, przechodząc przez ten sam proces — co spowoduje wgranie wszystkich nowych zmian.
Podsumowanie
Cały sekret pracy z lokalnymi modelami polega na zapewnieniu im na tyle lekkiego harnessu, by mogły osiągać dobre rezultaty.
10 najważniejszych takeaways — z kontekstem zastosowania
1.To harness, nie model, decyduje o jakości pracy z lokalnym AI
Na czym polega: Claude Code z góry zużywa ok. 20–30 tys. tokenów na system prompt i wewnętrzne narzędzia, jeszcze zanim zaczniesz pracę — to obciąża zwłaszcza modele o mniejszym oknie kontekstu.
Jak stosować: Przy korzystaniu z lokalnych modeli wybieraj lekkie harnessy, takie jak Pi Agent SDK czy OpenCode, zamiast domyślnie sięgać po Claude Code.
Na co uważać: Sam model może być dobry, ale w niewłaściwym środowisku i tak da słabe rezultaty — problem trzeba diagnozować na poziomie narzędzia, nie tylko modelu.
2.Pilnuj „strefy głupoty” w oknie kontekstu
Na czym polega: Po przekroczeniu ok. 50–70% zapełnienia okna kontekstu jakość odpowiedzi każdego modelu (także flagowych) zaczyna spadać.
Jak stosować: Utrzymuj instrukcje w danej sesji krótkie i konkretne, regularnie czyść kontekst komendą typu /new, zamiast prowadzić jedną, coraz dłuższą rozmowę.
Na co uważać: Przy lokalnych modelach z oknem rzędu 120 tys. tokenów margines błędu jest znacznie mniejszy niż przy modelach chmurowych ze znacznie większym kontekstem.
3.Dobierz model do dostępnego VRAM
Na czym polega: Model Qwen 3.6 dostępny jest w wariantach 27B (ok. 16 GB VRAM) i 35B (ok. 24 GB VRAM) parametrów.
Jak stosować: Przed pobraniem modelu sprawdź ilość VRAM swojej karty graficznej i dopasuj wariant modelu — ewentualnie poproś ChatGPT lub Claude o rekomendację dopasowaną do konkretnego sprzętu.
Na co uważać: Próba uruchomienia zbyt dużego modelu na zbyt małej ilości VRAM skończy się awarią lub drastycznym spowolnieniem działania.
4.Konfiguracja modeli w pliku models.json jest jednorazowa
Na czym polega: Pi Agent SDK wymaga ręcznego dodania modeli z Ollamy lub LM Studio do pliku models.json w folderze konfiguracyjnym agenta.
Jak stosować: Skonfiguruj plik raz, kopiując wzorcowy wpis dla każdego kolejnego modelu i zmieniając tylko jego nazwę; potem przełączaj się między modelami komendą /model.
Na co uważać: Jeśli plik nie istnieje, trzeba go stworzyć samodzielnie — brak tego kroku skutkuje pustą listą modeli w Pi.
5.Pliki pamięci (agents.md) narzucają stałe reguły projektu
Na czym polega: Plik agents.md w folderze projektu pozwala trwale ustawić zasady działania agenta, np. odwoływanie się do konkretnego systemu projektowego.
Jak stosować: Zapisuj w nim odniesienia do plików takich jak design.md, żeby agent automatycznie stosował ustalone reguły w każdej nowej sesji.
Na co uważać: Reguły w agents.md są tylko tak dobre, jak jasność i konkretność ich sformułowania — model może je zignorować, jeśli są zbyt ogólne.
6.Lokalne modele słabo radzą sobie z kreatywnym projektowaniem UI
Na czym polega: Modele lokalne mają ograniczoną „kreatywność” przy samodzielnym tworzeniu systemów projektowych od zera.
Jak stosować: Znajdź inspirację (np. na Dribbble) lub wykorzystaj zrzut ekranu od klienta, a system projektowy wygeneruj przy pomocy mocniejszego modelu (ChatGPT, Claude) lub narzędzia Google Stitch, dopiero potem przekaż go lokalnemu modelowi jako plik referencyjny.
Na co uważać: Poleganie wyłącznie na lokalnym modelu przy projektowaniu wizualnym może dać generyczny, mało dopracowany efekt.
7.Dostęp do internetu i MCP trzeba doinstalować ręcznie
Na czym polega: Pi Agent SDK domyślnie nie ma dostępu do sieci ani obsługi MCP — to celowy wybór projektowy, by harness pozostał lekki.
Jak stosować: Potrzebne funkcje (np. wyszukiwanie w sieci) dodawaj świadomie przez marketplace wtyczek Pi, tylko wtedy, gdy naprawdę są potrzebne do zadania.
Na co uważać: Każda dodana wtyczka zwiększa zużycie kontekstu — dodawaj tylko to, czego rzeczywiście potrzebujesz, żeby nie stracić przewagi lekkiego harnessu.
8.Szczegółowy plan implementacji jest ważniejszy niż sam model
Na czym polega: Bardzo szczegółowy plan pozwala uzyskać dobre rezultaty nawet ze słabszym modelem, podczas gdy słaby plan zepsuje efekt niezależnie od modelu.
Jak stosować: Plan implementacji twórz w mocniejszym modelu chmurowym (np. ChatGPT lub Claude, nawet w darmowym planie), opisując dokładnie docelowy produkt i wymagając logicznej kolejności funkcji zrozumiałej dla juniorskiego programisty.
Na co uważać: Plan generowany przez sam lokalny model może być zbyt ogólny lub niekompletny — warto oddzielić etap planowania od etapu wdrażania.
9.Dziel duże plany na mniejsze, sekwencyjne pliki funkcji
Na czym polega: Ogromny plik planu (w przykładzie 1364 linijki) przekracza okno kontekstu lokalnego modelu, jeśli wgra się go w całości.
Jak stosować: Poproś agenta o podział planu na osobne pliki funkcji w logicznej kolejności (np. 01-fundament, 02-nawigacja itd.), a następnie wdrażaj je pojedynczo, czyszcząc kontekst między kolejnymi krokami.
Na co uważać: Autotryby typu „goal”, które automatyzują całą sekwencję wdrożenia, nie są zalecane dla małych modeli — główny wątek rozmowy i tak szybko się zapełni.
10.Statyczną stronę HTML można wdrożyć bez znajomości DevOps
Na czym polega: Gotową stronę zbudowaną lokalnie da się wdrożyć na hosting (w materiale: Hosting Go) poprzez spakowanie plików do archiwum ZIP i przesłanie ich przez panel migracji.
Jak stosować: Pliki projektu HTML umieść w folderze public_html, spakuj do ZIP i prześlij przez opcję „Migrate Website”; przy React/Next.js wybierz zamiast tego środowisko Node.js.
Na co uważać: Każda kolejna zmiana w projekcie wymaga ponownego spakowania i przesłania całego archiwum — proces trzeba powtarzać ręcznie przy każdej aktualizacji.