GitHub Copilot – pierwsze wrażenia

Jeżeli w miarę na bieżąco śledzicie gorące tematy technologiczne, to zapewne doskonale wiecie o istnieniu nowego narzędzia od OpenAI, czyli ChatGPT. Wszyscy zachwycają się faktem, że ten system uczenia maszynowego potrafi tak dobrze udawać, że rozmawiamy z prawdziwym człowiekiem. W momencie pisania tego tekstu wiele dyskusji skupia się na dwóch rzeczach. Na tym, że dzieci w szkole i dorośli w pracy zaczynają używać AI do generowania tekstów, które powinni napisać sami. I na tym, że AI zabierze wielu ludziom pracę. Między innymi programistom, bo przecież ChatGPT, na pytanie o kod, potrafi (czasami nawet z dobrym skutkiem) podać nam kawałek kodu, który spełnia swoją rolę.

Jednak jak to opisywał na swoim Instagramie Andrzej Krzywda – AI będzie wg niego ułatwiało pracę programistów, a nie ich zastępowało. I w tym kontekście istnieje już narzędzie, które pełni tą rolę. Mowa o GitHub Copilot. Było o nim głośno wśród programistów jakiś czas temu, w momencie, kiedy wersja testowa wchodziła na rynek. Jednak z jakiegoś powodu ostatnio niewiele się o Copilocie mówi.

Jednak wiedziony ciekawością postanowiłem zainteresować się tym narzędziem. Używam go w tym momencie jedynie w jednym, pobocznym projekcie. Dodatkowo dodam, że robię to (na moment pisania tego tekstu) od jakichś 3 tygodni i korzystam z IDE JetBrains Rider.

Logika w kodzie

GitHub Copilot bazuje na kodzie dziesiątek tysięcy opensource’owych projektów z repozytorium GitHuba. Z tego też powodu można powiedzieć, że „widział dużo”. Nie ma co też się oszukiwać, że codziennie w pracy piszemy tylko unikalny w skali świata kod. Nie jest tak i nigdy nie będzie. Zawsze będziemy korzystali z podobnych frameworków, bibliotek, wzorców projektowych (w końcu po to one istnieją, żeby je powtarzalnie stosować!) i tak dalej. Dlatego istnieje bardzo duże prawdopodobieństwo, że nie jeden, ale setki programistów napisali już wcześniej podobny do naszego kawałek kodu. Zwłaszcza jeżeli pracujemy w językach, które mają mocno zakorzenione konwencje. Tak jest chociażby w języku C#, z którym ja pracuję.

W tym miejscu właśnie zaczyna się zauważalna od razu siła Copilota. Bardzo dobrze sobie to narzędzie radzi z podpowiadaniem kodu związanego z pewnymi powtarzalnymi schematami. Inicjalizacji popularnej biblioteki? N-te sprawdzanie cookies w filtrach w MVC? Robienie switch-case dla wszystkich możliwych wartości z enuma? To są obszary gdzie od razu zobaczysz zalety takiego narzędzia jak GitHub Copilot.

Przykładowo, tak powtarzalna rzecz jak dodawanie kontekstu bazodanowego w projektach .NET Core. Tutaj widać na szaro kod, który zaproponował mi Copilot, bazując na tym co zacząłem wpisywać. Dodatkowo zrozumiał kontekst, tzn. fakt jak może się nazywać moja klasa z kontekstem bazy danych:

To jest prostszy przykład, bo Copilot „wie” też, w jakim pliku pracujemy. Jeżeli jest to właśnie plik Startup.cs z .NET Core, to od razu jest w stanie zaproponować linijki, które najczęściej ludzie tam umieszczają. Chociażby dodawanie autoryzacji czy konfiguracji CORS.

W poniższym przykładzie Copilot zobaczył, że mam klasę ze słowem „repository”, więc od razu założył, że zaczynając nazwę metody od „G” jest duża szansa, że będę chciał napisać „GetX”, w dodatku uwzględniając dodatkowe zależności i wiedząc, że pracuję z Entity Frameworkiem:

