O czym jest ten film
- Cole Medin opisuje, jak szybko wyczerpał limity swoich subskrypcji Claude Code i Codex, choć nie zwiększył znacząco ilości pracy.
- Proponuje, by w wieloetapowym procesie programowania dobierać model osobno do planowania, pisania kodu i przeglądu zmian.
- Za najważniejszy etap uważa przygotowanie szczegółowego planu. Przy dobrym planie kod może pisać mniejszy, tańszy model.
- W swoich próbach powierzał implementację modelowi GLM 5.3 Flash, a planowanie i przegląd — modelom DeepSeek v4.1 Flash, Claude Fable 5.1 lub GPT-6 Astra.
- Pokazuje obieg pracy: opis zadania w GitHubie, plan, implementacja, przegląd, poprawki i testy przed scaleniem.
- Taki proces można prowadzić ręcznie, przekazując kolejnym agentom dokumenty Markdown, albo zautomatyzować.
- Autor używa do automatyzacji własnego projektu Archon oraz usług dających dostęp do różnych modeli.
- Porównuje trzy wersje gry powstałe przy różnych podziałach pracy między modelami.
- W jego pokazie połączenie GPT-6 Astra z GLM 5.3 Flash dało lepszy wynik niż użycie samych modeli otwartych i kosztowało mniej niż wariant oparty na Claude.
- Materiał zawiera także sponsorowaną prezentację Scrimba Explain, narzędzia tworzącego objaśnienia kodu w formie krótkich lekcji wideo.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozpisz pracę na etapy, zanim wybierzesz modele
Na czym polega: Planowanie, pisanie kodu i jego ocena stawiają modelowi różne wymagania. Jeden model do wszystkiego może szybko wyczerpać dostępny limit.
Jak stosować: Wypisz etapy swojego procesu i przypisz każdemu osobny model. Zacznij od zadań, które najczęściej wykonujesz, aby móc porównać wyniki.
Na co uważać: Oszczędność tokenów nie pomoże, jeśli podział pracy utrudni przekazywanie kontekstu między etapami.
2.Najwięcej uwagi poświęć planowi
Na czym polega: W próbach autora jakość planu miała duży wpływ na to, czy mniejszy model poradził sobie z implementacją.
Jak stosować: Przed pisaniem kodu określ zakres zmian, oczekiwane zachowanie, istotne ograniczenia i sposób sprawdzenia wyniku. Przekaż wykonawcy taki plan w postaci dokumentu.
Na co uważać: Nawet sprawny model wykonawczy może wiernie zrealizować błędny lub niepełny plan.
3.Tańszy model skieruj do pisania kodu według planu
Na czym polega: Implementacja zwykle zużywa w tym procesie najwięcej tokenów. Autor używa do niej GLM 5.3 Flash.
Jak stosować: Wypróbuj mniejszy model przy zadaniu z jasno opisanym zakresem i porównaj kod oraz koszt z dotychczasowym sposobem pracy.
Na co uważać: Przy trudnym, słabo rozpoznanym problemie sam dobry opis zadania może nie wystarczyć. Autor dopuszcza wtedy użycie mocniejszego modelu na każdym etapie.
4.Mocny model wykorzystaj ponownie do przeglądu
Na czym polega: Po implementacji autor kieruje wynik do modelu, który potrafi ocenić zgodność kodu z planem i wskazać usterki.
Jak stosować: Poproś model oceniający o konkretne uwagi, a poprawki przekaż modelowi wykonawczemu. Ustal maksymalną liczbę takich rund.
Na co uważać: Sama opinia modelu nie zastępuje uruchomienia testów ani sprawdzenia, czy projekt się buduje.
5.Zacznij od prostego przekazywania dokumentów
Na czym polega: Do połączenia różnych agentów nie jest potrzebny od razu rozbudowany system. Każdy etap może zakończyć się plikiem Markdown dla następnego.
Jak stosować: Zapisz plan, przekaż go agentowi piszącemu kod, a następnie dostarcz zmiany agentowi robiącemu przegląd.
Na co uważać: Przy ręcznej pracy łatwo pominąć ważne ustalenie. Sprawdzaj, czy dokument przekazania zawiera wszystkie ograniczenia i decyzje.
6.Automatyzuj dopiero ustalony obieg pracy
Na czym polega: Archon pozwala autorowi wielokrotnie uruchamiać ten sam ciąg etapów z różnymi modelami.
Jak stosować: Gdy ręczny proces daje powtarzalne wyniki, połącz etapy tak, by plan i uwagi z przeglądu trafiały automatycznie do kolejnego agenta.
Na co uważać: Automatyczna pętla poprawek powinna mieć limit prób. Inaczej może zużywać zasoby bez wyraźnej poprawy wyniku.
7.Zostaw kontrolę jakości przed scaleniem zmian
Na czym polega: W pokazanym procesie po przeglądzie i poprawkach uruchamiane są testy oraz sprawdzany jest wynik budowania projektu.
Jak stosować: Uczyń te kontrole stałym warunkiem zakończenia zadania przez agentów.
Na co uważać: Przejście testów potwierdza tylko to, co testy rzeczywiście obejmują. Warto ocenić również samo działanie produktu.
8.Porównuj modele na tym samym zadaniu
Na czym polega: Autor budował różne aplikacje, a w filmie szczegółowo pokazuje trzy wersje jednej gry, wykonane przy różnych konfiguracjach modeli.
Jak stosować: Daj porównywanym zestawom ten sam opis zadania i ten sam sposób oceny. Zapisuj jakość wyniku, zużycie tokenów, koszt i czas.
Na co uważać: Jeden efektowny przykład nie dowodzi, że dana konfiguracja będzie najlepsza przy każdym rodzaju oprogramowania.
9.Nie utożsamiaj jakości kodu wyłącznie z modelem, który go napisał
Na czym polega: W najlepiej ocenionej przez autora wersji gry cały kod napisał GLM 5.3 Flash, ale plan przygotował i wynik sprawdził GPT-6 Astra.
Jak stosować: Oceniaj cały proces: jakość zadania, planu, kodu, przeglądu i poprawek.
Na co uważać: Wyniku tej pary modeli nie należy przypisywać wyłącznie tańszemu modelowi wykonawczemu.
10.Dobierz układ do trudności i stopnia nadzoru
Na czym polega: Autor podaje różne warianty: mocne modele przy planowaniu i przeglądzie, mocny model na każdym etapie trudnego zadania oraz modele otwarte w małych zadaniach pod nadzorem człowieka.
Jak stosować: Zacznij od ograniczonego zadania, oceń wynik i dopiero potem rozszerzaj udział tańszych modeli.
Na co uważać: Im mniej człowiek uczestniczy w pracy agentów, tym większe znaczenie mają plan, przegląd i końcowa weryfikacja.
Redakcyjne tłumaczenie
Dlaczego zacząłem zmieniać sposób pracy
W tym tygodniu wyczerpałem limit Claude Code szybciej niż kiedykolwiek wcześniej, choć nie pracowałem dużo więcej niż zwykle. Korzystam z planu Max za 200 dolarów miesięcznie. Mam też subskrypcję Codex Pro w tej samej cenie i jej limit również jest już niemal wykorzystany. Na odnowienie obu muszę poczekać jeszcze trzy lub cztery dni.
Jeśli masz wrażenie, że ostatnio szybciej docierasz do limitów, nie jesteś sam. W moim odczuciu dostępne limity pogarszały się przez cały rok. Doszedłem do momentu, w którym samo oszczędniejsze gospodarowanie tokenami już mi nie wystarcza.
Od około pół roku sprawdzam, jak włączyć różne modele, zwłaszcza otwarte, do pracy z agentami programistycznymi. Wcześniej były to eksperymenty. Teraz stały się ważną częścią mojego codziennego procesu.
Coraz więcej osób buduje rozbudowane procesy z udziałem agentów: projektuje sposób ich działania, organizuje kolejne cykle pracy i tworzy systemy, które potrafią samodzielnie wytwarzać oprogramowanie. Chcemy w ten sposób robić więcej. Ogranicza nas jednak liczba tokenów, które możemy wykorzystać.
Dlatego trzeba ustalić, na których etapach naprawdę potrzebujemy najmocniejszego modelu, a gdzie podobny wynik uzyskamy dzięki modelowi mniejszemu, szybszemu i tańszemu. Mówię tu o całym procesie tworzenia oprogramowania, a nie o pojedynczej rozmowie z agentem.
Jak porównywałem modele
W ostatnim tygodniu rozbudowałem wcześniejsze próby i sprawdziłem modele na kolejnych etapach typowej pracy: planowaniu, implementacji, weryfikacji i przeglądzie kodu.
Testowałem je w swoim systemie do tworzenia oprogramowania z udziałem agentów AI. Wprowadzam opis zadania, a system przygotowuje plan, tworzy rozwiązanie i je sprawdza bez mojego udziału w kolejnych krokach. To sposób, by zobaczyć, jak daleko można posunąć automatyzację, zachowując użyteczny wynik. Ten sam system ułatwia mi też porównywanie różnych zestawów modeli.
Zbudowałem w ten sposób kilka aplikacji. W filmie pokazuję grę, bo na niej najłatwiej zobaczyć różnice. Wyniki przy innych aplikacjach były, według mojej oceny, podobne.
Podstawowe porównanie obejmowało trzy podejścia: modele otwarte, Claude oraz Codex. Wśród modeli otwartych wybrałem DeepSeek v4.1 Flash do planowania i przeglądu oraz GLM 5.3 Flash do implementacji. W głównych próbach GLM był stałym modelem wykonawczym, dzięki czemu mogłem porównać wpływ modeli użytych do planowania i oceny. W pozostałych wariantach te dwa etapy powierzyłem odpowiednio Claude Fable 5.1 lub GPT-6 Astra. Pokazuję też osobną wersję gry zbudowaną w całości przy użyciu Claude.
W chwili nagrywania uznawałem DeepSeek v4.1 Flash za czołowy model otwarty na podstawie obserwowanych rankingów. Claude Fable 5.1 i GPT-6 Astra wybrałem jako najmocniejsze modele w pozostałych porównywanych grupach.
Najważniejszy szczegół jest taki: w wariantach mieszanych mocniejszy model przygotowuje plan i ocenia wynik, a mniejszy pisze kod.
Dobry plan pozwala zmienić model wykonawczy
Z moich prób wynika, że planowanie jest najważniejszym etapem. Jeśli plan jest dobrze napisany, model wykonawczy nie musi należeć do najmocniejszych, by uzyskać bardzo dobry rezultat.
Widziałem na przykład podobne wyniki wtedy, gdy Claude Fable odpowiadał zarówno za plan, jak i implementację, oraz wtedy, gdy plan przygotowywał Fable, a kod pisał Sonnet. Dlatego w prezentowanych próbach świadomie powierzam planowanie mocniejszemu modelowi, a implementację tańszemu.
Ma to duże znaczenie dla limitów: pisanie kodu zwykle pochłania najwięcej tokenów. Przeniesienie właśnie tego etapu na mniejszy model daje więc największą szansę na ograniczenie zużycia.
Nie jest to reguła na każdą okazję. Jeśli zadanie jest wyjątkowo trudne i dotyczy słabo rozpoznanego problemu, warto rozważyć mocny model na wszystkich etapach. Z kolei przy małych, wyraźnie ograniczonych zadaniach, które człowiek na bieżąco nadzoruje, model otwarty może wystarczyć do całej pracy.
Obecnie najchętniej używam GPT-6 Astra do planowania i przeglądu, a GLM 5.3 Flash do szybkiej i taniej implementacji. Tak pracuję zarówno w swoim zautomatyzowanym systemie, jak i poza nim.
Materiał sponsorowany: Scrimba Explain
Sponsorem filmu jest Scrimba. Jej narzędzie Explain tworzy na podstawie pytania lekcję wideo z narracją. Według prezentacji autora zaczyna ją udostępniać po dwóch lub trzech sekundach i rozbudowuje w trakcie oglądania. Można je połączyć z Codex i Claude Code.
W pokazie miałem Explain podłączone do Claude Code. Poprosiłem o objaśnienie bardziej złożonej propozycji zmian w moim projekcie open source Archon. Claude odczytał różnice w kodzie, przygotował lekcję i przesyłał jej kolejne slajdy do Scrimba. Od razu otrzymałem odnośnik, więc mogłem oglądać materiał w miarę jego powstawania.
Gotowa lekcja przedstawiała zarówno ogólny schemat zmian, jak i konkretne fragmenty kodu. W filmie odtwarzam tylko krótkie urywki. Explain działa też z ChatGPT oraz jako rozszerzenie przeglądarki Chrome do objaśniania artykułów. Sponsor udostępnia możliwość wypróbowania narzędzia przez odnośnik w opisie filmu.
Jak połączyć różnych agentów w jeden proces
Jak zbudować proces, w którym kolejne etapy wykonują modele od różnych dostawców? Można to zrobić na kilka sposobów.
Najprostsza metoda wymaga ręcznej pracy. Jeden agent zapisuje wynik w dokumencie Markdown, a Ty przekazujesz ten dokument kolejnemu agentowi w nowej sesji. W ten sposób można przejść po kolei przez planowanie, implementację i przegląd.
Istnieją też narzędzia ułatwiające pracę z różnymi modelami i dostawcami, takie jak Omnigen. Ja korzystam przede wszystkim z Archona, tworzonego przeze mnie otwartego narzędzia do budowania procesów z udziałem agentów. Dzięki niemu mogłem w ostatnim tygodniu wielokrotnie uruchamiać podobny proces, zmieniając zestawy modeli.
W moich próbach wejściem jest zawsze zgłoszenie w GitHubie opisujące to, co trzeba zbudować. Najmocniejszy model, na przykład GPT-6 Astra, przygotowuje plan. Archon przekazuje ten plan modelowi GLM 5.3 Flash, który tworzy rozwiązanie. Potem Astra przegląda wynik. Jeśli znajdzie problem, uwagi wracają do GLM, który wprowadza poprawki. Pętla ma określoną maksymalną liczbę prób. Na końcu uruchamiane są testy i sprawdzany jest wynik budowania projektu, zanim zmiany zostaną scalone.
To dość zwyczajny ciąg kroków. W uproszczeniu wygląda tak samo w każdym z omawianych testów: plan od mocniejszego modelu, kod od tańszego, przegląd przez mocniejszy model i poprawki wykonane przez tańszy.
Dostęp do modeli otwartych
Do modeli otwartych można docierać różnymi drogami. Ostatnio korzystam z agenta programistycznego Pi oraz z Neon AI Gateway, który zapewnia dostęp do modeli. Pasuje mi to również dlatego, że Archon obsługuje taki układ.
Od dawna cenię Neon za jego bazę PostgreSQL. Firma dodaje też inne usługi, między innymi bramę do modeli AI, przechowywanie plików, uwierzytelnianie i funkcje działające po stronie serwera. W moim obecnym procesie ważna jest brama: przez nią uzyskuję dostęp do potrzebnych modeli otwartych, w tym GLM 5.3 Flash.
Sposób połączenia z modelem jest jednak drugorzędny. Istotne jest to, by nie kierować automatycznie całej pracy do Astry albo Fable. Archon jest bezpłatny i ma otwarty kod, ale nie trzeba go używać, aby zastosować przedstawiony podział zadań. Opisuję po prostu narzędzia, z których korzystałem podczas prób.
Trzy wersje gry
Jako czytelny przykład wybrałem grę opartą na pomyśle znajomego. Gracze ścigają w niej zjawiska pogodowe na Neptunie. Gra jest wieloosobowa: różne osoby mogą dołączyć do załogi i obsługiwać stanowiska. Nie pokazuję pełnej rozgrywki, ale opis wymagań przekazany mojemu systemowi obejmował całkiem szeroki zakres.
Pierwszą wersję stworzyłem przy użyciu samych modeli otwartych: DeepSeek v4.1 Flash przygotował plan i zrobił przegląd, a GLM 5.3 Flash napisał kod. Efekt wizualny jest słaby. Przez okna widać kilka chmur, a podczas sterowania zmienia się wskazanie kierunku, lecz ruch jest ledwie zauważalny. Moim zdaniem nie jest to nawet dobry punkt wyjścia do dalszej pracy nad grą.
Drugą wersję zbudowałem w całości przy użyciu Claude Fable 5.1. Ze względu na koszt tokenów ograniczyłem zakres pracy, więc nie powstała szczególnie dopracowana gra. Mimo to wygląda znacznie lepiej niż pierwsza. Mogę dojść do stanowiska pilota, przejąć sterowanie i zmieniać kierunek. Ruch bywa nieco szarpany, ale kiedy lecę w stronę chmur, rzeczywiście się do nich zbliżam. Jak na wstępną wersję, wynik oceniam dobrze.
W trzeciej wersji cały kod napisał GLM 5.3 Flash, natomiast GPT-6 Astra odpowiadał za planowanie i przegląd. Ta wersja zrobiła na mnie największe wrażenie. Nie twierdzę, że gra jest świetna, ale działa podobnie do wersji stworzonej przez Claude, a lot w stronę chmur wydaje się nawet płynniejszy. Uważam ją za nieco lepszą.
Według moich wyliczeń wariant z Astrą i GLM wymagał około czterokrotnie mniejszego wydatku na tokeny lub kosztował około czterokrotnie mniej niż porównywany wariant oparty na Claude. Dużą część kodu powstała bowiem przy użyciu tańszego modelu. Astra nadal pomagała, przygotowując plan i oceniając rezultat, ale nie musiała pisać każdej linijki.
To tylko wstępna wersja gry, a jej wygląd jest skromny. Pokazuję ją dlatego, że podobny układ wyników widziałem także przy innych budowanych aplikacjach. W mojej ocenie Claude Fable 5.1 i GPT-6 Astra mają zbliżone możliwości, a połączenie Astry z GLM dało w tych próbach wynik co najmniej porównywalny z użyciem Claude do całej pracy.
Co wynika z tych prób
Nie potrzebuję najmocniejszego modelu na każdym etapie tworzenia oprogramowania. Warto przejrzeć własny proces i sprawdzić, gdzie jego możliwości naprawdę decydują o wyniku. W moich próbach były to przede wszystkim planowanie i przegląd. Implementację, która zużywa najwięcej tokenów, mogłem często powierzyć tańszemu modelowi.
Mój zautomatyzowany system pozwolił mi przeprowadzić te porównania, ale sam wniosek dotyczy także prostszych sposobów pracy z agentami. Jeśli limity subskrypcji utrudniają Ci korzystanie z Claude Code lub Codex, wypróbuj modele otwarte w części zadań i oceń wynik całego procesu, od planu po końcowe testy.