AI++, czyli o interferencjach sztucznej inteligencji i developmentu

Fale mogą się znosić lub wzmacniać. W jaki sposób będą oddziaływać na siebie trendy, które adaptują AI do różnych zastosowań w cyklu rozwoju i życia oprogramowania? 

Programowanie z wykorzystaniem narzędzi AI, pomimo szeregu zastrzeżeń jakie rodzi wykorzystanie modeli uczących się i czerpiących z wytworzonego wcześniej kodu, jest zapewne jednym z bardziej namacalnych dowodów na to, jak sztuczna inteligencja zmienia sposób pracy.

Programowanie z wykorzystaniem narzędzi AI

Według Gartnera, do 2026 r. 80% firm będzie wykorzystywać modele i API do generatywnej AI oraz aplikacje oparte na generatywnej AI w wytwarzaniu oprogramowania. Skok jest ogromny, biorąc pod uwagę krótką historię współczesnej fali oprogramowania wspierającego programistę w oparciu o sugestie modelu AI.

Liderem rynku jest GitHub Copilot, narzędzie wytworzone przez Open AI i należące obecnie do Microsoft. W październiku 2023 roku posiadał on ponad 1 mln płatnych subskrybentów z 37 tys. firm na świecie. Sam GitHub chwali się ponadto, że jest „domem” dla 100 mln programistów. Według badania Keystone.AI, programiści akceptują ok. 30% sugestii Copilot (odsetek ten rośnie stopniowo od czasu udostępnienia narzędzia), a zależnie od kontekstu wzrost produktywności jest przez nich oceniany na ok. 30%.

Badania wskazują, że większe korzyści z wykorzystania Copilot mają słabsi, a mniejsze doświadczeni programiści. Potwierdzają to także inne badania, dodatkowo szacując indywidualny wzrost produktywności takiego programisty na kilkanaście procent – do kilkudziesięciu procent. Ma to oczywiście swoje konsekwencje dla dalszych perspektyw i scenariuszy zastosowania tych narzędzi, ale o tym za chwilę.

AI-charged DevOps vs AIOPs?

Jeszcze ciekawsze jest nałożenie tego trendu na nurt zmian w całym procesie wytwarzania oprogramowania. Mieliśmy zapoczątkowaną kilkanaście lat temu rewolucję DevOps, jednak metodyka ta potwierdza efektywność w ograniczonym gronie firm, ujawniając zarazem generalną słabość wobec dynamiki i zmienności środowiska technologicznego. W większości przypadków DevOps dąży do przyjęcia indywidualnej – dopasowanej do organizacji – „własnej” wersji DevOps, także podatnej na słabości i ograniczenia.

Odpowiedzią jest częściowy zwrot od fuzji DevOps w stronę Platform Engineering. Przygotowaniem, udostępnianiem i uaktualnianiem do potrzeb środowiska, w którym działać ma powstający kod zajmować mają się znowu osobne zespoły. Aby ich klientom – developerom – było łatwiej, aby wybierali z zamkniętej i zweryfikowanej listy możliwości technologicznych. Jednak i tutaj myśl organizacyjną dogania rewolucja AI i modeli LLM.

Z jednej strony developerzy uwolnieni od nadmiaru „Ops”, ukierunkowują się na bardziej twórcze działania, w tym adaptację wspomnianych na wstępie narzędzi do generowania kodu (ale także np.  konfigurowaniu przy ich pomocy i prowadzenia testów). Zastrzeżenia co do ich zastosowania zapewne zostaną wycofane w związku z ich doskonaleniem i uwzględnieniem zastrzeżeń, wobec presji i wrażenia jakie sprawia kilkunasto- a nawet kilkudziesięciokrotne podniesienie wydajności pracy programisty. Zespół odpowiedzialny za platformę będzie musiał zweryfikować i „wciągnąć” je na pokład.

Z drugiej strony platformy automatyzujące pracę developerów stają wobec konieczności automatyzowania własnej pracy. W jaki sposób uaktualniać środowisko dla developerów, kiedy już otworzy się je na rozwiązania AI, jeśli przybywa potencjalnie przydatnych narzędzi i modeli? Naturalnym wydaje się kierunek jaki wytycza stworzenie GPT dla modeli LLM. Przykład taki stanowi HuggingFace GPT do zarządzania modelami LLM, efekt współpracy HuggingFace i OpenAI.

