Jeszcze dwa lata temu większość dnia pracy spędzałem na pisaniu kodu. Dziś znacznie więcej czasu zajmuje mi opisywanie tego, co ma powstać, sprawdzanie wyników i podejmowanie decyzji. Z pomocą AI kodu powstaje tyle, ile wcześniej nie widziałem przez tydzień. Muszę umieć ocenić, czy nadaje się do użycia.
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.