Ta zmiana wpływa na cały sposób realizacji projektów. Programista inaczej wykorzystuje doświadczenie, agencja musi ponownie przemyśleć wycenę, a klient może zamówić prace, na które wcześniej brakowało budżetu. Każda z tych stron ma jednak inne zadanie do wykonania.

Doświadczenie przydaje się przy ocenie rozwiązania

W mojej pracy coraz większe znaczenie ma precyzyjne określenie zadania. Model potrzebuje opisu tego, co aplikacja ma robić. Jeśli opis jest niepełny, wygenerowany kod może wyglądać poprawnie, a mimo to rozwiązywać inny problem niż ten, z którym przyszedł klient.

Dlatego po wygenerowaniu kodu muszę wrócić do założeń i ocenić wynik. Tu korzystam z doświadczenia zdobytego przy wcześniejszych wdrożeniach. Pomaga mi rozpoznać błędne rozwiązanie, zanim trafi do sklepu, i zdecydować, co wymaga poprawy. Samo tempo pisania ma w tym procesie coraz mniejsze znaczenie.

Widać to na przykładzie panelu ekspertów PrestaShop, przy którym kiedyś pracowałem. Budowaliśmy go w trzech programistów przez trzy miesiące. Dziś oceniam, że z obecnymi narzędziami zrobiłbym ten sam projekt sam w miesiąc, uwzględniając sprawdzanie kodu. Duża część ówczesnej pracy była powtarzalna i właśnie ją najłatwiej mi teraz przyspieszyć.

Trudniej zacząć od prostych zadań

Przy takim sposobie pracy pojawia się problem nauki zawodu. Początkujący programista zdobywał doświadczenie na prostszych, powtarzalnych zadaniach. Ktoś musiał je wykonać, a junior miał okazję samodzielnie napisać kod i zrozumieć jego działanie.

Kiedy te zadania przejmuje model, od początkującej osoby szybciej oczekuje się oceny gotowego rozwiązania. Tyle że do tej oceny potrzebna jest wiedza, którą wcześniej zdobywało się właśnie przez pisanie. Nie mam jeszcze dobrej odpowiedzi na pytanie, jak powinna wyglądać taka nauka. Widzę natomiast, że dotychczasowa droga wejścia do zawodu wymaga przemyślenia.

Wycena musi uwzględniać nowy sposób pracy

Agencje przez lata opierały wyceny na godzinach programistów. Szacowały czas potrzebny na wykonanie zadań i mnożyły go przez stawkę. Trafność tych szacunków decydowała o tym, ile zostanie z projektu po pokryciu kosztów.

Jeśli część zadań można wykonać kilkukrotnie szybciej, stare kalkulacje przestają odpowiadać rzeczywistemu nakładowi pracy. Jedne agencje obniżają ceny i przyjmują więcej zleceń. Inne utrzymują cenę, mocniej opierając ofertę na zrozumieniu potrzeb klienta i odpowiedzialności za wdrożenie. Są też wykonawcy, którzy nadal wyceniają projekty według dawnych założeń.

Z punktu widzenia klienta liczy się więc wyjaśnienie, co zawiera oferta. Ile czasu zajmie rozpoznanie potrzeb? Jak powstanie kod i kto go sprawdzi? Co wykonawca zrobi, gdy po uruchomieniu pojawi się problem? Sama informacja o korzystaniu z AI nie odpowiada na żadne z tych pytań.

Niższy koszt wykonania otwiera nowe możliwości

Dla właściciela sklepu krótszy czas pracy może oznaczać tańszy moduł, integrację z magazynem albo przebudowę koszyka. Wtedy zmiany odkładane ze względu na koszt stają się możliwe w obecnym budżecie. To bardzo praktyczny skutek rozwoju tych narzędzi.

Oszczędność ma jednak sens wtedy, gdy obejmuje wykonanie działającego rozwiązania wraz z jego sprawdzeniem. Kod da się wygenerować szybko również bez kontroli. Moduł uruchomiony po jednym wieczorze pracy może działać do pierwszej aktualizacji platformy albo nietypowego zamówienia.

Spodziewam się, że takich przypadków będzie coraz więcej w audytach. Ustalenie przyczyny awarii nadal wymaga zrozumienia, co się wydarzyło, i nie staje się tańsze tylko dlatego, że sam kod powstał szybko. Dlatego przy wyborze wykonawcy pytałbym o testy, przegląd kodu i odpowiedzialność za późniejsze naprawy.

Najpierw trzeba wiedzieć, co warto zbudować

Niezależnie od narzędzi sklep potrzebuje rozwiązania dopasowanego do sposobu działania firmy. Model danych trzeba zaprojektować pod jej procesy. Przy integracji z ERP nadal potrzebuję rozmowy z osobą, która wie, dlaczego numer partii trafia do pola uwag. Tego nie wyczytam z przykładu w dokumentacji.

Podobnie jest z decyzją o migracji. Zanim doradzę zmianę platformy, przebudowę sklepu albo pozostawienie obecnego rozwiązania, muszę porównać koszty tych wariantów. AI pomaga w wykonaniu prac, ale bez wiedzy o firmie nie wybierze za klienta właściwego kierunku.

Właśnie dlatego w mojej pracy więcej miejsca zajmują dziś rozmowy, decyzje i ocena wyników. Mogę szybciej zbudować rozwiązanie, więc tym bardziej chcę najpierw ustalić, czy klient rzeczywiście go potrzebuje i czy koszt jego wykonania ma uzasadnienie.

