9 zasad programowania z AI - #6: Skille – mało i mierzone

W poprzedniej części zamienialiśmy powtarzające się błędy w stałe reguły. Niektórych rzeczy nie wystarczy agentowi zabronić, trzeba go też nauczyć od zera: jak wykonać konkretne, powtarzalne zadanie. Do tego służą skille, o których wspomniałem w pierwszej części. Tutaj przyjrzymy się im z bliska.

Zasada #6: skille – mało i mierzone

Zamiast pisać za każdym razem nowe, długie polecenie, zbuduj kilka krótkich skilli z narzędziami w środku i sprawdzaj, czy w ogóle pomagają.

Skill to paczka z wiedzą o jednym zadaniu, którą agent bierze „z półki” dopiero wtedy, gdy jej potrzebuje: instrukcja krok po kroku plus narzędzia do uruchomienia. Można myśleć o nim jak o przepisie z szufladą na potrzebne sprzęty, w odróżnieniu od jednorazowej kartki z poleceniem, którą trzeba pisać od nowa.

Z czego składa się skill

W filmie o tym, jak inżynierowie Anthropic pracują z Claude Code (autor: Austin Marchese; to jego synteza wystąpień, a nie oficjalne wytyczne firmy), opisane są trzy warstwy skilla:

1. opis, po którym agent rozpoznaje, że to ten skill pasuje do zadania,
2. instrukcje, czyli plan działania krok po kroku,
3. narzędzia: skrypty, pliki i połączenia z zewnętrznymi usługami.

Największą wartość ma ostatnia warstwa. Eric z Anthropic (cytowany w filmie) wskazuje typowy błąd: dopracowane instrukcje przy prymitywnych narzędziach, np. bez żadnego opisu, do czego służą, więc agent musi zgadywać. Według filmu inżynierowie Anthropic robią odwrotnie: inwestują w narzędzia, żeby agent nie zgadywał, tylko wykonywał sprawdzone operacje.

Do tego dochodzi prosta zasada: jeśli zadanie da się wykonać kodem, niech wykona je kod. Skrypt zawsze daje ten sam wynik, a tekst napisany przez model za każdym razem wychodzi trochę inaczej. Jeśli agent wielokrotnie pisze ten sam skrypt, zapisz go raz jako narzędzie w skillu. Przykład z filmu: Claude powtarzalnie pisał skrypt do stylizowania slajdów, więc zapisano go w skillu.

Małe, a nie jeden do wszystkiego

Skill „do wszystkiego” jest trudny w utrzymaniu: zmiana jednej części potrafi nieprzewidywalnie zepsuć inne. Lepiej mieć małe, wyspecjalizowane skille i łączyć je w większe procesy. Autor filmu podaje przykład: zamiast jednego skilla do tworzenia treści osobne do szukania pomysłów, pisania scenariusza i przygotowania posta. Gdy coś nie działa, wiadomo, w którym kawałku szukać, a poprawa jednego skilla od razu ulepsza wszystkie procesy, które z niego korzystają.

Krótsze znaczy lepsze

Najciekawszy argument przeciw rozbudowanym skillom pochodzi od Nicka Nisiego z WorkOS. Jego zespół wygenerował automatycznie z dokumentacji ponad 10 000 linii instrukcji. Testy porównawcze (takie, w których to samo zadanie wykonuje się wielokrotnie, żeby zmierzyć, jak często agent sobie radzi) trwały 68 minut i dawały gorsze wyniki. Po ręcznym przepisaniu zostało 553 linie, a przebieg skrócił się do ok. 6 minut, przy mniejszym zużyciu mocy.

Co zamiast streszczenia dokumentacji? Krótka lista pułapek: konkretnych rzeczy, w których agent najczęściej się myli. Nisi nazywa to zasadą guide, don't prescribe (podpowiadaj, nie dyktuj): zamiast opisywać wszystko, wskazać miejsca, gdzie łatwo o błąd.

Mierz, nie zakładaj

Najbardziej zaskakujące w historii Nisiego jest to, że skill potrafił zaszkodzić: zadanie udawało się w 77% prób ze skillem, a bez niego w 97%. Wyszło to tylko dlatego, że porównał oba warianty. Bez pomiaru nikt by tego nie zauważył, bo skill „wyglądał dobrze”. To trzecia z jego zasad (po enforce, don't instruct z czwartej części i guide, don't prescribe): measure, don't assume (mierz, nie zakładaj).

Te liczby pochodzą z jednego projektu jednego autora i bez opisu metody, więc nie jest to reguła dla wszystkich. Pokazują jednak, że „więcej instrukcji” nie musi znaczyć „lepiej”.

Kilka skilli, nie kilkadziesiąt

Ryan Lopopolo z OpenAI skupia całą pracę na 5–10 skillach. Woli ulepszać istniejące, niż dokładać nowe, bo narzędzia pod spodem zmieniają się zbyt często, żeby nadążać za dziesiątkami instrukcji. Całą tę złożoność chowa pod skillami, które wywołuje człowiek, a resztę agent ogarnia sam. Przykład: gdy zespół zmienił sposób sterowania przeglądarką, Lopopolo dowiedział się o tym po 3 tygodniach, bo agent sobie poradził dzięki dokumentacji w repozytorium.

Film wspomina też o możliwości blokady skilli: ryzykowne czynności, jak wysyłka wiadomości czy opublikowanie zmian dla użytkowników, powinien uruchamiać wyłącznie człowiek, a nie agent z własnej inicjatywy. Dla takich skilli da się to ustawić.

Co z tym zrobić od jutra?

• Zrób spis skilli i usuń te, których nie używasz albo które tylko powtarzają dokumentację
• Jeśli prosisz agenta o to samo wiele razy, zrób z tego skill, ale krótki, z listą pułapek
• Dodaj do skilla skrypt zamiast opisu „jak coś policzyć”
• Porównaj wynik ze skillem i bez niego (to samo zadanie, dwie sesje), zanim go zachowasz
• Czynności ryzykowne (wysyłka, publikacja, usuwanie) zostaw wyłącznie człowiekowi
• Po każdym użyciu zapytaj siebie: czy poprawka była jednorazowa, czy powinna wejść do skilla na stałe

Jedna pułapka: skill, który wygląda dobrze, a obniża trafność. Bez porównania tego nie zobaczysz.

W następnej części zajmiemy się tym, jak dopasować moc agenta i liczbę agentów do zadania, bo więcej nie zawsze znaczy lepiej.

A Wy – ile macie skilli i ile z nich naprawdę używacie? Jestem ciekaw, czy zdarzyło Wam się któryś usunąć, bo przeszkadzał – napiszcie w komentarzach 🙂