To też jest inżynieria

W pracy jestem przyzwyczajony do myślenia w przestrzeni rozwiązań. Dostaję do analizy zadanie – problem, który trzeba jakoś rozwiązać i pozwalam sobie z nim pobyć. Innymi słowy, myślę nad rozwiązaniem. Lata pracy nauczyły mnie jak mapować określone klasy problemów na określony schemat rozwiązania, a kolejne problemy albo potwierdzają sensowność danego schematu albo wyłaniają kolejny, warty zapamiętania. Schematy się tworzą, aktualizują, starzeją, uogólniają. Wymieniam się nimi z innymi. To one pozwalają mi działać efektywnie.

Dzisiaj na scenę wchodzi agent zasilany LLM-em zoptymalizowanym pod osiąganie ustalonych celów, zna prawie każdy wzorzec i potrafi przeglądać dziesiątki miejsc jednocześnie w poszukiwaniu informacji. Dostaje pytanie i po krótkiej chwili proponuje rozwiązanie, które – nawet jeśli nie jest idealne – to stanowi dobry punkt startowy do dalszych prac. Do tego sam je zaimplementuje.

Teoretycznie powinienem się pakować. W porównaniu do agenta długo myślę, piszę wolniej, czasem coś pominę lub zapomnę. Mam wrażenie, że samo odnalezienie miejsc wymagających zmian zajmuje mi więcej czasu, niż agentowi wstępna implementacja mojego pomysłu. Doświadczenie nauczyło mnie jednak, że dobór i implementacja rozwiązania są tylko częścią pracy inżyniera.

Alternatywna ścieżka prowadzi przez skupienie się bardziej na problemach i celach, a mniej na samych rozwiązaniach. Ktoś musi przecież zdecydować, co właściwie trzeba zrobić, jakie kompromisy są dopuszczalne, oraz z jakimi ograniczeniami trzeba się zmierzyć w kontekście zarówno technicznym jak i biznesowym. Samo zdefiniowanie celu nie wystarczy. Co prawda agent przejmie implementację, ale żeby zrobił to sprawnie i zgodnie z wymaganiami potrzebuje zestawu reguł, możliwości weryfikacji oraz odpowiednich narzędzi.

Implementacja nie wystarczy

Większość projektów IT prowadzi do powstania złożonych systemów. Te prostsze – o ile nie wymagają autoryzacji – powinny pozostać arkuszem kalkulacyjnym. Te bardziej rozbudowane posiadają wiele współpracujących ze sobą komponentów, które realizują określone zadania. Zakładając, że musimy być w stanie weryfikować poprawność działania takiego systemu, powinien on być audytowalny oraz możliwy do zrozumienia przez ludzi.

Dzisiejsi agenci są świetni w pisaniu kodu w istniejących projektach, ponieważ podążają za już obranymi praktykami – nawet, jeżeli nie mają one dobrego uzasadnienia. Trochę jak ludzie, którzy patrzą na istniejący kod w nadzieji że można go skopiować, ponownie wykorzystać lub też po prostu się zainspirować.

Ale agenci też błądzą. Próbują używać narzędzi, których nie ma. Uruchamiają komendy, których nie powinni. Zmieniają pliki, które powinny zostać nienaruszone. Wprowadzają za dużo zmian na raz. Próbują testować zmiany po swojemu, z różnym skutkiem. Robią to wszystko, tracąc czas, zasoby i pieniądze – bo jednak tokeny darmowe nie są.

Można jednak skupić się na tym, aby uczynić agentów bardziej użytecznymi przez odpowiednie reguły, skille, instrukcje oraz narzędzia. Kiedy już delegujemy im jakieś zadania, powinniśmy zadbać o środowisko, w którym te rozwiązanie będzie powstawać.

Środowisko rozwiązywania problemów

Zamiast budować budynek, określ do czego ma służyć i jak ma wyglądać. Zadbaj o rusztowania, materiały na szalunki i odpowiednie narzędzia, wprowadzając ciężki sprzęt w razie potrzeby. Przekaż wykonawcom jak powinni z Tobą pracować i co dla Ciebie oznacza, że coś jest gotowe. A kiedy widzisz, że coś nie idzie po Twojej myśli, dowiedz się dlaczego i koryguj – proces lub swoje myślenie.

Reguły, instrukcje dla agenta, dostępne narzędzia, a nawet kontekst samego projektu – to jest środowisko rozwiązywania problemu. Wszystko po to, aby dać agentom więcej możliwości do osiągania celów w sposób szybszy, bardziej wydajny oraz zgodny z naszymi oczekiwaniami.

Na pierwszy rzut oka wygląda to tak, jakby nasza rola sprowadzała się do roli stewarda usługującego agentom zawsze, kiedy nie mogą sobie z czymś poradzić lub zaczynają błądzić. Ja patrzę na to inaczej. Jeżeli celem jest rozwiązanie problemu, to jako inżynierowie powinniśmy wybierać optymalne ścieżki prowadzące do tego rozwiązania.

I chociaż agenci zaczynają przejmować nasze zadania, to ich ukierunkowanie i odpowiednie poprowadzenie jest jeszcze po naszej stronie. Agent implementuje, inżynier projektuje warunki wykonania, ocenia rezultat i poprawia proces. To też inżynieria, tylko problemy są inne. Zmiany są nieuniknione, więc środowisko musi się adaptować do nich cały czas – wchodzą nowe praktyki, powstają nowe narzędzia, zmienia się architektura ponieważ wymagania się zmieniają. Dobre środowisko pracy z agentami wspiera nie tylko agenta, ale też nas, inżynierów, ułatwiając zrozumienie domeny i pozwalając nam odkrywać nowe problemy warte rozwiązania. A ich przecież nie brakuje, nieprawdaż?