W ten sposób z nakładających się fal Internal Platform Engineering – Platform Engineering, AI-Augmented Software Engineering, AI Code Assistants czy samego GenAI przekuwa się wizja AIOps, zaobserwowanego na technologicznym nieboskłonie przez Gartnera w 2016. Zespoły Ops, uzbrojone w narzędzia AI wspierające ich w optymalizacji platformy (wydajnościowej, bezpieczeństwa, dostępności, perspektyw rozwoju itd.), udostępniają środowiska developerom, którzy nadzorują pracę różnych narzędzi AI wytwarzających i dokonujących orkiestracji rozwiązań.

Według cytowanego wielokrotnie Gartnera Hype Cycle for Software Engineering, 2023, technologie transformacyjne, w tym wspomniane powyżej inżynieria oprogramowania wspomagana sztuczną inteligencją (AIASE), asystenci kodowania AI (AI Code Assistants) i inżynieria platform (Platform Engineering), wejdą do grona rozwiązań głównego nurtu w ciągu 2–5 lat.

Może to wizja, dzięki której IT będzie w stanie wreszcie uprzedzać zapytania biznesu o nowe produkty, rozwiązania, o zmiany… Do momentu oczywiście, gdy biznes otrzyma od dostawcy, dzięki nieśmiertelnemu by-pass’owaniu i Shadow IT, bez wiedzy własnego IT, supergenerator AI potrzeb biznesowych. Automatycznie wyszukujący zarówno luki w ofercie firmy, jak i w możliwościach IT, wspieranego przez inne supergeneratory rozwiązań dla potencjalnych potrzeb biznesowych.

Podział IT – nonIT utrzyma się przecież nawet w bezszwowej organizacji przyszłości, tak, jak w bezklasowym społeczeństwie najlepszego ustroju na świecie jego członkowie bez trudu, po kilkuminutowej konwersacji identyfikowali „swoich” i „obcych”. I w tej dychotomii, w walce postu z karnawałem, w tym twórczym konflikcie upatrywać nadziei dalszego rozwoju.

Zastrzeżenia i ograniczenia asystentów programowania

Wracając jednak do codziennej pracy programistów. Trudności i zastrzeżenia dotyczące wykorzystania asystentów AI programisty, które uwzględniają zarówno perspektywę samego programisty, jak i inżyniera odpowiedzialnego za środowisko zawierające to narzędzie – mogą być wspólne. Oto jakie wyzwania widzi sama GenAI (popołudniowa sesja z ChatGPT):

• zrozumienie kontekstu i intencji kodu programisty, co może przynosić sugestie prowadzące na manowce;
• wybór najlepszej opcji w sytuacji, gdy istnieje wiele poprawnych sposobów na zaimplementowanie danego fragmentu kodu (problem niejednoznaczności);
• zakres danych szkoleniowych, a przede wszystkim ich jakość i różnorodność – przekłada się wprost na jakość sugestii;
• integracja z różnymi środowiskami programistycznymi, w tym edytorami kodu i środowiskami programistycznymi;
• uczenie się i dopasowanie do stylu – preferencji programisty, o ile personalizacja sugestii kodowania jest możliwa, zapewne wymaga określenia w jakim zakresie;
• bezpieczeństwo – unikanie podatności, które mogły występować w pierwotnie w repozytoriach kodu, stanowiących materiał szkoleniowy (mógł on np. powstać w czasie, kiedy dana podatność nie była jeszcze znana);
• zapewnienie transparentności i wyjaśnialności, pozwoli zaufać sugestiom narzędzia szczególnie bardziej doświadczonym programistom i w większym stopniu korzystać z sugestii;
• równomierny rozwój pozwalający na szeroki zakres wsparcia w różnorodnym zakresie języków programowania i frameworkach;
• uwzględnienie kwestii etycznych związanych z zastosowaniem sztucznej inteligencji – być może jako predefiniowana podstawa – ale trudno sobie wyobrazić, aby w całości asystent przejmował odpowiedzialność za tę sferę; co innego platformy IDE.

Z punktu widzenia poprawy produktywności, jaką obiecuje i niewątpliwie wnosi wykorzystanie wsparcia AI w kodowaniu, problemy te można sprowadzić do dwóch kwestii.