Artykuł AI zmienia nasz świat pochodzi z serwisu eCommerce Expert.

Wracam do tego projektu, bo dobrze pokazuje, jak zmieniła się moja praca. Znam jego zakres i pamiętam, na co poświęcaliśmy czas. Mogę więc porównać konkretne zadania z tym, jak podszedłbym do nich teraz.

Prosty katalog, sporo pracy pod spodem

Panel ekspertów PrestaShop to katalog certyfikowanych agencji. Właściciel sklepu przegląda ich profile, sprawdza specjalizacje i referencje, a następnie kontaktuje się z wybranym wykonawcą. Agencje zarządzają swoimi profilami i dbają o to, jak prezentują się na tle konkurencji.

Z perspektywy odwiedzającego zasada działania jest prosta. Przy budowie trzeba jednak zadbać o każdy etap: wprowadzanie danych, ich sprawdzanie, wyszukiwanie i prezentację wyników. Filtr wybrany na stronie musi odpowiadać parametrom w adresie i zapytaniu do bazy. Formularz powinien przyjąć poprawne dane i wychwycić błędne. Wszystko musi działać w różnych wersjach językowych.

Do tego dochodzi panel administracyjny. Użytkownik katalogu go nie widzi, ale jego wykonanie zajmowało tyle pracy co część publiczna. Właśnie takie zadania wypełniały nam kolejne tygodnie: potrzebne, często powtarzalne, a każde wymagające napisania i sprawdzenia kodu.

Trzy osoby oznaczały także czas na współpracę

Podział zadań pozwalał pracować równolegle, ale wymagał codziennych ustaleń. Czekaliśmy na przegląd kodu, uzgadnialiśmy rozwiązania i scalaliśmy zmiany, które powstawały w różnych częściach aplikacji. W harmonogramie ta współpraca wyglądała skromniej niż później w praktyce.

Dlatego trzy miesiące pracy trzech osób to znacznie więcej niż samo pisanie funkcji. W tym czasie mieściło się również wszystko, co było potrzebne, żeby z osobnych fragmentów powstała jedna działająca aplikacja.

Jak wyglądałaby ta praca dzisiaj

Przez ostatnie miesiące przygotowałem sobie zestaw narzędzi opartych na modelach językowych. Powierzam im dużą część powtarzalnej pracy programistycznej. Przy takim katalogu zacząłbym od opisania struktury danych i zasad działania, a następnie na tej podstawie tworzył szkielet aplikacji, migracje i panel administracyjny.

To zadania, przy których dziś myślę o dniach zamiast tygodni. Podobnie jest z formularzami, walidacją i wersjami językowymi: wspólny opis pozwala wygenerować powiązane fragmenty, które wcześniej trzeba było pisać osobno. Moja praca polega wtedy na sprawdzeniu, czy wynik odpowiada założeniom. Szczególnej uwagi wymagają miejsca, w których rozwiązanie odbiega od typowego schematu.

Zmieniło się też miejsce testów w całym procesie. Wcześniej zostawały na koniec, o ile wystarczyło czasu, a rzadko wystarczało. Teraz powstają razem z kodem. Do przeglądu mogę przejść od razu, bez oczekiwania na zakończenie zadania przez drugiego programistę.

Stąd mój szacunek: miesiąc samodzielnej pracy zamiast dziewięciu osobomiesięcy. Znaczna część tamtego wysiłku przypadała na czynności, które obecnie wykonują narzędzia. Przy pracy w pojedynkę odpada również czas potrzebny na koordynację trzech osób.

Co uwzględniam w tym miesiącu

Nadal musiałbym porozmawiać z ludźmi, którzy będą korzystać z panelu. Ustalić zawartość profilu agencji, uprawnienia do edycji i sposób wyszukiwania. Dobrym przykładem jest filtr kraju. Ma wskazywać siedzibę agencji czy rynek, który ona obsługuje? Oba warianty da się zaprogramować. Wybór zależy od tego, jak właściciel sklepu szuka wykonawcy.

Model może zaproponować odpowiedź, ale bez znajomości potrzeb użytkowników łatwo przyjąć błędne założenie. Szybsze napisanie kodu nie zwalnia mnie z podjęcia tej decyzji.

W szacowanym miesiącu uwzględniam także czytanie i sprawdzanie wygenerowanego kodu. Wymaga co najmniej takiej samej uwagi jak kod pisany ręcznie. Gotowo wyglądające rozwiązanie potrafi uśpić czujność, a za jego działanie nadal odpowiadam ja.

Co to porównanie mówi o wycenie projektu

Ten miesiąc jest moją oceną konkretnego, znanego mi projektu. Pokazuje, jak duże znaczenie dla kosztu wdrożenia ma sposób pracy wykonawcy. Przez lata liczyliśmy przede wszystkim czas potrzebny programistom na napisanie rozwiązania. Dziś przy powtarzalnych zadaniach ten nakład może być znacznie mniejszy.

Jeżeli zamawiasz podobny panel, poproś wykonawcę o wyjaśnienie, na co przeznaczy czas z wyceny. Jak korzysta z AI? Ile pracy przewiduje na ustalenie wymagań, a ile na sprawdzenie rezultatu? Z takiej rozmowy dowiesz się więcej niż z samej liczby godzin.

To porównanie skłoniło mnie też do szerszego spojrzenia na mój zawód i sposób rozliczania wdrożeń. Piszę o tym w artykule AI zmienia nasz świat.

Artykuł Projekt, na który mieliśmy trzy miesiące pochodzi z serwisu eCommerce Expert.