O czym jest ten film
- Instalacja Codexa i podstawowe pojęcia: projekty, plik
AGENTS.md, modele, uprawnienia, umiejętności i zadania cykliczne. - Budowa własnego systemu wiedzy, który łączy trwałe informacje o firmie z danymi z codziennie używanych aplikacji.
- Projektowanie umiejętności, czyli zapisanych instrukcji do wykonywania powtarzalnych zadań.
- Tworzenie dokumentów, arkuszy i prezentacji zgodnych z identyfikacją wizualną oraz stylem firmy.
- Generowanie obrazów i wideo, projektowanie stron oraz sprawdzanie ich działania w przeglądarce.
- Montaż filmów z pomocą Codexa i Hyperframes: od transkrypcji po animacje i kontrolę gotowego materiału.
- Budowa automatyzacji działających w Codexie albo na zewnętrznym serwerze, z uwzględnieniem kosztów i sposobu testowania.
- Sterowanie kilkoma zadaniami głosem, także z telefonu.
- Porównanie Codexa z Claude Code na 15 zadaniach z codziennej pracy autora.
- Sprzedaż wdrożeń AI: rozpoznanie rzeczywistego problemu firmy, wybór miernika sukcesu, wycena i ustalenie zakresu projektu.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od jednego projektu i uporządkuj wiedzę
Na czym polega: Projekt Codexa jest powiązany z folderem na komputerze. Może zawierać opis firmy, cele, wcześniejsze materiały i instrukcje pracy. Dzięki temu przy kolejnym zadaniu nie trzeba opowiadać wszystkiego od początku.
Jak stosować: Utwórz folder dla jednego obszaru pracy. Zapisz w nim podstawowe informacje i dodaj AGENTS.md z krótką instrukcją, gdzie znaleźć poszczególne materiały.
Na co uważać: Samo zgromadzenie plików nie wystarczy. Jeśli informacje są nieaktualne albo agent nie wie, który dokument jest właściwy, może oprzeć odpowiedź na złym źródle.
2.Rozróżniaj wiedzę stałą od danych, które się zmieniają
Na czym polega: Autor dzieli swój system na informacje względnie trwałe, takie jak oferta i cele, oraz połączenia z kalendarzem, pocztą, zadaniami czy danymi klientów.
Jak stosować: Opisz firmę w plikach, a bieżące informacje pobieraj z aplikacji wtedy, gdy są potrzebne. Regularnie sprawdzaj, czy zapisane cele, liczby i opisy nadal są aktualne.
Na co uważać: Kopia danych z poczty lub CRM szybko się starzeje. Ważne decyzje opieraj na aktualnych zapisach i sprawdzaj, skąd agent wziął daną informację.
3.Buduj umiejętność na podstawie dobrego przykładu
Na czym polega: Umiejętność to instrukcja wielokrotnego użytku. Najłatwiej ją przygotować, gdy masz już raport, artykuł lub arkusz, który spełnia twoje wymagania.
Jak stosować: Pokaż agentowi gotowy materiał. Poproś, by ustalił, jakie dane, decyzje i kontrole doprowadziły do tego wyniku, a następnie zapisał procedurę dla jednego konkretnego zadania.
Na co uważać: Ogólna instrukcja w rodzaju „prowadź marketing” daje agentowi zbyt wiele swobody. Podziel pracę na mniejsze czynności i określ, kiedy używać każdej z nich.
4.Wpisz sprawdzanie wyniku w samą procedurę
Na czym polega: Agent może sprawdzić własną pracę przed oddaniem jej człowiekowi. Część warunków da się zmierzyć, a inne wymagają oceny, na przykład czy ilustracja rzeczywiście pomaga zrozumieć tekst.
Jak stosować: Przy każdej umiejętności zapisz warunki ukończenia zadania. Dla artykułu mogą to być poprawne źródła, odpowiednia liczba obrazów, kontrola prywatnych danych i obejrzenie gotowego układu strony.
Na co uważać: Raport agenta o przeprowadzonej kontroli nie zastępuje twojej oceny. W demonstracji autora tańszy model potrafił zaliczyć własne sprawdzenie, choć źle rozmieścił zdjęcia.
5.Dobieraj model do zadania, a nie do jego prestiżu
Na czym polega: W kursie najmocniejszy model lepiej radzi sobie z częścią złożonych zadań, lecz prostsze czynności da się wykonać taniej. Autor porównuje też poziomy wysiłku obliczeniowego.
Jak stosować: Najpierw osiągnij zadowalający wynik, potem uruchom tę samą procedurę na tańszym modelu i z niższym poziomem wysiłku. Porównaj jakość, czas i koszt na kilku różnych przykładach.
Na co uważać: Jeden udany przebieg nie dowodzi, że tańszy model zawsze wystarczy. Dotyczy to zwłaszcza zadań, w których trzeba ocenić obraz, obsłużyć przeglądarkę lub podjąć wiele decyzji.
6.Zachowaj firmowy styl w materiałach tworzonych przez AI
Na czym polega: Codex może korzystać z zapisanych logo, kolorów, krojów pisma, szablonów i zasad językowych przy tworzeniu dokumentów, arkuszy, prezentacji czy stron.
Jak stosować: Przygotuj folder z zatwierdzonymi plikami oraz krótki opis zasad. Dodaj przykłady dobrych materiałów i listę sformułowań, których firma nie używa. Odwołuj się do tych zasobów w umiejętnościach.
Na co uważać: Wygenerowany przez AI przewodnik po marce może dopisać kolory lub zasady, których nikt nie zatwierdził. Przejrzyj go, zanim stanie się podstawą kolejnych publikacji.
7.Automatyzuj najprostszym sposobem, który rozwiązuje problem
Na czym polega: Autor proponuje kolejność: API, prosty skrypt, a dopiero później agent obsługujący stronę przez przeglądarkę. Im więcej decyzji podejmuje model podczas działania, tym więcej trzeba sprawdzać.
Jak stosować: Rozrysuj czynności od wyzwalacza po rezultat. Stałe kroki zapisz w kodzie, a modelowi powierz tylko te momenty, które naprawdę wymagają interpretacji, na przykład streszczenie zgłoszenia.
Na co uważać: Obsługa strony przez klikanie może zawieść po zmianie jej wyglądu lub wygaśnięciu sesji. Przed uruchomieniem bez nadzoru wielokrotnie przetestuj szczególnie zadania dotyczące finansów i danych klientów.
8.Sprawdzaj wynik w narzędziu, z którego skorzysta odbiorca
Na czym polega: W przykładach agent otwiera stronę, wypełnia formularze, sprawdza wersję mobilną, ogląda film i poprawia błędy zauważone w gotowym materiale.
Jak stosować: Po zbudowaniu strony każ agentowi przejść przez typowe i nietypowe scenariusze. Przy filmie sprawdź obraz, napisy i synchronizację dźwięku. Zachowaj listę wykrytych usterek i uruchom kontrolę ponownie po poprawkach.
Na co uważać: Zaliczone testy automatyczne nie oznaczają, że materiał dobrze wygląda albo jest zrozumiały. Autor kilkakrotnie poprawiał rezultat po własnym obejrzeniu pierwszej wersji.
9.Przenoś stałe automatyzacje poza Codexa, gdy ma to sens
Na czym polega: Zadania cykliczne w Codexie zużywają limit usługi. Autor pokazuje, jak zbudować procedurę w Codexie, zapisać kod w GitHubie i uruchamiać go przez Trigger.dev.
Jak stosować: Dla porannego raportu określ godzinę, źródła danych, miejsce dostarczenia, koszt pojedynczego uruchomienia i warunki błędu. Najpierw wykonaj próbę lokalną, potem test na serwerze, a harmonogram włącz po sprawdzeniu dostarczenia wiadomości.
Na co uważać: Połączenia dodane jako wtyczki Codexa nie przenoszą się automatycznie do zewnętrznej usługi. Klucze i dane dostępowe trzeba tam skonfigurować osobno, bez umieszczania ich w repozytorium.
10.Sprzedawaj rozwiązanie mierzalnego problemu
Na czym polega: Autor opisuje projekt, w którym zbudował klientowi asystenta, lecz nie ustalił, jaki wynik biznesowy ma on poprawić. Klient uznał później, że nie dostał wartości, za którą zapłacił.
Jak stosować: Przed wyceną zapytaj, gdzie firma traci czas lub pieniądze. Ustal stan obecny, docelowy wynik i sposób pomiaru. W ofercie opisz konkretne etapy oraz to, co klient będzie mógł samodzielnie sprawdzić.
Na co uważać: Oszczędność czasu nie zawsze oznacza równą jej oszczędność pieniędzy. Nie obiecuj korzyści, których nie umiesz wykazać, i nie zostawiaj odbioru projektu przy niejasnym warunku „działa zgodnie z oczekiwaniami”.
Redakcyjne tłumaczenie
Od czego zaczynam
Chcę pokazać, jak przejść od pierwszego uruchomienia Codexa do budowania z jego pomocą rozwiązań, za które firmy są gotowe płacić. Sam nie piszę zawodowo kodu. Zanim zacząłem intensywnie korzystać z AI, zajmowałem się analizą biznesową i marketingiem. Prowadziłem później firmę doradczą zajmującą się automatyzacją, którą rozwinęliśmy do ponad 100 tysięcy dolarów miesięcznego przychodu, a następnie sprzedałem. Dziś używamy AI w kilku przedsięwzięciach.
Pokażę instalację, podstawowe pojęcia, budowanie własnego systemu wiedzy i umiejętności, przygotowanie materiałów zgodnych z marką, tworzenie obrazów, stron i filmów, obsługę przeglądarki oraz automatyzacje. Na koniec opowiem, jak rozmawiałem z klientami o takich wdrożeniach.
W demonstracjach korzystam przede wszystkim z aplikacji Codex na komputerze. Istnieją też rozszerzenie do edytora kodu i narzędzie uruchamiane z wiersza poleceń, ale interfejs aplikacji jest dla mnie najwygodniejszy. Po instalacji loguję się na konto OpenAI i wybieram projekt. Codex działa w ramach abonamentu z limitem użycia; przy dłuższej pracy trzeba obserwować, jak szybko ten limit ubywa. Opłaty za korzystanie z modeli przez API są rozliczane osobno. Przywoływane przeze mnie ceny i limity dotyczą chwili nagrania.
Nie trzeba znać składni języka programowania, żeby zacząć. Trzeba natomiast rozumieć, do jakich danych agent ma dostęp, jakie zadanie mu powierzamy i jak sprawdzić, czy wykonał je prawidłowo.
Osiemnaście pojęć, które ułatwiają pracę
Pierwszym jest projekt. Dla mnie to po prostu folder z plikami, z którym wiążę rozmowę w Codexie. W osobnych projektach trzymam różne przedsięwzięcia. Główny zawiera informacje o firmie, wcześniejszych materiałach, zadaniach i zasadach pracy. Gdy pytam, czym zajmowaliśmy się w ostatnim miesiącu, agent może sięgnąć do tych materiałów zamiast zgadywać.
Drugim pojęciem jest plik AGENTS.md. Rozszerzenie .md oznacza zwykły plik tekstowy z prostym formatowaniem. Zapisuję w nim zasady dotyczące projektu: po co powstał, jak ze mną pracować oraz gdzie szukać określonych informacji. W dużym zbiorze danych szczególnie przydaje się mapa: wiedza o firmie znajduje się tu, materiały kursowe tam, a przykłady mojego stylu pisania jeszcze gdzie indziej. Każdy projekt może mieć własne instrukcje.
Trzecim jest cykl pracy agenta. Codex nie ogranicza się do odpowiedzi na pytanie. Może przeczytać plik, użyć narzędzia, ocenić wynik, wykonać następny krok i dopiero wtedy odpowiedzieć. W aplikacji widać, jakich narzędzi używał. Warto czasem prześledzić te czynności: łatwiej zrozumieć, skąd wziął dane i dlaczego wynik jest taki, a nie inny. W przykładzie poprosiłem go o znalezienie zabawnych komentarzy pod moim najnowszym filmem; najpierw musiał ustalić, który film jest najnowszy, a potem pobrać komentarze.
Czwartym są cele, oznaczane w aplikacji poleceniem /goal. Można podać agentowi wynik, do którego ma dążyć, i pozwolić mu pracować przez kilka kolejnych prób. Im precyzyjniej określimy warunek ukończenia, tym łatwiej ocenić powodzenie. Prośba o przygotowanie 18 kart z pojęciami do filmu jest wyraźniejsza niż prośba o „naprawdę świetną oprawę”. Przy zadaniach wymagających oceny estetycznej agent nadal może się poprawiać, ale to człowiek musi obejrzeć efekt.
Piąta sprawa to różnica między pracą lokalną i w chmurze. Pliki na moim komputerze oraz strona dostępna pod adresem localhost pozostają na tym komputerze. Wysłanie komuś takiego adresu nie udostępni mu strony. Jeśli chcę pokazać wynik zespołowi, muszę go opublikować. Mogę też kontynuować rozmowę z lokalnym Codexem przez telefon, o ile mój komputer działa i połączenie zdalne jest dostępne.
Szóstym pojęciem jest worktree: oddzielna kopia robocza projektu. Przydaje się, kiedy chcemy przetestować zmianę w aplikacji bez ingerowania w główną wersję, nad którą pracują inni. Przy prostych zadaniach biurowych rzadko go używam.
Siódma sprawa to ustawienia Codexa. Część dotyczy konkretnego projektu, część całego konta użytkownika. Nie trzeba ich pamiętać na początku. Warto jednak wiedzieć, że istnieją różne poziomy ustawień, i zapytać agenta, gdzie powinna trafić dana reguła.
Ósme i dziewiąte pojęcie to model oraz poziom wysiłku. Mocniejsze modele i wyższy poziom wysiłku mogą lepiej radzić sobie z trudnym zadaniem, ale zużywają więcej zasobów. W filmie używam modeli Astra, Sol, Terra i Luna. Do prostego opisu filmu lub wiadomości nie potrzebuję zwykle najmocniejszego z nich. Tryb szybszej pracy również kosztuje więcej limitu. Dobór modelu traktuję więc jako decyzję zależną od zadania.
Dziesiąte są uprawnienia. Mogę pozwolić agentowi działać szeroko albo ustawić częstsze prośby o zatwierdzenie czynności. Osobie początkującej polecam najpierw obserwować, o co agent prosi i co faktycznie robi. Przy późniejszej pracy zakres dostępu można dostosować do rodzaju projektu.
Jedenaste pojęcie to umiejętność: zapisana procedura do ponownego wykorzystania. Jeśli raz przygotuję dobry opis filmu, artykuł na X lub raport, mogę opisać sposób pracy w pliku SKILL.md. Potem wystarczy poprosić o podobny rezultat. Jedna umiejętność może odwoływać się do innych oraz do plików ze stylem, szablonów i skryptów.
Dwunaste dotyczy folderu, w którym umiejętności są przechowywane. Mogą należeć do projektu albo być dostępne szerzej. W samym pliku podaję nazwę, opis sytuacji, w której należy go użyć, oraz instrukcje. Prosta umiejętność może mieć kilka zdań; bardziej złożona, na przykład przygotowanie artykułu ze zrzutami ekranu z filmu, wymaga wielu kroków.
Trzynaste to wtyczki. Pozwalają połączyć Codexa z innymi aplikacjami, takimi jak poczta, dysk, narzędzie do zarządzania zadaniami czy serwis z danymi. Często wystarczy się zalogować. Gdy nie ma odpowiedniej wtyczki, można rozważyć API lub obsługę przez przeglądarkę.
Czternaste to przeglądarka w aplikacji. Po zalogowaniu na stronie agent może wykonać w niej czynności: odczytać dane, przygotować szkic wpisu lub sprawdzić formularz. Piętnaste to publikowanie stron. Stronę zbudowaną lokalnie można udostępnić, wybrać, kto ma do niej dostęp, podłączyć domenę i — jeśli projekt tego wymaga — bazę danych.
Szesnaste pojęcie to agenci pomocniczy. Zamiast samodzielnie wykonywać całe rozległe badanie, główny agent może podzielić je na zadania: przejrzenie komentarzy, wyszukanie wiadomości, analiza dyskusji na X. Poszczególne zadania można powierzyć tańszym modelom, a główny agent zbiera wyniki.
Siedemnaste są zadania cykliczne. Codex może o określonej porze rozpocząć rozmowę i wykonać zapisane polecenie, korzystając z plików projektu i umiejętności. Osiemnaste to tryb głosowy. Mogę mówić do agenta, uruchamiać osobne wątki, zlecać zadania i sprawdzać ich postęp. Pokazuję to zarówno na komputerze, jak i na telefonie.
Własny system wiedzy: cztery elementy
Chcę, żeby Codex był miejscem, od którego zaczynam pracę, a nie tylko oknem do zadawania pojedynczych pytań. Zbudowałem więc system zawierający wiedzę o firmie, spotkaniach, filmach, projektach i sposobach działania. Własny pulpit łączy mi kalendarz, komunikację, zadania i sygnały od społeczności. To nie jest funkcja, którą każdy musi odtworzyć w tej samej postaci. Istotne jest to, że agent ma do czego sięgnąć, kiedy proszę o pomoc.
Porządkuję ten system według czterech elementów: kontekst, połączenia, możliwości i rytm pracy. Kontekst to informacje, które rzadko się zmieniają: czym zajmuje się firma, do kogo kieruje ofertę, jakie ma cele i jak chcę się komunikować. Połączenia dają dostęp do zmiennych danych z poczty, kalendarza, ClickUpa czy innych usług. Możliwości to procedury i narzędzia, z których agent potrafi skorzystać. Rytm pracy oznacza zadania uruchamiane regularnie.
Kolejność ma znaczenie. Automatyzacja pozbawiona wiedzy o firmie daje ogólny wynik. Dopiero gdy agent zna kontekst i umie pobrać aktualne dane, zapisane procedury stają się naprawdę przydatne. Proponuję trzy sprawdziany. Czy potrafi odpowiedzieć na pytanie członka zespołu i wskazać źródło? Czy dzięki niemu rzadziej przełączam się między aplikacjami? Czy mogę odnaleźć wcześniejszą decyzję bez polegania na pamięci?
Na początek prowadzę rozmowę, w której agent pyta o mnie, firmę, priorytety i styl pracy, a odpowiedzi zapisuje w plikach. Potem łączę najważniejsze aplikacje. Uruchamiam przegląd systemu: agent wskazuje luki, nieaktualne informacje i możliwe usprawnienia. Następnie pytam, co poprawić w pierwszej kolejności, wprowadzam zmianę i po pewnym czasie ponawiam przegląd.
Osobna procedura polega na dłuższym wywiadzie. Proszę agenta, żeby wypytał mnie o konkretny temat, na przykład cele na kwartał, zespół albo proces obsługi klienta, i zachował odpowiedzi. Z takich materiałów buduję firmową bazę wiedzy z powiązaniami między osobami, projektami, spotkaniami i decyzjami. Pokazuję też jej wizualną wersję. Widok grafu jest wygodny, ale wartością pozostają pliki i zawarte w nich informacje. Mogę ich użyć również w innym narzędziu.
Jak przygotowuję umiejętności
Stosuję sześć kroków. Najpierw pokazuję dobry wynik. Jeśli mam świetny raport tygodniowy, daję agentowi ten raport i proszę o ustalenie, skąd pochodzą dane, jak zostały policzone i co decyduje o układzie dokumentu. To skuteczniejsze niż polecenie „zrób mi raport” bez przykładu.
Potem wyznaczam jedno zadanie i warunek użycia procedury. Umiejętność „zamień film z YouTube na artykuł na X” jest łatwiejsza do zastosowania niż „prowadź komunikację firmy”. Szerszy proces można później złożyć z kilku umiejętności.
Dobieram zakres swobody. Przepisanie danych z arkusza do CRM powinno mieć ścisłe kroki i kontrole. Przy artykule na podstawie filmu agent musi zdecydować, które fragmenty są ważne, jakie obrazy wybrać i gdzie je umieścić. Zbyt sztywna instrukcja mogłaby tu pogorszyć wynik.
Dodaję sprawdzanie. Liczbę źródeł czy obrazów da się policzyć. Czytelność tekstu i sensowność kadru wymagają oceny. Agent może przejrzeć gotowy materiał w aplikacji, a osobny agent może sprawdzić jego fakty. Zapisuję też, co powinno trafić do raportu z kontroli.
Porównuję modele. Tę samą procedurę uruchamiam na kilku modelach, zaczynając od takiego, który daje dobry wynik. Sprawdzam, czy tańszy utrzymuje jakość, a potem eksperymentuję z poziomem wysiłku.
Po każdym użyciu poprawiam instrukcję. Jeśli zrzut ekranu został zrobiony w połowie animacji albo obrazy znalazły się jeden pod drugim bez związku z tekstem, wskazuję konkretne błędy i proszę o zmianę umiejętności. W ten sposób kolejny przebieg korzysta z wyciągniętych wniosków.
Pokazuję porównanie na procedurze zamieniającej mój film w artykuł na X. Agent musi pobrać film, przygotować tekst i miniaturę, wybrać kadry, sprawdzić prywatne dane, umieścić obrazy we właściwych miejscach i zapisać całość jako szkic. Tańszy model Luna poradził sobie z obrazami lepiej, niż się spodziewałem. Terra zamazała część wrażliwych szczegółów, ale wybrała też słabe kadry i źle je rozmieściła. Sol przygotował poprawną wersję, choć trwało to dłużej. Po wcześniejszych próbach najczęściej wybieram do tego zadania Astrę na niższym poziomie wysiłku. Jeden test nie wystarczyłby jednak, żeby uznać to za regułę dla każdego filmu.
Materiały, po których widać, od kogo pochodzą
Kiedy zespół tworzy z pomocą AI dokumenty, arkusze i prezentacje, łatwo o niespójność. Dlatego dodaję do projektu zatwierdzone logo, kolory, kroje pisma, przykładowe materiały i zasady użycia. Trzymam zarówno czytelny dla ludzi przewodnik po marce, jak i wersję tekstową, z której agent może pobrać nazwy fontów oraz kody kolorów.
Pokazuję to na materiałach dwóch marek. Z kilku plików z logo i opisu pożądanego wyglądu powstaje propozycja przewodnika po identyfikacji. Przeglądam ją, poprawiam i dopiero wtedy używam jako punktu odniesienia. Późniejsze umiejętności tworzą na tej podstawie przewodniki dla uczniów, wewnętrzne notatki, raporty w arkuszach i prezentacje. W arkuszu agent może dodać wykresy, oznaczyć zakładki kolorami i zastosować firmowy krój pisma.
Równie ważny jest język. Zapisuję, do kogo mówimy, jakie zwroty stosujemy i jakich sformułowań nie chcę widzieć. Dzięki temu umiejętność może tworzyć materiały zgodne nie tylko z kolorami marki, lecz także z jej sposobem pisania. Gdy z rezultatu jestem zadowolony, dopiero wtedy zamieniam sposób jego przygotowania w procedurę dla zespołu.
Lubię przechowywać gotowe dokumenty w miejscu, w którym współpracownicy mogą je od razu otworzyć i edytować, na przykład we wspólnym Dysku Google. Lokalny plik HTML także bywa użyteczny, ale przy codziennych poprawkach i współpracy żywy dokument jest wygodniejszy.
Obrazy, strony i inspiracje projektowe
Codex potrafi generować obrazy. Jeśli potrzebuję skorzystać z innego modelu graficznego lub modelu wideo, pokazuję połączenie z zewnętrzną usługą przez API. W demonstracji tworzę klucz do usługi Higgsfield, zapisuję go w pliku środowiskowym i proszę Codexa o sprawdzenie dostępnych modeli oraz wykonanie próbnego zlecenia. Klucza nie wklejam do rozmowy. Przy takim sposobie pracy płaci się za użycie usługi zgodnie z jej zasadami, a nie za samą obecność połączenia w projekcie.
Przy projektowaniu stron sam opis „zrób nowoczesną witrynę” rzadko wystarcza. Podaję informacje o marce, odbiorcy, jego potrzebie i obietnicy składanej przez stronę. Dokładam przykłady witryn lub poszczególnych elementów, które mi się podobają. Na stronach takich jak Godly, 21st.dev czy Awwwards szukam rozwiązań odpowiadających danemu typowi działalności.
W swoich przykładach używam także umiejętności, która opisuje zasady układu, typografii, odstępów, warstw i animacji przy przewijaniu. Nie chodzi o to, by każda strona miała ten sam efekt. Serwis dla kancelarii, sklep z produktem i strona społeczności wymagają różnych decyzji. Po wygenerowaniu witryny przewijam ją, oglądam poszczególne sekcje i wskazuję poprawki.
Przeglądarka, testy i obsługa komputera
Przeglądarkę wykorzystuję na dwa sposoby. Pierwszy to testowanie. Przy prostym formularzu wskazuję elementy nachodzące na siebie i proszę o poprawki. Następnie każę agentowi wypełniać formularz różnymi danymi, próbować przejść dalej bez pól obowiązkowych, korzystać z klawiatury, wracać do poprzedniego kroku i sprawdzić widok mobilny. W demonstracji znalazł błędy dotyczące danych kontaktowych, resetowania kodu kraju oraz układu na telefonie.
Drugi sposób to wykonanie czynności w serwisie, z którym nie mam wygodnego połączenia przez API. Pokazuję pobieranie wyciągów z konta w Relay i zapisanie ich we wskazanym folderze. Ponieważ serwis finansowy może zakończyć sesję, agent czasem zatrzymuje się przy ekranie logowania. Dane do logowania przechowuję w menedżerze haseł przeglądarki, a nie w historii rozmowy. Przy takiej procedurze obserwowałbym wiele kolejnych przebiegów, zanim pozwoliłbym jej działać samodzielnie.
Moja kolejność wyboru narzędzia jest prosta. Najpierw sprawdzam API: zwykle jest szybkie i przewidywalne. Jeśli czynności na stronie zawsze przebiegają identycznie, rozważam zwykły skrypt. Agenta, który patrzy na ekran i decyduje, gdzie kliknąć, używam wtedy, gdy musi rozpoznać zmieniającą się sytuację. Bywa też, że wybieram przeglądarkę dlatego, że API danej usługi gorzej radzi sobie z formatowaniem albo generuje dodatkowy koszt. Tak jest w pokazanym przeze mnie przygotowaniu szkicu artykułu na X.
Osobno pokazuję sterowanie aplikacją na komputerze. Agent otwiera wskazany program i zmienia jego ustawienie. W tym przypadku początkowo ostrożnie interpretuje prośbę dotyczącą Bluetooth jako możliwą zmianę uprawnień systemowych; później rozpoznaje, że chodzi o ustawienie wewnątrz aplikacji. To dobry przykład, dlaczego trzeba obserwować działanie narzędzia, zwłaszcza gdy ma dostęp do pulpitu.
Montaż filmu z Codexem i Hyperframes
Do filmów korzystam z Hyperframes, które pozwala przygotować sceny i animacje, a potem złożyć je w materiał wideo. Codex pomaga mi przejść przez cały proces: transkrybuje nagranie, usuwa pomyłki i ciszę, planuje sceny, przygotowuje grafikę, dobiera materiały dodatkowe oraz sprawdza efekt.
W jednym przykładzie przekazuję nagranie twarzy i ekranu. Materiał trwający około 14 minut zostaje skrócony do dziewięciu. Montaż przełącza między widokiem prowadzącego a ekranem wtedy, gdy wymaga tego treść, i dodaje plansze zapowiadające kolejne pojęcia. W krótkich filmach agent przygotowuje napisy, przejścia, muzykę, efekty dźwiękowe i przebitki. Część materiałów wyszukuje, część tworzy.
Pokazuję też szczegółowe polecenie dotyczące krótkiego wstępu. Najpierw proszę o transkrypcję, ponieważ obrazy i napisy muszą pojawiać się we właściwym momencie. Potem opisuję kolejno, co ma się wydarzyć przy konkretnych zdaniach: animowane elementy po jednej i drugiej stronie kadru, napisy u dołu, zmiana wielkości obrazu prowadzącego oraz fragmenty starszych filmów pokazane jako przestrzenne karty. Na końcu proszę o obejrzenie wyniku i sprawdzenie synchronizacji.
Pierwsza wersja powstaje po około 18 minutach i skraca oryginalną minutę do 28 sekund. Podoba mi się ogólny kierunek, lecz zauważam słabsze pierwsze sekundy, zbyt mały napis i karty filmów, które nieprzekonująco przenikają przez siebie. W drugim poleceniu opisuję te konkretne problemy. Kolejna wersja jest lepsza. Sprawdzam też inny pomysł na sam początek filmu. Tak powstają moje umiejętności montażowe: od szczegółowo opisanego zadania, przez własną ocenę, po procedurę, którą można uruchamiać ponownie.
W innym przykładzie daję agentowi ponad 150 GB nagrań z wydarzenia i proszę o minutową relację. Jestem pod wrażeniem tego, jak wybiera wypowiedzi i buduje z nich opowieść, ale znajduję też błędną domenę w gotowym filmie. Szybkie przygotowanie materiału nie zwalnia więc z obejrzenia go przed publikacją.
Trzy sposoby uruchamiania automatyzacji
Zadanie cykliczne w Codexie jest wygodne, bo ma dostęp do kontekstu projektu i zapisanych umiejętności. Każde uruchomienie zużywa jednak limit. Jeśli proces jest stały i ma działać niezależnie od mojego komputera, buduję go w Codexie, a wykonanie przenoszę do Trigger.dev. Kod trzymam w GitHubie, żeby mieć historię zmian. Klucze i inne wrażliwe dane pozostają poza repozytorium.
Pierwszy przykład to automatyzacja według harmonogramu. W dni robocze o szóstej rano ma odczytać mój kalendarz, rozpoznać spotkania wymagające przygotowania, w razie potrzeby zrobić krótkie badanie w publicznych źródłach, napisać podsumowanie dnia i wysłać je do mnie przez ClickUp. Podczas planowania ustalamy godzinę, strefę czasową, kalendarz, miejsce dostarczenia wiadomości i górny limit kosztu jednego uruchomienia. Agent zwraca uwagę, że darmowy plan usługi może nie gwarantować wykonania dokładnie o szóstej.
Większość kroków tej procedury jest stała: uruchomienie, odczyt kalendarza, wysłanie wiadomości. Model jest potrzebny przy ocenie, czy spotkanie wymaga przygotowania, i przy napisaniu krótkiej notatki. Najpierw testuję wszystko lokalnie. Potem sprawdzam uruchomienie na serwerze i wiadomość w ClickUpie. Dopiero po takim teście włączam harmonogram. W demonstracji pojedyncza próba kosztuje około 1,33 centa, choć jest to koszt konkretnego przebiegu, a nie gwarancja dla przyszłych uruchomień.
Drugi przykład wyzwala zdarzenie: wypełnienie formularza. Dane trafiają do ClickUpa. Samo przekazanie pól formularza nie potrzebowałoby AI. Model dopisuje dopiero proponowaną odpowiedź i szkic wiadomości. Przed wdrożeniem warto sprawdzić między innymi poprawność adresu e-mail oraz zachowanie formularza przy wielu zgłoszeniach.
Trzeci przykład korzysta z SDK Codexa, gdy przebieg nie daje się z góry rozpisać w kilku stałych krokach. Agent może wielokrotnie wracać do notatek, badać nowe informacje i zmieniać wniosek. Pokazuję to na przeniesieniu własnej procedury analizującej rynek. Powstały osobne zadania do sprawdzenia konfiguracji, wykonania próbnego przebiegu i regularnego uruchamiania właściwego agenta. To bardziej złożone i droższe rozwiązanie. Stosowałbym je wtedy, gdy rzeczywiście potrzebuję takiej swobody działania oraz uruchamiania procesu poza abonamentem Codexa.
Sterowanie głosem i współpraca kilku wątków
W demonstracji głosowej zlecam równocześnie przygotowanie artykułu na X, dopasowanie miniatury, zbudowanie strony opisującej program kursowy i dodanie widoku spotkań do mojego pulpitu. W trakcie rozmowy doprecyzowuję, że zadania mają działać w projekcie zawierającym wiedzę o mojej firmie. Pierwsze wątki powstały poza nim, więc proszę o ich przeniesienie do właściwego kontekstu. To ważna poprawka: nawet sprawny agent bez dostępu do odpowiednich materiałów może przygotować wynik oderwany od marki.
Wątki przekazują sobie informacje. Zadanie odpowiedzialne za artykuł dostaje zaakceptowaną miniaturę; gotowy tekst zawiera kadry dobrane z filmu. Strona programu odwołuje się do rzeczywistych kursów i wyglądu istniejącej witryny. Widok spotkań łączy dane kalendarza z zapisami w Fireflies. Te same rozmowy mogę śledzić z telefonu. Głos ułatwia wydawanie poleceń w biegu, lecz nadal wracam do ekranu, żeby sprawdzić gotowe materiały.
Codex i Claude Code w 15 próbach
Używam obu narzędzi i chciałem porównać je na zadaniach, które sam wykonuję. W filmie zestawiam model Astra używany w Codexie z modelem Fable 5.1 używanym w Claude Code. To jednocześnie porównanie modeli i środowisk, więc wyniku nie należy traktować jak niezależnego testu samych modeli. Oceniałem pierwszą otrzymaną wersję, czas i oszacowany koszt użycia.
Fable bardziej spodobał mi się przy prezentacji dla firmy doradczej: materiał wyglądał profesjonalnie, choć Astra wykonała zadanie szybciej i taniej. Wybrałem też Fable przy tekście strony sprzedażowej, ponieważ pełniej odpowiadał na pytania potencjalnego klienta. Astra wypadła lepiej przy analizie danych podatkowych: zadała wcześniej pytania i przygotowała bardziej dopasowany arkusz. To był materiał do dalszego sprawdzenia, nie zastępstwo dla specjalisty.
W przeglądzie subskrypcji na podstawie poczty Astra dostarczyła pełniejszy arkusz; jedna zakładka wersji Fable pozostała pusta. Przy analizie spotkań kierownictwa oba modele wskazały podobny pomysł na proces obsługi uczestników programu, ale bardziej użyteczne uznałem rozpoznanie problemów przez Astrę. Przy filmowej relacji z wydarzenia obie wersje miały mocne strony i błędy, z niewielką przewagą Astry. W animowanym filmie promocyjnym Astra lepiej wykorzystała prawdziwe obrazy kursów.
W prostej grze, aplikacji do oceniania automatyzacji oraz zadaniu rysowania w Canvie przez przeglądarkę wybrałem Astrę. Przy wizualizacji mojej bazy wiedzy bardziej odpowiadała mi wersja Fable. Fable przygotował też bardziej szczegółowy wizualny przewodnik po filmie, choć Astra zrobiła czytelniejszy układ. Astra lepiej poradziła sobie z wprowadzeniem kursu do społeczności przez przeglądarkę: zapisała materiały wraz z filmami, których Fable nie zdołał dodać.
Przy odtworzeniu stylu wskazanej strony internetowej bliżej przykładu znalazł się Fable, choć w obu wersjach zauważyłem usterki. W ostatnim zadaniu, rocznym przeglądzie kanału YouTube i planie na kolejne miesiące, bardziej czytelny i obrazowy wydał mi się raport Astry.
W mojej punktacji Astra wygrała 10 z 15 prób. Łączny szacowany koszt wyniósł około 327 dolarów, wobec 513 dolarów dla Fable. Łączny czas Astry był jednak dłuższy: około 11 godzin i 19 minut wobec 9 godzin i 36 minut. To opis tych konkretnych uruchomień. Przy innym zadaniu, innych instrukcjach albo po poprawieniu pierwszej wersji wynik mógłby być inny. Dlatego zachowuję dostęp do kilku narzędzi i wybieram je według własnych prób.
Sprzedaż wdrożeń: najpierw rozpoznaj problem
Pierwszy duży błąd popełniłem, gdy klient poprosił mnie o osobistego asystenta AI. Zbudowałem go, ale klient powiedział później, że nie otrzymuje wartości, za którą zapłacił. Dziś widzę trzy powody: rozwiązanie nie usuwało głównej przeszkody w jego firmie, nie ustaliliśmy miernika sukcesu i zgadywałem cenę.
Na spotkaniu z klientem nie chcę być jedynie osobą przyjmującą zamówienie na „agenta”. Chcę ustalić, co naprawdę hamuje firmę. Ktoś może prosić o więcej potencjalnych klientów, ponieważ widział efektowną demonstrację. Właścicielka gabinetu, z którą rozmawiałem, też chciała narzędzia do pozyskiwania kontaktów. Po rozmowie okazało się, że zgłoszeń ma dużo. Problemem były nieobecności na umówionych wizytach oraz brak kontaktu po wizycie. Więcej zgłoszeń nie naprawiłoby tych strat. Bardziej potrzebne były przypomnienia i procedura ponownego kontaktu.
Pytam więc firmę, co zepsułoby się jako pierwsze, gdyby jutro liczba zamówień wzrosła dziesięciokrotnie. Jeśli zamówień jest za mało, pytam, co musiałoby się wydarzyć, by było ich znacznie więcej. Słucham odpowiedzi i dopytuję. Czasem najlepszym rozwiązaniem jest prosty skrypt, zmiana procesu albo zatrudnienie ludzi. Znajomość AI pomaga również rozpoznać sytuację, w której nie trzeba jej używać.
Jeden miernik, który obie strony rozumieją
Przed przyjęciem zapłaty chcę wraz z klientem wybrać liczbę, którą projekt ma poprawić. Może to być liczba umówionych spotkań, odsetek osób przychodzących na wizytę, czas przygotowania oferty albo liczba błędów w harmonogramie. Zapisujemy stan obecny, cel i sposób pomiaru.
Wspomniany klient czuł, że ma za dużo pracy. Później zrozumiałem, że wiele czasu poświęcał na ręczne pisanie ofert. Gdybyśmy skupili się na przygotowaniu szkicu oferty, który człowiek sprawdza i zatwierdza, łatwiej byłoby wykazać oszczędność czasu. Samo stwierdzenie, że asystent ma sprawić, by właściciel „czuł się mniej zajęty”, nie dawało nam takiej możliwości.
Nie każdy rezultat sprowadza się do liczby godzin. Prosta automatyzacja przepisująca telefoniczne zamówienia ekipy budowlanej do używanego przez nią formatu oszczędzała około 45 minut dziennie, lecz większe znaczenie miało ograniczenie błędów w planowaniu. Według przedstawionego przykładu kosztowały one firmę około 12 tysięcy dolarów miesięcznie. Warto więc pytać nie tylko o czas wykonania czynności, ale także o skutki pomyłki.
Jak dochodzę do ceny i zakresu
Rozliczenie godzinowe może pomóc zdobyć pierwsze zlecenia, gdy nie mam jeszcze przykładów własnych wdrożeń. Nie chcę jednak na nim opierać całej firmy. Jeśli dzięki doświadczeniu i narzędziom wykonuję tę samą pracę szybciej, stawka godzinowa zmniejsza moje wynagrodzenie za lepszą sprawność.
Rozdzielam koszt wykonania, wartość dla klienta i cenę. Koszt wyznacza dolną granicę, poniżej której projekt przestaje mi się opłacać. Wartość dla firmy pomaga zrozumieć górną granicę. Cenę ustalam między nimi, biorąc pod uwagę zakres i ryzyko. W rozmowie pytam, ile czasu zajmuje proces, ile osób go obsługuje, jak często występuje i co dzieje się po błędzie. Jeśli nie potrafię oszacować wartości, potrzebuję więcej danych przed wysłaniem oferty.
Na spotkaniu sprawdzam też trzy rzeczy: dlaczego klient chce właśnie tego rozwiązania, dlaczego potrzebuje go teraz i dlaczego rozważa współpracę ze mną zamiast wykonania pracy wewnątrz firmy. Ostatnie pytanie pozwala usłyszeć wątpliwości, które i tak pojawiłyby się później. Jeśli oferta musi powstać bez rozmowy, zapisuję jawnie założenia dotyczące liczby zgłoszeń czy użytkowników i proponuję ich doprecyzowanie.
W przedstawionym sposobie wyceny punktem wyjścia bywa dla mnie 10–20 procent oszacowanej wartości dla klienta w pierwszym roku. To moja praktyka, nie uniwersalny cennik. Często przedstawiam kilka wariantów o różnym zakresie. Na początku oferty opisuję sytuację firmy jej własnymi liczbami, wynik, do którego chce dojść, oraz plan pracy. Dopiero potem pokazuję cenę.
Projekt dzielę na etapy, które można sprawdzić. „Agent działa zgodnie z oczekiwaniami” to zbyt niejasny warunek odbioru. Lepszy jest opis działania, które klient może sam wykonać i zmierzyć: zadaje pytanie, system pobiera dane z ustalonej bazy i odpowiada w wyznaczonym czasie. Nowe pomysły, które pojawiają się w trakcie, zapisuję do rozważenia w kolejnej wersji. Jeśli cena przekracza budżet, proponuję mniejszy zakres pierwszego etapu.
Koszty działania po wdrożeniu — API, hosting i inne usługi — zwykle umieszczam na koncie klienta. W ofercie podaję ich szacunek oraz założoną liczbę uruchomień. Własne koszty prób i testowania uwzględniam natomiast w cenie przygotowania rozwiązania; po uruchomieniu produkcyjnym przechodzimy na konta klienta. Przy bardziej samodzielnym agencie przeznaczam na testy więcej czasu i pieniędzy.
Najważniejszą lekcją z pracy z klientami jest dla mnie rozmowa o wyniku przed rozmową o narzędziu i cenie. Gdy obie strony potrafią nazwać problem, jego koszt oraz zmianę, którą chcą zobaczyć, łatwiej zaprojektować właściwe rozwiązanie i później uczciwie ocenić, czy zadziałało.