GenAI notorycznie się myli. Powiela też błędy i podatności, które przyswoiło w publicznie dostępnych repozytoriach kodu – swoich zasobach edukacyjnych. Modele Copilot zostały np. przeszkolone w oparciu o repozytorium GitHub, którego historia sięga 15 lat wstecz. Ten kod zawiera nie tylko błędy, ale także luki w zabezpieczeniach, które nie były znane w momencie pisania kodu.

Po drugie – może sugerować kod, który jest zbyt skomplikowany lub nie jest zgodny z tym, co doświadczeni programiści uznają za najlepsze praktyki. Sugestie tworzą niekiedy niepotrzebnie, nadmiernie złożony, niejasny kod – trudniejszy do odczytania, sprawdzenia i wykorzystania, np. powielenia. Dowodzą tego badania prowadzone m.in. przez Arghavan Moradi Dakhel, badaczkę z Politechniki Montrealskiej. Komentując swoje badania w rozmowie z MIT Technology Review ocenia, że z czasem może stać się to istotnym problemem, jeśli udział kodu wytworzonego przy wsparciu AI będzie rósł.

Dodatkowa złożoność przyniesie np. wyzwania związane z utrzymaniem. W miarę używania sztucznej inteligencji o coraz większej liczbie kodu będziemy mieć coraz mniejsze pojęcie. To, co wygeneruje sztuczna inteligencja, będzie w coraz większym stopniu czarną skrzynką, a więc będzie też coraz trudniejsze w utrzymaniu dla ludzi. Z drugiej strony, dane treningowe mogą okazać się zbyt słabe, aby silnik dawał realne wsparcie, jeśli poszukiwane rozwiązanie ma stanowić odbicie unikalnej, specjalistycznej wiedzy firmy.

Sztuczna inteligencja będzie wspierać utrzymywanie oprogramowanie, które walnie pomoże stworzyć, ale nie zastąpi ludzi. Kod współtworzony przez AI wymaga weryfikacji, walidacji. I nie podoła temu programista, któremu brakuje umiejętności, wiedzy i doświadczenia. Zresztą, użytkownicy asystentów AI nie oczekują cudu i dostarczania gotowych, pełnych rozwiązań. Nie widzą też przeciwskazań, aby samemu dopracować sugestię, którą dostarczy asystent AI. Narzędzie dostarcza półfabrykat i elementy, ale odpowiedzialnym za ich złożenie i całość pozostaje programista. Jaki jest ciężar tej odpowiedzialności?

Czuły inżynier, czyli kwestie etyczne AI

Chris Nolan, reżyser „Oppenheimera”, na tydzień przed premierą filmu udzielił wywiadu, w którym powiedział, że w rozmowach z nim czołowi twórcy AI porównywali swoją obecną sytuację do dylematów przed jakimi stał „ojciec bomby atomowej”. To chwytliwe porównanie wielokrotnie powtórzone na potrzeby promocji filmu, odnosiło się do trudności w nałożeniu prawnych – albo raczej wykonawczych – wędzideł na dynamiczny rozwój AI, które mogłoby z czasem przejąć w zarządzanie np. arsenał broni atomowej.

„Moment Oppenheimerowski”, którego doświadczają badacze i twórcy AI, nie przychodzi w dobrym momencie. Programiści nie są uczeni rozwiązywania problemów etycznych, konfrontowania się z wpływem jaki ich praca ma na społeczeństwo. I trudno, aby stali się w tym zakresie szybko specjalistami. Problem jest wreszcie rozproszony – pomiędzy tysiące programistów, którzy posiadają dostęp do narzędzi AI – Oppenheimer realizował projekt unikalny, jednorazowy.  Firmom pozostanie zatem zatrudnić ekspertów albo szybko zbudować nowy zespół osób kompetentnych w tym zakresie, który pozwoli podjąć te dylematy programistom.

Sztuczna inteligencja i programowanie: gdzie są konfitury?

Szeroką perspektywę tych wyzwań opisał w ITwiz Maciej Chojnowski, dyrektor Centrum Etyki Technologii. Większość kwestii zawartych w nim, głównie odnośnie do strony prawnej i jakby to nie brzmiało – organizacyjnej, omawianych także swego czasu podczas spotkania CXO HUB, pozostaje aktualnych.

Elementów, które powinni więc uwzględnić architekci i inżynierowie odpowiedzialni za całościową strategię i wdrożenie AI do procesu wytwarzania, rozwoju i utrzymania oprogramowania jest więc wiele. Jeśli mają przygotować dynamiczne, efektywne środowisko pracy dla programistów, muszą podjąć szereg decyzji.

