O czym jest ten film
- Autor zlecił dwóm modelom — Claude Fable 5.1 i GPT-6 Astra — dokładnie to samo zadanie: budowę natywnego menedżera schowka na Maca na podstawie krótkiego promptu.
- Fable stworzył „Ledge”, wąską listę wysuwaną z prawej krawędzi ekranu; Astra — „Shelf”, szeroki pasek na dole z dużymi kartami, filtrami i podglądem.
- Astra dotarła do używalnej wersji szybciej i przy niższym zużyciu tokenów, co przełożyło się na więcej rund poprawek (1.0–1.2) w czasie, gdy Fable kończył wersję 1.0.
- Dwie różne, dobrze wykonane koncepcje designu pomogły autorowi zrozumieć, czego naprawdę chce — tego nie dałoby się ustalić na etapie pierwszego promptu.
- O codziennej użyteczności przesądziły detale: skrót Control+Shift+spacja okazał się łatwiejszy do zapamiętania niż Command+Shift+V, a brak komunikatu „skopiowano” dokładał niepewności przy każdej operacji.
- Astra przyjmowała poprawki w języku naturalnym (zrzut ekranu, opis objawu) i sama proponowała rozwiązania; finalny instalator przechodzi ponad 65 testów wymyślonych przez model.
- Najwyższą miarą sukcesu okazała się reakcja bardzo zapracowanej osoby, która od razu zainstalowała aplikację i została przy niej.
- Autor przestrzega przed szukaniem „najlepszego modelu raz na zawsze” — modele warto przydzielać do ról jak współpracownikom i regularnie przeglądać te przydziały.
- Praktyczny podział ról: Fable do głębokiego przemyślenia problemu i designu, Astra do szybkiej egzekucji, pisania i operowania komputerem, tańsze modele do prostej robocizny.
- Do zbudowania tej aplikacji nie był potrzebny system multiagentowy — wystarczył jeden agent i prompt na pięć linijek.
Redakcyjne tłumaczenie
Jedno zadanie, dwie aplikacje
Jedno zadanie, dwa modele — a w efekcie dwie zupełnie różne aplikacje, które próbują rozwiązać dokładnie ten sam problem: piekło kopiuj-wklej. Fable zbudował „Ledge”, wąską listę wysuwaną z prawej krawędzi ekranu. Astra postawiła na „Shelf”: szeroki pasek na dole, z dużymi kartami i okienkiem podglądu. Oba modele dostały identyczne zlecenie i tyle samo czasu, a w obu przypadkach powstało dopracowane, działające oprogramowanie. Przyznam, że sam jestem trochę zaskoczony.
Czego natomiast dziś praktycznie nikt nie mierzy, to sposób porównywania modeli w drugiej rundzie. Co robić dalej, gdy etap vibe codingu i pięciolinijkowych promptów masz już za sobą? Jak przejść od pierwszej wersji do gotowej aplikacji? Właśnie temu poświęcam ten materiał: rundzie poprawek, którą rozgrywasz wtedy, gdy działająca rzecz jest już w twoich rękach. I moim zdaniem to ważniejsze niż kiedykolwiek wcześniej. Na końcu wrzucam linki — pobranie zarówno Shelf, jak i Ledge zajmie chwilę.
(Informacja dodatkowa: „Fable 5.1” to nazwa modelu Claude firmy Anthropic; „Astra” — wariant modelu GPT-6 od OpenAI, dostępny w ChatGPT.)
(Informacja dodatkowa: vibe coding to styl tworzenia oprogramowania, w którym aplikację buduje się razem z modelem AI na podstawie krótkich, potocznych poleceń — bez samodzielnego pisania kodu.)
Zlecenie: menedżer schowka, jakiego brakuje w macOS
Konkrety: ChatGPT 6 Astra i Claude Fable 5.1 dostały dokładnie tę samą robotę. Brzmiała mniej więcej tak: „Męczę się z kopiowaniem i wklejaniem — o tym piekle mówiłem już na kanale. Zbuduj mi natywny menedżer schowka na Maca, taki, jakiego Apple powinien był od początku dostarczyć w systemie. Coś, co zapamiętuje kopiowany tekst, obrazy i linki, a potem pozwala przywołać je skrótem klawiszowym. Nie chcę pamiętać, co kiedy kopiowałem, ani ograniczać się do ostatniej pozycji.”
Pierwsze wyniki: mniej tokenów, więcej iteracji
W tym pojedynku Astra szybko dała mi coś, co nie tylko przypadło mi do gustu, ale czego naprawdę zacząłem używać do kopiowania. Wyszła na to mniejszym nakładem tokenów, oszczędziła mi około godziny, a to z kolei zostawiło więcej czasu na wypróbowanie aplikacji i zgłaszanie zmian — przeszedłem więc więcej rund rozwojowych. Fable zaproponował projekt, który również mi się podobał, ale ostatecznie okazał się mniej wygodny, i to przez drobiazgi w rodzaju skrótów klawiszowych; zaraz do nich dojdziemy.
Zawsze najbardziej zależy mi na tym, co konkretnie potrafię komuś zlecić i jak zagospodarowuję to, co wraca — w ten sposób AI realnie zwiększa moją produktywność. Tutaj zadanie było na tyle małe, że efekt można było sprawdzić od ręki: kopiuję fragment, otwieram panel w Ledge albo w Shelf, odnajduję go i wracam do przerwanej pracy. Po prostu wszedłem w nawyk korzystania z tego. A nawyk to ostateczny sprawdzian każdego oprogramowania.
Dwie wizje tego samego narzędzia
Ledge to wąska lista wyskakująca z prawej strony ekranu. Skopiujecie kolor — zobaczycie pełną próbkę. Kod wygląda jak kod. Shelf nie ma takiej precyzji; jest za to szeroki, z dużymi kartami, filtrami i obszerniejszym podglądem. Widać w tym dwie skrajnie różne koncepcje tego, jak narzędzie ma wpisać się w codzienną pracę — i właśnie to pokochałem, bo mogłem wypróbować obie w praktyce i rozwijać je w miarę użytkowania.
Bardzo cenię to, że na identyczne polecenie Fable odpowiedział czymś wyraźnie innym niż Astra. Jednym z najcenniejszych efektów takiego eksperymentu jest odkrycie, że sam nigdy nie rozstrzygnąłeś, czego właściwie chcesz — i nie miałeś jak, przy prompcie na pięć linijek. Chciałem dyskretnej listy? Nie podjąłem tej decyzji. Potrzebowałem więcej miejsca, by obejrzeć obraz? Też nie wiedziałem. Gdy widzisz różne, a przy tym dobrze wykonane decyzje projektowe w dwóch formatach, własne preferencje dużo łatwiej nazwać, rozwijać i zrozumieć.
Różne drogi do celu — i różne koszty startu
Oba modele dostały taki sam brief na start, ale wcale nie ruszyły tą samą drogą — i bardzo dobrze. Fable zadał pytania doprecyzowujące, między innymi o to, przy której krawędzi ekranu ma się pojawić panel. Astra na własną rękę wybrała dolną. Z Fable pracowałem przez Claude Co-work, z Astrą — przez Codex na Macu. Doświadczenie użytkownika składa się więc nie tylko z samych modeli, ale też z aplikacji i mechanizmów dostępu, które je otaczają — dziś to już norma. I każda przeszkoda na starcie, przy konfiguracji, zamienia się w realny koszt dla kogoś, kto chce szybko dokończyć robotę.
Jest w tym jeszcze jedna ciekawa rzecz: oba modele i ich aplikacje pokazują, że to samo utrudnienie różni ludzie odbierają inaczej. Różnic w tych decyzjach projektowych nie nazwałbym różnicą inteligencji. Widzę raczej dwie odrębne perspektywy — a one pomogły mi, twórcy aplikacji, lepiej zrozumieć, czego szukam pośród możliwych rozwiązań.
(Informacja dodatkowa: Co-work to agentowy tryb pracy w aplikacji Claude; Codex to narzędzie OpenAI do zadań programistycznych, tutaj uruchamiane lokalnie na Macu.)
Skrót klawiszowy, który przesądził o użyteczności
Shelf otwiera kombinacja Control+Shift+spacja. Uwielbiam ten wielki klawisz spacji — łapie się go bez patrzenia i idzie dalej. Jest coś intuicyjnego w tym, że spaca leży na dole klawiatury, a pasek wysuwa się z dołu ekranu. Ledge korzysta z Command+Shift+V — to działa, ale skrót Shelf zapamiętałem łatwiej. Brzmi to jak detal zbyt błahy, by miał cokolwiek znaczyć w porównaniu modeli; miarą inteligencji z pewnością nie jest. Z perspektywy użyteczności jednak: jeśli kopiujesz i wklejasz na okrągło, masz w palcach Control+C i Control+V, a tuż obok pojawia się skrót, którym sięgasz po wcześniejsze pozycje schowka — dla moich rąk to było po prostu naturalne. Wziąłem to pod uwagę, bo w oprogramowaniu chodzi o to, żeby było tak proste, że znika w tle i staje się przezroczyste.
Druga runda: zgłaszamy poprawki
Wizualnie lekko preferowałem projekt Astry, zwłaszcza sposób, w jaki obchodziła się z kartami i podglądem. Ale mój gust to nie twój gust — ktoś inny woli wąską listę, przede wszystkim gdy chce tylko pochwycić kawałek tekstu i pójść dalej.
Potem zaczęły się jednak rzeczy do zmiany. Część kart źle się wyrównywała przy lewej krawędzi. Chciałem przestawić panel i móc go przeciągać. Skróty z cyframi odpalały inne funkcje na Macu. No i ostatnia sprawa: skopiowałem coś — i chciałbym mieć tego pewność. Aplikacja nie pokazywała żadnego komunikatu, że operacja się udała. To najzwyklejszy softwarowy detal: robisz coś i chcesz wiedzieć, że zadziałało. Bez tego potwierdzenia zaczynasz powtarzać czynność, wklejać w próbnym miejscu, żeby się upewnić, albo zastanawiać się, czy nie wskoczyła niewłaściwa pozycja. Każda taka odrobina niepewności dokłada zbędnego ciężaru przy każdym użyciu aplikacji.
Z Astrą ten feedback szedł zaskakująco gładko. Na zrzucie ekranu pokazałem, która krawędź się nie zgadza. Powiedziałem, gdzie ma trafić panel. Wskazałem, która kombinacja klawiszy przeszkadza innej aplikacji. Wreszcie: po prostu powiedziałem, że chcę widzieć potwierdzenie skopiowania — nie specyfikując, jak to osiągnąć. Astra wymyśliła to sama.
Test szybkości: trzy wersje w czasie jednej
Możecie się spytać, czemu ten sam feedback nie poszedł do Fable. Bo to część testu szybkości. W czasie, w którym Fable kończył wersję 1.0, z Astrą zdążyłem przejść 1.0, 1.1 i 1.2. Uznałem, że to uczciwe: szybszy model pozwala wykonać więcej iteracji i rozwijać rzecz na bieżąco. A całość zgłoszonych zmian Astra zrealizowała: Shelf pamięta teraz swoje położenie i da się go przeciągać; po udanym kopiowaniu pokazuje komunikat; klawisze szybkiego kopiowania zostały przełożone; a aplikacja czeka, aż puszczę klawisz, i dopiero wtedy oddaje fokus poprzedniemu programowi. Ten ostatni detal ma znaczenie: gdyby fokus wrócił w złym momencie, ten sam klawisz mógłby odpalić skrót w aplikacji pod spodem — a tego nie chcemy.
Wszystko to weszło do wersji 1.1 i 1.2, a instalowany dziś build przechodzi ponad 65 testów wymyślonych przez Astrę — od przywracania schowka, przez zapisaną historię, po zachowanie klawiatury; do tego interakcje zostały przetestowane na żywo. Cała ta sztuka polega na budowaniu z myślą o drugiej i trzeciej rundzie promptowania.
Najwyższa miara sukcesu: czy ktoś inny chce z tego korzystać
Najwyższą miarą sukcesu jest dla mnie to, czy ktoś inny chce używać rzeczy, którą zrobiłem. Tak, sam lubię — ale pokazałem aplikację osobie skrajnie zapracowanej, z ogromem spraw na głowie, spędzającej przy komputerze cały dzień. Usłyszałem: „To jest aplikacja, którą chętnie bym używała.” Zainstalowała ją od razu i zaczęła pracować. Wtedy poczułem, że rzeczywiście użyłem AI do zbudowania czegoś pożytecznego. Z Fable i Astrą zbadałem zakres możliwych rozwiązań, zrozumiałem, co mi odpowiada, i doprowadziłem budowę do końca. Astra wygenerowała natywny instalator na Maca — plik DMG — który zdołałem podpisać i przepuścić przez apple’owy proces weryfikacji, dzięki czemu każdy posiadacz Maca zainstaluje aplikację bez ceregieli.
Dlaczego szybkość iteracji zmienia jakość — i gust
Wróćmy do szybkości, bo — mówię szczerze — to ona zmieniła moją preferencję. Gdy pierwsza wersja wraca prędzej, testuję ją, póki mam czas i skupienie na projekcie. Dostrzegam problem, o którym nigdy nie przyszłoby mi napisać w pierwszym prompcie — z całą wiedzą świeżo załadowaną w głowie — i mogę wziąć kolejną wersję, by sprawdzić, czy poprawka pomogła. Tempo iteracji bezpośrednio przekłada się na jakość tego, co finalnie potrafię wyprodukować i wam pokazać. Pierwsza wersja ukształtowała też sposób, w jaki zamawiam kolejne rzeczy: model nie musiał odgadywać wszystkich moich preferencji na starcie, bo posuwał się szybko, a ja nie musiałem pisać doskonałej specyfikacji, zanim cokolwiek użyłem.
Jesteśmy w punkcie, w którym z bardzo krótkiego promptu dostajesz używalną aplikację, rozwijasz ją jeden, dwa razy, przechodzisz zatwierdzenie u Apple — i możesz ją rozdawać. W tym projekcie takie doświadczenie dała mi szybciej Astra, i to przy niższym zużyciu tokenów.
Nie ma „najlepszego modelu” — są role
To był jeden build. Czy zamierzam twierdzić, że Astra zawsze będzie szybsza i tańsza w tokenach, że zawsze wybrałbym jej wersję? Skąd. Wiem, że wielu z was ekscytuje wybór właściwego modelu: czy ten będzie najlepszy do tego zadania? Jak przejść od jednego modelu do wielu? Pomyślmy o tym tak: daję wam swego rodzaju CV tych modeli — relację z tego, jak poradziły sobie na konkretnych stanowiskach. Bo jeśli zbyt mocno oprę się na jednym z nich, to ja tracę, nie korzystając z inteligencji, którą wnosi tamten drugi. Moim zadaniem jako człowieka jest rozstrzygnąć, gdzie ta inteligencja się przyda, i posadzić model we właściwym miejscu — trochę jak powierzyć komuś pracę, która idealnie do niego pasuje. Wstaw model tam, gdzie może rozkwitnąć.
Takie jest centrum mojej uwagi i będzie nim tym bardziej, im mądrzejsze stają się modele i im bardziej przypominają współpracowników: gdzie ten współpracownik rozkwita? W jakiej roli naprawdę mu się powiedzie? Waszym zadaniem jest dopasowanie: przyjrzyjcie się bliżej rolom, które macie do obsadzenia, i traktujcie takie materiały jak ten jako wskazówkę, jak posadzić modele we właściwych miejscach.
Który model do czego: pisanie, arkusze, prezentacje, komputer
Pisanie. Kiedy szukam partnera do tekstu i dopiero rozgryzam problem — walczę z jego zrozumieniem na wysokim poziomie — bez wahania zaczynam od Fable: przemyśleć to razem z nim. Potem przechodzę do Astry, bo ona pomaga nadać myślom szkielet i przełożyć je w coś na kształt planu tekstu; od tego momentu praca idzie bardzo szybko. Znowu wchodzi szybkość — ale na etapie wstępnego rozgryzania problemu szybkość nie jest priorytetem; chcesz to zrobić dobrze, przemyśleć starannie. To jest ten moment, w którym uwielbiam, jak Fable zagłębia się w problem — jest w tym coś wyjątkowego. W takiej sytuacji idę najpierw do niego, a Astra pomaga mi potem pisać.
Zdaję sobie sprawę, że to duża zmiana. Gdybyśmy rozmawiali trzy, cztery, pięć miesięcy temu, wszyscy zakładalibyśmy: do pisania bierzesz Claude’a, do pisania nie idziesz do ChatGPT. A tu jestem i mówię: Astra dała mi projekt interfejsu aplikacji, który naprawdę polubiłem; Astra sprawdziła się jako partnerka do pisania — czuję, że świetnie się z nią współtworzy tekst. To się zmieniło. Astra jest przy pisaniu bardzo sterowna — znakomicie reaguje na wskazówki.
Arkusze. Przy dużym, pogmatwanym arkuszu mój odruch jest dziś taki: Astra robi szkic — rozpisuje strukturę, dowodzi, że wszystkie formuły działają, i przeprowadza wstępną analizę — a potem idę do Fable po projekt, bo wciąż sądzę, że w podejściu Anthropic do PowerPointa i Excela jest coś wyjątkowego, choć wiem, że Astra w tej dziedzinie ogromnie poszła do przodu.
Prezentacje. Rozpisuję punkty i planuję narrację w Astrze — zakładając, że wiem, do czego zmierzam i mam już trochę struktury — a potem przechodzę do Fable, który rozwija całość treścią. Astra bywa przy tym bardzo mocnym partnerem do researchu.
Komputer. Kiedy chodzi o operowanie komputerem — czyli computer use, tryb, w którym model sam klika, wpisuje tekst i porusza się po aplikacjach zamiast użytkownika — oraz o integrację z narzędziami na moim Macu, idę do Astry, w Codex albo Co-work. Szybkość, z jaką ten model posługuje się komputerem, to przepaść. Czyni mnie znacznie skuteczniejszym. I nie sądzę, by to było wyrównane starcie: sterowanie komputerem w Codex i Co-work jest daleko przed tym, co oferuje aplikacja Claude. Szczerze mówiąc, Claude musi w tej dziedzinie nadrobić zaległości i przyspieszyć. A w tej roli szybkość po prostu pomaga.
A może system multiagentowy?
Ostatni temat: systemy multiagentowe, bo wiem, że budzą spore emocje. „Nate, co sądzisz o multi-agent? Jak do tego podchodzisz? Czy Astra jest droga w takim systemie? A jaka rola dla Fable?” Może zastanawiacie się, czy do zbudowania tej aplikacji — Shelf, Ledge — użyłem zestawu multiagentowego. Nie. Uznałem, że niepotrzebny. I to pokazuje, ile da się zrobić bez wchodzenia w multi-agent: prawdziwe oprogramowanie powstało z jednym agentem i jednym promptem na pięć linijek. Pokazałem wam go — i soft po prostu był.
Jednocześnie jestem wielkim fanem otwartych systemów multiagentowych: takich, które da się rozwijać w trakcie. Chodzi o otwarty punkt współpracy — kilka tygodni temu uruchomiłem w tym celu Ringer, ale istnieją i inne rozwiązania. Wymogi są proste: oba koordynujące podmioty — tu Claude i Codex albo Co-work — muszą mieć dostęp do repozytorium i do tablicy komunikatów, a każdemu osobno określasz rolę. Możesz na przykład powiedzieć: „Fable, ty koordynujesz i projektujesz” — to dobra rola dla Fable: przemyśl, zaprojektuj, co aplikacja ma robić, naszkicuj i zbuduj. „Astra, ty pilnujesz tego, co robi Fable, i zlecasz wykonanie dużo tańszemu modelowi OpenAI.” Nasuwa się Luna — bardzo tania i znakomita w egzekucji; zrobiłaby to błyskawicznie. I to jest przykład poukładanego systemu multiagentowego.
(Informacja dodatkowa: Ringer to uruchomione przez autora narzędzie służące właśnie jako otwarty punkt współpracy dla agentów pochodzących od różnych dostawców.)
Co dalej: najlepsze z obu światów
Patrząc wstecz na ten projekt, widzę dwie rzeczy. Po pierwsze: chcę teraz eksplorować z Fable jeszcze więcej, bo zobaczyłem, na co go stać i z jaką dbałością o detale podchodzi do budowania. Po drugie: kontynuując rozwój z Astrą — do wersji 1.3, 1.4 — wciągnąłbym do niej wnioski z projektowej eksploracji Fable, żeby połączyć najlepsze z obu światów.
Mamy się dobrze, i to jak nigdy: żyjemy w świecie, w którym dwie konkurujące firmy AI w niecałe dwie godziny są w stanie dostarczyć znakomite wersje dedykowanego kawałka oprogramowania. Jedna akurat robi to odrobinę szybciej. I to wy będziecie musieli wybrać, co bardziej wam leży. Moja zachęta jest taka: ponieważ oba modele potrafią pokazać naprawdę odmienne perspektywy na możliwe rozwiązania, będziecie mądrzejsi, używając obu. Jak w starciu Godzilli z Megalodonem — wygrywa publiczność. A to zawsze dobry film.
Jeśli chcecie zajrzeć głębiej i sprawdzić, co myślę o konkretnym scenariuszu, pomocny będzie przewodnik na Substacku — jest znacznie bogatszy niż to, co zmieszczę w filmie. Na razie: bawcie się dobrze z Shelf. Pobierzcie, dajcie znać, jak wam się widzi. Ja świetnie się przy tym bawiłem — a skoro widzę, jak łatwo wypuszczać takie drobne narzędzia, z pewnością będę ich używał częściej w porównaniach modeli. Wkrótce kolejne starcie Anthropic kontra OpenAI.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Druga runda decyduje o wyborze modelu
Na czym polega: Praktycznie nikt nie porównuje modeli na etapie po pierwszym promptcie — a to właśnie tam wybiera się narzędzie. Autor dostał od dwóch modeli dwie działające aplikacje i dopiero iterowanie po „wzięciu produktu do ręki” ujawniło różnice, które naprawdę mają znaczenie.
Jak stosować: Przy następnym projekcie daj dwóm modelom identyczny brief, a potem porównuj nie tylko wersję 1.0, lecz przede wszystkim tempo i łatwość wprowadzania poprawek w wersjach 1.1 i 1.2.
Na co uważać: Werdykt z jednego zadania nie jest regułą — autor wprost zastrzega, że nie zakłada stałej przewagi którejkolwiek strony.
2.W krótkim oknie uwagi liczy się szybkość iteracji
Na czym polega: Astra wygrała nie „inteligencją”, tylko czasem i tokenami: w czasie, w którym Fable kończył 1.0, autor z Astrą przeszedł trzy wersje. Szybki zwrot pozwala testować aplikację, póki projekt jest świeży w głowie, i zgłaszać problemy nieprzewidziane w pierwszym prompcie.
Jak stosować: Przy małych narzędziach wybieraj model o krótszym cyklu zwrotu i planuj od razu dwie–trzy rundy poprawek; nie pisz „idealnej specyfikacji” przed pierwszym użyciem.
Na co uważać: Do zadań koncepcyjnych (strategia, rozumienie problemu) szybkość bywa wrogiem — tam autor celowo wraca do wolniejszego, „głębszego” modelu.
3.Dwa różne wykonania uczą, czego naprawdę chcesz
Na czym polega: Wąska lista (Ledge) i pasek z kartami (Shelf) pokazały autorowi, że nie zdawał sobie sprawy z własnych preferencji — pięciolinijkowy prompt nie pozwala ich przesądzić. Kontrast dobrze wykonanych koncepcji ułatwia sformułowanie wymagań.
Jak stosować: Świadomie zamawiaj to samo u dwóch modeli i traktuj rozbieżności jak listę pytań do siebie: wąska lista czy przestronny podgląd? Dyskrecja czy filtry?
Na co uważać: To nie jest ranking inteligencji — różne perspektywy służą odkrywaniu własnego gustu, nie wyłanianiu jedynego słusznego narzędzia.
4.Detale ergonomii ważą więcej niż pozorna „mądrość” modelu
Na czym polega: O codziennej użyteczności przesądziły rzeczy, których nie zmierzy żaden benchmark: Control+Shift+spacja okazał się łatwiejszy do zapamiętania niż Command+Shift+V, a brak komunikatu „skopiowano” zmuszał do wklejania na próbę i powtarzania operacji.
Jak stosować: Oceniaj narzędzia rękami i w nawykach docelowych użytkowników — tam, gdzie „mieszkają” ich palce przy Control+C/V. W drugiej rundzie zamawiaj widoczne potwierdzenie dla każdej operacji.
Na co uważać: Ergonomia jest osobista — ktoś, kto tylko chwyta tekst i biegnie dalej, woli wąską listę od wielkich kart z podglądem.
5.Poprawki zgłaszaj efektem, nie przepisem — i podpieraj się zrzutem ekranu
Na czym polega: Autor nie opisywał rozwiązań; pokazał zrzut ekranu niewyrównanej krawędzi, wskazał kolidujący skrót i powiedział jedynie „chcę wiedzieć, że kopiowanie się udało”. Model sam dobrał mechanizm.
Jak stosować: W promptach poprawkowych opisuj objaw i oczekiwany efekt, a nie implementację; do błędów wizualnych dołączaj zrzuty z zaznaczonym miejscem.
Na co uważać: Nie każdy model przyjmie taki feedback równie sprawnie — warto to sprawdzić na własnym zadaniu, zanim ustawisz stały sposób pracy.
6.Pilnuj interakcji z systemem: fokus i kolizje skrótów
Na czym polega: Skróty z cyframi odpalały inne funkcje macOS, a zbyt wczesne oddanie fokusa mogło uruchomić ten sam skrót w programie „pod spodem”. Wersje 1.1–1.2 naprawiły obie rzeczy, a aplikacja przeszła ponad 65 testów wymyślonych przez sam model — od historii schowka po zachowanie klawiatury.
Jak stosować: Przy narzędziach globalnych (nakładki, hotkeye) każ modelowi przetestować kolizje skrótów i momenty zwrotu fokusa; proś o automatyczne testy klawiatury i zapisanej historii.
Na co uważać: Popularne kombinacje klawiszowe niemal na pewno kolidują z czymś w systemie — zbierz wszystkie kolizje i zgłoś je jedną listą.
7.Ostateczny test: czy ktoś inny dobrowolnie tego użyje
Na czym polega: Najwyższą miarą sukcesu autor uczynił nie własny zachwyt, lecz reakcję skrajnie zapracowanej osoby, która od razu zainstalowała aplikację i została przy niej.
Jak stosować: Wewnętrzne narzędzia oddawaj jednemu–dwóm „próbnym” użytkownikom mającym mało czasu; ich samodzielna instalacja i dalsze użytkowanie to najsilniejszy sygnał wartości.
Na co uważać: Entuzjazm twórcy to słaby prognostyk — testuj na ludziach bez sentymentu do projektu.
8.Nie „najlepszy model”, tylko role jak dla współpracowników
Na czym polega: Autor traktuje porównania jak CV kandydatów: Fable do głębokiego myślenia i designu, Astra do szybkiej egzekucji, pisania i sterowania komputerem, tańsze modele (np. Luna) do prostej robocizny. Przestrzega przed nadmiernym opieraniem się na jednym narzędziu.
Jak stosować: Wypisz swoje powtarzalne zadania (teksty, arkusze, prezentacje, automatyzacja) i przypisz do nich modele według mocnych stron; co miesiąc–dwa weryfikuj przydziały.
Na co uważać: Dzisiejsze pewniki bywają jutro nieaktualne — jeszcze niedawno „do pisania bierzesz Claude’a” uchodziło za oczywistość, a autor dziś współpisze z Astrą.
9.Zanim postawisz na multi-agent, sprawdź jednego agenta
Na czym polega: Działającą aplikację z instalatorem zbudował jeden agent z promptu na pięć linijek — bez orkiestry. Systemy multiagentowe mają sens przy większych projektach, najlepiej w wariancie „otwartym”: wspólne repozytorium, tablica komunikatów, jasno określone role.
Jak stosować: Zacznij od pojedynczego agenta i drugiej rundy poprawek; dopiero przy rozbudowanych projektach uruchamiaj podział ról — np. jeden model koordynuje i projektuje, drugi kontroluje i deleguje wykonanie do tańszego modelu.
Na co uważać: System zamknięty, którego nie da się rozwijać w trakcie, szybko stanie się wąskim gardłem — autor stawia na otwarte punkty współpracy.
10.Zamawiaj od razu ścieżkę dystrybucji, nie tylko działający kod
Na czym polega: „Ostatnia mila” — plik DMG, podpis i weryfikacja Apple — przesądziła, że aplikację może zainstalować każdy posiadacz Maca bez ostrzeżeń systemowych. To zamieniło eksperyment w realnie udostępniane narzędzie.
Jak stosować: Jeśli narzędzie ma wyjść poza twój komputer, dołącz do briefu polecenie przygotowania instalatora i przejścia ścieżki podpisu oraz weryfikacji.
Na co uważać: Notaryzacja wymaga konta deweloperskiego Apple i odrobiny czasu — zaplanuj ją, zanim obiecasz komuś instalację.