O czym jest ten film
- Jev nie pisze odpowiedzi słowo po słowie. Ocenia prawdopodobieństwo odpowiedzi określonych wcześniej przez użytkownika.
- Model obsługuje trzy rodzaje pytań: „tak lub nie”, wybór spośród możliwości oraz ocenę według zdefiniowanej skali.
- Szybkie i tanie oceny można połączyć z regułami, które uruchamiają dalsze działania albo przekazują sprawę człowiekowi.
- Autor pokazuje podział pracy: Jev podejmuje częste, drobne decyzje, a większy model planuje, bada błędy i poprawia kryteria.
- Taki układ posłużył mu do sterowania postacią w Minecrafcie; większy model wyznaczał kolejne cele i oceniał postępy.
- Jev może pomagać agentowi programistycznemu wybrać właściwą umiejętność z dużego zestawu dostępnych narzędzi.
- Autor proponuje wykorzystanie szybkich agentów przeglądarkowych do sprawdzania funkcji aplikacji po każdej zmianie.
- Inne zastosowania to ocena komentarzy w kodzie, wykrywanie oznak problemów projektowych i sprawdzanie reguł trudnych do zapisania w zwykłym linterze.
- W przeglądzie zmian Jev mógłby tanio wyszukiwać podejrzane miejsca, które następnie dokładniej oceni agent programistyczny.
- Podawane czasy i koszty pochodzą z pokazów autora oraz przywołanych przykładów; przed wdrożeniem trzeba sprawdzić skuteczność na własnym kodzie.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od decyzji, którą da się jasno określić
Na czym polega: Jev ocenia odpowiedzi podane z góry. Najlepiej pasuje do zadań, w których wiadomo, jakie rozstrzygnięcia są potrzebne i co ma się po nich wydarzyć.
Jak stosować: Zapisz konkretne pytanie, możliwe odpowiedzi i działanie przypisane do każdej z nich. Dobrym początkiem będzie wybór rodzaju zgłoszenia albo wskazanie zmian w kodzie wymagających dokładniejszego przeglądu.
Na co uważać: Jeśli istotnego przypadku brakuje wśród odpowiedzi, model i tak musi oceniać te, które dostał. Przewidź możliwość przekazania niejasnej sprawy człowiekowi.
2.Dobierz rodzaj pytania do zadania
Na czym polega: Pytanie dwuwartościowe służy do sprawdzenia jednej cechy, wybór — do rozróżnienia kategorii, a punktacja — do ustalenia miejsca na skali.
Jak stosować: Przy ocenie zgłoszeń możesz zapytać, czy występuje określony sygnał nadużycia, wybrać między kategoriami „oszustwo”, „do sprawdzenia” i „bez zastrzeżeń” albo ocenić pilność na skali z opisanymi poziomami.
Na co uważać: Skala bez jasnych opisów jest trudna do wykorzystania w automatyzacji. Sprawdź na przykładach, czy kolejne poziomy odpowiadają decyzjom, które rzeczywiście chcesz podejmować.
3.Ustal progi na podstawie własnych danych
Na czym polega: Wynik Jev można przekazać do zwykłej reguły programu, na przykład skierować przypadki powyżej określonego progu do dalszej obsługi.
Jak stosować: Zbierz próbkę wcześniej ocenionych przypadków, porównaj wyniki modelu z właściwymi rozstrzygnięciami i dopiero wtedy wybierz progi automatycznego działania oraz ręcznej kontroli.
Na co uważać: W filmie wynik tej samej oceny zmieniał się o kilka punktów procentowych między próbami. Nie opieraj ważnej decyzji na progu ustawionym tuż przy wyniku modelu.
4.Powierz tanim ocenom odsiew, a trudne przypadki głębszej analizie
Na czym polega: Jev może szybko przejrzeć wiele fragmentów danych. Większy model zajmuje się wtedy mniejszą liczbą przypadków, które wymagają wyjaśnienia lub poprawki.
Jak stosować: W przeglądzie zmian najpierw oceniaj cały diff zestawem pytań, a podejrzane fragmenty wraz z uzasadnieniem zadania przekazuj agentowi programistycznemu.
Na co uważać: Odsiew może przeoczyć ważny błąd. Mierz nie tylko oszczędność czasu i kosztów, lecz także liczbę istotnych problemów, które nie trafiły do dalszej analizy.
5.Poprawiaj kryteria po obejrzeniu wyników
Na czym polega: Większy model może przeanalizować decyzje Jev, wykryć powtarzające się pomyłki i zaproponować zmianę pytań, przykładów lub progów.
Jak stosować: Przechowuj ocenione przypadki i ich późniejszy wynik. Co pewien czas przejrzyj błędne klasyfikacje, zaktualizuj kryteria i porównaj nową wersję z poprzednią na tej samej próbce.
Na co uważać: Samodzielna zmiana zasad na podstawie kilku przypadków może pogorszyć działanie całości. Zachowuj wersje kryteriów i sprawdzaj je przed uruchomieniem.
6.Sprawdź, czy wybór umiejętności oszczędza kontekst agenta
Na czym polega: Przy dużej liczbie umiejętności agent musi przetwarzać ich opisy. Jev może wskazywać te, które pasują do bieżącego zadania.
Jak stosować: Jeśli używasz dziesiątek lub setek umiejętności, porównaj wybór dokonywany przez samego agenta z wyborem wspomaganym przez Jev. Zmierz trafność i zużycie tokenów.
Na co uważać: Wynik przytoczony w filmie dotyczy konkretnego zestawu 182 umiejętności i modelu Haiku 4.5. Nie zakładaj takiej samej poprawy w swoim środowisku.
7.Sprawdzaj działanie funkcji zaraz po jej zbudowaniu
Na czym polega: Szybki agent obsługujący przeglądarkę może przejść przez typowe czynności użytkownika i przekazać agentowi programistycznemu informację o usterce.
Jak stosować: Dla nowej funkcji określ kilka najważniejszych ścieżek: wejście na stronę, wykonanie działania i oczekiwany rezultat. Uruchamiaj je po zmianie, a wykryte problemy kieruj do poprawy.
Na co uważać: Przejście przez interfejs nie dowodzi, że funkcja działa poprawnie w każdym przypadku. Krytyczne zachowania nadal wymagają innych sposobów sprawdzenia.
8.Używaj ocen jakościowych tam, gdzie proste reguły nie wystarczają
Na czym polega: Jev może oceniać cechy kodu trudne do ujęcia w sztywnej regule, na przykład przydatność komentarza lub to, czy nazwa funkcji oddaje wszystkie jej skutki.
Jak stosować: Uruchom ocenę na niewielkiej próbce, obejrzyj listę wskazanych miejsc i dopracuj pytanie. Dopiero potem rozszerz kontrolę na repozytorium lub kolejne propozycje zmian.
Na co uważać: Ocena jakości jest zależna od kontekstu. Nie usuwaj ani nie przepisuj kodu automatycznie tylko dlatego, że uzyskał niski wynik.
9.Łącz ocenę modelu z analizą statyczną
Na czym polega: Część problemów w kodzie da się wykryć narzędziami opartymi na regułach; inne wymagają oceny znaczenia i kontekstu.
Jak stosować: Duplikaty, martwy kod czy inne łatwo wykrywalne wzorce sprawdzaj dostępnymi narzędziami. Jev wykorzystuj do pytań, przy których prosta reguła dawałaby dużo fałszywych alarmów.
Na co uważać: Sam autor przyznaje, że ze względu na sposób działania Jev nie znajdzie każdego rodzaju problemu projektowego. Wynik traktuj jako listę miejsc do zbadania.
10.Oszacuj cały koszt procesu
Na czym polega: Tania klasyfikacja pozwala częściej sprawdzać kod i aplikację, ale przy dużej skali dochodzą koszty przeglądarek, środowisk uruchomieniowych i dalszej analizy.
Jak stosować: W pilotażu licz koszt pojedynczej oceny, koszt uruchomienia środowiska oraz czas potrzebny na rozpatrzenie alarmów. Porównaj je z liczbą wykrytych usterek.
Na co uważać: Kwoty pokazane w materiale są przykładami z konkretnych prób lub szacunkami. Szczególnie ostrożnie traktuj przewidywania dotyczące tysięcy równoległych sesji przeglądarki.
Redakcyjne tłumaczenie
Czym jest Jev
Rzadko nagrywam materiał o zupełnie nowym modelu, ale Jev wydał mi się na tyle ciekawy, że postanowiłem zrobić wyjątek. Nazwa nawiązuje do paradoksu Jevonsa. Chcę pokazać, jak działa ten model i co może dać programiście korzystającemu z agentów takich jak Claude Code czy Codex.
Zwykłemu modelowi językowemu można przekazać pytanie i dane, na przykład fakturę oraz prośbę o ocenę, czy dokument wygląda na fałszywy. Model odpowie zdaniem, które tworzy kolejno, token po tokenie. Jev działa inaczej. Dostaje to samo pytanie i dokument, ale oprócz nich otrzymuje możliwe odpowiedzi. Następnie przypisuje im prawdopodobieństwa. Można mu podać na przykład kategorie „oszustwo”, „bez zastrzeżeń” i „wymaga sprawdzenia przez człowieka”.
Jev nie generuje więc swobodnej wypowiedzi. Ocenia odpowiedzi przygotowane wcześniej przez użytkownika. Wynik łatwo połączyć ze zwykłą regułą programu: jeśli prawdopodobieństwo przekroczy wybrany próg, wykonaj określone działanie. Można myśleć o tym jak o mechanizmie wyboru, który uwzględnia treść dokumentu czy opis sytuacji.
Według pokazu model często zwraca odpowiedź w mniej niż 200–300 milisekund, a w części przykładów w około 100 milisekund. To otwiera drogę do częstych ocen: od porządkowania dużych zbiorów danych po moderację wykonywaną niemal na bieżąco. Mnie interesuje przede wszystkim sprawdzanie pracy agentów piszących kod.
Na stronie usługi jest lista oczekujących. Po uzyskaniu dostępu można wejść do konsoli TypeSafeAI i wypróbować model w Playgroundzie. Warto poznać jego trzy podstawowe sposoby oceny, nawet jeśli później to agent będzie przygotowywał zapytania.
Trzy sposoby zadawania pytań
Pierwszy sposób to bool — ocena pytania, na które odpowiada się „tak” albo „nie”. W przykładzie pytam: „Czy ta faktura jest fałszywa?”. Po wklejeniu wymyślonej przeze mnie podejrzanej faktury model ocenia prawdziwość tego stwierdzenia na około 85%. Przy kolejnych próbach wynik różni się o dwa lub trzy punkty procentowe.
Mogę doprecyzować, co ma świadczyć o oszustwie, i dodać listę niepokojących cech dokumentu. Po tej zmianie ocena wzrasta w pokazie do około 94% i przy ponawianiu zapytania pozostaje blisko tej wartości. W aplikacji można później ustalić, co zrobić z wynikiem przekraczającym na przykład 85% lub 90%. Znaczenie odpowiedzi zależy jednak od kryteriów, które sami podamy.
Drugi sposób to choice, czyli wybór spośród możliwości. Podaję modelowi zasady oceny faktur i trzy odpowiedzi: „do sprawdzenia przez człowieka”, „oszustwo” oraz „bez zastrzeżeń”. W tym przykładzie Jev przypisuje 98% kategorii „oszustwo” i 2% kategorii „do sprawdzenia przez człowieka”; odpowiedź pojawia się w mniej niż 100 milisekund. Ten sposób daje więcej możliwości niż proste „tak” lub „nie”. Lista może liczyć do 255 pozycji.
Trzeci sposób to score — ocena według skali, której poziomy sami opisujemy. Załóżmy, że chcę uporządkować zapytania od potencjalnych klientów. Poziom zero oznacza studenta lub hobbystę bez budżetu. Wyżej umieszczam mały zespół, następnie firmę z konkretnym problemem i terminem, a na końcu duże przedsiębiorstwo. Po wprowadzeniu przykładowego zapytania od dużej firmy Jev zwraca wynik 2,91 na skali od zera do trzech.
Taką ocenę można powiązać z organizacją pracy. Powyżej 2,5 odpowiada tego samego dnia założyciel firmy. Wyniki od 1,5 do 2,5 trafiają do handlowca, który odpisuje w danym tygodniu. Przy niższych wynikach można przygotować automatyczną odpowiedź.
Podobną skalą da się ocenić pilność wpisu w dzienniku zdarzeń systemu. Zero oznacza zwykłe żądanie, a trzy — awarię. W przykładzie komunikat o wyczerpaniu puli połączeń uzyskuje 2,99. Reguła ustawiona powyżej 2,5 mogłaby natychmiast powiadomić inżyniera pełniącego dyżur. Niski koszt i krótki czas odpowiedzi pozwalają rozważyć częste sprawdzanie ważnego systemu.
Przy punktacji można określić do 11 poziomów, co daje skalę od zera do dziesięciu. Nie jest to lista 255 odpowiedzi dostępna przy wyborze kategorii. W jednym zapytaniu da się natomiast połączyć kilka pytań różnych rodzajów. Pokazuję to na zmianie przygotowanej przez agenta programistycznego: Jev ocenia, czy kod realizuje zadanie, czy nie osłabiono testów, jak mocne jest sprawdzenie poprawności oraz jak duży jest obszar ryzyka.
Wybór rodzaju pytania sprowadza się do tego, czego potrzebujemy. Przy pytaniu „tak lub nie” używamy bool. Jeśli przypadki da się ułożyć na sensownej skali, wybieramy score. Gdy chodzi o rozróżnienie kilku kategorii, korzystamy z choice.
Szybkie decyzje i przemyślana strategia
TypeSafeAI nazywa Jev modelem „Systemu 1”: przeznaczonym do szybkich, uporządkowanych decyzji. To nawiązanie do rozróżnienia między szybkim, niemal odruchowym myśleniem a powolniejszym namysłem, znanego z książki Pułapki myślenia. O myśleniu szybkim i wolnym.
Początkujący kierowca musi świadomie pamiętać o lusterkach, kierunkowskazach i zmianie biegów. Po nabraniu wprawy wiele z tych czynności wykonuje bez długiego zastanowienia. Na nieznanej drodze znów potrzebuje większej uwagi. To porównanie pomaga zrozumieć proponowany podział pracy między modelami: Jev może szybko rozstrzygać częste, dobrze opisane przypadki, a większy model zajmować się strategią i sytuacjami wymagającymi namysłu.
Wyobraźmy sobie program, który na podstawie wyniku Jev wykonuje czynność po przekroczeniu ustalonego progu. W pokazanym przez kogoś przykładzie jest to bot handlowy: model ocenia sytuację, a kod decyduje, czy złożyć zlecenie. Nie twierdzę, że taki bot zarabia ani że warto handlować w ten sposób. Przykład dobrze pokazuje jedynie szybkość całego mechanizmu.
Jeśli zapisywalibyśmy decyzje i ich późniejsze skutki, większy model mógłby co pewien czas badać, czy stosowana strategia działa. Na tej podstawie proponowałby nowe kryteria, przykłady albo progi. Zmiany trafiałyby następnie do szybkiego mechanizmu oceny. Właśnie współpraca tych dwóch sposobów działania jest dla mnie najciekawsza.
Eksperyment w Minecrafcie
Zobaczyłem też przykład, w którym Jev i większy model wspólnie grały w Minecrafta. Postanowiłem przygotować własną wersję. Wyznaczyłem cel: zbudować schronienie i zdobyć diamentowy kilof. Model GPT-5.6 Astra odpowiadał za planowanie, a Jev wybierał bieżące działania. Ruchy postaci wykonywała zainstalowana przeze mnie modyfikacja sterująca grą.
Planista ustalał priorytety, takie jak schronienie przed nocą czy rozpoczęcie wydobycia po zdobyciu jedzenia i narzędzi. Co dwie minuty oraz po ważniejszych wydarzeniach oceniał postęp. Gdyby postać zginęła, mógłby zbadać przyczynę i zmienić plan.
Jev podejmował częstsze decyzje. Wybierał między zbieraniem drewna, budową pieca i dokończeniem dachu. Reagował też na najbliższe otoczenie: mógł skierować postać do konkretnego drzewa, zmienić podejście do zadania albo przerwać wydobycie, gdy pojawiał się przeciwnik. Dostawał przy tym opis celu pośredniego, stanu zdrowia i głodu postaci, pory dnia, postępu prac, niedawnych zdarzeń oraz listę dostępnych czynności. W kodzie był to wybór jednej z podanych możliwości.
Gdy potrzebował wskazówek, gra była zatrzymywana, a Astra oceniał sytuację i wyznaczał następne mniejsze cele. W trakcie nagrania postać zbudowała schronienie i drzwi, zdobyła kamienny kilof, przeczekała noc w bezpiecznym miejscu, a później dotarła do diamentu. Pod koniec miała już diamentowy kilof i weszła do Netheru. To pokaz możliwości takiego podziału pracy, a nie dowód, że każdą grę lub zadanie da się prowadzić równie skutecznie.
Wybieranie umiejętności agenta
Podobny pomysł można zastosować w pracy z agentami programistycznymi. Kiedy sam tworzę umiejętności agenta, zwykle wiem, która przyda się do danego zadania. Agent mający ich dziesiątki albo setki musi dokonać takiego wyboru na podstawie opisów, które zajmują miejsce w jego kontekście.
Jev mógłby przeczytać polecenie i dotychczasowy przebieg pracy, a następnie wskazać najbardziej odpowiednią umiejętność. W oficjalnej książce przykładów Jev opisano próbę wyboru spośród 182 umiejętności agenta Hermes. Według przytoczonych wyników agent korzystający z Haiku 4.5 sam wybierał niewłaściwą umiejętność w 17% przypadków. Z podpowiedzią Jev odsetek spadł do 7,3%.
To skłania mnie do sprawdzenia, czy mogę umieścić własne umiejętności za takim mechanizmem wyboru. Ich liczne opisy zajmują u mnie około 10 tysięcy tokenów kontekstu. Chciałbym podawać agentowi tylko te, które są potrzebne do bieżącej pracy.
Szybkie sprawdzanie aplikacji w przeglądarce
Agenci piszący kod pracują lepiej, kiedy szybko dostają informację, czy przygotowana funkcja rzeczywiście działa. Jev może pomóc skrócić czas takiego sprawdzenia.
Autorzy jednego z przytoczonych projektów połączyli Jev z agentem obsługującym przeglądarkę. W pokazie wyszukanie lotu z Zurychu do Londynu na określony dzień trwało około siedmiu sekund i kosztowało 0,4 centa. Udostępnili także kod swojego rozwiązania.
Wyobrażam sobie podobnego agenta uruchomionego przy własnej aplikacji. Po zbudowaniu funkcji przechodziłby przez ważne czynności użytkownika i zgłaszał, co nie działa. Agent oparty na większym modelu, który napisał kod, otrzymywałby wynik, poprawiał usterkę i ponawiał sprawdzenie. Jeśli oceny Jev okazałyby się mało przydatne, mógłby też zmienić listę możliwości lub kryteria.
Widziałem przykład jeszcze szerszego zastosowania: wiele przeglądarek uruchomionych równolegle próbuje znaleźć błędy w kolejnej wersji aplikacji. Można wyobrazić sobie takie sprawdzanie po każdej propozycji zmiany w repozytorium. Dziesiątki agentów przechodziłyby przez różne ścieżki, a najważniejsze zgłoszenia trafiałyby do agenta programistycznego.
Chcę sam przetestować ten pomysł. Możliwość ciągłego sprawdzania aplikacji jest kusząca, lecz podane w materiale koszty dużej skali — na przykład 5–10 dolarów dziennie za tysiące sesji — pozostają na razie moim szacunkiem. Przy takiej liczbie przeglądarek trzeba też liczyć koszt środowisk, w których działają, a nie tylko koszt zapytań do modelu.
W tym miejscu wspominam o własnej usłudze AgentStack, oferującej środowiska do uruchamiania agentów. Prowadzę też dwutygodniowy program „Agent to Engineer” o pracy z agentami programistycznymi. Zapowiadam w nim około 200 lekcji, dodatkowe bezpłatne materiały, sesje pytań i odpowiedzi oraz rozmowy na Discordzie. W dalszej części omawiam eksperyment, który mógłby znaleźć zastosowanie również w takim szkoleniu.
Komentarze i jakościowe reguły dla kodu
Jeden z przykładów użycia Jev dotyczy komentarzy w kodzie. Komentarz „pomnóż wartość przez dwa” może dokładnie opisywać instrukcję, a mimo to niewiele pomagać czytelnikowi, skoro działanie widać od razu. Model może osobno oceniać poprawność i przydatność takich objaśnień.
Sprawdziłem to w projekcie, w którym znajduje się dużo słabych komentarzy pozostawionych przez starsze modele. Przekazałem agentowi umiejętność pozwalającą korzystać z TypeSafeAI oraz klucz API. Poprosiłem, by zaproponował kryteria oceny, uzgodnił je ze mną przed rozpoczęciem pracy, wskazał komentarze warte poprawienia, a następnie zlecił ich przeredagowanie agentom Haiku. Poleciłem mu zacząć od małej próbki i oszacować koszt przejrzenia całości.
Wynik próby: 150 komentarzy ocenionych w 9,3 sekundy za około jednego centa. Agent oszacował koszt oceny wszystkich komentarzy w repozytorium na około 57 centów. Przewidywał, że lista wymagających poprawy obejmie około 1700 pozycji.
To podsuwa pomysł narzędzia sprawdzającego jakość kodu według pytań zapisanych zwykłym językiem. Można na przykład pytać, czy nazwa funkcji opisuje również jej skutki uboczne. Przy wpisach w dzienniku zdarzeń systemu można oceniać, czy przypadkiem nie zapisujemy tajnych danych, wartości finansowych lub informacji pozwalających zidentyfikować osobę. Wynik mógłby oznaczać błąd albo ostrzeżenie podczas sprawdzania zmiany w repozytorium.
Takie pytania dotyczą znaczenia kodu. Czasem trudno ująć je w tradycyjnych regułach bez mnożenia wyjątków. Nie oznacza to jednak, że każdą ocenę modelu należy od razu zamieniać w zakaz wprowadzania zmiany. Kryteria trzeba najpierw sprawdzić na rzeczywistych przykładach.
Szukanie problemów projektowych
Jev mógłby również pomóc w przeglądzie całego repozytorium pod kątem oznak problemów projektowych, nazywanych czasem „zapachami kodu”. Należą do nich między innymi powielony kod, nieużywane fragmenty oraz liczby i ciągi znaków wpisane bezpośrednio w wielu miejscach.
Poprosiłem agenta Claude o strategię takiego przeglądu. W odpowiedzi wskazał problemy nadające się do zwykłej analizy statycznej oraz osobny zestaw pytań dla Jev. Oszacował, że szczegółowe przejrzenie całego repozytorium oznaczałoby 28 milionów tokenów wejściowych i koszt oceny przez Jev wynoszący 1,19 dolara. Jest to oszacowanie dla tego konkretnego projektu i zestawu pytań.
Nie każdy problem da się w ten sposób znaleźć. Rozsądny układ pracy wyglądałby następująco: Jev wykonuje szybki przegląd i wskazuje miejsca warte uwagi, a większy model ocenia krótszą listę dokładniej. Po obejrzeniu wyników można poprawić pytania i ponowić przegląd. Warto zapisywać wcześniejsze decyzje, aby sprawdzać, czy zmiana kryteriów rzeczywiście pomaga.
Tani pierwszy etap przeglądu zmian
Na tej samej zasadzie można zbudować pomocnika do przeglądu kodu. Zamiast prosić duży model, by od razu dokładnie przeczytał każdą linijkę, można zadać Jev wiele krótkich pytań o diff, ocenić wyniki i skierować najpoważniejsze sygnały do agenta programistycznego.
Zapytałem własnego agenta działającego na Opusie 5, ile mogłoby to dać. Jego ocena była taka, że Jev nie zastąpi narzędzia do przeglądu dostępnego w Claude Code, ale może dziesięciokrotnie ograniczyć ilość kodu, którą musi ono przeczytać. Wcześniejsza analiza moich sesji pokazała też, że tokeny wyjściowe odpowiadały za około 10% kosztów. Dlatego ograniczenie materiału do dokładnej analizy mogłoby mieć znaczenie finansowe. To jednak przewidywanie agenta, które zamierzam dopiero sprawdzić.
Można pójść dalej i przygotować zestaw pytań właściwy dla danego repozytorium: o jego stałe zasady, typowe błędy, zgodność między modułami czy skutki uboczne zmian. Przy każdej propozycji Jev oceniałby kod z wielu stron. Szeroki pierwszy przegląd mógłby wskazać dziedzinę problemu, na przykład bezpieczeństwo albo zgodność, a później uruchamiany byłby bardziej szczegółowy zestaw pytań. Najpoważniejsze przypadki trafiałyby do wyspecjalizowanego agenta.
Taki układ dałby agentowi programistycznemu szybki sygnał, że powinien zatrzymać się przy konkretnym fragmencie kodu. To na razie pomysł, który chcę przetestować, a nie gotowe narzędzie.
Zainteresował mnie również przykład opisany przez inżyniera Sentry. Według pokazanych przez niego wyników Jev w jednym z procesów związanych z bezpieczeństwem miał zachować wysoką trafność, działając szybciej i ponad pięciokrotnie taniej od używanych tam mniejszych modeli językowych. To zachęcający wynik z konkretnego zastosowania. Nie przesądza jeszcze, jak model poradzi sobie z przeglądem dowolnego repozytorium.
Co dalej
Najbardziej obiecujące zastosowania widzę dziś w szybkim odsiewaniu zmian wymagających uwagi: przy sprawdzaniu bezpieczeństwa, przeglądzie kodu, testowaniu aplikacji w przeglądarce i wyszukiwaniu problemów w dużych repozytoriach. Jev mógłby wykonywać wiele tanich ocen, a większy model zajmowałby się przypadkami, w których potrzebne są dokładniejsza analiza i poprawki.
Eksperyment z Minecraftem pokazał mi, jak taki podział może wyglądać w działaniu. W programowaniu trzeba jeszcze sprawdzić, czy szybkie oceny znajdują dość ważnych błędów i czy nie zasypują zespołu fałszywymi alarmami. Zamierzam prowadzić dalsze próby i opisywać ich wyniki w swoim newsletterze „Agentic Coding School” oraz w materiałach programu „Agent to Engineer”.