Najważniejsza praca z AI nie pokazuje się w żadnej metryce

Każda firma chwali się statystykami swojego modelu. A ten model potrafi to i tamto. Że jest lepszy od poprzednika o ileś tam procent. I każdy model jest świetny.

Ale nikt nie mówi, co trzeba ustawić i jaki prompt zadać, żeby te wyniki faktycznie osiągnąć.

Hype jest taki sam jak zawsze

Na początku jest ten hype. Każdy nowy model, jak kiedyś każdy nowy framework JavaScript, jest najlepszy. Każdy zastąpi wszystkich developerów, wygeneruje idealny kod, nie będziesz potrzebował zespołu.

A ja szczerze myślę, że on tylko dołożył nam pracy.

Sam zrozumiałem to dopiero niedawno. Wcześniej myślałem, że odpalasz Claude Code albo Codexa, wrzucasz prompt i gotowe, masz kod. No i masz kod. Tylko zwykle w tragicznym stanie.

Konkretny przykład

Potrzebowałem komponentu, który renderuje posty na blogu. AI twardo szło w dangerouslySetInnerHTML, "tak się to robi, jest okej".

Drążyłem dalej i wypunktowałem: przecież to otwiera drzwi na XSS. Jak treść nie jest sanitizowana, ktoś może wstrzyknąć dowolny skrypt. Model: "faktycznie masz rację, przepraszam".

Ale tu jest sedno. Gdybym nie wiedział, że to ryzyko, zmergowałbym to z czystym sumieniem. Kod by działał. Bomba tykałaby cicho, dopóki ktoś by jej nie odpalił.

Więc zaczynasz ustawiać rzeczy

Później, po przeczytaniu zbyt wielu artykułów, odkryłem, że zaczyna się od pliku AGENTS.md. Dobra. Tylko co w nim napisać, żeby to miało sens i pomogło, a nie dołożyło jeszcze więcej problemów?

Okazuje się, że jak chcesz naprawdę porządny kod, ten plik musi nieść podstawy projektu: jak ułożone są komponenty, jak typujesz rzeczy, jak ma wyglądać projekt. Czyli błaha z pozoru rzecz, jak wiedzieć, jak poukładać pliki, jaki linter wpiąć, co ustawić, jest naprawdę potrzebna. Ta wiedza nigdzie nie zniknęła.

Jeden plik nigdy nie wystarczy

Potem kolejny problem. Jak chcesz kod dobrze ostylowany i poukładany, nie wepchniesz wszystkiego w jeden AGENTS.md. Przeładujesz go i model zaczyna zmyślać, halucynuje, i wychodzą rzeczy, które ugryzą Cię później.

Więc dzielisz to: osobny plik, osobny agent. Dorzucasz value gates, żeby powiedzieć modelowi, co naprawdę jest istotne, a co jest szumem. A te instrukcje muszą być dobrze sformatowane i dobrane, bo ładują się do kontekstu i na dzień dobry zjadają Ci część tokenów.

Sam prompt to też praca

I sam prompt musi być odpowiedni. "Wygeneruj komponent, który coś tam robi" nie wystarczy, bo model raz zerknie na instrukcje, raz je zignoruje.

Trzeba mu powiedzieć wprost: zajrzyj do instrukcji w tym pliku, potem odpal agenta, który Cię zweryfikuje. A najlepiej wejść w tryb planowania i przejść kilka iteracji, wtedy wynik jest najlepszy.

Słowo o pójściu na skróty

Są oczywiście gotowe skille do instalacji jako plugin. Tylko to zaczyna przypominać kolejną warstwę, tym razem podpiętą bezpośrednio do agenta, który ma dostęp do repo, terminala i czasem sekretów.

A po tym, ile widzieliśmy ostatnio ataków na npm, PyPI czy rozszerzenia IDE, coraz mniej ufam instalowaniu losowych helperów bez sprawdzania, co faktycznie robią. Dlatego poświęcenie czasu na napisanie własnych skilli jest moim zdaniem po prostu bezpieczniejsze.

Część, której nikt nie mierzy

I to jest sedno. Cała ta praca przy ustawieniu modelu to największe wyzwanie, i to, o którym nikt nie mówi.

Statystyki modelu są prawdziwe, pokazują, co potrafi. Ale żeby faktycznie do nich dojść, do jakości obiecanej w benchmarkach, trzeba poświęcić godziny roboty, których nie widać w żadnym wykresie, żadnej metryce velocity, żadnym "X% lepszy od poprzedniego modelu".

Benchmark to sufit. Dojście do niego to ta niewidzialna praca.