Proces wytwarzania oprogramowania z AI - jak zmienia się współpraca biznesu i IT

‍
AI realnie obniża koszty tworzenia oprogramowania i pozwala zrobić więcej, szybciej, taniej i często w znacznie mniejszych zespołach. A jeśli faktycznie chcesz wykorzystać ten potencjał w swojej firmie, to trzeba zrozumieć kilka ważnych rzeczy. Przede wszystkim AI nie jest tylko narzędziem do pisania kodu.

AI zmienia de facto rolę programisty i sposób w jaki powinien wyglądać proces współpracy. I o tym będzie ten odcinek. Co się zmienia, co jest realnie opłacalne, gdzie AI faktycznie przyspiesza, a gdzie potrafi wprowadzić nowe ryzyka.

Zacznijmy od porównania standardowego procesu wytwarzania oprogramowania z tym, który dzieje się z wykorzystaniem AI. Jeśli spojrzymy na to, jak w praktyce działa wytwarzanie oprogramowania w firmach, to często wygląda to tak, że kontakt z tak zwanym biznesem albo klientem jest prowadzony głównie przez rolę pośrednie. Czy to projekt menadżera, czy analityka biznesowego. To te osoby zbierają potrzeby, porządkują wymagania, spisują je i doprecyzowują, i dopiero później przekazują je do zespołu technicznego. I w wielu zespołach technicznych wciąż działa dość prosty schemat.

Przyszło zadanie, realizujemy zadanie, oddajemy klientowi do odbioru. Czyli skupiamy się bardziej na tym, jak to zrobić technicznie, niż na tym, po co to robimy i jaki ma być oczekiwany efekt biznesowy. W momencie, kiedy zaczynamy wdrażać do procesu narzędzia i wykorzystujemy sztuczną inteligencję, zmienia się ten punkt ciężkości.

Coraz częściej musi przejmować część odpowiedzialności za to, żeby rozwiązanie miało sens w kontekście procesu i danych, na których działa aplikacja, po to, żeby móc sensownie wykorzystać AI, dobrze je naprowadzić i po prostu tym procesem świadomie zarządzić.

Gdzie AI daje największy zwrot z inwestycji – systemy budowane od zera

Gdzie AI można wykorzystać już dziś w procesie programowania? Tutaj bardzo ważne jest rozróżnienie dwóch typów projektów. Pierwszy typ to systemy budowane od zera.

W systemach wpisanych od podstaw jest dużo pracy takiej typowo produkcyjnej. Trzeba zbudować fundamenty, moduły, logikę biznesową, interfejsy, integracje i często też bardzo dużo powtarzalnych elementów, które po prostu muszą powstać, żeby system mógł działać. I to jest moment, w którym AI daje naprawdę duży zwrot z inwestycji.

Bo można szybciej budować, szybciej iterować, jeszcze szybciej robić prototypy i zwyczajnie szybciej sprawdzać założenia biznesowe z rzeczywistością. W takim wypadku AI realnie potrafi obniżyć koszt tworzenia oprogramowania, bo skraca czas pracy dokładnie tam, gdzie jest dużo implementacji i powtarzalnych fragmentów.

AI w utrzymaniu i rozwoju systemów – dokumentacja, analiza i dług technologiczny

‍
Natomiast w momencie, kiedy system już działa i przechodzimy do etapu utrzymania oraz rozwoju, sytuacja zaczyna wyglądać zupełnie inaczej.

Bo wtedy bardzo często przestaje się liczyć to, ile kodu dopiszemy, a zaczyna się liczyć to, czy w ogóle my ten system znamy i rozumiemy. I czy kolejna osoba, która wejdzie do projektu, będzie w stanie się w tym systemie odnaleźć. I niezależnie od tego, czy kod powstawał ręcznie, czy z wykorzystaniem AI, to wszystko musi być dopięte tak samo dobrze.

Czytelny kod, sensowna struktura, dokumentacja i jasne, udokumentowane decyzje architektoniczne. W kodzie produkcyjnym nie ma miejsca na oddawanie fragmentów, których tak naprawdę nie rozumiemy. I tu pasuje bardzo prosta anegdotka, która świetnie oddaje, jak wygląda utrzymanie systemów.

Ktoś płaci 1000 zł i na fakturze widzi złotówkę za użycie młotka, ale 999 zł za to, że wiesz, gdzie uderzyć. I dokładnie tak samo jest w IT przy systemach utrzymaniowych. Czasem zmiana to dosłownie dwie linijki kodu.

