O czym jest ten film
- Premiera wersji 1.2.0 zestawu „engineering skills” Matta Pococka — repozytorium ma już 24 tys. gwiazdek na GitHubie.
- Nowa dokumentacja pod adresem aihero.dev/skills, z mapą przepływu pracy, pełnym katalogiem skills i słownikiem pojęć AI coding.
- Zestaw trafił do oficjalnego marketplace’u wtyczek Claude Code — instalacja jednym poleceniem, z automatycznymi aktualizacjami.
- Dodano pliki
openai.yamldla każdego skilla, żeby ukrywanie skills przed kontekstem agenta działało również w Codeksie. - Nowy skill
/wait-what— reakcja na rozwlekłe i niezrozumiałe odpowiedzi modelu, zwłaszcza Opusa 5. - Gruntowna przebudowa
/grill-me: zamiast jednego pytania na turę, pytania zadawane są rundami według grafu zależności. writing-great-skillszmienia się wwriting-for-agents— do pisania dowolnych plików czytanych przez agenta, nie tylko skills.- Ujawnienie ukrywanego od kilku miesięcy skilla
/wizard, generującego interaktywne kreatory bashowe do zadań, które musi wykonać człowiek. - Nowy
/to-questionnaire— zamiana sesji odpytywania w dokument, przez który można przejść z inną osobą. - Zapowiedź samodzielnego, tańszego kursu AI coding dostępnego przez cały rok.
Redakcyjne tłumaczenie
Wersja 1.2.0 i wreszcie porządna dokumentacja
Skills, skills i jeszcze raz skills. Mam dla was kolejną porcję. To wersja 1.2.0, która wprowadza sporo usprawnień do moich — już i tak bardzo popularnych — skills inżynierskich. Repozytorium jest chyba dwudziestym czwartym najczęściej gwiazdkowanym repo w historii GitHuba, ma już 24 tysiące gwiazdek. A skoro to dojrzały projekt, potrzebuje porządnej dokumentacji. I ją mamy — pod adresem aihero.dev/skills.
(Informacja dodatkowa: „skills” to w ekosystemie Claude Code katalogi z instrukcjami, które agent wczytuje na żądanie albo z własnej inicjatywy; pozwalają opakować powtarzalny sposób pracy w wywoływalną komendę.)
Pracowałem nad tą stroną z zespołem i wyszła naprawdę świetnie. Najlepiej zwiedzać ją od strony głównej /skills, gdzie widać pogrupowane zestawy. Widać na przykład główny przepływ pracy: zaczynasz od grill-with-docs, potem przechodzisz do specyfikacji, dalej do ticketów, implementacji i wreszcie do code review. W lewym panelu znajdziecie pełny spis wszystkich skills wraz z opisem, co robią.
Pisanie dokumentacji było kiedyś moją etatową pracą, więc z przyjemnością do tego wróciłem. Jest tam nawet lista często zadawanych pytań, zaczerpnięta z prywatnej wiki, w której zbieram wszystkie pytania, jakie ludzie mi zadają. Skills są też powiązane ze słownikiem AI coding, który buduję. Ten mały odnośnik „ticket” prowadzi na przykład do definicji tego, co ja rozumiem przez ticket. Dokumentacja służy więc nie tylko do lepszego poznania moich skills — można z niej korzystać po prostu po to, żeby na głębokim poziomie zrozumieć, jak działa praca z agentami.
Oficjalny marketplace Claude Code
Druga duża zmiana: jesteśmy teraz częścią oficjalnego marketplace’u wtyczek Claude Code. Otwieracie Claude Code, wpisujecie polecenie plugin, wyszukujecie „Matt Pocock” albo „Matt Pocock skills” i instalujecie prosto z tego miejsca. Dostajecie paczkę tylko do odczytu, bez żadnych dodatkowych kroków, a wszystkie moje aktualizacje będą się do was pobierać automatycznie.
Wsparcie dla Codeksa: pliki sidecar
To brzmi dobrze, jeśli używacie Claude Code. Ale co z użytkownikami Codeksa? Co ta wersja daje im? Dołączam teraz pliki openai.yaml do każdego pojedynczego skilla. Dzięki temu wszystko powinno działać od ręki z interfejsami w rodzaju Codex UI, a przy okazji ustawienie allow-implicit-invocation: false przenosi się na Codeksa.
Wcześniej mieliśmy skills wywoływane przez model i skills wywoływane przez użytkownika. Zaleta tych drugich — widoczna w głównym pliku SKILL.md — polega na tym, że są ukryte przed oknem kontekstowym agenta, dopóki sam ich nie wywołasz. To działa w Claude Code, działa w Pi, działa w kilku innych środowiskach, ale nie działało w Codeksie. Nie do końca zdawałem sobie z tego sprawę. Dlatego teraz wysyłamy pliki sidecar razem z każdym skillem, żeby allow-implicit-invocation: false działał także tam.
(Informacja dodatkowa: sidecar to plik towarzyszący głównemu, który dokłada metadane dla konkretnego środowiska, nie zmieniając oryginału.)
/wait-what — lekarstwo na rozwlekłość modelu
Kolejna rzecz, dla której chciałem wypuścić skilla: Opus, a zwłaszcza Opus 5, mówi ostatnio bełkotem. Nie rozumiem, z czego to wynika, podejrzewam, że to typowa przypadłość nowego modelu. Ale z jakiegoś powodu za każdym razem, kiedy z Opusem rozmawiam, wszystko przelatuje mi nad głową. Jest niesamowicie rozwlekły, używa dziwacznych zwrotów rodem z LLM-ów i naprawdę ciężko mi się to czyta. Wiele osób ma to samo odczucie.
Brzmi to mniej więcej tak: „Uczciwe opcje to zaakceptować to i przeredagować kryteria akceptacji albo utrwalić skrót wzdłuż eksportu. Dzięki temu wznowiona, niezmieniona publikacja może pominąć odczyt na rzecz flagowania zamiast wybierania”. Co to w ogóle znaczy? A przecież to zdanie naprawdę niesie treść — i po tym właśnie poznajesz, że sprawa jest istotna.
Próbowałem to naprawiać na różne sposoby: przez output styles, przez dopiski w AGENTS.md. Ale zrozumiałem, że potrzebuję po prostu skilla, który powie: „zaraz, coś ty właśnie powiedział?”. Skill nazywa się więc wait-what. Jest bardzo prosty i robi dwie rzeczy.
Po pierwsze, każe używać konkretnego standardu ASD-STE100, czyli uproszczonego technicznego angielskiego. To w gruncie rzeczy hasło wywoławcze dla agenta: używaj bardzo prostego języka, mów jasnymi zdaniami oznajmującymi.
(Informacja dodatkowa: ASD-STE100 to standard kontrolowanego języka angielskiego stworzony dla dokumentacji lotniczej — ogranicza słownictwo i strukturę zdań, żeby teksty były jednoznaczne.)
Po drugie, każe mu się osadzić we wspólnym języku z pliku context.md. Prawdziwym lekarstwem na rozwlekłość nie jest bowiem polecenie „używaj prostego języka” — choć trochę tego też tu robimy — tylko polecenie „używaj mojego języka”, tego, który wypracowaliście w grill-with-docs.
Tego skilla używacie zawsze wtedy, gdy agent wyprodukuje jakiś przypadkowy bełkot i nie macie pojęcia, co właśnie powiedział. Mówicie po prostu: „Zaraz, co?” — a on powinien odpowiedzieć znacznie lepszą wersją.
/grill-me w rundach zamiast pytanie po pytaniu
Następna zmiana jest dość duża. To aktualizacja mojego najpopularniejszego skilla, czyli grill-me. Do tej pory grill-me przepytywał po jednym pytaniu naraz: dostajesz pytanie, odpowiadasz, dostajesz kolejne, znów odpowiadasz. Jedno pytanie na turę.
Ma to jednak fatalny scenariusz porażki. Pod koniec sesji, kiedy wszystkie trudne rzeczy są już przerobione, zostaje ci garść łatwych pytań — po jednym na turę — na które w kółko odpowiadasz „tak, brzmi dobrze”, „tak, to też brzmi dobrze”. To potwornie irytujące i strasznie wolne.
Od dłuższego czasu szukałem sposobu, żeby to przyspieszyć. Najsensowniejsze wydawało mi się zadawanie wielu pytań w jednej turze — jeśli masz dużo łatwych, możesz po prostu odpowiedzieć „tak, tak, tak, tak”. Ale co się dzieje, gdy odpowiedź na pytanie trzecie zależy od odpowiedzi na pytanie pierwsze? Wcześniej takiego problemu nie było, bo odpowiadałeś po kolei — jeśli jakieś pytanie zależało od wcześniejszego, to tamto miało już odpowiedź. W nowym układzie powinno być przecież bardziej chaotycznie: odpowiadasz na pytania błędne, w złym momencie albo takie, które wymagają wcześniejszego rozstrzygnięcia. Jak to ma działać?
Otóż jeśli się nad tym zastanowić, te pytania tworzą graf. Na samym początku może stać jedno krytyczne pytanie, które trzeba rozstrzygnąć, a które otwiera całą serię kolejnych — te z kolei prowadzą do następnych. Dlatego grill-me podąża teraz za tym grafem: zadaje wyłącznie te pytania, które są dostępne w danym momencie, ale zadaje je rundami. Dostajesz pierwszą rundę, w której może być zaledwie jedno krytyczne pytanie. Potem przechodzisz do kolejnej rundy, którą tamto pytanie otworzyło. Cały czas przesuwa cię tak szybko, jak się da, wzdłuż frontu pytań.
Wygląda to tak: jestem w rundzie pierwszej, mam pytanie Q1, a pod nim rekomendację. Zdecydowałem się użyć — wiem, wiem, pewnie tego nie lubicie, ale ja to uwielbiam — emoji, dla odrobiny koloru. Dzięki temu bardzo łatwo nawiguje się wzrokiem. Widzę: to jest Q1, a to rekomendowana odpowiedź. Q2, rekomendowana odpowiedź. A ponieważ korzystam z dyktowania, mogę to po prostu wystrzelić z siebie: „Q1 — zgadzam się. Q2 — zgadzam się. Q3 — tu trzeba coś zmienić. Q4 — tu też trzeba coś zmienić”. Niżej widać rundę drugą, zbudowaną tak samo. Odpowiedzieliśmy na pierwszą rundę pytań, dostaliśmy kolejną i dalej przesuwaliśmy front.
writing-for-agents zamiast writing-great-skills
Następna duża zmiana: przerobiłem skilla writing-great-skills, bo zauważyłem, że używam go do rzeczy innych niż skills. Używałem go do wszystkiego, co czyta agent — żeby agent działał lepiej, żeby dokument był bardziej zwięzły, a wynik bardziej przewidywalny.
Dlatego mamy teraz writing-for-agents. Można nim modyfikować AGENTS.md, CLAUDE.md, a także tworzyć i edytować skills — mechanika samych skills została doklejona w osobnym pliku referencyjnym. Da się go więc użyć do pisania skills, a co kluczowe — do wyciągania zawartości AGENTS.md i przenoszenia jej do skills, żeby zatrzymać to okropne ładowanie wszystkiego z góry.
(Informacja dodatkowa: „frontloading” to sytuacja, w której cała konfiguracja siedzi w jednym pliku wczytywanym na starcie każdej sesji i zjada okno kontekstowe, niezależnie od tego, czy jest w danym zadaniu potrzebna.)
Ogólnie łapię się na tym, że sięgam po tego skilla bardzo, bardzo często — zawsze gdy piszę jakąkolwiek konfigurację dla agenta i chcę, żeby dobrze się czytała i żeby agent dobrze z nią pracował. writing-for-agents to właściwy wybór. Jest przy tym wywoływalny również przez model, a jego opis jest naprawdę czysty, więc powinien się sam włączać, ilekroć agent modyfikuje AGENTS.md. To świetna sprawa.
/wizard — interaktywne kreatory dla człowieka
Kolejna rzecz to zupełnie nowy skill, który przez pewien czas trzymałem w ukryciu. To wizard. Musiałem ostatnio postawić trochę infrastruktury i przejść przez masę rzeczy w AWS-ie. Nienawidziłem tego i pomyślałem: przecież agent musi umieć mi tu pomóc.
Stworzyłem więc skilla wizard, który generuje interaktywnego kreatora w bashu, prowadzącego człowieka przez kroki, które tylko on może wykonać. Innymi słowy — pewnie mógłbym kazać agentowi wejść do AWS-a i wyklikać to przez computer use, ale to mi się wydawało niesmaczne. Chciałem zachować kontrolę nad wszystkim, a jednocześnie żeby było to możliwie łatwe.
Wygląda to tak. To był chyba kreator do migracji na zdalną maszynę. Odpalasz go, on pyta: „Gotowy, żeby zacząć?”, odpowiadasz „tak, poproszę”. I wysyła mnie dokładnie na tę stronę, na którą mam wejść — nawiasem mówiąc, to skrypt ją otworzył, nie musiałem nic robić. Odsyła mnie, każe się zalogować, każe zmienić dokładnie to, co trzeba. Wklejam swoje klucze API. Pamiętajcie: to deterministyczny skrypt, żaden agent tego nie dotyka. Nic nie leci do Anthropica ani nigdzie indziej. Wklejam więc klucz tutaj, a skrypt zapisuje go do właściwych plików — w razie potrzeby nawet do sekretów GitHuba. I tak prowadzi mnie przez kolejne etapy, z tym miłym interfejsem, aż dochodzimy do celu.
Odkryłem, że to przenosi provisioning usług z kategorii „potworna udręka” do kategorii „dziwnie przyjemne” — bo doskonale pamiętam, ile mi to wcześniej zajmowało. wizard stał się nieodzowną częścią mojego zestawu. Miałem go w toku przez kilka miesięcy i uznałem: dobra, czas, żebyście go zobaczyli.
/to-questionnaire — sesja odpytywania jako dokument dla ludzi
Kolejny ma zdecydowanie najnudniejszą nazwę, jaką kiedykolwiek wymyśliłem, ale okazał mi się bardzo potrzebny i zrozumiałem, że przyda się do więcej niż jednego zastosowania. Nazywa się to-questionnaire, a jego zadaniem jest wziąć decyzje z sesji odpytywania i wyciągnąć je do dokumentu, przez który można przejść z inną osobą.
Prowadziłem sesję wayfinder, żeby zaprojektować biuro ogrodowe na tyłach domu. Zorientowałem się, że agent przepytuje mnie, a osobą, z którą naprawdę powinienem o tym rozmawiać, jest moja żona — bo ona też będzie z tej przestrzeni korzystać, więc projektujemy ją wspólnie. Kazałem więc agentowi zamienić pytania, które miał zadać w sesji, w dokument Markdown. Wrzuciłem go do Google Docs, wysłałem żonie, przeszliśmy przez niego razem, a odpowiedzi wciągnęliśmy z powrotem do agenta.
To skill, który mam nadzieję kiedyś usunąć, bo jest w gruncie rzeczy łatką na to, że z agentami trudno się dziś współpracuje w grupie. Niektóre zespoły mają — moim zdaniem naprawdę dobre — ustawienie, w którym agent siedzi w Slacku: prowadzą tam rozmowy, w których mogą go otagować, więc współpracują i odpowiadają na pytania razem, zwłaszcza z interesariuszami, a agent może się wtrącić i powiedzieć „dobra, zaimplementuję to na tej podstawie”. Ale wiele osób jeszcze w tym świecie nie żyje. Wiele osób nie jest AI-native, może nie mają nawet Slacka ani Microsoft Teams. Dlatego posiadanie dokumentu, który da się po prostu wyjąć, komuś przekazać, a on go skomentuje w Google Docs czy gdziekolwiek indziej, jest naprawdę użyteczne.
Podsumowanie i zapowiedź kursu
I to w zasadzie tyle. Mamy porcję nowych skills. Szczególnie ciekaw jestem waszych reakcji na wait-what, bo myślę, że kilka razy uratuje wam skórę, kiedy Opus zacznie wyprawiać dziwne rzeczy. Kilka drobiazgów było zbyt małych, żeby o nich tu wspominać — pełną listę zmian znajdziecie przy wydaniu v1.2.0 w releasach na GitHubie.
A jeśli podoba wam się ten temat, wypuszczam kurs-przyspieszony z AI coding, dość odmienny od płatnych kursów, które robiłem wcześniej. Zamiast kohorty, w której wszyscy przechodzą materiał razem w ciągu kilku tygodni, będzie to tańszy kurs dostępny przez cały rok. Moim zdaniem AI coding trochę się już ustabilizowało — od mniej więcej grudnia zeszłego roku nie zmieniło się aż tak wiele. Czuję się więc na tyle pewnie, żeby wypuścić kurs do samodzielnego przerabiania, który — mam nadzieję — nie zdezaktualizuje się zbyt szybko mimo dalszego rozwoju. Chcę wam dać stabilny fundament, na którym da się pracować i wysyłać w świat świetne rzeczy. Link jest pod filmem, można zapisać się na listę oczekujących. Kurs powinien wyjść za jakieś dwa tygodnie.
Dzięki wielkie za oglądanie, korzystajcie z nowych skills, do zobaczenia wkrótce.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Rozwlekłość modelu leczy się wspólnym słownikiem, nie prośbą o prostotę
Na czym polega: Kluczowa teza wait-what brzmi: prawdziwym lekarstwem na bełkot nie jest polecenie „pisz prosto”, tylko polecenie „pisz moim językiem” — tym wypracowanym wcześniej w dokumentach projektu (u Pococka: context.md).
Jak stosować: Utrzymuj plik ze wspólnym słownictwem domenowym projektu i odsyłaj do niego agenta, gdy odpowiedź jest niezrozumiała. Prośbę o uproszczenie łącz z zakotwiczeniem w konkretnych pojęciach.
Na co uważać: Jeśli takiego słownika nie masz, sam mechanizm zadziała słabo — zostanie tylko połowa lekarstwa. Zadbaj najpierw o dokument z terminologią, inaczej agent podstawi własne, ogólne pojęcia.
2.Standard uproszczonego angielskiego jako hasło wywoławcze
Na czym polega: wait-what powołuje się na ASD-STE100 — realnie istniejący standard kontrolowanego angielskiego — jako skrót informujący model, żeby mówił jasnymi zdaniami oznajmującymi.
Jak stosować: Odwoływanie się do nazwanego standardu działa lepiej niż mgliste „pisz prościej”, bo model ma z nim skojarzone konkretne reguły. Tę technikę możesz przenieść do własnych promptów i output styles.
Na co uważać: Standard powstał dla dokumentacji technicznej — jeśli oczekujesz od agenta niuansowanej dyskusji o kompromisach projektowych, wymuszona prostota może obciąć treść, nie tylko formę. Używaj go doraźnie, do wyjaśniania, a nie na stałe.
3.Przepytywanie rundami zamiast pytanie po pytaniu
Na czym polega: Nowe grill-me traktuje pytania jak graf zależności i zadaje w każdej rundzie tylko te, które są w danym momencie „odblokowane” — czasem jedno krytyczne, czasem kilkanaście łatwych.
Jak stosować: Jeśli budujesz własny skill do zbierania wymagań, nie wybieraj sztywno między „jedno pytanie na turę” a „wszystko naraz”. Każ modelowi ustalić zależności i grupować pytania w rundy.
Na co uważać: Skuteczność zależy od tego, czy model poprawnie rozpozna zależności. Gdy odpowiedź na pytanie z tej samej rundy zmienia sens innego, trzeba to wychwycić samemu — model już rundę wypuścił.
4.Rekomendowana odpowiedź przy każdym pytaniu
Na czym polega: Każde pytanie w rundzie ma dołączoną rekomendację, dzięki czemu odpowiedź „zgadzam się” jest tania, a uwaga skupia się na tych pytaniach, gdzie faktycznie chcesz coś zmienić.
Jak stosować: Dodaj wymóg rekomendacji do własnych promptów zbierających decyzje. Przy dyktowaniu pozwala to przelecieć rundę jednym ciągiem wypowiedzi.
Na co uważać: Rekomendacje sprzyjają bezrefleksyjnemu przyklepywaniu. Przy decyzjach architektonicznych o dużym koszcie zmiany warto przeczytać uzasadnienie, a nie tylko sam werdykt.
5.Skills ukryte przed kontekstem wymagają wsparcia środowiska
Na czym polega: Ustawienie „nie pokazuj tego skilla modelowi, dopóki użytkownik go nie wywoła” działa w Claude Code i kilku innych narzędziach, ale nie działało w Codeksie — stąd dokładanie plików openai.yaml obok każdego skilla.
Jak stosować: Jeśli dystrybuujesz skills dla różnych środowisk, sprawdź osobno w każdym z nich, czy ukrywanie faktycznie działa. Nie zakładaj przenośności metadanych.
Na co uważać: Milcząca awaria tego mechanizmu jest kosztowna: skills, które miały być niewidoczne, ładują się do kontekstu i model wywołuje je z własnej inicjatywy w nieodpowiednich momentach.
6.Przenoszenie AGENTS.md do skills zamiast puchnięcia pliku startowego
Na czym polega: writing-for-agents służy między innymi do wyciągania treści z AGENTS.md czy CLAUDE.md do osobnych skills, żeby zatrzymać ładowanie wszystkiego z góry przy każdej sesji.
Jak stosować: Przejrzyj swój plik konfiguracyjny agenta i wydziel to, co dotyczy konkretnych, rzadszych zadań, do osobnych skills wczytywanych na żądanie. W pliku głównym zostaw tylko to, co potrzebne zawsze.
Na co uważać: Wydzielenie za dużo sprawia, że agent nie wie o istnieniu reguły, dopóki jej nie wczyta — a wczyta ją tylko wtedy, gdy opis skilla jest wystarczająco trafny. Opisy skills stają się wtedy krytyczne.
7.Deterministyczny kreator tam, gdzie agent nie powinien sięgać
Na czym polega: wizard każe agentowi wygenerować skrypt bashowy prowadzący człowieka przez kroki, które tylko on może wykonać — logowanie do konsoli chmury, wklejanie kluczy API. Sam skrypt jest deterministyczny, nic nie trafia do modelu.
Jak stosować: Traktuj to jako wzorzec dla wszystkich zadań z sekretami i dostępem produkcyjnym: agent pisze narzędzie, człowiek je wykonuje. Skrypt może zapisywać wartości do plików czy sekretów repozytorium.
Na co uważać: Skrypt wygenerowany przez model wciąż warto przeczytać przed uruchomieniem — zwłaszcza tam, gdzie dotyka kluczy, zmiennych środowiskowych albo sekretów. Deterministyczność nie znaczy poprawność.
8.Sesję odpytywania da się wyeksportować dla osób spoza narzędzia
Na czym polega: to-questionnaire zamienia pytania z sesji z agentem w dokument Markdown, który można przekazać komuś innemu — do Google Docs, do skomentowania — a odpowiedzi wciągnąć z powrotem.
Jak stosować: Sięgaj po to, gdy decyzje wymagają udziału osoby nieużywającej agenta: klienta, interesariusza, współpracownika z innego działu. Działa też poza kontekstem programistycznym.
Na co uważać: To obejście, nie docelowe rozwiązanie — sam autor liczy, że kiedyś je usunie. Jeśli twój zespół może posadzić agenta w Slacku czy Teams i tam prowadzić rozmowę z otagowaniem go, to lepsza droga.
9.Instalacja przez oficjalny marketplace daje automatyczne aktualizacje
Na czym polega: Zestaw jest dostępny w oficjalnym marketplace wtyczek Claude Code — po instalacji dostajesz paczkę tylko do odczytu, a aktualizacje pobierają się same.
Jak stosować: Jeśli korzystasz z cudzych skills bez zamiaru ich modyfikowania, wybieraj tę ścieżkę zamiast kopiowania plików. Znika ryzyko pracy na przestarzałej wersji.
Na co uważać: Tryb tylko do odczytu oznacza brak możliwości lokalnych poprawek, a automatyczne aktualizacje mogą zmienić zachowanie skilla, na którym opiera się twój proces. Śledź changelog przy większych wydaniach.
10.Tempo zmian w AI coding wyhamowało — praktyki zaczynają się stabilizować
Na czym polega: Pocock ocenia, że od mniej więcej grudnia poprzedniego roku niewiele się fundamentalnie zmieniło, i na tej podstawie decyduje się wypuścić kurs do samodzielnego przerabiania zamiast kohortowego.
Jak stosować: Jeśli odkładałeś spisanie własnych procesów pracy z agentem w obawie, że natychmiast się zdezaktualizują, to dobry moment, żeby je utrwalić — inwestycja w dokumentację i skills ma szansę się zwrócić.
Na co uważać: To osobista opinia jednej osoby o rynku, nie pomiar. Stabilizacja praktyk nie wyklucza, że pojedyncza zmiana w modelu albo narzędziu wywróci konkretny element twojego przepływu pracy — o czym najlepiej świadczy sam wait-what, powstały jako reakcja na zachowanie nowego modelu.