Dziewięć błędów, które ludzie popełniają z moimi skillami /grill-*

2026-05-25 • Matt Pocock • AI zagraniczne •tutorial •waga 4/5 •13 min czytania

Matt Pocock pokazuje, jak używać jego skilli /grill-* do planowania z agentami: rozdzielać pytania, pilnować zakresu i okna kontekstu, nie tracić decyzji sesji. Konkret dla programistów.

Robocza publikacja redakcyjna na podstawie publicznego transkryptu YouTube. Źródło: YouTube.

Oryginalny tytuł filmu

9 Things People Get Wrong With My /grill-* skills

O czym jest ten film

  1. Skille „Grill Me” i „Grill with Docs” mają zastępować tryb planowania w agentach: agent bez końca zadaje pytania, aż dojdziecie do wspólnego zrozumienia zadania — ale nie zastępują twojej umiejętności planowania.
  2. Pytania dzielą się na niskiej i wysokiej rozdzielczości (terminologia z książki „Shape Up” Ryana Singera) — i to rozróżnienie jest kluczem do całej metody.
  3. Pytań wysokiej rozdzielczości nie da się rozstrzygnąć rozmową; trzeba je przekazać do osobnej sesji prototypowania i wrócić z wnioskami.
  4. Zbyt duży zakres planowania prowadzi do dwóch problemów: ukrytych pytań wysokiej rozdzielczości oraz „strefy głupoty” modelu, która według szacunków autora zaczyna się około 120 tys. tokenów kontekstu.
  5. Grillowanie to rozmowa, nie przesłuchanie — zbyt bierna postawa kończy się lawiną pytań i rozsadzonym zakresem, zbyt nachalna odkładaniem kodu w nieskończoność.
  6. Kontekst wypracowany w sesji (odpowiedzi, decyzje projektowe) to najcenniejszy jej dorobek — nie wolno go czyścić; trzeba od razu implementować albo zrobić dokument przekazania w rodzaju PRD.
  7. Do grillowania potrzebny jest najsilniejszy model, bo liczy się jego wiedza parametryczna; do implementacji wystarczy słabszy, bo tam przeważa wiedza kontekstowa.
  8. Autor zaleca grillowanie równolegle w dwóch sesjach (maksymalnie trzech) — to porównywalne z prowadzeniem dwóch wątków na Slacku.
  9. W grillowaniu robi się lepszym z praktyką, co pozwala stopniowo zwiększać liczbę równoległych wątków.
  10. Materiał jest też promocją kohorty „AI coding for real engineers”, startującej 1 czerwca.

10 najważniejszych takeaways — z kontekstem zastosowania

1.Klasyfikuj pytania według „rozdzielczości”

Na czym polega: Część pytań da się uczciwie rozstrzygnąć samą odpowiedzią (np. pod jakim adresem ma być dana trasa), a część wymaga zobaczenia rzeczy w działaniu (np. jak formularz będzie się sprawował w użyciu). Typowy błąd to próba rozstrzygania tego drugiego typu w rozmowie.

Jak stosować: Zanim odpowiesz, zapytaj samego siebie: czy potrafię to rzetelnie rozstrzygnąć słowami? Jeśli nie — odłóż pytanie na później i ruszaj dalej.

Na co uważać: Agent nie zrobi tej klasyfikacji za ciebie; to twoja odpowiedzialność.

2.Pytania „niegrillowalne” przekazuj do prototypowania

Na czym polega: Gdy pytanie wymaga wyższej rozdzielczości, trzeba przenieść się do osobnej sesji prototypowej, przetestować kwestię w praktyce i wrócić z wnioskami do pierwotnego grillowania.

Jak stosować: Sekwencja: grill → prototyp → powrót do grilla. Wnioski z prototypu od razu dopisuj do sesji planistycznej.

Na co uważać: Nie pozwól, by jedna kwestia „czucia interfejsu” zablokowała całe planowanie.