Można na nie spojrzeć przez pryzmat kategorii narzędzi, które dotyczą samej inżynierii oprogramowania: od frameworków projektowania, uczenia i wdrażania ML (np. PyTorch, Tensor Flow), przez platformy AI oparte na chmurze (Google Vertex AI, Amazon AWS SageMaker), narzędzia wsparcia w kodowaniu (Copilot, Codex, Duet AI), wstępnie przeszkolone modele i platformy (JetBrains AI Assistant, który łączy różne LLM), po narzędzia do wyszukiwania architektury neuronowej – NAS (Hugging Face’s Transformers).

Nazywanie tego pejzażu narzędzi i platform AI „rozległym” byłoby niedopowiedzeniem. Generatywna sztuczna inteligencja i sztuczna inteligencja jako trendy technologiczne nie wykazują ponadto oznak spowolnienia. Sytuacja jest bardzo płynna. Wiele narzędzi jest wykupywanych lub projekt się kończy albo zmienia warunki dostępu (np. z open source na zamknięty).

Ważne jest nie tylko rozwijanie umiejętności za pomocą używanych narzędzi, firmy i programiści muszą także wbudować w swoje umiejętności zrozumienie ciągłych zmian, aby dostosować środowisko do rynku i portfela dostępnych technologii. Cytowane już badanie Keysone.AI prognozuje, że wpływ Copilot i innych narzędzi wspierających programowanie może do 2030 r. zwiększyć globalną gospodarkę o 1,5 bln dolarów. Jest to miarą zmiany, pewną obietnicą.

Połączenie sztucznej inteligencji z inżynierią oprogramowania niesie korzyści i stwarza nowe możliwości – to oczywiste. Naturalnym wydawało mi się spojrzenie z perspektywy synergii trendów takich, jak adaptacja asystentów programowania (AI Code Assistant) oraz platform/środowisk, predefiniowanych przez specjalne zespoły (Platform Engineering), z uwzględnieniem takich modeli jak AIOps. Jeśli więc mowa o przyszłości, to efekty synergii dotyczyć będą także samego procesu oprogramowania, możliwości jakie uzyska. Podoba mi się zestawienie korzyści, które z tej perspektywy przedstawił redaktor ZDNet, David Gewirtz.

Oto one:

Automatyzacja powtarzalnych zadań – Odpowiednio skonfigurowane środowiska IDE pozwalają przy na wypełnianie blokami kodu. Natomiast AI, która nauczy się wzorów przeznaczenia tego wypełniania, może podpowiadać właściwe zastosowanie. To dałoby przyspieszenie, ale i uspójnienie efektów pracy.

Analiza predykcyjna i większa niezawodność oprogramowania – Sztuczna inteligencja może w oparciu o wzorce przewidywać zachowanie kodu. Prognozy mogą dotyczyć przewidywania przeciążeń systemu, zachowania użytkowników, optymalizacji doświadczenia użytkownika i – jak to w analityce predykcyjnej – harmonogramowaniu konserwacji, która zapobiegnie awarii lub utracie efektywności. Także aktualizacja kodu do założonego poziomu wymagań mogłaby pozostawać w gestii AI.

Przyspieszenie cyklu rozwoju/testowania – Jeśli sztuczna inteligencja będzie w stanie przewidzieć zachowanie oprogramowania, może zgłosić błędy jeszcze przed rozpoczęciem testowania. Takie błędy, np. składni, potrafią sygnalizować istniejące środowiska programowania, ale ostrzeżenie przed błędami logicznymi pozwoliłoby przyspieszyć dostarczanie kodu wobec zmniejszenia liczby poprawek.

Obniżenie kosztów utrzymania – AI mogłoby przejąć utrzymanie dostarczonego oprogramowania, automatycznie wprowadzając zmiany i naprawiając wykryte błędy.

Wsparcie zespołów – AI pozwoli, monitorując pracę całego zespołu, znosić nadmierne obciążenia poszczególnych jego członków, poprawić przydział zadań.

Wracając zatem do początkowej analogii ze zjawiskiem nakładania się fal: adaptacja AI do inżynierii programowania dotyczy trendów technologicznych w różnych fazach, ale nie w przeciwfazie.