Sytuacja
Od kwietnia 2026 jestem AI Adoption Leader dla Claude Code w Intarget: decyduję, komu dać dostęp, szkolę ludzi i odpowiadam za koszty oraz korzyści. Gdyby zależało to ode mnie, dałbym Claude Code wszystkim. Samo włączenie niczego jednak nie rozwiązuje. Prawdziwe ryzyko to skalowanie błędów, czyli robienie tych samych złych rzeczy dwa razy częściej każdego dnia.
Co zrobiłem
Z dostępu zrobiłem proces. Każda rozmowa kończy się prawdziwym zadaniem, jego danymi wejściowymi, ustaleniem, co oznacza sukces, kto może go ocenić i kiedy znów o tym porozmawiamy. Przy kolejnych spotkaniach pytam o ostatnią wypuszczoną rzecz, jej jakość i miejsca, w których potrzebna jest pomoc. Zasady pracy umieściłem we wspólnym repo, napisanym dla ludzi, a przede wszystkim dla agenta. Dzięki temu Claude Code znajduje je przy każdym uruchomieniu.
Co tydzień odbywa się Laboratorio Generative AI. Andrea Zennaro je przygotowuje i prowadzi. Ja odpowiadam za część techniczną, robię demo i zbieram to, co nie działa, żeby to poprawić. Na labie także osoby, które nie piszą kodu, zamieniają swoją powtarzalną pracę w skille.
Co się zmieniło
Wdrażanie trwa i obejmuje kolejne zespoły, po jednym na raz. W każdym punktem odniesienia jest osoba, która wykonała już reprezentatywne zadanie. Autonomia rośnie, gdy ludzie pokazują, że potrafią podejmować dobre decyzje. Osoby, które nie programują, budują dziś skille do raportów i kontroli. Odzyskany czas przeznaczają na głębszą analizę. Jedna koleżanka nazywa to zyskanym czasem.
Czego się nauczyłem
Używam Claude Code do wszystkiego i nie piszę już kodu ręcznie. Mimo to w dużych bazach kodu narobił mi bałaganu. Wtedy zacząłem pisać testy przed kodem. Skoro zdarza się to komuś, kto używa go cały dzień, kurs podstawowy nie przenosi odpowiedzialności za projekt na agenta. Choć po jego ukończeniu można mieć poczucie, że potrafi się nadzorować każdą pracę. Dlatego dostęp wymaga rozmowy zakończonej prawdziwym zadaniem i wskazania osoby, która umie je ocenić. Przy każdej ważnej zmianie proszę osobę, która ją zleca, żeby potrafiła wyjaśnić projekt i sprawdzić działanie.
Quello che non può rimpiazzare è il systems design (Nie zastąpi projektowania systemów).
Koleżanka zapisywała prompt z każdej próby i za każdym razem go poprawiała. Kiedy metoda się ustabilizowała, zleciła jej uogólnienie w trzech częściach: metoda, brief klienta i lista plików do użycia. Ta sama metoda przechodziła od klienta do klienta. Zmieniały się tylko brief i pliki. Spec napisany od zera, przy biurku, wygląda na bardziej uporządkowany początek. Gubi jednak niewypowiedziane poprawki, dzięki którym metoda działa. Udana rozmowa je zachowuje. Od tamtej pory na labie proponuję zacząć właśnie od niej: najpierw udana praca, potem skill wyciągnięty z tej rozmowy.
Podczas demo na labie ta sama koleżanka wywołała skill i dodała długą listę instrukcji, jak wykonać pracę. Czat się pogubił. Otworzyła nowy, z już wgranymi plikami, i przez pomyłkę nacisnęła enter prawie bez tekstu. Wynik był niemal idealny. Metoda już była w skillu, a przepisanie jej na czacie sprawiało, że konkurowała sama ze sobą. Od tamtej pory sprawdzonemu skillowi przekazujemy dane wejściowe i wyjątki. Kiedy ktoś czuje potrzebę powtórzenia metody na czacie, traktujemy to jako sygnał, że trzeba poprawić skill.
Koleżanka, która nie pisze kodu, zbudowała wiele małych skilli, po jednym na operację, zamiast jednego do całej pracy dla klienta. Na labie pokazała wynik: porównywał dane i od razu wskazywał, gdzie zajrzeć, na przykład na zamówienie zwrócone tylko częściowo. Od automatyzacji dla osób nieprogramujących oczekuje się mniej kliknięć i szybszych raportów. Wartość, którą opisywała, była w wykrytej anomalii i decyzji, która po niej następowała. Dziś to moje pierwsze pytanie, kiedy ktoś chce zamienić kontrolę w skill: który wyjątek zasługuje na jego uwagę i do jakiej decyzji jest potrzebny.