O czym jest ten film
- Duża liczba zmian przygotowanych przez agenta AI wynika przede wszystkim ze sposobu organizacji pracy, a nie z samej szybkości programisty.
- Ustalenia wypracowane z agentem powinny być dostępne dla całego zespołu, zamiast ginąć w prywatnych rozmowach.
- Historia decyzji i postęp prac muszą przetrwać zamknięcie czatu, zmianę modelu oraz ponowne uruchomienie środowiska.
- Człowiek odpowiada za cel, granice działania agenta i decyzję o udostępnieniu wyniku użytkownikom.
- Testy, kontrole kodu i uprawnienia pozwalają wykrywać błędy w trakcie pracy, zanim staną się problemem przy odbiorze.
- Zadanie należy zostawić w takim stanie, by kolejna osoba lub kolejny agent mogli je podjąć bez odtwarzania całej rozmowy.
- Agent powinien mieć możliwość samodzielnego sprawdzenia, czy jego zmiany działają.
- Powracające błędy warto zamieniać we wspólne instrukcje lub automatyczne kontrole.
- AI daje okazję do usunięcia zbędnych etapów pracy, ale nie zastępuje wszystkich funkcji ludzkiej współpracy.
- Liczba zmian w kodzie nie jest miarą wartości. Liczy się to, czy zespół szybciej dostarcza rzeczy potrzebne użytkownikom.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zapisuj rozwiązania tam, gdzie znajdzie je cały zespół
Na czym polega: Jeśli sposób rozwiązania trudnego problemu zostaje tylko w prywatnym czacie, następna osoba i jej agent mogą powtórzyć te same próby oraz błędy.
Jak stosować: Po zakończeniu zadania przenieś przydatne ustalenia do wspólnej instrukcji projektu, krótkiej notatki lub procedury, z której agent może skorzystać przy podobnej pracy. Sprawdzaj, czy inni rzeczywiście do niej wracają.
Na co uważać: Samo dodanie agenta do firmowego komunikatora nie wystarczy. Wiedza musi być zrozumiała, aktualna i dostępna w miejscu, w którym zespół pracuje.
2.Zachowuj decyzje poza historią czatu
Na czym polega: Rozmowa może zostać skrócona lub zakończona. Wtedy giną powody podjętych decyzji, nawet jeśli kod pozostał na miejscu.
Jak stosować: Zapisuj cel zadania, odrzucone rozwiązania, otwarte problemy i istotne ustalenia w trwałym miejscu powiązanym z projektem.
Na co uważać: Nie traktuj pełnego zapisu rozmowy jako gotowej dokumentacji. Kolejny wykonawca potrzebuje przede wszystkim jasnego obrazu stanu prac.
3.Ustal odpowiedzialność człowieka przed uruchomieniem agenta
Na czym polega: Agent może analizować problem, pisać kod i uruchamiać testy, lecz człowiek nadal odpowiada za to, co trafia do użytkownika.
Jak stosować: Przed rozpoczęciem pracy określ, jaki wynik ma powstać, czego agentowi nie wolno zmieniać oraz na jakiej podstawie zatwierdzisz rezultat.
Na co uważać: Nie utożsamiaj odpowiedzialności z ręcznym śledzeniem każdego kroku. Potrzebne są także kontrole działające podczas pracy.
4.Ucz rozumienia wyników, nie ręcznego odtwarzania pracy AI
Na czym polega: Osoba korzystająca z AI powinna umieć wyjaśnić otrzymany wynik i odpowiedzieć na pytania o jego działanie.
Jak stosować: Przy arkuszu, raporcie lub kodzie poproś autora o wyjaśnienie kluczowych założeń, sprawdzenie wyniku oraz wskazanie ograniczeń.
Na co uważać: Wymóg wykonania wszystkiego bez AI może być sztucznym ćwiczeniem. Równie szkodliwe jest oddanie zespołowi obszernego wyniku, którego autor nie rozumie.
5.Wbuduj kontrole w przebieg pracy
Na czym polega: Testy, kontrole kodu i ograniczenia uprawnień mogą wychwycić znane problemy, zanim człowiek zobaczy końcowy rezultat.
Jak stosować: Dobierz kontrole do najczęstszych błędów projektu. Pozwól agentowi działać samodzielnie w ustalonych granicach, a człowiekowi zostaw ocenę ryzyka, celu produktu i jakości końcowej.
Na co uważać: Zaliczony test nie dowodzi, że produkt jest użyteczny lub bezpieczny w każdym sensie. Agent nie powinien też móc usuwać testów tylko po to, by uzyskać pozytywny wynik.
6.Zostawiaj zadanie gotowe do przejęcia
Na czym polega: Zachowanie historii rozmowy nie wystarczy, jeśli następna osoba nie wie, co działa i od czego zacząć.
Jak stosować: Kończ dłuższy etap krótkim zapisem postępu: co ukończono, co pozostało, jak uruchomić projekt i które podstawowe sprawdzenia wykonać na początku.
Na co uważać: Nie opieraj ciągłości pracy na pamięci jednej osoby ani na specjalnym poleceniu, którego nigdzie nie zapisano.
7.Daj agentowi sposób na ocenę własnych zmian
Na czym polega: Agent pracuje wolniej, gdy po każdej zmianie musi pytać człowieka, czy wynik wygląda i działa poprawnie.
Jak stosować: Przygotuj środowisko testowe, powtarzalny przypadek do sprawdzenia oraz kontrole, które agent może sam uruchomić. Przy interfejsie zachowuj przykładowe widoki lub scenariusze pod stałymi odnośnikami.
Na co uważać: Możliwość samodzielnego testowania ma sens tylko wtedy, gdy test mierzy cechę ważną dla użytkownika, a nie jedynie łatwy do zaliczenia warunek.
8.Zamieniaj powtarzające się pomyłki w reguły
Na czym polega: Gdy agent stale popełnia ten sam błąd, kolejne upomnienie w rozmowie pomaga tylko doraźnie.
Jak stosować: Utrwal poprawkę jako krótką instrukcję do ponownego użycia albo automatyczną kontrolę, która zatrzyma podobny błąd w przyszłości.
Na co uważać: Nie dopisuj bez końca akapitów do jednego wielkiego pliku z poleceniami. Reguła powinna być łatwa do odnalezienia i możliwa do sprawdzenia.
9.Oceniaj sens każdego etapu procesu
Na czym polega: AI może przyspieszyć sporządzanie dokumentów i przekazywanie zadań, które w danym projekcie przestały być potrzebne.
Jak stosować: Wybierz trzy powtarzalne czynności zespołu. Przy każdej ustal, jakie pytanie miała rozstrzygać, po czym skróć lub usuń jeden etap, jeśli cel da się osiągnąć prościej.
Na co uważać: Rytuał może służyć również współpracy i orientacji we wspólnym celu. Automatyczne przekazanie informacji nie zawsze zastąpi rozmowę ludzi.
10.Zacznij od małej grupy i mierz wartość dla użytkownika
Na czym polega: Praktyki pracy z agentami łatwiej dopracować w kilkuosobowym zespole. Sama liczba propozycji zmian w kodzie nie mówi, czy produkt stał się lepszy.
Jak stosować: Wypróbuj rozwiązania z trzema–pięcioma osobami, usuń najbardziej dotkliwe wąskie gardło i obserwuj, czy szybciej kończą zadania istotne dla klientów.
Na co uważać: Nie zamieniaj wyniku wyjątkowo produktywnej osoby w normę dla całego zespołu. Przy współpracy agentów ustal też granice ich działania, sposób kontroli i warunki przerwania zadania.
Redakcyjne tłumaczenie
Skąd bierze się tempo pracy z agentami?
W lipcu Lauren Tan przygotowała około tysiąca propozycji zmian w kodzie. Zapowiedziała, że w sierpniu podwoi ten wynik. Ostatecznie osiągnęła 2462. Zapowiedź była śmiała, a mimo to ją przebiła.
Twój zespół prawdopodobnie nie osiągnie w tym miesiącu podobnej liczby. Nie musi to oznaczać, że pracują w nim słabsi programiści. Przy takiej skali decydujące znaczenie ma sposób organizacji pracy z agentami AI. O tym mówi się znacznie mniej niż o samych narzędziach.
Agenci przygotowują zmiany, które trafiają dalej pod twoim nazwiskiem. Jednocześnie słyszysz, że trzeba pracować coraz szybciej. Jakimi środkami naprawdę dysponujesz, by wpływać zarówno na tempo, jak i na jakość? U wielu osób ta lista jest krótka. Nie świadczy to źle o nich samych. Po prostu nikt nie pokazał im, jak zorganizować pracę agentów.
Chcę przedstawić sześć zasad wyciągniętych z doświadczeń Lauren i innych osób. Można je zastosować z narzędziami AI, z których już korzystasz.
Według raportu Cursor o zwyczajach programistów najaktywniejsi użytkownicy tego narzędzia doprowadzają do połączenia z głównym kodem około piętnastu razy więcej propozycji zmian niż typowy programista, który również regularnie je zgłasza. Tymczasem w wielu zespołach, mimo dostępu do AI, nadal rośnie kolejka niedokończonych zadań. Skąd ta różnica?
Lauren, znana w sieci jako Potto, opowiedziała podczas Cursor Compile London, jak dochodzi do ponad dwóch tysięcy zmian miesięcznie. Udostępniła nagranie publicznie. To cenne, bo najpraktyczniejsze rozwiązania często kryją się w szczegółach czyjejś codziennej pracy. Rzadko zdobywają rozgłos, a firmy nie zawsze mają powód, by je ujawniać.
Przykład Lauren nie jest jedyny. Shopify zbudowało wspólny system pracy z agentami. Addy Osmani pisał o tym, za co ludzie nadal odpowiadają, gdy kod powstaje z pomocą AI. Fiona z zespołu Claude Code opisała zmianę sposobu pracy wraz z rozwojem narzędzia. Z tych przykładów wyłania się ważne pytanie: jak zorganizować pracę, żeby system nadal się sprawdzał, gdy modele stają się lepsze, a korzysta z nich coraz więcej osób?
Można stworzyć rozbudowaną konstrukcję, której utrzymanie zajmuje tygodnie. Steve Yegge mówił o swoim projekcie Gas Town: zbudował złożony system, lecz sam system nie przełożył się u niego na produktywną pracę. Jeśli każda zmiana modelu albo dołączenie nowej osoby zmusza do przebudowania całego rozwiązania, dokładamy sobie obowiązków. Dlatego przedstawione tu zasady mają pozostać proste.
1.Przenieś przydatną wiedzę do wspólnego miejsca
Przypomnij sobie ostatni trudny problem rozwiązany wspólnie z agentem. Kilka prób się nie udało, aż w końcu znaleźliście właściwe podejście. Co stało się z tą wiedzą? Jeśli pozostała w prywatnej rozmowie na twoim komputerze, koleżanka lub kolega z zespołu może jutro przejść dokładnie tę samą drogę.
To szczególnie kosztowne przy większych projektach. Zespoły szybko się zmieniają, nowi ludzie muszą wdrożyć się do pracy, a uruchomione przez nich agenty powinny móc skorzystać z wcześniejszych ustaleń.
Shopify daje ciekawy przykład. Jego agent River pracuje na firmowych kanałach Slacka. Rozmowy i odkrycia są więc widoczne dla innych, a przydatne ustalenia można zamienić we wspólne instrukcje i umiejętności dostępne w kolejnych sesjach. W opisanym przez firmę okresie trzydziestu dni River obsłużył około 60 tysięcy sesji na tysiącach kanałów. Według Shopify współtworzył też mniej więcej jedną na osiem propozycji zmian, które przyjęto do kodu. Nie służył zatem wyłącznie do rozmów.
Praca na wspólnym kanale może być poważną pracą. W wielu firmach ludzie przenoszą trudniejsze sprawy do prywatnych wiadomości. Kiedy agent działa w miejscu dostępnym dla zespołu, inni mogą zobaczyć, jak rozwiązano problem, i skorzystać z wyniku.
Nie chodzi jednak koniecznie o Slacka. Potrzebne są wspólne instrukcje projektu, rozwiązania nadające się do ponownego użycia i zapisy pracy, które nie znikają wraz z prywatnym czatem. Najbardziej doświadczeni użytkownicy AI potrafią już prosić agentów o pomoc w trudnych zadaniach, a nawet pozwalają im współpracować ze sobą. Inni w tym samym zespole mogą nie wiedzieć, że mają taką możliwość.
Jeśli kierujesz zespołem, zadbaj o to, by użyteczne ustalenia najlepszych osób stawały się dostępne dla wszystkich. Może to być instrukcja, notatka projektowa albo zapis działań agenta, z którego inni programiści wyciągną wnioski. Sprawdzaj, czy te materiały są wykorzystywane i czy pomagają kończyć zadania szybciej. Wiedza nie powinna być dostępna dopiero wtedy, gdy osoba, która rozwiązała problem, znajdzie czas na jej przekazanie.
2.Zachowaj historię decyzji niezależnie od bieżącej sesji
Zdarza się, że przez wiele godzin wprowadzasz agenta w projekt. W końcu rozumie, jaki ma być wynik, jakie rozwiązania odrzuciliście i co jeszcze nie działa. Potem zaczynasz nową rozmowę albo dotychczasowa zostaje skrócona. Trzeba tłumaczyć dużą część od początku.
Skracanie historii rozmów działa coraz lepiej, ale przy pracy wymagającej zachowania szczegółów nadal można stracić ważne rozumowanie. Kod pozostaje, za to znika wyjaśnienie, dlaczego powstał właśnie w tej postaci.
Za Riverem stoi platforma Shopify o nazwie Aquifer. Oddziela ona zachowaną historię sesji od oprogramowania uruchamiającego agenta oraz od tymczasowego środowiska, w którym działa kod. Oprogramowanie i środowisko można wymienić, a zapis wcześniejszej pracy pozostaje dostępny. Zmiana modelu czy ponowne uruchomienie maszyny nie oznacza więc utraty całej historii działania agenta.
Zadaj sobie pytanie: co stracisz, jeśli znikną rozmowy z agentem z ostatniego tygodnia? Wszystko, czego nie możesz sobie pozwolić utracić, powinno mieć miejsce poza czatem. W zespole trzeba to uwzględnić już przy organizowaniu projektu. Ciągłość pracy nie może zależeć od utrzymywania jednej rozmowy bez końca.
3.Człowiek nadal odpowiada za rezultat
Addy Osmani ujmuje tę odpowiedzialność jako nadzór nad całością zadania. Agent może badać problem, pisać kod, uruchamiać testy i ponawiać próby. To czynności, które często wykona samodzielnie. Człowiek określa jednak cel, granice działania oraz dowody, które pozwolą uznać wynik za wystarczająco dobry.
Za to, co trafia do klienta, musi odpowiadać człowiek. W praktyce potrzebne są różne kompetencje: ktoś powinien wyjaśnić wartość rozwiązania dla firmy, ktoś ocenić działanie kodu, a ktoś zrozumieć, jak współpracują dane, agenci i kontrole. Nie zawsze będzie to ta sama osoba. Potrzebna jest też dobra znajomość ludzi, którzy mają korzystać z produktu.
Narzędzia mogą zmieniać podział codziennych czynności, lecz nie usuwają odpowiedzialności. Dobrze widać to na przykładzie arkusza kalkulacyjnego. Zmuszanie osoby na początku kariery do sporządzenia go ręcznie tylko po to, by udowodniła, że potrafi, często byłoby stratą czasu. Możemy oczekiwać, że użyje AI. Powinniśmy jednak móc poprosić ją o wyjaśnienie ważnych komórek, zasad obliczeń i powodów, dla których arkusz daje określony wynik. Powinna również umieć sprawdzić go z pomocą AI.
Tak rozumiana odpowiedzialność służy nauce. Wymaga wysiłku, lecz pozwala rozwijać ludzi. Przeciwieństwem jest niekończący się strumień wyników wygenerowanych przez AI, których autor nie potrafi objaśnić. Może czuć się produktywny, ale reszta zespołu dostaje dodatkową pracę: musi sama ustalić, co właściwie otrzymała.
Nie sposób przy tym osobiście obserwować każdego ruchu agenta. Dlatego kontrole trzeba umieścić w samym przebiegu pracy. Testy mogą wykrywać uszkodzone funkcje, automatyczne sprawdzanie kodu zatrzymywać znane błędy, a uprawnienia uniemożliwiać agentowi zmiany tam, gdzie nie powinien ich wprowadzać. Agent otrzymuje swobodę w określonych granicach, człowiek zaś wie, które miejsca wymagają uważniejszego przeglądu. Całość nie może zależeć od tego, czy zauważysz błąd tuż przed publikacją.
Sam korzystam niekiedy z drugiego agenta, którego zadaniem jest nadzorowanie pracy pierwszego i zgłoszenie mi, kiedy wynik spełnia ustalone wymagania. Fiona opisuje podobny podział w zespole Claude Code. Claude wykonuje wiele kontroli stylu, szuka błędów i uruchamia testy. Ludzie skupiają się na kwestiach, za które odpowiadają: ryzyku prawnym, bezpieczeństwie, celu produktu i ocenie wyniku nawet wtedy, gdy testy zakończyły się pomyślnie.
Jeffrey Lit z Notion zwraca uwagę na jeszcze jeden powód, by rozumieć wykonaną pracę: tylko wtedy można wnieść następny pomysł i ulepszyć rozwiązanie. Rola człowieka nie sprowadza się do zatwierdzenia gotowego wyniku.
Przed kolejnym zadaniem spróbuj więc zapisać trzy rzeczy: co agent ma zrobić, co sam sprawdzi oraz na jakiej podstawie zdecydujesz o udostępnieniu efektu. Nie potrzeba komisji, która będzie dowodzić, że ludzie wciąż mają zajęcie. Potrzeba osób świadomych własnej odpowiedzialności i rozsądnego sposobu sprawdzania pracy agentów.
4.Zostawiaj pracę w stanie gotowym do przejęcia
Ta zasada wiąże się z zachowaniem historii, ale dotyczy innego problemu. Można przechować każdą wiadomość, a mimo to nie dać następnej osobie żadnej wskazówki, od czego zacząć.
Prace Justina Younga nad agentami wykonującymi długotrwałe zadania pokazują praktyczniejszy sposób przekazywania pracy. Obejmuje on listę funkcji, zapis postępu, sposób uruchomienia projektu oraz kod pozostawiony w stanie, z którym poradzi sobie następny człowiek lub agent.
Nowa sesja powinna najpierw ustalić stan projektu: przeczytać notatki, obejrzeć zmiany i sprawdzić, czy podstawowa wersja aplikacji nadal działa. Dopiero potem zaczyna kolejne zadanie.
Szczególnie ważny jest drobny szczegół. Agent może oznaczyć funkcję jako działającą, kiedy rzeczywiście przejdzie sprawdzenie. Nie może natomiast usuwać testów wykazujących, że coś nie działa. W przeciwnym razie łatwo stworzyć system, w którym agent psuje produkt, usuwa niewygodne testy i przedstawia nam zieloną listę wyników. Kontrole trzeba zaprojektować tak, by dało się je zaliczyć uczciwie.
Zanim odejdziesz od dłuższego zadania, pomyśl o jutrzejszym poranku. Czy ktoś inny uruchomi projekt? Czy dowie się, co pozostało do zrobienia? Jeśli potrzebne jest szczególne polecenie, zapisz je. Inżynierowie od lat przypominają, że projekt nie może zależeć od wiedzy jednej osoby. W pracy z agentami ma to jeszcze większe znaczenie.
5.Pozwól agentowi samodzielnie sprawdzić własną pracę
Przy tworzeniu interfejsów ten problem długo był szczególnie dotkliwy. Agent wprowadza zmianę, być może pobieżnie ją ogląda, po czym prosi człowieka o ocenę. Człowiek opisuje to, co widzi na ekranie. Agent poprawia projekt i ponownie prosi o opinię. W ten sposób można spędzić całe popołudnie.
Lewis Metaf pisał o przygotowywaniu małych środowisk, w których agent może przeprowadzić próbę i sam sprawdzić rezultat. Konkretny przypadek można zachować pod odnośnikiem, żeby inna osoba otworzyła dokładnie ten sam przykład. Można też dodać automatyczną kontrolę, która nie wymaga ręcznego przeklikiwania interfejsu. Agent wprowadza zmianę, sprawdza ją w takim środowisku i dowiaduje się, czy zadziałała. Człowiek może skupić się na ocenie wyniku i decyzji o dalszym kierunku.
Ta zasada wykracza poza pracę nad wyglądem produktu. Czy agent potrafi znaleźć dokumentację? Czy zasady projektu zapisano w miejscu, do którego zagląda? Czy może sam uruchomić potrzebne sprawdzenie, bez proszenia cię za każdym razem o objaśnienie środowiska? Przydatniejsza od ogólnego zwiększania swobody agenta bywa możliwość ustalenia, czy jego praca posuwa sprawę naprzód.
Można też udostępnić agentowi wiedzę, z którą będzie porównywał swoje odpowiedzi. Właśnie dlatego stworzyłem „Nate’s Library MCP”. Osoby z płatną subskrypcją mojego Substacka mogą połączyć używane przez siebie narzędzia AI z archiwum moich artykułów i transkryptów. Agent znajduje właściwy fragment i przywołuje go podczas pracy. Nie trzeba pamiętać, w którym tekście lub nagraniu pojawiła się dana myśl. Chciałem, by ta wiedza była dostępna tam, gdzie ludzie wykonują zadania związane z AI, zamiast pozostawać tylko na stronie z artykułami czy w serwisie YouTube.
Lauren stosuje podobną zasadę do powtarzających się pomyłek agentów. Gdy błąd wraca, zamienia poprawkę w instrukcję nadającą się do ponownego użycia albo w automatyczną kontrolę kodu. Następne zadania są już sprawdzane pod tym kątem. To skuteczniejsze niż dopisanie kolejnego akapitu do wielkiego pliku z poleceniami i liczenie, że agent przypomni sobie o nim za tydzień.
Lauren mówi, że przy jej obecnym tempie prawie nie zagląda już do kodu. Przy ponad dwóch tysiącach propozycji zmian miesięcznie trudno byłoby czytać każdą z nich w zwykły sposób. Nie należy jednak wyciągać z tego wniosku, że wystarczy przestać sprawdzać kod. Najpierw trzeba zrozumieć, jakie kontrole umożliwiają jej pracę i co dzieje się wtedy, gdy agent nie potrafi rozwiązać problemu.
6.Usuń etapy, które przestały pomagać
Dawniej papierowe notatki krążyły po biurach w kopertach. Na kopercie wpisywano nazwisko następnej osoby i przekazywano ją dalej. Przy pracy z AI łatwo nieświadomie odtworzyć ten sam obieg: jeden agent coś pisze, drugi przerabia format, trzeci przesyła wynik dalej, aż w końcu trafia on do człowieka. Zmieniły się narzędzia, ale dawny proces pozostał. Każdy dodatkowy krok zużywa czas i zasoby obliczeniowe.
Widziałem przypadek, w którym menedżer produktu uważał, że przed rozpoczęciem pisania kodu musi sporządzić dokument wymagań i utworzyć zadania w systemie. Jednocześnie twierdził, że cały zespół zgadza się już co do celu i rozwiązania technicznego. W małym zespole taki poziom porozumienia można czasem osiągnąć bez pełnego zestawu dokumentów. W dużym dokumentacja bywa konieczna. Nie chodzi o ogólną zasadę, które pliki należy przygotować. Chodzi o zadanie prostszego pytania: czy ten krok jest tu w ogóle potrzebny?
Nie ma powodu świętować, że dzięki AI dokument i zadania powstały w pięć minut, jeśli nie wnoszą niczego do pracy. Zanim uruchomisz agenta, ustal, jaki rezultat chcesz osiągnąć i jaka droga naprawdę do niego prowadzi. Dotyczy to również wydatków na modele AI: nie warto zużywać możliwości najdroższych modeli na podtrzymywanie zbędnego obiegu dokumentów.
Fiona opowiada, że w zespole Claude Code pracownicy dostali wyraźne przyzwolenie na rezygnację z przestarzałych procedur. Sześciomiesięczne plany szybko traciły aktualność. Zespół częściej przygotowuje prototyp, pokazuje go innym osobom w firmie i uczy się z ich uwag. Wraz z poprawą możliwości Claude’a łatwiejsze stawały się pisanie kodu, testowanie i porządkowanie istniejących rozwiązań. Ludzie poświęcają więcej uwagi ocenie rezultatów i bezpieczeństwu, bo tam ich udział jest szczególnie potrzebny.
To doświadczenie zespołu pracującego w Anthropic. Twoja firma zapewne działa w innych warunkach. Nadal możesz jednak pozwolić ludziom pytać o sens poszczególnych etapów. Możesz zatrudniać osoby, które potrafią budować i rozwijać systemy, a menedżerów trzymać dostatecznie blisko codziennej pracy, by nie zarządzali według wyobrażeń o AI sprzed roku.
Trzeba przy tym uważać na funkcje zespołowych zwyczajów, których agent może nie dostrzec. Krótkie codzienne spotkanie oficjalnie służy wymianie informacji o zadaniach. Nieoficjalnie pomaga zobaczyć współpracowników, dowiedzieć się, kto utknął, i przypomnieć sobie, dlaczego pracujecie razem. Jeśli aktualizacje zaczną przekazywać agenci, ta ludzka część spotkania sama się nie odtworzy.
Warto uczciwie nazwać cel każdego zwyczaju. Czy służy przekazaniu danych, budowaniu więzi, podejmowaniu decyzji, czy przypominaniu wspólnego kierunku? Ludzie potrzebują poczucia sensu szczególnie wtedy, gdy potrafią bardzo szybko coś zbudować. Przy takim tempie można też zajść daleko w niewłaściwą stronę, zanim ktokolwiek to zauważy.
Jeśli zarządzasz zespołem, przyjrzyj się trzem powtarzalnym czynnościom. Wybierz jedną, którą możliwości agentów uczyniły zbędną, i skróć ją albo usuń. Być może potrzebne pytanie da się rozstrzygnąć szybkim prototypem lub automatycznym sprawdzeniem. Zachowaj cel, ale pozwól sobie zmienić sposób jego osiągania.
Co można przejąć z przykładu Lauren?
W sposobie pracy Lauren kilka zasad działa jednocześnie: jasna odpowiedzialność, kontrole wykonywane przez agentów i dobry zapis wcześniejszych ustaleń. Udostępniła też otwartą wtyczkę Pstack. Jej wyniki wzrosły od około tysiąca propozycji zmian w lipcu do 2462 zmian dotyczących produktu w sierpniu.
Nie chciałbym, żeby ktoś pokazał te liczby programistom i zażądał od każdego dwóch tysięcy zmian miesięcznie. Bardziej przydatne jest zrozumienie warunków, które pozwoliły Lauren pracować w takim tempie. Jakie kontrole działają automatycznie? Co się dzieje, kiedy zadanie nie powiedzie się w nocy, a programistka śpi? Co kolejny agent może podjąć bez ponownego tłumaczenia całego projektu?
Lauren radzi zacząć od trzech do pięciu osób. Mały zespół może zobaczyć, jak te praktyki współdziałają, zanim spróbuje wprowadzić je szerzej.
Pojawia się tu również temat komunikacji między agentami. Po nagłośnionym incydencie związanym z Hugging Face oraz innych dyskusjach o bezpieczeństwie taka współpraca budzi zrozumiały niepokój. Jednocześnie agenci mogą badać różne części problemu, porównywać odpowiedzi i sprawdzać wyniki innych agentów. Ta sama możliwość wymiany informacji może również przenieść błąd dalej.
W opisie incydentu przedstawionym przez OpenAI oraz w analizach METR i Redwood pojawiają się zadania niemożliwe lub wadliwie przygotowane, presja na ich rozwiązanie, zawodzące zabezpieczenia i przekazywanie informacji między agentami. Nie oznacza to, że każda rozmowa agentów jest niebezpieczna. Pokazuje potrzebę granic działania, kontroli i możliwości przerwania pracy, kiedy zadania nie da się wykonać. Agent powinien móc powiedzieć: „Utknąłem”.
Dodanie kolejnego agenta nie zwalnia ludzi z odpowiedzialności za środowisko, w którym te systemy działają. Możesz zdecydować, gdzie będą zapisane wyniki, jak następna sesja podejmie pracę, co agent sprawdzi samodzielnie i które stare kroki przestaną obowiązywać. Możesz też sprawić, by agent zgłosił problem, kiedy nie potrafi sobie poradzić. Dzięki temu nie musisz osobiście odblokowywać każdej drobnej czynności, choć nadal odpowiadasz za rezultat udostępniony użytkownikom.
Co ważne, poprawa organizacji pracy całego zespołu nie wymaga spowalniania jego najwydajniejszych osób. Ludzie osiągający wyjątkowe wyniki mogą nadal działać po swojemu, a reszta dostaje lepsze warunki pracy. W rozmowach z firmami słyszę, że wzrost skuteczności całego zespołu o 20–30 procent byłby bardzo dużą zmianą. Przy stu programistach taka poprawa ma większe znaczenie niż próba doprowadzenia każdego do niezwykłego indywidualnego wyniku.
Proste systemy są łatwiejsze do utrzymania przy zmianach technologii i łatwiejsze do zastosowania w większej grupie. Trzeba jednak pamiętać, że liczba propozycji zmian nie jest sama w sobie miarą wartości. Podobnie liczba linii kodu czy poczucie produktywności po intensywnym tygodniu. Ważne jest to, czy zespół dostarcza rzeczy potrzebne ludziom i czy traci mniej czasu na wielokrotne tłumaczenie agentom tych samych spraw.
Zacznij od problemu, którego rozwiązanie ma wyraźną wartość. Znajdź przeszkodę: czy wiedza nie przechodzi między osobami, czy brakuje granic działania agentów, czy może nie mają jak sprawdzić wyników? Od odpowiedzi zależy, którą zasadę warto wdrożyć najpierw.
Przygotowałem również zestaw materiałów, który ma pomóc przenieść te pomysły do repozytorium, gdzie pracuje agent. Każda z sześciu zasad ma własny plik do uzupełnienia, obok przykładu z rzeczywistej migracji projektu. Jest też zestaw pytań pomagających ocenić, czy nowe rozwiązanie tworzy wartość, czy tylko komplikuje pracę. Odnośnik znajduje się w opisie nagrania.
O pracy z AI często opowiada się przez pryzmat firm tworzących modele. Tymczasem ważnych rzeczy uczą się również programiści i zespoły w całej branży. Warto zbierać te doświadczenia, szukać zasad, które powtarzają się w różnych miejscach, i na ich podstawie budować bezpieczne, odpowiedzialne oraz naprawdę pomocne sposoby współpracy z agentami.