3.Grilluj rzeczy w rozmiarze kęsa

Na czym polega: Za duży zakres ukrywa w sobie pytania wysokiej rozdzielczości i skłania do planowania w próżni, zamiast budować na tym, co już działa i co wyszło dobrze.

Jak stosować: Przed sesją poproś agenta, żeby rozbił duży zakres na mniejsze kawałki, i każdy grilluj osobno.

Na co uważać: Rozpisywanie wielu dni pracy do przodu bez ugruntowanego fundamentu kończy się — słowami autora — bublem.

4.Nie wjeżdżaj w „strefę głupoty” modelu

Na czym polega: Według szacunków autora większość czołowych modeli zaczyna głupieć po przekroczeniu około 120 tys. tokenów kontekstu, a długie grillowanie łatwo ten limit rozdmuchuje.

Jak stosować: Na bieżąco kontroluj zapełnienie okna kontekstu; zbliżasz się do progu — kończ i przygotuj przekazanie.

Na co uważać: Awaryjne kompakty i przekazania w środku sesji są niezręczne; wybór mniejszego zakresu na starcie eliminuje problem.

5.Prowadź rozmowę, nie daj się przesłuchiwać

Na czym polega: Bierna postawa skutkuje tym, że agent zadaje setki pytań, rozsadza zakres i drąży szczegóły, których w ogóle nie warto omawiać na tym etapie.

Jak stosować: Aktywnie kieruj rozmową: pilnuj tematu, zakresu i tempa — to rozmowa, nie przesłuchanie.

Na co uważać: Da się też przesadzić w drugą stronę: uparcie przepytywać coś, co trzeba po prostu zbudować, żeby zobaczyć.

6.Nie wyrzucaj dorobku sesji

Na czym polega: Kontekst wypełniony twoimi odpowiedziami i decyzjami projektowymi to najcenniejszy produkt grillowania; czyszczenie go przed utworzeniem dokumentu PRD jest — zdaniem autora — kompletnym bezsensem.

Jak stosować: Jeśli budżet kontekstu pozwala, przechodź do implementacji od razu; jeśli nie — stwórz dokument przekazania (np. PRD) w tej samej sesji.

Na co uważać: Każda operacja na kontekście (czyszczenie, kompaktowanie, przekazanie) powinna być świadomą decyzją, a odruchem.

7.Do grillowania bierz najsilniejszy model

Na czym polega: Wartość grillowania pochodzi z wiedzy parametrycznej modelu — jego wrodzonego rozumienia systemów, z którego rodzą się nieoczywiste pytania i pomysły, których sam byś nie rozważył.

Jak stosować: Sesje planistyczne prowadź na dużym modelu klasy frontier.

Na co uważać: Nie przenoś wniosku „tańszy model wystarczy” z implementacji na planowanie — to dwie różne sytuacje.

8.Do implementacji wystarczy słabszy model

Na czym polega: Przy implementacji większość informacji jest kontekstowa: szczegółowy plan, właściwe pliki kodu, wzorce do naśladowania. Model mało czerpie z parametrów.

Jak stosować: Rozdziel etapy: mocny model planuje, tańszy koduje na podstawie jego planu.

Na co uważać: Jakość planu przekazywanego słabszemu modelowi musi być naprawdę wysoka — to on niesie całą wartość.

9.Grilluj równolegle w dwóch sesjach

Na czym polega: Autor prowadzi dwie sesje naraz, dyktując odpowiedzi na przemian, i porównuje to do prowadzenia dwóch wątków na Slacku — to jego jedyny sprawdzony sposób na zwiększenie przepustowości planowania.

Jak stosować: Odpowiadasz w jednej sesji, przechodzisz do drugiej, która zdążyła już „pomyśleć”, wracasz — i tak w kółko.

Na co uważać: Limit autora to dwie sesje (trzy, gdy jedna czeka na długie zadanie, np. research); więcej męczy i odbiera jakości.

