O czym jest ten film
- Kilka miesięcy temu Matt Pocock napisał cztery zdania, z których powstał skill Grill Me — model językowy przesłuchuje użytkownika tak długo, aż osiągną wspólne zrozumienie projektu, pytanie po pytaniu rozstrzygając zależności między decyzjami.
- Umiejętność zdobyła ogromną popularność: autor codziennie dostaje około pięciu wiadomości od zachwyconych użytkowników, którzy po zebraniu kontekstu „wszystko załatwiają jednym zamachem”.
- Mimo pochwał Pocock zbudował następcę, bo dostrzegł lukę: ustalony wspólny język nie był nigdzie zapisywany, więc w każdej nowej sesji trzeba było od nowa tłumaczyć nieoczywiste pojęcia domeny (np. „film samodzielny”).
- Rozwiązanie zapożyczył z Domain-Driven Design — to koncepcja wspólnego języka (ubiquitous language), którym posługują się jednocześnie kod, programiści i eksperci domenowi.
- Nowa umiejętność, Grill with Docs, łączy przesłuchanie z prowadzeniem pliku
context.md— żywego glosariusza, który agent wczytuje na starcie, konfrontuje z nim wypowiedzi użytkownika i uzupełnia na bieżąco. - W monorepo podejście skaluje się przez wiele plików kontekstowych (bounded contexts); przy jednym dużym repozytorium wystarczy pojedynczy
context.mdw katalogu głównym plus wskaźnik w lokalnym CLAUDE.md. - Trzecim elementem są ADR — krótkie notatki z decyzji, które są trudne do odwrócenia, zaskakują bez kontekstu i wynikają z realnego kompromisu.
- W demo na własnym projekcie (pitchy do filmów) agent najpierw porządkuje język — liczność relacji, kolizje nazw, stany i cykl życia encji — a dopiero potem przechodzi do implementacji i zapisuje ustalenia do
context.md. - Korzyści: krótsze odpowiedzi, mniejsze zużycie tokenów (także w rozumowaniu modelu) oraz kod łatwiejszy do przeszukiwania — dokładnie te same zyski, jakie DDD daje zespołom złożonym z ludzi.
- Grill Me nie znika — trafia do kategorii „produktywność” na wypadek pracy bez bazy kodu (np. pisania przemówienia pożegnalnego); zasada jest prosta: masz kod → Grill with Docs, nie masz → Grill Me.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zanim powierzysz agentowi implementację, pozwól mu cię przesłuchać
Na czym polega: Rdzeń podejścia „grill”: model zadaje pytania, dopóki nie osiągniecie wspólnego rozumienia projektu — systematycznie przechodzi przez kolejne wątki projektowe i po kolei rozstrzyga zależności między decyzjami. Zamiast zgadywać intencje, agent wydobywa je z rozmówcy.
Jak stosować: Na starcie pracy nad funkcją, zamiast polecenia „zrób X”, uruchom sesję przesłuchania (Grill Me lub Grill with Docs) i odpowiadaj na pytania do momentu, w którym agent przestaje znajdować niejasności.
Na co uważać: Pierwsze sesje pozornie spowalniają pracę. Zysk przychodzi później — użytkownicy potwierdzają, że po zebraniu kontekstu kolejne polecenia załatwiają jednym zamachem.
2. Prowadź context.md — glosariusz wspólnego języka projektu
Na czym polega: Kluczowa nowość względem Grill Me: uzgodnione pojęcia (encje, ich stany, relacje, żargon) trafiają do pliku context.md, dzięki czemu wiedza przetrwa koniec sesji i nie trzeba jej odtwarzać od zera.
Jak stosować: Trzymaj plik w katalogu głównym repozytorium i pozwól skillowi Grill with Docs wciągać go na początku, sprawdzać względem niego twoje wypowiedzi i uzupełniać go w trakcie rozmowy; na koniec sesji poproś o zapis ustaleń.
Na co uważać: Glosariusz musi nadążać za rzeczywistością — przestarzały plik myli agenta bardziej niż jego brak.
3.Kolizje nazw rozstrzygaj, zanim padnie pierwsza linijka kodu
Na czym polega: W materiale sam termin „film samodzielny” zaczął znaczyć dwie rzeczy naraz (film z pitchem albo bez), a sposób rozstrzygnięcia przesądził o sekcjach w interfejsie i relacjach w bazie danych. Nazewnictwo to nie kosmetyka — to projektowanie.
Jak stosować: Gdy agent zgłasza, że coś „gryzie się z glosariuszem”, potraktuj to priorytetowo i doprecyzuj definicję, zanim rozmowa zejdzie na implementację.
Na co uważać: Pojęcia oczywiste dla ciebie nie są oczywiste dla modelu — każdy termin fachowy warto zdefiniować, nawet jeśli wydaje się banalny.
4.Dokumentuj decyzje w ADR — ale tylko te naprawdę warte zapisu
Na czym polega: ADR to krótkie pliki markdown dokumentujące decyzje nieoczywiste. Pocock podaje kryteria: decyzję trudno odwrócić, zaskakuje bez kontekstu i jest wynikiem realnego kompromisu — czyli ma konsekwencje w przyszłości.
Jak stosować: Podczas sesji Grill with Docs każ agentowi tworzyć ADR według szablonu wbudowanego w skilla — automatycznie zapisze kontekst i skutki rozstrzygnięcia.
Na co uważać: Nie dokumentuj wyborów wymiennych („biblioteka A czy B”) — repozytorium zamieni się w śmietnik notatek, których nikt nie czyta.
5.Miej świadomość, że glosariusz stanie się nazwami w kodzie
Na czym polega: Wszystkie nazwy zmiennych i plików generowane przez agenta wywodzą się z pojęć ustalonych w context.md, więc niedbałość językowa rozprzestrzeni się na całą bazę kodu.
Jak stosować: Sesję językową prowadź tak, jakbyś projektował API: dopracuj nazwy encji, statusów i relacji, zanim pozwolisz na implementację.
Na co uważać: Na drugim biegunie czeka tzw. bike-shedding — bezkresny spór o trywialny detal. Umiej powiedzieć: „wystarczy, słownik dopracujemy przy okazji refaktoryzacji”.
6.Wspólny język tnie tokeny — w odpowiedziach i w rozumowaniu
Na czym polega: Skoro nie trzeba wszystkiego opisywać od nowa, odpowiedzi agenta są krótsze. A ponieważ model „myśli” językiem, zwięzły słownik obniża też koszt jego rozumowania i poprawia zgranie z twoją intencją.
Jak stosować: Po uzgodnieniu terminów wymagaj od agenta ich używania zamiast omówień — „zmieniają się filmy samodzielne” zamiast wielozdaniowych opisów.
Na co uważać: Skróty działają tylko wtedy, gdy są zapisane w glosariuszu; niezanotowanego żargonu agent będzie zgadywał.
7.Skaluj słownik przez ograniczone konteksty (bounded contexts)
Na czym polega: W DDD ograniczony kontekst to obszar aplikacji mówiący jednym językiem; w monorepo różnym częściom systemu mogą odpowiadać różne języki.
Jak stosować: Jedno repozytorium i jedna domena — pojedynczy context.md u korzenia. Gigantyczny monorepo — mapa kontekstów i osobny plik dla każdego z nich.
Na co uważać: „Kontekst” to słowo mocno nadużywane w branży — zadbaj, by zespół (i agent) zawsze wiedział, który plik w danym miejscu obowiązuje.
8.Podłącz dokumentację do pliku konfiguracyjnego agenta
Na czym polega: Sam plik context.md nie wystarczy — agent musi wiedzieć, że istnieje. Pocock dodaje wskaźnik w lokalnym CLAUDE.md, z informacją o układzie dokumentacji.
Jak stosować: W lokalnym pliku konfiguracyjnym (np. CLAUDE.md) umieść jedną linijkę: dokumentacja domenowa leży w context.md w katalogu głównym, dalsze informacje — pod wskazanym adresem.
Na co uważać: Rozdziel konfigurację globalną i lokalną projektu — wskaźnik trzymaj w tej lokalnej, żeby nie zaśmiecać ustawień współdzielonych.
9.Daj metodzie kilka sesji — efekt narasta
Na czym polega: Testujący raportują, że pierwsze sesje wymagają definiowania mnóstwa pojęć, ale po czterech–pięciu agent sam podchwytuje kontekst i niemal czyta w myślach.
Jak stosować: Nie porzucaj procedury po pierwszej żmudnej sesji — koszt definicji ponosisz raz, a korzyść zbierasz w każdej następnej.
Na co uważać: Nie ziewaj nad trudnymi terminami podczas definiowania — to właśnie one najczęściej powodują późniejsze nieporozumienia.
10.Dobierz narzędzie do zadania: z kodem czy bez
Na czym polega: Zasada Pococka: masz bazę kodu — Grill with Docs; nie masz — Grill Me (przeniesiony do kategorii „produktywność”), bo sprawdza się w zadaniach pozainżynierskich, na przykład przy pisaniu przemówienia pożegnalnego.
Jak stosować: Do prac nad oprogramowaniem zawsze włączaj warstwę dokumentacyjną; do zadań tekstowych czy refleksyjnych wystarczy samo przesłuchanie.
Na co uważać: Nawet w zarodku projektu warto sięgnąć po wersję z dokumentacją — to właśnie na początku buduje się wspólny język, który potem procentuje.
Redakcyjne tłumaczenie
Cztery zdania, które okazały się przełomem
Kilka miesięcy temu napisałem cztery zdania, które okazały się najbardziej wpływowymi czterema zdaniami, jakie kiedykolwiek ułożyłem. Zapakowałem je w umiejętność (ang. skill) o nazwie Grill Me. Jej zadanie: model językowy przesłuchuje cię bezlitośnie — zadaje pytania tak długo, aż osiągniecie wspólne zrozumienie. Robi to metodycznie: przechodzi kolejno przez wszystkie wątki projektowe i po kolei rozplątuje zależności między decyzjami.
Wiem, że ta umiejętność zrobiła karierę, bo codziennie dostaję jakieś pięć wiadomości od ludzi, którzy ją wypróbowali i są zachwyceni. „To kompletnie zmienia sposób, w jaki pracuję”. „Jakie są wasze ulubione skille?”. „Grill Me jest świetny, pracuję nad projektem, bla, bla, bla”. „Skill Grill Me wyciąga ze mnie niejasności. Fantastycznie”. „Grill Me jest po prostu najlepszy. Na początku myślałem, że te wszystkie pytania mnie spowalniają, ale po trochę praktyki szczerze uważam, że oszczędza mi czas. Gdy raz zbierzesz cały kontekst, resztę załatwiasz jednym zamachem”. „Testowałeś skill o nazwie Grill Me?”. I tak dalej. Cudownie, cudownie, cudownie.
Po takiej lawinie pochwał można by pomyśleć: no to trzymaj się tego narzędzia, brzmi w końcu nieźle. Tymczasem zbudowałem coś lepszego. Nie umiem spoczywać na laurach — w każdej części mojego procesu widzę, co dałoby się poprawić. I tak Grill Me właśnie zastąpiła nowa umiejętność.
Gdzie Grill Me zawodzi — przykład z pitchami
Otwórzmy sesję, żebym pokazał na konkretnym przykładzie, gdzie Grill Me kuleje. Wklejam prompt przygotowany wcześniej — to pomysł na nową funkcję, nadiktowany na głos, więc oszczędzę wam szczegółów. Istota: chcę dodać do bazy danych nowy byt, z którym moja aplikacja będzie pracować. Dziś aplikacja operuje na kursach, lekcjach, filmach, sekcjach i paru innych rzeczach. Ja chcę wprowadzić pojęcie pitcha.
Obowiązuje u mnie zasada à la MrBeast: najpierw zaprojektuj opakowanie filmu, a dopiero potem zastanawiaj się, co trafi do środka. W moim systemie pitch to właśnie opakowanie: tytuł, opis, sposób, w jaki przedstawię materiał widzom. Tworzę całą serię pitchy, wybieram najlepsze i dopiero z nich powstają filmy. (Informacja dodatkowa: MrBeast, najpopularniejszy youtuber świata, słynie z dopracowywania tytułu i miniatury przed nagraniem materiału, a nie po nim.)
Zwróć uwagę, co się dzieje, gdy rozmawiam z agentem: skupiamy się na języku. Na tym, czym właściwie jest pitch. Musiałem ci to właśnie wyjaśnić, żebyś nadążył — dokładnie te same informacje agent będzie musiał wydobyć ode mnie. A w opisie jest dodatkowy żargon, którego agent jeszcze nie zna. Mówię na przykład o „filmach samodzielnych” (standalone videos). Co to znaczy? Cóż, oczywiście: film, którego nie przypisano do żadnej lekcji ani kursu. Ja to wiem — w moim systemie to swego rodzaju termin fachowy — ale agent nie ma o nim pojęcia. W trakcie sesji będzie więc musiał zapytać albo spróbować wywnioskować definicję z kodu.
Im dłużej używałem Grill Me, tym częściej zauważałem dwa zjawiska. Czasem agent wyrażał się bardzo opisowo i musiałem mu przypominać: „nie, na to już mamy termin”. Częściej jednak terminu nie było — albo sam myślałem o czymś bardzo rozwlekle i nikt mnie w tym nie kwestionował. I dochodziła najgorsza opcja: dochodziliśmy do naprawdę dobrego, wspólnego języka… którego nikt nigdzie nie zapisywał.
Coraz bardziej więc Grill Me mi nie leżał. W układance brakowało jednego elementu: o samym kodzie rozmawialiśmy całkiem sprawnie, ale za każdym razem musiałem od nowa wyjaśniać wszystkie nieoczywiste rzeczy o bazie kodu i o domenie — o problemie, który rozwiązujemy — zanim dało się zrobić coś produktywnego. Zacząłem się zastanawiać: jaka byłaby najcieńsza możliwa warstwa dokumentacji, która dałaby AI przewagę startową?
Wspólny język z Domain-Driven Design
Odpowiedzią okazała się umiejętność ubiquitous language, czyli „wspólny język”. Koncepcja pochodzi z Domain-Driven Design — z tej całej „grubej niebieskiej księgi” Erica Evansa, o której wszyscy tylko gadają. (Informacja dodatkowa: DDD to metodologia projektowania oprogramowania, w której struktura kodu odzwierciedla logikę biznesową; „niebieska księga” to klasyczny podręcznik Erica Evansa z 2003 roku.) Chodzi o stworzenie dokumentu opisującego język, którym posługuje się baza kodu, programiści i eksperci domenowi — czyli ludzie, którzy wiedzą, co budujesz, choć niekoniecznie jak. Te grupy powinny mówić jednym językiem. Wtedy ekspert może stwierdzić: „coś jest nie tak z tą częścią aplikacji”, programista od razu wie, o co chodzi, i kod to odzwierciedla.
W praktyce robiłem to tak: w środku sesji przesłuchania, gdy czułem, że warto doprecyzować jakieś pojęcie, wywoływałem skill ubiquitous language i wspólnie tworzyliśmy plik ubiquitous-language.md. Przez pewien czas używałem obu umiejętności równolegle, aż w końcu pomyślałem: czemu nie połączyć ich w jedną, nową?
Grill with Docs: przesłuchanie plus żywy glosariusz
I oto ona — Grill with Docs. Na górze ma dokładnie ten sam tekst co Grill Me, dochodzą jednak dodatki. Pierwszy: skill szuka pliku context.md, który dokumentuje cały wspólny język danego obszaru. Przyznaję — „kontekst” to jedno z najbardziej wyeksploatowanych słów w branży, więc nazwa trochę mnie uwiera, ale jakoś to znoszę. W DDD ograniczony kontekst (bounded context) to ta część aplikacji, w której mówi się jednym wspólnym językiem. W gigantycznym monorepo możesz więc trzymać mapę kontekstów i wiele osobnych plików — tak skalujesz rozwiązanie do ogromnych repozytoriów. A jeśli masz po prostu jeden spory katalog, w którym cała aplikacja mówi tym samym językiem co eksperci domenowi, wystarczy pojedynczy context.md.
Skill dostał zatem instrukcję, żeby szukać istniejącej dokumentacji i wciągać z niej wspólny język, a potem — w trakcie sesji — konfrontować twoje sformułowania z glosariuszem, doprecyzowywać to, co nieostre, omawiać konkretne scenariusze, odnosić wszystko do kodu i uzupełniać plik na bieżąco. To naprawdę porządkuje słownictwo w czasie rzeczywistym — i z czasem wyraźnie procentuje.
Jak to działa na ludziach — opinie testujących
Prosiłem o opinie i dostałem piękne cytaty. Jeden z użytkowników spędził na tym cały dzień. Na początku agent kazał mu definiować mnóstwo pojęć — niektóre trudno było uzgodnić, a z pewnością by o nich zapomniał. Ale po czterech, pięciu sesjach zauważył, że Claude sam podchwytuje kontekst podczas przesłuchania i „magicznie zgrał się z myślami, zanim zdążyły wyjść z głowy”. O to dokładnie chodzi. Dokumentując rzeczy nieoczywiste i uzgadniając wspólny język, naprawdę dochodzisz z AI do niemal telepatycznego porozumienia — do przekazania tego, co masz na myśli, potrzeba o wiele mniej słów.
Jak to wygląda u mnie? W context.md mojego repo jest krótki opis, czym projekt jest, potem kurs i repozytorium kursów, wszystkie byty — w tym wersje kursów, bo utrzymuję ich kilka. A gdyby szukać tego, o czym rozmawialiśmy, czyli filmu samodzielnego — proszę, na dole. Mamy precyzyjną specyfikację, czym film samodzielny jest.
Sam skill wie, że ma po ten plik sięgać, ale dodatkowo wstawiam wskaźnik — nie w globalnym, tylko w lokalnym CLAUDE.md. Wystarczy jedna linijka: dokumentacja domenowa trzyma się w pojedynczym pliku context.md w katalogu głównym, plus notka, gdzie szukać dalszych informacji. (Informacja dodatkowa: CLAUDE.md to plik konfiguracyjny agenta Claude Code, wczytywany na początku każdej sesji — odpowiednik stałych instrukcji dla modelu.)
ADR: warstwa dla decyzji, których glosariusz nie obejmie
Jest jeszcze jedna rzecz, którą robi Grill with Docs. Niektóre problemy rozwiąże doprecyzowanie języka — ale nie wszystkie. Potrzebowałem warstwy wyjaśniającej decyzje nieoczywiste, takie, których nie da się uchwycić w context.md. Wybór padł na ADR, czyli architektoniczne rekordy decyzji: zwykłe pliki markdown w repo, dokumentujące nieoczywiste rozstrzygnięcia. (Informacja dodatkowa: ADR — Architectural Decision Record — to krótka notatka obejmująca kontekst decyzji, samą decyzję i jej konsekwencje.)
ADR twórz tylko wtedy, gdy decyzję trudno odwrócić. Jeśli to wybór typu „weźmiemy tę bibliotekę zamiast tamtej”, a obie są wymienne — zawsze możesz podmienić później. Drugie kryterium: decyzja zaskakuje bez kontekstu, a takich w repozytorium jest mnóstwo, zwłaszcza w bardziej złożonych projektach. I wreszcie: musi być wynikiem realnego kompromisu, czyli mieć konsekwencje w przyszłości. W skillu siedzi szablon ADR, którego model używa przy ich tworzeniu.
Sesja na żywo: najpierw język, potem implementacja
Skoro znamy już wszystkie elementy, wróćmy do promptu: podmieniamy Grill Me na Grill with Docs i odpalamy sesję, żeby zobaczyć całość w akcji.
Pierwsza rzecz, którą robi agent: „O, context.md jest bogaty. Film samodzielny jest już zdefiniowany — to film o lessonId równym null”. I dalej: „Zanim ruszymy dalej, chcę zwrócić uwagę na jedną rzecz, która gryzie się z glosariuszem”. To bardzo typowe dla Grill with Docs — najpierw zajmuje się językiem, a dopiero potem szczegółami implementacji.
Agent podchodzi do liczności relacji między pitchem a filmem samodzielnym: czy jeden pitch obejmuje wiele filmów, czy jeden pitch odpowiada dokładnie jednemu filmowi? Zgadzam się z jego zaleceniem — ustalamy relację jeden-do-wielu.
Chwila później wyłapuje kolizję terminologiczną. „Film samodzielny” zaczął bowiem znaczyć dwie rzeczy naraz: film całkiem samodzielny albo film powiązany z pitchem. Agent pyta wprost: zostawiamy to pojęcie dla każdego filmu — z pitchem lub bez — czy redefiniujemy je na film wyłącznie bez pitchu i bez lekcji? Odpowiedź przesądzi o wszystkim, co pójdzie dalej: czy filmy samodzielne dostaną własną sekcję w interfejsie, czy będą się mieszać z filmami opatrzonymi pitchem. Język, który tu ustalamy, to przecież także język, który użytkownik zobaczy na ekranie, klikając po aplikacji. Wchodziłem w tę sesję z zamiarem wydzielenia osobnej sekcji dla filmów z pitchem — ale przyznaję agentowi rację: sensowniej trzymać pitch jako metadane samego filmu samodzielnego. (Tak przy okazji: dyktuję to przez Whisper Flow. Działa w porządku — nie powiedziałbym, żebym polecał, ale nie narzekam.)
Agent: „potrzebujemy semantyki statusów”. Każdy pitch może być w stanie bezczynności (idle), zaplanowany (scheduled) albo opublikowany (shipped). Postanawiam pozwolić na dowolne przejścia między statusami — nie zależy mi na automatyzacji. Automaty można dołożyć później: przycisk „wyślij na YouTube” przenoszący pitch w nowy stan. Na razie wystarcza mi ręczne przełączanie.
Kolejne pytanie: „czy pitch może istnieć bez ani jednego filmu?”. Oczywiście — pitch może mieć zero filmów. W tym cały sens: generuję pomysły na filmy, najpierw opakowanie — to znowu zasada MrBeasta. A ten język sięga aż do takich konkretów jak zasady kaskadowego usuwania. Ustalam on delete restrict — po prostu wolę restrykcyjne usuwanie; w praktyce i tak zwykle archiwizuję zamiast kasować.
W tym momencie wchodzimy w szczegóły implementacyjne. Zamiast was nimi nużyć, mówię agentowi: „Zapisz to, co ustaliliśmy, do context.md. Jeśli coś zostało nieustalone, przesłuchaj mnie o tym, zanim naniesiesz zmiany”. I proszę — plik zaktualizowany. Doszły informacje o pitchu: byt „pitch”, „status pitcha”… „pitched standalone video” brzmi niezgrabnie — być może trzeba będzie o to dopytać. Do tego „unattached standalone video”, czyli tak naprawdę „samodzielny film samodzielny”.
Pedanteria czy spór o daszek nad rowerem?
Może wyglądać, że jestem pedantyczny do bólu — że to typowy bike-shedding, kłótnia o daszek nad wiatą rowerową, gdy obok stoi nieruszony dom. Ale ten język odbije się na każdej linijce generowanego kodu: wszystkie nazwy zmiennych i plików wywodzą się właśnie z dokumentu context.md. Dopięcie słownika jest absolutnie kluczowe dla poczucia zgrania z AI.
Oczywiście nie chodzi o to, żeby dywagować nad terminami bez końca. Mówię więc: wystarczy. Zostaje tak, jak jest — słownik zrefaktoryzujemy później, jeśli zajdzie potrzeba.
Co z tego naprawdę masz
Co daje przejście przez tę całą ceremonię? Po pierwsze: zwięzłe odpowiedzi. Dzięki wspólnemu językowi AI potrzebuje mniej tokenów, żeby się do ciebie zwrócić — nie musi wszystkiego opisywać od nowa. Mówi po prostu: „filmy samodzielne się zmieniają, trzeba było ruszyć pitchy i sposób ich wyświetlania”.
Po drugie, zwięzłość przenosi się na wewnętrzne rozumowanie modelu. AI myśli językiem — więc lepszy słownik to i lepsze dopasowanie do twojej intencji, i mniej tokenów wydanych na samo myślenie. Obserwuję to u siebie i całkiem mi się podoba.
Po trzecie: kod, po którym łatwiej się poruszać. Skoro sposób rozmowy z AI jest zestrojony z wyglądem kodu, szukanie jest trywialne: „potrzebuję wszystkiego o pitchach — przeszukaj”. A wszystko to spina się w całość, bo są to dokładnie te korzyści, które opisuje samo Domain-Driven Design. Techniki działające na ludziach, jak się okazuje, działają również na AI.
Czy Grill Me umarł?
Pomyślasz może: czy właśnie zabiłem Grill Me? Czy jego własny twórca wbił mu nóż w plecy? Ależ skąd. Uważam Grill Me za znakomitą umiejętność — po prostu Grill with Docs jest lepszy, gdy masz bazę kodu. W moim repozytorium skillów przeniosłem Grill Me do kategorii „produktywność”: to narzędzie ogólnego przeznaczenia, na wypadek, gdy nie masz kodu. Ktoś opowiedział mi najlepszą z możliwych historii: pisał przemówienie na pogrzeb mamy i użył Grill Me, żeby AI wypytało go o nią i wydobyło na wierzch te wszystkie niezwykłe wspomnienia. Grill Me ma więc zastosowania wręcz niesamowite — poza inżynierią.
A co, jeśli jesteś na naprawdę wczesnym etapie projektu? Wtedy i tak raczej polecałbym Grill with Docs — z tego wspólnego języka wyciągasz najwięcej, a początek projektu to dokładnie ten moment, kiedy ów język dopiero budujesz. Zasada jest więc prosta: masz bazę kodu — bierz Grill with Docs. Nie masz — Grill Me.
Na koniec: newsletter i prośba o feedback
Skilli aktualizuję bardzo regularnie i nieustannie przychodzą mi do głowy nowe pomysły — czasem dotyczą samego skilla, czasem tylko lepszego sposobu jego użycia. O wszystkim informuję w newsletterze „AI skills for real engineers”. To dodatek do mojego dotychczasowego newslettera: raz na jakiś czas ekstra notka o zmianach w skillach. Nie znoszę spamu, więc zasypywać mailami nie będę — ale ta strona pozwoli ci śledzić dziennik zmian i podpowie, jak używać skilli lepiej. Dzięki za obejrzenie — do zobaczenia w następnym materiale. Jeśli skill przypadł wam do gustu, dajcie znać w komentarzach, jak poszło, a gdy widzicie coś do poprawy, otwórzcie zgłoszenie w repozytorium skilli.