Jeżeli wpisany na szaro fragment mi w miarę odpowiada, to po prostu klikam „Tab” i mam od razu napisany kawałek logiki. Mogę to potem ewentualnie rozszerzyć lub zmodyfikować, nadal mając do pomocy Copilota. I to Copilota, który uczy się również tego jak ja piszę kod, bo zauważyłem, że po czasie jego podpowiedzi coraz lepiej dopasowują się do mojego stylu pisania, mimo, że wcześniej w podobnej sytuacji podpowiadał coś innego.

Testy

Drugi moment kiedy widzę, że Copilot robi dobrą robotę, to obszar testów. Wydaje mi się, że w tym przypadku jest nawet lepiej niż w przypadku kodu logiki. Jest tak z prostego powodu – nazwy metod w testach często (w idealnym świecie zawsze) opisują to co się w ciele metody testowej będzie działo. W takim przypadku Copilot ma podane na tacy to, co chcemy osiągnąć w kodzie. Co prawda nie odgadnie wszystkich przypadków biznesowych, które chcemy przetestować, ale dobrze ogarnia te podstawowe, o których nieraz zapominamy, albo których zwyczajnie nie zawsze chce się pisać.

Tutaj przykład bardzo prostego testu. Niby trywialny przypadek, być może nawet nadmiarowy, jednak pokazuje, że Copilot potrafi, na podstawie opisu testu, wydedukować jaką klasę chcę przetestować i jakie potencjalnie asercje będą w kodzie. Nawet jeżeli ostatecznie wynik będzie nieco inny, to i tak Copilot daje nam niezłą bazę podczas pisania testów.
Tak jak w poprzednim podpunkcie, tutaj też kod zasugerowany przez Copilota jest na szaro, jeszcze przed akceptacją i faktycznym wklejeniem do pliku.

Podsumowanie

Po pierwszych próbach z Github Copilot widzę w tym narzędziu bardzo duży potencjał. Nie jest to potencjał na zastąpienie programistów, ale zapewnienie im wsparcia i zbudowanie środowiska pracy, w którym powtarzalne, mało innowacyjne fragmenty kodu piszą się praktycznie same.

W tym momencie dostępna jest jedynie wersja dla indywidualnego użytkownika i uważam, że te 10 dolarów miesięcznie to bardzo dobra cena za to co oferuje. Nawet jeżeli wykorzystamy Copilota jedynie we własnych domowych projektach. Czekam jednak na opcję zakupu przez większe firmy jakiejś licencji grupowej, firmowej. Mam nadzieję, że wtedy będzie to kolejny tool, który stanie się pewnego rodzaju standardem. Pewnie w przypadku licencji dla korporacji wchodzi w grę jakiś motyw zawężania bazy wiedzy Copilota jedynie do wewnętrznych projektów. Co byłoby świetne! Ile razy różne firmy narzucały mi pewien konkretny sposób tworzenia kodu i definiowały masę standardów wewnętrznych. Widzę tutaj ogromny potencjał na usprawnienie pracy programistów w takich firmach i zdecydowane ułatwienie trzymania się firmowych standardów, bez zbędnego poświęcenia czasu na przeszukiwania innych repozytoriów i podglądanie jak inni to zrobili.

Już słyszę te głosy mówiące o tym, że takie narzędzia tylko rozleniwiają programistów i teraz to już nic nie trzeba umieć, żeby pisać kod. Ale co w tym złego? Dlaczego mam znać na pamięć sposób inicjalizowania X bibliotek, co zwykle robię maksymalnie raz, na początku projektu. Wolę, żeby powtarzalna praca była zautomatyzowana, a mój zespół będzie mógł pracować bardziej koncepcyjnie i skupiać się faktycznie na logice biznesowej, innowacji i dostarczaniu realnej wartości.

Gdyby Github Copilot miał jakiś program afiliacyjny to bym na pewno tutaj wrzucał link do niego. Jednak niestety nie ma takiej opcji, więc mogę tylko zachęcić Cię do wejścia na stronę Copilota i przetestowanie wersji okresu próbnego. Podziel się w komentarzu swoimi spostrzeżeniami z korzystania z AI podczas pisania kodu.