10.Grillowanie to umiejętność, którą się trenuje

Na czym polega: Z czasem lepiej wyczuwasz rozdzielczość pytań, właściwy zakres i moment, w którym trzeba iść do kodu — a wtedy możesz dołożyć kolejny równoległy wątek.

Jak stosować: Zacznij od jednej sesji i małego zakresu, a równoległość dokładaj stopniowo.

Na co uważać: Nie myl tempa z jakością: najpierw opanuj klasyfikację pytań i zakres, dopiero potem zwiększaj liczbę wątków.

Redakcyjne tłumaczenie

Wsparcie, a nie zastępstwo

Moje skille „Grill Me” i „Grill with Docs” krążą po sieci od jakiegoś czasu i ludzie na całym świecie używają ich zamiast trybu planowania w agentach. Czasem jednak słyszę skargi w stylu: „Codex zadał mi dwieście pytań”. Za każdym razem trochę się wzdrygam. (Informacja dodatkowa: Codex to agent kodujący OpenAI; „skille” to pakiety instrukcji instalowane w agencie, które sterują jego zachowaniem.)

Cała idea tych skilli polega na tym, że agent nieubłaganie cię odpytuje — zadaje pytanie za pytaniem, dopóki nie dojdziecie do wspólnego rozumienia sprawy. A to oznacza, że bardzo wiele zależy od osoby odpowiadającej. Od ciebie. Musisz umieć planować, rozumieć, czym jest zakres projektu, i wyczuwać, które pytanie wymaga jakiego poziomu szczegółowości. Właśnie dlatego nagrywam ten materiał: chcę, żebyś naprawdę dobrze posługiwał się tymi skilla­mi. Same w sobie są krótkie — mają ci jako inżynyerowi pomagać, a nie cię zastępować.

Przygotowałem listę dziewięciu rzeczy, które ludzie robią źle. Zanim do niej przejdziemy, przyjrzymy się kilku perspektywom, przez które te błędy widać wyraźniej — bo jeśli źle zrozumiemy przyczyny, niczego nie naprawimy.

Na wstępie drobna reklama: jeśli podoba ci się sposób, w jaki uczę, spodoba ci się też moja kohorta „AI coding for real engineers” — następna edycja startuje 1 czerwca, a promocję trzydziestoprocentową zamykam już niedługo.

Wszystko sprowadza się do rozdzielczości pytań

Kiedy rozpoczynamy sesję grillowania, tak naprawdę próbujemy odpowiedzieć na pytania — o rzeczy, których jeszcze nie wiemy o tym, co zamierzamy zbudować. Te pytania różnią się rozdzielczością potrzebną do odpowiedzi. (Informacja dodatkowa: Terminologia pochodzi z książki „Shape Up” Ryana Singera o praktyce produktowej; „rozdzielczość” działa tu jak w obrazie — im wyższa, tym więcej szczegółów widać.)

Pytania wysokiej rozdzielczości to takie, do których potrzebujesz bardzo zbliżonego, szczegółowego obrazu. Na przykład: jak ten fragment interfejsu będzie się sprawował w użyciu? Czy rozbić pola formularza na kilka osobnych stron, czy zostawić jeden potężny formularz? Tego nie rozstrzygniesz inaczej niż prototypem o wysokiej wierności albo zbudowaniem całości. Pytania niskiej rozdzielczości wystarczy po prostu odpowiedzieć — choćby: pod jakim adresem ma mieszkać ta trasa?

Pierwszy błąd, który widuję, to próba rozstrzygania pytań wysokiej rozdzielczości w trakcie grillowania. Inaczej mówiąc: są pytania „grillowalne” — takie, które da się rozstrzygnąć w samej rozmowie — i „niegrillowalne”, których rozmową się nie rozstrzygnie.

Gdy pytanie wymaga prototypu

