O czym jest ten film
- Jev to niedawno udostępniony model nowego rodzaju — tzw. model „systemu 1” — który zamiast generować tekst, wyspecjalizował się w podejmowaniu decyzji.
- Na wejściu dostaje „stan” (opis sytuacji) i zestaw pytań zamkniętych; na wszystkie odpowiada równolegle, każdorazowo podając prawdopodobieństwo będące miarą własnej pewności.
- W zadaniach decyzyjnych Jev jest 20–200 razy szybszy i 40–1000 razy tańszy od dużych modeli językowych — a przy tym dokładniejszy.
- Pierwsze zastosowanie: hak uruchamiany przed każdym wywołaniem narzędzia przez agenta, który blokuje destrukcyjne akcje — czytanie pliku .env, kasowanie katalogów, eksfiltrację danych.
- W odsłonie z Jevem zabezpieczenie łączy trafność z szybkością (ćwierć sekundy na analizę) i kosztem na poziomie ułamka centa — lepiej niż wyrażenia regularne (fałszywe alarmy) i niż LLM (drogo i wolno).
- Drugie zastosowanie: testowanie gier w czasie rzeczywistym — Jev „gra” z prędkością 30–60 klatek na sekundę i wyłapuje błędy, których LLM nie znajdzie, bo nie umie grać.
- Trzecie: automatyczne testy stron internetowych — powstają open-source’owe narzędzia sterowane Jevem; model językowy zostaje tylko do generowania wpisywanego tekstu.
- Czwarte: klasyfikacja zadań na starcie przepływu — Jev rozstrzyga, czy zgłoszenie na GitHubie to błąd czy funkcja, i dobiera poziom modelu do trudności zadania.
- Kluczowy wzorzec: Jev nie pracuje sam — najlepiej sprawdza się „zapięty” pomiędzy wywołaniami LLM, który przygotowuje wejście i działa na jego decyzjach.
- Autor testował te układy na własnych narzędziach (przepływy w Arkonie, aplikacja DynaChat); trafność klasyfikacji ocenił sam: 12/12 w jednym workflow i 15/16 w przeglądzie pull requestów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Tam, gdzie LLM zwraca tylko wybór z listy, wstaw model decyzyjny
Na czym polega: LLM-y są przepłacone za proste rozstrzygnięcia — drogi, wolny model generatywny odpowiada na pytanie typu „tak/nie” albo „która z pięciu opcji”. Jev robi to samo 20–200 razy szybciej i 40–1000 razy taniej.
Jak stosować: Przejrzyj własne agenty i przepływy, znajdź kroki czysto decyzyjne (routing, klasyfikacja, dopuść/zablokuj) i przenieś je na endpoint decyzyjny — autor odpytuje Jeva przez OpenRouter.
Na co uważać: Jev nie generuje tekstu. Tam, gdzie odpowiedź musi być sformułowaniem, LLM pozostaje niezbędny.
2.Projektuj wejście jako „stan + pytania zamknięte”
Na czym polega: Cały interfejs Jeva to opis sytuacji oraz lista pytań z gotowymi opcjami odpowiedzi — każda odpowiedź przychodzi z prawdopodobieństwem, pełniącym rolę miary pewności.
Jak stosować: Zamieniaj wymogi bezpieczeństwa lub logiki biznesowej („czy to groźne?”, „jakiego modelu to wymaga?”) na precyzyjne pytania zamknięte; progi prawdopodobieństwa traktuj jak czułość regulowaną pod siebie.
Na co uważać: Jakość decyzji zależy od kompletności stanu. Jeśli zabraknie kluczowego kontekstu — np. argumentów wywołania narzędzia — model będzie zgadywał.
3.Zbuduj strażnika bezpieczeństwa na haku „przed użyciem narzędzia”
Na czym polega: Haki (wprowadzone w Claude Code, dziś obecne w praktycznie każdym agencie kodującym) pozwalają uruchomić automatyzację tuż przed każdą akcją agenta. Jev ocenia w ułamku sekundy, czy akcja zdradza sekrety, niszczy dane albo eksfiltruje informacje — i blokuje ją kodem błędu.
Jak stosować: Jako stan przekaż nazwę narzędzia, jego argumenty, efekt i bieżący katalog roboczy; po decyzji „blok” agent musi wybrać inną drogę — np. sięgnąć po .env.example zamiast .env.
Na co uważać: Globalne reguły i skille nie wystarczą — przy przeładowanym kontekście agent i tak znajdzie obejście. Z kolei lista wyrażeń regularnych generuje fałszywe alarmy i zawsze ma luki.
4.Wykorzystaj „model jako sędzia” także do pilnowania zgodności z zadaniem
Na czym polega: Hak uruchamiany przed narzędziem może oceniać nie tylko bezpieczeństwo, ale też to, czy agent nie schodzi z wyznaczonego toru — autor dorzuca takie pytanie do każdej analizy.
Jak stosować: Dopisz do zestawu pytań kontrolę celu, np. „czy ta akcja służy realizacji bieżącego zadania?” — dostaniesz tanią, ciągłą kontrolę jakości pracy agenta bez angażowania LLM-a.
Na co uważać: Zbyt ciasne progi potrafią blokować akcje nieoczywiste, ale poprawne. Przetestuj na własnych sesjach, zanim wdrożysz na stałe.
5.Powierz Jevowi testy wymagające refleksu — na przykład granie w gry
Na czym polega: Przy 30–60 klatkach na sekundę LLM zdąży przeanalizować scenę dopiero wtedy, gdy scena już przepadła. Jev nadąża i realnie „gra” jak użytkownik, znajdując błędy, których testy jednostkowe nie zobaczą.
Jak stosować: Niech LLM z góry zbuduje szkielet testowy: tłumaczenie stanu gry na wejście Jeva oraz listę możliwych ruchów. Potem Jev gra, a LLM pracuje nad znalezionymi błędami.
Na co uważać: Stare podejście — spowolnienie gry, by LLM grał klatka po klatce — działa, ale bywa zaporowo drogie i powolne. Bez dobrej reprezentacji stanu Jev też nic nie wykryje.
6.Trzymaj się schematu: LLM przygotowuje, Jev decyduje, LLM działa
Na czym polega: Jev nie potrafi sam wymyślić pytań, zbudować stanu ani zareagować na własną decyzję. Jego mocą jest samo rozstrzyganie — więc najlepiej wygląda w roli ogniwa między dwoma wywołaniami modelu językowego.
Jak stosować: W każdym przepływie rozdziel etapy: przygotowanie danych i opcji (LLM), decyzja (Jev), wykonanie i analiza wyników (LLM). Tak działa bezpieczeństwo i testy gier u autora.
Na co uważać: Jev nigdy nie jest finałem przepływu — nie buduj z niego samodzielnego agenta.
7.Przenieś testy przeglądarkowe na Jeva
Na czym polega: Strony, w odróżnieniu od gier, rzadko wymagają reakcji natychmiast, więc LLM-y dawały radę — ale wolno i drogo. Jev wychodzi pewniejszy, a open source oferuje już gotowe narzędzia tego typu.
Jak stosować: Krok po kroku zamieniaj decyzyjne akcje agenta (na czym skupić uwagę, który przycisk kliknąć) na rozstrzygnięcia Jeva; tekst wpisywany w pola niech LLM generuje z góry.
Na co uważać: Formularze wymagające swobodnego tekstu wciąż potrzebują modelu językowego — nie da się zamienić wszystkiego.
8.Klasyfikuj zadania na wejściu, zanim uruchomisz drogi model
Na czym polega: Na starcie przepływu Jev rozstrzyga typ pracy (błąd czy funkcja — to przesądza o dalszych krokach i skillach) oraz poziom modelu: szybki, standardowy czy mocny. W testach autora 12 na 12 decyzji było trafnych.
Jak stosować: Opisz kilka pytań zamkniętych o charakter i trudność zadania; wynik kieruje routingiem, a ty oszczędzasz tokeny, bo proste sprawy nie trafiają do najdroższych modeli.
Na co uważać: Pomyłka na wejściu wysyła całe zadanie złym torem. Zostaw sobie ścieżkę ręcznego nadpisania decyzji i zerkaj na rozkład prawdopodobieństw.
9.Licz koszt na tysiące wywołań, nie na jedno
Na czym polega: Pojedyncza analiza LLM-em wygląda na groszową (ok. 0,1 centa na Haiku), ale przy tysiącach wywołań dziennie robią się z tego setki dolarów miesięcznie. Przegląd pull requesta LLM-em kosztował autora 32 centy — Jevem ułamek centa.
Jak stosować: Pomnóż koszt pojedynczej decyzji przez realny wolumen (liczba wywołań narzędzi, PR-ów, zgłoszeń) — dopiero to pokazuje, gdzie wymiana modelu ma sens finansowy.
Na co uważać: Przy dzisiejszych limitach API oszczędność to nie tylko pieniądze, ale i przepustowość — mniej wywołań LLM to mniej zderzeń z limitem.
10.Porównuj warianty na własnych danych i sam bądź sędzią
Na czym polega: Autor zestawił trzy wersje zabezpieczenia (wyrażenia regularne, LLM, Jev), mierząc blokady, fałszywe alarmy, czas i koszt — a decyzje ocenił ręcznie. Uczciwie zaznacza, że Jeva używa dopiero od niedawna i wyniki są wstępne.
Jak stosować: Przed wdrożeniem zrób mini-benchmark: te same wejścia, kilka podejść, policz czas, koszt, trafność i fałszywe trafienia. Wskaźniki trzymaj w logach.
Na co uważać: „Ryzykowna akcja” to pojęcie względne — najpierw zdefiniuj kryteria oceny, bo bez nich porównanie nic nie powie.
Redakcyjne tłumaczenie
Jev, czyli model, który decyduje zamiast pisać
Jev robi furorę. Pojawił się niedawno i już spopularyzował cały nowy rodzaj modeli — tzw. modele „systemu 1”, wyspecjalizowane w podejmowaniu decyzji, a nie w generowaniu tekstu. To zupełnie inna bajka niż duże modele językowe, takie jak Claude czy GPT, a w sieci co rusz ktoś podsuwa kolejny pomysł na wykorzystanie tego podejścia.
(Informacja dodatkowa: nazwa „system 1” nawiązuje do Daniela Kahnemana, który myślenie dzielił na szybkie i intuicyjne — system 1 — oraz powolne i analityczne — system 2.)
Jest tylko jedno „ale”: większość tych pomysłów — taką opinię słyszę często, zwłaszcza od członków mojej społeczności Dynamis — robi wrażenie, ale mało która z nich nasuwa myśl „muszę to dziś wdrożyć do własnych przepływów”. Dlatego w tym filmie pokazuję konkretnie dla kodowania z AI cztery zastosowania Jeva, które przyspieszają pracę i oszczędzają tokeny — a to ostatnio sprawa pierwszej ważności, zważywszy na to, jak ciasne stały się limity zapytań.
Jeśli śledzisz nowinki z AI, Jev jest ci pewnie znany — być może nawet go przetestowałeś. To nie pierwszy model decyzyjny tego typu, ale to temat na osobny materiał. Sedno jest takie: Jev jest naprawdę mocny.
Jak działa Jev
Podajesz mu opis sytuacji — u modeli „systemu 1” nazywa się to stanem (ang. state) — wraz z listą pytań zamkniętych, z gotowymi opcjami odpowiedzi. Na każde z nich model odpowiada równolegle, podając prawdopodobieństwo, które jest de facto miarą jego pewności.
Teoretycznie to samo można osiągnąć z LLM-em, zwłaszcza przez wyjścia strukturalne — decyzje, na których opiera się dalsza część przepływu. Ale Jev robi to 20–200 razy szybciej i 40–1000 razy taniej. Rozpiętość bierze się stąd, że porównywać można z różnymi modelami językowymi — lecz niezależnie od punktu odniesienia, przy decyzjach Jev wychodzi dokładniejszy, szybszy i tańszy.
Jeśli potraktować Jeva jako decydenta, lista zastosowań nie ma końca. Dlatego zamiast ogólników pokażę cztery konkretne pomysły. Każdy z nich zasługuje na osobny film; dziś trzymam się poziomu przeglądu, krótko i na temat, żeby każdy mógł wybrać coś dla siebie i ewentualnie zbudować samodzielnie. W piątek poprowadzę w społeczności Dynamis warsztat, w którym wejdziemy w te tematy znacznie głębiej. Do Jeva wrócę jeszcze niejeden raz — to pierwszy od dłuższego czasu model, który autentycznie mnie cieszy, i myślę, że przy tych czterech przypadkach zrozumiesz dlaczego.
Zastosowanie 1: strażnik bezpieczeństwa agenta
Mój obecny faworyt. Asystenci AI są zdecydowanie zbyt skorzy do rzeczy, których robić nie powinni: wczytania zmiennych środowiskowych czy skasowania całego katalogu. I nawet gdy w globalnych regułach albo skillach wyraźnie tego zakazujemy, agent — zwłaszcza gdy kontekst rozmowy mocno spuchnie albo prompt podsunie mu obejście — znajdzie sposób, żeby to jednak zrobić. Stąd potrzeba barier bezpieczeństwa, które powstrzymają agenta przed akcjami destrukcyjnymi. I tu wchodzi Jev.
Najpopularniejszy i najskuteczniejszy sposób stawiania takich barier to haki (ang. hooks), wprowadzone w Claude Code, a dziś obecne praktycznie w każdym agencie kodującym. Hak to automatyzacja podpięta do zdarzenia w cyklu życia agenta, a najważniejsze ze zdarzeń to „przed użyciem narzędzia” (pre-tool use): tuż zanim agent odczyta plik albo uruchomi komendę, nasz skrypt analizuje tę akcję i albo ją blokuje, albo przepuszcza.
Klasyczny przykład: hak sprawdzający, czy agent zamierza odczytać plik .env. O sekretach w kontekście rozmowy mowy być nie powinno. Jeśli hak wykryje zagrożenie, zwraca kod błędu, akcja zostaje zablokowana, a agent musi wybrać inną drogę — na przykład sięgnąć po .env.example.
Do czasu pojawienia się Jeva mieliśmy dwie opcje: LLM analizujący każde wywołanie (drogo) albo proces deterministyczny na wyrażeniach regularnych (niedokładnie). Opcję z LLM-em od razu odrzućmy: skoro analizujemy każdą akcję agenta, sam strażnik kosztowałby nas setki, a nawet tysiące dolarów miesięcy — żeby blokować wywołania, które zdarzają się raz na jakiś czas. Ja sam, dopóki nie było Jeva, używałem wyrażeń regularnych: hak łapał dopasowania wzorców dla czytania moich poświadczeń Google, pliku .env, kasowania katalogów i tak dalej. Problem w tym, że destrukcyjną akcję da się wykonać na milion sposobów: wczytać plik bezpośrednio, napisać skrypt w Pythonie, użyć basha… Lista wzorców robi się ogromna i tak nie łapie wszystkiego, a do tego sypie fałszywymi alarmami. Dlatego wymieniłem ten hak na „Jev Guard” — za chwilę pokażę liczby.
Przypomnijmy mechanikę: modelowi „systemu 1” podajemy stan i pytania zamknięte. Dla wszystkiego, co może pójść źle, mam pytanie: czy ujawniamy sekrety? Czy niszczymy dane — na przykład usuwając cały katalog? Czy mamy do czynienia z eksfiltracją, czyli wysyłaniem wrażliwych danych na zewnątrz, choćby w wyniku ataku typu prompt injection? Do tego dochodzi bardzo ciekawe pytanie: czy agent nie schodzi z wyznaczonego zadania? Ten sam hak może więc służyć nie tylko bezpieczeństwu — to po prostu drugi model w roli sędziego, pilnujący, czy zostajemy przy tym, co mieliśmy zrobić.
Stan, czyli główne wejście Jeva, składa się u mnie z nazwy narzędzia, jego efektu, argumentów wywołania oraz bieżącego katalogu roboczego — razem daje to pełny obraz sytuacji. Jeva odpytuję przez OpenRouter i jego nowy endpoint decyzyjny, przekazując stan wraz ze wszystkimi pytaniami, które właśnie pokazałem.
(Informacja dodatkowa: OpenRouter to popularny pośrednik API dla modeli AI — to właśnie przez niego autor wysyła zapytania do Jeva.)
Twarde liczby: wyrażenia regularne kontra LLM kontra Jev
Hak z Jevem używam dopiero od niedawna — model wyszedł przed chwilą — ale pierwsze wyniki są znakomite. Stara wersja na wyrażeniach regularnych nie blokowała aż tak wielu ryzykownych wywołań („ryzykowne” to zresztą pojęcie umowne), a głównym jej problemem były fałszywe alarmy — na przykład blokada zapisania samego słowa „.env” do dokumentu w Markdownie. Wersja z LLM-em wypada bardzo dobrze: niewiele fałszywych trafień, blokuje większość ryzykownych akcji. Ale nawet szybki i tani Haiku odpowiada ponad sekundę, a cena rzędu jednej dziesiątej centa za analizę — pozornie groszowa — robi się poważna, gdy agent wykonuje tysiące wywołań dziennie. I wreszcie Jev: blokuje praktycznie każdą ryzykowną akcję, prawie wcale się nie myli, każda analiza trwa ćwierć sekundy i kosztuje ułamek ułamka centa. Mamy więc rozsądek LLM-a w tej klasie decyzji, w cenie, która wydaje się wręcz darmowa. No, nie do końca darmowa — ale zdecydowanie nie rujnuje budżetu.
Zastosowanie 2: testowanie gier w czasie rzeczywistym
Ten sam schemat pasuje do każdej aplikacji, w której model musi reagować natychmiast. Gry wideo biorę za przykład, bo widowiskowo wygląda samo granie Jeva — a przy okazji naprawdę buduję własną grę. W rozgrywce liczącej 60 albo 30 klatek na sekundę LLM nie ma czego szukać: zanim przeanalizuje scenę, scena już przepadła, a postać dawno nie żyje. Jev nadąża — i to jest naprawdę coś. Jest przy tym praktycznie: w przepływie kodowania zawsze chcemy mieć krok walidacji — po zbudowaniu kolejnej funkcji dobrze byłoby, żeby model zagrał w grę dokładnie tak, jak zrobił to użytkownik. Przed Jevem było to nierealne.
Zobaczcie na żywo: Jev gra w jedną z gier, dla których przygotowuję prototyp koncepcyjny. Wygląda to tak, jakbym to ja siedział przy klawiaturze: postać atakuje, robi uniki, porusza się po mapie. Po lewej stronie widać decyzje Jeva — prawdopodobieństwa dla wszystkich akcji, które dajemy mu do wyboru. Bo o to właśnie chodzi: stan (gdzie jest każdy w grze) plus decyzja — jaki ruch wykonujemy następny. Ręce mam z dala od klawiatury, a naprawdę wygląda, jakbym grał sam.
Skoro model gra i przetwarza stan gry, możemy też na bieżąco oceniać, jak sprawy mają się w ogóle, i na tej podstawie działać — na przykład wyłapywać prawdziwe błędy w trakcie rozgrywki, takie, których LLM nie wykryłby sam z siebie, uruchamiając testy jednostkowe. Uruchamiam to na poważnie przy budowie kolejnych funkcji i mechanika faktycznie złapała bugi, których LLM nie widział — bo LLM nie umie grać. Może co najwyżej odpalać inne testy i szkielety testowe, które napiszę, ale to podejście deterministyczne — nie granie jak użytkownik.
Ważne zastrzeżenie: do zbudowania szkieletu dla Jeva wciąż potrzebny jest LLM. To on musi ustalić, jak przełożyć stan gry na wejście Jeva i jakie opcje ruchów mu podać. Ten szkielet powstaje z góry, a całe dalsze testowanie robi już Jev — szybko, niezawodnie i tanio. Kiedyś eksperymentowałem z tym, by LLM po prostu spowalniał grę i przechodził ją klatka po klatce — mój przed-Jevowy sposób na „granie jak użytkownik” — ale, jak można się domyślić, koszmarnie wolny i drogi.
Zasada łącząca wszystkie przypadki: Jev nigdy nie pracuje w pojedynkę
Pewnie zaczynacie już widzieć schemat: Jeva praktycznie nigdy nie używamy samego w sobie. Naprawdę mocny jest w duecie z LLM-em — bo decyzje podejmuje znakomicie, ale nie potrafi sam przygotować ani pytań, ani stanu, ani zadziałać na podstawie własnej odpowiedzi. Najlepszy układ to taki, w którym po obu stronach Jeva pracuje model językowy. W testach gier LLM buduje szkielet, a potem pracuje nad błędami, które grający Jev znajdzie. W bezpieczeństwie agent wykonuje akcje, Jev je ocenia, a jeśli coś zablokuje — agent (czyli LLM) musi wymyślić coś innego. Jev nigdy nie jest finałem przepływu; zawsze tylko przyspiesza i taniej wykonuje jego fragmenty.
Zastosowanie 3: testowanie stron internetowych
Trzeci przypadek: model przechodzący przez stronę i obsługujący ją jak użytkownik — znów jako krok walidacji w przepływie kodowania. Mechanicznie podobnie do gier, z tą różnicą że LLM-y radziły sobie tu znośnie: w przeciwieństwie do gry strona zwykle nie wymaga reakcji w ułamku sekundy, więc agent może spokojnie rozejrzeć się po widoku i dopiero wybrać następny ruch. Ale zgadliście: obok Jeva to wciąż wolno i drogo — a do tego Jev w automatyzacji przeglądarki wychodzi po prostu pewniejszy. Jeśli testujecie z LLM-em narzędziami pokroju Playwright MCP albo Vercel Agent Browser CLI, to już teraz pojawiają się open-source’owe odpowiedniki oparte na Jevie — i działają zaskakująco dobrze; w sieci krąży mnóstwo nagrań, na których Jev klika po różnych stronach.
Najważniejsze, o czym trzeba pamiętać: nie zawsze da się wpiąć Jeva wszędzie, bo nie generuje tekstu jak LLM. Wszędzie tam, gdzie trzeba wprowadzić na stronę dowolny tekst, fragment przepływu wciąż powinien obsługiwać model językowy. Poza tym jednak — im więcej decyzji (na czym się skupić, który przycisk kliknąć), tym więcej warto przenieść na Jeva. Większość automatyzacji przeglądarkowej powinna się dziś opierać właśnie na nim. Link do najlepszego według mnie open-source’owego projektu tego typu wrzucę w opisie filmu; takich projektów jest już sporo, a równie dobrze można napisać własne rozwiązanie.
Własną automatyzację z Jevem zbudowałem przy okazji testów. Przykład: DynaChat — aplikacja działająca w produkcji pod adresem chat.dynamis.ai. Agent przeszukuje całą moją zawartość z YouTube, a jeśli zalogujesz się tym samym adresem e-mail, którego używasz w społeczności Dynamis, dorzuci też materiały z warsztatów i kursów. Testowałem tak budowanie kolejnych funkcji: puszczałem Jeva przez nie dokładnie tak, jak przeszedłby użytkownik. Pełnego przebiegu nie będę tu odtwarzać, ale pokażę krótko Jeva w akcji na żywo: każdy tekst, który wpisuje, jest wygenerowany z góry przez LLM-a; cała reszta — w którą ramkę czatu kliknąć, jaki przycisk nacisnąć przy logowaniu — to jego decyzje podejmowane na bieżąco. A wszystko, co zrobi, można potem przeanalizować LLM-em, by wychwycić błędy wymagające poprawek.
Zastosowanie 4: klasyfikacja zadań na wejściu przepływu
Ostatni z czterech przypadków — i ten, którego waga rośnie u mnie z miesiąca na miesiąc. Chcę, żeby moje przepływy były dynamiczne. Po pierwsze: nie zawsze chcę używać tego samego modelu językowego — zależy to od trudności zadania, a przy dzisiejszej cenie tokenów przydałoby się coś, co na starcie zaklasyfikuje, jakiego poziomu modelu potrzebuję. Po drugie: od typu nadchodzącej pracy zależy, jakich skillo-w i kroków użyć. Przejrzysty przykład: zgłoszenie (issue) na GitHubie. To może być błąd, który trzeba zdiagnozować i naprawić, albo funkcja, którą trzeba zaplanować i zbudować. Nie chcę rozstrzygać tego samodzielnie — to się nie będzie skalowało. Potrzebuję czegoś, co sklasyfikuje zadanie i pokieruje przepływem już na początku. I dokładnie do tego Jev się nadaje.
Dokładnie ten przepływ, z opisanymi krokami klasyfikacji, zbudowałem jako workflow w Arkonie. Arkon pokazywałem na kanale wiele razy — to mój open-source’owy harness builder, narzędzie pozwalające łatwo składać większe przepływy kodowania z AI, w tym większość rzeczy z tego filmu. No i oczywiście wpiąłem w niego Jeva. To, co widzicie, to wizualizacja grafu: na wejściu trafia zgłoszenie z GitHuba, a Jev klasyfikuje dwie rzeczy. Po pierwsze, jakiego poziomu model potrzebny, żeby to załatwić — bo może to coś błahego i wystarczy na przykład Sonnet 5. Po drugie, kierunek: błąd do zbadania i naprawy czy funkcja do zaplanowania i zbudowania.
Cały workflow to jeden plik YAML. Dla każdego kroku, w którym wołam Jeva, mam mały skrypt w Pythonie: podaję argumenty, on formułuje zapytanie decyzyjne, odpytuje Jeva, a dalsza część przepływu działa na podstawie wyniku. Pokażę nawet skrypt, bo u jego samej góry widać wszystkie pytania kierowane do Jeva — i to jest właśnie ta siła: można zadać stos pytań, na które Jev odpowie równolegle, za grosze. Jakiej pracy wymaga to zgłoszenie — błąd czy funkcja? To przesądza o skillach użytych w dalszej części. Jakiego poziomu modelu potrzebujemy, biorąc pod uwagę trudność zadania: szybkiego (np. GPT-6 Terra), standardowego (Sonnet 5 albo GPT-6 Soul), czy mocnego (Opus 5.5 albo GPT-6 Astra)? Rozumiecie schemat — to Jev wydaje ten werdykt i w moich testach znakomicie wyczuwa zarówno trudność, jak i typ zadania.
W pokazanym przebiegu rozpoznał błąd wymagający zbadania, a poziom — widać go w logach, choć trzeba się wczytać — to „investigate standard”, czyli środkowy tier, coś w rodzaju Sonnet 5. We wszystkich testach Jeva sam byłem sędzią: dwunastokrotnie uruchamiałem ten przepływ w Arkonie i za każdym razem w pełni zgadzałem się z klasyfikacjami, które podejmował na starcie.
Mam też osobny workflow w Arkonie do przeglądu pull requestów: klasyfikacja z góry rozstrzyga, jakiego przeglądu wymagają zmiany — czy to większa sprawa, w której trzeba przeprowadzić pełny przegląd architektury, czy drobiazg wymagający tylko szybkiego sprawdzenia. Idealnie nie było, ale 15 trafnych rozstrzygnięć na 16 to wynik naprawdę dobry. A gdy spojrzymy na koszty — ułamek centa zamiast typowej ceny LLM-a. Te 32 centy za pull request naprawdę się sumują, zwłaszcza przy projekcie takim jak Arkon, gdzie co tydzień przechodzimy przez dziesiątki, a czasem setki PR-ów i zgłoszeń.
Na koniec
To moje cztery ulubione zastosowania Jeva w przepływach kodowania z AI. Dajcie znać w komentarzach, jeśli chcecie osobny materiał o którymś z nich — mogę wejść znacznie głębiej i pomóc wpiąć to w wasze własne przepływy. Jeśli film się spodobał i czekacie na więcej o Jevie i kodowaniu z AI, łapka i subskrypcja będą mile widziane. Do zobaczenia w następnym.