Ale nawet w projektach utrzymaniowych AI może realnie wesprzeć pracę programistów, tylko już w trochę inny sposób niż przy budowaniu systemów od zera. Może tutaj pomóc nadrobić brakującą dokumentację, opisać strukturę projektu, wytłumaczyć zależności między modułami, wskazać, gdzie w systemie może znajdować się dana logika. W praktyce oznacza to, że zamiast kilku godzin ręcznego przeklikiwania się przez repozytorium, można szybciej złapać ogólny obraz projektu i zrozumieć, jak te elementy są ze sobą powiązane.

I to jest szczególnie wartościowe w projektach, które były rozwijane latami albo przechodziły przez wiele rąk. Podobnie wygląda też temat długu technologicznego. Jeśli porządkowanie systemu polega na wydzielaniu modułów, planowaniu migracji albo stopniowym przepisywaniu fragmentów aplikacji, AI może nam pomóc przygotować mapę zależności, listę krytycznych elementów, wstępny zakres zmian do wykonania.

Oczywiście, takie podpowiedzi zawsze muszą być zweryfikowane przez zespół techniczny, ale jako punkt wyjścia do dalszych decyzji to realnie skraca czas i porządkuje pracę.

AI a debugowanie i dane produkcyjne - ryzyko bezpieczeństwa

W projektach utrzymaniowych jest jednak jeden obszar, w którym AI potrafi bardzo szybko pomóc, ale również szybko narobić problemów. To klasyczna sytuacja, którą zna chyba każdy zespół techniczny.

Na lokalnym środowisku wszystko działa poprawnie, a na produkcji system się wysypuje przy określonych tzw. przypadkach brzegowych, czyli tzw. u mnie nie działa.

I bardzo często przyczyna nie leży w samym kodzie, bo kod bywa identyczny i na produkcji, i na środowisku lokalnym. Różnica jest w danych. Lokalne środowisko działa na uproszczonych testowych rekordach, a produkcja na realnych danych pełnych wyjątków, historii i nietypowych kombinacji.

I właśnie w tym miejscu pojawia się pokusa pójścia na skróty. No bo skoro problem dotyczy danych, to najprościej byłoby skopiować bazę z produkcji i spróbować odtworzyć błąd lokalnie na tej samej bazie. Tyle, że to nigdy nie było dobre rozwiązanie i nadal nim nie jest.

AI daje tu dużo lepszą alternatywę pod warunkiem, że jest świadomie używane. Zamiast kopiować produkcyjne dane, można opisać problem, czyli jakie pola mają znaczenie, jakie wartości występują, jakie warunki muszą być spełnione, żeby błąd się pojawił i na tej podstawie wygenerować dane testowe, które odtwarzają konkretny przypadek bez dotykania produkcji i bez ryzyka wycieku informacji. W takim scenariuszu AI faktycznie przyspiesza debugowanie i zmniejsza ryzyko.

Problem zaczyna się wtedy, gdy zespoły robią dokładnie odwrotnie. Czyli gdy do narzędzia opartych o AI trafiają fragmenty kodu z danymi dostępowymi, konfiguracje środowisk produkcyjnych albo wręcz całe fragmenty bazy. I tu ryzyko przestaje być teoretyczne.

Dobrym przykładem jest historia związana z GitHub Copilotem i z danymi wyciąganymi z repozytoriów. W jednym z badań, podlinkujemy w opisie, w jakim pokazano, że przy odpowiednim promptowaniu da się wydobywać ciągi znaków, które wyglądają jak realne dane dostępowe, czyli hasła, tokeny, klucze API. I te dane wcześniej trafiły do kodu, a kod trafił do repozytoriów.

Pytanie, czy tak powinno być patrząc przez pryzmat dobrych praktyk, ale to jest temat na zupełnie inny odcinek. Ale to jest właśnie bardzo ważna lekcja dla projektów utrzymaniowych. AI nie zwalnia zespołu z myślenia o bezpieczeństwie. Wręcz przeciwnie, wymusza znacznie większą dyscyplinę.

Podsumowując, wykorzystanie AI to dzisiaj ogromne przyspieszenie dla wytwarzania oprogramowania, ale tylko wtedy, gdy jest wpisany w świadomie zaprojektowany proces, a nie traktowany jako magiczny skrót. Jeśli myślisz o wdrożeniu AI do swojego zespołu, to daj znać.


Źródło: https://blog.gitguardian.com/yes-github-copilot-can-leak-secrets