Co więc robić, gdy trafi się pytanie niegrillowalne — gdy chodzi o wrażenie, o zobaczenie rzeczy w wyższej rozdzielczości? Ja stosuję wtedy przekazanie do prototypowania. Wyobraź sobie, że w pierwszej sesji grilluję i natrafiam na pytanie, którego nie rozstrzygnę słowami. Korzystam ze skilla przekazania (link znajdziesz w opisie filmu), przenoszę się do sesji prototypowej i przez kolejną sesję prototypuję właśnie tę kwestię. To, czego się przy tym dowiem, przekazuję z powrotem do pierwotnej sesji i ruszam dalej z pytaniami, które rozmową rozstrzygnąć się dadzą. Wiele moich sesji wygląda właśnie tak: „Grill with Docs”, potem prototyp, potem powrót do grillowania.

Zakres: planuj w kawałkach, które da się przeżuć

Drugie pojęcie to zakres — jak dużą rzecz grillujesz. Jeśli jest za duża, czekają cię dwa problemy.

Po pierwsze, w obszernym zakresie łatwo o ukryte pytania wysokiej rozdzielczości — takie, których nie rozstrzygniesz bez zobaczenia całości. Zawsze łatwiej budować na czymś, co działa i co wyszło ci dobrze, niż bez końca planować daleko w przyszłość. Wiele osób wpada w tę pułapkę, próbując rozpisać na wiele dni naprzód kolejne zadania: dostaje w rezultacie bubla, bo nie buduje na fundamencie, z którym się utożsamiło. Plan wypchnęło się za daleko, zanim cokolwiek ugruntowano.

Po drugie, dochodzą ograniczenia praktyczne. Przy zbyt dużym zakresie wpadniesz prosto w strefę głupoty modelu. Owszem, sesję zaczynasz z niemal pustym oknem kontekstu, ale ono szybko się zapełnia: ledwo odpowiedzisz na połowę pytań, a już jesteś w strefie głupoty — i trzeba przekazać sesję dalej, skompaktować albo zrobić coś równie niezręcznego. Wszystkiemu temu można było zapobiec, wybierając od razu mniejszy zakres i grillując wygodnie w strefie rozumu. Dla niewtajemniczonych: szacuję, że u większości czołowych modeli strefa głupoty zaczyna się około 120 tysięcy tokenów. Trzeba więc bardzo uważnie pilnować okna kontekstu, żeby go nie przekroczyć — uwaga modelu zaczyna się rozłazić i podejmuje coraz głupsze decyzje.

W praktyce: jeśli startujesz z dużym zakresem, który najwyraźniej przerasta agenta, lepiej od razu poprosić go, żeby rozbil go na mniejsze kawałki — i każdy grillować osobno, odpowiadając na jego pytania po kolei.

Bierny czy nadaktywny — znajdź środek

Kolejna perspektywa: czy w sesjach grillowania jesteś wobec agenta bierny, czy aktywny. Kiedy widzę te gigantyczne sesje, martwi mnie, że ich autorzy siedzą zbyt wygodnie. Sam zawsze jestem bardzo w akcji, staram się prowadzić rozmowę. Bo to rozmowa, nie przesłuchanie. Agent zadaje pytania, ale to twoje zadanie to wiedzieć, dokąd zmierzacie, pilnować zakresu i trzymać temat. Jeśli się wycofasz, agent zrobi z sesji głupoty: zada 540 pytań, rozsadzi zakres, będzie drążył kwestie o zbyt niskiej rozdzielczości. Trzeba wziąć stery w swoje ręce.

Ale można też przesadzić w drugą stronę: uparcie grillować coś, czego i tak nie rozstrzygniesz w rozmowie, choć żeby to zobaczyć, trzeba po prostu zbudować. Mamy więc znów dwa błędy: nadmierną bierność z jednej strony i upór oraz odkładanie kodu w nieskończoność z drugiej. Warto zastanowić się, gdzie na tej osi lądujesz ty.

Nie wyrzucaj dorobku sesji

Następny błąd: ludzie nie doceniają tego, co powstaje w trakcie grillowania. Odpowiadając na pytania, zapełniasz okno kontekstu naprawdę wartościowymi rzeczami — odpowiedziami, podjętymi decyzjami projektowymi. Ten fragment kontekstu jest bezcenny.

Zwykle cel jest taki: jeśli budżetu jeszcze starcza, przechodzisz od razu do implementacji. Chwilę planujesz, a potem mówisz: „Dobra, implementujemy. Nie trzeba niczego przekazywać, miejsca w oknie jeszcze wystarczy, a decyzje projektowe już zapadły”. Jeśli natomiast jesteś już w punkcie, w którym sesję trzeba zakończyć, to znak, że pora na PRD. (Informacja dodatkowa: PRD — dokument wymagań produktowych; Matt ma własnego skilla, który zamienia przebieg sesji w taki dokument.) U mnie to wygodny sposób stworzenia dokumentu przekazania dopasowanego do pracy inżynierskiej — przydaje się i w pracy wielosesyjnej, i w pojedynczej sesji.

Jedna rzecz, którą widziałem, jest dla mnie kompletnie niezrozumiała: ludzie najpierw czyszczą kontekst, otwierają nowe okno i dopiero tam generują PRD. Co wy robicie?! Stworzyliście wspaniałą sesję — sto tysięcy tokenów dobrych decyzji projektowych — i po prostu to wyrzucacie? Każda sesja grillowania i każda podjęta w niej decyzja jest tak cenna, że powinna być gdzieś utrwalona: zamieniona w kod albo spisana w dokumencie, do którego później wrócisz. Naprawdę nie wolno wyrzucać tego, co wypracowałeś w grillu. Podejrzewam, że to po prostu kwestia wprawy: potrzeba większej świadomości w zarządzaniu kontekstem — w decyzjach o czyszczeniu, kompak­towaniu i przekazywaniu. To był dla mnie naprawdę szokujący błąd.

Do grillowania mocny model, do implementacji byle jaki

Wreszcie: ludzie grillują zbyt słabym modelem. Rozpoznawanie, które pytania są niskiej, a które wysokiej rozdzielczości, i wymyślanie pytań, które zmuszą cię do mocniejszych decyzji projektowych — to zadanie dla porządnego modelu.

Skąd modele czerpią wiedzę? Z dwóch źródeł. Pierwsze to wiedza kontekstowa — wszystko, co przekażesz modelowi w kontekście: przeczytane pliki, twoje prompty, wyniki wywołanych narzędzi. Drugie to wiedza parametryczna — to, czego model nauczył się w trakcie treningu. Ta druga jest mniej pewna, ale w grillowaniu właśnie na niej polegamy. Liczymy na to, że wrodzone zrozumienie systemów i aplikacji podsunie pomysły, których sam jeszcze nie rozważyłeś. Gdybyś je rozważył, przekazałbyś je jako wiedzę kontekstową — my natomiast liczymy na nieoczywiste, dziwne wręcz propozycje. A żeby na tym polegać, potrzebny jest model z wielką liczbą parametrów — czyli duże modele klasy frontier, do tego najlepiej wytrenowane i po prostu sprawniejsze od mniejszych. Zbyt słaby model to bardzo częsty błąd w grillowaniu właśnie dlatego, że cała metoda opiera się na wiedzy parametrycznej.

Co wielu osób nie wie: do implementacji można spokojnie użyć modelu głupszego, bo większość informacji, które tam przekazujesz, jest kontekstowa. Do czasu implementacji masz zwykle szczegółowy plan, dołączasz właściwe pliki kodu, jest co kopiować — niewiele w tym wiedzy parametrycznej.

Grilluj równolegle

I na koniec coś banalnie prostego, czego jednak prawie nikt nie robi: prowadź kilka sesji grillowania naraz. U mnie to zwykle wygląda tak: grilluję w jednej sesji, wpisuję — a częściej dyktuję — odpowiedź na pytanie, po czym przechodzę do drugiej sesji, która w tym czasie zazwyczaj już skończyła myśleć. Odpowiadam tam, wracam do pierwszej. I tak w kółko. Ludzie mówią, że to ciągłe przełączanie kontekstu, ale naprawdę jest to jak prowadzenie dwóch wątków na Slacku jednocześnie — nic trudnego. Podejmujesz wprawdzie sporo decyzji na wysokim poziomie, ale to jedyny znany mi sposób, żeby zwiększyć przepustowość: więcej planowania w krótszym czasie. Zwykle zamykam się na dwóch sesjach; wyjątek to sytuacja, gdy jedna czeka na długie zadanie, na przykład research — wtedy, jeśli mam energię, próbuję trzech. Ale dwie to mój limit. Tak czy inaczej: podwajam przepustowość, przyjemnie się to robi i jeśli masz na to głowę — zdecydowanie powinieneś spróbować.

Uważam też, że w grillowaniu robi się lepszym z czasem — a im lepszy jesteś, tym więcej równoległych wątków możesz prowadzić.

Podsumowanie

Zbierzmy to wszystko. Grillowanie to w pierwszej kolejności pytania. Pytania niskiej rozdzielczości rozstrzyga sama odpowiedź — to pytania grillowalne. Pytania wysokiej rozdzielczości są niegrillowalne: żeby je rozstrzygnąć, trzeba czasem przekazać sesję do trybu prototypowania, rozwiązać tę jedną kwestię (albo całą ich kupę) i wrócić do pierwotnego grillowania.

Wyznaczenie właściwego zakresu to podstawa. Jeśli spróbujesz objąć grillowaniem za dużo, przejedziesz przez okno kontekstu, wypalisz własną energię i nie będziesz miał z tym nic w ręku. Zbyt bierny w sesji? Będziesz siedział bezradnie, podczas gdy komputer zasypie cię kolejnymi pytaniami. Zbyt aktywny? Będziesz w kółko drążył pytania niskiej rozdzielczości, choć naprawdę potrzebujesz po prostu dojść do kodu. Do tego potrzebujesz sprytnego modelu — jego wiedza parametryczna da ci lepsze podpowiedzi i lepsze pytania do rozstrzygnięcia. I wreszcie: grilluj dwie sesje naraz. Gdy opanujesz te podstawy i będziesz wiedział, co się dzieje w każdej z nich, przełączanie się pójdzie ci gładko — a przy bardziej plastycznym mózgu niż mój dasz radę pewnie nawet cztery.

Na koniec — zwrot do widzów

Dzięki za oglądanie. Jeśli ten materiał ci się podobał, spodoba ci się też moja kohorta „AI coding for real engineers” — zostało niecałe półtorej doby promocyjnej ceny. W pakiecie dostajesz nagrania i interaktywne ćwiczenia ułożone tak, by nauka szła maksymalnie szybko i sprawnie, a ja odpowiadam na pytania na dyżurach i na czacie Discorda.

Przy okazji: mój kanał ostatnio mocno rośnie — dziękuję wam za to, naprawdę to doceniam. Świetnie bawię się przy tworzeniu tych filmów i samych skilli. Właśnie przegoniliśmy „G Stack” Gary’ego Tana liczbą gwiazdek na GitHubie, co brzmi dla mnie absurdalnie. (Informacja dodatkowa: Gary Tan — prezes Y Combinator; „gwiazdki” to oznaczenia popularności repozytorium na GitHubie.) Jeśli masz pomysł na film, który mam nagrać — daj znać, bo żyję waszymi sugestiami. Dzięki i do zobaczenia wkrótce.